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
Email:   [email protected]

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

Hi Loa,

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?

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





_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to