Blog Viewer

SRv6 SID Encoding and Transposition

By Krzysztof Szarkowicz posted 12-02-2022 09:14

  


JUNOS 22.3 introduced several changes in the SRv6 infrastructure, this article covers them in details.                                                        

Introduction

This is the 4th blog in the series of SRv6 blogs. It discusses the SRv6 infrastructure changes introduced with Junos 22.3. Namely:

  • structured way of SRv6 SID composition (Locator Block, Node Block, Function, Argument), including the ways to change the default block sizes
  • static and dynamic SRv6 SID ranges
  • partial SRv6 SID encoding in the label value in the L3VPN (SAFI=128) NLRI
  • relaxation of the requirement that BGP Protocol Next Hop must be changed to SRv6 locator or SRv6 SID of egress PE

This blog post is based on the capabilities of Junos 22.3 running on MX Series and ACX7000 routers. Config and show command outputs have been collected on vMX in our labs.

You can test yourself all the concepts described in this article, we created labs in JCL and vLabs:
JCL (Junivators and partners)
vLabs (open to all)

SRv6 SID Composition

As discussed in the 1st SRv6 blog, SRv6 SID (Segment Identifier) is composed of LOCATOR:FUNCTION:ARGUMENT parts, where LOCATOR can be further decomposed to Locator Block and Locator Node. The general SRv6 SID structure is outlined in Figure 1.

Figure 1: General SRv6 SID Structure

The length of each part can be changed if the Junos defaults are not suitable for the particular SRv6 deployment:

  • BL – Locator Block Length (Junos default 48)
  • NL – Locator Node Length (Junos default 0)
  • FL – Function Length (Junos default 16)
  • AL – Argument Length (Junos default 0)

For example, Figure 1 shows Junos non-default values for the BL, NL and AL. Up to Junos release 22.2, this strict SID segmentation was not enforced. If you check CLI-Output 1 in the 2nd SRv6 blog, you can observe that BL/NL/FL/AL values are all 0: there is no specific enforcement there.

In this article we are using the same topology and the same VPNs (Virtual Private Networks) as in the 2nd SRv6 blog, with slight changes in the addressing – particularly in the SRv6 locator addressing – as outlined in Figure 2.

Figure 2: SRv6 Topology (only VPN 20 shown for readability; VPN 30 not shown)

Consequently, comparing to the 2nd SRv6 blog, different SRv6 SIDs are configured for each VPN:

  • VPN 20:
    • end-dt4-sid fc01:0:11:0420::
    • end-dt6-sid fc01:0:11:0620::
  • VPN 30
    • end-dt46-sid fc01:0:11:4630::

Now, let’s check, what is advertised by PE11 to the route reflector P1:

1       root@PE11> show route advertising-protocol bgp 2001:db8:bad:cafe::1 table RI-VRF20 detail
2       
3       
4       RI-VRF20.inet.0: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden)
5       * 20.11.91.0/24 (1 entry, 1 announced)
6        BGP group GR-IBGP-RR type Internal
7            Route Distinguisher: 198.51.100.11:20
8            VPN Label: 16896
9            Nexthop: Self
10           Flags: Nexthop Change
11           Localpref: 100
12           AS path: [65000] I 
13           Communities: target:65000:20
14                      SRv6 SID: fc01:0:11:: Behavior: 19 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48
15      
16      * 192.168.20.11/32 (1 entry, 1 announced)
17       BGP group GR-IBGP-RR type Internal
18           Route Distinguisher: 198.51.100.11:20
19           VPN Label: 16896
20           Nexthop: Self
21           Flags: Nexthop Change
22           Localpref: 100
23           AS path: [65000] I 
24           Communities: target:65000:20
25                      SRv6 SID: fc01:0:11:: Behavior: 19 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48
26      
27      * 192.168.20.91/32 (1 entry, 1 announced)
28       BGP group GR-IBGP-RR type Internal
29           Route Distinguisher: 198.51.100.11:20
30           VPN Label: 16896
31           Nexthop: Self
32           Flags: Nexthop Change
33           MED: 1
34           Localpref: 100
35           AS path: [65000] I
36           Communities: target:65000:20 rte-type:0.0.0.0:1:0
37                      SRv6 SID: fc01:0:11:: Behavior: 19 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48
38      
39      RI-VRF20.inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
40      
41      * 2001:db8:abba:20::11/128 (1 entry, 1 announced)
42       BGP group GR-IBGP-RR type Internal
43           Route Distinguisher: 198.51.100.11:20
44           VPN Label: 25088
45           Nexthop: Self
46           Flags: Nexthop Change
47           Localpref: 100
48           AS path: [65000] I
49           Communities: target:65000:20
50                      SRv6 SID: fc01:0:11:: Behavior: 18 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48
51                                          
52      * 2001:db8:abba:20::91/128 (1 entry, 1 announced)
53       BGP group GR-IBGP-RR type Internal
54           Route Distinguisher: 198.51.100.11:20
55           VPN Label: 25088
56           Nexthop: Self
57           Flags: Nexthop Change
58           MED: 1000
59           Localpref: 100
60           AS path: [65000] I 
61           Communities: target:65000:20 rte-type:0.0.0.0:1:0
62                      SRv6 SID: fc01:0:11:: Behavior: 18 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48
63
64      * 2001:db8:babe:face:20:0:1191:0/112 (1 entry, 1 announced)
65       BGP group GR-IBGP-RR type Internal
66           Route Distinguisher: 198.51.100.11:20
67           VPN Label: 25088
68           Nexthop: Self
69           Flags: Nexthop Change
70           Localpref: 100
71           AS path: [65000] I
72           Communities: target:65000:20
73                      SRv6 SID: fc01:0:11:: Behavior: 18 BL: 48 NL: 0 FL: 16 AL: 0 TL: 16 TO: 48

