Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
As for other reviewers, many of my comments duplicate those for the OSPF document; I expect that the analogous responses apply and am fine if they only appear for one document's review. Here, the question I have about normative language applies to the text in Section 3: When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. The scenario in question is analogous to the OSPF cross-area case: is the router propagating the prefix between ISIS levels required to implement this document; is preservation of the flag value a new requirement from this document vs. a preexisting property; and is this document trying to make normative requirements of devices that don't implement this document? Likewise, the ASBR case for cross-protocol redistribution seems to rather inherently require understanding the semantics of the flags being translated.
Section 1 Should we add a sentence at the end of the last paragraph about how "this document defines a mechanism to signal the ERLD using IS-IS"? In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be side note(?): I don't know that SR-MPLS is so popular so as to be privileged as the only example given for LSP usage. If we instead talked about using IGPs to signal labels, this selection would seem less surprising to me. Section 3 unless all of its interfaces are capable of processing ELs. If a router supports ELs on all of its interfaces, it SHOULD set the ELC for every local host prefix it advertises in IS-IS. Do we want to say anything about (not) advertising the ELC for other prefixes? Section 4 I agree with Roman's comment about code 2 vs TBD2. ERLD in the range between 0 to 255. The scope of the advertisement depends on the application. If a router has multiple interfaces with Just to check: w.r.t. "scope", both this document and the OSPF one only define usage of this MSD type at the scope of a single node, right? (I don't see a particular reason to preclude using it at a different scope.) Section 6 - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV registry has been assigned to the ELC Flag. IANA is asked to Is there an "IS-IS" in the name of this registry? Section 7 Should we say anything about considerations for redistributing ELC/ERLD information at the ASBR with respect to exposing "internal information" to external parties? This document specifies the ability to advertise additional node capabilities using IS-IS and BGP-LS. As such, the security considerations as described in [RFC7981], [RFC7752], [RFC7794], [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and RFC 8662's security considerations have a pretty hard dependency on RFC 6790's security considerations; it might be worth mentioning 6790 directly in this list as well. [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this document. Could we also have a brief note that the normal IS-IS authentication mechanisms serve to protect the ELC/ERLD information? Incorrectly setting the E flag during origination, propagation or redistribution may lead to black-holing of the traffic on the egress node. This is what happens when the E flag should not be set but is erroneously set. Should we also say what happens if we should set the E flag but erroneously clear it (e.g., that poor or no load-balancing may occur)? Section 8 I do see the note in the shepherd writeup about the sixth author (thank you!); if we're already breaking through the 5-author limit, did we consider making those who "should be considered as co-authors" listed as co-authors? Section 10.1 Should we reference RFC 7981 from Section 4 as well? Right now we seem to only use it for the security considerations, which is not necessarily enough to qualify it as a normative reference.
Two editorial nits: ** Section 3. Editorial. s/ When a router propagates a prefix between ISIS levels ([RFC5302],/When a router propagates a prefix between ISIS levels [RFC5302],/ ** Section 4. Figure 2. The text says that “A MSD-Type Code 2 has been assigned by IANA”, but Figure 2 says “MSD-Type=TBD2”.
[[ nits ]] [ section 1 ] * "(e.g., SR-MPLS [...]," appears to lack a closing parenthesis.
What Barry said. Also, I presume your AD has approved going over the usual limit of five authors.
I had the weirdest sense of deja vu when reviewing this document -- enough that I went back to see if it had been on a previous telechat -- and then realized that it was the IS-IS version of draft-ietf-ospf-mpls-elc :-)
Just a few editorial nits: — 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 — originator. Similarly in a multi-domain network, the identity of the Nit: “Similarly” needs a comma after it. When a router propagates a prefix between ISIS levels ([RFC5302], it Nit: remove the open parenthesis. an Autonomous System Boundary Router (ASBR) is outside of the scope Nit: the abbreviation “ASBR” is not used elsewhere in the document, so there’s no reason to include it. — Section 4 — A new MSD-type [RFC8491], called ERLD-MSD is defined to advertise the Nit: 8491 capitalizes the “T” in “MSD-Type”. Nit: there needs to be a comma after “ERLD-MSD”.
Thank you for the work put into this document. The document is easy to read. Like other ADs, I wonder why the IS-IS and OSPF are separate documents. Please find below one NIT. I hope that this helps to improve the document, Regards, -éric == NIT == -- section 4 -- The "one" is ambiguous in "the router MUST advertise the smallest one." even if we can guess that it is not "interface" ;-)
Hi, Same comment as for equivalent OSPF draft. 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