idnits 2.17.1 draft-mirsky-6man-unified-id-sr-07.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2020) is 1391 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 692 -- Looks like a reference, but probably isn't: '1' on line 697 -- Looks like a reference, but probably isn't: '2' on line 702 -- Looks like a reference, but probably isn't: '3' on line 704 == 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-08 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 Summary: 1 error (**), 0 flaws (~~), 6 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: January 3, 2021 ZTE Corp. 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 G. Mishra 10 Verizon Inc. 11 July 2, 2020 13 Unified Identifier in IPv6 Segment Routing Networks 14 draft-mirsky-6man-unified-id-sr-07 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 January 3, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . 4 71 4. The Use Case of Unified Segment Identifier . . . . . . . . . 6 72 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID . . . . 6 73 5. Operations with Unified Segment Identifier . . . . . . . . . 9 74 5.1. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . 10 75 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 10 76 6. Interworking Between Different UET domain Considerations . . 12 77 6.1. Interworking Using Binding SID . . . . . . . . . . . . . 12 78 6.2. Interworking Using Mixing U-SID . . . . . . . . . . . . . 12 79 6.2.1. UET capability Advertisement . . . . . . . . . . . . 13 80 6.2.2. SRv6 SID Allocated per UET . . . . . . . . . . . . . 13 81 6.2.3. Packets Forwarding Procedures . . . . . . . . . . . . 15 82 6.2.4. SRH with mixing elements Pseudo-code . . . . . . . . 18 83 7. Control Plane in Support of Unified SID . . . . . . . . . . . 19 84 8. U-SID supporting SRv6 programming . . . . . . . . . . . . . . 20 85 9. Implementation Considerations . . . . . . . . . . . . . . . . 20 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 90 14. Normative References . . . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 Segment Routing architecture [RFC8402] leverages the paradigm of 96 source routing. It can be realized in a network data plane by 97 prepending the packet with a list of instructions, a.k.a. segment 98 identifiers (SIDs). A segment can be encoded as a Multi-Protocol 99 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 100 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 101 MPLS label stack [RFC8660]. It also can be applied to IPv6 data 102 plane by encoding a list of 128-bits SIDs in IPv6 Segment Routing 103 Extension Header (SRH) [I-D.ietf-6man-segment-routing-header]. 105 This document extends the use of the SRH 106 [I-D.ietf-6man-segment-routing-header] to unified identifiers encoded 107 as MPLS label or IPv4 address to support more detailed network 108 programming and interworking between SR-MPLS and SRv6 domains. 110 1.1. Conventions used in this document 112 1.1.1. Acronyms 114 SR: Segment Routing 116 SRH: Segment Routing Extension Header 118 MPLS: Multiprotocol Label Switching 120 SR-MPLS: Segment Routing using MPLS data plane 122 SID: Segment Identifier 124 IGP: Interior Gateway Protocol 126 DA: Destination Address 128 ILM: Incoming Label Map 130 FEC: Forwarding Equivalence Class 132 FTN: FEC-to-NHLFE map 134 OAM: Operation, Administration and Maintenance 136 TE: Traffic Engineering 138 SRv6: Segment Routing in IPv6 140 U-SID: Unified Segment Identifier 141 PSP: Penultimate Segment Popping 143 FIB: Forwarding Information Base 145 UET: U-SID Encapsulation Type 147 1.1.2. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2. Segment Routing Extension Header: Benefits and Challenges 157 Many functions related to Operation, Administration and Maintenance 158 (OAM) require identification of the SR tunnel ingress and the path, 159 constructed by segments, between the ingress and the egress SR nodes. 160 Combination of IPv6 encapsulation [RFC8200] and SRH 161 [I-D.ietf-6man-segment-routing-header], referred to as SRv6, comply 162 with these requirements while it is challenging when applying SR in 163 MPLS networks, also referred to as SR-MPLS. 165 On the other hand, the size of IPv6 SID presents a scaling challenge 166 to use topological instructions that define strict explicit traffic- 167 engineered (TE) path or support network programming in combination 168 with service-based instructions. At the same time, that is where SR- 169 MPLS approach provides better results due to smaller SID length. It 170 can be used to compress the SRv6 header size when a smaller namespace 171 of available SIDs is sufficient for addressing the particular 172 network. 174 SR-MPLS is broadly used in metro networks. With the gradual 175 deployment of SRv6 in the core networks, supporting interworking 176 between SR-MPLS and SRv6 becomes the necessity for operators. It is 177 operationally more efficient and straightforward if SRv6 can use the 178 same size SIDs as in SR-MPLS. The SRH can be extended to define the 179 same as in SR-MPLS SID length to support the unified segment 180 identifier (U-SID). As a result, end-to-end SR tunnel may use U-SIDs 181 across SR-MPLS and SRv6 domains. 183 3. Unified SIDs in IPv6 Segment Routing Extension Header 185 SRH format has been defined in Section 3 of 186 [I-D.ietf-6man-segment-routing-header] as presented in Figure 1 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Last Entry | Flags | Tag | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 | Segment List[0] (128 bits IPv6 address) | 196 | | 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 | | 201 ... 202 | | 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 | Segment List[n] (128 bits IPv6 address) | 207 | | 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 // // 211 // Optional Type Length Value objects (variable) // 212 // // 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: SRH format 217 This document defines a new field Size in the SRH Flags field as a 218 two-bits field, termed as UET (U-SID Encapsulation Type), with the 219 following values: 221 0b00 - 128-bits SID, an IPv6 address. 223 0b01 - 32-bits SID. In some environments, the context could be of 224 IPv4 address, while in some other cases, it could represent an 225 index of list or range of IPv4/IPv6 addresses. Another 226 interpretation of 32-bits SID could be as a complementary element 227 of an IPv4/IPv6 prefix. The setting of the interpretation might 228 be done through the control plane based signaling and is outside 229 the scope of this document. If this SID represents a 230 complementary part of an IPv4/IPv6 prefix, the original IP address 231 can be re-constructed by using, for example, mapping, stitching, 232 shifting or translating operation. Specification of such a 233 mechanism is outside the scope of this document. 235 0b10 - 32-bits SID, which includes an MPLS label in the leftmost 236 20-bits as displayed in Figure 2. Information in the Context 237 field could be interpreted as a flavor of a particular network 238 programming behavior. Specification of the network programming 239 using this type of U-SID is outside the scope of this document. 240 [Ed.note. Replace with a reference to the U-SID network 241 programming document.] 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | MPLS Label | Context | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: Format of Unified SID with MPLS Label 251 0b11 - Reserved for future use. 253 This document also introduce a compatible operation on Segment Left 254 field, also termed as SRH.SL. That is, if SRH.UET Flag is 0b00, 255 SRH.SL represents the count of 128bits-SID items in SRH, if SRH.UET 256 Flag is 0b01 or 0b10, SRH.SL represents the count of 32bits-SID items 257 in SRH. 259 4. The Use Case of Unified Segment Identifier 261 U-SID can be used for interworking between SR-MPLS and SRv6 domains. 262 SR-MPLS is often used in a metro network, for example, in the 263 backhaul metro network of CMCC. If the core network uses SRv6, for 264 example, the core network of the same operator, U-SID can be used in 265 the SRv6 domain to interwork with SR-MPLS in the metro network to 266 form an end-to-end tunnel. 268 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID 270 SR-MPLS uses SR SIDs as MPLS label in MPLS stack, and the SIDs are 271 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, and 272 the SIDs are 128-bits long. 274 The U-SID uses the same 32-bits long SIDs in MPLS stack and SRH. 275 Thus, four 32-bits long U-SIDs can be placed in the space of a single 276 128-bits long header. The encapsulation is illustrated in Figure 3. 278 +---------+ +----------------------------------+ 279 | | | IPv6 header | 280 | Ethernet| +----------------------------------+ 281 | | | SRH | 282 +---------+ +----------------------------------+ 283 | USID1 | | USID1 | USID2 | ... | USID4 | 284 +---------+ +----------------------------------+ 285 | USID2 | | USID5 |... | USIDn | Null | 286 +---------+ +----------------------------------+ 287 | ... | + Payload | 288 +---------+ +----------------------------------+ 289 | USIDn | 290 +---------+ 291 | Payload | 292 +---------+ 294 Figure 3: 32-bits long U-SIDs Encapsulation 296 The SR-MPLS and SRv6 interworking is illustrated in Figure 4. An 297 end-to-end SR tunnel from A to F crosses the SR-MPLS and SRv6 298 domains. The SR-MPLS domain could be using IPv4 or IPv6 address 299 family. The SRv6 border nodes (E/G) receive SR-MPLS packets and 300 forward them into the SRv6 domain using an SR-MPLS Binding SID 301 [RFC8660]. 303 +-----+ +-----+ +-----+ +-----+ 304 | A +-----------+ B +-----------+ E +-----------+ F | 305 +-----+ +--+--+ +--+--+ +--+--+ 306 | SR-MPLS | | SRv6 | 307 | | | | 308 +-----+ +--+--+ +--+--+ +--+--+ 309 | C |-----------| D +-----------+ G +-----------+ H | 310 +-----+ +-----+ +-----+ +-----+ 312 +--------------+ 313 | Eth(E->G) | 314 +--------------+ +--------------+ 315 | Eth(A->B) | |IPv6 DA:G.intf| 316 +--------------+ +--------------+ +--------------+ 317 | USID(B) | | Eth(B->E) | |SRH | 318 +--------------+ +--------------+ |NH:MPLS SL:2| 319 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 320 +--------------+ +--------------+ |USID(ADJ G->H)| 321 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 322 +--------------+ +--------------+ +--------------+ 323 |Label(service)| |Label(service)| |Label(service)| 324 +--------------+ +--------------+ +--------------+ 325 | Payload | -> | Payload | -> | Payload | 326 +--------------+ +--------------+ +--------------+ 328 Figure 4: SR-MPLS and SRv6 interworking 330 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 331 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 332 policy (from E to F, via segment list E-G-H-F) with U-SID 333 encapsulation. At the headend A, the end-to-end segment list could 334 be B-E1-E2. Figure 6 demonstrates an example of the packet 335 forwarding, where U-SID is an MPLS label. 337 The reverse interworking is illustrated in Figure 5. An end-to-end 338 SR tunnel from F to A crosses the SRv6 and SR-MPLS domains. The SRv6 339 border nodes (E/G) receive SRv6 packets and forward them into the SR- 340 MPLS domain using an SR-MPLS Binding SID or normal Prefix/Adjacency 341 SID. 343 +-----+ +-----+ +-----+ +-----+ 344 | A +-----------+ B +-----------+ E +-----------+ F | 345 +-----+ +--+--+ +--+--+ +--+--+ 346 | SR-MPLS | | SRv6 | 347 | | | | 348 +-----+ +--+--+ +--+--+ +--+--+ 349 | C |-----------| D +-----------+ G +-----------+ H | 350 +-----+ +-----+ +-----+ +-----+ 352 +--------------+ 353 | Eth(F->H) | 354 +--------------+ 355 |IPv6 DA:H.intf| 356 +--------------+ 357 |SRH | 358 |NH:MPLS SL:2| 359 |USID(ADJ F->H)| 360 +--------------+ |USID(ADJ H->G)| 361 | Eth(E->B) | |USID(ADJ G->E)| 362 +--------------+ +--------------+ +--------------+ 363 | Eth(B->A) | | USID(B) | | USID(B) | 364 +--------------+ +--------------+ +--------------+ 365 | USID(A) | | USID(A) | | USID(A) | 366 +--------------+ +--------------+ +--------------+ 367 |Label(service)| |Label(service)| |Label(service)| 368 +--------------+ +--------------+ +--------------+ 369 | Payload | <- | Payload | <- | Payload | 370 +--------------+ +--------------+ +--------------+ 372 Figure 5: SR-MPLS and SRv6 reverse interworking 374 The SRv6 edge node F assigns an SR-MPLS Binding-SID F2, which 375 represents an SRv6 policy (from F to E, via segment list F-H-G-E) 376 with U-SID encapsulation. At the headend F, the end-to-end segment 377 list could be F2-B-A. 379 5. Operations with Unified Segment Identifier 381 When SRH is used to include 32-bits long U-SIDs, the ingress and 382 transit nodes of an SR tunnel act as described in Section 5.1 and 383 Section 5.2 of [I-D.ietf-6man-segment-routing-header] respectively. 385 If U-SID is used to support interworking between SR-MPLS and SRv6 386 domains, it is beneficial that U-SID type matches to an MPLS label. 387 In that case, an ILM (Incoming Label Map) entry can be used to map a 388 U-SID to an IPv6 address. As a result, it is not necessary to 389 introduce a new type of index-based mapping table. For ILM entry of 390 Adjacency-SID, the mapping result copied to DA (Destination Address) 391 is the remote interface IPv6 address, for ILM entry of Node-SID, the 392 mapping result that is copied into DA is a remote node loopback IPv6 393 address. 395 Operations on an MPLS label of U-SID type are the same as those 396 defined in [RFC8663]. However, SR-MPLS over SRH has the following 397 advantages compared with SR-MPLS over UDP: 399 o SRH is flexible to extend flags or sub-TLVs for service 400 requirements, but UDP not. 402 o Labels in SRH can meet 8 bytes alignment requirements as per 403 [RFC8200], but UDP not. 405 o The source address of the SR policy is not discarded, but UDP not. 407 5.1. Procedures of SR-MPLS over IP 409 Procedures of SR-MPLS over IP of [RFC8663] described how to construct 410 an adjusted SR-MPLS FTN (FEC-to-NHLFE map) and ILM entry towards a 411 prefix-SID when next-hops are IP-only routers. The action of FTN and 412 ILM entry will steer the packet along an outer tunnel to the 413 destination node that has originated the FEC (Forwarding Equivalence 414 Class). UDP header is removed and put again at the each segment 415 endpoint. However, for SR-MPLS over SRH in this document we don't 416 try to depend on that adjusted FIB (Forwarding Information Base) 417 entry, because there are not any actions needed to get from the FIB 418 entry, a traditional ILM entry (maybe without out-label because of 419 IP-only next-hop) is enough to get the FEC information, i.e., to map 420 a U-SID to an IPv6 address and copy to DA. Note that an 421 implementation can get both FEC and next-hop/interface forwarding 422 information from the ILM entry, to avoid extra FIB lookup. An SRv6 423 policy chosen to encapsulate U-SID list within SRH is determined at 424 the ingress node of this SRv6 policy, SRH is preserved along the SR 425 to egress, though PSP (Penultimate Segment Popping) may be used, that 426 is different from SR-MPLS over IP/UDP method [RFC8663], so the source 427 address (i.e., the ingress of the SRv6 policy) is not discarded. 429 5.2. Packet Forwarding 431 U-SID based packet forwarding is similar to the processing described 432 in [RFC8663]. But it differs from that in FIB action and segment 433 list processing. For completeness, we repeat the description of 434 [RFC8663] with modification as follows. 436 +-----+ +-----+ +-----+ +-----+ +-----+ 437 | A +-------+ B +-------+ C +--------+ D +--------+ H | 438 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 439 | | | 440 | | | 441 +--+--+ +--+--+ +--+--+ 442 | E +-------+ F +--------+ G | 443 +-----+ +-----+ +-----+ 445 +--------+ +--------+ +--------+ 446 |IP(A->E)| |IP(A->G)| |IP(A->G)| 447 +--------+ +--------+ +--------+ 448 |SRH | |SRH | |SRH |(or PSP) 449 | SL:2 | | SL:1 | | SL:0 | 450 | L(E) | | L(E) | | L(E) | 451 | L(G) | | L(G) | | L(G) | 452 | L(H) | | L(H) | | L(H) | 453 +--------+ +--------+ +--------+ 454 | Packet | ---> | Packet | ---> | Packet | 455 +--------+ +--------+ +--------+ 457 Figure 6: Packet Forwarding Example 459 In the example shown in Figure 6, assume that routers A, E, G, and H 460 are U-SID capable (i.e., both SR-MPLS and SRv6 capable ) while the 461 remaining routers (B, C, D, and F) are only capable of forwarding IP 462 packets. Routers A, E, G, and H advertise their Segment Routing 463 related information via IS-IS or OSPF. 465 Now assume that router A (the Domain ingress) wants to send a packet 466 to router H (the Domain egress) via an SRv6 policy with the explicit 467 path {E->G->H}. Router A will impose an MPLS label stack within SRH 468 on the packet that corresponds to that explicit path. Router A 469 searches ILM entry by the top label (that indicated router E), get 470 the FEC information and next-hop/interface forwarding information, a 471 loopback IPv6 address of E, and then copy to DA and sends the packet. 472 The value of SRH.SL is 2. 474 When the IPv6 packet arrives at router E, router E picks the next 475 segment (label) within SRH based on the SRH.SL value of 2, searches 476 ILM entry by the next label, get the FEC information and next-hop/ 477 interface forwarding information, a loopback IPv6 address of G, and 478 then copy to DA and sends the packet. The value of SRH.SL is 1. 480 When the IPv6 packet arrives at router G, router G gets the next 481 segment (label) within SRH based on the SRH.SL value of 1, looks up 482 ILM entry by the next label, gets the FEC information and next-hop/ 483 interface forwarding information, a loopback IPv6 address of H, and 484 then copies it to IP DA and transmits the packet. Because the value 485 of SRH.SL is 0, the SRH can be removed if the behavior flavor 486 codepoint of next segment (label) is set to PSP. 488 6. Interworking Between Different UET domain Considerations 490 6.1. Interworking Using Binding SID 492 In Figure 4 and Figure 5, We have seen a simple interworking solution 493 based on Binding SID. 495 This document RECOMMOND this method for interworking, because Binding 496 SID is very simple to hide the difference U-SID type of different 497 domain. Especially, a headend only with classical SRv6 SRH 498 encapsulation capability, i.e., no capability to put multiple short 499 U-SIDs to a single 128bits item, will not need to upgrade. 501 Altough Binding SID that is allocated for the specific SR policy 502 instance will bring more states on some domain boder nodes, the SR 503 policy instance itself maybe pre-exist due to other requirements. 504 The SR policy is created within each UET domain which is upgraded 505 separately. 507 In order to do interwork, as mentioned before, an MPLS Binding SID 508 could be allocated for an SRv6 policy, used to hide the details of 509 UET-0b00 domain (classical SRv6) for a traditional MPLS Label stack. 510 Similarly, an SRv6 Binding SID could be allocated for an SR-MPLS 511 policy, used to hide the details of UET-0b10 domain for a traditional 512 SRv6 SRH. And, an SRv6 Binding SID allocated for an SRv6 policy 513 which enable UET-0b01 compression style, will hide the details of 514 UET-0b01 domain for a traditional SRv6 SRH. There maybe other 515 combinations, and not list one by one. 517 Note that in some cases, Binding SID will cause multiple SRH to be 518 inserted in IPv6 header. 520 6.2. Interworking Using Mixing U-SID 522 U-SRH can also provide an alternate interworking scheme to support an 523 end-to-end SR tunnel or policy using mixing type of U-SIDs, if more 524 headend nodes have be upgraded to support encapsulating mixing U-SID 525 in SRH. For example, an SID list could contain some 128bits-SIDs, 526 some 32bits-SIDs, some 32bits-Labels. For this purpose, we need 527 explicitly define U-SID types, in other words, the type is just UET. 529 The interworking of different UET domain is illustrated in Figure 7. 530 An end-to-end SR tunnel or policy from S to D with segment list , crosses the UET-0b00 domain, UET-0b01 domain 532 and UET-0b10 domain. Note that any order of UET domains are also 533 possible and similar with the following illustration. 535 ..................... .................. ................... 536 : : : : : : 537 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 538 | S +-----+ X +-----+ABR1+-----+ Y +-----+ABR2+-----+ Y +-----+ D | 539 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 540 : : : : : : 541 ......UET(0b00)...... .....UET(0b01).... .....UET(0b10)..... 543 Figure 7: Interworking between different UET SID 545 6.2.1. UET capability Advertisement 547 In SRv6 network, each node can configure its UET capability, and 548 advertise it to other nodes. Controller can also collect UET 549 capability information of all nodes. Typical UET capability is: 551 UET-0: Support classical 128bits SRv6 SID. 553 UET-1: Support shorter 32bits IPv4 address or number. 555 UET-2: Support shorter 32bits MPLS label. 557 UET-3: Support shorter 16bits number. 559 Each node can support one or more than one UET capabilitys. Refer to 560 Figure 7, node S/X/ABR1 can configure to support UET-0 capability, 561 node ABR1/Y/ABR2 can configure to support UET-1 capability, and node 562 ABR2/Y/D can configure to support UET-2 capability. 564 6.2.2. SRv6 SID Allocated per UET 566 An SRv6 SID is allocated per UET capability. In control plane, an 567 SRv6 SID is always 128bits, however: 569 An SRv6 SID that has UET-0 attribute means it is allocated for 570 traditional 128bits encapsulation purpose, that means in SRH the 571 next SID is also a 128bits SID. 573 An SRv6 SID that has UET-1 attribute means it is allocated for 574 32bits IPv4 encapsulation purpose, that means in SRH the next SID 575 is a 32bits IPv4 address. 577 An SRv6 SID that has UET-2 attribute means it is allocated for 578 32bits MPLS encapsulation purpose, that means in SRH the next SID 579 is a 32bits MPLS Label. 581 An SRv6 SID that has UET-3 attribute means it is allocated for 582 16bits number encapsulation purpose, that means in SRH the next 583 SID is a 16bits number. 585 For the local SID entry of each SRv6 SID allocated per UET 586 capability, it will explicitly give the UET attribute information. 588 Each node allocate its SRv6 SID per UET capability, and advertise it 589 to other nodes with additional UET-Flavor. Controller can also 590 collect these SIDs used for E2E SID List programming. 592 In order to save label resources, MPLS label is not allocated per 593 UET. The UET information can be directly inserted in the context 594 field of the label item in SRH. 596 For example, refer to Figure 7, each node allocate the following SRv6 597 SID per UET. 599 Node S: 128bits-END-SID-S for UET-0. 601 NOde X: 128bits-END-SID-X for UET-0. 603 NOde ABR1: 128bits-END-SID-ABR1 for UET-0, and 128bits-END-SID- 604 ABR1' for UET-1. 606 NOde Y: 128bits-END-SID-Y for UET-1. 608 NOde ABR2: 128bits-END-SID-ABR2 for UET-1, and 128bits-END-SID- 609 ABR2' for UET-2. 611 NOde Z: 32bits-PREFIX-SID-Z. Note that MPLS Label allocation is 612 independent with UET. 614 NOde D: 32bits-PREFIX-SID-D. Note that MPLS Label allocation is 615 independent with UET. 617 Note that the above SRv6 SID itself is always a 128bits IPv6 address, 618 no relationship with its UET attribute. The UET attribute indicate 619 the next SID type, i.e., 128bits classical SID, 32bits IPv4 address, 620 or 32bits MPLS Label, etc. 622 6.2.3. Packets Forwarding Procedures 624 Controller compute an E2E segment list . 626 Controller knows that ABR1 and ABR2 are the border nodes between 627 different UET domain for the above segment list. 629 So, the SID list informed to headend is: 631 No.1 SID: 128bits-END-SID-X (with UET-0 Flag, and BL|NBL info) 633 No.2 SID: 128bits-END-SID-ABR1' (with UET-1 Flag, and BL|NBL info) 635 No.3 SID: 128bits-END-SID-Y (with UET-1 Flag, and BL|NBL info) 637 No.4 SID: 128bits-END-SID-ABR2' (with UET-2 Flag, and BL|NBL info) 639 No.5 SID: 32bits-PREFIX-SID-Z, (with UET-2 Flag) 641 No.6 SID: 32bits-PREFIX-SID-D, (with UET-0 Flag) 643 Note: BL is Block Length, NBL is non-Block Length. 645 The headend analysis how to get the compressed SID List. 647 The No.1 SID, 128bits-END-SID-X, has UET-0 Flag, so keep 128bits. 649 The No.1 SID, 128bits-END-SID-X, has UET-0 Flag, that means the next 650 SID, 128bits-END-SID-ABR1', need also keep 128bits. 652 The No.2 SID, 128bits-END-SID-ABR1' has UET-1 Flag, that means the 653 next SID, 128bits-END-SID-Y, need to be compressed as 32bits IPv4 654 address. 656 The No.3 SID, 128bits-END-SID-Y, has UET-1 Flag, that means the next 657 SID, 128bits-END-SID-ABR2', need to be compressed as 32bits IPv4 658 address. 660 The No.4 SID, 128bits-END-SID-ABR2', has UET-2 Flag, that means the 661 next SID, 32bits-PREFIX-SID-Z, need keep 32bits. 663 The No.5 SID, 32bits-PREFIX-SID-Z, has UET-2 Flag, that means the 664 next SID, 32bits-PREFIX-SID-D, need keep 32bits. 666 The No.6 SID, 32bits-PREFIX-SID-D, has UET-0 Flag, that means the 667 next SID, maybe a VPN service SRv6 SID, need keep 128bits. 669 So, the headend can get the following compressed SID List: 671 128bits-END-SID-X for UET-0 673 128bits-END-SID-ABR1' for UET-1 675 32bits of 128bits-END-SID-Y for UET-1 677 32bits of 128bits-END-SID-ABR2' for UET-2 679 32bits-PREFIX-SID-Z (with UET-2 in context.field) 681 32bits-PREFIX-SID-D (with UET-0 in context.field) 683 At headend, the encapsulated SRH could be: 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Last Entry | Flags |UET| | Tag | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 ~ 128bits VPN-SID ~ [0] 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 694 | 32bits-PREFIX-SID-D (with UET-0 in context.field) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | 32bits-PREFIX-SID-Z (with UET-2 in context.field) | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [1] 698 | 32bits of 128bits-END-SID-ABR2' for UET-2 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | 32bits of 128bits-END-SID-Y for UET-1 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 702 ~ 128bits-END-SID-ABR1' for UET-1 ~ [2] 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 704 ~ 128bits-END-SID-X for UET-0 ~ [3] 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 // // 707 // Optional Type Length Value objects (variable) // 708 // // 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Figure 8: SRH including different UET SID 713 The initial SRH.SL is set to 4, that is the count of 128bits based 714 SIDs in SRH, and the initial SRH.UET is set to 0b00, that represent 715 the first UET domain. 717 During the process of packets passing through multiple UET domains, 718 if SRH.UET change from 0b00 to 0b01 or 0b10, SRH.SL will quadruple, 719 i.e., SRH.SL = SRH.SL * 4, that is the count of 32bits based SIDs in 720 SRH. When SRH.UET changed from 0b01 or 0b10 to 0b00, SRH.SL will 721 revert to its original size, i.e., SRH.SL = SRH.SL / 4, that is the 722 count of 128bits based SIDs in SRH. 724 Refer to Figure 7, next we will describe the process of packets 725 passing through each UET domain. 727 At the headend S, when packets sent to the No.1 segment node X, it 728 will decrement SRH.SL by 1, get the first 128bits SID from 729 SRH.List[], 128bits-END-SID-X for UET-0, copy to DA, and lookup FIB 730 to send packets. At this time, SRH.SL is 3, SRH.UET is 0b00. 732 At the No.1 segment node X, the local SID matched by DA has UET-0 733 attribute, that is, SRH.UET has no change. It will continue to 734 decrement SRH.SL by 1, get the next 128bits SID from SRH.List[], 735 128bits-END-SID-ABR1' for UET-1, copy to DA, and lookup FIB to send 736 packets. At this time, SRH.SL is 2, SRH.UET is 0b00. 738 At the No.2 segment node ABR1, the local SID matched by DA has UET-1 739 attribute, that is, SRH.UET has changed from UET-0 to UET-1. It will 740 firstly let SRH.SL * 4, then decrement SRH.SL by 1, get the next 741 32bits SID from SRH.List[], 32bits of 128bits-END-SID-Y for UET-1, 742 convert it to a complete IPv6 SID, copy to DA, and lookup FIB to send 743 packets. At this time, SRH.SL is 7, SRH.UET is 0b01. 745 At the No.3 segment node Y, the local SID matched by DA has UET-1 746 attribute, that is, SRH.UET has no change. It will continue to 747 decrement SRH.SL by 1, get the next 32bits SID from SRH.List[], 748 32bits of 128bits-END-SID-ABR2' for UET-2, convert it to a complete 749 IPv6 SID, copy to DA, and lookup FIB to send packets. At this time, 750 SRH.SL is 6, SRH.UET is 0b01. 752 At the No.4 segment node ABR2, the local SID matched by DA has UET-2 753 attribute, that is, SRH.UET has changed from UET-1 to UET-2. Because 754 the size of SID has no change, it will continue to decrement SRH.SL 755 by 1, get the next 32bits SID from SRH.List[], 32bits-PREFIX-SID-Z 756 (with UET-2 in context.field), map it to a complete IPv6 prefix FEC 757 by ILM entry, copy to DA, and lookup FIB (or directly get forwarding 758 information from ILM entry) to send packets. Note that the UET 759 information in context.field need update to SRH.UET again and see if 760 it changes, no change at this time, so there is no additional 761 processing. At this time, SRH.SL is 5, SRH.UET is 0b02. 763 At the No.5 segment node Z, the normal address route entry matched by 764 DA has not any further UET attribute, that is, SRH.UET has no change. 765 It will continue to decrement SRH.SL by 1, get the next 32bits SID 766 from SRH.List[], 32bits-PREFIX-SID-D (with UET-0 in context.field), 767 map it to a complete IPv6 prefix FEC by ILM entry, copy to DA, and 768 lookup FIB (or directly get forwarding information from ILM entry) to 769 send packets. Note that the UET information in context.field need 770 update to SRH.UET again and see if it changes, it is changed from 771 UET-2 to UET-0, so SRH.SL will be revert to its original size, i.e., 772 let SRH.SL / 4. At this time, SRH.SL is 1, SRH.UET is 0b00. 774 At the No.6 segment node D, the normal address route entry matched by 775 DA has not any further UET attribute, that is, SRH.UET has no change. 776 It will continue to decrement SRH.SL by 1, get the next 128bits SID 777 from SRH.List[], 128bits VPN-SID, and follow the rest process 778 described in [I-D.ietf-spring-srv6-network-programming]. 780 6.2.4. SRH with mixing elements Pseudo-code 782 Processing of SRH with mixing elements is demonstrated in the 783 following pseudo-code: 785 Headend sending packet: 787 S01. set initial SRH.UET, respond to the UET type of the first SID; 788 S02. set initial SRH.SL, it is the count of 128bits-based SID; 789 S03. if (SRH.UET == 0b00) { 790 S04. SRH.SL --; 791 S05. Get SRH.List[SRH.SL], 128bits, copy to IPv6 Header DA; Or, 792 headend know the first SID before SRH encapsulation, 793 just copy it to DA. 794 S06. FIB lookup according to DA, and forward packet; 795 S07. } 796 S08. else if (SRH.UET == 0b01) { 797 S09. SRH.SL = SRH.SL * 4; 798 S10. SRH.SL --; 799 S11. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 800 to IPv6 Header DA; Or, headend know the first SID before SRH 801 encapsulation, just copy it to DA; 802 S12. FIB lookup according to DA, and forward packet; 803 S13. } 804 S14. else if (SRH.UET == 0b10) { 805 S15. SRH.SL = SRH.SL * 4; 806 S16. SRH.SL --; 807 S17. Get SRH.List[SRH.SL], 32bits, lookup ILM entry and map it to 128 808 IPv6 address, copy it to IPv6 Header DA; Or, headend know 809 the first SID before SRH encapsulation, just copy it to DA; 810 S18. FIB lookup according to DA, or, directly get forwarding information 811 from ILM entry, and forward packet; 812 S19. } 813 Transit/Egress receive packets: 815 S01. If DA matched local SID entry, copy the UET attr of local SID entry 816 to SRH.UET, check when SRH.UET changed from 0b00 to 0b01 or 0b10, 817 SRH.SL*4, when from 0b01 or 0b10 to 0b00, SRH.SL / 4; 818 Else If DA matched normal address route entry, SRH.UET no update; 819 S02. if (SRH.SL == 0) { 820 S03. process the inner payload; 821 S04. } 822 S05. else { 823 S06. if (SRH.UET == 0b00) { 824 S07. SRH.SL -- ; 825 S08. Get SRH.List[SRH.SL], 128bits, copy it to IPv6 Header DA; 826 S09. FIB lookup according to DA, and forward packet; 827 S10. } 828 S11. else if (SRH.UET == 0b01) { 829 S12. SRH.SL -- ; 830 S13. Get SRH.List[SRH.SL], 32bits, convert to 128bits SRv6 SID, copy 831 to IPv6 Header DA; 832 S14. FIB lookup according to DA, and forward packet; 833 S15. } 834 S16. else if (SRH.UET == 0b10) { 835 S17. SRH.SL -- 836 S18. Get SRH.List[SRH.SL], 32bits, lookup ILM entry, map it to 837 128bits IPv6 address, copy it to IPv6 Header DA; 838 S19. Get UET info from SRH.List[SRH.SL] Context Field, copy it to 839 SRH.UET. Check if SRH.UET changed from 0b10 to 0b00, SRH.SL/4; 840 S20. FIB lookup according to DA, or, directly get forwarding 841 information from ILM entry, and forward packet; 842 S21. } 843 S22. } 845 7. Control Plane in Support of Unified SID 847 The introduction of the Unified Identifier may rely on the existing 848 SR extensions to the routing protocols. But some enhancements in the 849 control plane are still required. This section references to the 850 existing protocols and identifies necessary extensions. 852 Each node in the SRv6 domain need advertise its U-SID Encapsulation 853 capability, this information can be carried within SRv6-Capabilities 854 sub-TLV defined in [I-D.ietf-lsr-isis-srv6-extensions] and SRv6 855 Capabilities TLV defined in [I-D.ietf-lsr-ospfv3-srv6-extensions]. 856 It need also allocate SRv6 SID (Topology type and Service Function 857 type) per UET and advertise to other nodes, the advertisement of SRv6 858 END SID, END.X SID, LAN END.X SID defined in 860 [I-D.ietf-lsr-isis-srv6-extensions] and 861 [I-D.ietf-lsr-ospfv3-srv6-extensions] need to be extended to carry 862 UET-Flavor information. These information can be collected and sent 863 to central controller through BGP-LS. Then, controller can send the 864 computed segment list to the headend through BGP or PCEP, and each 865 segment will include an explicit UET information. All these will be 866 defined in other documents. 868 The SR-MPLS extensions to Interior Gateway Protocols (IGP), IS-IS 869 [RFC8667], OSPF [RFC8665], and OSPFv3 [RFC8666], defined how 20-bits 870 and 32-bits SIDs advertised and bound to SR objects and/or 871 instructions. Extensions to BGP Link-state address family 872 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 873 segment information of variable length via BGP. The existed SR-MPLS 874 extensions can be used to get MPLS U-SID mapping FIB entry, and it 875 can coexist with SRv6 extensions to the same IGP/BGP-LS instance. 876 For simplicity purpose, tihs document suggest to use the existed 877 mature SR-MPLS control plane and FIB entry to server the MPLS U-SID 878 advertisement and mapping entry. However, it is possible to based on 879 SRv6 related TLVs/sub-TLVs to advertise the MPLS U-SID, and that will 880 be discussed in another document. 882 8. U-SID supporting SRv6 programming 884 U-SID can support SRv6 programming defined by 885 [I-D.ietf-spring-srv6-network-programming]. The details will be 886 described in another document. 888 9. Implementation Considerations 890 The Unified SID solution has been already implemented and tested by 891 two companies: 893 o Centec has conducted its PoC, and the report is available at 894 https://cloud.tencent.com/developer/article/1540023. 896 o Broadcom, in its lab, also conducted PoC testing of the U-SID 897 solution. 899 10. IANA Considerations 901 IANA is requested to allocate from the Segment Routing Header Flags 902 registry the two-bits long field referred to as Size. 904 11. Security Considerations 906 This specification inherits all security considerations of [RFC8402] 907 and [I-D.ietf-6man-segment-routing-header]. 909 12. Contributors 911 Wan Xiaolan 912 New H3C Technologies Co. Ltd 913 No.8, Yongjia Road, Haidian District 914 Beijing 915 China 917 Email: wxlan@h3c.com 919 Cheng Wei 920 Centec 921 Building B, No.5 Xing Han Street, Suzhou Industrial Park 922 Suzhou 923 China 925 Email: Chengw@centecnetworks.com 927 S.Zadok 928 Broadcom 929 Israel 931 Email: shay.zadok@broadcom.com 933 13. Acknowledgements 935 TBD 937 14. Normative References 939 [I-D.ietf-6man-segment-routing-header] 940 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 941 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 942 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 943 progress), October 2019. 945 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 946 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 947 and M. Chen, "BGP Link-State extensions for Segment 948 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 949 (work in progress), June 2019. 951 [I-D.ietf-lsr-isis-srv6-extensions] 952 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 953 Z. Hu, "IS-IS Extension to Support Segment Routing over 954 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 955 (work in progress), April 2020. 957 [I-D.ietf-lsr-ospfv3-srv6-extensions] 958 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 959 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 960 ospfv3-srv6-extensions-00 (work in progress), February 961 2020. 963 [I-D.ietf-spring-srv6-network-programming] 964 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 965 Matsushima, S., and Z. Li, "SRv6 Network Programming", 966 draft-ietf-spring-srv6-network-programming-16 (work in 967 progress), June 2020. 969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 970 Requirement Levels", BCP 14, RFC 2119, 971 DOI 10.17487/RFC2119, March 1997, 972 . 974 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 975 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 976 May 2017, . 978 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 979 (IPv6) Specification", STD 86, RFC 8200, 980 DOI 10.17487/RFC8200, July 2017, 981 . 983 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 984 Decraene, B., Litkowski, S., and R. Shakir, "Segment 985 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 986 July 2018, . 988 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 989 Decraene, B., Litkowski, S., and R. Shakir, "Segment 990 Routing with the MPLS Data Plane", RFC 8660, 991 DOI 10.17487/RFC8660, December 2019, 992 . 994 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 995 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 996 DOI 10.17487/RFC8663, December 2019, 997 . 999 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1000 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1001 Extensions for Segment Routing", RFC 8665, 1002 DOI 10.17487/RFC8665, December 2019, 1003 . 1005 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1006 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1007 December 2019, . 1009 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1010 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1011 Extensions for Segment Routing", RFC 8667, 1012 DOI 10.17487/RFC8667, December 2019, 1013 . 1015 Authors' Addresses 1017 Cheng Weiqiang 1018 China Mobile 1019 Beijing 1020 China 1022 Email: chengweiqiang@chinamobile.com 1024 Greg Mirsky 1025 ZTE Corp. 1027 Email: gregimirsky@gmail.com 1029 Peng Shaofu 1030 ZTE Corporation 1031 No.50 Software Avenue, Yuhuatai District 1032 Nanjing 1033 China 1035 Email: peng.shaofu@zte.com.cn 1037 Liu Aihua 1038 ZTE Corporation 1039 Zhongxing Industrial Park, Nanshan District 1040 Shenzhen 1041 China 1043 Email: liu.aihua@zte.com.cn 1044 Gyan S. Mishra 1045 Verizon Inc. 1046 13101 Columbia Pike 1047 Silver Spring MD 20904 1048 United States of America 1050 Phone: 301 502-1347 1051 Email: gyan.s.mishra@verizon.com