Subject: Re: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Jan 2016 19:59:05 +0000

Hi all,

I have read the Segment Routing Problem Statement and Requirements draft and I have a couple of comments  on it.

Editorial:

The Abstract states that "Multicast use-cases and requirements are out of scope of this document", but this (or equivalent) statement does not appear anywhere in the body of the document. IMHO and FWIW this contradicts the last para in Section 4.3 of RFC 7322 that states that "the RFC should be self-contained as if there were no Abstract".

Technical:

The draft requires, in Section 2, that "The SPRING architecture SHOULD leverage the existing MPLS dataplane without any modification...".

In addition, in Section 3.3 it requires that "The SPRING architecture SHOULD allow incremental and selective deployment without any requirement of flag day or massive upgrade of all network elements"  .

My reading (FWIW) of these two requirements is that SPRING with MPLS dataplane should work on existing MPLS forwarding HW.

If this understanding is correct, it is in potential conflict with another requirement formulated in the Section1 of the draft: "The SPRING architecture SHOULD allow optimal virtualization: put policy state in the packet header and not in the intermediate nodes along the path".

This conflict stems from the following (admittedly, naïve) observation:

1.       The policy state representing the desired source route must be pushed in its entirety onto the packet by the source (here source is interpreted in the same way as in the draft itself) and must be parsed by all the transit nodes.

2.       The amount of the policy state grows (linearly?) as the number of elements in the source route selected by the packet. In particular, the policy representing a strict route could be potentially quite large.

3.       In the nodes that use hardware-based forwarding, the size of the policy state that can be pushed and parsed with the expected throughput is inherently limited. These limits differ for different implementations but they usually cannot be exceeded without replacing the forwarding hardware.

4.       Passing "offending" packets for software handling could result in dramatic decrease of throughput. S

In the case of the MPLS dataplane, the policy state is expressed as the MPLS label stack where each segment is represented by a label stack entry. AFAIK, existing (and probably future) forwarding HW that supports MPLS is inherently limited (the limits differ for different implementations) both regarding the number of labels that could be pushed on the packet, and regarding the total depth of the label stack that it can parse.

Note: The limit on the number of labels that can be pushed on a packet by forwarding HW is obvious. The limit on  that can be parsed becomes essential in the scenarios when ECMP is used, because:

*                    As per RFC 7325, Section 2.4.5.1., "The most entropy is generally found in the label stack entries near the bottom of the label stack (innermost label, closest to S=1 bit)"

*                    As per Section 2.4.5.2 of the same RFC, "Inspecting the IP payload provides the most entropy in provider networks.  The practice of looking past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs".

*                    Both these methods (hashing the label stack and hashing IP header) obviously require parsing the entire label stack.

The limits of forwarding HW could be considered an implementation problem, were it not for the draft requiring (and I fully agree with validity of this requirement) that SPRING could be used on existing MPLS-capable HW.

>From my POV the document should at least explicitly acknowledge this conflict as part of the SPRING problem statement. Preferably it should also include some guidelines for its resolution:

*                    One possibility that comes to mind could be a requirement to provide the information about hardware-specific limitations to traffic-engineering entities in order to avoid computation of paths that do not meet HW-imposed constraints.

*                    Another possibility is to clearly indicate that loose route options are preferable for using with SPRING. To the best of my understanding this could be translated into a requirement for a new type of constrained path computation algorithms that yield loose (rather than strict) routes

Of course there may be other (and, possibly, better) ways to resolve this conflict. But, from my POV, if it is not acknowledged explicitly, its resolution becomes much more problematic.

Hopefully, these LC comments would be useful.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of The IESG
Sent: Tuesday, December 15, 2015 8:11 PM
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document:

