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