CLI-Output 1: Advertising L3VPN Service Prefix with End.DT4 or End.DT6 SRv6 SID

If you compare this output with the 2nd SRv6 blog, there are couple of differences.

First of all, from Junos 22.3 onwards there is no need to set the BGP (Border Gateway Protocol) protocol next-hop to SRv6 locator or SRv6 SID. Keeping it to the default (i.e. ‘self’, which is typically loopback when iBGP session is used, see lines 9, 20, 31, 45, 56, 68) is fully OK, as from Junos 22.3, for service prefixes with SRv6 SID, not a BGP protocol next-hop, but SRv6 SID is used for next-hop resolution. Therefore, Configuration 4 from the 2nd SRv6 blog, is no longer required, and is omitted in this blog.

Secondly, lengths of each part (BL/NL/FL/AL) in SRv6 SID are now reported (lines 14, 25, 37, 50, 62, 73) with some meaningful values. In the 2nd SRv6 blog all these lengths were reported as ‘0’.

Thirdly, the advertised SRv6 SIDs (lines 14, 25, 37, 50, 62, 73) show only SRv6 locator portion (in the 2nd SRv6 blog we have seen full SRv6 SID advertisements). Where are our configured END.DT4/END.DT6 (fc01:0:11:420::, fc01:0:11:620::) values?

And, finally, there are some ‘strange’ VPN labels advertised (lines 8, 19, 30, 44, 55, 67). At the first look, these VPN labels show some sort of randomness, as they are not allocated sequentially – the label values are not even close to each other. This is very suspicious! In the 2nd SRv6 blog our VPN labels were set to ‘3’ (implicit null), given the fact SRv6 doesn’t use MPLS, so there is no need for a meaningful VPN label. Moreover, checking the label table (LIB – Label Information Base), we don’t even see these labels (CLI-Output 2)!

1       root@PE11> show route table mpls.0
2       
3       mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
4       + = Active Route, - = Last Active, * = Both
5       
6       17                 *[VPN/0] 1d 12:37:49
7                           >  via lsi.1 (RI-VRF30), Pop
8       18                 *[VPN/0] 1d 12:27:06
9                           >  via lsi.3 (RI-VRF20), Pop
CLI-Output 2: MPLS routing table on PE11

Instead, we see in the LIB different labels associated with our VPNs. Essentially, it means, when a packet with the label value 16896 (lines 8, 19, 30 in CLI-Output 1) or with the label value 25088 (lines 44, 55, 67 in CLI-Output 1) arrives to PE11, it will be dropped!

So, why after upgrading to Junos 22.3 do we have MPLS labels in the advertisements?

SRv6 SID Transposition

To answer these questions, let’s make some packet capture, to see PE11 BGP advertisements to P1 (Packet Capture 1).

