idnits 2.17.1 draft-mirsky-6man-unified-id-sr-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 September 2021) is 937 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 199 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-17 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network C. Weiqiang 3 Internet-Draft China Mobile 4 Intended status: Standards Track G. Mirsky 5 Expires: 29 March 2022 Ericsson 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 G. Mishra 10 Verizon Inc. 11 25 September 2021 13 Unified Identifier in IPv6 Segment Routing Networks 14 draft-mirsky-6man-unified-id-sr-10 16 Abstract 18 Segment Routing architecture leverages the paradigm of source 19 routing. It can be realized in a network data plane by prepending 20 the packet with a list of instructions, a.k.a. segments. A segment 21 can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 22 address, or IPv6 address. Segment Routing can be applied in the MPLS 23 data plane by encoding segments in the MPLS label stack. It also can 24 be applied to the IPv6 data plane by encoding a list of segment 25 identifiers in IPv6 Segment Routing Extension Header (SRH). This 26 document extends the use of the SRH to unified segment identifiers 27 encoded, for example, as MPLS label or IPv4 address, to compress the 28 SRH, and support more detailed network programming and interworking 29 between SR-MPLS and SRv6 domains. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 29 March 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Conventions used in this document . . . . . . . . . . . . 3 66 1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 68 2. Segment Routing Extension Header: Benefits and Challenges . . 4 69 3. Unified SIDs in IPv6 Segment Routing Extension Header . . . . 4 70 4. Operations with Unified Segment Identifier . . . . . . . . . 6 71 4.1. Procedures of 32bits MPLS Label within SRH . . . . . . . 7 72 4.1.1. Packet Forwarding Based on UET-MPLS U-SID . . . . . . 8 73 4.2. Procedures of 32bits IP Address within SRH . . . . . . . 9 74 4.2.1. Packet Forwarding Based on UET-32 U-SID . . . . . . . 10 75 5. The Use Case of Unified Segment Identifier . . . . . . . . . 11 76 5.1. Nesting Interworking Between SR-MPLS and SRv6 Using Binding 77 U-SID . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2. Flat Interworking Between Different UET Domains Using 79 Mixing U-SID . . . . . . . . . . . . . . . . . . . . . . 15 80 5.2.1. UET Capability Advertisement . . . . . . . . . . . . 15 81 5.2.2. SRv6 SID Allocated per UEC . . . . . . . . . . . . . 16 82 5.2.3. Packets Forwarding Procedures . . . . . . . . . . . . 17 83 6. Control Plane in Support of Unified SID . . . . . . . . . . . 21 84 7. SRH with U-SID Pseudo-code . . . . . . . . . . . . . . . . . 22 85 8. U-SID supporting SRv6 programming . . . . . . . . . . . . . . 23 86 9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 10. Implementation Considerations . . . . . . . . . . . . . . . . 24 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 90 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 91 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 92 15. Normative References . . . . . . . . . . . . . . . . . . . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction 97 Segment Routing architecture [RFC8402] leverages the paradigm of 98 source routing. It can be realized in a network data plane by 99 prepending the packet with a list of instructions, a.k.a. segment 100 identifiers (SIDs). A segment can be encoded as a Multi-Protocol 101 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 102 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 103 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 104 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 105 Extension Header (SRH) [RFC8754]. 107 This document extends the use of the SRH [RFC8754] to unified 108 identifiers encoded as MPLS label or IPv4 address to support more 109 detailed network programming and interworking between SR-MPLS and 110 SRv6 domains. 112 1.1. Conventions used in this document 114 1.1.1. Acronyms 116 SR: Segment Routing 118 SRH: Segment Routing Extension Header 120 MPLS: Multiprotocol Label Switching 122 SR-MPLS: Segment Routing using MPLS data plane 124 SID: Segment Identifier 126 IGP: Interior Gateway Protocol 128 DA: Destination Address 130 ILM: Incoming Label Map 132 FEC: Forwarding Equivalence Class 134 FTN: FEC-to-NHLFE map 136 OAM: Operation, Administration, and Maintenance 138 TE: Traffic Engineering 140 SRv6: Segment Routing in IPv6 142 U-SID: Unified Segment Identifier 143 PSP: Penultimate Segment Popping 145 FIB: Forwarding Information Base 147 UET: U-SID Encapsulation Type 149 UEC: U-SID Encapsulation Capability 151 1.1.2. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2. Segment Routing Extension Header: Benefits and Challenges 161 Many functions related to Operation, Administration, and Maintenance 162 (OAM) require identification of the SR tunnel ingress and the path, 163 constructed by segments, between the ingress and the egress SR nodes. 164 Combination of IPv6 encapsulation [RFC8200] and SRH [RFC8754], 165 referred to as SRv6, comply with these requirements while it is 166 challenging when applying SR in MPLS networks, also referred to as 167 SR-MPLS. 169 On the other hand, the size of IPv6 SID presents a scaling challenge 170 to use topological instructions that define strict explicit traffic- 171 engineered (TE) path or support network programming in combination 172 with service-based instructions. At the same time, that is where SR- 173 MPLS approach provides better results due to the smaller SID length. 174 It can be used to compress the SRv6 header size when a smaller 175 namespace of available SIDs is sufficient for addressing the 176 particular network. 178 SR-MPLS is broadly used in metro networks. With the gradual 179 deployment of SRv6 in the core networks, supporting interworking 180 between SR-MPLS and SRv6 becomes necessary for operators. It is 181 operationally more efficient and straightforward if SRv6 can use the 182 same size SIDs as in SR-MPLS. The SRH can be extended to define the 183 same, as in SR-MPLS, SID length to support the unified segment 184 identifier (U-SID). As a result, end-to-end SR tunnel may use U-SIDs 185 across SR-MPLS and SRv6 domains. 187 3. Unified SIDs in IPv6 Segment Routing Extension Header 189 SRH format has been defined in Section 3 of [RFC8754] as presented in 190 Figure 1 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Last Entry | Flags | Tag | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 | Segment List[0] (128 bits IPv6 address) | 200 | | 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 | | 205 ... 206 | | 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | Segment List[n] (128 bits IPv6 address) | 211 | | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 // // 215 // Optional Type Length Value objects (variable) // 216 // // 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: SRH format 221 This document defines a new field Size in the SRH Flags field as a 222 two-bits field, termed as UET (U-SID Encapsulation Type) flag, to 223 indicate which type of SIDs are encoded in SRH. The UET flag has the 224 following values: 226 0b00 - indicate a 128-bits SID, an IPv6 address, termed as UET-128 227 U-SID. 229 0b01 - indicate a 32-bits SID, termed as UET-32 U-SID. In some 230 environments, the context could be of IPv4 address, while in some 231 other cases, it could represent an index of list or range of IPv4/ 232 IPv6 addresses. Another interpretation of 32-bits SID could be as 233 a complementary element of an IPv4/IPv6 prefix. Setting the 234 interpretation might be made through the control plane-based 235 signaling and is outside the scope of this document. If this SID 236 represents a complementary part of an IPv4/IPv6 prefix, the 237 original IP address can be re-constructed by using, for example, 238 mapping, stitching, shifting, or translating operation. 239 Specification of such a mechanism is outside the scope of this 240 document. 242 0b10 - indicate a 32-bits SID, termed as UET-MPLS U-SID, which 243 includes an MPLS label in the leftmost 20-bits as displayed in 244 Figure 2. Information in the Context field could be interpreted 245 as a flavor of a particular network programming behavior. 246 Specification of the network programming using this type of U-SID 247 is outside the scope of this document. [Ed.note. Replace with 248 reference to the U-SID network programming document.] 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | MPLS Label | Context | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: Format of Unified SID with MPLS Label 258 0b11 - indicate a 16-bits SID, termed as UET-16 U-SID. It is 259 similar to 32bits SID and suitable for scenes with higher 260 compression efficiency 262 This document also introduces a compatible operation on Segment Left 263 field, also termed as SRH.SL. The relationship between the value of 264 SRH.UET and the interpretation of the SRH.SL is as follows: 266 * if SRH.UET Flag is UET-128, SRH.SL represents the count of 267 128bits-SID entries in SRH; 269 * if SRH.UET Flag is UET-32 or UET-MPLS, SRH.SL represents the count 270 of 32bits-SID entries in SRH; 272 * if SRH.UET Flag is UET-16, SRH.SL represents the count of 16bits- 273 SID entries in SRH. 275 4. Operations with Unified Segment Identifier 277 When SRH is used to include 32-bits long U-SIDs, the ingress and 278 transit nodes of an SR tunnel act as described in Section 5.1 and 279 Section 5.2 of [RFC8754] respectively. 281 4.1. Procedures of 32bits MPLS Label within SRH 283 This section describes how the UET-MPLS type of U-SID is used to 284 encode a compressed SRH. In this case, an ILM (Incoming Label Map) 285 entry can be used to map a U-SID to an IPv6 address. As a result, it 286 is not necessary to introduce a new type of index-based mapping 287 table. For the ILM entry of Adjacency-SID, the mapping result copied 288 to DA (Destination Address) is the remote interface IPv6 address. 289 For the ILM entry of Node-SID, the mapping result copied into DA is a 290 remote node loopback IPv6 address. 292 Operations on an MPLS label of U-SID type are the same as those 293 defined in [RFC8663]. However, SR-MPLS over SRH has the following 294 advantages compared with SR-MPLS over UDP: 296 * SRH is flexible to extend flags or sub-TLVs for service 297 requirements, but not in the case of SR-MPLS over UDP. 299 * Labels in SRH can meet 8 bytes alignment requirements as per 300 [RFC8200], but not in the case of SR-MPLS over UDP. 302 * The source address and the complete path information of the SR 303 policy are not discarded, but not in the case of SR-MPLS over UDP. 305 * The forwarding performance of SR-MPLS over SRH is better than the 306 UDP method because it only updates the destination address rather 307 than frequently removing and adding outer headers. 309 Procedures of SR-MPLS over IP of [RFC8663] described how to construct 310 an adjusted SR-MPLS FTN (FEC-to-NHLFE map) and ILM entry towards a 311 prefix-SID when next-hops are IP-only routers. The action of FTN and 312 ILM entry will steer the packet along an outer tunnel to the 313 destination node that has originated the FEC (Forwarding Equivalence 314 Class). UDP header is removed and put again at each segment 315 endpoint. However, for SR-MPLS over SRH in this document, the 316 proposed solution is not dependent on adjusted FIB (Forwarding 317 Information Base) entry. That is because no action is needed to get 318 from the FIB entry. A traditional ILM entry (maybe without out-label 319 because of IP-only next-hop) is enough to get the FEC information, 320 i.e., map a U-SID to an IPv6 address and copy to DA. Note that an 321 implementation can get FEC and next-hop/interface forwarding 322 information from the ILM entry, avoiding extra FIB lookup. An SRv6 323 policy chosen to encapsulate the U-SID list within SRH is determined 324 at the ingress node of this SRv6 policy. The SRH is preserved along 325 the SR to the egress. However, in the case of PSP (Penultimate 326 Segment Popping), the behavior is different from SR-MPLS over IP/UDP 327 method [RFC8663], so the source address (i.e., the ingress of the 328 SRv6 policy) is not discarded. 330 4.1.1. Packet Forwarding Based on UET-MPLS U-SID 332 The packet forwarding based on UET-MPLS U-SID is similar to the 333 processing described in [RFC8663]. But it differs from that in FIB 334 action and segment list processing. For completeness, we repeat the 335 description of [RFC8663] with modification as follows. 337 +-----+ +-----+ +-----+ +-----+ +-----+ 338 | A +-------+ B +-------+ C +--------+ D +--------+ H | 339 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 340 | | | 341 | | | 342 +--+--+ +--+--+ +--+--+ 343 | E +-------+ F +--------+ G | 344 +-----+ +-----+ +-----+ 346 +--------+ +--------+ +--------+ 347 |IP(A->E)| |IP(A->G)| |IP(A->G)| 348 +--------+ +--------+ +--------+ 349 |SRH | |SRH | |SRH |(or PSP) 350 | SL:2 | | SL:1 | | SL:0 | 351 | L(E) | | L(E) | | L(E) | 352 | L(G) | | L(G) | | L(G) | 353 | L(H) | | L(H) | | L(H) | 354 +--------+ +--------+ +--------+ 355 | Packet | ---> | Packet | ---> | Packet | 356 +--------+ +--------+ +--------+ 358 Figure 3: Packet Forwarding Example with UET-MPLS U-SID 360 In the example shown in Figure 3, assume that routers A, E, G, and H 361 are U-SID capable (i.e., both SR-MPLS and SRv6 capable) while the 362 remaining routers (B, C, D, and F) are only capable of forwarding IP 363 packets. Routers A, E, G, and H advertise their Segment Routing 364 related information via IS-IS or OSPF. 366 Now assume that router A (the Domain ingress) wants to send a packet 367 to router H (the Domain egress) via an SRv6 policy with the explicit 368 path {E->G->H}. Router A will impose an MPLS label stack within SRH 369 on the packet corresponding to the explicit path. Router A searches 370 ILM entry by the top label (that indicated router E), get the FEC 371 information and next-hop/interface forwarding information, a loopback 372 IPv6 address of E, and then copies to DA and sends the packet. 373 SRH.UET is set to UET-MPLS and the value of SRH.SL is 2. 375 When the IPv6 packet arrives at router E, router E picks the next 376 segment (label) within SRH based on the SRH.SL value of 2, searches 377 ILM entry by the next label, get the FEC information and next-hop/ 378 interface forwarding information, a loopback IPv6 address of G, and 379 then copy to DA and sends the packet. SRH.UET is set to UET-MPLS, 380 and the value of SRH.SL is 1. 382 When the IPv6 packet arrives at router G, router G gets the next 383 segment (label) within SRH based on the SRH.SL value of 1, then looks 384 up ILM entry by the next label, gets the FEC information and next- 385 hop/interface forwarding information, a loopback IPv6 address of H, 386 and then copies it to IP DA and transmits the packet. Because the 387 value of SRH.SL is 0; the SRH can be removed if the behavior flavor 388 codepoint of the above next segment (label) is set to PSP. 390 4.2. Procedures of 32bits IP Address within SRH 392 This section describes how the UET-32 type of U-SID is used to encode 393 a compressed SRH. 395 [RFC6554] specifies the Source Routing Header (to avoid confusion 396 with Segment Routing Header, we call it SRH3 according to type 3) for 397 use strictly between RPL (Routing Protocol for Low-Power and Lossy 398 Networks) routers in the same RPL routing domain. It introduces 399 mechanisms to compact the source route entries when all entries share 400 the same prefix with the IPv6 Destination Address of a packet 401 carrying an SRH. For each entry in Address[1..n] within the Routing 402 header, the shared prefix octets are not carried, but only a shorter 403 truncated piece of the original 128bits. During packet forwarding, 404 the shorter entry gets one by one and restored to the original IPv6 405 address. The Segment Left field represents the number of segments 406 remaining, i.e., the number of explicitly listed intermediate nodes 407 still to be visited before reaching the final destination, not the 408 number of 128bits entries. 410 The described above mechanism, introduced in SRH3, could also be 411 brought to Segment Routing Header (SRH). However, unlike in SRH3, 412 using explicit fields within the Routing header to indicate the 413 number of prefix octets common with the IPv6 Destination Address, 414 this document introduces a new Flavor for Endpoint Behavior, defined 415 in [RFC8986], termed as UET Flavor, for SRv6 SIDs. The UET Flavor of 416 the current active SID indicates the next SID's compressed length 417 within SRH, thus preparing the next SID of the corresponding length. 419 The UET Flavor information of a SID can be stored in the local SID 420 entry of that SID. 422 This section defines the following two UET Flavors for Endpoint 423 Behavior: 425 UET-32 Flavor: a SID with UET-32 Flavor means in SRH that the next 426 SID is a 32bits IPv4 address or number. 428 UET-16 Flavor: a SID with UET-16 Flavor means in SRH that the next 429 SID is a 16bits address or number. 431 For the convenience of expression, we can use UET-128 Flavor for the 432 case when the next SID is a traditional 128bits IPv6 address. Note 433 that UET-128 Flavor is not defined in the document. 435 An SRv6 SID MUST NOT have multiple UET Flavors at the same time. 437 4.2.1. Packet Forwarding Based on UET-32 U-SID 439 This section describes the packet forwarding based on UET-32 U-SID. 440 For UET-16 U-SID, it is similar. 442 +-----+ +-----+ +-----+ +-----+ +-----+ 443 | A +-------+ B +-------+ C +--------+ D +--------+ H | 444 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 445 | | | 446 | | | 447 +--+--+ +--+--+ +--+--+ 448 | E +-------+ F +--------+ G | 449 +-----+ +-----+ +-----+ 451 +--------+ +--------+ +--------+ 452 |IP(A->E)| |IP(A->G)| |IP(A->G)| 453 +--------+ +--------+ +--------+ 454 |SRH | |SRH | |SRH | 455 | SL:2 | | SL:1 | | SL:0 | 456 | 32-H | | 32-H | | 32-H | 457 | 32-G | | 32-G | | 32-G | 458 | 32-E | | 32-E | | 32-E | 459 +--------+ +--------+ +--------+ 460 | Packet | ---> | Packet | ---> | Packet | 461 +--------+ +--------+ +--------+ 463 Figure 4: Packet Forwarding Example with UET-32 U-SID 465 In the example shown in Figure 4, assume that routers A, E, G, and H 466 are U-SID capable while the remaining routers (B, C, D, and F) are 467 only capable of forwarding IP packets. Routers A, E, G, and H 468 advertise their Segment Routing related information via IS-IS or 469 OSPF, especially SRv6 SIDs with SID structure and UET-32 Flavor 470 information. 472 Suppose that router A allocates an END SID B:32-A::, router E 473 allocates an END SID B:32-E::, router G allocates an END SID 474 B:32-G::, and router H allocates an END SID B:32-H::. All these SIDs 475 have the same SID structure, i.e., share the same common prefix B 476 (also known as the SRv6 SID Locator Block), and the sum of the Node 477 Length, Function Length, Argument Length of each SID are the same. 479 Now assume that router A (the Domain ingress) wants to send a packet 480 to router H (the Domain egress) via an SRv6 policy with the explicit 481 path {E->;G->H}. Router A will impose a UET-32 U-SID stack within SRH 482 on the packet that corresponds to that explicit path. The U-SID 483 stack consists of three shorter 32bits UET-32 U-SIDs, which are 32-E, 484 32-G, 32-H. Router A gets the first U-SID 32-E from SRH and restores 485 it to the original IPv6 address B:32-E::, then copy it to DA and 486 sends the packet according to IPv6 FIB lookup. SRH.UET is initially 487 set to UET-32 and the value of SRH.SL is 2. 489 When the IPv6 packet arrives at router E, match the local SID entry 490 of B:32-E::. Router E get the next U-32 32-G within SRH based on the 491 SRH.SL value of 2, and restore it to the original IPv6 address 492 B:32-G::, then copy it to DA and sends the packet according to IPv6 493 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 1. 495 When the IPv6 packet arrives at router G, match the local SID entry 496 of B:32-G::. Router G gets the next U-32 32-H within SRH based on the 497 SRH.SL value of 1, and restore it to the original IPv6 address 498 B:32-H::, then copy it to DA and sends the packet according to IPv6 499 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 0. 500 The SRH can be removed if the local SID entry of B:32-G:: has PSP 501 Flavor. 503 When the IPv6 packet arrives at router H, match the local SID entry 504 of B:32-H:: and Proceed to process the next header in the packet. 506 5. The Use Case of Unified Segment Identifier 508 In addition to being used for compression, U-SID can also be used in 509 interworking between SR-MPLS and SRv6 domains. SR-MPLS is often used 510 in a metro network, for example, in the backhaul metro network of 511 CMCC. If the core network uses SRv6, for example, the core network 512 of the same operator, U-SID can be used in the SRv6 domain to 513 interwork with SR-MPLS in the metro network to form an end-to-end SR 514 policy or tunnel. 516 5.1. Nesting Interworking Between SR-MPLS and SRv6 Using Binding U-SID 518 SR-MPLS uses SR SIDs as MPLS labels in the MPLS stack, and the SIDs 519 are 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, 520 and the SIDs are 128-bits long. 522 The type UET-MPLS of U-SID uses the same 32-bits long SIDs in the 523 MPLS stack and SRH. Thus, four 32-bits long U-SIDs can be placed in 524 the space of a single 128-bits long header. The encapsulation is 525 illustrated in Figure 5. 527 +---------+ +----------------------------------+ 528 | | | IPv6 header | 529 | Ethernet| +----------------------------------+ 530 | | | SRH | 531 +---------+ +----------------------------------+ 532 | USID1 | | USID1 | USID2 | ... | USID4 | 533 +---------+ +----------------------------------+ 534 | USID2 | | USID5 |... | USIDn | Null | 535 +---------+ +----------------------------------+ 536 | ... | + Payload | 537 +---------+ +----------------------------------+ 538 | USIDn | 539 +---------+ 540 | Payload | 541 +---------+ 543 Figure 5: 32-bits long U-SIDs Encapsulation 545 This document RECOMMENDS using Binding SID for interworking because 546 Binding SID allows hiding the difference between U-SID types of 547 different domains Additionally, a headend with only classical SRv6 548 SRH encapsulation capability, i.e., no capability to put multiple 549 short U-SIDs to a single 128bits entry, will not need to upgrade. 551 Although Binding SID that is allocated for the specific SR policy 552 instance will bring more states on some domain border nodes, the SR 553 policy instance itself maybe pre-exist due to other requirements. 554 The SR policy is created within each UET domain that can be upgraded 555 separately. 557 To interwork, an MPLS Binding SID could be allocated for an SRv6 558 policy, used to hide the details of the UET-128 domain (classical 559 SRv6) for a traditional MPLS Label stack. Similarly, an SRv6 Binding 560 SID could be allocated for an SR-MPLS policy, used to hide the UET- 561 MPLS domain's details for a conventional SRv6 SRH. An SRv6 Binding 562 SID allocated for an SRv6 policy that enables the UET-32 compression 563 style will hide the details of the UET-32 domain for a traditional 564 SRv6 SRH. There may be other combinations that are not discussed in 565 the document. 567 Note that in some cases, Binding SID will cause multiple SRH to be 568 inserted in the IPv6 header. 570 The SR-MPLS and SRv6 interworking is illustrated in Figure 6. An 571 end-to-end SR path from A to F crosses the SR-MPLS and SRv6 domains. 572 The SR-MPLS domain could be using the IPv4 or IPv6 address family. 573 The SRv6 border nodes (E/G) receive SR-MPLS packets and forward them 574 into the SRv6 domain using an SR-MPLS Binding SID [RFC8660]. 576 +-----+ +-----+ +-----+ +-----+ 577 | A +-----------+ B +-----------+ E +-----------+ F | 578 +-----+ +--+--+ +--+--+ +--+--+ 579 | SR-MPLS | | SRv6 | 580 | | | | 581 +-----+ +--+--+ +--+--+ +--+--+ 582 | C |-----------| D +-----------+ G +-----------+ H | 583 +-----+ +-----+ +-----+ +-----+ 585 +--------------+ 586 | Eth(E->G) | 587 +--------------+ +--------------+ 588 | Eth(A->B) | |IPv6 DA:G.intf| 589 +--------------+ +--------------+ +--------------+ 590 | USID(B) | | Eth(B->E) | |SRH | 591 +--------------+ +--------------+ |NH:MPLS SL:2| 592 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 593 +--------------+ +--------------+ |USID(ADJ G->H)| 594 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 595 +--------------+ +--------------+ +--------------+ 596 |Label(service)| |Label(service)| |Label(service)| 597 +--------------+ +--------------+ +--------------+ 598 | Payload | -> | Payload | -> | Payload | 599 +--------------+ +--------------+ +--------------+ 601 Figure 6: SR-MPLS and SRv6 interworking 603 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 604 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 605 policy (from E to F, via segment list E-G-H-F) with U-SID 606 encapsulation. At the headend A, the end-to-end segment list could 607 be B-E1-E2. Figure 3 demonstrates an example of the packet 608 forwarding, where U-SID is an MPLS label. 610 The reverse interworking is illustrated in Figure 7. An end-to-end 611 SR path from F to A crosses the SRv6 and SR-MPLS domains. The SRv6 612 border nodes (E/G) receive SRv6 packets and forward them into the SR- 613 MPLS domain using an SR-MPLS Binding SID or normal Prefix/Adjacency 614 SID. 616 +-----+ +-----+ +-----+ +-----+ 617 | A +-----------+ B +-----------+ E +-----------+ F | 618 +-----+ +--+--+ +--+--+ +--+--+ 619 | SR-MPLS | | SRv6 | 620 | | | | 621 +-----+ +--+--+ +--+--+ +--+--+ 622 | C |-----------| D +-----------+ G +-----------+ H | 623 +-----+ +-----+ +-----+ +-----+ 625 +--------------+ 626 | Eth(F->H) | 627 +--------------+ 628 |IPv6 DA:H.intf| 629 +--------------+ 630 |SRH | 631 |NH:MPLS SL:2| 632 |USID(ADJ F->H)| 633 +--------------+ |USID(ADJ H->G)| 634 | Eth(E->B) | |USID(ADJ G->E)| 635 +--------------+ +--------------+ +--------------+ 636 | Eth(B->A) | | USID(B) | | USID(B) | 637 +--------------+ +--------------+ +--------------+ 638 | USID(A) | | USID(A) | | USID(A) | 639 +--------------+ +--------------+ +--------------+ 640 |Label(service)| |Label(service)| |Label(service)| 641 +--------------+ +--------------+ +--------------+ 642 | Payload | <- | Payload | <- | Payload | 643 +--------------+ +--------------+ +--------------+ 645 Figure 7: SR-MPLS and SRv6 reverse interworking 647 The SRv6 edge node F assigns an SR-MPLS Binding-SID F2, which 648 represents an SRv6 policy (from F to E, via segment list F-H-G-E) 649 with U-SID encapsulation. At the headend F, the end-to-end segment 650 list could be F2-B-A. 652 5.2. Flat Interworking Between Different UET Domains Using Mixing U-SID 654 U-SRH can provide a different interworking scheme to support an end- 655 to-end SR tunnel or policy using a mixing type of U-SIDs if more 656 headend nodes have been upgraded to support encapsulating mixing 657 U-SID in SRH. For example, a SID list could contain some 128bits 658 classical SIDs, some 32bits U-SIDs (IP or Label), and some 16bits 659 U-SIDs at the same time. For this purpose, each U-SID in SRH must 660 meet the alignment requirement. For example, a UET-32 U-SID is 661 stored in a 4-byte alignment, and a UET-16 U-SID is stored in a 662 2-byte alignment. 664 The interworking of different UET domains is illustrated in Figure 8. 665 An end-to-end SR tunnel or policy from S to D with segment list , crosses the UET-128 domain, UET-32 domain and 667 UET-MPLS domain. Note that any order of UET domains is also possible 668 and is similar to the case displayed in Figure 8. 670 ...................... .................... ..................... 671 : : : : : : 672 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 673 | S +-----+ X +-----+ABR1+-----+ Y +-----+ABR2+-----+ Y +-----+ D | 674 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 675 : : : : : : 676 ........UET-128....... .......UET-32....... .......UET-MPLS...... 678 Figure 8: Interworking between different UET SID 680 5.2.1. UET Capability Advertisement 682 In an SRv6 network, each node can configure its U-SID Encapsulation 683 Capability (UEC), and advertise it to other nodes. A controller can 684 collect UEC information of all nodes. Typical UEC is: 686 UEC-128: Support classical 128bits SRv6 SID, which is the default 687 capability of an SRv6 node. 689 UEC-32: Support shorter 32bits IPv4 address or number. 691 UEC-MPLS: Support shorter 32bits MPLS label. 693 UEC-16: Support shorter 16bits number. 695 Each node can support one or more UECs. Refer to Figure 8, node S/X/ 696 ABR1 can configure to support UEC-128 capability, node ABR1/Y/ABR2 697 can configure to support UEC-32 capability, and node ABR2/Y/D can 698 configure to support UEC-MPLS capability. 700 A UET domain is constructed by several connected SRv6 nodes with the 701 same UEC. For example, a UET-128 domain is constructed by the 702 connected nodes all with UEC-128. 704 5.2.2. SRv6 SID Allocated per UEC 706 An SRv6 SID is allocated per UEC. For example, an SRv6 Node can 707 allocate different END SIDs each for UEC-128, UEC-32, UEC-MPLS, etc. 709 The local SID entry of each SRv6 SID allocated per UEC will 710 explicitly have the specific UET Flavor attribute information. 712 In addition to the two UET Flavors, i.e., UET-32 and UET-16 Flavors 713 that is defined in Section 4.2, below is described a third UET Flavor 714 for SRv6 SID: 716 UET-MPLS Flavor: a SID with UET-MPLS Flavor means in SRH the next 717 SID is a 32bits MPLS label. 719 Each node allocates its SRv6 SID per UEC and advertises it to other 720 nodes with additional UET-Flavor. A controller can collect these 721 SIDs to be used for E2E SID List programming. 723 To save label resources, an MPLS label is not allocated per UEC. 724 Relevant UET-Flavor information can be directly inserted in the 725 context field of the label item in SRH. However, to meet the SRH 726 processing restrictions defined in [RFC8754], it is possible to 727 allocate MPLS labels for some of the topology-related SRv6 SIDs, 728 which will consume more label resources. 730 Refer to the scenario presented in Figure 8, where each node may 731 allocate the following SRv6 SID per UEC. 733 Node S: 128bits-END-SID-S for UEC-128. 735 Node X: 128bits-END-SID-X for UEC-128. 737 Node ABR1: 128bits-END-SID-ABR1 for UEC-128, and 128bits-END-SID- 738 ABR1' for UEC-32. 740 Node Y: 128bits-END-SID-Y for UEC-32. 742 Node ABR2: 128bits-END-SID-ABR2 for UEC-32, and 128bits-END-SID- 743 ABR2' for UEC-MPLS. 745 Node Z: 32bits-PREFIX-SID-Z. Note that MPLS Label allocation is 746 independent with UEC. 748 Node D: 32bits-PREFIX-SID-D. Note that MPLS Label allocation is 749 independent with UEC. 751 Note that the above SRv6 SID itself is always a 128bits IPv6 address, 752 with no relationship with its UET Flavor attribute. The UET Flavor 753 attribute indicates the next SID type, i.e., 128bits classical SID, 754 32bits IPv4 address, or 32bits MPLS Label, etc. 756 5.2.3. Packets Forwarding Procedures 758 Consider that the controller computes an E2E segment list . 761 For the above E2E segment list, the controller knows which UET domain 762 does each segment node belongs to, especially that ABR1 and ABR2 are 763 the border nodes between different UET domains. Controller will 764 select appropriate SID with specific UET Flavor attribute to indicate 765 the UET domain which the next SID belongs to, i.e., whether the next 766 SID is a classical IPv6 address or a shorter truncated value. 768 The SID list informed to headend could be: 770 FSU: First SID UET, which indicates the compression result of the 771 first SID, in this example, is set to UET-128. 773 No.1 SID: 128bits-END-SID-X (with BL|TL info of itself, and 774 UET-128 Flavor to indicate the compression result of the next SID) 776 No.2 SID: 128bits-END-SID-ABR1' (with BL|TL info of itself, and 777 UET-32 Flavor to indicate the compression result of the next SID) 779 No.3 SID: 128bits-END-SID-Y (with BL|TL info of itself, and UET-32 780 Flavor to indicate the compression result of the next SID) 782 No.4 SID: 128bits-END-SID-ABR2' (with BL|TL info of itself, and 783 UET-MPLS Flavor to indicate the compression result of the next 784 SID) 786 No.5 SID: 32bits-PREFIX-SID-Z, (with UET-MPLS Flavor to indicate 787 the compression result of the next SID) 789 No.6 SID: 32bits-PREFIX-SID-D, (with UET-128 Flavor to indicate 790 the compression result of the next SID) 792 Note: 794 FSU indicates the compression result of the first SRv6 SID itself, 795 while the UET Flavor attribute of the first SID just indicates the 796 compression result of the second SRv6 SID. 798 BL is the Block Length of SRv6 SID. TL is the Truncated Length of 799 SRv6 SID, i.e., the compression result. 801 The headend analysis of how to get the compressed SID List: 803 FSU is UET-128, so the first SID 128bits-END-SID-X uses 128 bits. 805 The No.1 SID, 128bits-END-SID-X, has UET-128 Flavor, which means the 806 next SID, 128bits-END-SID-ABR1', also needs to use 128 bits. 808 The No.2 SID, 128bits-END-SID-ABR1' has UET-32 Flavor, which means 809 the next SID, 128bits-END-SID-Y, needs to be compressed as 32 bits 810 IPv4 address. 812 The No.3 SID, 128bits-END-SID-Y, has UET-32 Flavor, which means the 813 next SID, 128bits-END-SID-ABR2', needs to be compressed as 32 bits 814 IPv4 address. 816 The No.4 SID, 128bits-END-SID-ABR2', has UET-MPLS Flavor, which means 817 the next SID, 32bits-PREFIX-SID-Z, needs to use 32 bits. 819 The No.5 SID, 32bits-PREFIX-SID-Z, has UET-MPLS Flavor, which means 820 the next SID, 32bits-PREFIX-SID-D, needs to use 32 bits. 822 The No.6 SID, 32bits-PREFIX-SID-D, has UET-128 Flavor, which means 823 the next SID, maybe a VPN service SRv6 SID, needs to use 128 bits. 825 Note that in some cases, an overlay VPN service SRv6 SID could be 826 compressed. At that time, the last SID within the underlay segment 827 list may select the UET-32 or UET-16 Flavor attribute. 829 Thus, the headend can get the following compressed SID List: 831 128 bits-END-SID-X with UET-128 Flavor 833 128 bits-END-SID-ABR1' with UET-32 Flavor 835 32 bits of 128 bits-END-SID-Y with UET-32 Flavor 837 32 bits of 128 bits-END-SID-ABR2' with UET-MPLS Flavor 839 32 bits-PREFIX-SID-Z (with UET-MPLS Flavor in context.field) 841 32 bits-PREFIX-SID-D (with UET-128 Flavor context.field) 843 At the However, to meet the SRH processing restrictions defined in 844 [RFC8754], it is possible to allocate MPLS labels for some of the 845 topology-related SRv6 SIDs, which will consume more label 846 resources.At the headend, the encapsulated SRH could be: 848 0 1 2 3 849 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Last Entry | Flags |UET| | Tag | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 855 ~ 128bits VPN-SID ~ SN1 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 857 | 32bits-PREFIX-SID-D (with UET-128 in context.field) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | 32bits-PREFIX-SID-Z (with UET-MPLS in context.field) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SN2 861 | 32bits of 128bits-END-SID-ABR2' with UET-MPLS | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | 32bits of 128bits-END-SID-Y with UET-32 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 865 ~ 128bits-END-SID-ABR1' with UET-32 ~ SN3 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 867 ~ 128bits-END-SID-X with UET-128 ~ SN4 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 869 // // 870 // Optional Type Length Value objects (variable) // 871 // // 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Figure 9: SRH including different UET SID 876 The initial SRH.SL is set to 4: the number of 128bits based SIDs in 877 SRH, and the initial SRH.UET is set to UET-128, according to FSU, 878 which represents the first UET domain. 880 During the process of packets passing through multiple UET domains, 881 if SRH.UET change from UET-128 to UET-32 or UET-MPLS, SRH.SL will 882 quadruple, i.e., SRH.SL = SRH.SL * 4, which is the number of 32bits 883 based SIDs in SRH. When SRH.UET changed from UET-32 or UET-MPLS to 884 UET-128, SRH.SL will revert to its original size, i.e., SRH.SL = 885 SRH.SL / 4, which is the number of 128bits based SIDs in SRH. 887 Similarly, when SRH.UET changes from UET-128 to UET-16, SRH.SL = 888 SRH.SL * 8, from UET-32 to UET-16, SRH.SL = SRH.SL * 2, vice versa. 890 Refer to Figure 8, next we will describe the process of packets 891 passing through each UET domain. 893 Before transmitting packets to segment node 1 (SN1) X, the headend S 894 decrements SRH.SL by one and gets the first 128bits SID from 895 SRH.List[], 128bits-END-SID-X with UET-128. Then copies to DA, and 896 then the lookups up FIB to where send the packet. Now, the SRH.SL 897 value is 3 and SRH.UET is UET-128. 899 At the SN1 X, the local SID matches the DA and has the UET-128 Flavor 900 attribute. Hence, SRH.UET has not changed. It decrements SRH.SL by 901 one, gets the next 128bits SID from SRH.List[], 128bits-END-SID-ABR1' 902 with UET-32, copies the value to DA, and then looks up FIB to where 903 to send the packet. At this time, SRH.SL is 2 and SRH.UET is UET- 904 128. 906 At the SN2 ABR1, the local SID matches the DA has UET-32 Flavor 907 attribute. Hence, SRH.UET has changed from UET-128 to UET-32. Tne 908 node will firstly calculate SRH.SL * 4, then decrement SRH.SL by 1, 909 get the next 32bits SID from SRH.List[], 32bits of 128bits-END-SID-Y 910 with UET-32, convert it to a complete IPv6 SID, copy to DA, and 911 lookup FIB to send packets. At this time, SRH.SL is 7 and SRH.UET is 912 UET-32. 914 At the SN3 Y, the local SID matches the DA has UET-32 Flavor 915 attribute. Thus, SRH.UET has not changed. The node will decrement 916 SRH.SL by 1, get the next 32bits SID from SRH.List[], 32bits of 917 128bits-END-SID-ABR2' with UET-MPLS, convert it to a complete IPv6 918 SID, copy to DA, and lookup FIB to send packets. At this time, 919 SRH.SL is 6, SRH.UET is UET-32. 921 At the SN4 ABR2, the local SID matches the DA has UET-MPLS Flavor 922 attribute. Hence, SRH.UET has changed from UET-32 to UET-MPLS. 923 Because the size of SID has not changed, the node will decrement 924 SRH.SL by 1, get the next 32bits SID from SRH.List[], 32bits-PREFIX- 925 SID-Z (with UET-MPLS in context.field), map it to a complete IPv6 926 prefix FEC by ILM entry, copy to DA, and lookup FIB (or directly get 927 forwarding information from ILM entry) to send packets. Note that 928 the UET information in the context.field needs to be compared with 929 the value in SRH.UET. Since values are equal no change and no 930 additional processing. At this time, SRH.SL is 5, SRH.UET is 0b02. 932 At the SN5 Z, the address route entry matches the DA and has no UET 933 Flavor attribute. As a result, SRH.UET has not changed. The node 934 decrements SRH.SL by 1, will get the next 32bits SID from SRH.List[], 935 32bits-PREFIX-SID-D (with UET-128 in context.field), map it to a 936 complete IPv6 prefix FEC by ILM entry, copy to DA, and lookup FIB (or 937 directly get forwarding information from ILM entry) to send packets. 939 Note that the UET information in context.field needs to be compared 940 to SRH.UET. Because it is changed from UET-MPLS to UET-128, the 941 SRH.SL will be reverted to its original size, i.e., let SRH.SL / 4. 942 At this time, SRH.SL is 1, SRH.UET is UET-128. 944 At the SN6 D, the address route entry matched by DA has no associated 945 UET Flavor attribute. Hence, SRH.UET has not changed. The node 946 decrements SRH.SL by 1, will get the next 128bits SID from 947 SRH.List[], 128bits VPN-SID, and follow the rest process described in 948 [RFC8986]. 950 6. Control Plane in Support of Unified SID 952 The introduction of the Unified Identifier may rely on the existing 953 SR extensions to the routing protocols. But some enhancements in the 954 control plane are still required. This section analyzes control 955 plane protocols and identifies necessary extensions. 957 Each node in the SRv6 domain needs to advertise its U-SID 958 Encapsulation Capability, this information can be carried within 959 SRv6-Capabilities sub-TLV defined in 960 [I-D.ietf-lsr-isis-srv6-extensions] and SRv6 Capabilities TLV defined 961 in [I-D.ietf-lsr-ospfv3-srv6-extensions]. It need also allocate SRv6 962 SID (Topology type and Service Function type) per UEC and advertise 963 to other nodes, the advertisement of SRv6 END SID, END.X SID, LAN 964 END.X SID defined in [I-D.ietf-lsr-isis-srv6-extensions] and 965 [I-D.ietf-lsr-ospfv3-srv6-extensions] need to be extended to carry 966 UET-Flavor information. This information can be collected and sent 967 to the central controller through BGP-LS. The controller then can 968 send the computed segment list to the headend through BGP or PCEP, 969 and each segment will include explicit UET Flavor information. The 970 detailed procedures are outside the scope of this document. 972 The SR-MPLS extensions to Interior Gateway Protocols (IGP), IS-IS 973 [RFC8667], OSPF [RFC8665], and OSPFv3 [RFC8666], defined how 20-bits 974 and 32-bits SIDs advertised and bound to SR objects and/or 975 instructions. Extensions to BGP Link-state address family [RFC9085] 976 enabled propagation of segment information of variable length via 977 BGP. Already defined SR-MPLS extensions can be used to get MPLS 978 U-SID mapping FIB entry, and it can coexist with SRv6 extensions to 979 the same IGP/BGP-LS instance. For simplicity, this document suggests 980 using the existing mature SR-MPLS control plane and FIB entry for the 981 MPLS U-SID advertisement and mapping entry. However, it is possible 982 to base it on SRv6 related TLVs/sub-TLVs to advertise the MPLS U-SID. 983 It is outside the scope of this specification and will be discussed 984 in another document. 986 7. SRH with U-SID Pseudo-code 988 Processing of SRH with U-SID is demonstrated in the following pseudo- 989 code: 991 Headend sending packet: 993 S01. set initial SRH.UET, respond to the FSU, i.e., 994 the compressed result of the first SID; 995 S02. set initial SRH.SL, it is the count of 128bits-based SIDs; 996 S03. if (SRH.UET == UET-128) { 997 S04. SRH.SL --; 998 S05. Get SRH.List[SRH.SL], 128bits, copy to IPv6 Header DA; Or, 999 headend know the first SID before SRH encapsulation, 1000 just copy it to DA. 1001 S06. FIB lookup according to DA, and forward packet; 1002 S07. } 1003 S08. else if (SRH.UET == UET-32) { 1004 S09. SRH.SL = SRH.SL * 4; 1005 S10. SRH.SL --; 1006 S11. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 1007 to IPv6 Header DA; Or, headend know the first SID before SRH 1008 encapsulation, just copy it to DA; 1009 S12. FIB lookup according to DA, and forward packet; 1010 S13. } 1011 S14. else if (SRH.UET == UET-MPLS) { 1012 S15. SRH.SL = SRH.SL * 4; 1013 S16. SRH.SL --; 1014 S17. Get SRH.List[SRH.SL], 32bits, lookup ILM entry and map it to 128 1015 IPv6 address, copy it to IPv6 Header DA; Or, headend know 1016 the first SID before SRH encapsulation, just copy it to DA; 1017 S18. FIB lookup according to DA, or directly get forwarding 1018 information from ILM entry and forward packet; 1019 S19. } 1020 S20. else if (SRH.UET == UET-16) { 1021 S21. SRH.SL = SRH.SL * 8; 1022 S22. SRH.SL --; 1023 S23. Get SRH.List[SRH.SL], 16bits, convert to 128bits SRv6 SID, copy 1024 to IPv6 Header DA; Or, headend know the first SID before SRH 1025 encapsulation, just copy it to DA; 1026 S24. FIB lookup based on DA and forward packet; 1027 S25. } 1029 Transit/Egress receive packets: 1031 S01. If DA matched local SID entry, copy the UET attr of local SID entry 1032 to SRH.UET, check when SRH.UET changed from UET-128 to UET-32 or 1033 UET-MPLS, SRH.SL*4, when from UET-32 or UET-MPLS to UET-128, 1034 SRH.SL / 4, similar treatment of UET-16 related SRH.SL update; 1035 Else If DA matched normal address route entry, 1036 SRH.UET no update; 1037 S02. if (SRH.SL == 0) { 1038 S03. process the inner payload; 1039 S04. } 1040 S05. else { 1041 S06. if (SRH.UET == UET-128) { 1042 S07. SRH.SL -- ; 1043 S08. Get SRH.List[SRH.SL], 128bits, copy it to IPv6 Header DA; 1044 S09. FIB lookup based on DA and forward packet; 1045 S10. } 1046 S11. else if (SRH.UET == UET-32) { 1047 S12. SRH.SL -- ; 1048 S13. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 1049 to IPv6 Header DA; 1050 S14. FIB lookup based on DA and forward packet; 1051 S15. } 1052 S16. else if (SRH.UET == UET-MPLS) { 1053 S17. SRH.SL -- 1054 S18. Get SRH.List[SRH.SL], 32bits, lookup ILM entry, map it to 1055 128bits IPv6 address, copy it to IPv6 Header DA; 1056 S19. Get UET info from SRH.List[SRH.SL] Context Field, copy it to 1057 SRH.UET. Check if SRH.UET changed from UET-MPLS to UET-128, 1058 SRH.SL/4; 1059 S20. FIB lookup according to DA, or, directly get forwarding 1060 information from ILM entry, and forward packet; 1061 S21. } 1062 S22. else if (SRH.UET == UET-16) { 1063 S23. SRH.SL -- ; 1064 S24. Get SRH.List[SRH.SL], 16bits, convert to 128bits SRv6 SID, copy 1065 to IPv6 Header DA; 1066 S25. FIB lookup based on DA and forward packet; 1067 S26. } 1068 S27. } 1070 8. U-SID supporting SRv6 programming 1072 U-SID can support SRv6 programming defined by [RFC8986]. The details 1073 will be described in another document. 1075 9. Benefits 1077 To be discussed in the next version. 1079 10. Implementation Considerations 1081 The Unified SID solution has been already implemented and tested by 1082 two companies: 1084 * Centec has conducted its PoC, and the report is available at 1085 https://cloud.tencent.com/developer/article/1540023. 1087 * Broadcom, in its lab, also conducted PoC testing of the U-SID 1088 solution. 1090 11. IANA Considerations 1092 IANA is requested to allocate the two-bits long field from the 1093 Segment Routing Header Flags registry referred to as Size. 1095 12. Security Considerations 1097 This specification inherits all security considerations of [RFC8402] 1098 and [RFC8754]. 1100 13. Contributors 1101 Wan Xiaolan 1102 New H3C Technologies Co. Ltd 1103 No.8, Yongjia Road, Haidian District 1104 Beijing 1105 China 1107 Email: wxlan@h3c.com 1109 Cheng Wei 1110 Centec 1111 Building B, No.5 Xing Han Street, Suzhou Industrial Park 1112 Suzhou 1113 China 1115 Email: Chengw@centecnetworks.com 1117 S.Zadok 1118 Broadcom 1119 Israel 1121 Email: shay.zadok@broadcom.com 1123 14. Acknowledgements 1125 TBD 1127 15. Normative References 1129 [I-D.ietf-lsr-isis-srv6-extensions] 1130 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1131 Z. Hu, "IS-IS Extensions to Support Segment Routing over 1132 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 1133 ietf-lsr-isis-srv6-extensions-17, 18 June 2021, 1134 . 1137 [I-D.ietf-lsr-ospfv3-srv6-extensions] 1138 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 1139 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 1140 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-02, 15 1141 February 2021, . 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, 1146 DOI 10.17487/RFC2119, March 1997, 1147 . 1149 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1150 Routing Header for Source Routes with the Routing Protocol 1151 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1152 DOI 10.17487/RFC6554, March 2012, 1153 . 1155 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1156 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1157 May 2017, . 1159 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1160 (IPv6) Specification", STD 86, RFC 8200, 1161 DOI 10.17487/RFC8200, July 2017, 1162 . 1164 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1165 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1166 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1167 July 2018, . 1169 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1170 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1171 Routing with the MPLS Data Plane", RFC 8660, 1172 DOI 10.17487/RFC8660, December 2019, 1173 . 1175 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 1176 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 1177 DOI 10.17487/RFC8663, December 2019, 1178 . 1180 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1181 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1182 Extensions for Segment Routing", RFC 8665, 1183 DOI 10.17487/RFC8665, December 2019, 1184 . 1186 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1187 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1188 December 2019, . 1190 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1191 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1192 Extensions for Segment Routing", RFC 8667, 1193 DOI 10.17487/RFC8667, December 2019, 1194 . 1196 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1197 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1198 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1199 . 1201 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1202 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1203 (SRv6) Network Programming", RFC 8986, 1204 DOI 10.17487/RFC8986, February 2021, 1205 . 1207 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 1208 H., and M. Chen, "Border Gateway Protocol - Link State 1209 (BGP-LS) Extensions for Segment Routing", RFC 9085, 1210 DOI 10.17487/RFC9085, August 2021, 1211 . 1213 Authors' Addresses 1215 Cheng Weiqiang 1216 China Mobile 1217 Beijing, 1218 China 1220 Email: chengweiqiang@chinamobile.com 1222 Greg Mirsky 1223 Ericsson 1225 Email: gregimirsky@gmail.com 1227 Peng Shaofu 1228 ZTE Corporation 1229 No.50 Software Avenue, Yuhuatai District 1230 Nanjing, 1231 China 1233 Email: peng.shaofu@zte.com.cn 1234 Liu Aihua 1235 ZTE Corporation 1236 Zhongxing Industrial Park, Nanshan District 1237 Shenzhen, 1238 China 1240 Email: liu.aihua@zte.com.cn 1242 Gyan S. Mishra 1243 Verizon Inc. 1244 13101 Columbia Pike 1245 Silver Spring, MD 20904 1246 United States of America 1248 Phone: 301 502-1347 1249 Email: gyan.s.mishra@verizon.com