Re: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07

<bruno.decraene@orange.com> Wed, 20 December 2017 20:09 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96663127342; Wed, 20 Dec 2017 12:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 P_9n93o2qQ_h; Wed, 20 Dec 2017 12:09:35 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC291275FD; Wed, 20 Dec 2017 12:09:34 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 540C61C0DE1; Wed, 20 Dec 2017 21:09:33 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 34106C0085; Wed, 20 Dec 2017 21:09:33 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 21:09:32 +0100
From: <bruno.decraene@orange.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>
CC: "isis-ads@ietf.org" <isis-ads@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
Thread-Index: AQHTecn/m/Qe8GDQj02zNRn5qeKUkKNMod2g
Date: Wed, 20 Dec 2017 20:09:32 +0000
Message-ID: <10239_1513800573_5A3AC37D_10239_227_1_53C29892C857584299CBF5D05346208A47927F48@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <87ind1pzn8.fsf@chopps.org> <30285_1513764651_5A3A372B_30285_488_1_53C29892C857584299CBF5D05346208A47926D1B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <F0CE8AA5-188F-45C7-BE45-6212A0DC1EAA@gmail.com>
In-Reply-To: <F0CE8AA5-188F-45C7-BE45-6212A0DC1EAA@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ms6OdNKrJOW3stspEZPJ6ePRNM4>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 20:09:38 -0000

Hi Jeff,

Thanks for the quick answers.
Looks good to me (pending the updated draft)
Please see inline [Bruno]

 > From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
> 
 > Hi Bruno,
 > 
 > Many thanks for your valuable comments and see in line
 > 
 > Cheers,
 > Jeff
 > 
 > -----Original Message-----
 > From: <bruno.decraene@orange.com>
 > Date: Wednesday, December 20, 2017 at 02:10
 > To: "draft-ietf-isis-segment-routing-msd@ietf.org" <draft-ietf-isis-segment-routing-msd@ietf.org>
 > Cc: "isis-ads@ietf.org" <isis-ads@ietf.org>rg>, "isis-wg@ietf.org" <isis-wg@ietf.org>rg>, Christian
 > Hopps <chopps@chopps.org>
 > Subject: RE: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
 > Resent-From: <alias-bounces@ietf.org>
 > Resent-To: <jefftant.ietf@gmail.com>om>, <uma.chunduri@huawei.com>om>, <aldrin.ietf@gmail.com>om>,
 > <ginsberg@cisco.com>
 > Resent-Date: Wed, 20 Dec 2017 02:10:57 -0800 (PST)
 > 
 >     Hi authors,
 > 
 >     Please find below WGLC comments on this document.
 > 
 >     Major:
 >     -----
 >     "the provisioned MSD
 >        of the router originating the Router Capability TLV.  Node MSD is the
 >        lowest MSD supported by the node of any interface and can be
 >        provisioned in IS-IS instance."
 > 
 >     I don't see the MSD as a provisioned value, but as a hardware capability. (Note that as a
 > network operator, I'd be happy to be able to provision this capability without changing the
 > hardware/software, but that has not been my experience so far.)
 >     Let's not put the burden on the network operator to configure this, while the node should know
 > the value better. (as a priori, in the absence this extension, the node would report an error if
 > instructed to push more labels than it is capable of). Especially for WAN routers, when Line Card
 > may be changed (e.g. upgraded), so this would requires the network operator to keep track of all
 > Line card change and update the MSD capability accordingly.(in which case, it may be just
 > simpler to configure it directly on the controler, rather than requiring IS-IS, OSPF, BGP-LS
 > protocol extensions, plus new features on all (involded) nodes)
 > 
 > [jeff] In ideal situation, the MSD capabilities should come from the HW SDK, while in a vertically
 > integrated device, it might be vendor provisioned, however in a disaggregated case (HW and SW
 > are from different vendors), ability to query HW for its MSD capabilities becomes crucial.
 > I have brought this point and discussed with BCM, Barefoot and few other HW vendors:
 > everyone agreed that would be a useful functionality, and would require quite simple API to add.
 > Now it is up to their customers to demand an implementation, CP is standardized here, and, as
 > usual, HW vendors have preference for a formal specification, that is stable.
 > For the time being, while there are no implementations we need to provide means to configure
 > the value
 > Please also note, MSD configuration is covered by SR YANG model, in case the MSD value is
 > communicated from HW(ro), it would go into operational data store

[Bruno] Thanks for the clarification.
Regarding hardware API, I think we agree that for integrated equipment the control plane should know the MSD from day one. And for de-aggregated equipment, this is the medium term goal.
All I'm asking is not to write in stone (RFC) that configuration is the (only) way to get the MSD value. I think it should come from the hardware as default behavior, and could be overridden by configuration. So already the MSD part of the SR Yang module is excellent, thanks.

 > 
 >     -----
 >     "the provisioned MSD of the interface associated with the link."
 > 
 >     Please explicit whether the controller/reader need to use the MSD of the incoming link or of
 > the outgoing link.
 >     If you believe this may be hardware dependent, this need to be signaled.
 > 
 > [jeff] always from outgoing link prospective, so the internals (ingress/egress/spitted MSD
 > imposition) of a device are not of importance