1       Frame 1: 1608 bytes on wire (12864 bits), 1608 bytes captured (12864 bits)
2       (…)
3       Border Gateway Protocol - UPDATE Message
4           Marker: ffffffffffffffffffffffffffffffff
5           Length: 152
6           Type: UPDATE Message (2)
7           Withdrawn Routes Length: 0
8           Total Path Attribute Length: 129
9           Path attributes
10              Path Attribute - ORIGIN: IGP
11                  Flags: 0x40, Transitive, Well-known, Complete
12                      0... .... = Optional: Not set
13                      .1.. .... = Transitive: Set
14                      ..0. .... = Partial: Not set
15                      ...0 .... = Extended-Length: Not set
16                      .... 0000 = Unused: 0x0
17                  Type Code: ORIGIN (1)
18                  Length: 1
19                  Origin: IGP (0)
20              Path Attribute - AS_PATH: empty
21                  Flags: 0x40, Transitive, Well-known, Complete
22                      0... .... = Optional: Not set
23                      .1.. .... = Transitive: Set
24                      ..0. .... = Partial: Not set
25                      ...0 .... = Extended-Length: Not set
26                      .... 0000 = Unused: 0x0
27                  Type Code: AS_PATH (2)
28                  Length: 0
29              Path Attribute - MULTI_EXIT_DISC: 1
30                  Flags: 0x80, Optional, Non-transitive, Complete
31                      1... .... = Optional: Set
32                      .0.. .... = Transitive: Not set
33                      ..0. .... = Partial: Not set
34                      ...0 .... = Extended-Length: Not set
35                      .... 0000 = Unused: 0x0
36                  Type Code: MULTI_EXIT_DISC (4)
37                  Length: 4
38                  Multiple exit discriminator: 1
39              Path Attribute - LOCAL_PREF: 100
40                  Flags: 0x40, Transitive, Well-known, Complete
41                      0... .... = Optional: Not set
42                      .1.. .... = Transitive: Set
43                      ..0. .... = Partial: Not set
44                      ...0 .... = Extended-Length: Not set
45                      .... 0000 = Unused: 0x0
46                  Type Code: LOCAL_PREF (5)
47                  Length: 4
48                  Local preference: 100
49              Path Attribute - EXTENDED_COMMUNITIES
50                  Flags: 0xc0, Optional, Transitive, Complete
51                      1... .... = Optional: Set
52                      .1.. .... = Transitive: Set
53                      ..0. .... = Partial: Not set
54                      ...0 .... = Extended-Length: Not set
55                      .... 0000 = Unused: 0x0
56                  Type Code: EXTENDED_COMMUNITIES (16)
57                  Length: 16
58                  Carried extended communities: (2 communities)
59                      Route Target: 65000:20 [Transitive 2-Octet AS-Specific]
60                          Type: Transitive 2-Octet AS-Specific (0x00)
61                              0... .... = IANA Authority: Allocated on FCFS Basis
62                              .0.. .... = Transitive across ASes: Transitive
63                          Subtype (AS2): Route Target (0x02)
64                          2-Octet AS: 65000
65                          4-Octet AN: 20
66                      OSPF Route Type: Area: 0.0.0.0, Type: Router [Transitive Opaque]
67                          Type: Transitive Opaque (0x03)
68                              0... .... = IANA Authority: Allocated on FCFS Basis
69                              .0.. .... = Transitive across ASes: Transitive
70                          Subtype (Opaque): OSPF Route Type (0x06)
71                          Area ID: 0.0.0.0
72                          Route type: Router (1)
73                          Options: 0x00 (Metric: Type-1)
74                              .... ...0 = Metric type: Type-1
75              Path Attribute - BGP Prefix-SID
76                  Flags: 0xc0, Optional, Transitive, Complete
77                      1... .... = Optional: Set
78                      .1.. .... = Transitive: Set
79                      ..0. .... = Partial: Not set
80                      ...0 .... = Extended-Length: Not set
81                      .... 0000 = Unused: 0x0
82                  Type Code: BGP Prefix-SID (40)
83                  Length: 37
84                  SRv6 L3 Service
85                      Type: SRv6 L3 Service (5)
86                      Length: 34
87                      Reserved: 00
88                      SRv6 Service Sub-TLVs
89                          SRv6 Service Sub-TLV - SRv6 SID Information
90                              Type: SRv6 SID Information (1)
91                              Length: 30
92                              Reserved: 00
93                              SRv6 SID Value: fc01:0:11::
94                              SRv6 SID Flags: 0x00
95                              SRv6 Endpoint Behavior: End.DT4 (0x0013)
96                              Reserved: 00
97                              SRv6 Service Data Sub-Sub-TLVs
98                                  SRv6 Service Data Sub-Sub-TLV - SRv6 SID Structure
99                                      Type: SRv6 SID Structure (1)
100                                     Length: 6
101                                     Locator Block Length: 48
102                                     Locator Node Length: 0
103                                     Function Length: 16
104                                     Argument Length: 0
105                                     Transposition Length: 16
106                                     Transposition Offset: 48
107             Path Attribute - MP_REACH_NLRI
108                 Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
109                     1... .... = Optional: Set
110                     .0.. .... = Transitive: Not set
111                     ..0. .... = Partial: Not set
112                     ...1 .... = Extended-Length: Set
113                     .... 0000 = Unused: 0x0
114                 Type Code: MP_REACH_NLRI (14)
115                 Length: 45
116                 Address family identifier (AFI): IPv4 (1)
117                 Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
118                 Next hop:  RD=0:0 IPv6=2001:db8:bad:cafe::11
119                     Route Distinguisher: 0:0
120                     IPv6 Address: 2001:db8:bad:cafe::11
121                 Number of Subnetwork points of attachment (SNPA): 0
122                 Network Layer Reachability Information (NLRI)
123                     BGP Prefix
124                         Prefix Length: 120
125                         Label Stack: 16896 (bottom)
126                         Route Distinguisher: 198.51.100.11:20
127                         MP Reach NLRI IPv4 prefix: 192.168.20.91
128     Border Gateway Protocol - UPDATE Message
129         Marker: ffffffffffffffffffffffffffffffff
130         Length: 152
131         Type: UPDATE Message (2)
132         Withdrawn Routes Length: 0
133         Total Path Attribute Length: 129
134         Path attributes
135             Path Attribute - ORIGIN: IGP
136                 Flags: 0x40, Transitive, Well-known, Complete
137                     0... .... = Optional: Not set
138                     .1.. .... = Transitive: Set
139                     ..0. .... = Partial: Not set
140                     ...0 .... = Extended-Length: Not set
141                     .... 0000 = Unused: 0x0
142                 Type Code: ORIGIN (1)
143                 Length: 1
144                 Origin: IGP (0)
145             Path Attribute - AS_PATH: empty
146                 Flags: 0x40, Transitive, Well-known, Complete
147                     0... .... = Optional: Not set
148                     .1.. .... = Transitive: Set
149                     ..0. .... = Partial: Not set
150                     ...0 .... = Extended-Length: Not set
151                     .... 0000 = Unused: 0x0
152                 Type Code: AS_PATH (2)
153                 Length: 0
154             Path Attribute - LOCAL_PREF: 100
155                 Flags: 0x40, Transitive, Well-known, Complete
156                     0... .... = Optional: Not set
157                     .1.. .... = Transitive: Set
158                     ..0. .... = Partial: Not set
159                     ...0 .... = Extended-Length: Not set
160                     .... 0000 = Unused: 0x0
161                 Type Code: LOCAL_PREF (5)
162                 Length: 4
163                 Local preference: 100
164             Path Attribute - EXTENDED_COMMUNITIES
165                 Flags: 0xc0, Optional, Transitive, Complete
166                     1... .... = Optional: Set
167                     .1.. .... = Transitive: Set
168                     ..0. .... = Partial: Not set
169                     ...0 .... = Extended-Length: Not set
170                     .... 0000 = Unused: 0x0
171                 Type Code: EXTENDED_COMMUNITIES (16)
172                 Length: 8
173                 Carried extended communities: (1 community)
174                     Route Target: 65000:20 [Transitive 2-Octet AS-Specific]
175                         Type: Transitive 2-Octet AS-Specific (0x00)
176                             0... .... = IANA Authority: Allocated on FCFS Basis
177                             .0.. .... = Transitive across ASes: Transitive
178                         Subtype (AS2): Route Target (0x02)
179                         2-Octet AS: 65000
180                         4-Octet AN: 20
181             Path Attribute - BGP Prefix-SID
182                 Flags: 0xc0, Optional, Transitive, Complete
183                     1... .... = Optional: Set
184                     .1.. .... = Transitive: Set
185                     ..0. .... = Partial: Not set
186                     ...0 .... = Extended-Length: Not set
187                     .... 0000 = Unused: 0x0
188                 Type Code: BGP Prefix-SID (40)
189                 Length: 37
190                 SRv6 L3 Service
191                     Type: SRv6 L3 Service (5)
192                     Length: 34
193                     Reserved: 00
194                     SRv6 Service Sub-TLVs
195                         SRv6 Service Sub-TLV - SRv6 SID Information
196                             Type: SRv6 SID Information (1)
197                             Length: 30
198                             Reserved: 00
199                             SRv6 SID Value: fc01:0:11::
200                             SRv6 SID Flags: 0x00
201                             SRv6 Endpoint Behavior: End.DT4 (0x0013)
202                             Reserved: 00
203                             SRv6 Service Data Sub-Sub-TLVs
204                                 SRv6 Service Data Sub-Sub-TLV - SRv6 SID Structure
205                                     Type: SRv6 SID Structure (1)
206                                     Length: 6
207                                     Locator Block Length: 48
208                                     Locator Node Length: 0
209                                     Function Length: 16
210                                     Argument Length: 0
211                                     Transposition Length: 16
212                                     Transposition Offset: 48
213             Path Attribute - MP_REACH_NLRI
214                 Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
215                     1... .... = Optional: Set
216                     .0.. .... = Transitive: Not set
217                     ..0. .... = Partial: Not set
218                     ...1 .... = Extended-Length: Set
219                     .... 0000 = Unused: 0x0
220                 Type Code: MP_REACH_NLRI (14)
221                 Length: 60
222                 Address family identifier (AFI): IPv4 (1)
223                 Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
224                 Next hop:  RD=0:0 IPv6=2001:db8:bad:cafe::11
225                     Route Distinguisher: 0:0
226                     IPv6 Address: 2001:db8:bad:cafe::11
227                 Number of Subnetwork points of attachment (SNPA): 0
228                 Network Layer Reachability Information (NLRI)
229                     BGP Prefix
230                         Prefix Length: 112
231                         Label Stack: 16896 (bottom)
232                         Route Distinguisher: 198.51.100.11:20
233                         MP Reach NLRI IPv4 prefix: 20.11.91.0
234                     BGP Prefix
235                         Prefix Length: 120
236                         Label Stack: 16896 (bottom)
237                         Route Distinguisher: 198.51.100.11:20
238                         MP Reach NLRI IPv4 prefix: 192.168.20.11
239     (…)

