Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

Please check inline with KT3 for response.


On Thu, Oct 6, 2022 at 5:29 PM Alvaro Retana <[e-mail]> 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.
>