idnits 2.17.1 draft-srcompdt-spring-compression-requirement-02.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 (November 16, 2020) is 1257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-08 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-04 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Informational November 16, 2020 5 Expires: May 20, 2021 7 Compressed SRv6 SID List Requirements 8 draft-srcompdt-spring-compression-requirement-02 10 Abstract 12 This document specifies requirements for solutions to compress SRv6 13 SID lists. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 20, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 3 51 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. SRv6 SID List Compression Requirements . . . . . . . . . . . 4 54 3.1. Dataplane Efficiency and Performance Requirements . . . . 4 55 3.1.1. Encapsulation Header Size . . . . . . . . . . . . . . 4 56 3.1.2. Forwarding Efficiency . . . . . . . . . . . . . . . . 5 57 3.1.3. State Efficiency . . . . . . . . . . . . . . . . . . 5 58 4. SRv6 Specific Requirements . . . . . . . . . . . . . . . . . 5 59 4.1. Functional Requirements . . . . . . . . . . . . . . . . . 5 60 4.1.1. SID list length . . . . . . . . . . . . . . . . . . . 5 61 4.1.2. SID summarization . . . . . . . . . . . . . . . . . . 6 62 4.2. Operational Requirements . . . . . . . . . . . . . . . . 6 63 4.2.1. Lossless Compression . . . . . . . . . . . . . . . . 6 64 4.3. Scalability Requirements . . . . . . . . . . . . . . . . 6 65 4.3.1. Adjacency segment scale . . . . . . . . . . . . . . . 6 66 4.3.2. Prefix segment scale . . . . . . . . . . . . . . . . 7 67 4.3.3. Service Scale . . . . . . . . . . . . . . . . . . . . 7 68 5. Protocol Design Requirements . . . . . . . . . . . . . . . . 7 69 5.1. SRv6 Base Coexistence . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Appendix A. Proposed Requirements . . . . . . . . . . . . . . . 10 75 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10 76 A.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 10 77 A.2.1. SRv6 Based . . . . . . . . . . . . . . . . . . . . . 10 78 A.2.2. SRv6 Functionality . . . . . . . . . . . . . . . . . 11 79 A.2.3. Heterogeneous SID lists . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The SPRING working group defined SRv6, with [RFC8402] describing how 85 the Segment Routing (SR) architecture is instantiated on two data- 86 planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). SRv6 uses a 87 routing header called the SR Header (SRH) [RFC8754] and defines SRv6 88 SID behaviors and a registry for identifying them in 89 [I-D.ietf-spring-srv6-network-programming]. SRv6 is a proposed 90 standard and is deployed today. 92 The SPRING working group has observed that some use cases, such as 93 strict path TE, may require long SRv6 SID lists. There are several 94 proposed methods to reduce the resulting SRv6 encapsulation size by 95 compressing the SID list. 97 The SPRING working group formed a design team to define requirements 98 for, and analyze proposals to, compress SRv6 SID lists. 100 It is a goal of the design team to identify the requirements for 101 proposals to SR over IPv6 SID list compression. 103 For each requirement, a description, rationale and metrics are 104 described. 106 The design team will produce a separate document to analyze the 107 proposals. 109 This document is a draft; additional requirements are under review, 110 additional requirements will be added, and current requirements may 111 change. Appendix A contains a subset of requirements without 112 unanimous consensus. Additional requirements without unanimous 113 consensus are not in the appendix. 115 2. Conventions used in this document 117 2.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2.2. Terminology 127 SR: Segment Routing 129 SRH: Segment Routing Header 131 MPLS: Multiprotocol Label Switching 133 SR-MPLS: Segment Routing over MPLS data plane 135 SID: Segment Identifier 137 SRv6: Segment Routing over IPv6 139 SRv6 SID List: A list of SRv6 SIDs 141 Compression proposal: A proposal to compress SRv6 SID lists 142 SRv6 base: SRv6 as defined in [RFC8402], [RFC8754], 143 [I-D.ietf-spring-srv6-network-programming] 145 SID numbering space: may be implemented as 147 o a single IGP instance 149 o a single IGP level or area 151 o two or more autonomous systems that coordinate SID numbering space 153 o two or more IGP instances that coordinate SID numbering space 155 SRv6 Encapsulation Header: The IPv6 header, and any extension headers 156 preceding a payload, used to implement a SRv6 base or compression 157 proposal. 159 3. SRv6 SID List Compression Requirements 161 3.1. Dataplane Efficiency and Performance Requirements 163 3.1.1. Encapsulation Header Size 165 Description: The compression proposal MUST reduce the size of the 166 SRv6 encapsulation header. 168 Rationale: A smaller SRv6 encapsulation results in better MTU 169 efficiency. 171 Metric: Compression is the ratio of the IPv6 encapsulation size of 172 SRv6 as defined in [RFC8402], [RFC8754], 173 [I-D.ietf-spring-srv6-network-programming] vs the IPv6 encapsulation 174 size of a given proposal. The encapsulation savings of a compression 175 proposal vs the SRv6 base is a useful measurement to compare 176 proposals. 178 The encapsulation metric (E) records the number of bytes required for 179 a proposal to encapsulate a packet given a specific segment list. 181 o E(proposal, segment list). 183 The encapsulation savings(ES)records the encapsulation savings for a 184 proposal to encapsulate a packet given a specific segment list. 186 o ES(proposal, segment list) = 1 - E(proposal, segment list)/E(SRv6 187 base, segment list). 189 3.1.2. Forwarding Efficiency 191 Description: The compression proposal SHOULD minimize the number of 192 required hardware resources accessed to process a segment. 194 Rationale: Efficiency in bits on the wire and processing efficiency 195 are both important. Optimizing one at the expense of the other may 196 lead to significant performance impact. 198 Metric: The data plane efficiency metric (D) records the data plane 199 forwarding efficiency of the proposed solution. Two metrics are used 200 and recorded at each segment endpoint: 202 o D.PRS(segment list): number of headers parsed during processing of 203 the segment list, starting from and including the IPv6 header. 205 o D.LKU(segment list): number of FIB lookups during processing of 206 the segment list. The type of lookup is also recorded as longest 207 prefix match (LPM) or exact match (EM) 209 3.1.3. State Efficiency 211 Description: The compression proposal SHOULD minimize the amount of 212 additional forwarding state stored at a node. 214 Rationale: Additional state increases the complexity of the control 215 plane and data plane. It can also result in an increase in memory 216 usage. 218 Metric: The state efficiency metric (S) records the amount of 219 additional forwarding state required by the proposed solution. 221 o S(node parameters): the number of additional forwarding states 222 that need to be stored at a node, given a set of node parameters 223 consisting of the number of nodes in the network, number of local 224 interfaces, number of adjacencies. The forwarding state is 225 counted as entries required in a Forwarding Information Base (FIB) 226 at a node. 228 4. SRv6 Specific Requirements 230 4.1. Functional Requirements 232 4.1.1. SID list length 234 Description: The compression proposal MUST be able to represent SR 235 paths that contain up to 16 segments. 237 Rationale: Strict TE paths require SID list lengths proportional to 238 the diameter of the SR domain. 240 Metric: The compression proposal must be able to steer a packet 241 through an SR path that contains up to sixteen segments. 243 4.1.2. SID summarization 245 Description: The solution MUST be compatible with segment 246 summarization. 248 Rationale: Summarization of segments is a key benefit of SRv6 vs SR 249 MPLS. In interdomain deployments, any node can reach any other node 250 via a single prefix segment. Without summarization, border router 251 SIDs must be leaked, and an additional global prefix segment is 252 required for each domain border to be traversed. 254 Metric: A solution supports summarization when segments can be 255 summarized for advertisement into other IGP domains or levels. 257 4.2. Operational Requirements 259 4.2.1. Lossless Compression 261 Description: The segments of the compressed SID list MUST be 262 equivalent to the original SID List. For example, a strict path TE 263 SID List is not compressed to a loose path TE SID list. 265 Rationale: In SRv6, we can represent a path to meet certain 266 objectives. A compression proposal needs to support the objectives 267 with the same path. 269 Metric: Information present in the pre-compression segment list MUST 270 also be present in the post-compression SID list. 272 4.3. Scalability Requirements 274 4.3.1. Adjacency segment scale 276 Description: The compression proposal MUST be capable of representing 277 65000 adjacency segments per node 279 Rationale: Typically, network operators deploy networks with tens or 280 hundreds of adjacency segments per node, but some network operators 281 may deploy networks that use more adjacency segments per node. 283 Metric: A proposal that allows 65000 adjacency segments per node 284 satisfies this requirement. 286 4.3.2. Prefix segment scale 288 Description: The compression proposal MUST be capable of representing 289 1 million prefix segments per SID numbering space. 291 Rationale: Typically, network operators deploy networks with 292 thousands of prefix segments per SID numbering space, but some 293 network operators may deploy networks that use more prefix segments 294 per SID numbering space. 296 Metric: A proposal that allows 1 million prefix segments per SID 297 numbering space satisfies this requirement. 299 4.3.3. Service Scale 301 Description: The compression proposal MUST be capable of representing 302 1 million services per node. 304 Rationale: Typically, network operators deploy networks with tens to 305 hundreds of thousands of services per node, but some network 306 operators may deploy networks that use more services per node. 308 Metric: A proposal that allows 1 million services per node satisfies 309 this requirement. 311 5. Protocol Design Requirements 313 5.1. SRv6 Base Coexistence 315 Description: The compression proposal MUST support deployment in 316 existing SRv6 networks. 318 Rationale: SRv6 is deployed today. A compression proposal that 319 interoperates well with SRv6, as deployed, will reduce the overhead 320 and simplify operations. For Network operators who would migrate to 321 compressed SRv6 SID lists, the migration is expected to gradually 322 occur over a period of time as they upgrade networks, domains, device 323 families and software instances. 325 Metric: A compliant compression proposal provides the following 327 o Supports simultaneous deployment at a node with current SRv6 SIDs. 329 o Supports simultaneous deployment at a node with current SRv6 330 control plane. 332 o Supports simultaneous operation of current SRv6 paths with 333 compressed paths. 335 o Supports the behaviors in 336 [I-D.ietf-spring-srv6-network-programming]. 338 o Does not require removal of existing IPv6 address planning. 340 6. IANA Considerations 342 This document has no requests to IANA. 344 7. Security Considerations 346 TBD 348 8. Contributors 350 The following individuals contributed to this draft 352 Chongfeng Xie, China Telecom, xiechf@chinatelecom.cn 354 Ron Bonica, Juniper Networks, rbonica@juniper.net 356 Darren Dukes, Cisco Systems, ddukes@cisco.com 358 Cheng Li, Huawei, c.l@huawei.com 360 Peng Shaofu, ZTE, peng.shaofu@zte.com.cn 362 Wim Henderickx, Nokia, wim.henderickx@nokia.com 364 Sanders Steffann, SJM Steffann Consultancy, sander@steffann.nl 366 9. Normative References 368 [I-D.ietf-6man-spring-srv6-oam] 369 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 370 Chen, "Operations, Administration, and Maintenance (OAM) 371 in Segment Routing Networks with IPv6 Data plane (SRv6)", 372 draft-ietf-6man-spring-srv6-oam-08 (work in progress), 373 October 2020. 375 [I-D.ietf-bess-srv6-services] 376 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 377 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 378 Overlay services", draft-ietf-bess-srv6-services-05 (work 379 in progress), November 2020. 381 [I-D.ietf-idr-bgpls-srv6-ext] 382 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 383 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 384 State Extensions for SRv6", draft-ietf-idr-bgpls- 385 srv6-ext-04 (work in progress), November 2020. 387 [I-D.ietf-lsr-flex-algo] 388 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 389 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 390 algo-13 (work in progress), October 2020. 392 [I-D.ietf-lsr-isis-srv6-extensions] 393 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 394 Z. Hu, "IS-IS Extension to Support Segment Routing over 395 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 396 (work in progress), October 2020. 398 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 399 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 400 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 401 "Topology Independent Fast Reroute using Segment Routing", 402 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 403 progress), August 2020. 405 [I-D.ietf-spring-segment-routing-policy] 406 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 407 P. Mattes, "Segment Routing Policy Architecture", draft- 408 ietf-spring-segment-routing-policy-09 (work in progress), 409 November 2020. 411 [I-D.ietf-spring-sr-service-programming] 412 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 413 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 414 Henderickx, W., and S. Salsano, "Service Programming with 415 Segment Routing", draft-ietf-spring-sr-service- 416 programming-03 (work in progress), September 2020. 418 [I-D.ietf-spring-srv6-network-programming] 419 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 420 Matsushima, S., and Z. Li, "SRv6 Network Programming", 421 draft-ietf-spring-srv6-network-programming-24 (work in 422 progress), October 2020. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 430 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 431 May 2017, . 433 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 434 Decraene, B., Litkowski, S., and R. Shakir, "Segment 435 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 436 July 2018, . 438 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 439 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 440 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 441 . 443 Appendix A. Proposed Requirements 445 This appendix contains requirements that the design team discussed 446 but could not be agreed upon. 448 A.1. Introduction 450 It is a goal of the design team to identify solutions to SRv6 SID 451 list compression that are based on the SRv6 standards. As such, this 452 document provides requirements for SRv6 SID list compression 453 solutions that utilize the existing SRv6 data plane and control 454 plane. 456 It is also a goal of the design team to consider proposals that are 457 not based on the SRv6 data plane and control plane. As such, this 458 document includes requirements to evaluate whether a compression 459 proposal provides all the functionality of SRv6 (section "SRv6 460 Functionality") in addition to satisfying compression specific 461 requirements. 463 A.2. Requirements 465 A.2.1. SRv6 Based 467 Description: A solution to compress SRv6 SID Lists SHOULD be based on 468 the SRv6 architecture, control plane and data plane. 470 Rationale: A compression proposal built on existing IETF standards is 471 preferable to creating new standards with equivalent functionality 472 and performance. 474 Metric: The utilization metric (U) records whether a proposal 475 utilizes the SRv6 specifications. 477 Utilization is recorded in a table, with a column per proposal and 478 rows consisting of the following metrics: 480 o U.RFC8402: utilizes [RFC8402]. 482 o U.RFC8754: utilizes [RFC8754]. 484 o U.PGM: utilizes [I-D.ietf-spring-srv6-network-programming]. 486 o U.IGP: utilizes [I-D.ietf-lsr-isis-srv6-extensions]. 488 o U.BGP: utilizes [I-D.ietf-bess-srv6-services]. 490 o U.POL: utilizes [I-D.ietf-spring-segment-routing-policy]. 492 o U.BLS: utilizes [I-D.ietf-idr-bgpls-srv6-ext]. 494 o U.SVC: utilizes [I-D.ietf-spring-sr-service-programming]. 496 o U.OAM: utilizes [I-D.ietf-6man-spring-srv6-oam]. 498 o U.ALG: utilizes [I-D.ietf-lsr-flex-algo]. 500 o U.TOT: the total number of specifications utilized. 502 Each cell contains "yes" for utilizes, or "no" for does not utilize. 503 U.TOT counts the number of "yes" in each column. 505 A.2.2. SRv6 Functionality 507 Description: A solution to compress an SRv6 SID list MUST support the 508 functionality of SRv6. This requirement and set of metrics is meant 509 to assess whether a proposal that is not fully SRv6 based, as 510 evaluated in section "SRv6 Based", provides equivalent functionality 511 to SRv6. Such a proposal may utilize different control planes and or 512 data planes. 514 Rationale: Operators require SRv6 functionality. Evaluating the 515 extent to which a proposal supports SRv6 functionality is important 516 for operators and implementors to understand the impact on network 517 operations. 519 Metric: The Functionality metric (F) records whether a proposal 520 supports SRv6 functionality and how the functionality is provided. 522 Functionality is recorded in a table with columns for each proposal 523 and rows consisting of the following metrics: 525 o F.SID: Supports SRv6 SIDs described in [RFC8402] 527 o F.SCOPE: Supports globally and locally scoped SIDs described in 528 [RFC8402] 530 o F.PFX: Supports prefix SIDs described in [RFC8402] and 531 [I-D.ietf-spring-srv6-network-programming] 533 o F.ADJ: Supports adjacency SIDs described in [RFC8402] and 534 [I-D.ietf-spring-srv6-network-programming] 536 o F.BIND: Supports binding SIDs described in [RFC8402] and 537 [I-D.ietf-spring-srv6-network-programming] 539 o F.PEER: Supports BGP peering SIDs described in [RFC8402] and 540 [I-D.ietf-spring-srv6-network-programming] 542 o F.SVC: Supports L3 and L2 VPN service SIDs described in 543 [I-D.ietf-spring-srv6-network-programming] 545 o F.ALG: Supports flexible algorithms described in 546 [I-D.ietf-lsr-flex-algo] 548 o F.TILFA: Supports TI-LFA as described in 549 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 551 o F.SEC: Supports securing an SR domain with ingress filtering as 552 defined in [RFC8754] 554 o F.IGP: Supports distributing topological SIDs and behaviors via 555 ISIS as described in [I-D.ietf-lsr-isis-srv6-extensions] 557 o F.BGP: Supports BGP VPNs as described in 558 [I-D.ietf-bess-srv6-services] 560 o F.POL: Supports SR policies and steering traffic over those 561 policies as described in [I-D.ietf-spring-segment-routing-policy] 563 o F.BLS: Supports Link State distribution via BGP as described in 564 [I-D.ietf-idr-bgpls-srv6-ext] 566 o F.SFC: Supports stateless service programming as described in 567 [I-D.ietf-spring-sr-service-programming] 569 o F.PING: Supports pinging a SID to verify the SID is implemented as 570 described in [I-D.ietf-6man-spring-srv6-oam] 572 o F.TOT: The total number of SRv6 functionality metrics supported by 573 a proposal 575 Each cell contains the specification name documenting the 576 functionality. F.TOT counts the number of specifications in each 577 column. 579 A.2.3. Heterogeneous SID lists 581 Description: The compression proposal SHOULD support a combination of 582 compressed and non-compressed segments in a single path. 584 Rationale: Support of SID lists with compressed and non-compressed 585 SIDs reduces encapsulation size when not all SRv6 nodes deploy the 586 compression proposal or 128-bit SIDs are required. 588 Metric: A compliant compression proposal supports both: 590 o classic 128-bit SRv6 SIDs in the IPv6 Destination Address field 592 o segment lists (i.e., paths) with both compressed and 128-bit SRv6 593 SIDs. 595 Author's Address 597 Weiqiang Cheng 598 China Mobile 600 Email: chengweiqiang@chinamobile.com