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
------------------------------
Alin Bandiu
------------------------------
Original Message:
Sent: 07-29-2019 10:38
From: ankurt
Subject: MPLS - Adaptive vs Soft-Preemption
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!!!