- 'SPRING Problem Statement and Requirements'

  <draft-ietf-spring-problem-statement-06.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked]<mailto:[email-masked]> mailing lists by 2016-01-05. Exceptionally, comments may be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   The ability for a node to specify a forwarding path, other than the

   normal shortest path, that a particular packet will traverse,

   benefits a number of network functions.  Source-based routing

   mechanisms have previously been specified for network protocols, but

   have not seen widespread adoption.  In this context, the term

   'source' means 'the point at which the explicit route is imposed' and

   therefore it is not limited to the originator of the packet (i.e.:

   the node imposing the explicit route may be the ingress node of an

   operator's network).

   This document outlines various use cases, with their requirements,

   that need to be taken into account by the Source Packet Routing in

   Networking (SPRING) architecture for unicast traffic.  Multicast use-

   cases and requirements are out of scope of this document.

The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/

IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________

spring mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/spring

---

From: Martin Horneffer <[email-masked]>
Date: Wed, 6 Jan 2016 16:20:58 +0100

Hello everyone,

concerning the first comment: I don't think that a document needs to 
explicitly specify all out-of-scope topics in order to be 
self-contained. So not exactly a contradiction, just maybe confusing.

Concerning the second comment: This is just another example of the 
frequent misunderstanding, that typical use cases for segment routing 
would required a lot of explicit path information.

There's more than enough analyses that show that in typical carrier 
topologies traffic engineering with segment routing can achieve almost 
everything with just adding one or maybe two segments (labels).
However those analyses are not neccessarily public, nor would I think an 
Internet Draft or RFC would be a good place for this kind of information.

Maybe we should add a section to draft-ietf-spring-segment-routing-mpls 
saying that the operators are responsible for understanding the 
capabilities of the hardware they use, and to consider those when 
setting up their specific traffic-engineering tricks.

Best regards, Martin

Am 05.01.16 um 20:59 schrieb Alexander Vainshtein:
>
> Hi all,
>
> I have read the Segment Routing Problem Statement and Requirements 
> draft and I have a couple of comments  on it.
>
> Editorial:
>
> The Abstract states that “/Multicast use-cases and requirements are 
> out of scope of this document/”, but this (or equivalent) statement 
> /does not appear anywhere in the body of the document/. IMHO and FWIW 
> this contradicts the last para in Section 4.3 of RFC 7322 that states 
> that “/the RFC should be self-contained as if there were no Abstract/”.
>
> Technical:
>
> The draft requires, in Section 2, that “The SPRING architecture SHOULD 
> leverage the existing MPLS dataplane/without any modification/...”.
>
> In addition, in Section 3.3 it requires that "/The SPRING architecture 
> SHOULD allow incremental and selective deployment without any 
> requirement of flag day or massive upgrade of all network elements/"  .
>
> My reading (FWIW) of these two requirements is that SPRING with MPLS 
> dataplane /should work on existing MPLS forwarding HW/.
>
> If this understanding is correct, it is in potential conflict with 
> another requirement formulated in the Section1 of the draft: "The 
> SPRING architecture SHOULD allow optimal virtualization: /put policy 
> state in the packet heade/r /and not in the intermediate nodes along 
> the path/".
>
> 1.The policy state representing the desired source route must be 
> pushed in its entirety onto the packet by the source (here source is 
> interpreted in the same way as in the draft itself) and must be parsed 
> by all the transit nodes.
>
> 2.The amount of the policy state /grows /(linearly?) /as the number of 
> elements in the source route/ selected by the packet. In particular, 
> the policy representing /a strict route/ could be potentially quite large.
>
> 3.In the nodes that use hardware-based forwarding, the size of the 
> policy state that can be pushed and parsed with the expected 
> throughput is /inherently/ /limited/. These limits differ for 
> different implementations but /they usually cannot be exceeded without 
> replacing the forwarding hardware/.
>
> 4.Passing “offending” packets for software handling could result in 
> dramatic decrease of throughput. S
>
> In the case of the MPLS dataplane, the policy state is expressed as 
> the MPLS label stack where each segment is represented by a label 
> stack entry. AFAIK, existing (and probably future) forwarding HW that 
> supports MPLS is inherently limited (the limits differ for different 
> implementations) both regarding the /number of labels that could be 
> pushed on the packet/, and regarding /the total depth of the label 
> stack that it can parse/.
>
> *Note*: The limit on the /number of labels that can be pushed on a 
> packet/ by forwarding HW is obvious. The limit on / that can be parsed 
> /becomes essential in the scenarios when ECMP is used, because:
>
> •As per RFC 7325, Section 2.4.5.1., “The most entropy is generally 
> found in the label stack entries /near the bottom of the label stack/ 
> (innermost label, closest to S=1 bit)”
>
> •As per Section 2.4.5.2 of the same RFC, “Inspecting the IP payload 
> provides the most entropy in provider networks.  The practice of 
> looking /past the bottom of stack label/ for an IP payload is well 
> accepted and documented in [RFC4928] and in other RFCs”.
>
> •Both these methods (hashing the label stack and hashing IP header) 
> obviously /require parsing the entire label stack/.
>
> The limits of forwarding HW could be considered an implementation 
> problem, /were it not for the draft requiring /(and I fully agree with 
> validity of this requirement) /that SPRING could be used on existing 
> MPLS-capable HW/.
>
> From my POV the document should at least explicitly acknowledge this 
> conflict /as part of the SPRING problem statement./ Preferably it 
> should also include some guidelines for its resolution:
>
> •One possibility that comes to mind could be a requirement to provide 
> the information about hardware-specific limitations to 
> traffic-engineering entities in order to avoid computation of paths 
> that do not meet HW-imposed constraints.
>
> •Another possibility is to clearly indicate that loose route options 
> are preferable for using with SPRING. To the best of my understanding 
> this could be translated into a requirement for a new type of 
> constrained path computation algorithms that yield loose (rather than 
> strict) routes
>
> Of course there may be other (and, possibly, better) ways to resolve 
> this conflict. But, from my POV, /if it is not acknowledged 
> explicitly, its resolution becomes much more problematic/.
>
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [spring] Last Call: 
> <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement 
> and Requirements) to Informational RFC
>
> The IESG has received a request from the Source Packet Routing in 
> Networking WG (spring) to consider the following document:
>
> The IESG plans to make a decision in the next few weeks, and solicits 
> final comments on this action. Please send substantive comments to the 
> [email-masked] <mailto:[email-masked]> mailing lists by 2016-01-05. 
> Exceptionally, comments may be sent to [email-masked] 
> <mailto:[email-masked]> instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 6 Jan 2016 16:59:13 +0000

