Re: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13

[Dhruv Dhody <[e-mail]>]

Hi Peter,

Thanks for your reply, snipping to points that need further discussion...

> What about:
>
> Segment Routing with the MPLS Data Plane relies on Interior Gateway
> Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666] to signal
> labels.
>

Much better.


> > (3) Section 4
> >
> >     The absence of ERLD-MSD advertisements indicates only that the
> >     advertising node does not support advertisement of this capability.
> >
> >     Do you mean to differentiate between support for the capability itself v/s
> >     support for 'advertisement' only. But RFC 8662 says that ERLD value is
> >     advertised only when following conditions are met:
>
> What is meant is that even though all the below conditions are set, if
> the node does not support the advertisement, one can not conclude what
> its ERLD is.
>
> If the node supports the advertisement of the ERLD, but the below
> conditions are not met, the node should not advertise the ELC capability
> in a first place.
>

There are two things here - (a) the actual load balancing capability
of a node (b) the capability to advertise the ELC/ERLD. Usually
capability and the advertisement of the capability go together. In
this case we want to be explicit that the absence of ERLD-MSD
indicates just (b) and not (a).

You do use the word "only", so may its all fine! I will leave it to
you/shepherd.

> >
> >     *  MUST be entropy label capable and, as a consequence, MUST apply
> >        the data-plane procedures defined in [RFC6790].
> >
> >     *  MUST be able to read an ELI/EL, which is located within its ERLD
> >        value.
> >
> >     *  MUST take into account an EL within the first ERLD labels in its
> >        load-balancing function.
> >
> >     Thus, I am not sure about this sentence. Maybe you mean to say that the
> >     absence only indicates that the ERLD-MSD value of the node is unknown (and
> >     it might still be capable of handling ELI/EL)?
> >
> > (4) Section 4
> >
> >      What would be the behavior if an OSPF router receives a ERLD of the node
> >      but no ELC set for the corresponding prefix? That would be an error as per
> >      RFC 8662, we should specify how one handles it within OSPF. If it is to
> >      just ignore the ERLD, we should explicitly say that.
>
> the behavior is specified in the RFC 8662.  OSPF is just a messenger,
> not the consumer of this information.
>

Is there some text in RFC 8662 the clarify what one does on the
receiving side? I found only the sending conditions in section 4. How
does a receiving node behaves when he receives conflicting
information, which one does he trust (no ELC present or ERLD=10). We
could have interop issues here if you leave it open.

Thanks!
Dhruv

PS. Since the comments are the same for the IS-IS I-D, no need duplicate them.