Segment Routing with RSVP-Traffic Engineering Tunnels

In the previous post we discussed setting up SR.

SR is now running but its relying on IGP for the shortest path through the SP core. RSVP-TE is used to choose the best route and not necessarily the shortest path. We'll pretend that the connections between XR1 and XR2, XR3 and XR4 are 10 Gbps connections, the rest of the network is 40 Gbps. The goal is to build a TE tunnel that will take the path XR1 > XR5 > XR6 > XR2 > XR3 > XR7 > XR8 > XR4, which will effectively bypass the slower links. There will also be a backup path option that will be able to take the direct XR1 > XR2 > XR3 > XR4 path.

The first thing that needs to be done is enabling MPLS Traffic Engineering, RSVP and enabling OSPF to support MPLS TE for area 0.


XR1 - XR8
router ospf 1
 area 0
  mpls traffic-eng
 !
 mpls traffic-eng router-id Loopback0


XR1
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.115


XR2
rsvp
 interface GigabitEthernet0/0/0/0.112
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.112
 !
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.126


XR3
rsvp
 interface GigabitEthernet0/0/0/0.123
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.123
 !
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.137


XR4
rsvp
 interface GigabitEthernet0/0/0/0.134
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.134
 !
 interface GigabitEthernet0/0/0/0.148


XR5
rsvp
 interface GigabitEthernet0/0/0/0.115
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.115
 !
 interface GigabitEthernet0/0/0/0.156


XR6
rsvp
 interface GigabitEthernet0/0/0/0.126
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.156
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
!
mpls traffic-eng
 !
 interface GigabitEthernet0/0/0/0.126
 !
 interface GigabitEthernet0/0/0/0.156
 !
 interface GigabitEthernet0/0/0/0.167


XR7
rsvp
 interface GigabitEthernet0/0/0/0.137
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.167
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.137
 !
 interface GigabitEthernet0/0/0/0.167
 !
 interface GigabitEthernet0/0/0/0.178


XR8
rsvp
 interface GigabitEthernet0/0/0/0.148
  bandwidth 750000
 !
 interface GigabitEthernet0/0/0/0.178
  bandwidth 750000
 !
!
mpls traffic-eng
 interface GigabitEthernet0/0/0/0.148
 !
 interface GigabitEthernet0/0/0/0.178

Now that we have built the TE topology, we can build the unidirectional tunnel from XR1 to XR4 via the path we laid out from above, there should also be another path option that follows the IGP path. The TE tunnel should advertise the TE tunnel as an IGP route.

XR1
explicit-path name SR_TE
 index 1 next-address strict ipv4 unicast 192.0.2.25
 index 2 next-address strict ipv4 unicast 192.0.2.26
 index 3 next-address strict ipv4 unicast 192.0.2.22
 index 4 next-address strict ipv4 unicast 192.0.2.23
 index 5 next-address strict ipv4 unicast 192.0.2.27
 index 6 next-address strict ipv4 unicast 192.0.2.28
 index 7 next-address strict ipv4 unicast 192.0.2.24
!
interface tunnel-te1
 ipv4 unnumbered Loopback0
 autoroute announce
 !
 destination 192.0.2.24
 path-option 5 explicit name SR_TE segment-routing
 path-option 10 segment-routing

RP/0/0/CPU0:XR1#sh ip int br
tunnel-te1                     192.0.2.21      Up              Up       default 

We can see that the tunnel was signaled successfully, if it wasn't the tunnel wouldn't not become up/up.

RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels 1 
Thu May 10 22:34:29.600 UTC


