Hi Peter, Dhruv,
On 5/6/20, 12:00 PM, "Peter Psenak" <ppsenak@xxxxxxxxx> wrote:
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.
As document shepherd, I think this aligns with other OSPF functional capabilities.
Thanks,
Acee
>
>>>
>>> * 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.
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
