Signaling Maximum SID Depth (MSD) Using IS-IS
draft-ietf-isis-segment-routing-msd-19

[Ballot comment]
Sorry for the re-send; I forgot to add the following paragraph:

I'm not sure I followed correctly some discussion around the rtgdir
review, specifically the meaning of the indicated MSD value for SR-enabled
vs. non-SR-enabled networks.  In particular, I still don't really understand
why it's okay to use the same codepoint (value 1 as assigned here) for
the max SID depth in SR-enabled networks and for the max label depth
in non-SR MPLS networks.  Why couldn't they just be separate MSD Type codepoints?

The shepherd writeup is silent about the WG's discussion of the IPR
disclosure (but the corresponding ospf draft says this sort of thing is
typical for LSR drafts).

Section 3

  The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
  223 to carry the MSD of the interface associated with the link.  MSD

Please add the appropriate qualifier (IS-IS?) before the list of TLV
numbers.

  MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
  represents lack of the ability to support SID stack of any depth; any
  other value represents that of the link.

It's unclear that there's a referent for "that of the link" to attach to.
That is, is it better to say "represents the maximum SID depth supported by
the link" (or similar)?

Section 6

As discussed in the secdir review, this section needs to include guidance
to the Experts to check that the meaning of the absence of an MSD type is
specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
attempts to place a similar requirement on future MSD types (but for OSPF
vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
appropriately general fashion so as to apply to all places where the
registered MSD value would be used.

Section 7

  Advertisement of the additional information defined in this document
  that is false, e.g., an MSD that is incorrect, may result in a path
  computation failing, having a service unavailable, or calculation of
  a path that cannot be supported by the head-end (the node performing
  the imposition).

In the analogous OSPF document we split out the case of a value that is too
small and a value that is too large, to describe the different
consequences.

I would also suggest rewording to something like "calculation by the
head-end of a path that cannot be supported" to avoid the mis-parsing
"(calculation of a path) (that cannot be supported by the head-end)".

[Ballot comment]
The shepherd writeup is silent about the WG's discussion of the IPR
disclosure (but the corresponding ospf draft says this sort of thing is
typical for LSR drafts).

Section 3

  The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
  223 to carry the MSD of the interface associated with the link.  MSD

Please add the appropriate qualifier (IS-IS?) before the list of TLV
numbers.

  MSD-Value is a number in the range of 0-255.  For all MSD-Types, 0
  represents lack of the ability to support SID stack of any depth; any
  other value represents that of the link.

It's unclear that there's a referent for "that of the link" to attach to.
That is, is it better to say "represents the maximum SID depth supported by
the link" (or similar)?

Section 6

As discussed in the secdir review, this section needs to include guidance
to the Experts to check that the meaning of the absence of an MSD type is
specified.  Given the text in draft-ietf-ospf-segment-routing-msd that
attempts to place a similar requirement on future MSD types (but for OSPF
vs. IS-IS usage thereof), hopefully this guidance can be phrased in an
appropriately general fashion so as to apply to all places where the
registered MSD value would be used.

Section 7

  Advertisement of the additional information defined in this document
  that is false, e.g., an MSD that is incorrect, may result in a path
  computation failing, having a service unavailable, or calculation of
  a path that cannot be supported by the head-end (the node performing
  the imposition).

In the analogous OSPF document we split out the case of a value that is too
small and a value that is too large, to describe the different
consequences.

I would also suggest rewording to something like "calculation by the
head-end of a path that cannot be supported" to avoid the mis-parsing
"(calculation of a path) (that cannot be supported by the head-end)".

[Ballot comment]
Thank you for a well written, clear and easy to understand document.
Also thanks to Zitao Wang for the OpsDir review ( https://mailarchive.ietf.org/arch/msg/ops-dir/GT5r_8_OukxlqMb1NFdsbNysJIw )


While reviewing it I found some minor nits - these are not blocking comments, but please consider addressing them to make the document even better:

1: Section 1:
" Path Computation Element Protocol (PCEP) SR extensions"
I think this would read better as "The Path Computation ..." (Hey! I did say they were nits :-))

2: Section 2.  Node MSD Advertisement
"Type: 23 (allocated by IANA via the early assignment process)"
Comment:  Thank you for mentioning here that this is an early allocation - it makes it much easier on the reviewer than flipping to the back of the document to check, flipping forward, etc.!

3: Section 3.  Link MSD Advertisement
"MSD values may be learned via a hardware API or may be provisioned."
I don't quite get what a "hardware API" is -- perhaps "an API which talks directly to the hardware"? Or just drop API (or hardware)?

4: Section 6.  IANA Considerations
"Per TLV information where Link MSD sub-TLV can be part of:
  TLV  22 23 25 141 222 223
  ---  --------------------
yyyyyy
        Figure 5: TLVs where LINK MSD Sub-TLV can be present"

I understand what this is trying to say, but I don't think it does a very good job of doing so. Perhaps remove the figure and just say "The LINK MSD Sub-TLV can be in TLVs 22, 23, 25,141, 222 or 223" or similar....

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-isis-segment-routing-msd-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) registry on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The early assignment for Value 23:

