idnits 2.17.1 draft-cheng-spring-shorter-srv6-sid-requirement-01.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 (March 8, 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-spring-sr-service-programming' is defined on line 574, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-13 == Outdated reference: A later version (-03) exists of draft-cl-spring-generalized-srv6-np-00 == Outdated reference: A later version (-07) exists of draft-decraene-spring-srv6-vlsid-02 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-03 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-01 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-05 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Informational C. Xie 5 Expires: September 9, 2020 China Telecom 6 R. Pang 7 China Unicom 8 Z. Li 9 Huawei Technologies 10 R. Chen 11 ZTE Corporation 12 L. Zu 13 Unionpay 14 X. Duan 15 China Mobile 16 G. Mirsky 17 ZTE Corporation 18 March 8, 2020 20 Shorter SRv6 SID Requirements 21 draft-cheng-spring-shorter-srv6-sid-requirement-01 23 Abstract 25 This document describes a list of requirements for the use of a 26 shortened identifier in a segment routing network with the IPv6 data 27 plane. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 9, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Typical Application Scenarios . . . . . . . . . . . . . . . . 3 68 4. Analysis of SRH Overhead . . . . . . . . . . . . . . . . . . 5 69 5. Gap Analysis of Existing Solutions . . . . . . . . . . . . . 6 70 5.1. Binding SID . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.2. Loose Path TE . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Requirements: . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. The proposal solutions of shorter SRv6 SID . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Segment routing (SR) [RFC8402] is a source routing paradigm that 84 explicitly indicates the forwarding path for packets at the ingress 85 node by inserting an ordered list of instructions, called segments. 87 A segment can be encoded as a Multi-Protocol Label Switching (MPLS) 88 label, IPv4 address（确定吗）, or IPv6 89 address. Segment Routing can be deployed on the MPLS data plane by 90 encoding 32-bits SIDs in MPLS label stack [RFC8660]. It also can be 91 deployed on the IPv6 data plane by encoding a list of 128-bits SRv6 92 SIDs in IPv6 Segment Routing Extension Header 93 (SRH)[I-D.ietf-6man-segment-routing-header]. 95 The SRv6 Network Programming 96 [I-D.ietf-spring-srv6-network-programming] specifies the base set of 97 SRv6 behaviors that enables the creation of interoperable overlays 98 with underlay optimization. 100 However, the size of the SRv6 SID presents a scalabilities challenge 101 to use topological instructions that define a strict explicitly 102 routed path in combination with service-based instructions. At the 103 same time, the size of the SRH/SID may be a challenge for some data 104 plane processors and traffic overhead. Meanwhile, SR-MPLS currently, 105 more often than SRv6, is used in metro networks. With the gradual 106 deployment of SRv6 in the core networks, it becomes necessary to 107 support interworking between SR-MPLS and SRv6 and upgrading to SRv6 108 from SR-MPLS. It requires some solutions to resolve these problems. 110 2. Conventions used in this document 112 2.1. Terminology 114 SR: Segment Routing 116 SRH: Segment Routing Extension Header 118 MPLS: Multiprotocol Label Switching 120 SR-MPLS: Segment Routing over MPLS data plane 122 SID: Segment Identifier 124 SRv6: Segment Routing over IPv6 126 2.2. Keywords 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Typical Application Scenarios 136 At present, only typical application scenarios are discussed, and 137 other scenarios will be considered in the next version. 139 In the scenario of the mobile backhaul network shown in Figure 1, the 140 eNodeB communicates with RC (Radio Controller). SRv6 path can be set 141 up between the ASGs (Access Site Gateway) and the RSG (RC Site 142 Gateway) to bear mobile services. For a strict SRv6 TE path in this 143 scenarios, the typical number of the SIDs in the SRH is about 5 to 8 144 and the maximum is 10. 146 In the scenario of the mobile backhaul network, there are two 147 different domains. The domain between the ASGs and the AGGs 148 (Aggregation Gateway) is the access domain. And the domain between 149 the AGGs and the RSGs is the aggregation domain. The locators of the 150 SRv6 SIDs in each domain can share the common prefix. But the 151 locators of different domains may be different, meaning they cannot 152 share the common prefix. 154 eNodB2---ASG2-------AGG1------P1------RSG1------RC1 155 | | | 156 | | | 157 eNodB1---ASG1 | | 158 | | | 159 | | | 160 eNodB1---ASG3-------AGG2------P2------RC2-------RC2 162 Figure 1. Mobile Backhaul Network 164 In the scenario of multiple netowrk domains shown in Figure 2, the 165 typical case is that Domain 1 and Domain 3 can be the mubile backhaul 166 networks and the Domain 2 can be the IP backbone network. An SRv6 167 path can be set up from the node in Domain 1 and end up at the node 168 in Domain 2 for bearing mobile services, which will travel multiple 169 network domains. In this case, the typical number of the SIDs in the 170 SRH for the E2E SRv6 path may be up to 15, that is, for each network 171 domain, the typical number of the SIDs in SRH for each network domain 172 is 5. Though Binding SIDs [RFC8402] can be used for shortening the 173 SIDs List. 175 In the scenario of multiple network domains, the locators of the SRv6 176 SIDs in each network domain can share the common prefix. But the 177 locators of different network domains may be different, meaning they 178 does not share the common prefix. 180 A1--A3--ASBR11--ASBR21---P3--ASBR23--ASBR31--B3--B1 181 | | | | | | 182 | | | | | | 183 | Domain1 | | Domain2 | | Domain3 | 184 | | | | | | 185 | | | | | | 186 A2--A4--ASBR12--ASBR22--P4---ASBR24--ASBR32--B4--B2 188 Figure 2. Multiple Network Domains 190 4. Analysis of SRH Overhead 192 There are three major concerns about SRH overhead: 194 1. Path MTU 196 Since an SRv6 SID is a 128-bits value, when many SRv6 SIDs are 197 carried within an SRH, the large size overhead introduced by the SRH 198 increases the size of the packet which may exceed the Path MTU so 199 that the packet will be dropped. 201 In the current network, the PMTU of most UNI (User-to-Network 202 Interface) is configured as 1500 Bytes, due to the old link layer 203 technology in the user side. In most scenarios, such as IP WAN and 204 DCN, the PMTU of most NNI(Network-to-Network Interface) is configured 205 as 9000 bytes, since most vendors have to support Jumpo frame(>9000 206 Bytes). Therefore, when a packet come from the UNI, the packet size 207 is under 1500 bytes, which is far away from 9000 bytes even include 208 the overhead of SRH. So the Path MTU is not a critical issue in the 209 current network. 211 2. Forwarding Performance 213 As the size of the SRH overhead increases, it will bring burdens to 214 the hardware forwarding or software forwarding, and it will have 215 effect on the forwarding performance. 217 SRv6 can be deployed step-by-step in the networks while the hardware 218 capability is being developed. Given the fact some vendors already 219 supports the forwarding capability of up to 10 SIDs in the SRH now, 220 the challenges can be mitigated in the near future. But SRv6 will be 221 deployed in the wide network domains, the challenges to support more 222 SIDs in SRH still exist. 224 3. Payload Efficiency 225 As the size of the SRH overhead increases, the ratio of the effective 226 payload of a packet will be decreased. The SRH overhead will cause 227 the waste of bandwidth. 229 According to the statistics information from AMS-IX 230 , the average packet 232 size is about 512 Bytes. From throughput (in bps) point of view, the 233 packets large than 1024 bytes are more than 87% among the traffic. 234 Given the typical packet size and traffic statistics information, the 235 effect of payload efficiency can be under control with gradually 236 introducing of SRv6. However, in the long term there may be 237 requirements to insert up to 10 or more SIDs in an SRH which will low 238 down the payload efficiency. 240 In summary, according to the above analysis, the issue of SRv6 SRH 241 overhead can be under control in the short time. However, as the 242 development of SRv6 in the wider network domains, more SIDs will be 243 inserted in the SRH to support strict TE and other functionalities, 244 it will propose more challenges for the haraware. 246 5. Gap Analysis of Existing Solutions 248 5.1. Binding SID 250 The Binding SID [RFC8402] is bound to an SR Policy, instantiation of 251 which may involve a list of SIDs. Using BSID can shorten the SID 252 list [I-D.peng-spring-srv6-compatibility], and BSID is wide deployed 253 in the SR and SRv6 networks. However, the node that imposes the 254 bound policy needs to store the SID list, meaning the node should 255 maintain more states. 257 For example, the strict TE path can be represented as a seriels of END.X SIDs allocated by the 259 nodes, and the SID list can be represented as . BSID1 is bound to an SID 261 list , BSID2 is bound to an SID list 262 . Therefore, the path can be 263 represented as by using the Binding SIDs. In 264 this way, the SID number in the SRH is reduced form 9 to 3. While 265 the drawback is that the states of Binding SIDs should be maintained 266 at the mapping nodes R2 and R6. 268 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 269 + + 270 + + 271 + BSID1 BSID2 + 272 CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2 273 + + 274 + + 275 + + 276 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 278 Figure 2. Binding SID for Shorter the SID List 280 5.2. Loose Path TE 282 In some cases, if the strict TE path represented by an adjacency SID 283 list is the same as the loose TE path represented by a node SID or 284 prefix SID, the adjacency SID list can be replaced by the node SID or 285 the prefix SID to reduce the number of SIDs. However, loose path TE 286 can not guarantee the SLA of per-hop processing(bandwidth, delay, 287 etc.) for the traffic. 289 For example, an SRv6 policy explicitly indicates a strict TE path by 290 SID list . If this path is the same as the SPF path of an END SID S10 292 of node R10, then this END SID S10 can be used for forwarding the 293 traffic instead of the long SID list. However, if there are some SLA 294 policy associated to the Adjacency SIDs along the path, then it can 295 not be assured in best effert forwarding by using the END SID, even 296 the packet is forwarded following the same path. 298 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 299 + R11-------R12----R13 + 300 + | | | + 301 + | | | + END SID S10 302 CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2 303 + | | + 304 + | | + 305 + R14-------------------------------R15 + 306 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 308 Figure 3. Binding SID for Shorter the SID List 310 6. Requirements: 312 Based on the above typical scenario and gap analysis of existing 313 solutions , this section lists the suggested requirements for Shorter 314 SRv6 SID, which can be used to help the WG evaluate against the 315 proposed solutions: 317 REQ#1: The Shorter SRv6 solution MUST be compatible with the basic 318 SRv6. There are three basic Segment Routing over the IPv6 data-plane 319 (SRv6) documents: 321 o The Segment Routing (SR) architecture is defined in [RFC8402]. 323 o The IPv6 Segment Routing Header (SRH) is defined in 324 [I-D.ietf-6man-segment-routing-header]. 326 o SRv6 Network Programming is defined in 327 [I-D.ietf-spring-srv6-network-programming]. 329 The Shorter SRv6 SID solution MUST be compatible with the above 330 listed SRv6 documents. 332 REQ#2: The Shorter SRv6 SID solution MUST support Efficient SRv6 333 header compression. 335 When SRv6 is deployed, the SRv6 header overhead must be considered, 336 as the size of the SRH may affect the forwarding performance. The 337 solution MUST reduce the SRv6 SID size effectively. 339 REQ#3: The Shorter SRv6 SID solution MUST support source routing, 340 SHOULD NOT introduce per-flow states on middle nodes. 342 Reducing the states on the middle nodes is the advantage of SR, and 343 it should be maintained. New states should be introduced after 344 carefully consideration if they are really needed. 346 REQ#4: The Shorter SRv6 SID solution SHOULD be routable as a Native 347 IPv6 address for currently typical application. 349 It is the key feature of SRv6 that SRv6 SID can be routable as a 350 native IPv6 address: 352 1. The feature guarantees the compatibility of SRv6 to IPv6. 354 2. SRv6 SID is routable as a normal native IPv6 address, so the 355 traffic can be forwarded as the normal IPv6 traffic on the SRv6 356 unaware nodes. it simplifies the service provision that SRv6-based 357 services can take use of the basic IPv6 reachability. 359 3. The routes of SRv6 SIDs can be aggregated since SRv6 SID can be 360 routed as a native IPv6 address. This can reduce the number of 361 forwarding entries and improve the scalability, especially in inter- 362 AS networks scenarios. Based on the native IPv6 routing, the SRv6 BE 363 VPN can be deployed by only upgrading the VPN endpoint nodes. Also, 364 SRv6 VPN traffic can be forwarded as the native IPv6 address without 365 difficult configurations on the edge nodes in inter-domain scenarios. 367 Therefore, the shorter SID SHOULD be routable as a Native IPv6 368 address. 370 Other scenarios will be considered in future, the solution should 371 have the forward compabilities to support other scenarios. 373 REQ#5: The Shorter SRv6 SID solution CAN NOT require specific address 374 planning or address type. 376 When deploying SRv6 in a network, the SIDs can be allocated from a 377 SID space, the address block managed by the operators. The Shorter 378 SID solution should support this as well. It MUST support flexible 379 address planning as different networks have their own address 380 allocation policy. The Shorter SID MUST NOT depend on some specific 381 address type, and it SHOULD NOT introduce new address type in the 382 network since this increases the complexities of configurations and 383 operations, which will also bring troubles of OAM due to operators 384 may have limited experience of it. 386 REQ#6: The Shorter SRv6 SID solution MUST be a Loseless Compression 387 mechanism. The information carried by the shorter SID list in SRH 388 MUST equal to the original SID list. 390 The information can not be lost in compression since each SID 391 represents the action and related services on a node, the Shorter SID 392 solution MUST represent the same function. The format of the Shorter 393 SID may be different with the original SRv6 SID, while the related 394 function should be identical. 396 REQ#7: The Shorter SRv6 SID solution SHOULD support multiple 397 functions, including END, END.X and END.T but not limit to them. 399 The solution MUST be scalable to support multiple functions and it 400 SHOULD NOT be limited in only END, END.X and END.T, since there will 401 be multiple SIDs to be introduced in the future, the solution should 402 have the forward compabilities to support the new SIDs. 404 REQ#8: The Shorter SRv6 SID solution MUST be easy to implement and 405 hardware-friendly(Including ASIC-based and NP-based hardware) 406 The Shorter SRv6 SID solution MUST be simple and easy to implement 407 based on existing commercial hardware, which can be supported by 408 multiple vendors instead of some specific vendors. 410 REQ#9: The Shorter SRv6 SID solution MUST be compatible with SRv6 411 header(SRH). 413 For support of the SRv6 network, Segment Routing Header (SRH) has 414 been defined in [I-D.ietf-6man-segment-routing-header]. The Shorter 415 SRv6 SID solution MUST be compatible with SRH. 417 REQ#10: The Shorter SRv6 SID solution SHOULD support to encode 418 Compressed SRv6 Network Programming SIDs and SRv6 SIDs in a single 419 SRH. 421 In an SR domain, there will be a scenario in which some nodes support 422 Compressed SRv6, while others support IPv6 without SR extensions. 423 The proposed solution MUST support this scenario. 425 REQ#11: The Shorter SRv6 SID solution MUST support super-large-scale 426 networking and address planning. 428 Note: The operator suggest to reuse the current address assignment 429 and planning, thus minimizing the impact on the network. 431 REQ#12: The Shorter SRv6 SID solution MUST have the ability to 432 upgrade smoothly from SR-MPLS to SRv6. 434 2G/3G/4G backhaul networks widely deploy MPLS to connect wireless 435 services. Many operators are already deploying 5G networks. To 436 optimize the operation of the network, many operators intent to adopt 437 the segment routing. Currently, given the maturity of SR-MPLS, it 438 has been deployed on a large scale. Meanwhile the requirements of 5G 439 super-large-scale number of connections accelerate the deployment of 440 IPv6 networks. Thus, logically, operators consider SRv6 solution to 441 fulfill the 5G backhaul requirement. But the backhaul network could 442 not deploy SRv6 in one day, especially if it has already been using 443 MPLS and SR-MPLS. It might be reasonable to upgrade from MPLS to SR- 444 MPLS and then to SRv6. 446 REQ#13: The Shorter SRv6 SID solution MUST support interworking 447 between SRv6 and SR-MPLS domains in the network. 449 SR-MPLS currently, more often than SRv6, is used in metro networks. 450 With the gradual deployment of SRv6 in the core networks, it becomes 451 necessary to support interworking between SR-MPLS and SRv6. 453 7. The proposal solutions of shorter SRv6 SID 455 As we know, there several proposals in the called 'shorter SRv6 456 SID'topic. This document tries to summarize these proposals here. 457 Then we can discuss whether all the proposals can meet the 458 requirements. And then we can look at the merits and costs of each 459 solution. After that, we will possibly refine them, possibly 460 converge on a single one, and probably drop multiples. 462 Here are the solutions that have been proposed: 464 o [I-D.mirsky-6man-unified-id-sr] extends the use of the flag of the 465 SRH to unified identifiers encoded as shorter SID (such as 466 32-bits). It can be interworking with SR-MPLS. It is the 467 earliest one, simple, and compatible well with original SRH. 469 o [I-D.filsfils-spring-net-pgm-extension-srv6-usid] extends SRv6 470 Network Programming with a new type of SRv6 SID behavior. A uSID 471 carrier can be encoded in the Destination Address of an IPv6 472 header or at any position in the Segment List of an SRH. 474 o [I-D.li-spring-compressed-srv6-np] defines a compressed SRv6 475 network programming mechanism in order to reduce the overhead of 476 SRv6 by introducing the Compressed Segment Identifier (C-SID) and 477 the Compressed SRH (C-SRH). The C-SRH can be a new Routing Header 478 or an enhancement of SRH. The Common prefix of SRv6 SIDs will be 479 removed, while only the different path, the C-SID, will be carried 480 in the C-SRH. In this way, the overhead of SRv6 is reduced. 482 o [I-D.decraene-spring-srv6-vlsid] extends SRH and SRv6 Network 483 Programming to allow for SIDs of variable length, from 1 up to 128 484 bits. It is required to extend the control plane to advertise the 485 SID length. 487 o [I-D.bonica-6man-comp-rtg-hdr] defines two new Routing header 488 types. Collectively, they are called the Compressed Routing 489 Headers (CRH). Individually, they are called CRH-16 and CRH-32. 490 In the CRH, the Type-specific data field contains a list of 491 Segment Identifiers (SIDs)(16bits/32bits). 493 o [I-D.cl-spring-generalized-srv6-np] proposes Generalized Segment 494 Routing over IPv6 (G-SRv6) Networking Programming, which supports 495 to encode multiple types of Segments in an SRH, called Generalized 496 SRH (G-SRH). These Segments can be called Generalized Segment, 497 and the ID can be Generalized Segment Identifier (G-SID), which 498 may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 499 tunnel information. 501 8. IANA Considerations 503 This document has no requests to IANA. 505 9. Security Considerations 507 This document does not change the security considerations of SRv6, 508 please refers to [RFC8402], [I-D.ietf-6man-segment-routing-header] 509 and [I-D.ietf-spring-srv6-network-programming]. 511 10. References 513 10.1. Normative References 515 [I-D.ietf-6man-segment-routing-header] 516 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 517 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 518 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 519 progress), October 2019. 521 [I-D.ietf-spring-srv6-network-programming] 522 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 523 Matsushima, S., and Z. Li, "SRv6 Network Programming", 524 draft-ietf-spring-srv6-network-programming-10 (work in 525 progress), February 2020. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 533 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 534 May 2017, . 536 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 537 Decraene, B., Litkowski, S., and R. Shakir, "Segment 538 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 539 July 2018, . 541 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 542 Decraene, B., Litkowski, S., and R. Shakir, "Segment 543 Routing with the MPLS Data Plane", RFC 8660, 544 DOI 10.17487/RFC8660, December 2019, 545 . 547 10.2. Informative References 549 [I-D.bonica-6man-comp-rtg-hdr] 550 Bonica, R., Kamite, Y., Niwa, T., Alston, A., and L. 551 Jalil, "The IPv6 Compressed Routing Header (CRH)", draft- 552 bonica-6man-comp-rtg-hdr-13 (work in progress), March 553 2020. 555 [I-D.cl-spring-generalized-srv6-np] 556 Cheng, W., Li, Z., Li, C., Xie, C., Cong, L., Tian, H., 557 and F. Zhao, "Generalized SRv6 Network Programming", 558 draft-cl-spring-generalized-srv6-np-00 (work in progress), 559 February 2020. 561 [I-D.decraene-spring-srv6-vlsid] 562 Decraene, B. and R. Raszuk, "SRv6 vSID: Network 563 Programming extension for variable length SIDs", draft- 564 decraene-spring-srv6-vlsid-02 (work in progress), February 565 2020. 567 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 568 Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, 569 I., Patel, K., Henderickx, W., Jonnalagadda, P., and D. 570 Melman, "Network Programming extension: SRv6 uSID 571 instruction", draft-filsfils-spring-net-pgm-extension- 572 srv6-usid-03 (work in progress), February 2020. 574 [I-D.ietf-spring-sr-service-programming] 575 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 576 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 577 Henderickx, W., and S. Salsano, "Service Programming with 578 Segment Routing", draft-ietf-spring-sr-service- 579 programming-01 (work in progress), November 2019. 581 [I-D.li-spring-compressed-srv6-np] 582 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 583 Guichard, J., Cong, L., and S. Peng, "Compressed SRv6 584 Network Programming", draft-li-spring-compressed- 585 srv6-np-02 (work in progress), February 2020. 587 [I-D.mirsky-6man-unified-id-sr] 588 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., Wei, 589 C., and S. Shay, "Unified Identifier in IPv6 Segment 590 Routing Networks", draft-mirsky-6man-unified-id-sr-05 591 (work in progress), February 2020. 593 [I-D.peng-spring-srv6-compatibility] 594 Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, 595 Z., and J. Guichard, "SRv6 Compatibility with Legacy 596 Devices", draft-peng-spring-srv6-compatibility-02 (work in 597 progress), January 2020. 599 Authors' Addresses 601 Weiqiang Cheng 602 China Mobile 604 Email: chengweiqiang@chinamobile.com 606 Chongfeng 607 China Telecom 609 Email: xiechf.bri@chinatelecom.cn 611 Ran Pang 612 China Unicom 614 Email: pangran@chinaunicom.cn 616 Zhenbin Li 617 Huawei Technologies 619 Email: lizhenbin@huawei.com 621 Ran Chen 622 ZTE Corporation 624 Email: chen.ran@zte.com.cn 626 Lijun 627 Unionpay 629 Email: zulijun@unionpay.com 631 Xiaodong Duan 632 China Mobile 634 Email: duanxiaodong@chinamobile.com 635 Greg Mirsk 636 ZTE Corporation 638 Email: gregimirsky@gmail.com