On October 6, 2022 at 5:46:59 AM, Ketan Talaulikar wrote: Ketan:
Hi! ... > > (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. I understand all that. However, the specification should be written and interpreted in the context of using the extension. IOW, if the RM is being used what should be the behavior? Is it only recommended that the RM be used (even after enabling the configuration knob)? Or should it be required? >From your answer I would expect §7 to require configuration (default = off). Why is it only recommended? Thanks! Alvaro. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
