[Isis-wg] draft-tantsura-isis-segment-routing-msd-02

<bruno.decraene@orange.com> Mon, 07 November 2016 10:12 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 D65CB1295D7 for <isis-wg@ietfa.amsl.com>; Mon, 7 Nov 2016 02:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.116
X-Spam-Level:
X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, 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 JZatZsIwNcWt for <isis-wg@ietfa.amsl.com>; Mon, 7 Nov 2016 02:12:18 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A691297DE for <isis-wg@ietf.org>; Mon, 7 Nov 2016 02:12:18 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 830A6C0311; Mon, 7 Nov 2016 11:12:16 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 556061A007E; Mon, 7 Nov 2016 11:12:16 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Mon, 7 Nov 2016 11:12:16 +0100
From: bruno.decraene@orange.com
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Thread-Topic: draft-tantsura-isis-segment-routing-msd-02
Thread-Index: AdI430XpX+q4MNmnRKyWEW5Et+CF6Q==
Date: Mon, 07 Nov 2016 10:12:15 +0000
Message-ID: <16761_1478513536_58205380_16761_458_1_53C29892C857584299CBF5D05346208A1EC6CC6C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
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/mos80DqmfXnNNU8rHgVkUL0DURE>
Cc: "draft-tantsura-isis-segment-routing-msd@tools.ietf.org" <draft-tantsura-isis-segment-routing-msd@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: [Isis-wg] draft-tantsura-isis-segment-routing-msd-02
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 07 Nov 2016 10:12:21 -0000

Hi Jeff,

Thanks for the answers.
Please see inline [Bruno]

[Changing the topic of the thread, as we are discussing the draft, not the WG adoption]

> From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]  > Sent: Friday, November 04, 2016 7:26 PM
> 
 > Hi Bruno,
 > 
 > Thanks for your valuable comments!
 > 
 > In general – today no silicon vendor provides an API to query and have MSD set
 > automatically, for the time being it will have to be set manually, there are also technics to
 > increase MSD by packet recirculation or ingress/egress split (used by some vendors). All of
 > above would requre a vendor to clearly communiate the values to be configured.
 > Please also note that IANA considerations will be extended for the link MSD to include
 > *all* the link TLVs (22, 23, 141, 222, 223) (thanks Hannes for pointing out!)
 > 
 > Please let me know whether you are happy with the aswers provided
 > 
 > Please see inline
 > 
 > Thanks,
 > Jeff
 > 
 > 
 > On 11/2/16, 08:36, "isis-wg-bounces@ietf.org on behalf of bruno.decraene@orange.com"
 > <isis-wg-bounces@ietf.org on behalf of bruno.decraene@orange.com> wrote:
 > 
 >     Hi all,
 > 
 >     I have read and support.
 >     "MSD" is a useful info to be advertised. While I would a priori assume that it's mainly
 > useful for the PCE (hence defined in draft-ietf-pce-segment-routing) I can understand that
 > one want to also have it advertised in the IGP.
 > [jeff] you are correct – the main use case is to notify Path Computation entity of this
 > particular capability of a node/link on a node so that the path computed would be in line
 > and doesn’t violate what is supported by the node.  In case of different types of NPU’s on
 > a single device, different line cards would have different capabilities, by including those in
 > the computation PCE would be able to compute a path that alternatively would potentially
 > have exited out of a wrong link
 > 
 > Please find some below some comments:
 > 
 >     - I'd like the draft to expand and specify the interaction with the entropy labels.
 >     e.g. is msd the maximum number of label that can be pushed, i.e. including entropy
 > labels?
 >     Currently draft talks about SID; IMO entropy labels are not SIDs; should we understand
 > that the node is capable of pushing MSID + 2 (EL) labels?
 > 
 > [jeff] to my experience (I have built SR on 3 different NPU’s, 1 of them merchant), the
 > number of SIDs (labels with MPLS encap) is always communicated as the number of
 > labels used in data plane and exclude entropy labels,

[Bruno] Could this be clarified in the document? Indeed, we need both the sender of the MSD and the reader to agree on the meaning.

e.g. suppose:
- a NPU can push a total of 5 labels
- the SP use MPLS for MPLS VPN hence needs 1 label for the service
- the SP wants to use entropy label hence needs 2 labels for EL

As a result, for SR tunnel purpose, which is my understanding of the purpose of this document, only 2 labels / SIDs are available.

Question: what should be the advertised MSD?
- 5: total number of labels
- 4: total number of labels usable for the "transport/LSP part"
- 2: total number of labels/SID usable for the routing/steering part of the LSP

I think this needs to be crystal clear in the document. 

> please also note - draft-ietf-mpls-
 > spring-entropy-label states – “multiple <ELI, EL> pairs MAY be inserted in the label stack
 > as long as the tunnel's label below which they are inserted are advertised with entropy
 > label capability enabled”, in other words there could be more than 1 pair of <ELI,EL>
 > 
 >     - To a lesser extent, it would be good to clarify the interaction with service labels.
 >     e.g. if the SID list/SR tunnel is (also) to be used by VPN traffic, who need to account for
 > this additional label? (the sender or the receiver of the MSD?)
 > [jeff] service should only be considered if it is instantiated as a part of path computed by a
 > Path Computation entity, ie service chaining, where a SID could be used as s
 > service/context identifier, if it is a service overlaid of top of a SR tunnel, it is out of scoop.

