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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
