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

[Peter Psenak <[e-mail]>]

Hi Dhruv,

please see inline:

On 06/05/2020 17:40, Dhruv Dhody wrote:
> 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.

yes, the absence of ERLD-MSD advertisements only indicates that a node 
does not support advertisement of (b).

It can not be interpreted that (b) is not supported.  Old nodes that do 
not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.

The "only" is there to express the above.

> 
>>>
>>>      *  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.

well, if the node does not support ELC, then ERLD value is irrelevant. 
It's like having a speed limit for a road with no entry.

But that is something that does not belong to protocol drafts.

thanks,
Peter


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