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

Jeff Tantsura <jefftant.ietf@gmail.com> Tue, 15 November 2016 08:48 UTC

Return-Path: <jefftant.ietf@gmail.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 CF9AB129A5D for <isis-wg@ietfa.amsl.com>; Tue, 15 Nov 2016 00:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-TKrDrinxpM for <isis-wg@ietfa.amsl.com>; Tue, 15 Nov 2016 00:48:26 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 47B1A129A52 for <isis-wg@ietf.org>; Tue, 15 Nov 2016 00:48:26 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id p66so64524827pga.2 for <isis-wg@ietf.org>; Tue, 15 Nov 2016 00:48:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=K03CzHpE7Od7byuPu93DuyD60iyDoHGYaggVU9Bdv+8=; b=fusutGjXI2Nc8r1xKXgw+TrmcsmcIqJZ4bAJYC81aHtIioNYQFOyRYdVP5cHPFvb1u FkkW+9m203Gbo10obIj2XxLnp1Ycqcw6GIF2lH1k3QOIjzsjSpsfF7VAvWDAj0Lme2KW u/ZCi+bFtwb2pS2h+YCcoroP8gUu5WuSJkJY56A9gdjzsa0R5FLWRc+OV8VVrHMxz8jL E+z67WB6nUxfYzt8FgivQVZit8RuKgPq/wtVQcpOh/VuMWQMC1zBW4CC6UkTj9oer4iL Szd/2k6GhWIEwiMClZF9A+XOmxWq1ouWQrLyzJKn6/N8KU8AIjqIzqYL2A6AfxqoWKcr J7ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=K03CzHpE7Od7byuPu93DuyD60iyDoHGYaggVU9Bdv+8=; b=JexEKqfaYObRi8EJQ9UMEWjjAm2Vxu/ShMv9uYpKVAwHxts/JK3rSNbFKsXPGbOxkr r2XijyD/1CuCby6peVFxpukKDIQQIAuFYxz3kCoNBeDgO2sAAzmZgoAZdbeZKxQ1AEWh GtTlorPnXqVtQOQyQUkUazZ/+p/48OQLe/RZE2Sif1zzQu8HCerZmMJs17ej13yU8gKK qZN8DgUjIvqfR22rqyEONymfbJqi9qB6f/Cns5xhYBWPDqMJ7vLks+NlEktFaP6OWyaK 0WoMl19TXX6dD0Di43ypDh2MP4K+cX4WlSugBoL9CoyvOoCKdy/vmRL78tTobo4FNtRz osCg==
X-Gm-Message-State: ABUngvf0O2ogMZZQvrxuSONfMQuaXhBLxzFwPm1WPrWPR4otdfDu4b4DdE6wyC6gws1y5Q==
X-Received: by 10.99.7.210 with SMTP id 201mr75501134pgh.51.1479199705372; Tue, 15 Nov 2016 00:48:25 -0800 (PST)
Received: from [31.133.129.79] ([2001:67c:370:128:38c8:2ed1:53ab:4213]) by smtp.gmail.com with ESMTPSA id cm6sm21584369pad.3.2016.11.15.00.48.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 00:48:24 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Tue, 15 Nov 2016 00:48:49 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: <bruno.decraene@orange.com>
Message-ID: <178A3CA7-BDCA-4218-A1E1-ED9BC4D7BDDD@gmail.com>
Thread-Topic: draft-tantsura-isis-segment-routing-msd-02
References: <16761_1478513536_58205380_16761_458_1_53C29892C857584299CBF5D05346208A1EC6CC6C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <16761_1478513536_58205380_16761_458_1_53C29892C857584299CBF5D05346208A1EC6CC6C@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/0kBvs0_guX9E9hL4XQcZUkPTX90>
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: Re: [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: Tue, 15 Nov 2016 08:48:29 -0000

Hi Bruno,

Thanks for your comments!

The main idea is to make PCE/controller aware of the limitations of a node/links on a node and make sure the end result of the computation (MSD stack) does not exceed that of supported by a node. It is not trying to differentiate between different actions ie PUSH vs SWAP or any combination of those.

Whether the SID’s in the stack are used for forwarding only or have some other semantics (service chaining as an example) as long as ingress node//binding sid anchor node has to push whole stack limitations would apply.
I’d also envision that a PCE, in absence of an ingress node capable of pushing whole stack could instantiate a number of segmented tunnels instead 


Please see inline [jeff]


Cheers,
Jeff
 

On 11/7/16, 02:12, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

    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.
[jeff] Ok, will do
    
    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. 

[jeff] The use of the MSD is as follows - when total SID stack is computed, either locally or remotely, number of SID’s in the stack must not exceed that of MSD, the semantics of SID’s in the stack are irrelevant, the MSD value is to be used as a constrain when the stack is computed, EL/ELI pair(s) should be excluded, as these are not part of CSPF/PCE computation and are imposed locally
   
 > 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)
[jeff] Ok, will do
    
     > 
     >     - 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.
[jeff] yes, you are correct, binding sid anchor node, expanding the stack is a subject to the same limitations set, I wouldn’t necessarily describe the action taken as SWAP (1:1), it is more expansion (1:N)  
    
     
     >     - 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.
[jeff]Ok, will do, to reemphasize – MSD is meant only for ingress/binding sid anchor node, not transport neither receiver nodes.
    
    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.