Value Description Reference
----- --------------- -------------
23 Node MSD [draft-ietf-isis-segment-routing-msd]

will be made permanent and the reference changed to [ RFC-to-be ].

Second, in the Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) registry also on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The early assignment for value 15:

Value Description Reference
----- --------------- -------------
15 Link MSD [draft-ietf-isis-segment-routing-msd]

will be made permanent and the reference changed to [ RFC-to-be ].

Third, a new registry is to be created called the IGP MSD Types registry. The new registry will be located on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters/

The registration procedure is "Expert Review" as defined in [RFC8126]. Types are an unsigned 8 bit number with values from 0 to 255.

There are initial values in the new registry as follows:

Value Name Reference
----- --------------------- -------------
0 Reserved [ RFC-to-be ]
1 Base MPLS Imposition MSD [ RFC-to-be ]
2-250 Unassigned [ RFC-to-be ]
251-254 Experimental [ RFC-to-be ]
255 Reserved [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-isis-segment-routing-msd@ietf.org, chopps@chopps.org, aretana.ietf@gmail.com, Christian Hopps , lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Signaling MSD (Maximum SID Depth) using IS-IS) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Signaling MSD (Maximum SID Depth) using
IS-IS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a way for an Intermediate System to
  Intermediate System (IS-IS) Router to advertise multiple types of
  supported Maximum SID Depths (MSDs) at node and/or link granularity.
  Such advertisements allow entities (e.g., centralized controllers) to
  determine whether a particular SID stack can be supported in a given
  network.  This document only defines one type of MSD maximum label
  imposition, but defines an encoding that can support other MSD types.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3037/
  https://datatracker.ietf.org/ipr/3255/

