idnits 2.17.1 draft-mirsky-6man-unified-id-sr-09.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 (30 March 2021) is 1116 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 857 -- Looks like a reference, but probably isn't: '1' on line 862 -- Looks like a reference, but probably isn't: '2' on line 867 -- Looks like a reference, but probably isn't: '3' on line 869 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-17 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: 1 October 2021 ZTE Corp. 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 G. Mishra 10 Verizon Inc. 11 30 March 2021 13 Unified Identifier in IPv6 Segment Routing Networks 14 draft-mirsky-6man-unified-id-sr-09 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 MPLS 23 data plane by encoding segments in the MPLS label stack. It also can 24 be applied to 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 1 October 2021. 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 Domain Using Mixing 79 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. t 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. The setting of 234 the 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 ILM entry of Adjacency-SID, the mapping result copied to 288 DA (Destination Address) is the remote interface IPv6 address, for 289 ILM entry of Node-SID, the mapping result that is 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 UDP not. 299 * Labels in SRH can meet 8 bytes alignment requirements as per 300 [RFC8200], but UDP not. 302 * The source address and the complete path information of the SR 303 policy are not discarded, but UDP not. 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, we don't 316 try to depend on that adjusted FIB (Forwarding Information Base) 317 entry, because there are not any actions needed to get from the FIB 318 entry, a traditional ILM entry (maybe without out-label because of 319 IP-only next-hop) is enough to get the FEC information, i.e., to map 320 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, SRH is preserved along the 325 SR to egress, though PSP (Penultimate Segment Popping) may be used, 326 that is different from SR-MPLS over IP/UDP method [RFC8663], so the 327 source address (i.e., the ingress of the SRv6 policy) is not 328 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 that corresponds to that explicit path. Router A 370 searches ILM entry by the top label (that indicated router E), get 371 the FEC information and next-hop/interface forwarding information, a 372 loopback IPv6 address of E, and then copy 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, looks up 384 ILM entry by the next label, gets the FEC information and next-hop/ 385 interface forwarding information, a loopback IPv6 address of H, and 386 then copies it to IP DA and transmits the packet. Because the value 387 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 above described 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 [I-D.ietf-spring-srv6-network-programming], termed as UET Flavor, 416 for SRv6 SIDs. The UET Flavor of the current active SID indicates 417 the next SID's compressed length within SRH, thus preparing the next 418 SID of the corresponding length. 420 The UET Flavor information of a SID can be stored in the local SID 421 entry of that SID. 423 This section defines the following two UET Flavors for Endpoint 424 Behavior: 426 UET-32 Flavor: a SID with UET-32 Flavor means in SRH that the next 427 SID is a 32bits IPv4 address or number. 429 UET-16 Flavor: a SID with UET-16 Flavor means in SRH that the next 430 SID is a 16bits address or number. 432 For the convenience of expression, we can use UET-128 Flavor for the 433 case when the next SID is a traditional 128bits IPv6 address. Note 434 that UET-128 Flavor is not defined in the document. 436 An SRv6 SID MUST NOT have multiple UET Flavors at the same time. 438 4.2.1. Packet Forwarding Based on UET-32 U-SID 440 This section describes the packet forwarding based on UET-32 U-SID. 441 For UET-16 U-SID, it is similar. 443 +-----+ +-----+ +-----+ +-----+ +-----+ 444 | A +-------+ B +-------+ C +--------+ D +--------+ H | 445 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 446 | | | 447 | | | 448 +--+--+ +--+--+ +--+--+ 449 | E +-------+ F +--------+ G | 450 +-----+ +-----+ +-----+ 452 +--------+ +--------+ +--------+ 453 |IP(A->E)| |IP(A->G)| |IP(A->G)| 454 +--------+ +--------+ +--------+ 455 |SRH | |SRH | |SRH | 456 | SL:2 | | SL:1 | | SL:0 | 457 | 32-H | | 32-H | | 32-H | 458 | 32-G | | 32-G | | 32-G | 459 | 32-E | | 32-E | | 32-E | 460 +--------+ +--------+ +--------+ 461 | Packet | ---> | Packet | ---> | Packet | 462 +--------+ +--------+ +--------+ 464 Figure 4: Packet Forwarding Example with UET-32 U-SID 466 In the example shown in Figure 4, assume that routers A, E, G, and H 467 are U-SID capable while the remaining routers (B, C, D, and F) are 468 only capable of forwarding IP packets. Routers A, E, G, and H 469 advertise their Segment Routing related information via IS-IS or 470 OSPF, especially SRv6 SIDs with SID strucuture and UET-32 Flavor 471 information. 473 Suppose that router A allocates an END SID B:32-A::, router E 474 allocates an END SID B:32-E::, router G allocates an END SID 475 B:32-G::, and router H allocates an END SID B:32-H::. All these SIDs 476 have the same SID structure, i.e., share the same common prefix B 477 (also known as the SRv6 SID Locator Block), and the sum of the Node 478 Length, Function Length, Argument Length of each SID are the same. 480 Now assume that router A (the Domain ingress) wants to send a packet 481 to router H (the Domain egress) via an SRv6 policy with the explicit 482 path {E->;G->H}. Router A will impose a UET-32 U-SID stack within SRH 483 on the packet that corresponds to that explicit path. The U-SID 484 stack consists of three shorter 32bits UET-32 U-SIDs, which are 32-E, 485 32-G, 32-H. Router A gets the first U-SID 32-E from SRH and restores 486 it to the original IPv6 address B:32-E::, then copy it to DA and 487 sends the packet according to IPv6 FIB lookup. SRH.UET is initially 488 set to UET-32 and the value of SRH.SL is 2. 490 When the IPv6 packet arrives at router E, match the local SID entry 491 of B:32-E::. Router E get the next U-32 32-G within SRH based on the 492 SRH.SL value of 2, and restore it to the original IPv6 address 493 B:32-G::, then copy it to DA and sends the packet according to IPv6 494 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 1. 496 When the IPv6 packet arrives at router G, match the local SID entry 497 of B:32-G::. Router G gets the next U-32 32-H within SRH based on the 498 SRH.SL value of 1, and restore it to the original IPv6 address 499 B:32-H::, then copy it to DA and sends the packet according to IPv6 500 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 0. 501 The SRH can be removed if the local SID entry of B:32-G:: has PSP 502 Flavor. 504 When the IPv6 packet arrives at router H, match the local SID entry 505 of B:32-H:: and Proceed to process the next header in the packet. 507 5. The Use Case of Unified Segment Identifier 509 In addition to being used for compression, U-SID can also be used in 510 interworking between SR-MPLS and SRv6 domains. SR-MPLS is often used 511 in a metro network, for example, in the backhaul metro network of 512 CMCC. If the core network uses SRv6, for example, the core network 513 of the same operator, U-SID can be used in the SRv6 domain to 514 interwork with SR-MPLS in the metro network to form an end-to-end SR 515 policy or tunnel. 517 5.1. Nesting Interworking Between SR-MPLS and SRv6 Using Binding U-SID 519 SR-MPLS uses SR SIDs as MPLS label in the MPLS stack, and the SIDs 520 are 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, 521 and the SIDs are 128-bits long. 523 The type UET-MPLS of U-SID uses the same 32-bits long SIDs in MPLS 524 stack and SRH. Thus, four 32-bits long U-SIDs can be placed in the 525 space of a single 128-bits long header. The encapsulation is 526 illustrated in Figure 5. 528 +---------+ +----------------------------------+ 529 | | | IPv6 header | 530 | Ethernet| +----------------------------------+ 531 | | | SRH | 532 +---------+ +----------------------------------+ 533 | USID1 | | USID1 | USID2 | ... | USID4 | 534 +---------+ +----------------------------------+ 535 | USID2 | | USID5 |... | USIDn | Null | 536 +---------+ +----------------------------------+ 537 | ... | + Payload | 538 +---------+ +----------------------------------+ 539 | USIDn | 540 +---------+ 541 | Payload | 542 +---------+ 544 Figure 5: 32-bits long U-SIDs Encapsulation 546 This document RECOMMENDS using Binding SID for interworking because 547 Binding SID allows hiding the difference between U-SID types of 548 different domains Additionally, a headend with only classical SRv6 549 SRH encapsulation capability, i.e., no capability to put multiple 550 short U-SIDs to a single 128bits entry, will not need to upgrade. 552 Although Binding SID that is allocated for the specific SR policy 553 instance will bring more states on some domain border nodes, the SR 554 policy instance itself maybe pre-exist due to other requirements. 555 The SR policy is created within each UET domain that can be upgraded 556 separately. 558 To interwork, an MPLS Binding SID could be allocated for an SRv6 559 policy, used to hide the details of the UET-128 domain (classical 560 SRv6) for a traditional MPLS Label stack. Similarly, an SRv6 Binding 561 SID could be allocated for an SR-MPLS policy, used to hide the UET- 562 MPLS domain's details for a conventional SRv6 SRH. An SRv6 Binding 563 SID allocated for an SRv6 policy that enables the UET-32 compression 564 style will hide the details of the UET-32 domain for a traditional 565 SRv6 SRH. There may be other combinations that are not discussed in 566 the document. 568 Note that in some cases, Binding SID will cause multiple SRH to be 569 inserted in IPv6 header. 571 The SR-MPLS and SRv6 interworking is illustrated in Figure 6. An 572 end-to-end SR path from A to F crosses the SR-MPLS and SRv6 domains. 573 The SR-MPLS domain could be using IPv4 or IPv6 address family. The 574 SRv6 border nodes (E/G) receive SR-MPLS packets and forward them into 575 the SRv6 domain using an SR-MPLS Binding SID [RFC8660]. 577 +-----+ +-----+ +-----+ +-----+ 578 | A +-----------+ B +-----------+ E +-----------+ F | 579 +-----+ +--+--+ +--+--+ +--+--+ 580 | SR-MPLS | | SRv6 | 581 | | | | 582 +-----+ +--+--+ +--+--+ +--+--+ 583 | C |-----------| D +-----------+ G +-----------+ H | 584 +-----+ +-----+ +-----+ +-----+ 586 +--------------+ 587 | Eth(E->G) | 588 +--------------+ +--------------+ 589 | Eth(A->B) | |IPv6 DA:G.intf| 590 +--------------+ +--------------+ +--------------+ 591 | USID(B) | | Eth(B->E) | |SRH | 592 +--------------+ +--------------+ |NH:MPLS SL:2| 593 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 594 +--------------+ +--------------+ |USID(ADJ G->H)| 595 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 596 +--------------+ +--------------+ +--------------+ 597 |Label(service)| |Label(service)| |Label(service)| 598 +--------------+ +--------------+ +--------------+ 599 | Payload | -> | Payload | -> | Payload | 600 +--------------+ +--------------+ +--------------+ 602 Figure 6: SR-MPLS and SRv6 interworking 604 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 605 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 606 policy (from E to F, via segment list E-G-H-F) with U-SID 607 encapsulation. At the headend A, the end-to-end segment list could 608 be B-E1-E2. Figure 3 demonstrates an example of the packet 609 forwarding, where U-SID is an MPLS label. 611 The reverse interworking is illustrated in Figure 7. An end-to-end 612 SR path from F to A crosses the SRv6 and SR-MPLS domains. The SRv6 613 border nodes (E/G) receive SRv6 packets and forward them into the SR- 614 MPLS domain using an SR-MPLS Binding SID or normal Prefix/Adjacency 615 SID. 617 +-----+ +-----+ +-----+ +-----+ 618 | A +-----------+ B +-----------+ E +-----------+ F | 619 +-----+ +--+--+ +--+--+ +--+--+ 620 | SR-MPLS | | SRv6 | 621 | | | | 622 +-----+ +--+--+ +--+--+ +--+--+ 623 | C |-----------| D +-----------+ G +-----------+ H | 624 +-----+ +-----+ +-----+ +-----+ 626 +--------------+ 627 | Eth(F->H) | 628 +--------------+ 629 |IPv6 DA:H.intf| 630 +--------------+ 631 |SRH | 632 |NH:MPLS SL:2| 633 |USID(ADJ F->H)| 634 +--------------+ |USID(ADJ H->G)| 635 | Eth(E->B) | |USID(ADJ G->E)| 636 +--------------+ +--------------+ +--------------+ 637 | Eth(B->A) | | USID(B) | | USID(B) | 638 +--------------+ +--------------+ +--------------+ 639 | USID(A) | | USID(A) | | USID(A) | 640 +--------------+ +--------------+ +--------------+ 641 |Label(service)| |Label(service)| |Label(service)| 642 +--------------+ +--------------+ +--------------+ 643 | Payload | <- | Payload | <- | Payload | 644 +--------------+ +--------------+ +--------------+ 646 Figure 7: SR-MPLS and SRv6 reverse interworking 648 The SRv6 edge node F assigns an SR-MPLS Binding-SID F2, which 649 represents an SRv6 policy (from F to E, via segment list F-H-G-E) 650 with U-SID encapsulation. At the headend F, the end-to-end segment 651 list could be F2-B-A. 653 5.2. Flat Interworking Between Different UET Domain Using Mixing U-SID 655 U-SRH can provide a different interworking scheme to support an end- 656 to-end SR tunnel or policy using a mixing type of U-SIDs if more 657 headend nodes have been upgraded to support encapsulating mixing 658 U-SID in SRH. For example, a SID list could contain some 128bits 659 classical SIDs, some 32bits U-SIDs (IP or Label), and some 16bits 660 U-SIDs at the same time. For this purpose, each U-SID in SRH must 661 meet the alignment requirement. For example, a UET-32 U-SID is 662 stored in a 4-byte alignment, and a UET-16 U-SID is stored in a 663 2-byte alignment. 665 The interworking of different UET domain is illustrated in Figure 8. 666 An end-to-end SR tunnel or policy from S to D with segment list , crosses the UET-128 domain, UET-32 domain and 668 UET-MPLS domain. Note that any order of UET domains is also possible 669 and is similar to the case displayed in Figure 8. 671 ...................... .................... ..................... 672 : : : : : : 673 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 674 | S +-----+ X +-----+ABR1+-----+ Y +-----+ABR2+-----+ Y +-----+ D | 675 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 676 : : : : : : 677 ........UET-128....... .......UET-32....... .......UET-MPLS...... 679 Figure 8: Interworking between different UET SID 681 5.2.1. UET Capability Advertisement 683 In an SRv6 network, each node can configure its U-SID Encapsulation 684 Capability (UEC), and advertise it to other nodes. A controller can 685 collect UEC information of all nodes. Typical UEC is: 687 UEC-128: Support classical 128bits SRv6 SID, which is the default 688 capability of an SRv6 node. 690 UEC-32: Support shorter 32bits IPv4 address or number. 692 UEC-MPLS: Support shorter 32bits MPLS label. 694 UEC-16: Support shorter 16bits number. 696 Each node can support one or more than one UEC. Refer to Figure 8, 697 node S/X/ABR1 can configure to support UEC-128 capability, node 698 ABR1/Y/ABR2 can configure to support UEC-32 capability, and node 699 ABR2/Y/D can configure to support UEC-MPLS capability. 701 A UET domain is constructed by several connected SRv6 nodes with the 702 same UEC. For example, a UET-128 domain is constructed by the 703 connected nodes all with UEC-128. 705 5.2.2. SRv6 SID Allocated per UEC 707 An SRv6 SID is allocated per UEC. For example, an SRv6 Node can 708 allocate different END SIDs each for UEC-128, UEC-32, UEC-MPLS, etc. 710 The local SID entry of each SRv6 SID allocated per UEC will 711 explicitly have the specific UET Flavor attribute information. 713 For flat interworking between different UET domain purpose, in 714 addition to the two UET Flavors, i.e., UET-32 and UET-16 Flavors that 715 is defined in section Section 4.2, here we continue to define a third 716 UET Flavor for SRv6 SID: 718 UET-MPLS Flavor: a SID with UET-MPLS Flavor means in SRH the next 719 SID is a 32bits MPLS label. 721 Each node allocates its SRv6 SID per UEC and advertises it to other 722 nodes with additional UET-Flavor. A controller can collect these 723 SIDs to be used for E2E SID List programming. 725 To save label resources, an MPLS label is not allocated per UEC. The 726 related UET-Flavor information can be directly inserted in the 727 context field of the label item in SRH. However, to meet the SRH 728 processing restrictions defined in [RFC8754], it is possible to 729 allocate MPLS labels for some of the topology-related SRv6 SIDs, 730 which will consume more label resources. 732 Refer to the scenario presented in Figure 8, where each node may 733 allocate the following SRv6 SID per UEC. 735 Node S: 128bits-END-SID-S for UEC-128. 737 Node X: 128bits-END-SID-X for UEC-128. 739 Node ABR1: 128bits-END-SID-ABR1 for UEC-128, and 128bits-END-SID- 740 ABR1' for UEC-32. 742 Node Y: 128bits-END-SID-Y for UEC-32. 744 Node ABR2: 128bits-END-SID-ABR2 for UEC-32, and 128bits-END-SID- 745 ABR2' for UEC-MPLS. 747 Node Z: 32bits-PREFIX-SID-Z. Note that MPLS Label allocation is 748 independent with UEC. 750 Node D: 32bits-PREFIX-SID-D. Note that MPLS Label allocation is 751 independent with UEC. 753 Note that the above SRv6 SID itself is always a 128bits IPv6 address, 754 with no relationship with its UET Flavor attribute. The UET Flavor 755 attribute indicates the next SID type, i.e., 128bits classical SID, 756 32bits IPv4 address, or 32bits MPLS Label, etc. 758 5.2.3. Packets Forwarding Procedures 760 Consider that the controller computes an E2E segment list . 763 For the above E2E segment list, the controller knows which UET domain 764 does each segment node belongs to, especially that ABR1 and ABR2 are 765 the border nodes between different UET domain. Controller will 766 select appropriate SID with specific UET Flavor attribute to indicate 767 the UET domain which the next SID belongs to, i.e., whether the next 768 SID is a classical IPv6 address or a shorter truncated value. 770 The SID list informed to headend could be: 772 FSU: First SID UET, which indicates the compression resulst of the 773 first SID, in this example, it is set to UET-128. 775 No.1 SID: 128bits-END-SID-X (with BL|TL info of itself, and 776 UET-128 Flavor to indicate the compression result of the next SID) 778 No.2 SID: 128bits-END-SID-ABR1' (with BL|TL info of itself, and 779 UET-32 Flavor to indicate the compression result of the next SID) 781 No.3 SID: 128bits-END-SID-Y (with BL|TL info of itself, and UET-32 782 Flavor to indicate the compression result of the next SID) 784 No.4 SID: 128bits-END-SID-ABR2' (with BL|TL info of itself, and 785 UET-MPLS Flavor to indicate the compression result of the next 786 SID) 788 No.5 SID: 32bits-PREFIX-SID-Z, (with UET-MPLS Flavor to indicate 789 the compression result of the next SID) 791 No.6 SID: 32bits-PREFIX-SID-D, (with UET-128 Flavor to indicate 792 the compression result of the next SID) 794 Note: 796 FSU indicates the compression result of the first SRv6 SID itself, 797 while the UET Flavor attribute of the first SID just indicates the 798 compression result of the second SRv6 SID. 800 BL is the Block Length of SRv6 SID. TL is the Truncated Length of 801 SRv6 SID, i.e., the compression result. 803 The headend analysis of how to get the compressed SID List. 805 FSU is UET-128, so the first SID 128bits-END-SID-X keep 128bits. 807 The No.1 SID, 128bits-END-SID-X, has UET-128 Flavor, which means the 808 next SID, 128bits-END-SID-ABR1', also needs to keep 128bits. 810 The No.2 SID, 128bits-END-SID-ABR1' has UET-32 Flavor, which means 811 the next SID, 128bits-END-SID-Y, needs to be compressed as 32bits 812 IPv4 address. 814 The No.3 SID, 128bits-END-SID-Y, has UET-32 Flavor, which means the 815 next SID, 128bits-END-SID-ABR2', needs to be compressed as 32bits 816 IPv4 address. 818 The No.4 SID, 128bits-END-SID-ABR2', has UET-MPLS Flavor, which means 819 the next SID, 32bits-PREFIX-SID-Z, needs to keep 32bits. 821 The No.5 SID, 32bits-PREFIX-SID-Z, has UET-MPLS Flavor, which means 822 the next SID, 32bits-PREFIX-SID-D, needs to keep 32bits. 824 The No.6 SID, 32bits-PREFIX-SID-D, has UET-128 Flavor, which means 825 the next SID, maybe a VPN service SRv6 SID, needs to keep 128bits. 827 Note that in some cases, an overlay VPN service SRv6 SID could be 828 compressed. At that time, the last SID within the underlay segment 829 list may select the one with UET-32 or UET-16 Flavor attribute. 831 Thus, the headend can get the following compressed SID List: 833 128bits-END-SID-X with UET-128 Flavor 835 128bits-END-SID-ABR1' with UET-32 Flavor 837 32bits of 128bits-END-SID-Y with UET-32 Flavor 839 32bits of 128bits-END-SID-ABR2' with UET-MPLS Flavor 841 32bits-PREFIX-SID-Z (with UET-MPLS Flavor in context.field) 843 32bits-PREFIX-SID-D (with UET-128 Flavor context.field) 845 At the However, to meet the SRH processing restrictions defined in 846 [RFC8754], it is possible to allocate MPLS labels for some of the 847 topology-related SRv6 SIDs, which will consume more label 848 resources.At the headend, the encapsulated SRH could be: 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Last Entry | Flags |UET| | Tag | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 ~ 128bits VPN-SID ~ [0] 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 859 | 32bits-PREFIX-SID-D (with UET-128 in context.field) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | 32bits-PREFIX-SID-Z (with UET-MPLS in context.field) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [1] 863 | 32bits of 128bits-END-SID-ABR2' with UET-MPLS | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | 32bits of 128bits-END-SID-Y with UET-32 | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 867 ~ 128bits-END-SID-ABR1' with UET-32 ~ [2] 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 869 ~ 128bits-END-SID-X with UET-128 ~ [3] 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 // // 872 // Optional Type Length Value objects (variable) // 873 // // 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Figure 9: SRH including different UET SID 878 The initial SRH.SL is set to 4: the number of 128bits based SIDs in 879 SRH, and the initial SRH.UET is set to UET-128, according to FSU, 880 which represents the first UET domain. 882 During the process of packets passing through multiple UET domains, 883 if SRH.UET change from UET-128 to UET-32 or UET-MPLS, SRH.SL will 884 quadruple, i.e., SRH.SL = SRH.SL * 4, which is the number of 32bits 885 based SIDs in SRH. When SRH.UET changed from UET-32 or UET-MPLS to 886 UET-128, SRH.SL will revert to its original size, i.e., SRH.SL = 887 SRH.SL / 4, which is the number of 128bits based SIDs in SRH. 889 Similarly, when SRH.UET change from UET-128 to UET-16, SRH.SL = 890 SRH.SL * 8, from UET-32 to UET-16, SRH.SL = SRH.SL * 2, vice versa. 892 Refer to Figure 8, next we will describe the process of packets 893 passing through each UET domain. 895 At the headend S, when packets sent to the No.1 segment node X, it 896 will decrement SRH.SL by 1, get the first 128bits SID from 897 SRH.List[], 128bits-END-SID-X with UET-128, copy to DA, and lookup 898 FIB to send packets. Now, SRH.SL is 3 and SRH.UET is UET-128. 900 At the No.1 segment node X, the local SID matches the DA and has 901 UET-128 Flavor attribute. Hence, SRH.UET has no change. It will 902 decrement SRH.SL by 1, get the next 128bits SID from SRH.List[], 903 128bits-END-SID-ABR1' with UET-32, copy to DA, and lookup FIB to send 904 packets. At this time, SRH.SL is 2 and SRH.UET is UET-128. 906 At the No.2 segment node ABR1, the local SID matches the DA has 907 UET-32 Flavor attribute. Hence, SRH.UET has changed from UET-128 to 908 UET-32. Tne node will firstly calculate SRH.SL * 4, then decrement 909 SRH.SL by 1, get the next 32bits SID from SRH.List[], 32bits of 910 128bits-END-SID-Y with UET-32, convert it to a complete IPv6 SID, 911 copy to DA, and lookup FIB to send packets. At this time, SRH.SL is 912 7 and SRH.UET is UET-32. 914 At the No.3 segment node Y, the local SID matches the DA has UET-32 915 Flavor attribute. Thus, SRH.UET has no change. The node will 916 decrement SRH.SL by 1, get the next 32bits SID from SRH.List[], 917 32bits of 128bits-END-SID-ABR2' with UET-MPLS, convert it to a 918 complete IPv6 SID, copy to DA, and lookup FIB to send packets. At 919 this time, SRH.SL is 6, SRH.UET is UET-32. 921 At the No.4 segment node ABR2, the local SID matches the DA has UET- 922 MPLS Flavor attribute. Hence, SRH.UET has changed from UET-32 to 923 UET-MPLS. Because the size of SID has no change, the node will 924 decrement SRH.SL by 1, get the next 32bits SID from SRH.List[], 925 32bits-PREFIX-SID-Z (with UET-MPLS in context.field), map it to a 926 complete IPv6 prefix FEC by ILM entry, copy to DA, and lookup FIB (or 927 directly get forwarding information from ILM entry) to send packets. 928 Note that the UET information in context.field needs to be compared 929 to SRH.UET. Since values are equal no change and no additional 930 processing. At this time, SRH.SL is 5, SRH.UET is 0b02. 932 At the No.5 segment node Z, the normal address route entry matches 933 the DA and has no UET Flavor attribute. As a result, SRH.UET has no 934 change. The node decrements SRH.SL by 1, will get the next 32bits 935 SID from SRH.List[], 32bits-PREFIX-SID-D (with UET-128 in 936 context.field), map it to a complete IPv6 prefix FEC by ILM entry, 937 copy to DA, and lookup FIB (or directly get forwarding information 938 from ILM entry) to send packets. Note that the UET information in 939 context.field needs to be compared to SRH.UET. Because it is changed 940 from UET-MPLS to UET-128, the SRH.SL will be reverted to its original 941 size, i.e., let SRH.SL / 4. At this time, SRH.SL is 1, SRH.UET is 942 UET-128. 944 At the No.6 segment node D, the normal address route entry matched by 945 DA has no associated UET Flavor attribute. Hence, SRH.UET has no 946 change. The node decrements SRH.SL by 1, will get the next 128bits 947 SID from SRH.List[], 128bits VPN-SID, and follow the rest process 948 described in [I-D.ietf-spring-srv6-network-programming]. 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 references the 955 existing 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 976 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 977 segment information of variable length via BGP. The existed SR-MPLS 978 extensions can be used to get MPLS U-SID mapping FIB entry, and it 979 can coexist with SRv6 extensions to the same IGP/BGP-LS instance. 980 For simplicity, this document suggests using the existing mature SR- 981 MPLS control plane and FIB entry for the MPLS U-SID advertisement and 982 mapping entry. However, it is possible to base it on SRv6 related 983 TLVs/sub-TLVs to advertise the MPLS U-SID, which will be discussed in 984 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 according to 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 according to 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 according to 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 according to DA, and forward packet; 1067 S26. } 1068 S27. } 1070 8. U-SID supporting SRv6 programming 1072 U-SID can support SRv6 programming defined by 1073 [I-D.ietf-spring-srv6-network-programming]. The details will be 1074 described in another document. 1076 9. Benefits 1078 To be discussed in the next version. 1080 10. Implementation Considerations 1082 The Unified SID solution has been already implemented and tested by 1083 two companies: 1085 * Centec has conducted its PoC, and the report is available at 1086 https://cloud.tencent.com/developer/article/1540023. 1088 * Broadcom, in its lab, also conducted PoC testing of the U-SID 1089 solution. 1091 11. IANA Considerations 1093 IANA is requested to allocate from the Segment Routing Header Flags 1094 registry the two-bits long field referred to as Size. 1096 12. Security Considerations 1098 This specification inherits all security considerations of [RFC8402] 1099 and [RFC8754]. 1101 13. Contributors 1102 Wan Xiaolan 1103 New H3C Technologies Co. Ltd 1104 No.8, Yongjia Road, Haidian District 1105 Beijing 1106 China 1108 Email: wxlan@h3c.com 1110 Cheng Wei 1111 Centec 1112 Building B, No.5 Xing Han Street, Suzhou Industrial Park 1113 Suzhou 1114 China 1116 Email: Chengw@centecnetworks.com 1118 S.Zadok 1119 Broadcom 1120 Israel 1122 Email: shay.zadok@broadcom.com 1124 14. Acknowledgements 1126 TBD 1128 15. Normative References 1130 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 1131 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 1132 and M. Chen, "BGP Link-State extensions for Segment 1133 Routing", Work in Progress, Internet-Draft, draft-ietf- 1134 idr-bgp-ls-segment-routing-ext-17, 21 March 2021, 1135 . 1138 [I-D.ietf-lsr-isis-srv6-extensions] 1139 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1140 Z. Hu, "IS-IS Extension to Support Segment Routing over 1141 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 1142 ietf-lsr-isis-srv6-extensions-11, 8 October 2020, 1143 . 1146 [I-D.ietf-lsr-ospfv3-srv6-extensions] 1147 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 1148 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 1149 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-02, 15 1150 February 2021, . 1153 [I-D.ietf-spring-srv6-network-programming] 1154 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 1155 Matsushima, S., and Z. Li, "Segment Routing over IPv6 1156 (SRv6) Network Programming", Work in Progress, Internet- 1157 Draft, draft-ietf-spring-srv6-network-programming-28, 29 1158 December 2020, . 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, 1163 DOI 10.17487/RFC2119, March 1997, 1164 . 1166 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1167 Routing Header for Source Routes with the Routing Protocol 1168 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1169 DOI 10.17487/RFC6554, March 2012, 1170 . 1172 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1173 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1174 May 2017, . 1176 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1177 (IPv6) Specification", STD 86, RFC 8200, 1178 DOI 10.17487/RFC8200, July 2017, 1179 . 1181 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1182 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1183 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1184 July 2018, . 1186 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1187 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1188 Routing with the MPLS Data Plane", RFC 8660, 1189 DOI 10.17487/RFC8660, December 2019, 1190 . 1192 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 1193 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 1194 DOI 10.17487/RFC8663, December 2019, 1195 . 1197 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1198 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1199 Extensions for Segment Routing", RFC 8665, 1200 DOI 10.17487/RFC8665, December 2019, 1201 . 1203 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1204 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1205 December 2019, . 1207 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1208 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1209 Extensions for Segment Routing", RFC 8667, 1210 DOI 10.17487/RFC8667, December 2019, 1211 . 1213 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1214 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1215 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1216 . 1218 Authors' Addresses 1220 Cheng Weiqiang 1221 China Mobile 1222 Beijing, 1223 China 1225 Email: chengweiqiang@chinamobile.com 1227 Greg Mirsky 1228 ZTE Corp. 1230 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 1232 Peng Shaofu 1233 ZTE Corporation 1234 No.50 Software Avenue, Yuhuatai District 1235 Nanjing, 1236 China 1237 Email: peng.shaofu@zte.com.cn 1239 Liu Aihua 1240 ZTE Corporation 1241 Zhongxing Industrial Park, Nanshan District 1242 Shenzhen, 1243 China 1245 Email: liu.aihua@zte.com.cn 1247 Gyan S. Mishra 1248 Verizon Inc. 1249 13101 Columbia Pike 1250 Silver Spring, MD 20904 1251 United States of America 1253 Phone: 301 502-1347 1254 Email: gyan.s.mishra@verizon.com