Packet Capture 1: PE11 to P1 BGP packet capture

The BGP packet might contain multiple BGP Update messages in a single packet. For brevity, out of multiple BGP Update messages present in this packet, only two BGP Update messages are shown:

Lines 3-127, announcing 198.51.100.11:20:192.168.20.91/120 prefix (CE91 loopback within VPN20 --> lines 122-127)

Lines 128-238, announcing 198.51.100.11:20:20.11.91.0/112 prefix (CE91-PE11 link within VPN20) and 198.51.100.11:20:192.168.20.11/120 prefix (PE11 loopback within VPN20: lines 228-238)

Next-hop in both updates is the loopback of PE11 (lines 118 and 224). This is expected, since as mentioned earlier, from Junos 22.3 there is no need to set the BGP next-hop to SRv6 locator or SRv6 SID, hence configuration to set BGP next-hop to SRv6 locator, used in the 2nd SRv6 blog, is not used here.

Lengths of SRv6 parts are advertised via additional Sub-Sub-TLV (Type-Length-Value), called ‘SRv6 SID Structure’ (lines 98-106, and 204-212). Support for this Sub-Sub-TLV (RFC 9252, Section 3.2.1) was introduced in Junos 22.3.

And, indeed, we see only SRv6 locator portion, fc01:0:11:: in both updates, in SRv6 SID advertisements (lines 93 and 199). Further, we can definitely confirm these strange label values observed earlier (CLI-Output 1) are visible in BGP packet capture (lines 125, 231, 236). So, BGP packet capture is in line with CLI output.

