Routing

morning,

Preparing for IE test

for MPLS, there are two knobs: Soft-preemption and Adaptive

They seem to have very similar effects - smooth transition of LSP traffic, holding the old LSP up while transitioning traffic to the new LSP. A number of scenarios set this off: optimize-timer, connectivity interruption, preemption & path modification

according to their respective Techlibrary pages the only difference seems to be that bw is double counted with SP and not with adaptive. Though SP seems to only mention preemption as a trigger (as in a superior priority LSP pushes our LSP onto new links) - this seems clear with the name but hoping for confirmation here. I feel like I am missing something - are there any other differences? Do these four scenarios trigger either/both mechanisms? Any best practices involved?

Thanks

Hello,

"adaptive" sets LSP reservation style as Shared Explicit, JUNOS default is Fixed Filter 

Both are described in RFC 3209 https://tools.ietf.org/html/rfc3209

"Make-before-break" for the SAME individual LSP is the default behaviour and is not configurable. However, it is not the default for SEVERAL LSPs which need to yield each other to fit into a given finite network BW to be established and that's where soft-preemption comes handy.

"soft-preemption" is described in RFC 5712 https://tools.ietf.org/html/rfc5712 and is useful, well, when You have something to preempt! I.e. when BW of Your links are oversubscribed or are going to be oversubscribed and You have a priority service that uses some of the LSPs then it's time to think about LSP setup priority, hold priority and soft-preeemption on top.

HTH

Thx

Alex

By default reservations are set using Fixed Filter Reservation Style, which means that each session has its own reserved bandwidth. You can see in the example, that if the routers attempt to create the new LSP, also requesting 6Gbps, the new LSP set up will fail.

When you configure adaptive, the bandwidth reservation is changed to Shared Explicit, which means the sessions share a single bandwidth reservation. Thus, when you enable adaptive, the new LSP will be successfully created.

HTH

Hi Byron,

What yo have said is true for most part of it. let me explain a little more.

Soft preemption attempts to establish a new path for a preempted LSP before tearing down the original LSP. The default behavior is to tear down a preempted LSP first, signal a new path, and then reestablish the LSP over the new path. In the interval between when the path is taken down and the new LSP is established, any traffic attempting to use the LSP is lost. Soft preemption prevents this type of traffic loss. The trade-off is that during the time when an LSP is being soft preempted, two LSPs with their corresponding bandwidth requirements are used until the original path is torn down.

Another use case for soft-preemption can be during network-maintenances, where you want to move all LSPs away from a particular link, and then take the interface down without interrupting traffic. You can find more details on soft-preemption in RFC 5712.

As you already said, soft-preemption is useful to minimize traffic interruption where Superior priority LSP pushes other LSPs to new links.But when we are taking about the other 3 of the 4 scenarios like LSP reroute due to some link failure, explicit-path modification or LSP re-optimization then the useful knob would be adaptive.

You can configure an LSP to be adaptive when it is attempting to reroute itself. When it is adaptive, the LSP holds onto existing resources until the new path is successfully established and traffic has been cut over to the new LSP. It avoids double-counting BW for the links that share the new and old paths as it works on Shared Explicit reservation style, which means the sessions share  single bandwidth reservation.

To achieve hitless switchover for LSPs (Make before break) you can leverage both these knobs along with some addiitonal features.
As for the best practices to achieve MBB for LSPs, kindly refer the below techlibrary document,

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/make-before-break-achieving-for-lsps.html

I hope this helps !

Regards,
Ankur
JNCIE x 3 (SP,DC & ENT)
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!

This is a fantastic Reply! What I think it lacks is an example, for anyone studying hope this might help! 

Topology: 

All links 1G BW. 

LSP Blue: User defined ERO(P5-strict P3 strict), RSVP request for 1G bw , Priority 6,6 
LSP Yellow: User defined ERO(P2-strict,P3-strict) RSVP request for 1G bw , Priority 5,5 

