[Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.