=== AD Review of draft-ietf-isis-segment-routing-msd-13 ===
(https://mailarchive.ietf.org/arch/msg/lsr/FJEl9YBq9a19CsF7dXyEijQbojI)

Dear authors:

I just finished reading this document.  I have several comments and concerns that I included inline below.

One item that I want to highlight here is the lack of specific procedures defined to handle the cases of multiple advertisements (in both §2 and §3).  Please take a look at my specific comments below -- in short, a clear specification is required for proper interoperability.  I will wait for (at least) this item to be addressed before starting the IETF LC.

Thanks!

Alvaro.



[The line numbers came from the idnits output.]

...
76 1.  Introduction
...
95  links in the network MSD is relevant, MSD capabilites should be
96  advertised by every IS-IS router in the network.

[nit] s/capabilites/capabilities

...
109  or SIDs associated with another dataplane e.g., IPv6.  Although MSD
110  advertisements are associated with Segment Routing, the
111  advertisements MAY be present even if Segment Routing itself is not
112  enabled.

[minor] Given that you're using Normative language...  It would be nice if you expanded on the use of the MSD in a non-SR network.  Something simple such as "a SID and a label are the same thing" would be enough.

114 1.1.  Conventions used in this document

116 1.1.1.  Terminology

[minor] Except for BMI/MSD, the other terms are not definitions, just expansions.  Some of the abbreviations are already included in the RFC Editor Abbreviations List [1].  In general, it would be better to just expand on first use (BGP-LS, for example, is used *before* this section) than to have this section with expansions.

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

...
147 2.  Node MSD Advertisement
...
156          0                  1
157          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

159        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
160        |    Type      |  Length      |
161        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
162        |  MSD-Type    | MSD Value    |
163        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
164        //    ...................    //
165        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
166        |  MSD-Type    | MSD Value    |
167        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

169                        Figure 1: Node MSD Sub-TLV

171  Type: 23 (allocated by IANA via the early assignment process)

173  Length: variable (minimum of 2, multiple of 2 octets) and represents
174  the total length of value field.

[nit] ...in octets (?).

176  Value: field consists of one or more pairs of a 1 octet MSD-Type and
177  1 octet MSD-Value.

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

[nit] The figure says "MSD Value", but the text talks about "MSD-Value".

...
191  If there exist multiple Node MSD advertisements for the same MSD-Type
192  originated by the same router, the procedures defined in [RFC7981]
193  apply.

[major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a node MSD sub-TLV), or both?

[major] The only relevant text I can find in rfc7981 is this:

  Where a receiving system has two copies of an IS-IS Router CAPABILITY
  TLV from the same system that have conflicting information for a
  given sub-TLV, the procedure used to choose which copy shall be used
  is undefined.

I then don't know how to handle the multiple advertisements.  Please point me in the right direction.

195 3.  Link MSD Advertisement

197  The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
198  223 to carry the MSD of the interface associated with the link.  MSD
199  values may be learned via a hardware API or may be provisioned.

[nit] A reference to the appropriate RFCs would be nice.

201        0                  1
202        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

204        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
205        |    Type      |  Length      |
206        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
207        |  MSD-Type    | MSD Value    |
208        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
209        //    ...................    //
210        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
211        |  MSD-Type    | MSD Value    |
212        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

214                        Figure 2: Link MSD Sub-TLV

216  Type: 15 (allocated by IANA via the early assignment process)

218  Length: variable (minimum of 2, multiple of 2 octets) and represents
219  the total length of value field.

[nit] ...in octets (?).

221  Value: consists of one or more pairs of a 1 octet MSD-Type and 1
222  octet Value.

[nit] There is no "Value" field illustrated above.  You might want to reword a little.

[nit] The figure says "MSD Value", but the text talks about "Value".

...
235  If multiple Link MSD advertisements for the same MSD Type and the
236  same link are received, the procedure used to select which copy is
237  used is undefined.

[major] Does this text refer to multiple link MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a link MSD sub-TLV), or both?

[major] Without a procedure "it is unlikely that multiple implementations of the specification would interoperate" [2].

[2] https://www.ietf.org/blog/discuss-criteria-iesg-review/


239 4.  Using Node and Link MSD Advertisements

[major] After reading this section, I still don't know how do use the advertisements.  What should a receiver do with the values?  Maybe the use is constrained to a controller...maybe the exact operation is our of the scope of this document.  Either way, please say something.

241  When Link MSD is present for a given MSD type, the value of the Link
242  MSD MUST take preference over the Node MSD.  When a Link MSD type is
243  not signalled but the Node MSD type is, then the Node MSD type value
244  MUST be considered as the MSD value for that link.

[nit] s/signalled/signaled

...
258 5.  Base MPLS Imposition MSD

260  Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
261  labels a node is capable of imposing, including all
262  service/transport/special labels.

264  Absence of BMI-MSD advertisements indicates solely that the
265  advertising node does not support advertisement of this capability.

[major] The MSD Types are applicable for both nodes and links, right?  The description above only talks about nodes -- what about links?

267 6.  IANA Considerations

269  This document requests IANA to allocate a sub-TLV type for the new
270  sub TLV proposed in Section 2 of this document from IS-IS Router
271  Capability TLV Registry as defined by [RFC7981].

[minor] The registry is called "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)". [3]

[3] https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242

...
303  This document requests creation of an IANA managed registry under a
304  new category of "Interior Gateway Protocol (IGP) Parameters" IANA
305  registries to identify MSD types as proposed in Section 2 and
306  Section 3.  The registration procedure is "Expert Review" as defined
307  in [RFC8126].  Suggested registry name is "IGP MSD Types".  Types are
308  an unsigned 8 bit number.  The following values are defined by this
309  document

[nit] s/under a new category/under the category

[major] This creation of the registry needs to include the "required documentation and review criteria, giving clear guidance to the designated expert" -- please see §4.5 in rfc8126.

311      Value    Name                            Reference
312      -----    ---------------------            -------------
313      0        Reserved                        This document

[major] 0 is not Reserved, but has a specific meaning (from §2 and §3).

314      1        Base MPLS Imposition MSD        This document
315      2-250    Unassigned                      This document
316      251-254  Experimental                    This document
317      255      Reserved                        This document

