Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF
draft-ietf-ospf-mpls-elc-15

Note: This ballot was opened for revision 13 and is now closed.

Alvaro Retana Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2020-05-20 for -13)
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.

Roman Danyliw No Objection

Martin Duke No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-05-31 for -14)
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.

Erik Kline No Objection

Comment (2020-05-16 for -13)
[[ 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.)

Murray Kucherawy No Objection

Comment (2020-05-05 for -13)
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?

Warren Kumari No Objection

Comment (2020-05-14 for -13)
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...

Barry Leiba No Objection

Comment (2020-05-05 for -13)
— 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.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-05-11 for -13)
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?

Magnus Westerlund No Objection

Robert Wilton No Objection

Comment (2020-05-19 for -13)
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