Hi Alvaro,

Thanks for your quick response and please check inline below with KT2 for
response.


On Thu, Oct 6, 2022 at 4:27 PM Alvaro Retana <aretana.i...@gmail.com> wrote:

> On October 6, 2022 at 5:46:59 AM, Ketan Talaulikar wrote:
>
> Ketan:
>
> Hi!
>
>
> ...
> > > (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>

Thanks,
Ketan


>
>
> Thanks!
>
> Alvaro.
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to