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

[Alvaro Retana <[e-mail]>]

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?
>
> KT> 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.).


Alvaro.