Name: tunnel-te1  Destination: 192.0.2.24  Ifhandle:0x680 
  Signalled-Name: XR1_t1
  Status:
    Admin:    up Oper:   up   Path:  valid   Signalling: connected

    path option 5, (Segment-Routing) type explicit SR_TE (Basis for Setup)
      Protected-by PO index: none
    path option 10,  type segment-routing 
    G-PID: 0x0800 (derived from egress interface properties)
    Bandwidth Requested: 0 kbps  CT0
    Creation Time: Thu May 10 21:31:07 2018 (01:03:23 ago)
  Config Parameters:
    Bandwidth:        0 kbps (CT0) Priority:  7  7 Affinity: 0x0/0xffff
    Metric Type: TE (default)
    Path Selection:
      Tiebreaker: Min-fill (default)
      Protection: any (default)
    Hop-limit: disabled
    Cost-limit: disabled
    Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
    AutoRoute:  enabled  LockDown: disabled   Policy class: not set
    Forward class: 0 (default)
    Forwarding-Adjacency: disabled
    Loadshare:          0 equal loadshares
    Auto-bw: disabled
    Path Protection: Not Enabled
    BFD Fast Detection: Disabled
    Reoptimization after affinity failure: Enabled
    SRLG discovery: Disabled
  History:
    Tunnel has been up for: 01:03:22 (since Thu May 10 21:31:08 UTC 2018)
    Current LSP:
      Uptime: 00:52:10 (since Thu May 10 21:42:20 UTC 2018)
    Prior LSP:
      ID: 2 Path Option: 10
      Removal Trigger: reoptimization completed

  Segment-Routing Path Info (OSPF 1 area 0)
    Segment0[Node]: 192.0.2.25, Label: 16025
    Segment1[Node]: 192.0.2.26, Label: 16026
    Segment2[Node]: 192.0.2.22, Label: 16022
    Segment3[Node]: 192.0.2.23, Label: 16023
    Segment4[Node]: 192.0.2.27, Label: 16027
    Segment5[Node]: 192.0.2.28, Label: 16028
    Segment6[Node]: 192.0.2.24, Label: 16024
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

The MPLS TE tunnel output shows that SR is being used to build the tunnel, meaning that SR labels will be used and not RSVP-TE which would be labels starting at 24000 and above. The current path being leveraged is option 5, the explicit path, which is defined above. 

RP/0/0/CPU0:XR1#sh route 192.0.2.24
Thu May 10 22:35:40.545 UTC

Routing entry for 192.0.2.24/32
  Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
  Installed May 10 21:31:09.200 for 01:04:31
  Routing Descriptor Blocks
    192.0.2.24, from 192.0.2.24, via tunnel-te1
      Route metric is 4
  No advertising protos. 

Expanding the route to XR4's loopback, we see that the path now follows the TE1 path and is using a labeled SR path.

RP/0/0/CPU0:XR1#sh cef 192.0.2.24
Thu May 10 22:35:56.954 UTC
192.0.2.24/32, version 46, internal 0x1000001 0x1 (ptr 0xa12b3a74) [1], 0x0 (0xa127f584), 0xa20 (0xa150d320)
 Updated May 10 21:31:09.460
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 192.0.2.24/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0f164f0 0xa0f16154]
    next hop 192.0.2.24/32
    local adjacency
     local label 24007      labels imposed {ImplNull}

Looking at the CEF table we can see label 24007 was allocated as adjacency SID since the TE1 tunnel is a new tunnel and therefore a label needs to be allocated.

RP/0/0/CPU0:XR1#sh mpls forwarding labels 24007
Thu May 10 22:50:33.174 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------

24007  Pop         192.0.2.24/32      tt1          192.0.2.24      0   

We can prove that by looking at what label 24007 was applied to, in this case it is the TE tunnel.

Once the tunnel is up, re-optimization maybe needed to take the explicit path.

RP/0/0/CPU0:XR1#mpls traffic-eng reoptimize 1

Now that we have a TE tunnel up and running, the routing table shows that traffic towards XR4 will take the TE tunnel. Let's do a trace from XR1 to XR4 and see what happens.

RP/0/0/CPU0:XR1#traceroute 192.0.2.24 source 192.0.2.21 num
Thu May 10 22:36:40.701 UTC

Type escape sequence to abort.
Tracing the route to 192.0.2.24

 1  100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024 Exp 0] 139 msec  119 msec  109 msec 
 2  100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024 Exp 0] 119 msec  109 msec  149 msec 
 3  100.64.126.12 [MPLS: Labels 16023/16027/16028/16024 Exp 0] 119 msec  119 msec  119 msec 
 4  100.64.123.13 [MPLS: Labels 16027/16028/16024 Exp 0] 129 msec  109 msec  119 msec 
 5  100.64.137.17 [MPLS: Labels 16028/16024 Exp 0] 109 msec  119 msec  119 msec 
 6  100.64.178.18 [MPLS: Label 16024 Exp 0] 119 msec  129 msec  109 msec 
 7  100.64.148.14 109 msec  *  109 msec 

