idnits 2.17.1 draft-srcompdt-spring-compression-requirement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2021) is 1200 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-05 == 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-05 == 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 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 W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Informational January 12, 2021 5 Expires: July 16, 2021 7 Compressed SRv6 SID List Requirements 8 draft-srcompdt-spring-compression-requirement-03 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 July 16, 2021. 32 Copyright Notice 34 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . 6 59 4.1. SRv6 Based . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Functional Requirements . . . . . . . . . . . . . . . . . 6 61 4.2.1. SRv6 Functionality . . . . . . . . . . . . . . . . . 6 62 4.2.2. Heterogeneous SID lists . . . . . . . . . . . . . . . 8 63 4.2.3. SID list length . . . . . . . . . . . . . . . . . . . 8 64 4.2.4. SID summarization . . . . . . . . . . . . . . . . . . 9 65 4.3. Operational Requirements . . . . . . . . . . . . . . . . 9 66 4.3.1. Lossless Compression . . . . . . . . . . . . . . . . 9 67 4.4. Scalability Requirements . . . . . . . . . . . . . . . . 9 68 4.4.1. Adjacency segment scale . . . . . . . . . . . . . . . 9 69 4.4.2. Prefix segment scale . . . . . . . . . . . . . . . . 9 70 4.4.3. Service Scale . . . . . . . . . . . . . . . . . . . . 10 71 5. Protocol Design Requirements . . . . . . . . . . . . . . . . 10 72 5.1. SRv6 Base Coexistence . . . . . . . . . . . . . . . . . . 10 73 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 74 6.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 11 75 6.2. SR Domain Protection . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 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 solutions to SRv6 SID 101 list compression that are based on the SRv6 standards. As such, this 102 document provides requirements for SRv6 SID list compression 103 solutions that utilize the existing SRv6 data plane and control 104 plane. 106 It is also a goal of the design team to consider proposals that are 107 not based on the SRv6 data plane and control plane. As such, this 108 document includes requirements to evaluate whether a compression 109 proposal provides all the functionality of SRv6 (section "SRv6 110 Functionality") in addition to satisfying compression specific 111 requirements. 113 For each requirement, a description, rationale and metrics are 114 described. 116 The design team will produce a separate document to analyze the 117 proposals. 119 This document is a draft; additional requirements are under review, 120 additional requirements will be added, and current requirements may 121 change. Appendix A contains a subset of requirements without 122 unanimous consensus. Additional requirements without unanimous 123 consensus are not in the appendix. 125 2. Conventions used in this document 127 2.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2.2. Terminology 137 SR: Segment Routing 139 SRH: Segment Routing Header 141 MPLS: Multiprotocol Label Switching 142 SR-MPLS: Segment Routing over MPLS data plane 144 SID: Segment Identifier 146 SRv6: Segment Routing over IPv6 148 SRv6 SID List: A list of SRv6 SIDs 150 Compression proposal: A proposal to compress SRv6 SID lists 152 SRv6 base: SRv6 as defined in [RFC8402], [RFC8754], 153 [I-D.ietf-spring-srv6-network-programming] 155 SID numbering space: may be implemented as 157 o a single IGP instance 159 o a single IGP level or area 161 o two or more autonomous systems that coordinate SID numbering space 163 o two or more IGP instances that coordinate SID numbering space 165 SRv6 Encapsulation Header: The IPv6 header, and any extension headers 166 preceding a payload, used to implement a SRv6 base or compression 167 proposal. 169 3. SRv6 SID List Compression Requirements 171 3.1. Dataplane Efficiency and Performance Requirements 173 3.1.1. Encapsulation Header Size 175 Description: The compression proposal MUST reduce the size of the 176 SRv6 encapsulation header. 178 Rationale: A smaller SRv6 encapsulation results in better MTU 179 efficiency. 181 Metric: Compression is the ratio of the IPv6 encapsulation size of 182 SRv6 as defined in [RFC8402], [RFC8754], 183 [I-D.ietf-spring-srv6-network-programming] vs the IPv6 encapsulation 184 size of a given proposal. The encapsulation savings of a compression 185 proposal vs the SRv6 base is a useful measurement to compare 186 proposals. 188 The encapsulation metric (E) records the number of bytes required for 189 a proposal to encapsulate a packet given a specific segment list. 191 o E(proposal, segment list). 193 The encapsulation savings(ES)records the encapsulation savings for a 194 proposal to encapsulate a packet given a specific segment list. 196 o ES(proposal, segment list) = 1 - E(proposal, segment list)/E(SRv6 197 base, segment list). 199 3.1.2. Forwarding Efficiency 201 Description: The compression proposal SHOULD minimize the number of 202 required hardware resources accessed to process a segment. 204 Rationale: Efficiency in bits on the wire and processing efficiency 205 are both important. Optimizing one at the expense of the other may 206 lead to significant performance impact. 208 Metric: The data plane efficiency metric (D) records the data plane 209 forwarding efficiency of the proposed solution. Two metrics are used 210 and recorded at each segment endpoint: 212 o D.PRS(segment list): number of headers parsed during processing of 213 the segment list, starting from and including the IPv6 header. 215 o D.LKU(segment list): number of FIB lookups during processing of 216 the segment list. The type of lookup is also recorded as longest 217 prefix match (LPM) or exact match (EM) 219 3.1.3. State Efficiency 221 Description: The compression proposal SHOULD minimize the amount of 222 additional forwarding state stored at a node. 224 Rationale: Additional state increases the complexity of the control 225 plane and data plane. It can also result in an increase in memory 226 usage. 228 Metric: The state efficiency metric (S) records the amount of 229 additional forwarding state required by the proposed solution. 231 o S(node parameters): the number of additional forwarding states 232 that need to be stored at a node, given a set of node parameters 233 consisting of the number of nodes in the network, number of local 234 interfaces, number of adjacencies. The forwarding state is 235 counted as entries required in a Forwarding Information Base (FIB) 236 at a node. 238 4. SRv6 Specific Requirements 240 4.1. SRv6 Based 242 Description: A solution to compress SRv6 SID Lists SHOULD be based on 243 the SRv6 architecture, control plane and data plane. The compression 244 solution MAY be based on a different data plane and control plane, 245 provided that it derives sufficient benefit. 247 Rationale: A compression proposal built on existing IETF standards is 248 preferable to creating new standards with equivalent functionality 249 and performance. 251 Metric: The utilization metric (U) records whether a proposal 252 utilizes the SRv6 specifications. 254 Utilization is recorded in a table, with a column per proposal and 255 rows consisting of the following metrics: 257 o U.RFC8402: utilizes [RFC8402]. 259 o U.RFC8754: utilizes [RFC8754]. 261 o U.PGM: utilizes [I-D.ietf-spring-srv6-network-programming]. 263 o U.IGP: utilizes [I-D.ietf-lsr-isis-srv6-extensions]. 265 o U.BGP: utilizes [I-D.ietf-bess-srv6-services]. 267 o U.POL: utilizes [I-D.ietf-spring-segment-routing-policy]. 269 o U.BLS: utilizes [I-D.ietf-idr-bgpls-srv6-ext]. 271 o U.SVC: utilizes [I-D.ietf-spring-sr-service-programming]. 273 o U.OAM: utilizes [I-D.ietf-6man-spring-srv6-oam]. 275 o U.ALG: utilizes [I-D.ietf-lsr-flex-algo]. 277 Each cell contains "yes" for utilizes, or "no" for does not utilize. 279 4.2. Functional Requirements 281 4.2.1. SRv6 Functionality 283 Description: A solution to compress an SRv6 SID list MUST support the 284 functionality of SRv6. This requirement ensures no SRv6 285 functionality is lost. It is particularly important to understand 286 how a proposal, as evaluated in section "SRv6 Based", provides this 287 functionality. 289 Rationale: Operators require SRv6 functionality. Evaluating the 290 extent to which a proposal supports SRv6 functionality is important 291 for operators and implementors to understand the impact on network 292 operations. 294 Metric: The Functionality metric (F) records whether a proposal 295 supports SRv6 functionality and how the functionality is provided. 297 Functionality is recorded in a table with columns for each proposal 298 and rows consisting of the following metrics: 300 o F.SID: Supports SRv6 SID functionality as described in [RFC8402] 302 o F.SCOPE: Supports globally and locally scoped SID functionality as 303 described in [RFC8402] 305 o F.PFX: Supports prefix SID functionality as described in [RFC8402] 306 and [I-D.ietf-spring-srv6-network-programming] 308 o F.ADJ: Supports adjacency SID functionality as described in 309 [RFC8402] and [I-D.ietf-spring-srv6-network-programming] 311 o F.BIND: Supports binding SID functionality as described in 312 [RFC8402] and [I-D.ietf-spring-srv6-network-programming] 314 o F.PEER: Supports BGP peering SID functionality as described in 315 [RFC8402] and [I-D.ietf-spring-srv6-network-programming] 317 o F.SVC: Supports L3 and L2 VPN service SID functionality as 318 described in [I-D.ietf-spring-srv6-network-programming] 320 o F.ALG: Supports flexible algorithms functionality as described in 321 [I-D.ietf-lsr-flex-algo] 323 o F.TILFA: Supports TI-LFA functionality as described in 324 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 326 o F.SEC: Supports securing an SR domain with ingress filtering as 327 functionally defined in [RFC8754] 329 o F.IGP: Supports distributing topological SIDs and behaviors via 330 ISIS as functionally described in 331 [I-D.ietf-lsr-isis-srv6-extensions] 333 o F.BGP: Supports BGP VPNs as functionally described in 334 [I-D.ietf-bess-srv6-services] 336 o F.POL: Supports SR policies and steering traffic over those 337 policies as funcitonally described in 338 [I-D.ietf-spring-segment-routing-policy] 340 o F.BLS: Supports Link State distribution via BGP as functionally 341 described in [I-D.ietf-idr-bgpls-srv6-ext] 343 o F.SFC: Supports stateless service programming as functionally 344 described in [I-D.ietf-spring-sr-service-programming] 346 o F.PING: Supports pinging a SID to verify the SID is implemented as 347 functionally described in [I-D.ietf-6man-spring-srv6-oam] 349 Each cell contains the specification name documenting the 350 functionality. 352 4.2.2. Heterogeneous SID lists 354 Description: The compression proposal SHOULD support a combination of 355 compressed and non-compressed segments in a single path. As an 356 example, a solution may satisfy this requirement without being SRv6 357 based by using a binding SID to impose an additional SRv6 header 358 (IPv6 header plus optional SRH) with non-compressed SID. 360 Rationale: Support of SID lists with compressed and non-compressed 361 SIDs reduces encapsulation size when not all SRv6 nodes deploy the 362 compression proposal or 128-bit SIDs are required. 364 Metric: A compliant compression proposal supports both: 366 o classic 128-bit SRv6 SIDs in the IPv6 Destination Address field 368 o segment lists (i.e., paths) with both compressed and 128-bit SRv6 369 SIDs. 371 4.2.3. SID list length 373 Description: The compression proposal MUST be able to represent SR 374 paths that contain up to 16 segments. 376 Rationale: Strict TE paths require SID list lengths proportional to 377 the diameter of the SR domain. 379 Metric: The compression proposal must be able to steer a packet 380 through an SR path that contains up to sixteen segments. 382 4.2.4. SID summarization 384 Description: The solution MUST be compatible with segment 385 summarization. 387 Rationale: Summarization of segments is a key benefit of SRv6 vs SR 388 MPLS. In interdomain deployments, any node can reach any other node 389 via a single prefix segment. Without summarization, border router 390 SIDs must be leaked, and an additional global prefix segment is 391 required for each domain border to be traversed. 393 Metric: A solution supports summarization when segments can be 394 summarized for advertisement into other IGP domains or levels. 396 4.3. Operational Requirements 398 4.3.1. Lossless Compression 400 Description: A path traversed using a compessed SID list MUST always 401 be the same as the path traversed using the uncompressed SID list if 402 no compression was applied. 404 Rationale: In SRv6, we can represent a path to meet certain 405 objectives. A compression proposal needs to support the objectives 406 with the same path. 408 Metric: Information present in the pre-compression segment list MUST 409 also be present in the post-compression SID list. 411 4.4. Scalability Requirements 413 4.4.1. Adjacency segment scale 415 Description: The compression proposal MUST be capable of representing 416 65000 adjacency segments per node 418 Rationale: Typically, network operators deploy networks with tens or 419 hundreds of adjacency segments per node, but some network operators 420 may deploy networks that use more adjacency segments per node. 422 Metric: A proposal that allows 65000 adjacency segments per node 423 satisfies this requirement. 425 4.4.2. Prefix segment scale 427 Description: The compression proposal MUST be capable of representing 428 1 million prefix segments per SID numbering space. 430 Rationale: Typically, network operators deploy networks with 431 thousands of prefix segments per SID numbering space, but some 432 network operators may deploy networks that use more prefix segments 433 per SID numbering space. 435 Metric: A proposal that allows 1 million prefix segments per SID 436 numbering space satisfies this requirement. 438 4.4.3. Service Scale 440 Description: The compression proposal MUST be capable of representing 441 1 million services per node. 443 Rationale: Typically, network operators deploy networks with tens to 444 hundreds of thousands of services per node, but some network 445 operators may deploy networks that use more services per node. 447 Metric: A proposal that allows 1 million services per node satisfies 448 this requirement. 450 5. Protocol Design Requirements 452 5.1. SRv6 Base Coexistence 454 Description: The compression proposal MUST support deployment in 455 existing SRv6 networks. 457 Rationale: SRv6 is deployed today. A compression proposal that 458 interoperates well with SRv6, as deployed, will reduce the overhead 459 and simplify operations. For Network operators who would migrate to 460 compressed SRv6 SID lists, the migration is expected to gradually 461 occur over a period of time as they upgrade networks, domains, device 462 families and software instances. 464 Metric: A compliant compression proposal provides the following 466 o Supports simultaneous deployment at a node with current SRv6 SIDs. 468 o Supports simultaneous deployment at a node with current SRv6 469 control plane. 471 o Supports simultaneous operation of current SRv6 paths with 472 compressed paths. 474 o Supports the behaviors in 475 [I-D.ietf-spring-srv6-network-programming]. 477 o Does not require removal of existing IPv6 address planning. 479 6. Security Requirements 481 6.1. Security Mechanisms 483 Description: The compression solution SHOULD be able to address 484 security issues that it introduces, using existing security 485 mechanisms. 487 Rationale: It is important to identify security issues and how to 488 address them in any specification. 490 Metric: A compression solution that does not introduce unresolved 491 security issues meets this requirement. 493 6.2. SR Domain Protection 495 Description: A compression solution must not require nodes outside 496 the SR domain to know SID values within the SR domain, and it must 497 provide the ability to block nodes outside an SR domain from 498 accessing SIDS. 500 Rationale: The unauthorized use of SIDs within the SR domain by nodes 501 outside the domain can disrupt an operators' network. 503 Metric: A compliant solution describes how access to SIDs within the 504 SR domain is denied to nodes outside the SR domain. 506 7. IANA Considerations 508 This document has no requests to IANA. 510 8. Security Considerations 512 TBD 514 9. Contributors 516 The following individuals contributed to this draft 518 Chongfeng Xie, China Telecom, xiechf@chinatelecom.cn 520 Ron Bonica, Juniper Networks, rbonica@juniper.net 522 Darren Dukes, Cisco Systems, ddukes@cisco.com 524 Cheng Li, Huawei, c.l@huawei.com 526 Peng Shaofu, ZTE, peng.shaofu@zte.com.cn 527 Wim Henderickx, Nokia, wim.henderickx@nokia.com 529 Sanders Steffann, SJM Steffann Consultancy, sander@steffann.nl 531 10. Normative References 533 [I-D.ietf-6man-spring-srv6-oam] 534 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 535 Chen, "Operations, Administration, and Maintenance (OAM) 536 in Segment Routing Networks with IPv6 Data plane (SRv6)", 537 draft-ietf-6man-spring-srv6-oam-08 (work in progress), 538 October 2020. 540 [I-D.ietf-bess-srv6-services] 541 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 542 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 543 Overlay services", draft-ietf-bess-srv6-services-05 (work 544 in progress), November 2020. 546 [I-D.ietf-idr-bgpls-srv6-ext] 547 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 548 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 549 State Extensions for SRv6", draft-ietf-idr-bgpls- 550 srv6-ext-05 (work in progress), November 2020. 552 [I-D.ietf-lsr-flex-algo] 553 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 554 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 555 algo-13 (work in progress), October 2020. 557 [I-D.ietf-lsr-isis-srv6-extensions] 558 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 559 Z. Hu, "IS-IS Extension to Support Segment Routing over 560 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 561 (work in progress), October 2020. 563 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 564 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 565 and D. Voyer, "Topology Independent Fast Reroute using 566 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 567 lfa-05 (work in progress), November 2020. 569 [I-D.ietf-spring-segment-routing-policy] 570 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 571 P. Mattes, "Segment Routing Policy Architecture", draft- 572 ietf-spring-segment-routing-policy-09 (work in progress), 573 November 2020. 575 [I-D.ietf-spring-sr-service-programming] 576 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 577 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 578 Henderickx, W., and S. Salsano, "Service Programming with 579 Segment Routing", draft-ietf-spring-sr-service- 580 programming-03 (work in progress), September 2020. 582 [I-D.ietf-spring-srv6-network-programming] 583 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 584 Matsushima, S., and Z. Li, "SRv6 Network Programming", 585 draft-ietf-spring-srv6-network-programming-28 (work in 586 progress), December 2020. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 595 May 2017, . 597 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 598 Decraene, B., Litkowski, S., and R. Shakir, "Segment 599 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 600 July 2018, . 602 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 603 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 604 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 605 . 607 Author's Address 609 Weiqiang Cheng 610 China Mobile 612 Email: chengweiqiang@chinamobile.com