Interesting question to ask is: why we have two BGP Update Messages to advertise three prefixes? Why is it not a single BGP Update Message, for all three prefixes, or, eventually, why we don’t see three BGP Update Messages – unique BGP Update Message per prefix.

When BGP prepares updates, it makes some optimization. Prefixes that have the same set of BGP attributes (i.e., the list of BGP attributes is the same, as well as value of each BGP attribute is the same) are grouped together. They are eligible to be sent withing the same BGP Update Message, and the list of BGP attributes is sent only once – obviously, it doesn’t make sense to resend the same list of BGP attributes for each prefix individually. This is the essence of BGP packing optimization.

If you check the second BGP Update Message (lines 128-238), you see that it has two prefixes (lines 213-238) and single list of BGP attributes (lines 135-212). All these BGP attributes apply to two advertised prefixes. And why the first prefix is in separate BGP Update Message? The reason is, BGP attributes are not the same. In the first BGP Update Message there is one additional BGP attribute: MED – Multi-Exit Discriminator (lines 29-38). All other attributes are the same, including their value. So, based on BGP attribute lists, these three prefixes are divided into two groups, each group with unique BGP attribute list, and each group advertised in a separate BGP Update Message.

But, why we are discussing all of this? How is it relevant to SRv6? Well, one of the BGP attributes is BGP Prefix SID (lines 75-106, and lines 181-212), which includes SRv6 SID (lines 93 and 199). In our packet capture, SRv6 SID contains only SRv6 Locator portion, which is the same for all VPN prefixes advertised from given PE. So, even with per-prefix SID allocation, with thousands of VPN prefixes, each VPN prefix with different SRv6 SID (the same Locator part, but different Function part) specified in the configuration, all prefixes could be grouped together, and potentially advertised via single BGP Update Message (well, if they fit into single BGP Update Message with maximum size 4k bytes). This brings the efficiency into BGP packing, which is later reflected in e.g., faster BGP convergence.

But, what we do with the variable part of SRv6 SID, i.e. Function part? In fact, designers of original MPLS based L3VPN were facing the same challenge, as MPLS label with pre-prefix label allocation is different for each VPN prefix. To benefit from optimized BGP packing, the decision was made to include VPN label as part of NLRI, rather than defining new BGP attribute to carry VPN label. As a result, multiple VPN prefixes with different VPN labels, but otherwise with the same set of BGP attributes (NEXT_HOP, AS_PATH, COMMUNITIES, …) could be grouped together and packed into the BGP Update Messages in an efficient manner.

SRv6 is reusing exactly the same NLRI (SAFI=128), to advertise VPN prefixes, with additional SRv6 information carried in some additional attributes (i.e., SRv6 SID). So, the label field (20 bits, RFC 8277, Section 2.2) is there in the NLRI, even if not exactly useful in the SRv6 context, as SRv6 doesn’t utilize MPLS.

But, wait a minute, is it really not useful for SRv6? In fact, instead of wasting these 20 bits (do you recall the 2nd SRv6 blog, where always value ‘3’ was carried in these 20 bits?), we can actually exploit this space in the NLRI, to carry variable part of SRv6 SID (i.e., Function) in it, and carry only the fixed, constant part of SRv6 SID (i.e., Locator) in the BGP Prefix SID attribute. In this way, we make BGP Prefix SID attribute to be the same for all NLRIs, thus allowing efficient BGP packing.

