Hi Alvaro, We've posted an update to include the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-10
I hope this addresses your DISCUSS and comments. Thanks, Ketan On Thu, Oct 6, 2022 at 5:43 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > 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
