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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 15 August 2018 20:53 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 77133130E11; Wed, 15 Aug 2018 13:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TeabcE8toAX3; Wed, 15 Aug 2018 13:53:28 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57B5130E09; Wed, 15 Aug 2018 13:53:27 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id n21-v6so4305549oig.3; Wed, 15 Aug 2018 13:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=yPCicRAeViYA6Oa4V14XSZED7XDD9AjbWYQsdJwGe2Q=; b=mrcKUFHLZI8PAl46eaF9b7mYKs7IHFrbZbQp+hi3njwRQY35195HVofAiqzipV4KAu w7hIa/jOskQ+WdAhP2EhBMVWyseuN5Z9/gRxuOT5X0NpYQTdAEEAqpc4DArSIW6NheII zvkgGzDLCmLLzD7YHwhRcSsopzB5uGudJixtB3y4tY4OSzQhzxgcbps9xmFkWNtFQqe8 dEXXChS67SRv8n0BugN8GOMwiQZ32QkqanXJi3/isiOkHVl3AQ73OdUy/Y/LGsAiZcZu aqco2EeTPptghemycbUNxS9x36BYX1Sjm/2bXA2CfmtkNRTBZzDpcC5JjbYMJ7EBLhDC wuqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=yPCicRAeViYA6Oa4V14XSZED7XDD9AjbWYQsdJwGe2Q=; b=KWWz7N/U8JRs6DfzSHxgOQaLEk+UJCrfh0LB24Gnpvgd/ABOTvZJxfyYXUDMSUIjux pFJqAztjyd9yS5T6K/JIjoqK0T8l6RSUwxlxGCIaAexjDpCxzZnrc+9s28cIdCXf+B69 JLkt06RdORa0HSZfC3zHB1BqGWEev3wmpbD15sbjevDbVWQuL6FfRTShQW98AIEppxgu jxBsauRt0wAHk2iMaWnV8nfZCwWzSY2D1NQhccmjq6rEAbUG0kleTkBJHLC48qWaH65H xjfLEXZGGc48WMY4L1dhHnjKb2QnYoZN/Fjb18lsUSBWeIc2oy0kTEhGov3O9Ld+PDep 9Efg==
X-Gm-Message-State: AOUpUlFW1EuA6JRtxUW4LN+Zua92cA9IEd1nXKk+2vwvRpeNx6PWbUtA 9XHEBCU2hhblj3dmGhyXecA2vGwXYptxSbod6CKV1Q==
X-Google-Smtp-Source: AA+uWPwOQVE4bTxc09xkh95hSus2qRm83JK+U6I0vt/O3uDI+wJkVcutFQqZ9bv365TiYT07B4yZZzCXL32dVU71BOY=
X-Received: by 2002:aca:5004:: with SMTP id e4-v6mr30545613oib.111.1534366406760; Wed, 15 Aug 2018 13:53:26 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Aug 2018 16:53:26 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 15 Aug 2018 16:53:26 -0400
Message-ID: <CAMMESsxptarNYpLnNHA3mB+QBzb=RV0si1NNScPZdNJw4UyLog@mail.gmail.com>
To: draft-ietf-isis-segment-routing-msd@ietf.org
Cc: lsr-chairs@ietf.org, lsr@ietf.org, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="000000000000a15d5c05737f8412"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/FJEl9YBq9a19CsF7dXyEijQbojI>
Subject: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Aug 2018 20:53:32 -0000

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.



[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


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