[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [161.106.5.9]) 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 [127.0.0.1]) 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 [10.193.21.125]) 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 [127.0.0.1]) 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 [10.194.32.11]) by l-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id BCEA2520F93; Mon, 10 Sep 2018 17:28:21 +0200 (CEST)
Received: from [10.193.71.36] (10.193.71.36) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) 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
Hello, 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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 *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:" 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 enough). - OLD 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. NEW 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 subobjects"). *Nits:* - 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/ --- Regards, Julien
- [Lsr] RtgDir Review: draft-ietf-isis-segment-rout… Julien Meuric
- Re: [Lsr] RtgDir Review: draft-ietf-isis-segment-… Les Ginsberg (ginsberg)
- Re: [Lsr] RtgDir Review: draft-ietf-isis-segment-… Julien Meuric
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Jeff Tantsura
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Julien Meuric
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Alvaro Retana
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Alvaro Retana
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Julien Meuric
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Julien Meuric
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Jeff Tantsura
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Acee Lindem (acee)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Acee Lindem (acee)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Les Ginsberg (ginsberg)
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… bruno.decraene
- Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isi… Julien Meuric