Hi Alvaro, I've just posted the update with changes to address your remaining comments (as also Martin's): https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-11
Thanks, Ketan On Thu, Oct 6, 2022 at 8:33 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > 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
