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

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....

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)".