Martin hi!
Lots of thanks for a prompt response.

Please see some comments inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Martin Horneffer [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 5:21 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

Hello everyone,

concerning the first comment: I don't think that a document needs to explicitly specify all out-of-scope topics in order to be self-contained. So not exactly a contradiction, just maybe confusing.
[[Sasha]] I fully agree that a document does not have to explicitly specify all out-of-scope issue. But IMHO  issues that are not mentioned in the document should not appear in the Abstract. It is up to you and your colleagues to decide whether you remove Multicast from the Abstract or add it to the document:).

Concerning the second comment: This is just another example of the frequent misunderstanding, that typical use cases for segment routing would required a lot of explicit path information.
[[Sasha]] The typical use cases may or may not require lots of explicit path information. But the draft explicitly mentions support of strict route option for Traffic Engineering (the first bullet in the long list of TE requirements in Section 3.3). And, to the best of my understanding, a strict route option  means that all the links (or at least all the nodes) on the path are specified in the right order. Do I miss something?

There's more than enough analyses that show that in typical carrier topologies traffic engineering with segment routing can achieve almost everything with just adding one or maybe two segments (labels).
[[Sasha]] I have seen several such analyses but they mainly deal with TI-FRR. I have not seen any that say that one or two added segments address the typical traffic engineering needs - and I am not sure we can define what exactly the typical traffic engineering needs are- e.g., can you claim that a typical strict TE route with not exceed 10 hops/segments?

However those analyses are not neccessarily public, nor would I think an Internet Draft or RFC would be a good place for this kind of information.
[[Sasha]] May I suggest that that you take a look at Section 9 "Operation in Real World Topologies" of RFC 7490<https://www.rfc-editor.org/rfc/rfc7490.txt>? From my POV this is a valid counterexample to your approach. However, I do not expect to see such analysis in the Problem Statement document. I am asking to acknowledge a problem first of all. Once this is done, you can explain (possibly in another document) how it can be addressed. And to make it absolutely clear: from my POV the very fact that somebody has taken care to perform the analyses to which you refer is an indication that the problem exists and that the operators are aware of its existence.

Maybe we should add a section to draft-ietf-spring-segment-routing-mpls saying that the operators are responsible for understanding the capabilities of the hardware they use, and to consider those when setting up their specific traffic-engineering tricks.
[[Sasha]] Of course the operators are responsible for understanding the capabilities of the HW they use. The really interesting question, from my POV, is, whether the TE entities (e.g., the CSPF algorithms that would be used in conjunction with Segment Routing) should be also aware of these capabilities (or, rather, limitations)? From my POV the answer is "Definitely yes" - I would rather not encounter the situation when the PCE sends to the requesting NE a TE path that meets the operator-specified constraints (e.g., avoid over-utilized links and try to use under-utilized ones) but  the network cannot implement "as given".

Best regards, Martin

Hi all,

Editorial:

