Hi Alvaro, Thanks for your review and comments/suggestions. Please check inline below for responses.
We have posted an update which includes the changes as discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09 On Thu, Oct 6, 2022 at 6:21 AM Alvaro Retana via Datatracker < nore...@ietf.org> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-lsr-ospf-reverse-metric-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am balloting DISCUSS because I believe that the behavior specified in > this > document is not clear enough. I think these points should be easy to > address. > > (1) The main behavior in this document (using the reverse metric) is > covered in > the following sentences: > > §6: > A router receiving a Hello packet from its neighbor that contains the > Reverse Metric TLV on a link SHOULD use the RM value to derive the > metric for the link to the advertising router in its Router-LSA... > > ... > The neighbor SHOULD use the reverse TE metric value... > > §7: > Implementations SHOULD NOT accept the RM from its neighbors by default > and SHOULD provide a configuration option to enable the acceptance of > the RM from neighbors on specific links. > > For all cases, why is this behavior recommended and not required? When is > it > ok to not use the RM, or to accept it by default? > KT> This feature is expected to be used in specific deployments and use cases. This behavior is not something that is enabled by default - this applies to both the sending and the receiving side. If the feature is not properly configured/enabled, e.g. if there is a misbehaving router (as in the case pointed out by Martin), we don't want this to affect the network. > > (2) §6: > > A router stops including the Reverse Metric TLV in its Hello packets > when it needs its neighbors to go back to using their own provisioned > metric values. When this happens, a router that had modified its > metric in response to receiving a Reverse Metric TLV from its > neighbor should revert to using its provisioned metric value. > > No normative language is used here -- should there be a SHOULD/MUST there? > > Even if "should revert" is used, the behavior is unclear and could be > interpreted as not required. > KT> Ack. Fixed to use MUST. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (0) I support Martin's DISCUSS. > KT> Please let us know if the response to him and the related text changes address the issue raised. > > (1) The calculation of the RM is out of scope, according to this text from > §6: > > The mechanisms used to determine the value to be used for the > RM is specific to the implementation and use case and is outside the > scope of this document. > > However, there are 3 occurrences in the same section that indicate > requirements > when determining the RM: > > * The RM value that is signaled by a router to its neighbor MUST NOT > be derived from... > > * The RM value that is signaled by a router MUST NOT be derived from... > > ...a router MUST never start, stop, or change its RM metric signaling > based on... > > All 3 instances try to avoid a circular dependency on other RMs, which is > good. > But normatively requiring that behavior (instead of making suggestions or > pointing out the danger) contradicts declaring the mechanism used to > derive the > RM out of scope. > KT> I understand your point. Changed those rules to guidelines along with use of RECOMMENDED and also removed most of the other normative words. The exact mechanism to pick the value is use case and deployment dependent. However, those guardrails are still expected to be followed. > > (2) §6 allows the inclusion of multiple instances of the Reverse Metric TLV > (for different topologies). What should a receiver do if multiple > instances > are received for the same MTID? > KT> Thanks for catching that. It should use the first instance and ignore the rest. Clarified this now. Thanks, Ketan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