We can see that the TE tunnel is being taken with the 7 SR label stack. This stack is encoded as it hits the ingress PE.

R1#ping 192.0.2.2 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/86/90 ms

R1#traceroute 192.0.2.2 source lo0 num
Type escape sequence to abort.
Tracing the route to 192.0.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.101.11 19 msec 7 msec 10 msec
  2 100.64.115.15 [MPLS: Labels 16026/16022/16023/16027/16028/16024/24004 Exp 0] 131 msec 133 msec 126 msec
  3 100.64.156.16 [MPLS: Labels 16022/16023/16027/16028/16024/24004 Exp 0] 143 msec 134 msec 123 msec
  4 100.64.126.12 [MPLS: Labels 16023/16027/16028/16024/24004 Exp 0] 143 msec 129 msec 124 msec
  5 100.64.123.13 [MPLS: Labels 16027/16028/16024/24004 Exp 0] 140 msec 133 msec 126 msec
  6 100.64.137.17 [MPLS: Labels 16028/16024/24004 Exp 0] 141 msec 138 msec 124 msec
  7 100.64.178.18 [MPLS: Labels 16024/24004 Exp 0] 135 msec 132 msec 128 msec
  8 100.64.148.14 [MPLS: Label 24004 Exp 0] 130 msec 133 msec 127 msec
  9 100.64.103.2 133 msec *  136 msec

We see that in the above ping worked, but that doesn't showcase the SR TE output. The traceroute showcases the SR TE stack. The screenshot shows that the entire stack is encoded as traffic enters the SP core.

Thanks for stopping by!

Rob Riker, CCIE #50693

Segment Routing on IOS XR 6.0

Segment Routing or SR is another labeling mechanism on IOS XR. Most people are familiar with LDP or Label Distribution Protocol for allocating labels the PE and P loopbacks and their connected links. LDP requires the network to maintain a level state equal to the size of the network, if there are only a few routers making up the core, the level of state is pretty low.

The purpose of SR is to control the label allocation that the PE and P routers will use for their loopbacks and the transit links. The key difference between SR and LDP is SR allocates the label to the loopback interface. LDP does not do this, static labeling is supported but configuration intensive. SR uses a dedicated block of labels, the SRGB with a range of 16000-23999.

LDP is deployed along side of IGP but as a different process, IGP needs to be converged before LDP converges or micro loops can occur.

SR is configured under the IGP process for both OSPF and IS-IS. The SR labels are propagated inside of the IS-IS TLVs and OSPF Opaque LSAs.

There are 2 different label allocations, the loopback of the P or PE router and the connected links between the P and PE routers.

The loopback label is called the "Prefix SID" or Prefix Segment Identifier.
The transit label is called the "Adjacency SID" or Adjacency Segment Identifier.

The Prefix SID comes from the 16000-23999 label range, the SRGB.
The Adjacency SID comes from the dynamic label range 24000-1048575.

The only thing that changes in the MPLS L3VPN deployment here is SR is the labeling technique, VRFs, MP-BGP, VRF Aware BGP PE-CE and IGP routing are still needed. The above IOS routers, R1-R4 R1 is ASN 101, R2 is ASN 102 and so forth. The ASN in the core is ASN1. XR6 is a RR to the PE routers.

The configuration and verification outputs are below.

XR1
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16021
  !
  interface GigabitEthernet0/0/0/0.112
  !
  interface GigabitEthernet0/0/0/0.115

XR2
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16022
  !
  interface GigabitEthernet0/0/0/0.112
  !
  interface GigabitEthernet0/0/0/0.123
  !
  interface GigabitEthernet0/0/0/0.126

XR3
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16023
  !
  interface GigabitEthernet0/0/0/0.123
  !
  interface GigabitEthernet0/0/0/0.134
  !
  interface GigabitEthernet0/0/0/0.137

XR4
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16024
  !
  interface GigabitEthernet0/0/0/0.134
  !
  interface GigabitEthernet0/0/0/0.148