Technical:

&#0;.                      As per RFC 7325, Section 2.4.5.1., "The most entropy is generally found in the label stack entries near the bottom of the label stack (innermost label, closest to S=1 bit)"

&#0;.                      As per Section 2.4.5.2 of the same RFC, "Inspecting the IP payload provides the most entropy in provider networks.  The practice of looking past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs".

&#0;.                      Both these methods (hashing the label stack and hashing IP header) obviously require parsing the entire label stack.

>From my POV the document should at least explicitly acknowledge this conflict as part of the SPRING problem statement. Preferably it should also include some guidelines for its resolution:

&#0;.                      One possibility that comes to mind could be a requirement to provide the information about hardware-specific limitations to traffic-engineering entities in order to avoid computation of paths that do not meet HW-imposed constraints.

&#0;.                      Another possibility is to clearly indicate that loose route options are preferable for using with SPRING. To the best of my understanding this could be translated into a requirement for a new type of constrained path computation algorithms that yield loose (rather than strict) routes

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of The IESG
Sent: Tuesday, December 15, 2015 8:11 PM
To: IETF-Announce
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

Abstract

   operator's network).

spring mailing list

spring mailing list

---

From: Rob Shakir <[email-masked]>
Date: Wed, 6 Jan 2016 10:08:44 -0700

Hi All,

On 6 January, 2016 at 8:21:22 AM, Martin Horneffer ([email-masked]) wrote:

Maybe we should add a section to draft-ietf-spring-segment-routing-mpls saying that the operators are responsible for understanding the capabilities of the hardware they use, and to consider those when setting up their specific traffic-engineering tricks.
I agree with Martin here, but I also don’t really agree that there is a new conflict that is being raised here.

1) SR must be realisable on existing iLER hardware where there may be limits in terms of the number of labels that can be pushed. SPRING does not mandate a requirement to be able to push an arbitrary number labels - like RSVP-TE does not mandate any particular head-end path computation requirements. If any change is to be made to this document it should be to highlight that there MAY be operational limitations w.r.t how complex the policy specified at the iLER can be (_or_ optimisations may be required to map one path onto another path - e.g., through binding a SID to a stack of labels on another device). I find this quite self-evident though.

I have analysed label stack depth in a number of networks - and discussed it with hardware implementors in that context, and not found this to be a significant operational concern. The problem of publishing any analysis in this area is it contains information relating to topology (which may be considered sensitive); and to the operator’s policy requirements.

2) SR must be realisable on existing LSR hardware where there may be limits in terms of the depth of label stack that can be examined. SPRING is generally always realisable by forwarding on the outermost label (be in Node-SID or Prefix-SID) - in some cases, there may be a need to pop that label and forward on the following one (e.g., an anycast segment or where there is an Adj-SID that terminates on the node) which is a capability of the existing MPLS forwarding plane. The case of entropy is generally something that is complex, and the work on EL means that there is a requirement for a device to be able to find the ELI+EL pair in the label stack - this isn’t something that SR introduces. So, we should note that _as with anything that increases the label stack depth_, then if we have that ELI+EL deeper than where a midpoint can read to, then we may lose entropy. But this is no different than any other hierarchical LSPs that we have today - so again, I’m not sure I find this a necessary note.

Essentially, what is being highlighted here is that certain MPLS forwarding planes may have optimised for a) limited push capabilities, or b) limited midpoint visibility into the label stack - these are optimisations that might have been acceptable in some deployments in the past, and may not be going forward. I would really want to consider whether there is anything that is not already noted in RFC 7325 that has been raised here.

I also disagree that this should be in the problem statement document — this document tries to describe the requirements and use-cases for the SPRING architecture. It seems to me that if we do address these concerns, then really the document that they should be addressed in is draft-ietf-spring-segment-routing-mpls - which specifically deals with the realisation of the SPRING architecture in the MPLS data-plane.

r.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 Jan 2016 12:42:04 +0000

Rob hi!

My understanding of the difference in our positions goes as following:

1.       We both agree that Segment Routing must be supported on existing MPLS-capable devices

2.       We both agree existing MPLS-capable devices are limited with regard to the number of labels that can be pushed on the packet

a.      I also claim that they are limited with regard to the total depths of the label stack that they can parse, but this is a less important issue

3.       We both agree that disregarding this limitation may result in TE entities computing paths that cannot be implemented “as computed”.