Let’s quickly check all labels advertised by PE11:

1      root@PE11> show route advertising-protocol bgp 2001:db8:bad:cafe::1 detail | match label
2            VPN Label: 16896
3            VPN Label: 16896
4            VPN Label: 16896
5            VPN Label: 287488
6            VPN Label: 287488
7            VPN Label: 287488
8            VPN Label: 25088
9            VPN Label: 25088
10           VPN Label: 25088
11           VPN Label: 287488
12           VPN Label: 287488
13           VPN Label: 287488

CLI-Output 3: VPN labels advertised by PE11

If you convert the observed VPN labels to hexadecimal numbers:

  • 16896 = 0x04200
  • 25088 = 0x06200
  • 287488 = 0x46300

and compare it to the SRv6 SIDs configured for VPNs, and mentioned already earlier:

  • VPN 20:
    • end-dt4-sid fc01:0:11:0420::
    • end-dt6-sid fc01:0:11:0620::
  • VPN 30
    • end-dt46-sid fc01:0:11:4630::

you probably discover some similarity!

Simply, the configured Function (16 bits) is carried not in SRv6 SID Information Sub-TLV, but it is carried instead in 20 bits label space in the NLRI itself, taking first 16 most significant bits (i.e., from the left) of 20 bits label space. This mechanism is called Transposition.

But wait a minute, how all these things are achieved, and how do we know, what is actually carried in the 20 bits label space? This info is as well encoded in the SRv6 SID Structure Sub-Sub-TLV, via Transposition Length – TL, and Transposition Offset – TO (lines 14, 25, 37, 50, 62, 73 in CLI-Output 1, and lines 105-106, 211-212 in Packet Capture 1). Essentially, it says:

  • starting from bit 48 (TO) in the SRv6 locator
  • take 16 bits (TL)
  • put these bits into the label space of the NLRI, aligning to the left
  • in the SRv6 locator, put ‘0’ in place of these moved bits

Basically, SRv6 implementations supporting the SRv6 SID Structure Sub-Sub-TLV (i.e., Junos 22.3 or later) support transposition, allowing for optimized BGP packing for NLRIs with different SRv6 SID (different Function), while implementations not supporting the SRv6 SID Structure Sub-Sub-TLV (i.e., Junos 22.2, or earlier) do not support transposition.

The receiver PE, based on the TL/TO information, can put together the original SRv6 SID from the part advertised in SRv6 SID value, and the part advertised in the label space of the NLRI. This re-constructed SRv6 SID is used in the data plane during packet encapsulation.

In summary, label space in L3VPN NLRI is used in following ways:

  • A. NLRI without SRv6 SID attribute --> classical VPN label (e.g., 18) carried in the label space of the L3VPN NLRI
  • B. NLRI with SRv6 SID attribute, but without SRv6 SID Structure Sub-Sub-TLV --> invalid label (e.g., 3) carried in the label space of the L3VPN NLRI
  • C. NLRI with SRv6 SID attribute, and with SRv6 SID Structure Sub-Sub-TLV --> part of SRv6 SID – in accordance with transposition ruled encoded via TL/TO in the SRv6 SID Structure Sub-Sub-TLV – carried in the label space of the L3VPN NLRI

Actual SRv6 locator structure, as well as the status (i.e., how many SIDs use given SRv6 locator) for local locators can be verified with following operational command:

1       root@PE11> show srv6 locator
2       
3       Locator: SL-000
4         Locator prefix: fc01:0:11::, Locator length: 48
5         Block length: 48, Node length: 0
6         Function length: 16, Argument length: 0
7         Static SID range: 0x1-0x7FFF, Dynamic SID range: 0x8000-0xFFFF
8         Allocated static SID count: 3, Allocated dynamic SID count: 0
9         Available static SID count: 32764, Available dynamic SID count: 32768

CLI-Output 4: Structure and status of locally configured SRv6 locators

Important to note is, that from Junos 22.3 the SRv6 locator infrastructure is prepared to allocate static (by default, first 32767 SRv6 SIDs within the SRv6 locator) and dynamic SRv6 SIDs (remaining SID space within the SRv6 locator). At the time this blog was written, dynamic SRv6 SIDs were supported for EVPN (Ethernet Virtual Private Network) E-Line only. For L3 services (global IPv4/IPv6, and VPN-IPv4/VPN-IPv6) only static SRv6 SIDs were supported. Commit errors prevents to configure static SRv6 SID that falls into the dynamic SRv6 SID range

SRv6 SID Partial Function Transposition

Let’s make some more experiments, by reconfiguring the SRv6 locator on PE12 to non-default BL/NL/FL values, using extended static SRv6 SID range, and adjusting the SRv6 SIDs associated with configured VPNs accordingly.

