Note: This ballot was opened for revision 13 and is now closed.
I wasn't clear on where the thread ended up from the Gen-ART review, but I'm nevertheless suggesting some text below to resolve the main sticking point. OLD If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF. NEW If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF. The absence of these advertisements implies that advertisement of the ELC is not supported. Not sure if that matches the intent though.
Thank you for educating me, and addressing the minor residual remains of my discuss point that were left after that, as well as my comments.
[[ nits ]] [ section 1 ] * "(e.g., SR-MPLS" is missing a closing parenthesis [ section 3 ] * "...unless all of its interfaces...":" do management interfaces, or other interfaces over which no forwarding is taking place, count in this definition of "all"? If not, does this text need to be tightened or is this just one of those things all implementers will naturally figure out? (I'm actually betting this is just something readers will intuit.)
As with the IS-IS document, I assume the presence of six authors, above our usual limit of five, was approved by your AD. I agree with Barry's point that this document and the IS-IS document could easily have been combined. Even some of the syntactical things he corrected are present in both documents. When would you ever not do what the two SHOULDs in Section 3 say?
Nit: “ When an OSPF Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of the OSPF or from some other protocol, it SHOULD preserve the ELC signaling for the prefix.“ S/the /OSPF/OSPF/. S/for the prefix/for the prefix (if it exists)/ — some protocols will not have / carry the ELC. Apologies if I missed it, but I didn’t see discussion on *exporting* ELC into other protocols...
— Section 1 — In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be Nit: you need a closing parenthesis instead of the second comma. This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in [RFC8662] may be used by ingress LSRs to Nit: this needs a comma after the citation. — Section 3 — When an OSPF Area Border Router (ABR) distributes information between Nit: the abbreviation “ABR” is not used elsewhere in the document, so there’s no reason to include it. — Section 3.1 — Prefix TLV includes a one octet Flags field. Nit: hyphenate “one-octet” as a compound modifier. — Section 4 — The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc]. Just checking: is the IS-IS draft the right reference here in this OSPF document? There does seem to be so much common text between that document and this one that I really don’t understand why these (the IS-IS and OSPF signaling) were not put into one document, and this reference really drives that home.
Thank you for the work put into this document. The document is easy to read. Please find below one non-blocking COMMENTs and two NITs. I hope that this helps to improve the document, Regards, -éric == COMMENT == For my own curiosity, is there a possibility that a router receives conflicting node capability via OSPFv2 and OSPFv3 (assuming that both are running over the same network and using the same router-ID over OSPFv2 and OSPFv3) ? == NITS == -- section 4 -- The "one" is ambiguous in "the router MUST advertise the smallest one." even if we can guess that it is not "interface" ;-) -- Sections 3 & 4 -- Is there a meaningful difference between the "advertizing" of section 3 and the "signaling" of section 4?
Hi, This is a straight forward document, thanks. Is there any associated YANG module required to manage this protocol enhancement? If so, is that already being worked or, or planned work for the WG? Regards, Rob