[Lsr] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Julien Meuric <julien.meuric@orange.com> Mon, 10 September 2018 15:28 UTC

Return-Path: <julien.meuric@orange.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 3519F130F04; Mon, 10 Sep 2018 08:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jGKnnF7B_uAx; Mon, 10 Sep 2018 08:28:38 -0700 (PDT)
Received: from l-mail-ext.rd.orange.com (l-mail-ext.rd.orange.com []) by ietfa.amsl.com (Postfix) with ESMTP id 89324130EE8; Mon, 10 Sep 2018 08:28:38 -0700 (PDT)
Received: from l-mail-ext.rd.orange.com (localhost []) by localhost (Postfix) with SMTP id A7FBF521CD2; Mon, 10 Sep 2018 17:28:16 +0200 (CEST)
Received: from l-mail-int.rd.francetelecom.fr (l-mail-int.rd.francetelecom.fr []) by l-mail-ext.rd.orange.com (Postfix) with ESMTP id 9D091521CD1; Mon, 10 Sep 2018 17:28:16 +0200 (CEST)
Received: from l-mail-int.rd.francetelecom.fr (localhost.localdomain []) by localhost (Postfix) with SMTP id C64DF520F9C; Mon, 10 Sep 2018 17:28:21 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (ftrdch01.rd.francetelecom.fr []) by l-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id BCEA2520F93; Mon, 10 Sep 2018 17:28:21 +0200 (CEST)
Received: from [] ( by FTRDCH01.rd.francetelecom.fr ( with Microsoft SMTP Server id 14.3.408.0; Mon, 10 Sep 2018 17:28:21 +0200
From: Julien Meuric <julien.meuric@orange.com>
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: draft-ietf-isis-segment-routing-msd@ietf.org, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, lsr@ietf.org
Organization: Orange
Message-ID: <cb33dfed-f14a-e079-78a7-83659aac7ffb@orange.com>
Date: Mon, 10 Sep 2018 17:28:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/C0jZ5Lzk0ZY8bQMYhC5DViLUpUI>
Subject: [Lsr] RtgDir Review: draft-ietf-isis-segment-routing-msd-15
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 10 Sep 2018 15:28:51 -0000


I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-isis-segment-routing-msd-15
Reviewer: Julien Meuric (with some inputs from Bruno Decraene)
Review Date: 2018-09-07
IETF LC End Date: 2018-09-12
Intended Status: ST

I have some minor concerns about this document that I think should be
resolved before publication.

The document is well focused on a solution to a clearly scoped problem.
The defined encodings are simple and clear. All the same, there are a
few loose wordings, implicit assumptions or fuzzy zones which require
clarification before publication.

*Minor issues:*

- The abstract uses the acronym "SID", however:
    * It should be expanded at first use,
    * It should be defined, e.g. by adding a (normative) reference to
RFC 8402 (at least in the introduction),
    * The SR context is missing and should be explicitly mentioned
(adding a phrase such as "in a Segment Routing-enabled network" would be

   Path Computation Element Protocol (PCEP) SR extensions draft
   [I-D.ietf-pce-segment-routing] signals MSD in SR Path Computation
   Element (PCE) Capability TLV and METRIC Object.
   The Path Computation Element communication Protocol (PCEP) SR
   extension document [I-D.ietf-pce-segment-routing] defines how to
   signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and
   the METRIC object (per request).

- The introduction says that the solution to complement BGP-LS lies in
IS-IS (the OSPF draft claiming the counterpart on its side). This is a
bit rough, the sentence 2 paragraph below already does the necessary
scoping job: "This document defines an extension to <your favorite IGP
here>". I suggest to temper the early sentence by rephrasing the
beginning of page 3 into: "MSD capabilities should be advertised by
every router in the network involved in the IGP."

- The wording of the following sentence is not clear: "Note that in a
non-SR MPLS network, label depth is what is defined by the MSD
advertisements." Is it intended to say: "Note that MSD advertisements
are applicable beyond SR-enabled networks and may refer to label depth
in MPLS networks."?

- "SID" may deserve to join the terminology section.

- s/SIDs a node or a link on a node can support./SIDs supported by a
node or a link on a node./

- The same ASCII art is used for the 2 figures (sections 2 and 3). It
would be nice to specialize each one a little bit by explicitly adding
their respective codepoint in the type field (23 and 15).

- Section 3 says "any other value represents that of the link when used
as an outgoing link." Is it not excessive to be that prescriptive about
outgoing vs. incoming? E.g., if an implementation was to advertise ERLD
as a link MSD, that would rather refer to a capability of the
incominglink. This specification could be left to each MSD-Type definition.

- In section 4: s/the Link MSD MUST take preference/the Link MSD MUST
take precedence/

- In section 5, BMI-MSD is defined as "the total number of MPLS  labels
which can be imposed" (which is OK when the incoming packet is
unlabled). When the incoming packet is labeled (e.g. use of segment
routing binding SID), if the incoming label is to be "replaced" by N
outgoing labels, what processing model is assumed when advertising the MSD:
 * one swap and one imposition of N-1 labels?
 * one pop and one imposition of N labels?

- For the BMI-MSD use case, the draft seems to clearly target a value
attached to the outgoing link. However, this capability on a router is
highly hardware-dependent: some implementations may push a stack on the
egress linecard while some may perform it on the ingress linecard. The
I-D seems to make some implicit hardware assumption and the current link
MSD advertisement is not suited to describe these possible combinations
of hardware implementations. This needs to be addressed somehow.

- Section 7 says that "an MSD that is incorrect, may result in [...]
instantiation of a path that can't be supported". It would be more
accurate to mention "instantiation attempt", as a proper state control
mechanism is expected to deny unsupported instantiation (e.g. PCEP
errors for "invalid objects" include "Unsupported number of SR-ERO

- s/(IS-IS) Router to advertise/(IS-IS) router to advertise/
- s/link a given SR path/each node/link of a given SR path/
- s/path doesn't exceed/path does not exceed/
- s/and associated attributes and capabilities/as well as associated
attributes and capabilities/
- s/it is expected, that/it is expected that/
- s/an IANA managed registry/an IANA-managed registry/
- s/defined by this document/defined by this document:/
- s/path that can't be/path that cannot be/