idnits 2.17.1 draft-mirsky-6man-unified-id-sr-05.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 (February 19, 2020) is 1521 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 189 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network C. Weiqiang 3 Internet-Draft China Mobile 4 Intended status: Standards Track G. Mirsky 5 Expires: August 22, 2020 ZTE Corp. 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 W. Xiaolan 10 New H3C Technologies Co. Ltd 11 C. Wei 12 Centec 13 S. Zadok 14 Broadcom 15 February 19, 2020 17 Unified Identifier in IPv6 Segment Routing Networks 18 draft-mirsky-6man-unified-id-sr-05 20 Abstract 22 Segment Routing architecture leverages the paradigm of source 23 routing. It can be realized in a network data plane by prepending 24 the packet with a list of instructions, a.k.a. segments. A segment 25 can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 26 address, or IPv6 address. Segment Routing can be applied in MPLS 27 data plane by encoding segments in the MPLS label stack. It also can 28 be applied to IPv6 data plane by encoding a list of segment 29 identifiers in IPv6 Segment Routing Extension Header (SRH). This 30 document extends the use of the SRH to unified segment identifiers 31 encoded, for example, as MPLS label or IPv4 address, to compress the 32 SRH, and support more detailed network programming and interworking 33 between SR-MPLS and SRv6 domains. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 22, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Conventions used in this document . . . . . . . . . . . . 3 70 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 71 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 72 2. Segment Routing Extension Header: Benefits and Challenges . . 4 73 3. Unified SIDs in IPv6 Segment Routing Extension Header . . . . 4 74 4. The Use Case of Unified Segment Identifier . . . . . . . . . 6 75 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID . . . . 6 76 5. Operations with Unified Segment Identifier . . . . . . . . . 9 77 5.1. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . 10 78 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Control Plane in Support of Unified SID . . . . . . . . . 13 80 6. U-SID supporting SRv6 programming . . . . . . . . . . . . . . 14 81 7. Implementation Considerations . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Segment Routing architecture [RFC8402] leverages the paradigm of 91 source routing. It can be realized in a network data plane by 92 prepending the packet with a list of instructions, a.k.a. segment 93 identifiers (SIDs). A segment can be encoded as a Multi-Protocol 94 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 95 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 96 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 97 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 98 Extension Header (SRH) [I-D.ietf-6man-segment-routing-header]. 100 This document extends the use of the SRH 101 [I-D.ietf-6man-segment-routing-header] to unified identifiers encoded 102 as MPLS label or IPv4 address to support more detailed network 103 programming and interworking between SR-MPLS and SRv6 domains. 105 1.1. Conventions used in this document 107 1.1.1. Terminology 109 SR: Segment Routing 111 SRH: Segment Routing Extension Header 113 MPLS: Multiprotocol Label Switching 115 SR-MPLS: Segment Routing using MPLS data plane 117 SID: Segment Identifier 119 IGP: Interior Gateway Protocol 121 DA: Destination Address 123 ILM: Incoming Label Map 125 FEC: Forwarding Equivalence Class 127 FTN: FEC-to-NHLFE map 129 OAM: Operation, Administration and Maintenance 131 TE: Traffic Engineering 133 SRv6: Segment Routing in IPv6 135 U-SID: Unified Segment Identifier 137 PSP: Penultimate Segment Popping 139 FIB: Forwarding Information Base 141 1.1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Segment Routing Extension Header: Benefits and Challenges 151 Many functions related to Operation, Administration and Maintenance 152 (OAM) require identification of the SR tunnel ingress and the path, 153 constructed by segments, between the ingress and the egress SR nodes. 154 Combination of IPv6 encapsulation [RFC8200] and SRH 155 [I-D.ietf-6man-segment-routing-header], referred to as SRv6, comply 156 with these requirements while it is challenging when applying SR in 157 MPLS networks, also referred to as SR-MPLS. 159 On the other hand, the size of IPv6 SID presents a scaling challenge 160 to use topological instructions that define strict explicit traffic- 161 engineered (TE) path or support network programming in combination 162 with service-based instructions. At the same time, that is where SR- 163 MPLS approach provides better results due to smaller SID length. It 164 can be used to compress the SRv6 header size when a smaller namespace 165 of available SIDs is sufficient for addressing the particular 166 network. 168 SR-MPLS is broadly used in metro networks. With the gradual 169 deployment of SRv6 in the core networks, supporting interworking 170 between SR-MPLS and SRv6 becomes the necessity for operators. It is 171 operationally more efficient and straightforward if SRv6 can use the 172 same size SIDs as in SR-MPLS. The SRH can be extended to define the 173 same as in SR-MPLS SID length to support the unified segment 174 identifier (U-SID). As a result, end-to-end SR tunnel may use U-SIDs 175 across SR-MPLS and SRv6 domains. 177 3. Unified SIDs in IPv6 Segment Routing Extension Header 179 SRH format has been defined in Section 3 of 180 [I-D.ietf-6man-segment-routing-header] as presented in Figure 1 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Last Entry | Flags | Tag | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 | Segment List[0] (128 bits IPv6 address) | 190 | | 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 | | 195 ... 196 | | 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 | Segment List[n] (128 bits IPv6 address) | 201 | | 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 // // 205 // Optional Type Length Value objects (variable) // 206 // // 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1: SRH format 211 This document defines a new field Size in the SRH Flags field as a 212 two-bits field with the following values: 214 0b00 - 128-bits SID, an IPv6 address. 216 0b01 - 32-bits SID. In some environments, the context could be of 217 IPv4 address, while in some other cases, it could represent an 218 index of list or range of IPv4/IPv6 addresses. Another 219 interpretation of 32-bits SID could be as a complementary element 220 of an IPv4/IPv6 prefix. The setting of the interpretation might 221 be done through the control plane based signaling and is outside 222 the scope of this document. If this SID represents a 223 complementary part of an IPv4/IPv6 prefix, the original IP address 224 can be re-constructed by using, for example, mapping, stitching, 225 shifting or translating operation. Specification of such a 226 mechanism is outside the scope of this document. 228 0b10 - 32-bits SID, which includes an MPLS label in the leftmost 229 20-bits as displayed in Figure 2. Information in the Context 230 field could be interpreted as a flavor of a particular network 231 programming behavior. Specification of the network programming 232 using this type of U-SID is outside the scope of this document. 233 [Ed.note. Replace with a reference to the U-SID network 234 programming document.] 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | MPLS Label | Context | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2: Format of Unified SID with MPLS Label 244 0b11 - Reserved for future use. 246 Entries of the segment list in the SRH MUST be of the same length. 248 4. The Use Case of Unified Segment Identifier 250 U-SID can be used for interworking between SR-MPLS and SRv6 domains. 251 SR-MPLS is often used in a metro network, for example, in the 252 backhaul metro network of CMCC. If the core network uses SRv6, for 253 example, the core network of the same operator, U-SID can be used in 254 the SRv6 domain to interwork with SR-MPLS in the metro network to 255 form an end-to-end tunnel. 257 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID 259 SR-MPLS uses SR SIDs as MPLS label in MPLS stack, and the SIDs are 260 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, and 261 the SIDs are 128-bits long. 263 The U-SID uses the same 32-bits long SIDs in MPLS stack and SRH. 264 Thus, four 32-bits long U-SIDs can be placed in the space of a single 265 128-bits long header. The encapsulation is illustrated in Figure 3. 267 +---------+ +----------------------------------+ 268 | | | IPv6 header | 269 | Ethernet| +----------------------------------+ 270 | | | SRH | 271 +---------+ +----------------------------------+ 272 | USID1 | | USID1 | USID2 | ... | USID4 | 273 +---------+ +----------------------------------+ 274 | USID2 | | USID5 |... | USIDn | Null | 275 +---------+ +----------------------------------+ 276 | ... | + Payload | 277 +---------+ +----------------------------------+ 278 | USIDn | 279 +---------+ 280 | Payload | 281 +---------+ 283 Figure 3: 32-bits long U-SIDs Encapsulation 285 The SR-MPLS and SRv6 interworking is illustrated in Figure 4. An 286 end-to-end SR tunnel from A to F crosses the SR-MPLS and SRv6 287 domains. The SR-MPLS domain could be using IPv4 or IPv6 address 288 family. The SRv6 border nodes (E/G) receive SR-MPLS packets and 289 forward them into the SRv6 domain using an SR-MPLS Binding SID 290 [RFC8660]. 292 +-----+ +-----+ +-----+ +-----+ 293 | A +-----------+ B +-----------+ E +-----------+ F | 294 +-----+ +--+--+ +--+--+ +--+--+ 295 | SR-MPLS | | SRv6 | 296 | | | | 297 +-----+ +--+--+ +--+--+ +--+--+ 298 | C |-----------| D +-----------+ G +-----------+ H | 299 +-----+ +-----+ +-----+ +-----+ 301 +--------------+ 302 | Eth(E->G) | 303 +--------------+ +--------------+ 304 | Eth(A->B) | |IPv6 DA:G.intf| 305 +--------------+ +--------------+ +--------------+ 306 | USID(B) | | Eth(B->E) | |SRH | 307 +--------------+ +--------------+ |NH:MPLS SL:2| 308 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 309 +--------------+ +--------------+ |USID(ADJ G->H)| 310 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 311 +--------------+ +--------------+ +--------------+ 312 | USID(F) | | USID(F) | | USID(F) | 313 +--------------+ +--------------+ +--------------+ 314 |Label(service)| |Label(service)| |Label(service)| 315 +--------------+ +--------------+ +--------------+ 316 | Payload | -> | Payload | -> | Payload | 317 +--------------+ +--------------+ +--------------+ 319 Figure 4: SR-MPLS and SRv6 interworking 321 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 322 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 323 policy (from E to F, via segment list E-G-H-F) with U-SID 324 encapsulation. At the headend A, the end-to-end segment list could 325 be B-E1-E2-F. Figure 6 demonstrates an example of the packet 326 forwarding, where U-SID is an MPLS label. 328 The controller may assign the end-to-end SR tunnel U-SIDs (from A to 329 F), and another method is outside the scope of this document. 331 The reverse interworking is illustrated in Figure 5. An end-to-end 332 SR tunnel from F to A crosses the SRv6 and SR-MPLS domains. The SRv6 333 border nodes (E/G) receive SRv6 packets and forward them into the SR- 334 MPLS domain using an SR-MPLS Binding SID or normal Prefix/Adjacency 335 SID. 337 +-----+ +-----+ +-----+ +-----+ 338 | A +-----------+ B +-----------+ E +-----------+ F | 339 +-----+ +--+--+ +--+--+ +--+--+ 340 | SR-MPLS | | SRv6 | 341 | | | | 342 +-----+ +--+--+ +--+--+ +--+--+ 343 | C |-----------| D +-----------+ G +-----------+ H | 344 +-----+ +-----+ +-----+ +-----+ 346 +--------------+ 347 | Eth(F->H) | 348 +--------------+ 349 |IPv6 DA:H.intf| 350 +--------------+ 351 |SRH | 352 |NH:MPLS SL:2| 353 |USID(ADJ F->H)| 354 +--------------+ |USID(ADJ H->G)| 355 | Eth(E->B) | |USID(ADJ G->E)| 356 +--------------+ +--------------+ +--------------+ 357 | Eth(B->A) | | USID(B) | | USID(B) | 358 +--------------+ +--------------+ +--------------+ 359 | USID(A) | | USID(A) | | USID(A) | 360 +--------------+ +--------------+ +--------------+ 361 |Label(service)| |Label(service)| |Label(service)| 362 +--------------+ +--------------+ +--------------+ 363 | Payload | <- | Payload | <- | Payload | 364 +--------------+ +--------------+ +--------------+ 366 Figure 5: SR-MPLS and SRv6 reverse interworking 368 The SRv6 edge node F assigns an SR-MPLS Binding-SID F2, which 369 represents an SRv6 policy (from F to E, via segment list F-H-G-E) 370 with U-SID encapsulation. At the headend F, the end-to-end segment 371 list could be F2-B-A. 373 5. Operations with Unified Segment Identifier 375 When SRH is used to include 32-bits long U-SIDs, the ingress and 376 transit nodes of an SR tunnel act as described in Section 5.1 and 377 Section 5.2 of [I-D.ietf-6man-segment-routing-header] respectively. 379 If U-SID is used to support interworking between SR-MPLS and SRv6 380 domains, it is beneficial that U-SID type matches to an MPLS label. 381 In that case, an ILM (Incoming Label Map) entry can be used to map a 382 U-SID to an IPv6 address. As a result, it is not necessary to 383 introduce a new type of index-based mapping table. For ILM entry of 384 Adjacency-SID, the mapping result copied to DA (Destination Address) 385 is the remote interface IPv6 address, for ILM entry of Node-SID, the 386 mapping result that is copied into DA is a remote node loopback IPv6 387 address. 389 Operations on an MPLS label of U-SID type are the same as those 390 defined in [RFC8663]. However, SR-MPLS over SRH has the following 391 advantages compared with SR-MPLS over UDP: 393 o SRH is flexible to extend flags or sub-TLVs for service 394 requirements, but UDP not. 396 o Labels in SRH can meet 8 bytes alignment requirements as per 397 [RFC8200], but UDP not. 399 o The source address of the SR policy is not discarded, but UDP not. 401 5.1. Procedures of SR-MPLS over IP 403 Procedures of SR-MPLS over IP of [RFC8663] described how to construct 404 an adjusted SR-MPLS FTN (FEC-to-NHLFE map) and ILM entry towards a 405 prefix-SID when next-hops are IP-only routers. The action of FTN and 406 ILM entry will steer the packet along an outer tunnel to the 407 destination node that has originated the FEC (Forwarding Equivalence 408 Class). UDP header is removed and put again at the each segment 409 endpoint. However, for SR-MPLS over SRH in this document we don't 410 try to depend on that adjusted FIB (Forwarding Information Base) 411 entry, because there are not any actions needed to get from the FIB 412 entry, a traditional ILM entry (maybe without out-label because of 413 IP-only next-hop) is enough to get the FEC information, i.e., to map 414 a U-SID to an IPv6 address and copy to DA. Note that an 415 implementation can get both FEC and next-hop/interface forwarding 416 information from the ILM entry, to avoid extra FIB lookup. An SRv6 417 policy chosen to encapsulate U-SID list within SRH is determined at 418 the ingress node of this SRv6 policy, SRH is preserved along the SR 419 to egress, though PSP (Penultimate Segment Popping) may be used, that 420 is different from SR-MPLS over IP/UDP method [RFC8663], so the source 421 address (i.e., the ingress of the SRv6 policy) is not discarded. 423 5.2. Packet Forwarding 425 U-SID based packet forwarding is similar to the processing described 426 in [RFC8663]. But it differs from that in FIB action and segment 427 list processing. For completeness, we repeat the description of 428 [RFC8663] with modification as follows. 430 +-----+ +-----+ +-----+ +-----+ +-----+ 431 | A +-------+ B +-------+ C +--------+ D +--------+ H | 432 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 433 | | | 434 | | | 435 +--+--+ +--+--+ +--+--+ 436 | E +-------+ F +--------+ G | 437 +-----+ +-----+ +-----+ 439 +--------+ +--------+ +--------+ 440 |IP(A->E)| |IP(A->G)| |IP(A->G)| 441 +--------+ +--------+ +--------+ 442 |SRH | |SRH | |SRH |(or PSP) 443 | SL:2 | | SL:1 | | SL:0 | 444 | L(E) | | L(E) | | L(E) | 445 | L(G) | | L(G) | | L(G) | 446 | L(H) | | L(H) | | L(H) | 447 +--------+ +--------+ +--------+ 448 | Packet | ---> | Packet | ---> | Packet | 449 +--------+ +--------+ +--------+ 451 Figure 6: Packet Forwarding Example 453 In the example shown in Figure 6, assume that routers A, E, G, and H 454 are U-SID capable (i.e., both SR-MPLS and SRv6 capable ) while the 455 remaining routers (B, C, D, and F) are only capable of forwarding IP 456 packets. Routers A, E, G, and H advertise their Segment Routing 457 related information via IS-IS or OSPF. 459 Now assume that router A (the Domain ingress) wants to send a packet 460 to router H (the Domain egress) via an SRv6 policy with the explicit 461 path {E->G->H}. Router A will impose an MPLS label stack within SRH 462 on the packet that corresponds to that explicit path. Router A 463 searches ILM entry by the top label (that indicated router E), get 464 the FEC information and next-hop/interface forwarding information, a 465 loopback IPv6 address of E, and then copy to DA and sends the packet. 466 The value of SRH.SL is 2. 468 When the IPv6 packet arrives at router E, router E picks the next 469 segment (label) within SRH based on the SRH.SL value of 2, searches 470 ILM entry by the next label, get the FEC information and next-hop/ 471 interface forwarding information, a loopback IPv6 address of G, and 472 then copy to DA and sends the packet. The value of SRH.SL is 1. 474 When the IPv6 packet arrives at router G, router G gets the next 475 segment (label) within SRH based on the SRH.SL value of 1, looks up 476 ILM entry by the next label, gets the FEC information and next-hop/ 477 interface forwarding information, a loopback IPv6 address of H, and 478 then copies it to IP DA and transmits the packet. Because the value 479 of SRH.SL is 0, the SRH can be removed if the behavior flavor 480 codepoint of next segment (label) is set to PSP. 482 Processing of SRH with elements carrying 20 bits-long SIDs closely 483 follows SRH processing as defined in Section 4.3.1.1 484 [I-D.ietf-6man-segment-routing-header] and is demonstrated in the 485 pseudo-code below: 487 S01. When an SRH is processed { 488 S02. If (Segments Left == zero) { 489 S03. Proceed to process the next header in the packet, 490 whose type is identified by the Next Header field in 491 the Routing header. 492 S04. } 493 S05. Else { 494 S06. If local configuration requires TLV processing { 495 S07. Perform TLV processing (see TLV Processing) 496 S08. } 497 S09. max_last_entry = 498 ( Hdr Ext Len * 8/ sizeof(SRH_element) ) - 1 499 S10. If ((Last Entry > max_last_entry) or 500 S11. (Segments Left is greater than (Last Entry+1)) { 501 S12. Send an ICMP Parameter Problem, Code 0, message to 502 the Source Address, pointing to the Segments Left 503 field, and discard the packet. 504 S13. } 505 S14. Else { 506 S15. Decrement Segments Left by 1. 507 S16. Use Segment List[Segments Left] as the key 508 in exact match lookup of FIB 509 S17. If (Lookup_result == Empty) 510 S18. Send an ICMP Destination Unreachable and 511 discard the packet 512 S19. Else { 513 S20. Copy Lookup_result as the destination address 514 of the IPv6 header. 515 S21. If (IPv6 Hop Limit is less than or equal <= to 1) { 516 S22. Send an ICMP Time Exceeded -- Hop Limit Exceeded in 517 Transit message to the Source Address and discard 518 the packet. 519 S23. } 520 S24. Else { 521 S25. Decrement the Hop Limit by 1 522 S26. Resubmit the packet to the IPv6 module 523 for transmission to the new destination. 524 S27. } 525 S28. } 526 S29. } 527 S30. } 528 S31. } 530 5.3. Control Plane in Support of Unified SID 532 The introduction of the Unified Identifier may rely on the existing 533 SR extensions to the routing protocols. But some enhancements in the 534 control plane are still required. This section references to the 535 existing protocols and identifies necessary extensions. 537 SR extensions to Interior Gateway Protocols (IGP), IS-IS [RFC8667], 538 OSPF [RFC8665], and OSPFv3 [RFC8666], defined how 20-bits and 32-bits 539 SIDs advertised and bound to SR objects and/or instructions. 540 Extensions to BGP Link-state address family 541 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 542 segment information of variable length via BGP. 544 6. U-SID supporting SRv6 programming 546 U-SID can support SRv6 programming defined by 547 [I-D.ietf-spring-srv6-network-programming]. The details will be 548 described in another document. 550 7. Implementation Considerations 552 The Unified SID solution has been already implemented and tested by 553 two companies: 555 o Centec has conducted its PoC, and the report is available at 556 https://cloud.tencent.com/developer/article/1540023. 558 o Broadcom, in its lab, also conducted PoC testing of the U-SID 559 solution. 561 8. IANA Considerations 563 IANA is requested to allocate from the Segment Routing Header Flags 564 registry the two-bits long field referred to as Size. 566 9. Security Considerations 568 This specification inherits all security considerations of [RFC8402] 569 and [I-D.ietf-6man-segment-routing-header]. 571 10. Acknowledgements 573 TBD 575 11. Normative References 577 [I-D.ietf-6man-segment-routing-header] 578 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 579 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 580 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 581 progress), October 2019. 583 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 584 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 585 and M. Chen, "BGP Link-State extensions for Segment 586 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 587 (work in progress), June 2019. 589 [I-D.ietf-spring-srv6-network-programming] 590 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 591 Matsushima, S., and Z. Li, "SRv6 Network Programming", 592 draft-ietf-spring-srv6-network-programming-09 (work in 593 progress), February 2020. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, 597 DOI 10.17487/RFC2119, March 1997, 598 . 600 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 601 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 602 May 2017, . 604 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 605 (IPv6) Specification", STD 86, RFC 8200, 606 DOI 10.17487/RFC8200, July 2017, 607 . 609 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 610 Decraene, B., Litkowski, S., and R. Shakir, "Segment 611 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 612 July 2018, . 614 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 615 Decraene, B., Litkowski, S., and R. Shakir, "Segment 616 Routing with the MPLS Data Plane", RFC 8660, 617 DOI 10.17487/RFC8660, December 2019, 618 . 620 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 621 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 622 DOI 10.17487/RFC8663, December 2019, 623 . 625 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 626 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 627 Extensions for Segment Routing", RFC 8665, 628 DOI 10.17487/RFC8665, December 2019, 629 . 631 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 632 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 633 December 2019, . 635 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 636 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 637 Extensions for Segment Routing", RFC 8667, 638 DOI 10.17487/RFC8667, December 2019, 639 . 641 Authors' Addresses 643 Cheng Weiqiang 644 China Mobile 645 Beijing 646 China 648 Email: chengweiqiang@chinamobile.com 650 Greg Mirsky 651 ZTE Corp. 653 Email: gregimirsky@gmail.com 655 Peng Shaofu 656 ZTE Corporation 657 No.50 Software Avenue, Yuhuatai District 658 Nanjing 659 China 661 Email: peng.shaofu@zte.com.cn 663 Liu Aihua 664 ZTE Corporation 665 Zhongxing Industrial Park, Nanshan District 666 Shenzhen 667 China 669 Email: liu.aihua@zte.com.cn 670 Wan Xiaolan 671 New H3C Technologies Co. Ltd 672 No.8, Yongjia Road, Haidian District 673 Beijing 674 China 676 Email: wxlan@h3c.com 678 Cheng Wei 679 Centec 680 Building B, No.5 Xing Han Street, Suzhou Industrial Park 681 Suzhou 682 China 684 Email: Chengw@centecnetworks.com 686 S.Zadok 687 Broadcom 688 Israel 690 Email: shay.zadok@broadcom.com