[Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

[Alvaro Retana <[e-mail]>]

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              <https://www.rfc-editor.org/info/rfc8126>.