[Bruno] Excellent. Could this be specified in the draft?
 > 
 >     ==============
 >     Minor:
 >     "MSD of type 1 (IANA Registry), called Base MSD, is used to signal the total number of SIDs a
 > node is capable of imposing,"
 >     I think that this is limited to MPLS-SID. It would be good to state this somewhere. e.g.
 > :s/SIDs/MPLS SIDs
 > [jeff] No, it doesn’t have to, IPv6 data plane could be covered as well, however topic for future
 > and would be done thru a separate draft.


[Bruno] A priori the SRv6 MSD would be advertised in a different MSD type (e.g. type 2), while the MSD type 1 is specifically for MPLS-SR, no?

 >     ----
 >     "MSD: Maximum SID Depth"
 >     IMHO, I'm not a big fan of the term "depth".
 >     I find that it can be mislead with RLD (Readable Label Depth Capability). I don't feel that
 > pushing N SID requires looking/going deep into the packet. Looking at the surface of the
 > incoming label looks enough.
 >     Obviously, the comment is late.
 > [jeff] Let’s agree to disagree on this one, the draft explicitly mentions RLD and spells out the
 > difference.
 
[Bruno] sure, no problem. I understand that this is a bit late to change the name. But possibly someone could have come up with the same MSD acronym, with a different word for D.

> 
 >     Related comment: I don't find the definition to be explicit enough. e.g. You now need to define
 > what "SID depth" is or provide or reference.
 > [jeff] Point taken, will include in the terminology section – would definition such as “ SID depth is
 > a number of SID’s a node or a link on a node is capable of imposing” work? Any text you would
 > like to propose?

[Bruno] looks good. Thanks.

 >     -----
 >     1.1.1.  Terminology
 > 
 >     Given that the term are very very briefly explained, may be adding a reference to the RFC
 > defining/explaining them.
 >     ---
 >     "In order, for BGP-LS to signal MSD for
 >        the all nodes and links in the network MSD is relevant, MSD
 >        capabilites SHOULD be distributed to every IS-IS router in the
 >        network."
 > 
 >     I don't think that the "SHOULD" is related to interoperability. Hence a "should" is probably
 > enough.
 > [jeff] agreed, will change
 
[Bruno] ok, thanks.

 
 >     -----
 >        "Value field consists of a 1 octet sub-type (IANA Registry) and 1 octet value."
 > 
 >     I don't see the value (sic) to hard code the legnth of the "sub-value":
 >     - this restrict the use of future MSD Sub-type Codepoints
 >     - if we hard code it, there is no use of the "length" field. (and "Length is variable " becomes not
 > true)
 >     -----
 >            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >            |    Type       |   Length      |      Sub-Type and Value       |
 >            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > 
 >     "Value field consists of a 1 octet sub-type (IANA Registry) and 1
 >        octet value."
 > 
 >     Text and figure do not match: the value field is either 'Sub-Type and value" as per the text, or
 > just "value without the Sub-type" as per the figure.
 > 
 > [jeff]point taken, will update

[Bruno] ok, thanks.

 > 
 >     *2 (link and node MSD)
 >     ---
 >     § MSD Advertisement
 > 
 >     "   Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
 >        of the router originating the corresponding TLV's 22, 23, 141, 222,
 >        and 223.  Link MSD is a number in the range of 0-254. 0 represents
 >        lack of the ability to impose MSD stack of any depth; any other value
 >        represents that of the particular link MSD value."
 > 
 >     It's not clear whether the text related to the MSD value is specific to the Sub-type 1 or to the
 > whole Link MSD Advertisment. (i.e. would restrict the usage of future sub-Types). May be using
 > two sections would help: one defining the Link MSD, one defining Sub-type 1. In which case the
 > last paragraph of the introduction may be move to this new sub-type 1 section.
 > 
 > [jeff]point taken, will update

[Bruno] ok, thanks.
 
 >     *2 (link and node MSD)
 >     -----
 >     " Other Sub-types other than defined above are reserved for future extensions.  This sub-TLV
 > is optional."
 >     It's not clear whether you mean this sub-TLV 1, or any sub-TLV n, or the presence of a sub-
 > TLV.
 > 
 > [jeff]point taken, will update

[Bruno] ok, thanks.

 >     ----
 >     "the ability to impose MSD stack of any depth"
 >     Were are not imposing an "MSD stack", but SID stack. Actually the SR architecture tends to
 > use the term "list of segments" (or "ordered list of segments")
 > 
 > [jeff] agreed, will correct
 