XR5
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16025
  !
  interface GigabitEthernet0/0/0/0.115
  !
  interface GigabitEthernet0/0/0/0.156

XR6
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16026
  !
  interface GigabitEthernet0/0/0/0.126
  !
  interface GigabitEthernet0/0/0/0.156
  !
  interface GigabitEthernet0/0/0/0.167

XR7
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid absolute 16027
  !
  interface GigabitEthernet0/0/0/0.137
  !
  interface GigabitEthernet0/0/0/0.167
  !
  interface GigabitEthernet0/0/0/0.178

XR8
router ospf 1
 area 0
  segment-routing forwarding mpls
  segment-routing mpls
  interface Loopback0
   prefix-sid index 28
  !
  interface GigabitEthernet0/0/0/0.148
  !
  interface GigabitEthernet0/0/0/0.178

XR8 is running 5.3 XR code, so the "absolute" option isn't supported, Index and absolute do the same thing, index just calls the label value that will get added to 16000 where absolute defines it completely.


RP/0/0/CPU0:XR1#sh mpls interfaces  detail 
Wed May  9 19:17:00.751 UTC
Interface GigabitEthernet0/0/0/0.112:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.115:
        LDP labelling not enabled
        LSP labelling not enabled

        MPLS enabled

RP/0/0/CPU0:XR2#show mpls interfaces detail 
Wed May  9 19:18:20.711 UTC
Interface GigabitEthernet0/0/0/0.112:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.123:
        LDP labelling not enabled
        LSP labelling not enabled
        MPLS enabled
Interface GigabitEthernet0/0/0/0.126:
        LDP labelling not enabled
        LSP labelling not enabled

        MPLS enabled

As you can see, LDP is not being used here, Segment Routing is.

R1 and R2 have now peered with the SP and advertised their loopbacks into BGP.

R1#sh ip route bgp | b  Gateway
Gateway of last resort is not set

      192.0.2.0/32 is subnetted, 2 subnets

B        192.0.2.2 [20/0] via 100.64.101.11, 10:18:02


R2#sh ip route bgp | b  Gateway
Gateway of last resort is not set

      192.0.2.0/32 is subnetted, 2 subnets
B        192.0.2.1 [20/0] via 100.64.103.14, 10:18:48

Now we'll do some trace routes to see how Segment Routing will look different than what LDP will look. NOTE - BGP VPNv4 is still used to allocate labels for customer learned routes, these labels are pulled from the global dynamic label pool.

R2#traceroute 192.0.2.1 source loopback 0 numeric 
Type escape sequence to abort.
Tracing the route to 192.0.2.1
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.103.14 23 msec 14 msec 8 msec
  2 100.64.134.13 [MPLS: Labels 16021/24004 Exp 0] 107 msec 92 msec 91 msec
  3 100.64.123.12 [MPLS: Labels 16021/24004 Exp 0] 99 msec 97 msec 100 msec
  4 100.64.112.11 [MPLS: Label 24004 Exp 0] 99 msec 85 msec 88 msec
  5 100.64.101.1 89 msec *  110 msec

The 16021/24004 is the 2 label stack we would normally see with LDP, the top label, the transport label, 16021 wouldn't be in the range of 16000-23999.

In this case, the label 16021 isn't LDP allocating labels arbitrarily, this label value is configured on XR1 on the loopback interface and propagated to the other P/PE routers inside of OSPF Opaque LSAs. All of the routers in the core know that to reach XR1 via a labeled path, they must use label 16021 to get there.

We'll take the next several outputs and examine them to breakdown how we the label values above were allocated and understand where they fit in.

Let's see what routes we received in from XR1 via the RR of XR6.

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast neighbors 192.0.2.26 routes | b Network
Wed May  9 19:31:25.218 UTC
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf A)
*>i192.0.2.1/32       192.0.2.21               0    100      0 101 i

Processed 1 prefixes, 1 paths

We can see that we learned 192.0.2.1 from 192.0.2.21, let's expand that to see what label value VPNv4 applied.

