idnits 2.17.1 draft-ietf-spring-compression-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Description: The compression mechanism requires every node along the packet's delivery path to be IPv6-capable. It MUST not require any node along the packet's forwarding path to support any other forwarding plane (e.g., IPv4, MPLS) -- The document date (March 29, 2022) is 751 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-09 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 Summary: 0 errors (**), 0 flaws (~~), 7 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 C. Xie 5 Expires: September 30, 2022 China Telecom 6 R. Bonica 7 Juniper 8 D. Dukes 9 Cisco Systems 10 C. Li 11 Huawei 12 P. Shaofu 13 ZTE 14 W. Henderickx 15 Nokia 16 March 29, 2022 18 Compressed SRv6 SID List Requirements 19 draft-ietf-spring-compression-requirement-01 21 Abstract 23 This document specifies requirements for solutions to compress SRv6 24 SID lists. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 30, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. SRv6 SID List Compression Requirements . . . . . . . . . . . 4 65 3.1. Dataplane Efficiency and Performance Requirements . . . . 4 66 3.1.1. Encapsulation Header Size . . . . . . . . . . . . . . 5 67 3.1.2. Forwarding Efficiency . . . . . . . . . . . . . . . . 5 68 3.1.3. State Efficiency . . . . . . . . . . . . . . . . . . 6 69 4. SRv6 Specific Requirements . . . . . . . . . . . . . . . . . 6 70 4.1. SRv6 Based . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Functional Requirements . . . . . . . . . . . . . . . . . 7 72 4.2.1. SRv6 Functionality . . . . . . . . . . . . . . . . . 7 73 4.2.2. Heterogeneous SID lists . . . . . . . . . . . . . . . 8 74 4.2.3. SID list length . . . . . . . . . . . . . . . . . . . 8 75 4.2.4. SID summarization . . . . . . . . . . . . . . . . . . 8 76 4.3. Operational Requirements . . . . . . . . . . . . . . . . 9 77 4.3.1. Lossless Compression . . . . . . . . . . . . . . . . 9 78 4.3.2. Preservation of non-routing information . . . . . . . 9 79 4.3.3. Address Planning . . . . . . . . . . . . . . . . . . 10 80 4.4. Scalability Requirements . . . . . . . . . . . . . . . . 10 81 4.4.1. Adjacency segment scale . . . . . . . . . . . . . . . 10 82 4.4.2. Prefix segment scale . . . . . . . . . . . . . . . . 11 83 4.4.3. Service Scale . . . . . . . . . . . . . . . . . . . . 11 84 4.4.4. Compression Levels . . . . . . . . . . . . . . . . . 11 85 5. Protocol Design Requirements . . . . . . . . . . . . . . . . 11 86 5.1. SRv6 Base Coexistence . . . . . . . . . . . . . . . . . . 11 87 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 88 6.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 12 89 6.2. SR Domain Protection . . . . . . . . . . . . . . . . . . 12 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 93 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 94 Appendix A. Proposed Requirements . . . . . . . . . . . . . . . 14 95 A.1. IPv6 Based . . . . . . . . . . . . . . . . . . . . . . . 14 96 A.2. Point to Multipoint . . . . . . . . . . . . . . . . . . . 15 97 A.3. Parsability . . . . . . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 The SPRING working group defined SRv6, with [RFC8402] describing how 103 the Segment Routing (SR) architecture is instantiated on two data- 104 planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). SRv6 uses a 105 routing header called the SR Header (SRH) [RFC8754] and defines SRv6 106 SID behaviors and a registry for identifying them in [RFC8986]. SRv6 107 is a proposed standard and is deployed today. 109 The SPRING working group has observed that some use cases, such as 110 strict path TE, may require long SRv6 SID lists. There are several 111 proposed methods to reduce the resulting SRv6 encapsulation size by 112 compressing the SID list. 114 The SPRING working group formed a design team to define requirements 115 for, and analyze proposals to, compress SRv6 SID lists. 117 It is a goal of the design team to identify solutions to SRv6 SID 118 list compression that are based on the SRv6 standards. As such, this 119 document provides requirements for SRv6 SID list compression 120 solutions that utilize the existing SRv6 data plane and control 121 plane. 123 It is also a goal of the design team to consider proposals that are 124 not based on the SRv6 data plane and control plane. As such, this 125 document includes requirements to evaluate whether a compression 126 proposal provides all the functionality of SRv6 (section "SRv6 127 Functionality") in addition to satisfying compression specific 128 requirements. 130 For each requirement, a description, rationale and metrics are 131 described. 133 The design team will produce a separate document to analyze the 134 proposals. 136 This document is a draft; additional requirements are under review, 137 additional requirements will be added, and current requirements may 138 change. Appendix A contains a subset of requirements without 139 unanimous consensus. Additional requirements without unanimous 140 consensus are not in the appendix. 142 2. Conventions used in this document 144 2.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 2.2. Terminology 154 SR: Segment Routing 156 SRH: Segment Routing Header 158 MPLS: Multiprotocol Label Switching 160 SR-MPLS: Segment Routing over MPLS data plane 162 SID: Segment Identifier 164 SRv6: Segment Routing over IPv6 166 SRv6 SID List: A list of SRv6 SIDs 168 Compression proposal: A proposal to compress SRv6 SID lists 170 SRv6 base: SRv6 as defined in [RFC8402], [RFC8754], [RFC8986] 172 SID numbering space: may be implemented as 174 o a single IGP instance 175 o a single IGP level or area 176 o two or more autonomous systems that coordinate SID numbering space 177 o two or more IGP instances that coordinate SID numbering space 179 SRv6 Encapsulation Header: The IPv6 header, and any extension headers 180 preceding a payload, used to implement a SRv6 base or compression 181 proposal. 183 3. SRv6 SID List Compression Requirements 185 3.1. Dataplane Efficiency and Performance Requirements 186 3.1.1. Encapsulation Header Size 188 Description: The compression proposal MUST reduce the size of the 189 SRv6 encapsulation header. 191 Rationale: A smaller SRv6 encapsulation results in better MTU 192 efficiency. 194 Metric: Compression is the ratio of the IPv6 encapsulation size of 195 SRv6 as defined in [RFC8402], [RFC8754], [RFC8986] vs the IPv6 196 encapsulation size of a given proposal. The encapsulation savings of 197 a compression proposal vs the SRv6 base is a useful measurement to 198 compare proposals. 200 The encapsulation metric (E) records the number of bytes required for 201 a proposal to encapsulate a packet given a specific segment list. 203 o E(proposal, segment list). 205 The encapsulation savings(ES)records the encapsulation savings for a 206 proposal to encapsulate a packet given a specific segment list. 208 o ES(proposal, segment list) = 1 - E(proposal, segment list)/E(SRv6 209 base, segment list). 211 3.1.2. Forwarding Efficiency 213 Description: The compression proposal SHOULD minimize the number of 214 required hardware resources accessed to process a segment. 216 Rationale: Efficiency in bits on the wire and processing efficiency 217 are both important. Optimizing one at the expense of the other may 218 lead to significant performance impact. 220 Metric: The data plane efficiency metric (D) records the data plane 221 forwarding efficiency of the proposed solution. Two metrics are used 222 and recorded at each segment endpoint: 224 o D.PRS(segment list): number of headers parsed during processing of 225 the segment list, starting from and including the IPv6 header. 226 o D.LKU(segment list): number of FIB lookups during processing of 227 the segment list. The type of lookup is also recorded as longest 228 prefix match (LPM) or exact match (EM) 230 3.1.3. State Efficiency 232 Description: The compression proposal SHOULD minimize the amount of 233 additional forwarding state stored at a node. 235 Rationale: Additional state increases the complexity of the control 236 plane and data plane. It can also result in an increase in memory 237 usage. 239 Metric: The state efficiency metric (S) records the amount of 240 additional forwarding state required by the proposed solution. 242 o S(node parameters): the number of additional forwarding states 243 that need to be stored at a node, given a set of node parameters 244 consisting of the number of nodes in the network, number of local 245 interfaces, number of adjacencies. The forwarding state is 246 counted as entries required in a Forwarding Information Base (FIB) 247 at a node. 249 4. SRv6 Specific Requirements 251 4.1. SRv6 Based 253 Description: A solution to compress SRv6 SID Lists SHOULD be based on 254 the SRv6 architecture, control plane and data plane. The compression 255 solution MAY be based on a different data plane and control plane, 256 provided that it derives sufficient benefit. 258 Rationale: A compression proposal built on existing IETF standards is 259 preferable to creating new standards with equivalent functionality 260 and performance. 262 Metric: The utilization metric (U) records whether a proposal 263 utilizes the SRv6 specifications. 265 Utilization is recorded in a table, with a column per proposal and 266 rows consisting of the following metrics: 268 o U.RFC8402: utilizes [RFC8402]. 269 o U.RFC8754: utilizes [RFC8754]. 270 o U.PGM: utilizes [RFC8986]. 271 o U.IGP: utilizes [I-D.ietf-lsr-isis-srv6-extensions]. 272 o U.BGP: utilizes [I-D.ietf-bess-srv6-services]. 273 o U.POL: utilizes [I-D.ietf-spring-segment-routing-policy]. 274 o U.BLS: utilizes [I-D.ietf-idr-bgpls-srv6-ext]. 275 o U.SVC: utilizes [I-D.ietf-spring-sr-service-programming]. 276 o U.OAM: utilizes [I-D.ietf-6man-spring-srv6-oam]. 277 o U.ALG: utilizes [I-D.ietf-lsr-flex-algo]. 279 Each cell contains "yes" for utilizes, or "no" for does not utilize. 281 4.2. Functional Requirements 283 4.2.1. SRv6 Functionality 285 Description: A solution to compress an SRv6 SID list MUST support the 286 functionality of SRv6. This requirement ensures no SRv6 287 functionality is lost. It is particularly important to understand 288 how a proposal, as evaluated in section "SRv6 Based", provides this 289 functionality. 291 Rationale: Operators require SRv6 functionality. Evaluating the 292 extent to which a proposal supports SRv6 functionality is important 293 for operators and implementors to understand the impact on network 294 operations. 296 Metric: The Functionality metric (F) records whether a proposal 297 supports SRv6 functionality and how the functionality is provided. 299 Functionality is recorded in a table with columns for each proposal 300 and rows consisting of the following metrics: 302 o F.SID: Supports SRv6 SID functionality as described in [RFC8402] 303 o F.SCOPE: Supports globally and locally scoped SID functionality as 304 described in [RFC8402] 305 o F.PFX: Supports prefix SID functionality as described in [RFC8402] 306 and [RFC8986] 307 o F.ADJ: Supports adjacency SID functionality as described in 308 [RFC8402] and [RFC8986] 309 o F.BIND: Supports binding SID functionality as described in 310 [RFC8402] and [RFC8986] 311 o F.PEER: Supports BGP peering SID functionality as described in 312 [RFC8402] and [RFC8986] 313 o F.SVC: Supports L3 and L2 VPN service SID functionality as 314 described in [RFC8986] 315 o F.ALG: Supports flexible algorithms functionality as described in 316 [I-D.ietf-lsr-flex-algo] 317 o F.TILFA: Supports TI-LFA functionality as described in 318 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 319 o F.SEC: Supports securing an SR domain with ingress filtering as 320 functionally defined in [RFC8754] 321 o F.IGP: Supports distributing topological SIDs and behaviors via 322 ISIS as functionally described in 323 [I-D.ietf-lsr-isis-srv6-extensions] 324 o F.BGP: Supports BGP VPNs as functionally described in 325 [I-D.ietf-bess-srv6-services] 327 o F.POL: Supports SR policies and steering traffic over those 328 policies as funcitonally described in 329 [I-D.ietf-spring-segment-routing-policy] 330 o F.BLS: Supports Link State distribution via BGP as functionally 331 described in [I-D.ietf-idr-bgpls-srv6-ext] 332 o F.SFC: Supports stateless service programming as functionally 333 described in [I-D.ietf-spring-sr-service-programming] 334 o F.PING: Supports pinging a SID to verify the SID is implemented as 335 functionally described in [I-D.ietf-6man-spring-srv6-oam] 337 Each cell contains the specification name documenting the 338 functionality. 340 4.2.2. Heterogeneous SID lists 342 Description: The compression proposal SHOULD support a combination of 343 compressed and non-compressed segments in a single path. As an 344 example, a solution may satisfy this requirement without being SRv6 345 based by using a binding SID to impose an additional SRv6 header 346 (IPv6 header plus optional SRH) with non-compressed SID. 348 Rationale: Support of SID lists with compressed and non-compressed 349 SIDs reduces encapsulation size when not all SRv6 nodes deploy the 350 compression proposal or 128-bit SIDs are required. 352 Metric: A compliant compression proposal supports both: 354 o classic 128-bit SRv6 SIDs in the IPv6 Destination Address field 355 o segment lists (i.e., paths) with both compressed and 128-bit SRv6 356 SIDs. 358 4.2.3. SID list length 360 Description: The compression proposal MUST be able to represent SR 361 paths that contain up to 16 segments. 363 Rationale: Strict TE paths require SID list lengths proportional to 364 the diameter of the SR domain. 366 Metric: The compression proposal must be able to steer a packet 367 through an SR path that contains up to sixteen segments. 369 4.2.4. SID summarization 371 Description: The solution MUST be compatible with segment 372 summarization. 374 Rationale: Summarization of segments is a key benefit of SRv6 vs SR 375 MPLS. In interdomain deployments, any node can reach any other node 376 via a single prefix segment. Without summarization, border router 377 SIDs must be leaked, and an additional global prefix segment is 378 required for each domain border to be traversed. 380 Metric: A solution supports summarization when segments can be 381 summarized for advertisement into other IGP domains or levels. 383 4.3. Operational Requirements 385 4.3.1. Lossless Compression 387 Description: A path traversed using a compessed SID list MUST always 388 be the same as the path traversed using the uncompressed SID list if 389 no compression was applied. 391 Rationale: In SRv6, we can represent a path to meet certain 392 objectives. A compression proposal needs to support the objectives 393 with the same path. 395 Metric: Information present in the pre-compression segment list MUST 396 also be present in the post-compression SID list. 398 4.3.2. Preservation of non-routing information 400 Description:The compression mechanism MUST NOT cause the loss of non- 401 routing information when delivering a packet from the SR ingress node 402 to the egress/penultimate SR node 404 Rationale: SRv6 ingress nodes encode non-routing information in the 405 IPv6 header chain. This information can be encoded in the following 406 fields: 408 o Hop Count 409 o DSCP bits 410 o ECN bits 411 o Flow label 412 o HBH Options Extension header 413 o Fragment Extension header 414 o Authentication Extension header 415 o Encrypted Security Payload Extension header 416 o Destination Options Extension header 418 Some of these fields are mutable (e.g., Hop Count) while others are 419 immutable (e.g., Fragment Extension Header). 421 Some of these fields contain information that is required by every 422 node along a packet's delivery path (e.g., Hop Count). Others 423 contain information that is required only by the packet's ultimate 424 destination (e.g., Fragment Extension Header). 426 Therefore, the compression mechanism MUST NOT prevent this 427 information from being delivered, in an IPv6 header chain, to any 428 node that needs it. 430 Metric: The SR source node encapsulates its payload (e.g.., Ethernet, 431 IP, TCP) in an IPv6 header. The SRv6 header contains both routing 432 and non-routing information. The compression mechanism MUST NOT 433 cause the loss of non-routing information when delivering a packet 434 from the SR ingress node to the egress/penultimate SR node. 436 4.3.3. Address Planning 438 Description: Network operators require addressing plan flexibility, 439 The compression mechanism MUST support flexible IPv6 address 440 planning, it MUST support deployment by using GUA from different 441 address blocks. 443 Rationale: The address planning of the network may vary based on the 444 addressing scheme of the operator, so the solution MUST support a 445 flexible addressing scheme. Operators need to deploy the solution 446 based on their own address planning. 448 Metric: The compression proposal supports locators drawn from 449 different prefixes with the solutions analysis indicating efficiency. 451 4.4. Scalability Requirements 453 4.4.1. Adjacency segment scale 455 Description: The compression proposal MUST be capable of representing 456 65000 adjacency segments per node 458 Rationale: Typically, network operators deploy networks with tens or 459 hundreds of adjacency segments per node, but some network operators 460 may deploy networks that use more adjacency segments per node. 462 Metric: A proposal that allows 65000 adjacency segments per node 463 satisfies this requirement. 465 4.4.2. Prefix segment scale 467 Description: The compression proposal MUST be capable of representing 468 1 million prefix segments per SID numbering space. 470 Rationale: Typically, network operators deploy networks with 471 thousands of prefix segments per SID numbering space, but some 472 network operators may deploy networks that use more prefix segments 473 per SID numbering space. 475 Metric: A proposal that allows 1 million prefix segments per SID 476 numbering space satisfies this requirement. 478 4.4.3. Service Scale 480 Description: The compression proposal MUST be capable of representing 481 1 million services per node. 483 Rationale: Typically, network operators deploy networks with tens to 484 hundreds of thousands of services per node, but some network 485 operators may deploy networks that use more services per node. 487 Metric: A proposal that allows 1 million services per node satisfies 488 this requirement. 490 4.4.4. Compression Levels 492 Description: The compression proposal SHOULD be able to support 493 multiple levels of compression. 495 Rationale: The compression proposal will be deployed in networks of 496 varying size with SID numbering spaces of varying size. Network and 497 service scale can directly impact SID length and the ability of a 498 proposal to compress the SID list. 500 Metric: A compression proposal that supports relatively better 501 compression for smaller SID numbering spaces and service scale 502 satisfies this requirement. 504 5. Protocol Design Requirements 506 5.1. SRv6 Base Coexistence 508 Description: The compression proposal MUST support simultaneous 509 deployment with SRv6 networks. 511 Rationale: SRv6 is deployed today. A compression proposal that 512 interoperates well with SRv6, as deployed, will reduce the overhead 513 and simplify operations. For Network operators who would migrate to 514 compressed SRv6 SID lists, the migration is expected to gradually 515 occur over a period of time as they upgrade networks, domains, device 516 families and software instances. 518 Metric: A compliant compression proposal provides the following 520 o Supports simultaneous deployment at a node with current SRv6 SIDs. 521 o Supports simultaneous deployment at a node with current SRv6 522 control plane. 523 o Supports simultaneous operation of current SRv6 paths with 524 compressed paths. 525 o Supports the behaviors in [RFC8986]. 526 o Does not require removal of existing IPv6 address planning. 528 6. Security Requirements 530 6.1. Security Mechanisms 532 Description: The compression solution SHOULD be able to address 533 security issues that it introduces, using existing security 534 mechanisms. 536 Rationale: It is important to identify security issues and how to 537 address them in any specification. 539 Metric: A compression solution that does not introduce unresolved 540 security issues meets this requirement. 542 6.2. SR Domain Protection 544 Description: A compression solution must not require nodes outside 545 the SR domain to know SID values within the SR domain, and it must 546 provide the ability to block nodes outside an SR domain from 547 accessing SIDS. 549 Rationale: The unauthorized use of SIDs within the SR domain by nodes 550 outside the domain can disrupt an operators' network. 552 Metric: A compliant solution describes how access to SIDs within the 553 SR domain is denied to nodes outside the SR domain. 555 7. IANA Considerations 557 This document has no requests to IANA. 559 8. Security Considerations 561 TBD 563 9. Contributors 565 The following individuals contributed to this draft 567 Sanders Steffann, SJM Steffann Consultancy, sander@steffann.nl 569 10. Normative References 571 [I-D.ietf-6man-spring-srv6-oam] 572 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 573 Chen, "Operations, Administration, and Maintenance (OAM) 574 in Segment Routing Networks with IPv6 Data plane (SRv6)", 575 draft-ietf-6man-spring-srv6-oam-13 (work in progress), 576 January 2022. 578 [I-D.ietf-bess-srv6-services] 579 Dawra, G., Talaulikar, K., Raszuk, R., Decraene, B., 580 Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay 581 Services", draft-ietf-bess-srv6-services-15 (work in 582 progress), March 2022. 584 [I-D.ietf-idr-bgpls-srv6-ext] 585 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 586 Bernier, D., and B. Decraene, "BGP Link State Extensions 587 for SRv6", draft-ietf-idr-bgpls-srv6-ext-09 (work in 588 progress), November 2021. 590 [I-D.ietf-lsr-flex-algo] 591 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 592 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 593 algo-18 (work in progress), October 2021. 595 [I-D.ietf-lsr-isis-srv6-extensions] 596 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 597 Z. Hu, "IS-IS Extensions to Support Segment Routing over 598 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 599 (work in progress), October 2021. 601 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 602 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 603 Decraene, B., and D. Voyer, "Topology Independent Fast 604 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 605 routing-ti-lfa-08 (work in progress), January 2022. 607 [I-D.ietf-spring-segment-routing-policy] 608 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 609 P. Mattes, "Segment Routing Policy Architecture", draft- 610 ietf-spring-segment-routing-policy-22 (work in progress), 611 March 2022. 613 [I-D.ietf-spring-sr-service-programming] 614 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 615 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 616 S. Salsano, "Service Programming with Segment Routing", 617 draft-ietf-spring-sr-service-programming-05 (work in 618 progress), September 2021. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 626 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 627 May 2017, . 629 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 630 Decraene, B., Litkowski, S., and R. Shakir, "Segment 631 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 632 July 2018, . 634 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 635 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 636 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 637 . 639 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 640 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 641 (SRv6) Network Programming", RFC 8986, 642 DOI 10.17487/RFC8986, February 2021, 643 . 645 Appendix A. Proposed Requirements 647 This appendix contains requirements that the design team discussed 648 but could not be agreed upon. 650 A.1. IPv6 Based 652 Description: The compression mechanism requires every node along the 653 packet's delivery path to be IPv6-capable. It MUST not require any 654 node along the packet's forwarding path to support any other 655 forwarding plane (e.g., IPv4, MPLS) 657 Rational: According to RFC 8402, SRv6 is an instantiation of the SR 658 Architecture over the IPv6 data plane. 660 Metric: A compliant solution requires every node along the packet's 661 delivery path to be IPv6-capable. It does not require any node along 662 the packet's forwarding path to support any other forwarding plane 663 (e.g., IPv4, MPLS) 665 A.2. Point to Multipoint 667 Description: The compression mechanism SHOULD support point-to- 668 multipoint SR paths. 670 Rationale: Many VPN services require point-to-multipoint SR paths. 672 Metric: A compliant proposal can encode a multicast address in the 673 ultimate segment of the segment list. 675 A.3. Parsability 677 Description: The compression mechanism MUST be parsable. That is, 678 the node that consumes the compressed SID list must be able to decode 679 the active and next segment. Parsing information MAY be conveyed in 680 either the forwarding or control plane. 682 Rationale: Failure to parse the compressed SID list leads to 683 undesired behaviors. 685 Metric: In the nominal case the producer and consumer of the SID list 686 agree on the active segment and next segment. In forseeable failure 687 modes it is possible to determine why the producer and consumer don't 688 agree. 690 Authors' Addresses 692 Weiqiang Cheng 693 China Mobile 695 Email: chengweiqiang@chinamobile.com 697 Chongfeng Xie 698 China Telecom 700 Email: xiechf@chinatelecom.cn 701 Ron Bonica 702 Juniper 704 Email: rbonica@juniper.net 706 Darren Dukes 707 Cisco Systems 709 Email: ddukes@cisco.com 711 Cheng Li 712 Huawei 714 Email: c.l@huawei.com 716 Peng Shaofu 717 ZTE 719 Email: peng.shaofu@zte.com.cn 721 Wim Henderickx 722 Nokia 724 Email: wim.henderickx@nokia.com