idnits 2.17.1 draft-mirsky-6man-unified-id-sr-08.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 (January 5, 2021) is 1179 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 859 -- Looks like a reference, but probably isn't: '1' on line 864 -- Looks like a reference, but probably isn't: '2' on line 869 -- Looks like a reference, but probably isn't: '3' on line 871 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == 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-01 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: July 9, 2021 ZTE Corp. 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 G. Mishra 10 Verizon Inc. 11 January 5, 2021 13 Unified Identifier in IPv6 Segment Routing Networks 14 draft-mirsky-6man-unified-id-sr-08 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 July 9, 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 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Conventions used in this document . . . . . . . . . . . . 3 67 1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 69 2. Segment Routing Extension Header: Benefits and Challenges . . 4 70 3. Unified SIDs in IPv6 Segment Routing Extension Header . . . . 5 71 4. Operations with Unified Segment Identifier . . . . . . . . . 6 72 4.1. Procedures of 32bits MPLS Label within SRH . . . . . . . 7 73 4.1.1. Packet Forwarding Based on UET-MPLS U-SID . . . . . . 8 74 4.2. Procedures of 32bits IP Address within SRH . . . . . . . 9 75 4.2.1. Packet Forwarding Based on UET-32 U-SID . . . . . . . 10 76 5. The Use Case of Unified Segment Identifier . . . . . . . . . 11 77 5.1. Nesting Interworking Between SR-MPLS and SRv6 Using 78 Binding U-SID . . . . . . . . . . . . . . . . . . . . . . 12 79 5.2. Flat Interworking Between Different UET Domain Using 80 Mixing U-SID . . . . . . . . . . . . . . . . . . . . . . 14 81 5.2.1. UET Capability Advertisement . . . . . . . . . . . . 15 82 5.2.2. SRv6 SID Allocated per UEC . . . . . . . . . . . . . 16 83 5.2.3. Packets Forwarding Procedures . . . . . . . . . . . . 17 84 6. Control Plane in Support of Unified SID . . . . . . . . . . . 21 85 7. SRH with U-SID Pseudo-code . . . . . . . . . . . . . . . . . 21 86 8. U-SID supporting SRv6 programming . . . . . . . . . . . . . . 23 87 9. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 10. Implementation Considerations . . . . . . . . . . . . . . . . 24 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 93 15. Normative References . . . . . . . . . . . . . . . . . . . . 25 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 96 1. Introduction 98 Segment Routing architecture [RFC8402] leverages the paradigm of 99 source routing. It can be realized in a network data plane by 100 prepending the packet with a list of instructions, a.k.a. segment 101 identifiers (SIDs). A segment can be encoded as a Multi-Protocol 102 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 103 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 104 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 105 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 106 Extension Header (SRH) [RFC8754]. 108 This document extends the use of the SRH [RFC8754] to unified 109 identifiers encoded as MPLS label or IPv4 address to support more 110 detailed network programming and interworking between SR-MPLS and 111 SRv6 domains. 113 1.1. Conventions used in this document 115 1.1.1. Acronyms 117 SR: Segment Routing 119 SRH: Segment Routing Extension Header 121 MPLS: Multiprotocol Label Switching 123 SR-MPLS: Segment Routing using MPLS data plane 125 SID: Segment Identifier 127 IGP: Interior Gateway Protocol 129 DA: Destination Address 131 ILM: Incoming Label Map 133 FEC: Forwarding Equivalence Class 135 FTN: FEC-to-NHLFE map 137 OAM: Operation, Administration and Maintenance 139 TE: Traffic Engineering 141 SRv6: Segment Routing in IPv6 143 U-SID: Unified Segment Identifier 144 PSP: Penultimate Segment Popping 146 FIB: Forwarding Information Base 148 UET: U-SID Encapsulation Type 150 UEC: U-SID Encapsulation Capability 152 1.1.2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2. Segment Routing Extension Header: Benefits and Challenges 162 Many functions related to Operation, Administration and Maintenance 163 (OAM) require identification of the SR tunnel ingress and the path, 164 constructed by segments, between the ingress and the egress SR nodes. 165 Combination of IPv6 encapsulation [RFC8200] and SRH [RFC8754], 166 referred to as SRv6, comply with these requirements while it is 167 challenging when applying SR in MPLS networks, also referred to as 168 SR-MPLS. 170 On the other hand, the size of IPv6 SID presents a scaling challenge 171 to use topological instructions that define strict explicit traffic- 172 engineered (TE) path or support network programming in combination 173 with service-based instructions. At the same time, that is where SR- 174 MPLS approach provides better results due to the smaller SID length. 175 It can be used to compress the SRv6 header size when a smaller 176 namespace of available SIDs is sufficient for addressing the 177 particular network. 179 SR-MPLS is broadly used in metro networks. With the gradual 180 deployment of SRv6 in the core networks, supporting interworking 181 between SR-MPLS and SRv6 becomes necessary for operators. t is 182 operationally more efficient and straightforward if SRv6 can use the 183 same size SIDs as in SR-MPLS. The SRH can be extended to define the 184 same as in SR-MPLS SID length to support the unified segment 185 identifier (U-SID). As a result, end-to-end SR tunnel may use U-SIDs 186 across SR-MPLS and SRv6 domains. 188 3. Unified SIDs in IPv6 Segment Routing Extension Header 190 SRH format has been defined in Section 3 of [RFC8754] as presented in 191 Figure 1 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Last Entry | Flags | Tag | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 | Segment List[0] (128 bits IPv6 address) | 202 | | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 | | 207 ... 208 | | 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 | Segment List[n] (128 bits IPv6 address) | 213 | | 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 // // 217 // Optional Type Length Value objects (variable) // 218 // // 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: SRH format 223 This document defines a new field Size in the SRH Flags field as a 224 two-bits field, termed as UET (U-SID Encapsulation Type) flag, to 225 indicate which type of SIDs are encoded in SRH. The UET flag has the 226 following values: 228 0b00 - indicate a 128-bits SID, an IPv6 address, termed as UET-128 229 U-SID. 231 0b01 - indicate a 32-bits SID, termed as UET-32 U-SID. In some 232 environments, the context could be of IPv4 address, while in some 233 other cases, it could represent an index of list or range of IPv4/ 234 IPv6 addresses. Another interpretation of 32-bits SID could be as 235 a complementary element of an IPv4/IPv6 prefix. The setting of 236 the interpretation might be made through the control plane based 237 signaling and is outside the scope of this document. If this SID 238 represents a complementary part of an IPv4/IPv6 prefix, the 239 original IP address can be re-constructed by using, for example, 240 mapping, stitching, shifting or translating operation. 241 Specification of such a mechanism is outside the scope of this 242 document. 244 0b10 - indicate a 32-bits SID, termed as UET-MPLS U-SID, which 245 includes an MPLS label in the leftmost 20-bits as displayed in 246 Figure 2. Information in the Context field could be interpreted 247 as a flavor of a particular network programming behavior. 248 Specification of the network programming using this type of U-SID 249 is outside the scope of this document. [Ed.note. Replace with 250 reference to the U-SID network programming document.] 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | MPLS Label | Context | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 2: Format of Unified SID with MPLS Label 260 0b11 - indicate a 16-bits SID, termed as UET-16 U-SID. It is 261 similar to 32bits SID and suitable for scenes with higher 262 compression efficiency 264 This document also introduces a compatible operation on Segment Left 265 field, also termed as SRH.SL. The relationship between the value of 266 SRH.UET and the interpretation of the SRH.SL is as follows: 268 o if SRH.UET Flag is UET-128, SRH.SL represents the count of 269 128bits-SID entries in SRH; 271 o if SRH.UET Flag is UET-32 or UET-MPLS, SRH.SL represents the count 272 of 32bits-SID entries in SRH; 274 o if SRH.UET Flag is UET-16, SRH.SL represents the count of 16bits- 275 SID entries in SRH. 277 4. Operations with Unified Segment Identifier 279 When SRH is used to include 32-bits long U-SIDs, the ingress and 280 transit nodes of an SR tunnel act as described in Section 5.1 and 281 Section 5.2 of [RFC8754] respectively. 283 4.1. Procedures of 32bits MPLS Label within SRH 285 This section describes how the UET-MPLS type of U-SID is used to 286 encode a compressed SRH. In this case, an ILM (Incoming Label Map) 287 entry can be used to map a U-SID to an IPv6 address. As a result, it 288 is not necessary to introduce a new type of index-based mapping 289 table. For ILM entry of Adjacency-SID, the mapping result copied to 290 DA (Destination Address) is the remote interface IPv6 address, for 291 ILM entry of Node-SID, the mapping result that is copied into DA is a 292 remote node loopback IPv6 address. 294 Operations on an MPLS label of U-SID type are the same as those 295 defined in [RFC8663]. However, SR-MPLS over SRH has the following 296 advantages compared with SR-MPLS over UDP: 298 o SRH is flexible to extend flags or sub-TLVs for service 299 requirements, but UDP not. 301 o Labels in SRH can meet 8 bytes alignment requirements as per 302 [RFC8200], but UDP not. 304 o The source address and the complete path information of the SR 305 policy are not discarded, but UDP not. 307 o The forwarding performance of SR-MPLS over SRH is better than the 308 UDP method because it only updates the destination address rather 309 than frequently removing and adding outer headers. 311 Procedures of SR-MPLS over IP of [RFC8663] described how to construct 312 an adjusted SR-MPLS FTN (FEC-to-NHLFE map) and ILM entry towards a 313 prefix-SID when next-hops are IP-only routers. The action of FTN and 314 ILM entry will steer the packet along an outer tunnel to the 315 destination node that has originated the FEC (Forwarding Equivalence 316 Class). UDP header is removed and put again at each segment 317 endpoint. However, for SR-MPLS over SRH in this document, we don't 318 try to depend on that adjusted FIB (Forwarding Information Base) 319 entry, because there are not any actions needed to get from the FIB 320 entry, a traditional ILM entry (maybe without out-label because of 321 IP-only next-hop) is enough to get the FEC information, i.e., to map 322 a U-SID to an IPv6 address and copy to DA. Note that an 323 implementation can get FEC and next-hop/interface forwarding 324 information from the ILM entry, avoiding extra FIB lookup. An SRv6 325 policy chosen to encapsulate the U-SID list within SRH is determined 326 at the ingress node of this SRv6 policy, SRH is preserved along the 327 SR to egress, though PSP (Penultimate Segment Popping) may be used, 328 that is different from SR-MPLS over IP/UDP method [RFC8663], so the 329 source address (i.e., the ingress of the SRv6 policy) is not 330 discarded. 332 4.1.1. Packet Forwarding Based on UET-MPLS U-SID 334 The packet forwarding based on UET-MPLS U-SID is similar to the 335 processing described in [RFC8663]. But it differs from that in FIB 336 action and segment list processing. For completeness, we repeat the 337 description of [RFC8663] with modification as follows. 339 +-----+ +-----+ +-----+ +-----+ +-----+ 340 | A +-------+ B +-------+ C +--------+ D +--------+ H | 341 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 342 | | | 343 | | | 344 +--+--+ +--+--+ +--+--+ 345 | E +-------+ F +--------+ G | 346 +-----+ +-----+ +-----+ 348 +--------+ +--------+ +--------+ 349 |IP(A->E)| |IP(A->G)| |IP(A->G)| 350 +--------+ +--------+ +--------+ 351 |SRH | |SRH | |SRH |(or PSP) 352 | SL:2 | | SL:1 | | SL:0 | 353 | L(E) | | L(E) | | L(E) | 354 | L(G) | | L(G) | | L(G) | 355 | L(H) | | L(H) | | L(H) | 356 +--------+ +--------+ +--------+ 357 | Packet | ---> | Packet | ---> | Packet | 358 +--------+ +--------+ +--------+ 360 Figure 3: Packet Forwarding Example with UET-MPLS U-SID 362 In the example shown in Figure 3, assume that routers A, E, G, and H 363 are U-SID capable (i.e., both SR-MPLS and SRv6 capable) while the 364 remaining routers (B, C, D, and F) are only capable of forwarding IP 365 packets. Routers A, E, G, and H advertise their Segment Routing 366 related information via IS-IS or OSPF. 368 Now assume that router A (the Domain ingress) wants to send a packet 369 to router H (the Domain egress) via an SRv6 policy with the explicit 370 path {E->G->H}. Router A will impose an MPLS label stack within SRH 371 on the packet that corresponds to that explicit path. Router A 372 searches ILM entry by the top label (that indicated router E), get 373 the FEC information and next-hop/interface forwarding information, a 374 loopback IPv6 address of E, and then copy to DA and sends the packet. 375 SRH.UET is set to UET-MPLS and the value of SRH.SL is 2. 377 When the IPv6 packet arrives at router E, router E picks the next 378 segment (label) within SRH based on the SRH.SL value of 2, searches 379 ILM entry by the next label, get the FEC information and next-hop/ 380 interface forwarding information, a loopback IPv6 address of G, and 381 then copy to DA and sends the packet. SRH.UET is set to UET-MPLS, 382 and the value of SRH.SL is 1. 384 When the IPv6 packet arrives at router G, router G gets the next 385 segment (label) within SRH based on the SRH.SL value of 1, looks up 386 ILM entry by the next label, gets the FEC information and next-hop/ 387 interface forwarding information, a loopback IPv6 address of H, and 388 then copies it to IP DA and transmits the packet. Because the value 389 of SRH.SL is 0; the SRH can be removed if the behavior flavor 390 codepoint of the above next segment (label) is set to PSP. 392 4.2. Procedures of 32bits IP Address within SRH 394 This section describes how the UET-32 type of U-SID is used to encode 395 a compressed SRH. 397 [RFC6554] specifies the Source Routing Header (to avoid confusion 398 with Segment Routing Header, we call it SRH3 according to type 3) for 399 use strictly between RPL (Routing Protocol for Low-Power and Lossy 400 Networks) routers in the same RPL routing domain. It introduces 401 mechanisms to compact the source route entries when all entries share 402 the same prefix with the IPv6 Destination Address of a packet 403 carrying an SRH. For each entry in Address[1..n] within the Routing 404 header, the shared prefix octets are not carried, but only a shorter 405 truncated piece of the original 128bits. During packet forwarding, 406 the shorter entry gets one by one and restored to the original IPv6 407 address. The Segment Left field represents the number of segments 408 remaining, i.e., the number of explicitly listed intermediate nodes 409 still to be visited before reaching the final destination, not the 410 number of 128bits entries. 412 The above described mechanism, introduced in SRH3, could also be 413 brought to Segment Routing Header (SRH). However, unlike in SRH3, 414 using explicit fields within the Routing header to indicate the 415 number of prefix octets common with the IPv6 Destination Address, 416 this document introduces a new Flavor for Endpoint Behavior, defined 417 in [I-D.ietf-spring-srv6-network-programming], termed as UET Flavor, 418 for SRv6 SIDs. The UET Flavor of the current active SID indicates 419 the next SID's compressed length within SRH, thus preparing the next 420 SID of the corresponding length. 422 The UET Flavor information of a SID can be stored in the local SID 423 entry of that SID. 425 This section defines the following two UET Flavors for Endpoint 426 Behavior: 428 UET-32 Flavor: a SID with UET-32 Flavor means in SRH that the next 429 SID is a 32bits IPv4 address or number. 431 UET-16 Flavor: a SID with UET-16 Flavor means in SRH that the next 432 SID is a 16bits address or number. 434 For the convenience of expression, we can use UET-128 Flavor for the 435 case when the next SID is a traditional 128bits IPv6 address. Note 436 that UET-128 Flavor is not defined in the document. 438 An SRv6 SID MUST NOT have multiple UET Flavors at the same time. 440 4.2.1. Packet Forwarding Based on UET-32 U-SID 442 This section describes the packet forwarding based on UET-32 U-SID. 443 For UET-16 U-SID, it is similar. 445 +-----+ +-----+ +-----+ +-----+ +-----+ 446 | A +-------+ B +-------+ C +--------+ D +--------+ H | 447 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 448 | | | 449 | | | 450 +--+--+ +--+--+ +--+--+ 451 | E +-------+ F +--------+ G | 452 +-----+ +-----+ +-----+ 454 +--------+ +--------+ +--------+ 455 |IP(A->E)| |IP(A->G)| |IP(A->G)| 456 +--------+ +--------+ +--------+ 457 |SRH | |SRH | |SRH | 458 | SL:2 | | SL:1 | | SL:0 | 459 | 32-H | | 32-H | | 32-H | 460 | 32-G | | 32-G | | 32-G | 461 | 32-E | | 32-E | | 32-E | 462 +--------+ +--------+ +--------+ 463 | Packet | ---> | Packet | ---> | Packet | 464 +--------+ +--------+ +--------+ 466 Figure 4: Packet Forwarding Example with UET-32 U-SID 468 In the example shown in Figure 4, assume that routers A, E, G, and H 469 are U-SID capable while the remaining routers (B, C, D, and F) are 470 only capable of forwarding IP packets. Routers A, E, G, and H 471 advertise their Segment Routing related information via IS-IS or 472 OSPF, especially SRv6 SIDs with SID strucuture and UET-32 Flavor 473 information. 475 Suppose that router A allocates an END SID B:32-A::, router E 476 allocates an END SID B:32-E::, router G allocates an END SID 477 B:32-G::, and router H allocates an END SID B:32-H::. All these SIDs 478 have the same SID structure, i.e., share the same common prefix B 479 (also known as the SRv6 SID Locator Block), and the sum of the Node 480 Length, Function Length, Argument Length of each SID are the same. 482 Now assume that router A (the Domain ingress) wants to send a packet 483 to router H (the Domain egress) via an SRv6 policy with the explicit 484 path {E->;G->H}. Router A will impose a UET-32 U-SID stack within 485 SRH on the packet that corresponds to that explicit path. The U-SID 486 stack consists of three shorter 32bits UET-32 U-SIDs, which are 32-E, 487 32-G, 32-H. Router A gets the first U-SID 32-E from SRH and restores 488 it to the original IPv6 address B:32-E::, then copy it to DA and 489 sends the packet according to IPv6 FIB lookup. SRH.UET is initially 490 set to UET-32 and the value of SRH.SL is 2. 492 When the IPv6 packet arrives at router E, match the local SID entry 493 of B:32-E::. Router E get the next U-32 32-G within SRH based on the 494 SRH.SL value of 2, and restore it to the original IPv6 address 495 B:32-G::, then copy it to DA and sends the packet according to IPv6 496 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 1. 498 When the IPv6 packet arrives at router G, match the local SID entry 499 of B:32-G::. Router G gets the next U-32 32-H within SRH based on 500 the SRH.SL value of 1, and restore it to the original IPv6 address 501 B:32-H::, then copy it to DA and sends the packet according to IPv6 502 FIB lookup. SRH.UET remains unchanged, and the value of SRH.SL is 0. 503 The SRH can be removed if the local SID entry of B:32-G:: has PSP 504 Flavor. 506 When the IPv6 packet arrives at router H, match the local SID entry 507 of B:32-H:: and Proceed to process the next header in the packet. 509 5. The Use Case of Unified Segment Identifier 511 In addition to being used for compression, U-SID can also be used in 512 interworking between SR-MPLS and SRv6 domains. SR-MPLS is often used 513 in a metro network, for example, in the backhaul metro network of 514 CMCC. If the core network uses SRv6, for example, the core network 515 of the same operator, U-SID can be used in the SRv6 domain to 516 interwork with SR-MPLS in the metro network to form an end-to-end SR 517 policy or tunnel. 519 5.1. Nesting Interworking Between SR-MPLS and SRv6 Using Binding U-SID 521 SR-MPLS uses SR SIDs as MPLS label in the MPLS stack, and the SIDs 522 are 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, 523 and the SIDs are 128-bits long. 525 The type UET-MPLS of U-SID uses the same 32-bits long SIDs in MPLS 526 stack and SRH. Thus, four 32-bits long U-SIDs can be placed in the 527 space of a single 128-bits long header. The encapsulation is 528 illustrated in Figure 5. 530 +---------+ +----------------------------------+ 531 | | | IPv6 header | 532 | Ethernet| +----------------------------------+ 533 | | | SRH | 534 +---------+ +----------------------------------+ 535 | USID1 | | USID1 | USID2 | ... | USID4 | 536 +---------+ +----------------------------------+ 537 | USID2 | | USID5 |... | USIDn | Null | 538 +---------+ +----------------------------------+ 539 | ... | + Payload | 540 +---------+ +----------------------------------+ 541 | USIDn | 542 +---------+ 543 | Payload | 544 +---------+ 546 Figure 5: 32-bits long U-SIDs Encapsulation 548 This document RECOMMENDS using Binding SID for interworking because 549 Binding SID allows hiding the difference between U-SID types of 550 different domains Additionally, a headend with only classical SRv6 551 SRH encapsulation capability, i.e., no capability to put multiple 552 short U-SIDs to a single 128bits entry, will not need to upgrade. 554 Although Binding SID that is allocated for the specific SR policy 555 instance will bring more states on some domain border nodes, the SR 556 policy instance itself maybe pre-exist due to other requirements. 557 The SR policy is created within each UET domain that can be upgraded 558 separately. 560 To interwork, an MPLS Binding SID could be allocated for an SRv6 561 policy, used to hide the details of the UET-128 domain (classical 562 SRv6) for a traditional MPLS Label stack. Similarly, an SRv6 Binding 563 SID could be allocated for an SR-MPLS policy, used to hide the UET- 564 MPLS domain's details for a conventional SRv6 SRH. An SRv6 Binding 565 SID allocated for an SRv6 policy that enables the UET-32 compression 566 style will hide the details of the UET-32 domain for a traditional 567 SRv6 SRH. There may be other combinations that are not discussed in 568 the document. 570 Note that in some cases, Binding SID will cause multiple SRH to be 571 inserted in IPv6 header. 573 The SR-MPLS and SRv6 interworking is illustrated in Figure 6. An 574 end-to-end SR path from A to F crosses the SR-MPLS and SRv6 domains. 575 The SR-MPLS domain could be using IPv4 or IPv6 address family. The 576 SRv6 border nodes (E/G) receive SR-MPLS packets and forward them into 577 the SRv6 domain using an SR-MPLS Binding SID [RFC8660]. 579 +-----+ +-----+ +-----+ +-----+ 580 | A +-----------+ B +-----------+ E +-----------+ F | 581 +-----+ +--+--+ +--+--+ +--+--+ 582 | SR-MPLS | | SRv6 | 583 | | | | 584 +-----+ +--+--+ +--+--+ +--+--+ 585 | C |-----------| D +-----------+ G +-----------+ H | 586 +-----+ +-----+ +-----+ +-----+ 588 +--------------+ 589 | Eth(E->G) | 590 +--------------+ +--------------+ 591 | Eth(A->B) | |IPv6 DA:G.intf| 592 +--------------+ +--------------+ +--------------+ 593 | USID(B) | | Eth(B->E) | |SRH | 594 +--------------+ +--------------+ |NH:MPLS SL:2| 595 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 596 +--------------+ +--------------+ |USID(ADJ G->H)| 597 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 598 +--------------+ +--------------+ +--------------+ 599 |Label(service)| |Label(service)| |Label(service)| 600 +--------------+ +--------------+ +--------------+ 601 | Payload | -> | Payload | -> | Payload | 602 +--------------+ +--------------+ +--------------+ 604 Figure 6: SR-MPLS and SRv6 interworking 606 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 607 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 608 policy (from E to F, via segment list E-G-H-F) with U-SID 609 encapsulation. At the headend A, the end-to-end segment list could 610 be B-E1-E2. Figure 3 demonstrates an example of the packet 611 forwarding, where U-SID is an MPLS label. 613 The reverse interworking is illustrated in Figure 7. An end-to-end 614 SR path from F to A crosses the SRv6 and SR-MPLS domains. The SRv6 615 border nodes (E/G) receive SRv6 packets and forward them into the SR- 616 MPLS domain using an SR-MPLS Binding SID or normal Prefix/Adjacency 617 SID. 619 +-----+ +-----+ +-----+ +-----+ 620 | A +-----------+ B +-----------+ E +-----------+ F | 621 +-----+ +--+--+ +--+--+ +--+--+ 622 | SR-MPLS | | SRv6 | 623 | | | | 624 +-----+ +--+--+ +--+--+ +--+--+ 625 | C |-----------| D +-----------+ G +-----------+ H | 626 +-----+ +-----+ +-----+ +-----+ 628 +--------------+ 629 | Eth(F->H) | 630 +--------------+ 631 |IPv6 DA:H.intf| 632 +--------------+ 633 |SRH | 634 |NH:MPLS SL:2| 635 |USID(ADJ F->H)| 636 +--------------+ |USID(ADJ H->G)| 637 | Eth(E->B) | |USID(ADJ G->E)| 638 +--------------+ +--------------+ +--------------+ 639 | Eth(B->A) | | USID(B) | | USID(B) | 640 +--------------+ +--------------+ +--------------+ 641 | USID(A) | | USID(A) | | USID(A) | 642 +--------------+ +--------------+ +--------------+ 643 |Label(service)| |Label(service)| |Label(service)| 644 +--------------+ +--------------+ +--------------+ 645 | Payload | <- | Payload | <- | Payload | 646 +--------------+ +--------------+ +--------------+ 648 Figure 7: SR-MPLS and SRv6 reverse interworking 650 The SRv6 edge node F assigns an SR-MPLS Binding-SID F2, which 651 represents an SRv6 policy (from F to E, via segment list F-H-G-E) 652 with U-SID encapsulation. At the headend F, the end-to-end segment 653 list could be F2-B-A. 655 5.2. Flat Interworking Between Different UET Domain Using Mixing U-SID 657 U-SRH can provide a different interworking scheme to support an end- 658 to-end SR tunnel or policy using a mixing type of U-SIDs if more 659 headend nodes have been upgraded to support encapsulating mixing 660 U-SID in SRH. For example, a SID list could contain some 128bits 661 classical SIDs, some 32bits U-SIDs (IP or Label), and some 16bits 662 U-SIDs at the same time. For this purpose, each U-SID in SRH must 663 meet the alignment requirement. For example, a UET-32 U-SID is 664 stored in a 4-byte alignment, and a UET-16 U-SID is stored in a 665 2-byte alignment. 667 The interworking of different UET domain is illustrated in Figure 8. 668 An end-to-end SR tunnel or policy from S to D with segment list , crosses the UET-128 domain, UET-32 domain and 670 UET-MPLS domain. Note that any order of UET domains is also possible 671 and is similar to the case displayed in Figure 8. 673 ...................... .................... ..................... 674 : : : : : : 675 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 676 | S +-----+ X +-----+ABR1+-----+ Y +-----+ABR2+-----+ Y +-----+ D | 677 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 678 : : : : : : 679 ........UET-128....... .......UET-32....... .......UET-MPLS...... 681 Figure 8: Interworking between different UET SID 683 5.2.1. UET Capability Advertisement 685 In an SRv6 network, each node can configure its U-SID Encapsulation 686 Capability (UEC), and advertise it to other nodes. A controller can 687 collect UEC information of all nodes. Typical UEC is: 689 UEC-128: Support classical 128bits SRv6 SID, which is the default 690 capability of an SRv6 node. 692 UEC-32: Support shorter 32bits IPv4 address or number. 694 UEC-MPLS: Support shorter 32bits MPLS label. 696 UEC-16: Support shorter 16bits number. 698 Each node can support one or more than one UEC. Refer to Figure 8, 699 node S/X/ABR1 can configure to support UEC-128 capability, node 700 ABR1/Y/ABR2 can configure to support UEC-32 capability, and node 701 ABR2/Y/D can configure to support UEC-MPLS capability. 703 A UET domain is constructed by several connected SRv6 nodes with the 704 same UEC. For example, a UET-128 domain is constructed by the 705 connected nodes all with UEC-128. 707 5.2.2. SRv6 SID Allocated per UEC 709 An SRv6 SID is allocated per UEC. For example, an SRv6 Node can 710 allocate different END SIDs each for UEC-128, UEC-32, UEC-MPLS, etc. 712 The local SID entry of each SRv6 SID allocated per UEC will 713 explicitly have the specific UET Flavor attribute information. 715 For flat interworking between different UET domain purpose, in 716 addition to the two UET Flavors, i.e., UET-32 and UET-16 Flavors that 717 is defined in section Section 4.2, here we continue to define a third 718 UET Flavor for SRv6 SID: 720 UET-MPLS Flavor: a SID with UET-MPLS Flavor means in SRH the next 721 SID is a 32bits MPLS label. 723 Each node allocates its SRv6 SID per UEC and advertises it to other 724 nodes with additional UET-Flavor. A controller can collect these 725 SIDs to be used for E2E SID List programming. 727 To save label resources, an MPLS label is not allocated per UEC. The 728 related UET-Flavor information can be directly inserted in the 729 context field of the label item in SRH. However, to meet the SRH 730 processing restrictions defined in [RFC8754], it is possible to 731 allocate MPLS labels for some of the topology-related SRv6 SIDs, 732 which will consume more label resources. 734 Refer to the scenario presented in Figure 8, where each node may 735 allocate the following SRv6 SID per UEC. 737 Node S: 128bits-END-SID-S for UEC-128. 739 Node X: 128bits-END-SID-X for UEC-128. 741 Node ABR1: 128bits-END-SID-ABR1 for UEC-128, and 128bits-END-SID- 742 ABR1' for UEC-32. 744 Node Y: 128bits-END-SID-Y for UEC-32. 746 Node ABR2: 128bits-END-SID-ABR2 for UEC-32, and 128bits-END-SID- 747 ABR2' for UEC-MPLS. 749 Node Z: 32bits-PREFIX-SID-Z. Note that MPLS Label allocation is 750 independent with UEC. 752 Node D: 32bits-PREFIX-SID-D. Note that MPLS Label allocation is 753 independent with UEC. 755 Note that the above SRv6 SID itself is always a 128bits IPv6 address, 756 with no relationship with its UET Flavor attribute. The UET Flavor 757 attribute indicates the next SID type, i.e., 128bits classical SID, 758 32bits IPv4 address, or 32bits MPLS Label, etc. 760 5.2.3. Packets Forwarding Procedures 762 Consider that the controller computes an E2E segment list . 765 For the above E2E segment list, the controller knows which UET domain 766 does each segment node belongs to, especially that ABR1 and ABR2 are 767 the border nodes between different UET domain. Controller will 768 select appropriate SID with specific UET Flavor attribute to indicate 769 the UET domain which the next SID belongs to, i.e., whether the next 770 SID is a classical IPv6 address or a shorter truncated value. 772 The SID list informed to headend could be: 774 FSU: First SID UET, which indicates the compression resulst of the 775 first SID, in this example, it is set to UET-128. 777 No.1 SID: 128bits-END-SID-X (with BL|TL info of itself, and 778 UET-128 Flavor to indicate the compression result of the next SID) 780 No.2 SID: 128bits-END-SID-ABR1' (with BL|TL info of itself, and 781 UET-32 Flavor to indicate the compression result of the next SID) 783 No.3 SID: 128bits-END-SID-Y (with BL|TL info of itself, and UET-32 784 Flavor to indicate the compression result of the next SID) 786 No.4 SID: 128bits-END-SID-ABR2' (with BL|TL info of itself, and 787 UET-MPLS Flavor to indicate the compression result of the next 788 SID) 790 No.5 SID: 32bits-PREFIX-SID-Z, (with UET-MPLS Flavor to indicate 791 the compression result of the next SID) 793 No.6 SID: 32bits-PREFIX-SID-D, (with UET-128 Flavor to indicate 794 the compression result of the next SID) 796 Note: 798 FSU indicates the compression result of the first SRv6 SID itself, 799 while the UET Flavor attribute of the first SID just indicates the 800 compression result of the second SRv6 SID. 802 BL is the Block Length of SRv6 SID. TL is the Truncated Length of 803 SRv6 SID, i.e., the compression result. 805 The headend analysis of how to get the compressed SID List. 807 FSU is UET-128, so the first SID 128bits-END-SID-X keep 128bits. 809 The No.1 SID, 128bits-END-SID-X, has UET-128 Flavor, which means the 810 next SID, 128bits-END-SID-ABR1', also needs to keep 128bits. 812 The No.2 SID, 128bits-END-SID-ABR1' has UET-32 Flavor, which means 813 the next SID, 128bits-END-SID-Y, needs to be compressed as 32bits 814 IPv4 address. 816 The No.3 SID, 128bits-END-SID-Y, has UET-32 Flavor, which means the 817 next SID, 128bits-END-SID-ABR2', needs to be compressed as 32bits 818 IPv4 address. 820 The No.4 SID, 128bits-END-SID-ABR2', has UET-MPLS Flavor, which means 821 the next SID, 32bits-PREFIX-SID-Z, needs to keep 32bits. 823 The No.5 SID, 32bits-PREFIX-SID-Z, has UET-MPLS Flavor, which means 824 the next SID, 32bits-PREFIX-SID-D, needs to keep 32bits. 826 The No.6 SID, 32bits-PREFIX-SID-D, has UET-128 Flavor, which means 827 the next SID, maybe a VPN service SRv6 SID, needs to keep 128bits. 829 Note that in some cases, an overlay VPN service SRv6 SID could be 830 compressed. At that time, the last SID within the underlay segment 831 list may select the one with UET-32 or UET-16 Flavor attribute. 833 Thus, the headend can get the following compressed SID List: 835 128bits-END-SID-X with UET-128 Flavor 837 128bits-END-SID-ABR1' with UET-32 Flavor 839 32bits of 128bits-END-SID-Y with UET-32 Flavor 841 32bits of 128bits-END-SID-ABR2' with UET-MPLS Flavor 843 32bits-PREFIX-SID-Z (with UET-MPLS Flavor in context.field) 845 32bits-PREFIX-SID-D (with UET-128 Flavor context.field) 847 At the However, to meet the SRH processing restrictions defined in 848 [RFC8754], it is possible to allocate MPLS labels for some of the 849 topology-related SRv6 SIDs, which will consume more label 850 resources.At the headend, the encapsulated SRH could be: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Last Entry | Flags |UET| | Tag | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 ~ 128bits VPN-SID ~ [0] 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 861 | 32bits-PREFIX-SID-D (with UET-128 in context.field) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | 32bits-PREFIX-SID-Z (with UET-MPLS in context.field) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [1] 865 | 32bits of 128bits-END-SID-ABR2' with UET-MPLS | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | 32bits of 128bits-END-SID-Y with UET-32 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 869 ~ 128bits-END-SID-ABR1' with UET-32 ~ [2] 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 871 ~ 128bits-END-SID-X with UET-128 ~ [3] 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 // // 874 // Optional Type Length Value objects (variable) // 875 // // 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 9: SRH including different UET SID 880 The initial SRH.SL is set to 4: the number of 128bits based SIDs in 881 SRH, and the initial SRH.UET is set to UET-128, according to FSU, 882 which represents the first UET domain. 884 During the process of packets passing through multiple UET domains, 885 if SRH.UET change from UET-128 to UET-32 or UET-MPLS, SRH.SL will 886 quadruple, i.e., SRH.SL = SRH.SL * 4, which is the number of 32bits 887 based SIDs in SRH. When SRH.UET changed from UET-32 or UET-MPLS to 888 UET-128, SRH.SL will revert to its original size, i.e., SRH.SL = 889 SRH.SL / 4, which is the number of 128bits based SIDs in SRH. 891 Similarly, when SRH.UET change from UET-128 to UET-16, SRH.SL = 892 SRH.SL * 8, from UET-32 to UET-16, SRH.SL = SRH.SL * 2, vice versa. 894 Refer to Figure 8, next we will describe the process of packets 895 passing through each UET domain. 897 At the headend S, when packets sent to the No.1 segment node X, it 898 will decrement SRH.SL by 1, get the first 128bits SID from 899 SRH.List[], 128bits-END-SID-X with UET-128, copy to DA, and lookup 900 FIB to send packets. Now, SRH.SL is 3 and SRH.UET is UET-128. 902 At the No.1 segment node X, the local SID matches the DA and has 903 UET-128 Flavor attribute. Hence, SRH.UET has no change. It will 904 decrement SRH.SL by 1, get the next 128bits SID from SRH.List[], 905 128bits-END-SID-ABR1' with UET-32, copy to DA, and lookup FIB to send 906 packets. At this time, SRH.SL is 2 and SRH.UET is UET-128. 908 At the No.2 segment node ABR1, the local SID matches the DA has 909 UET-32 Flavor attribute. Hence, SRH.UET has changed from UET-128 to 910 UET-32. Tne node will firstly calculate SRH.SL * 4, then decrement 911 SRH.SL by 1, get the next 32bits SID from SRH.List[], 32bits of 912 128bits-END-SID-Y with UET-32, convert it to a complete IPv6 SID, 913 copy to DA, and lookup FIB to send packets. At this time, SRH.SL is 914 7 and SRH.UET is UET-32. 916 At the No.3 segment node Y, the local SID matches the DA has UET-32 917 Flavor attribute. Thus, SRH.UET has no change. The node will 918 decrement SRH.SL by 1, get the next 32bits SID from SRH.List[], 919 32bits of 128bits-END-SID-ABR2' with UET-MPLS, convert it to a 920 complete IPv6 SID, copy to DA, and lookup FIB to send packets. At 921 this time, SRH.SL is 6, SRH.UET is UET-32. 923 At the No.4 segment node ABR2, the local SID matches the DA has UET- 924 MPLS Flavor attribute. Hence, SRH.UET has changed from UET-32 to 925 UET-MPLS. Because the size of SID has no change, the node will 926 decrement SRH.SL by 1, get the next 32bits SID from SRH.List[], 927 32bits-PREFIX-SID-Z (with UET-MPLS in context.field), map it to a 928 complete IPv6 prefix FEC by ILM entry, copy to DA, and lookup FIB (or 929 directly get forwarding information from ILM entry) to send packets. 930 Note that the UET information in context.field needs to be compared 931 to SRH.UET. Since values are equal no change and no additional 932 processing. At this time, SRH.SL is 5, SRH.UET is 0b02. 934 At the No.5 segment node Z, the normal address route entry matches 935 the DA and has no UET Flavor attribute. As a result, SRH.UET has no 936 change. The node decrements SRH.SL by 1, will get the next 32bits 937 SID from SRH.List[], 32bits-PREFIX-SID-D (with UET-128 in 938 context.field), map it to a complete IPv6 prefix FEC by ILM entry, 939 copy to DA, and lookup FIB (or directly get forwarding information 940 from ILM entry) to send packets. Note that the UET information in 941 context.field needs to be compared to SRH.UET. Because it is changed 942 from UET-MPLS to UET-128, the SRH.SL will be reverted to its original 943 size, i.e., let SRH.SL / 4. At this time, SRH.SL is 1, SRH.UET is 944 UET-128. 946 At the No.6 segment node D, the normal address route entry matched by 947 DA has no associated UET Flavor attribute. Hence, SRH.UET has no 948 change. The node decrements SRH.SL by 1, will get the next 128bits 949 SID from SRH.List[], 128bits VPN-SID, and follow the rest process 950 described in [I-D.ietf-spring-srv6-network-programming]. 952 6. Control Plane in Support of Unified SID 954 The introduction of the Unified Identifier may rely on the existing 955 SR extensions to the routing protocols. But some enhancements in the 956 control plane are still required. This section references the 957 existing protocols and identifies necessary extensions. 959 Each node in the SRv6 domain needs to advertise its U-SID 960 Encapsulation Capability, this information can be carried within 961 SRv6-Capabilities sub-TLV defined in 962 [I-D.ietf-lsr-isis-srv6-extensions] and SRv6 Capabilities TLV defined 963 in [I-D.ietf-lsr-ospfv3-srv6-extensions]. It need also allocate SRv6 964 SID (Topology type and Service Function type) per UEC and advertise 965 to other nodes, the advertisement of SRv6 END SID, END.X SID, LAN 966 END.X SID defined in [I-D.ietf-lsr-isis-srv6-extensions] and 967 [I-D.ietf-lsr-ospfv3-srv6-extensions] need to be extended to carry 968 UET-Flavor information. This information can be collected and sent 969 to the central controller through BGP-LS. The controller then can 970 send the computed segment list to the headend through BGP or PCEP, 971 and each segment will include explicit UET Flavor information. The 972 detailed procedures are outside the scope of this document. 974 The SR-MPLS extensions to Interior Gateway Protocols (IGP), IS-IS 975 [RFC8667], OSPF [RFC8665], and OSPFv3 [RFC8666], defined how 20-bits 976 and 32-bits SIDs advertised and bound to SR objects and/or 977 instructions. Extensions to BGP Link-state address family 978 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 979 segment information of variable length via BGP. The existed SR-MPLS 980 extensions can be used to get MPLS U-SID mapping FIB entry, and it 981 can coexist with SRv6 extensions to the same IGP/BGP-LS instance. 982 For simplicity, this document suggests using the existing mature SR- 983 MPLS control plane and FIB entry for the MPLS U-SID advertisement and 984 mapping entry. However, it is possible to base it on SRv6 related 985 TLVs/sub-TLVs to advertise the MPLS U-SID, which will be discussed in 986 another document. 988 7. SRH with U-SID Pseudo-code 990 Processing of SRH with U-SID is demonstrated in the following pseudo- 991 code: 993 Headend sending packet: 995 S01. set initial SRH.UET, respond to the FSU, i.e., 996 the compressed result of the first SID; 997 S02. set initial SRH.SL, it is the count of 128bits-based SIDs; 998 S03. if (SRH.UET == UET-128) { 999 S04. SRH.SL --; 1000 S05. Get SRH.List[SRH.SL], 128bits, copy to IPv6 Header DA; Or, 1001 headend know the first SID before SRH encapsulation, 1002 just copy it to DA. 1003 S06. FIB lookup according to DA, and forward packet; 1004 S07. } 1005 S08. else if (SRH.UET == UET-32) { 1006 S09. SRH.SL = SRH.SL * 4; 1007 S10. SRH.SL --; 1008 S11. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 1009 to IPv6 Header DA; Or, headend know the first SID before SRH 1010 encapsulation, just copy it to DA; 1011 S12. FIB lookup according to DA, and forward packet; 1012 S13. } 1013 S14. else if (SRH.UET == UET-MPLS) { 1014 S15. SRH.SL = SRH.SL * 4; 1015 S16. SRH.SL --; 1016 S17. Get SRH.List[SRH.SL], 32bits, lookup ILM entry and map it to 128 1017 IPv6 address, copy it to IPv6 Header DA; Or, headend know 1018 the first SID before SRH encapsulation, just copy it to DA; 1019 S18. FIB lookup according to DA, or, directly get forwarding 1020 information from ILM entry, and forward packet; 1021 S19. } 1022 S20. else if (SRH.UET == UET-16) { 1023 S21. SRH.SL = SRH.SL * 8; 1024 S22. SRH.SL --; 1025 S23. Get SRH.List[SRH.SL], 16bits, convert to 128bits SRv6 SID, copy 1026 to IPv6 Header DA; Or, headend know the first SID before SRH 1027 encapsulation, just copy it to DA; 1028 S24. FIB lookup according to DA, and forward packet; 1029 S25. } 1031 Transit/Egress receive packets: 1033 S01. If DA matched local SID entry, copy the UET attr of local SID entry 1034 to SRH.UET, check when SRH.UET changed from UET-128 to UET-32 or 1035 UET-MPLS, SRH.SL*4, when from UET-32 or UET-MPLS to UET-128, 1036 SRH.SL / 4, similar treatment of UET-16 related SRH.SL update; 1037 Else If DA matched normal address route entry, 1038 SRH.UET no update; 1039 S02. if (SRH.SL == 0) { 1040 S03. process the inner payload; 1041 S04. } 1042 S05. else { 1043 S06. if (SRH.UET == UET-128) { 1044 S07. SRH.SL -- ; 1045 S08. Get SRH.List[SRH.SL], 128bits, copy it to IPv6 Header DA; 1046 S09. FIB lookup according to DA, and forward packet; 1047 S10. } 1048 S11. else if (SRH.UET == UET-32) { 1049 S12. SRH.SL -- ; 1050 S13. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 1051 to IPv6 Header DA; 1052 S14. FIB lookup according to DA, and forward packet; 1053 S15. } 1054 S16. else if (SRH.UET == UET-MPLS) { 1055 S17. SRH.SL -- 1056 S18. Get SRH.List[SRH.SL], 32bits, lookup ILM entry, map it to 1057 128bits IPv6 address, copy it to IPv6 Header DA; 1058 S19. Get UET info from SRH.List[SRH.SL] Context Field, copy it to 1059 SRH.UET. Check if SRH.UET changed from UET-MPLS to UET-128, 1060 SRH.SL/4; 1061 S20. FIB lookup according to DA, or, directly get forwarding 1062 information from ILM entry, and forward packet; 1063 S21. } 1064 S22. else if (SRH.UET == UET-16) { 1065 S23. SRH.SL -- ; 1066 S24. Get SRH.List[SRH.SL], 16bits, convert to 128bits SRv6 SID, copy 1067 to IPv6 Header DA; 1068 S25. FIB lookup according to DA, and forward packet; 1069 S26. } 1070 S27. } 1072 8. U-SID supporting SRv6 programming 1074 U-SID can support SRv6 programming defined by 1075 [I-D.ietf-spring-srv6-network-programming]. The details will be 1076 described in another document. 1078 9. Benefits 1080 To be discussed in the next version. 1082 10. Implementation Considerations 1084 The Unified SID solution has been already implemented and tested by 1085 two companies: 1087 o Centec has conducted its PoC, and the report is available at 1088 https://cloud.tencent.com/developer/article/1540023. 1090 o Broadcom, in its lab, also conducted PoC testing of the U-SID 1091 solution. 1093 11. IANA Considerations 1095 IANA is requested to allocate from the Segment Routing Header Flags 1096 registry the two-bits long field referred to as Size. 1098 12. Security Considerations 1100 This specification inherits all security considerations of [RFC8402] 1101 and [RFC8754]. 1103 13. Contributors 1104 Wan Xiaolan 1105 New H3C Technologies Co. Ltd 1106 No.8, Yongjia Road, Haidian District 1107 Beijing 1108 China 1110 Email: wxlan@h3c.com 1112 Cheng Wei 1113 Centec 1114 Building B, No.5 Xing Han Street, Suzhou Industrial Park 1115 Suzhou 1116 China 1118 Email: Chengw@centecnetworks.com 1120 S.Zadok 1121 Broadcom 1122 Israel 1124 Email: shay.zadok@broadcom.com 1126 14. Acknowledgements 1128 TBD 1130 15. Normative References 1132 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 1133 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 1134 and M. Chen, "BGP Link-State extensions for Segment 1135 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 1136 (work in progress), June 2019. 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", draft-ietf-lsr-isis-srv6-extensions-11 1142 (work in progress), October 2020. 1144 [I-D.ietf-lsr-ospfv3-srv6-extensions] 1145 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 1146 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 1147 ospfv3-srv6-extensions-01 (work in progress), August 2020. 1149 [I-D.ietf-spring-srv6-network-programming] 1150 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1151 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1152 draft-ietf-spring-srv6-network-programming-28 (work in 1153 progress), December 2020. 1155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1156 Requirement Levels", BCP 14, RFC 2119, 1157 DOI 10.17487/RFC2119, March 1997, 1158 . 1160 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1161 Routing Header for Source Routes with the Routing Protocol 1162 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1163 DOI 10.17487/RFC6554, March 2012, 1164 . 1166 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1167 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1168 May 2017, . 1170 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1171 (IPv6) Specification", STD 86, RFC 8200, 1172 DOI 10.17487/RFC8200, July 2017, 1173 . 1175 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1176 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1177 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1178 July 2018, . 1180 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1181 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1182 Routing with the MPLS Data Plane", RFC 8660, 1183 DOI 10.17487/RFC8660, December 2019, 1184 . 1186 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 1187 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 1188 DOI 10.17487/RFC8663, December 2019, 1189 . 1191 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1192 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1193 Extensions for Segment Routing", RFC 8665, 1194 DOI 10.17487/RFC8665, December 2019, 1195 . 1197 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1198 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1199 December 2019, . 1201 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1202 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1203 Extensions for Segment Routing", RFC 8667, 1204 DOI 10.17487/RFC8667, December 2019, 1205 . 1207 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1208 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1209 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1210 . 1212 Authors' Addresses 1214 Cheng Weiqiang 1215 China Mobile 1216 Beijing 1217 China 1219 Email: chengweiqiang@chinamobile.com 1221 Greg Mirsky 1222 ZTE Corp. 1224 Email: gregimirsky@gmail.com 1226 Peng Shaofu 1227 ZTE Corporation 1228 No.50 Software Avenue, Yuhuatai District 1229 Nanjing 1230 China 1232 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 1241 Gyan S. Mishra 1242 Verizon Inc. 1243 13101 Columbia Pike 1244 Silver Spring MD 20904 1245 United States of America 1247 Phone: 301 502-1347 1248 Email: gyan.s.mishra@verizon.com