[Bruno] ok, this needs to be clarified (cf above)

 > 
 >     - I assume that the MSD is "incoming protocol independent" i.e. applies to any type of
 > incoming/received packets: IPv4, IPv6, MPLS (i.e. the "SWAP" operation counts as a PUSH)
 >     Please clarify in the doc.
 > [jeff] MSD is only meaningful at the ingress node, where the tunnel is instantiated and
 > full SID/label stack is pushed
 
[Bruno] well, a priori MSD could be applicable for binding SIDs, where a (incoming) label is assigned to the tunnel and hence a SWAP is performed.
It would be good that the document clarify whether MSD is also application to this case.

 
 >     - MSD 0
 >     I note that in the PCE draft, the MSD value 0 means "no default limitation" while in the
 > IGP draft it means " lack of the ability to push MSD of any depth".
 >     IOW, their meaning is opposite.
 >     While this is technically possible, this seems counter intuitive and open
 > misunderstandings, at least for human beings.
 >     Could the authors of both draft work to harmonize this?
 > [jeff] already done, in draft-ietf-pce-segment-routing-08, we have introduced L-flag, when
 > set - indicates that PCC does not impose any limit on MSD.
 > An MSD value MUST be non-zero otherwise the receiver of the SR-PCE-CAPABILITY TLV
 > MUST assume that the sender is not capable of imposing a MSD of any depth and hence
 > is not SR-TE capable.
 > 
 > [jeff]We have also clarified the case where MSD could be learnt thru PCEP and other
 > source of information:
 > Note that the MSD value exchanged via SR-PCE-CAPABILITY TLV indicates the SID/label
 > imposition limit for the PCC node.  However,
 > if a PCE learns MSD value of a PCC node via different means, e.g routing protocols, as
 > specified in: [I-D.tantsura-isis-segment-routing-msd];
 > [I-D.tantsura-ospf-segment-routing-msd]; [I-D.tantsura-idr-bgp-ls-segment-routing-msd],
 > then it ignores the
 > MSD value in the SR-PCE-CAPABILITY TLV.  Furthermore, whenever a PCE learns MSD for a
 > link via different means, it MUST use that value for
 > that link regardless of the MSD value exchanged via SR-PCE-CAPABILITY TLV.
 
[Bruno] ok, thanks *2
 
 >     - "Node MSD is the lowest MSD supported by the node"
 >     Open question: an alternative would be to advertise the lowest MSD supported by the
 > IS-IS enabled interfaces of this node. As possibly, customer/peer facing interfaces could
 > be of a different hardware type, possibly not supporting MPLS at all.
 >     Alternative 2: :s/ IS-IS enabled interfaces/ MPLS enabled interfaces
 >     Alternative 3: :s/ IS-IS enabled interfaces/ Segment Routing enabled interfaces
 > [jeff] The MSD value is always in relation to either:  the interface SR tunnel exits over if
 > link MSD is used or the lowest MSD supported by every possible exit interface on a node.
 > If you feel more clarity is needed, I’d be happy to change
 
[Bruno] ok. For link, I feel that the document could be cleared on whether the MSD advertise the value for the ingress/incoming link (where the packet is received) or the egress/outgoing link (where the packet is sent). The optimal choice could be different depending on hardware/software choice, put the meaning needs to be clear for the receiver.

Thanks again for the engaging the discussion and the clarifications.

-- Bruno


 
 >     - Nits: " Length is 1 bytes"
 >     Do you mean the length of the "length field" or the length of the value/MSD field?
 > Especially since this line is below " The Type (1 byte)" where "1 byte" is the length or the
 > "Type" field.
 > [jeff] I’ll include the drawing in the next version, it is the length of the "length field
 >     "Node MSD is a number in the range of 0-254" is "254" a typo or do you have a plan for
 > 255 to have a special meaning (and if so, please specify)
 > [jeff] In the beginning we indeed had, later dropped for sake of simplicity
 > 
 >     Thanks,
 >     Regards,
 >     -- Bruno
 >      > -----Original Message-----
 >      > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler
 >      > Sent: Monday, October 24, 2016 11:07 AM
 >      > To: isis-wg@ietf.org
 >      > Cc: Christian Hopps
 >      > Subject: [Isis-wg] WG adoption for draft-tantsura-isis-segment-routing-msd
 >      >
 >      > WG,
 >      >
 >      > the authors of draft-tantsura-isis-segment-routing-msd have requested
 >      > adoption as a WG item.
 >      >
 >      > https://datatracker.ietf.org/doc/draft-tantsura-isis-segment-routing-msd/
 >      >
 >      > opinions/comments appreciated.
 >      >
 >      > thanks,
 >      >
 >      > /hannes & 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.
 > 
 >     _______________________________________________
 >     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.