[Bruno] ok, thanks.
 
 >     ----
 >     "   This document describes a mechanism to signal Segment Routing MSD
 >        supported at node and/or link granularity through IS-IS LSPs and does
 >        not introduce any new security issues."
 > 
 >     Improved fingerprinting capability would be one. Which may help target the right vulnerability
 > of the advertising router.
 > 
 > [jeff] I don’t see how exposing MSD would increase the risk, please elaborate

[Bruno] As of today, different vendors have different MSD. Hence, by reading the MSD value, an attacker can guess the vendor of each node. One vendor (hopefully) increase its MSD over time, it may also provide some info regarding the software version running on the node.
Note that this is not new and already expressed in https://tools.ietf.org/html/rfc7981#section-5 ... which BTW also spell out my comment: "Specifications based on this mechanism need to describe the security  considerations around the disclosure and modification of their information."

 >     ==============
 >     Nits:
 >     "supported by a node at node and/or link granularity"
 >     May be NEW: supported by a node or link
 > [jeff] declined, both could be signaled at the same time

[Bruno] sorry, I meant "supported by a node and/or link"
That's just a nits. I felt that the sentence could be simplified, especially the part 'by a node at node". But it's up to you.

 > 
 >     "In order, for BGP-LS to signal MSD for
 >        the all nodes and links in the network MSD is relevant, MSD
 >        capabilites SHOULD be distributed to every IS-IS router in the
 >        network."
 >     In my understandind:
 >     :s/the all nodes/all the nodes
 >     :s/distributed to every IS-IS router/advertised by every IS-IS router
 > 
 > [jeff] agreed, will correct

[Bruno] ok, thanks.

 >     ---
 > 
 >        "A new sub-TLV within the body of IS-IS Router Capability TLV
 >        [RFC7981], Node MSD sub-TLV is defined to carry the provisioned MSD
 >        of the router originating the Router Capability TLV. ""
 > 
 >     May be the following would be easier to read
 > 
 >        A new sub-TLV "Node MSD sub-TLV" is defined within the body of IS-IS Router Capability
 > TLV
 >        [RFC7981],  to carry the provisioned MSD
 >        of the router originating the Router Capability TLV.
 > 
 > [jeff] agreed will correct

[Bruno] ok, thanks.

 >     -----
 > 
 >        "Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
 >        of the router originating the corresponding TLV's 22, 23, 141, 222,
 >        and 223.  Link MSD is a number in the range of 0-254."
 > 
 >     Please use two paragraphs. One for "Sub-type" field, one for "MSD value" field.
 > 
 > [jeff] agreed will correct

[Bruno] ok, thanks.

 >     -----
 >     "0 represents lack of the ability to impose MSD stack of any depth "
 >     May be NEW: "0 represents lack of the ability to impose any SID"
 >     ----
 >     "Maximum MSD"
 >     NEW: MSD
 >     ("M" already stands for Maximum)
 >     Multiple times in the doc, with "Maximum" or "maximum"
 > [jeff] agreed will correct

[Bruno] ok, thanks.

 >     ----
 >     The document has 2 "Terminology" sections. You should probably merge them.
 > [jeff] agreed will correct

[Bruno] ok, thanks.

Thanks Jeff,

Cheers,
--Bruno
 > 
 >     Thanks
 >     Regards,
 >     --Bruno
 > 
 >      > -----Original Message-----
 >      > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Christian Hopps
 >      > Sent: Wednesday, December 20, 2017 9:33 AM
 >      > To: isis-wg@ietf.org
 >      > Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
 >      > Subject: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
 >      >
 >      >
 >      > The authors have asked for and we are starting a WG Last Call on
 >      >
 >      >  https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
 >      >
 >      > which will last an extended 4 weeks to allow for year-end PTO patterns.
 >      >
 >      > An IPR statement exists:
 >      >
 >      >   https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd
 >      >
 >      > Authors please reply to the list indicating whether you are aware of any
 >      > *new* IPR.
 >      >
 >      > Thanks,
 >      > Chris.
 >      >
 >      > _______________________________________________
 >      > Isis-wg mailing list
 >      > Isis-wg@ietf.org
 >      > https://www.ietf.org/mailman/listinfo/isis-wg
 > 
 > 
 > _____________________________________________________________________________
 > ____________________________________________
 > 
 >     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou
 > privilegiees et ne doivent donc
 >     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par
 > erreur, veuillez le signaler
 >     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
 > susceptibles d'alteration,
 >     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 > 
 >     This message and its attachments may contain confidential or privileged information that may
 > be protected by law;
 >     they should not be distributed, used or copied without authorisation.
 >     If you have received this email in error, please notify the sender and delete this message and
 > its attachments.
 >     As emails may be altered, Orange is not liable for messages that have been modified, changed
 > or falsified.
 >     Thank you.
 > 
 > 
 > 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.