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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Alvaro –

A very thorough review – thanx.

Jeff has the pen – but I think he is on holiday at the moment – so there may be a short delay as regards a new version.
I will confine myself to comments on the non-editorial issues.
Inline.

From: Alvaro Retana <[e-mail]>
Sent: Wednesday, August 15, 2018 1:53 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; Christian Hopps <[e-mail]>
Subject: AD Review of draft-ietf-isis-segment-routing-msd-13

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?

[Les:] It really doesn’t matter. If you have two advertisements for the same MSD type from the same source then the procedures defined in RFC 7981 apply. It does not matter whether you find the advertisements in the same sub-TLV, in the same Router Capabilities TLV but different sub-TLVs, or in different Router Capabilities TLVs(sic).



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

[Les:] Your searching skills are excellent. ☺
RFC 7981 declined to define procedures for reasons which are explained in the three paragraphs prior to the one you have quoted.
If you have a problem with that please raise it in the context of RFC 7981 – not in the context of this draft.

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.

[Les:] You are asking for an RFC reference for each of the mentioned TLV types (22, 23,…)???
Given that information is readily available here:  https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml why should we clutter a draft with duplicate info??


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?

[Les:] As with node MSD, it does not matter. What matters is that you have duplicate advertisements for the same link and MSD type.
Ohhh…and these advertisements are not in Router Capability TLV. ☺


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

[Les:] The issue is not interoperability but that you do not know which one is correct. So no matter which one you choose you might use a value that is either not supported by the advertising node or limits label imposition unnecessarily.
I really don’t think there is an interoperability issue here.


[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?

[Les:] This section is not specific to link advertisements or node advertisements. It is talking about what it means when there is no applicable advertisement of BMI-MSD.
What is an applicable advertisement? That is explained in Section 4.
For a given link I either have an advertisement for that link or I have a node advertisement. If I have neither, I have no information and so you can infer that the node “declined to state”.

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.

[Les:] Guidance for Designated Experts – at least for IS-IS codepoints – has been defined in RFC 7170. Would it be sufficient to refer to that document and state that it applies in this case as well??
(I sure hope so. ☺ )

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

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

[Les:] I am confused by your comment.
What is being reserved is the value “0” as an MSD-Type (See Figures 1 and 2) – not 0 as an MSD-Value.
Please help me to understand what text in the draft is in conflict??

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?

[Les:]I think the same issues apply to disclosure. How about if we added:

“The presence of this information also may inform an attacker of how to induce any of the aforementioned conditions.”

???

   Les


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