Note: SRv6 locator parameter changes (like e.g., BL/NL/FL changes) are not taken into effect until RPD (or entire router) is restarted. Therefore, to avoid router or RPD restart, following steps can be taken to change the SRv6 locator parameters. They will still interrupt SRv6 routing for the commit times.

  • 1) delete the SRv6 locator (including all SIDs associated with the SRv6 locator)
  • 2) commit
  • 3) recreate the SRv6 locator (including all SIDs associated with the SRv6 locator)
  • 4) commit
1       [edit routing-instances RI-VRF20 protocols]
2       -     bgp {
3       -         source-packet-routing {
4       -             srv6 {
5       -                 locator SL-000 {
6       -                     end-dt4-sid fc01:0:12:420::;
7       -                     end-dt6-sid fc01:0:12:620::;
8       -                 }
9       -             }
10      -         }
11      -     }
12      [edit routing-instances RI-VRF30 protocols]
13      -     bgp {
14      -         source-packet-routing {
15      -             srv6 {
16      -                 locator SL-000 end-dt46-sid fc01:0:12:4630::;
17      -             }
18      -         }
19      -     }
20      [edit routing-options source-packet-routing srv6]
21      -     locator SL-000 fc01:0:12::/48;
22      [edit protocols isis source-packet-routing srv6]
23      -      locator SL-000 {
24      -          end-sid fc01:0:12::;
25      -      }
CLI-Output 5: Removing the SRv6 locator

1       [edit routing-instances RI-VRF20 protocols]
2       +     bgp {
3       +         source-packet-routing {
4       +             srv6 {
5       +                 locator SL-000 {
6       +                     end-dt4-sid fc01:0:12:0400:0020::;
7       +                     end-dt6-sid fc01:0:12:0600:0020::;
8       +                 }
9       +             }
10      +         }
11      +     }
12      [edit routing-instances RI-VRF30 protocols]
13      +     bgp {
14      +         source-packet-routing {
15      +             srv6 {
16      +                 locator SL-000 end-dt46-sid fc01:0:12:4600:0030::;
17      +             }
18      +         }
19      +     }
20      [edit routing-options source-packet-routing srv6]
21      +     locator SL-000 {
22      +         fc01:0:12::/48;
23      +         block-length 32;
24      +         function-length 32;
25      +         static-function-max-entries 2147483647;
26      +     }
27      [edit protocols isis source-packet-routing srv6]
28      +      locator SL-000 {
29      +          end-sid fc01:0:12::;
30      +      }

CLI-Output 6: Recreating the SRv6 locator with new parameters

In the newly recreated SRv6 locator and SRv6 SIDs, following changes were done:

  • Locator Block Length (BL) changed from 48 to 32 (line 23)
  • Locator Node Length (NL) changed from 0 to 16. This change is implicit, without explicit configuration: SRv6 prefix length (line 22) minus BL (line 23)
  • Function Length (FL) changed from 16 to 32 (line 24)
  • Maximum static SRv6 SID entries changed from 216-1 (32767) to 232-1 (2147483647), so that first half of the extended (32-bit) function space is available to static SRv6 SIDs (line 25)
  • SRv6 SIDs for VPN 20 and VPN 30 were extended to span across 32 bits (lines 6-7 and 16)

With these changes, let’s check how the transposition works:

1       root@PE12> show route advertising-protocol bgp 2001:db8:bad:cafe::1 detail | match "entry|label|SRv6|inet"
2       
3       RI-VRF20.inet.0: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden)
4       * 20.12.92.0/24 (1 entry, 1 announced)
5            VPN Label: 32
6                       SRv6 SID: fc01:0:12:400:: Behavior: 19 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
7       * 192.168.20.12/32 (1 entry, 1 announced)
8            VPN Label: 32
9                       SRv6 SID: fc01:0:12:400:: Behavior: 19 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
10      * 192.168.20.92/32 (1 entry, 1 announced)
11           VPN Label: 32
12                      SRv6 SID: fc01:0:12:400:: Behavior: 19 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
13      
14      RI-VRF30.inet.0: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden)
15      * 30.12.92.0/24 (1 entry, 1 announced)
16           VPN Label: 48
17                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
18      * 192.168.30.12/32 (1 entry, 1 announced)
19           VPN Label: 48
20                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
21      * 192.168.30.92/32 (1 entry, 1 announced)
22           VPN Label: 48
23                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
24      
25      RI-VRF20.inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
26      * 2001:db8:abba:20::12/128 (1 entry, 1 announced)
27           VPN Label: 32
28                      SRv6 SID: fc01:0:12:600:: Behavior: 18 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
29      * 2001:db8:abba:20::92/128 (1 entry, 1 announced)
30           VPN Label: 32
31                      SRv6 SID: fc01:0:12:600:: Behavior: 18 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
32      * 2001:db8:babe:face:20:0:1292:0/112 (1 entry, 1 announced)
33           VPN Label: 32
34                      SRv6 SID: fc01:0:12:600:: Behavior: 18 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
35      
36      RI-VRF30.inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
37      * 2001:db8:abba:30::12/128 (1 entry, 1 announced)
38           VPN Label: 48
39                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
40      * 2001:db8:abba:30::92/128 (1 entry, 1 announced)
41           VPN Label: 48
42                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60
43      * 2001:db8:babe:face:30:0:1292:0/112 (1 entry, 1 announced)
44           VPN Label: 48
45                      SRv6 SID: fc01:0:12:4600:: Behavior: 20 BL: 32 NL: 16 FL: 32 AL: 0 TL: 20 TO: 60

