Hi Alvaro, Please check inline with KT3 for response.
On Thu, Oct 6, 2022 at 5:29 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > On October 6, 2022 at 7:44:51 AM, Ketan Talaulikar wrote: > > > Ketan: > > > > > > > (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? > > > > KT2> I think that I now understand your point. Indeed, we need the MUST > for > > both the config for sending and receiving/accepting part. How about the > > following change? > > > > <OLD> > > Implementations MUST NOT signal reverse metric to neighbors by default > and > > MUST provide a configuration option to enable the signaling of reverse > metric > > on specific links. 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. > > </OLD> > > > > <NEW> > > Implementations MUST NOT signal reverse metric to neighbors by default > and > > MUST provide a configuration option to enable the signaling of reverse > metric > > on specific links. Implementations MUST NOT accept the RM from its > neighbors > > by default and MUST provide a configuration option to enable the > acceptance of > > the RM from neighbors on specific links. > > </NEW> > > Yes, that works. > > What about the SHOULDs from §6? If accepting RM has been enabled, > when is it ok to not accept it? I'm assuming that if the > configuration was turned on then the user wants to receive the RM, and > that a misbehavior is addressed separately (back-off, etc.). > KT3> That SHOULD is qualified by what is in the brackets (i.e., reference to sec 7 for enablement). Plus, we have also recently added text in security considerations when the receiver would ignore RM if it saw instability in the RM signaling. Thanks, Ketan > > > Alvaro. >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