319                  Figure 6: MSD Types Codepoints Registry

321 7.  Security Considerations

323  Security considerations as specified by [RFC7981] are applicable to
324  this document.

326  Advertisement of the additional information defined in this document
327  that is false, e.g., an MSD that is incorrect, may result in a path
328  computation failing, having a service unavailable, or instantiation
329  of a path that can't be supported by the head-end (the node
330  performing the imposition).

[major] rfc7981 says that "specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information".  I think that the paragraph above applies also to modification.  What about disclosure?

...
364 10.2.  Informative References

[major] rfc8126 should be Normative.

...
390  [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
391              Writing an IANA Considerations Section in RFCs", BCP 26,
392              RFC 8126, DOI 10.17487/RFC8126, June 2017,
393              .

    (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
        Standard, Informational, Experimental, or Historic)? Why is this the
        proper type of RFC? Is this type of RFC indicated in the title page
        header?

A Standards Track RFC is being requested and is indicated in the
title page header.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

    Technical Summary:

This document describes IS-IS protocol extensions to disseminate Segment Routing
Maximum Segment Depth (MSD) information. The initial and only MSD type specified
is "Label Imposition MSD", i.e., the maximum number of labels that can be
imposed for a link or router (minimum of all links). An analogous OSPF document
exists as well.

    Working Group Summary:

Good consensus, and no controversy.

    Document Quality:

This document has been a WG document for over a year (and has existed for
over 2 yars) and has been regularly revised and well reviewed.

    Personnel:

Shepherd: Christian Hopps
AD: Alvaro Retana

    (3) Briefly describe the review of this document that was performed by the
        Document Shepherd. If this version of the document is not ready for
        publication, please explain why the document is being forwarded to the
        IESG.

I have personally reviewed this document, and provided comments that led to the
final revision which is being submitted to the IESG.

    (4) Does the document Shepherd have any concerns about the depth or breadth
        of the reviews that have been performed?

No.

    (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that took
        place.

No.

    (6) Describe any specific concerns or issues that the Document Shepherd has
        with this document that the Responsible Area Director and/or the IESG
        should be aware of? For example, perhaps he or she is uncomfortable with
        certain parts of the document, or has concerns whether there really is a
        need for it. In any event, if the WG has discussed those issues and has
        indicated that it still wishes to advance the document, detail those
        concerns here.

None.

    (7) Has each author confirmed that any and all appropriate IPR disclosures
        required for full conformance with the provisions of BCP 78 and BCP 79
        have already been filed. If not, explain why?

Yes.

    (8) Has an IPR disclosure been filed that references this document? If so,
        summarize any WG discussion and conclusion regarding the IPR
        disclosures.

Yes, https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd

    (9) How solid is the WG consensus behind this document? Does it represent
        the strong concurrence of a few individuals, with others being silent,
        or does the WG as a whole understand and agree with it?

Strong consensus from vendors and operators.

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this document.
        (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

No Nits.

    (12) Describe how the document meets any required formal review criteria,
        such as the MIB Doctor, media type, and URI type reviews.

N/A

    (13) Have all references within this document been identified as either
        normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

No.

    (15) Are there downward normative references references (see RFC 3967)? If
        so, list these downward references to support the Area Director in the
        Last Call procedure.

No.

    (16) Will publication of this document change the status of any existing
        RFCs? Are those RFCs listed on the title page header, listed in the
        abstract, and discussed in the introduction? If the RFCs are not listed
        in the Abstract and Introduction, explain why, and point to the part of
        the document where the relationship of this document to the other RFCs
        is discussed. If this information is not in the document, explain why
        the WG considers it unnecessary.

No.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all protocol extensions that the document makes
        are associated with the appropriate reservations in IANA registries.
        Confirm that any referenced IANA registries have been clearly
        identified. Confirm that newly created IANA registries include a
        detailed specification of the initial contents for the registry, that
        allocations procedures for future registrations are defined, and a
        reasonable name for the new registry has been suggested (see RFC 5226).

Reviewed, also as expert review for earlier code-point allocation. New registry is OK.

    (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

An IGP agnostic registry "MSD types" with Expert Review is being created with an
initial single entry along with some reserved values. Any of the standard IS-IS
experts would be good choices as experts here (Les (also doc author), myself
(co-chair), Hannes), but also another OSPF focused expert my be useful
e.g., Acee or Peter Psenak?

    (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

N/A