Skip to main content

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

Yes

(Alvaro Retana)

No Objection

Roman Danyliw
(Deborah Brungard)
(Magnus Westerlund)
(Martin Duke)
(Martin Vigoureux)

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

Erik Kline
No Objection
Comment (2020-05-16 for -13) Sent
[[ 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) Sent
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?
Roman Danyliw
No Objection
Warren Kumari
No Objection
Comment (2020-05-14 for -13) Sent
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...
Éric Vyncke
No Objection
Comment (2020-05-11 for -13) Sent
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?
Alvaro Retana Former IESG member
Yes
Yes (for -13) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2020-05-20 for -13) Sent
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.
Barry Leiba Former IESG member
No Objection
No Objection (2020-05-05 for -13) Sent
— 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.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-05-31 for -14) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-05-19 for -13) Sent
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