RP/0/0/CPU0:XR4#sh bgp vrf A 192.0.2.1/32
Wed May  9 19:25:24.652 UTC
BGP routing table entry for 192.0.2.1/32, Route Distinguisher: 1:1
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  4           4
Last Modified: May  9 09:00:02.407 for 10:25:22
Paths: (1 available, best #1)
  Advertised to CE peers (in unique update groups):
    100.64.103.2    
  Path #1: Received by speaker 0
  Advertised to CE peers (in unique update groups):
    100.64.103.2    
  101
    192.0.2.21 (metric 4) from 192.0.2.26 (192.0.2.21)
      Received Label 24004
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 4
      Extended community: RT:1:1 
      Originator: 192.0.2.21, Cluster list: 192.0.2.26
      Source AFI: VPNv4 Unicast, Source VRF: A, Source Route Distinguisher: 1:1

We see that label 24004 was allocated by VPNv4 for the 192.0.2.1/32 route advertised by XR1. We have the VPN label, now we need to know what to configure as the transport label.

RP/0/0/CPU0:XR4#sh route 192.0.2.21
Wed May  9 19:34:21.986 UTC

Routing entry for 192.0.2.21/32
  Known via "ospf 1", distance 110, metric 4, labeled SR, type intra area
  Installed May  8 22:23:31.979 for 21:10:50
  Routing Descriptor Blocks
    100.64.134.13, from 192.0.2.21, via GigabitEthernet0/0/0/0.134
      Route metric is 4

  No advertising protos.

We see that the route was learned via OSPF intra area propagation, more importantly, labeled SR is propagated as well.

RP/0/0/CPU0:XR4#show cef 192.0.2.21
Wed May  9 19:36:06.659 UTC
192.0.2.21/32, version 16, internal 0x1000001 0x81 (ptr 0xa12b3a74) [1], 0x0 (0xa12994f4), 0xa28 (0xa150d140)
 Updated May  8 22:23:32.049 
 local adjacency 100.64.134.13
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 100.64.134.13/32, GigabitEthernet0/0/0/0.134, 9 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0f592a4 0x0]
    next hop 100.64.134.13/32
    local adjacency
     local label 16021      labels imposed {16021}

Checking the CEF table we can see that both the imposed label and the local label are both 16021. Imposed means that 16021 will be used to forward these packets through the core.

RP/0/0/CPU0:XR4#show mpls forwarding labels 16021        
Wed May  9 19:38:12.840 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
16021  16021       SR Pfx (idx 21)    Gi0/0/0/0.134 100.64.134.13   5628  

This is a prefix SID that is applied to XR1's loopback. It is both the local label and the outgoing label.

RP/0/0/CPU0:XR4#sh ospf database opaque-area adv-router 192.0.2.21
Wed May  9 19:39:44.484 UTC


            OSPF Router with ID (192.0.2.24) (Process ID 1)

                Type-10 Opaque Link Area Link States (Area 0)

  LS age: 926
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 4.0.0.0
  Opaque Type: 4
  Opaque ID: 0
  Advertising Router: 192.0.2.21
  LS Seq Number: 80000027
  Checksum: 0x8ceb
  Length: 52

    Router Information TLV: Length: 4
    Capabilities:
      Graceful Restart Helper Capable
      Stub Router Capable
      All capability bits: 0x60000000

    Segment Routing Algorithm TLV: Length: 1
      Algorithm: 0

    Segment Routing Range TLV: Length: 12
      Range Size: 8000

        SID sub-TLV: Length 3
         Label: 16000

  LS age: 664
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 7.0.0.1
  Opaque Type: 7
  Opaque ID: 1
  Advertising Router: 192.0.2.21
  LS Seq Number: 80000027
  Checksum: 0xc5ee
  Length: 44

    Extended Prefix TLV: Length: 20
      Route-type: 1
      AF        : 0
      Flags     : 0x40
      Prefix    : 192.0.2.21/32

      SID sub-TLV: Length: 8
        Flags     : 0x0
        MTID      : 0
        Algo      : 0
        SID Index : 21

Looking at the bolded parts of the OSPF Opaque LSA, we see that the Prefix SID begins at 16000 and carries for 8000 which ranges from 16000 - 23999. Below that we see the Prefix of 192.0.2.21 with an index of 21. 16000 plus 21 gets us 16021. This boils down that 16021 will be the transport label for every SP core router, XR2 through XR8 to reach XR1.