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