a.       I say that:

                                                               i.      This problem/conflict should be publicly acknowledged as part of the of the Segment Routing problem statement

                                                             ii.      It can be quite acute if the operator tries to implement strict routes using Segment Routing

                                                            iii.      It is not specific to the MPLS data plane

b.      You say that:

                                                               i.      The problem/conflict is not new (and I fully agree with that)

                                                             ii.      In most cases this problem/conflict be resolved by some trick (e.g., by replacing the originally computed strict TE path by another – loose? - one) and hence is not worth mentioning

                                                            iii.      Nevertheless it may be mentioned in the document defining Segment Routing with the MPLS data plane.

Do you think that this summary correctly represents our differences?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Rob Shakir [mailto:[email-masked]]
Sent: Wednesday, January 06, 2016 7:09 PM
To: Martin Horneffer; [email-masked]; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

Hi All,

On 6 January, 2016 at 8:21:22 AM, Martin Horneffer ([email-masked]<mailto:[email-masked]>) wrote:
There's more than enough analyses that show that in typical carrier topologies traffic engineering with segment routing can achieve almost everything with just adding one or maybe two segments (labels).
However those analyses are not neccessarily public, nor would I think an Internet Draft or RFC would be a good place for this kind of information.

r.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Jan 2016 22:56:31 +0800

Sasha and Rob,

Isn't also known that the Segment Routing increases the label stack,
and that is very much the root of this problem, so why not mention it
up front?

/Loa

On 2016-01-07 20:42, Alexander Vainshtein wrote:
> 1.We both agree that Segment Routing must be supported on existing
> MPLS-capable devices
>
> 2.We both agree existing MPLS-capable devices are limited with regard to
> the number of labels that can be pushed on the packet
>
> /a.//I also claim that they are limited with regard to the total depths
> of the label stack that they can parse, but this is a less important issue/
>
> 3.We both agree that disregarding this limitation may result in TE
> entities computing paths that cannot be implemented “as computed”.
>
> a.I say that:
>
> i.This problem/conflict should be /publicly acknowledged/ as part of the
> of the Segment Routing problem statement
>
> ii.It can be quite acute if the operator tries to implement strict
> routes using Segment Routing
>
> iii.It is not specific to the MPLS data plane
>
> b.You say that:
>
> i.The problem/conflict is not new (and I fully agree with that)
>
> ii./In most cases this problem/conflict be resolved by some trick/(e.g.,
> by replacing the originally computed strict TE path by another – loose?
> - one) /and hence is not worth mentioning/
>
> iii.Nevertheless it may be mentioned in the document defining Segment
> Routing with the MPLS data plane.
>
> *From:*Rob Shakir [mailto:[email-masked]]
> *Sent:* Wednesday, January 06, 2016 7:09 PM
> *To:* Martin Horneffer; [email-masked]; Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [spring] Last Call:
>     topologies traffic engineering with segment routing can achieve
>     almost everything with just adding one or maybe two segments (labels).
>     However those analyses are not neccessarily public, nor would I
>     think an Internet Draft or RFC would be a good place for this kind
>     of information.
>
>     Maybe we should add a section to
>     draft-ietf-spring-segment-routing-mpls saying that the operators are
>     responsible for understanding the capabilities of the hardware they
>     use, and to consider those when setting up their specific
>     traffic-engineering tricks.
>
> 1) SR must be realisable on existing iLER hardware where there may be
> limits in terms of the number of labels that can be pushed. SPRING does
> not mandate a requirement to be able to push an arbitrary number labels
> - like RSVP-TE does not mandate any particular head-end path computation
> requirements. If any change is to be made to this document it should be
> to highlight that there MAY be operational limitations w.r.t how complex
> the policy specified at the iLER can be (_or_ optimisations may be
> required to map one path onto another path - e.g., through binding a SID
> to a stack of labels on another device). I find this quite self-evident
> though.
>
> I have analysed label stack depth in a number of networks - and
> discussed it with hardware implementors in that context, and not found
> this to be a significant operational concern. The problem of publishing
> any analysis in this area is it contains information relating to
> topology (which may be considered sensitive); and to the operator’s
> policy requirements.
>
> 2) SR must be realisable on existing LSR hardware where there may be
> limits in terms of the depth of label stack that can be examined. SPRING
> is generally always realisable by forwarding on the outermost label (be
> in Node-SID or Prefix-SID) - in some cases, there may be a need to pop
> that label and forward on the following one (e.g., an anycast segment or
> where there is an Adj-SID that terminates on the node) which is a
> capability of the existing MPLS forwarding plane. The case of entropy is
> generally something that is complex, and the work on EL means that there
> is a requirement for a device to be able to find the ELI+EL pair in the
> label stack - this isn’t something that SR introduces. So, we should
> note that _as with anything that increases the label stack depth_, then
> if we have that ELI+EL deeper than where a midpoint can read to, then we
> may lose entropy. But this is no different than any other hierarchical
> LSPs that we have today - so again, I’m not sure I find this a necessary
> note.
>
> Essentially, what is being highlighted here is that certain MPLS
> forwarding planes may have optimised for a) limited push capabilities,
> or b) limited midpoint visibility into the label stack - these are
> optimisations that might have been acceptable in some deployments in the
> past, and may not be going forward. I would really want to consider
> whether there is anything that is not already noted in RFC 7325 that has
> been raised here.
>
> I also disagree that this should be in the problem statement document —
> this document tries to describe the requirements and use-cases for the
> SPRING architecture. It seems to me that if we do address these
> concerns, then really the document that they should be addressed in
> is draft-ietf-spring-segment-routing-mpls - which specifically deals
> with the realisation of the SPRING architecture in the MPLS data-plane.
>
> r.
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Jan 2016 16:11:42 +0100

