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

From: <[email-masked]>
Date: Mon, 7 Nov 2016 10:12:15 +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:[email-masked]]  > 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, "[email-masked] on behalf of [email-masked]"
 > <[email-masked] on behalf of [email-masked]> 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:[email-masked]] On Behalf Of Hannes Gredler
 >      > Sent: Monday, October 24, 2016 11:07 AM
 >      > To: [email-masked]
 >      > 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
 >      > [email-masked]
 >      > 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
 >     [email-masked]
 >     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.

---

From: <[email-masked]>
Date: Mon, 7 Nov 2016 13:27:00 +0000

Hi Bruno

[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.
[SLI] It may be a swap and push in case the binding SID is bound to another SR-tunnel. In this case, the LSR  becomes an ingress node as well and the bound SR-TE tunnel starting at this LSR should take into account the MSD of this LSR.

> [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,
[SLI] I also agree that it should be crystal clear in the document as I know some vendors for which this statement is not true and then the limit of the number of labels to be pushed includes all labels (service, transport, entropy).
Moreover it would be interesting to know if there is a difference in the maximum number of label to be pushed for a push only operation, a swap then push, a pop then push, a pop then swap then push ... I think there could be a difference.

Brgds,

Stephane

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 07, 2016 11:12
To: Jeff Tantsura
Cc: [email-masked]; [email-masked]
Subject: [Isis-wg] draft-tantsura-isis-segment-routing-msd-02

Hi Jeff,

Thanks for the answers.

 > 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, "[email-masked] on behalf of [email-masked]"
 > 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:
 > 
 > [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,

e.g. suppose:

 > 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>  > 
 > 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.

 > [jeff] MSD is only meaningful at the ingress node, where the tunnel is instantiated and  > full SID/label stack is pushed

 > [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];
 > 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
 
 > 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.
 > [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.

-- Bruno

 > Especially since this line is below " The Type (1 byte)" where "1 byte" is the length or the  > "Type" field.
 > 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

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.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 Nov 2016 00:48:49 -0800

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, "[email-masked]" <[email-masked]> wrote:

    Hi Jeff,
    
    Thanks for the answers.

    
[jeff] Ok, will do
    
    e.g. suppose:

    

[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

[jeff] Ok, will do

    [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)  

    [Bruno] ok, thanks *2

    [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.

    -- Bruno

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 Nov 2016 01:06:10 -0800

Hi Stephane,

It could be really great if vendors could comment!
 
Cheers,
Jeff

On 11/7/16, 05:27, "[email-masked]" <[email-masked]> wrote:

    Hi Bruno

[jeff] you are exactly right, MSD is applicable to both, ingress as well as binding sid anchor nodes

[jeff] unless VPN labels are distributed centrally – those are imposed locally and are not included in the path computation, same goes for entropy, back to my previous coments to Bruno – vendors should provide guidelines, and if entropy and/or service labels have impact on number of SID’s used for a computed path, then perhaps they should be included 

    Moreover it would be interesting to know if there is a difference in the maximum number of label to be pushed for a push only operation, a swap then push, a pop then push, a pop then swap then push ... I think there could be a difference.
[jeff] I don’t think semantics of forwarding are of importance, the MSD value represents total numbers of SID’s a node is capable of imposing before a packets leaves the node, whether it is programmed as SWAP or PUSH or a combination thereof is irrelevant. Recirculation (at the price of decreased capacity) could be used to traverse pipeline more than once and push more labels, however, those are implementation semantics.

Hope this clarifies    
    
    Brgds,
    
    Stephane

    -----Original Message-----
    From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Monday, November 07, 2016 11:12
    To: Jeff Tantsura
    Cc: [email-masked]; [email-masked]
    Subject: [Isis-wg] draft-tantsura-isis-segment-routing-msd-02
    
    Hi Jeff,
    
    Thanks for the answers.

    
    
    e.g. suppose:

    

    

     
    [Bruno] ok, thanks *2

    
    
    -- Bruno

---

From: <[email-masked]>
Date: Tue, 15 Nov 2016 10:18:56 +0000

Topic#1  

[SLI2] I agree that PCE needs to know how much label it can propose in the "transport" MPLS stack, so we come back to the initial definition of MSD:
"The "Maximum SID Depth" (1  octet) field (MSD) specifies the maximum number of SIDs (MPLS label stack depth in context of this document) that a PCC is capable of imposing on a packet."
It does not tell that it is transport only...
Now each HW/SW combination has a specific limit in the number of labels it can push (whatever the label is a service, or ELI/EL, or FAT, or transport label). Let's call it HW_MSD.

Scenario 1) PCC does the job of substracting HW_MSD with a value X to obtain the MSD that will be available for the transport tunnel it will request to PCE. The issue I see here is that it will be highly depend of the PCC configuration and it may also vary depending on the services. Let's that I have on the PCC a PW service that uses FAT label and requires an SR-TE tunnel. It should decrease HW_MSD by 2 to obtain MSD.
Now if on the same PCC, I have a basic L3VPN service that requires a transport SR-TE tunnels from PCC, it should decrease HW_MSD by 1 to obtain MSD.
 Now if on the same PCC, I have a interAS option C VPN that uses entropy label that requires a transport SR-TE tunnels from PCC, it should decrease HW_MSD by 4 to obtain MSD.
So what will be the value advertised in the Node MSD ? A local configuration may align to the worst case value.

Scenario 2) PCC advertises HW_MSD as MSD value. It becomes the job of PCE to understand how to determine the real usable MSD while it does not have any information to do so. Only a local configuration of the decrement may help here.

In any case, it looks good to have a configuration knob for advertised MSD but this requires a strong knowledge from the SP/customer, and I not sure that every SP/customer has such experts while SR is usually designed for "simple" networks and deployment. 

Topic#2

 [SLI]   Moreover it would be interesting to know if there is a difference in the maximum number of label to be pushed for a push only operation, a swap then push, a pop then push, a pop then swap then push ... I think there could be a difference.

[SLI2] I'm not sure that this is irrelevant but I would like to hear from multiple vendors on this. It may be irrelevant for some implementations but not others. An HW may have some "timing" constraint leading to a limited number of operations to be done in the allocated time slot, so if you have already done a swap and/or a pop, this may reduce your capacity of push. Yes recirculation is a possibility for platforms that supports it. Again it's implementation dependant and as you mentioned, feedback from multiple vendors would help ! 

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2016 18:06
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]
Subject: Re: draft-tantsura-isis-segment-routing-msd-02

Hi Stephane,

 
Cheers,
Jeff

    Hi Bruno

Hope this clarifies    
    
    Brgds,
    
    Stephane

    -----Original Message-----
    From: Isis-wg [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Monday, November 07, 2016 11:12
    To: Jeff Tantsura
    Cc: [email-masked]; [email-masked]
    Subject: [Isis-wg] draft-tantsura-isis-segment-routing-msd-02
    
    Hi Jeff,
    
    Thanks for the answers.

    
    
    e.g. suppose:

    

    

     
    [Bruno] ok, thanks *2

    
    
    -- Bruno