Case 1: LSP Blue setup with adaptive only configured: (LSP Yellow not yet setup) 
root@PE1# show | display set
set protocols mpls optimize-aggressive
set protocols mpls label-switched-path PE1-P6 traceoptions file CSPF
set protocols mpls label-switched-path PE1-P6 traceoptions flag cspf
set protocols mpls label-switched-path PE1-P6 to 172.16.0.66
set protocols mpls label-switched-path PE1-P6 bandwidth 1g
set protocols mpls label-switched-path PE1-P6 priority 6 6
set protocols mpls label-switched-path PE1-P6 optimize-timer 10
set protocols mpls label-switched-path PE1-P6 adaptive
set protocols mpls label-switched-path PE1-P6 primary via-P5-P3
set protocols mpls path via-P5-P3 172.16.0.55 strict
set protocols mpls path via-P5-P3 172.16.0.33 strict
set protocols mpls interface all

LSP blue will be UP. 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
10.1.15.55 S 10.1.35.33 S 10.1.36.66 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.1.15.55(Label=300480) 10.1.35.33(Label=300752) 10.1.36.66(Label=3)

LSP Yellow is configured, and the link between P3 and P6 is shared, so LSP Yellow will Preempt LSP Blue due to priority configuration, we have adaptive configured on LSP Blue. This preemption will cause some downtime on LSP blue. 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
10.1.15.55 S 10.1.35.33 S 10.1.34.44 S 10.1.46.66 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.1.15.55(Label=300496) 10.1.35.33(Label=300784) 10.1.34.44(Label=300064) 10.1.46.66(Label=3)
96 Feb 5 12:44:24.495 Self-ping ended successfully
95 Feb 5 12:44:24.121 Selected as active path
94 Feb 5 12:44:24.120 Up
93 Feb 5 12:44:24.119 Self-ping started
92 Feb 5 12:44:24.119 Self-ping enqueued
91 Feb 5 12:44:24.119 Record Route: 10.1.15.55(Label=300496) 10.1.35.33(Label=300784) 10.1.34.44(Label=300064) 10.1.46.66(Label=3)
90 Feb 5 12:44:24.069 Originate Call
89 Feb 5 12:44:24.069 CSPF: computation result accepted 10.1.15.55 10.1.35.33 10.1.34.44 10.1.46.66
88 Feb 5 12:44:18.609 CSPF failed: no route toward 172.16.0.55
87 Feb 5 12:44:18.609 Clear Call: CSPF computation failed
86 Feb 5 12:44:18.608 Deselected as active
85 Feb 5 12:44:18.607 ResvTear received
84 Feb 5 12:44:18.607 10.1.15.1: Down
83 Feb 5 12:44:18.607 10.1.35.33: Requested bandwidth unavailable
82 Feb 5 12:44:18.607 10.1.35.33: Session preempted


Case2: LSP Blue configured with soft-preemption only: 

Will be enqueued for recomputation in 2 second(s).
21 Feb 5 12:54:58.288 CSPF failed: no route toward 172.16.0.55[2 times, first Feb 5 12:54:55.670]
20 Feb 5 12:54:55.669 Clear Call: CSPF computation failed
19 Feb 5 12:54:55.668 Deselected as active
18 Feb 5 12:54:55.668 ResvTear received 

LSP Blue because is missing the adaptive keyword will not have enough bw on link PE1-P5 for setting up the new LSP, because of that the computation of the new path fails, and we still have downtime. 



Case 3: Adaptive and Soft-preemption configured  NO-DOWNTIME 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
10.1.15.55 S 10.1.35.33 S 10.1.34.44 S 10.1.46.66 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.1.15.55(Label=300560) 10.1.35.33(Label=300880) 10.1.34.44(Label=300096) 10.1.46.66(Label=3)
19 Feb 5 13:00:40.716 Make-before-break: Switched to new instance
18 Feb 5 13:00:40.714 Self-ping ended successfully
17 Feb 5 13:00:40.583 Up
16 Feb 5 13:00:40.583 Self-ping started
15 Feb 5 13:00:40.583 Self-ping enqueued
14 Feb 5 13:00:40.583 Record Route: 10.1.15.55(Label=300560) 10.1.35.33(Label=300880) 10.1.34.44(Label=300096) 10.1.46.66(Label=3)
13 Feb 5 13:00:40.537 Originate make-before-break call
12 Feb 5 13:00:40.537 CSPF: computation result accepted 10.1.15.55 10.1.35.33 10.1.34.44 10.1.46.66
11 Feb 5 13:00:40.537 10.1.35.33: Reroute request due to soft preemption received. 

Hope this helps! 

BR, 
Alin