Hi Loa,

> and that is very much the root of this problem, so why not mention it

​It depends on the application.

If one uses SR as a replacement for LDP signalling there is no increase of
the label stack at all. So such statement would not be correct.

If one needs some TE, service chaining or any other services from your
network then you impose in addition one or more ​labels or use v6 extension
header.

If you just want to compare MPLS-TE with SR then you need to consider all
elements involved especially the MPLS-TE control plane not just keep
focusing on the packet.

Cheers,
r.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 7 Jan 2016 15:41:21 +0000

>> entities computing paths that cannot be implemented “as computed”.

SB> There are of course some help a friend techniques whereby a more limited
SB> device requests that a more capable device pushes the larger stack 
for it.

>> - one) /and hence is not worth mentioning/
SB> I always feel that including an LSR component in a SSR stack to 
abbreviate
SB> the stack is a dangerous thing to so since the packet travels 
unconstrained
SB> and may end up somewhere it is not supposed to be.

SB> So it depends what the reason for SSR is  whether the LSR approximation
SB> is satisfactory or not.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 7 Jan 2016 15:51:53 +0000

Robert, Loa and all,
Quoting from a very old Jewish joke, “you are both right”.

If SR is used just as replacement to LDP, and if its FRR mechanism is limited to what is defined for IP FRR with RLFA, it uses the same size of label stack as LDP would use. It may also provide FRR in situations that are not covered by LDP FRR with RLFA – at the expense of pushing more labels.
I have seen a public presentation that claims that, for some specific network 100% protection coverage against link and node failure can be achieved if up to 4 labels could be pushed.

If SR is used as an alternative (to RSVP-TE) TE tool, it also increases the depth of the stack. This is pretty obvious if the LSP is required to follow a fully specified (strict) route.

From my POV the Problem Statement draft explicitly refers to (at least) all these applications.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, January 07, 2016 5:12 PM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [spring] Last Call: <draft-ietf-spring-problem-statement-06.txt> (SPRING Problem Statement and Requirements) to Informational RFC

Hi Loa,

If one uses SR as a replacement for LDP signalling there is no increase of the label stack at all. So such statement would not be correct.

If one needs some TE, service chaining or any other services from your network then you impose in addition one or more ​labels or use v6 extension header.

If you just want to compare MPLS-TE with SR then you need to consider all elements involved especially the MPLS-TE control plane not just keep focusing on the packet.

Cheers,
r.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 7 Jan 2016 23:56:06 +0800

Robert,

We had a context in the mail I responded to (at least I read it - TE
and the depth of the label stack. I commented in that context, I agree
that some more extensive comparisons would be nice to have.

/Loa

On 2016-01-07 23:11, Robert Raszuk wrote:
> If one uses SR as a replacement for LDP signalling there is no increase
> of the label stack at all. So such statement would not be correct.
>
> network then you impose in addition one or more ​labels or use v6
> extension header.
>
> If you just want to compare MPLS-TE with SR then you need to consider
> all elements involved especially the MPLS-TE control plane not just keep
> focusing on the packet.
>
> Cheers,
> r.
>
>
>
>
>
>