CLI-Output 7: Transposition with non-standard SRv6 locator parameters

As you can see, new BL/NL/FL parameters are taken into account. When it comes to transposition, 20 bits (TL=20) starting from bit 60 (TO=60) are placed in the label space in the L3VPN NLRI, and corresponding bits in SRv6 SID are set to ‘0’.

Let’s have a closer look at the transposition process here. The useful information in the SRv6 SID is carried in the first (starting from the most significant bit, i.e., from the left side) 80 bits (BL=32 + NL=16 + FL=32 --> 80). Label space available in the L3VPN NLRI is 20 bits. Therefore, out of 80 bits of SRv6 SID (out of 32 bits in the function part), only last 20 bits are moved to the label space in the L3VPN NLRI, as depicted in Figure 3.

Figure 3: SRv6 Transposition example 1

Therefore, if FL is longer than 20 bits, and Function varies not only within last 20 bits, like in the example used in this blog and depicted in Figure 4:

Figure 4: SRv6 Transposition example 2

Then, resulting SRv6 SID value carried in the SRv6 Service Sub-TLV, even after Transposition of last 20 bits, will vary as well. These NRLIs will not be subject to optimized BGP packing.

SRv6 implementations that do not support Transposition (do not support SRv6 SID Structure Sub-Sub-TLV), like for example Junos version 22.2 or earlier, may interpret, when receiving an SRv6-based BGP NLRI, the part of the SRv6 SID encoded in an MPLS Label field as MPLS label, and not as part (last 20 ‘useful’ bits) of SRv6 SID. Therefore, to allow smooth interoperability between SRv6 implementations supporting and SRv6 implementations not supporting SRv6 SID Structure Sub-Sub-TLV, you might consider following approach:

  • use large, more than 20 bits, e.g., 32 bits, Function field
  • assign Function values in such a way, that last 20 bits are always ‘0’, and Function varies only in remaining Function bits

In this way, Transposed bits will have ‘0’ value, thus the part of SRv6 SID carried in the SRv6 Service Sub-TLV will contain all useful SID bits, and the receiver, even if not using bits from the MPLS label field, will construct proper SRv6 SID. This is outlined in Figure 5.

Figure 5: SRv6 Function allocation scheme for enhanced interoperability

This will of course result in not optimized BGP packing. But, there is no free lunch!

When assigning the values to Locator block, node or function, we can further divide these fields into smaller chunks, encoding different thigs. For example, we could encode network hierarchy (i.e., aggregation domain ID, access domain ID, etc.), or we could have some indication of Flex-Algo ID (Flex-Algo will be discussed in some future blog), etc. Therefore, before SRv6 is introduced, it is important to make proper design for SRv6 locators and SIDs, as the changes in SRv6 locator properties, like BL/NL/FL/AL, are traffic affecting (SRv6 locator/SIDs must be removed, and in the next commit must be recreated with new parameters).

In the next blog we will show an interesting use case, showing guaranteed link slicing with SRv6, where Function field is further divided to carry Slice ID and VPN ID.

Useful links

Glossary

  • AL: Argument Length
  • BGP: Border Gateway Protocol
  • BL: Block Length
  • CE: Customer Edge
  • CLI: Command Line Interface
  • EVPN: Ethernet Virtual Private Network
  • FL: Function Length
  • iBGP: internal Border Gateway Protocol
  • IPv4: Internet Protocol version 4
  • IPv6: Internet Protocol version 6
  • IS-IS: Intermediate System to Intermediate System
  • L3VPN: Layer 3 Virtual Private Network
  • LIB: Label Information Base
  • MED: Multi-Exit Discriminator
  • MPLS: Multiprotocol Label Switching
  • NL: Node Length
  • NLRI: Network Layer Reachability Information
  • P: Provider
  • PE: Provider Edge
  • RFC: Request for Comments
  • RPD: Routing Protocol Daemon
  • RR: Route Reflector
  • SAFI: Subsequent Address Family Identifier
  • SID: Segment Identifier
  • SRv6: Segment Routing version 6
  • TL: Transposition Length
  • TLV: Type Length Value
  • TO: Transposition Offset
  • VPN: Virtual Private Network
  • VRF: Virtual Routing and Forwarding

Acknowledgements

Thanks to Anton Elita for thorough review, and Abhishek Murali for preparing JCL and vLabs topologies.

Feedback

Revision History

Version Author(s) Date Comments
1 Krzysztof Szarkowicz December 2022 Initial publication


#SolutionsandTechnology


#Routing

Permalink