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

[Jeff Tantsura <[e-mail]>]

I’m almost ready with OSPF,  let’s take it from there

 

Cheers,

Jeff

 

From: "Les Ginsberg (ginsberg)" <[e-mail]>
Date: Wednesday, August 15, 2018 at 15:51
To: Alvaro Retana <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Christian Hopps <[e-mail]>
Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13
Resent-From: <[e-mail]>
Resent-To: Jeff Tantsura <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Wed, 15 Aug 2018 15:51:43 -0700 (PDT)

 

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

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

 

 

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

 

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