idnits 2.17.1 draft-srcompdt-spring-compression-requirement-05.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 05, 2021) is 1147 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 (~~), 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 C. Xie 5 Expires: September 6, 2021 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 05, 2021 18 Compressed SRv6 SID List Requirements 19 draft-srcompdt-spring-compression-requirement-05 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 6, 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 . . . . 5 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 5.2. PS or BCP Compliance . . . . . . . . . . . . . . . . . . 12 88 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 89 6.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 12 90 6.2. SR Domain Protection . . . . . . . . . . . . . . . . . . 13 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 93 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 94 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 95 Appendix A. Proposed Requirements . . . . . . . . . . . . . . . 15 96 A.1. IPv6 Based . . . . . . . . . . . . . . . . . . . . . . . 15 97 A.2. Point to Multipoint . . . . . . . . . . . . . . . . . . . 15 98 A.3. Parsability . . . . . . . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 101 1. Introduction 103 The SPRING working group defined SRv6, with [RFC8402] describing how 104 the Segment Routing (SR) architecture is instantiated on two data- 105 planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). SRv6 uses a 106 routing header called the SR Header (SRH) [RFC8754] and defines SRv6 107 SID behaviors and a registry for identifying them in 108 [I-D.ietf-spring-srv6-network-programming]. SRv6 is a proposed 109 standard and is deployed today. 111 The SPRING working group has observed that some use cases, such as 112 strict path TE, may require long SRv6 SID lists. There are several 113 proposed methods to reduce the resulting SRv6 encapsulation size by 114 compressing the SID list. 116 The SPRING working group formed a design team to define requirements 117 for, and analyze proposals to, compress SRv6 SID lists. 119 It is a goal of the design team to identify solutions to SRv6 SID 120 list compression that are based on the SRv6 standards. As such, this 121 document provides requirements for SRv6 SID list compression 122 solutions that utilize the existing SRv6 data plane and control 123 plane. 125 It is also a goal of the design team to consider proposals that are 126 not based on the SRv6 data plane and control plane. As such, this 127 document includes requirements to evaluate whether a compression 128 proposal provides all the functionality of SRv6 (section "SRv6 129 Functionality") in addition to satisfying compression specific 130 requirements. 132 For each requirement, a description, rationale and metrics are 133 described. 135 The design team will produce a separate document to analyze the 136 proposals. 138 This document is a draft; additional requirements are under review, 139 additional requirements will be added, and current requirements may 140 change. Appendix A contains a subset of requirements without 141 unanimous consensus. Additional requirements without unanimous 142 consensus are not in the appendix. 144 2. Conventions used in this document 146 2.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2.2. Terminology 156 SR: Segment Routing 158 SRH: Segment Routing Header 160 MPLS: Multiprotocol Label Switching 162 SR-MPLS: Segment Routing over MPLS data plane 164 SID: Segment Identifier 166 SRv6: Segment Routing over IPv6 168 SRv6 SID List: A list of SRv6 SIDs 170 Compression proposal: A proposal to compress SRv6 SID lists 172 SRv6 base: SRv6 as defined in [RFC8402], [RFC8754], 173 [I-D.ietf-spring-srv6-network-programming] 175 SID numbering space: may be implemented as 177 o a single IGP instance 178 o a single IGP level or area 179 o two or more autonomous systems that coordinate SID numbering space 180 o two or more IGP instances that coordinate SID numbering space 182 SRv6 Encapsulation Header: The IPv6 header, and any extension headers 183 preceding a payload, used to implement a SRv6 base or compression 184 proposal. 186 3. SRv6 SID List Compression Requirements 187 3.1. Dataplane Efficiency and Performance Requirements 189 3.1.1. Encapsulation Header Size 191 Description: The compression proposal MUST reduce the size of the 192 SRv6 encapsulation header. 194 Rationale: A smaller SRv6 encapsulation results in better MTU 195 efficiency. 197 Metric: Compression is the ratio of the IPv6 encapsulation size of 198 SRv6 as defined in [RFC8402], [RFC8754], 199 [I-D.ietf-spring-srv6-network-programming] vs the IPv6 encapsulation 200 size of a given proposal. The encapsulation savings of a compression 201 proposal vs the SRv6 base is a useful measurement to compare 202 proposals. 204 The encapsulation metric (E) records the number of bytes required for 205 a proposal to encapsulate a packet given a specific segment list. 207 o E(proposal, segment list). 209 The encapsulation savings(ES)records the encapsulation savings for a 210 proposal to encapsulate a packet given a specific segment list. 212 o ES(proposal, segment list) = 1 - E(proposal, segment list)/E(SRv6 213 base, segment list). 215 3.1.2. Forwarding Efficiency 217 Description: The compression proposal SHOULD minimize the number of 218 required hardware resources accessed to process a segment. 220 Rationale: Efficiency in bits on the wire and processing efficiency 221 are both important. Optimizing one at the expense of the other may 222 lead to significant performance impact. 224 Metric: The data plane efficiency metric (D) records the data plane 225 forwarding efficiency of the proposed solution. Two metrics are used 226 and recorded at each segment endpoint: 228 o D.PRS(segment list): number of headers parsed during processing of 229 the segment list, starting from and including the IPv6 header. 230 o D.LKU(segment list): number of FIB lookups during processing of 231 the segment list. The type of lookup is also recorded as longest 232 prefix match (LPM) or exact match (EM) 234 3.1.3. State Efficiency 236 Description: The compression proposal SHOULD minimize the amount of 237 additional forwarding state stored at a node. 239 Rationale: Additional state increases the complexity of the control 240 plane and data plane. It can also result in an increase in memory 241 usage. 243 Metric: The state efficiency metric (S) records the amount of 244 additional forwarding state required by the proposed solution. 246 o S(node parameters): the number of additional forwarding states 247 that need to be stored at a node, given a set of node parameters 248 consisting of the number of nodes in the network, number of local 249 interfaces, number of adjacencies. The forwarding state is 250 counted as entries required in a Forwarding Information Base (FIB) 251 at a node. 253 4. SRv6 Specific Requirements 255 4.1. SRv6 Based 257 Description: A solution to compress SRv6 SID Lists SHOULD be based on 258 the SRv6 architecture, control plane and data plane. The compression 259 solution MAY be based on a different data plane and control plane, 260 provided that it derives sufficient benefit. 262 Rationale: A compression proposal built on existing IETF standards is 263 preferable to creating new standards with equivalent functionality 264 and performance. 266 Metric: The utilization metric (U) records whether a proposal 267 utilizes the SRv6 specifications. 269 Utilization is recorded in a table, with a column per proposal and 270 rows consisting of the following metrics: 272 o U.RFC8402: utilizes [RFC8402]. 273 o U.RFC8754: utilizes [RFC8754]. 274 o U.PGM: utilizes [I-D.ietf-spring-srv6-network-programming]. 275 o U.IGP: utilizes [I-D.ietf-lsr-isis-srv6-extensions]. 276 o U.BGP: utilizes [I-D.ietf-bess-srv6-services]. 277 o U.POL: utilizes [I-D.ietf-spring-segment-routing-policy]. 278 o U.BLS: utilizes [I-D.ietf-idr-bgpls-srv6-ext]. 279 o U.SVC: utilizes [I-D.ietf-spring-sr-service-programming]. 280 o U.OAM: utilizes [I-D.ietf-6man-spring-srv6-oam]. 281 o U.ALG: utilizes [I-D.ietf-lsr-flex-algo]. 283 Each cell contains "yes" for utilizes, or "no" for does not utilize. 285 4.2. Functional Requirements 287 4.2.1. SRv6 Functionality 289 Description: A solution to compress an SRv6 SID list MUST support the 290 functionality of SRv6. This requirement ensures no SRv6 291 functionality is lost. It is particularly important to understand 292 how a proposal, as evaluated in section "SRv6 Based", provides this 293 functionality. 295 Rationale: Operators require SRv6 functionality. Evaluating the 296 extent to which a proposal supports SRv6 functionality is important 297 for operators and implementors to understand the impact on network 298 operations. 300 Metric: The Functionality metric (F) records whether a proposal 301 supports SRv6 functionality and how the functionality is provided. 303 Functionality is recorded in a table with columns for each proposal 304 and rows consisting of the following metrics: 306 o F.SID: Supports SRv6 SID functionality as described in [RFC8402] 307 o F.SCOPE: Supports globally and locally scoped SID functionality as 308 described in [RFC8402] 309 o F.PFX: Supports prefix SID functionality as described in [RFC8402] 310 and [I-D.ietf-spring-srv6-network-programming] 311 o F.ADJ: Supports adjacency SID functionality as described in 312 [RFC8402] and [I-D.ietf-spring-srv6-network-programming] 313 o F.BIND: Supports binding SID functionality as described in 314 [RFC8402] and [I-D.ietf-spring-srv6-network-programming] 315 o F.PEER: Supports BGP peering SID functionality as described in 316 [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] 319 o F.ALG: Supports flexible algorithms functionality as described in 320 [I-D.ietf-lsr-flex-algo] 321 o F.TILFA: Supports TI-LFA functionality as described in 322 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 323 o F.SEC: Supports securing an SR domain with ingress filtering as 324 functionally defined in [RFC8754] 325 o F.IGP: Supports distributing topological SIDs and behaviors via 326 ISIS as functionally described in 327 [I-D.ietf-lsr-isis-srv6-extensions] 328 o F.BGP: Supports BGP VPNs as functionally described in 329 [I-D.ietf-bess-srv6-services] 331 o F.POL: Supports SR policies and steering traffic over those 332 policies as funcitonally described in 333 [I-D.ietf-spring-segment-routing-policy] 334 o F.BLS: Supports Link State distribution via BGP as functionally 335 described in [I-D.ietf-idr-bgpls-srv6-ext] 336 o F.SFC: Supports stateless service programming as functionally 337 described in [I-D.ietf-spring-sr-service-programming] 338 o F.PING: Supports pinging a SID to verify the SID is implemented as 339 functionally described in [I-D.ietf-6man-spring-srv6-oam] 341 Each cell contains the specification name documenting the 342 functionality. 344 4.2.2. Heterogeneous SID lists 346 Description: The compression proposal SHOULD support a combination of 347 compressed and non-compressed segments in a single path. As an 348 example, a solution may satisfy this requirement without being SRv6 349 based by using a binding SID to impose an additional SRv6 header 350 (IPv6 header plus optional SRH) with non-compressed SID. 352 Rationale: Support of SID lists with compressed and non-compressed 353 SIDs reduces encapsulation size when not all SRv6 nodes deploy the 354 compression proposal or 128-bit SIDs are required. 356 Metric: A compliant compression proposal supports both: 358 o classic 128-bit SRv6 SIDs in the IPv6 Destination Address field 359 o segment lists (i.e., paths) with both compressed and 128-bit SRv6 360 SIDs. 362 4.2.3. SID list length 364 Description: The compression proposal MUST be able to represent SR 365 paths that contain up to 16 segments. 367 Rationale: Strict TE paths require SID list lengths proportional to 368 the diameter of the SR domain. 370 Metric: The compression proposal must be able to steer a packet 371 through an SR path that contains up to sixteen segments. 373 4.2.4. SID summarization 375 Description: The solution MUST be compatible with segment 376 summarization. 378 Rationale: Summarization of segments is a key benefit of SRv6 vs SR 379 MPLS. In interdomain deployments, any node can reach any other node 380 via a single prefix segment. Without summarization, border router 381 SIDs must be leaked, and an additional global prefix segment is 382 required for each domain border to be traversed. 384 Metric: A solution supports summarization when segments can be 385 summarized for advertisement into other IGP domains or levels. 387 4.3. Operational Requirements 389 4.3.1. Lossless Compression 391 Description: A path traversed using a compessed SID list MUST always 392 be the same as the path traversed using the uncompressed SID list if 393 no compression was applied. 395 Rationale: In SRv6, we can represent a path to meet certain 396 objectives. A compression proposal needs to support the objectives 397 with the same path. 399 Metric: Information present in the pre-compression segment list MUST 400 also be present in the post-compression SID list. 402 4.3.2. Preservation of non-routing information 404 Description:The compression mechanism MUST NOT cause the loss of non- 405 routing information when delivering a packet from the SR ingress node 406 to the egress/penultimate SR node 408 Rationale: SRv6 ingress nodes encode non-routing information in the 409 IPv6 header chain. This information can be encoded in the following 410 fields: 412 o Hop Count 413 o DSCP bits 414 o ECN bits 415 o Flow label 416 o HBH Options Extension header 417 o Fragment Extension header 418 o Authentication Extension header 419 o Encrypted Security Payload Extension header 420 o Destination Options Extension header 422 Some of these fields are mutable (e.g., Hop Count) while others are 423 immutable (e.g., Fragment Extension Header). 425 Some of these fields contain information that is required by every 426 node along a packet's delivery path (e.g., Hop Count). Others 427 contain information that is required only by the packet's ultimate 428 destination (e.g., Fragment Extension Header). 430 Therefore, the compression mechanism MUST NOT prevent this 431 information from being delivered, in an IPv6 header chain, to any 432 node that needs it. 434 Metric: The SR source node encapsulates its payload (e.g.., Ethernet, 435 IP, TCP) in an IPv6 header. The SRv6 header contains both routing 436 and non-routing information. The compression mechanism MUST NOT 437 cause the loss of non-routing information when delivering a packet 438 from the SR ingress node to the egress/penultimate SR node. 440 4.3.3. Address Planning 442 Description: Network operators require addressing plan flexibility, 443 The compression mechanism MUST support flexible IPv6 address 444 planning, it MUST support deployment by using GUA from different 445 address blocks. 447 Rationale: The address planning of the network may vary based on the 448 addressing scheme of the operator, so the solution MUST support a 449 flexible addressing scheme. Operators need to deploy the solution 450 based on their own address planning. 452 Metric: The compression proposal supports locators drawn from 453 different prefixes with the solutions analysis indicating efficiency. 455 4.4. Scalability Requirements 457 4.4.1. Adjacency segment scale 459 Description: The compression proposal MUST be capable of representing 460 65000 adjacency segments per node 462 Rationale: Typically, network operators deploy networks with tens or 463 hundreds of adjacency segments per node, but some network operators 464 may deploy networks that use more adjacency segments per node. 466 Metric: A proposal that allows 65000 adjacency segments per node 467 satisfies this requirement. 469 4.4.2. Prefix segment scale 471 Description: The compression proposal MUST be capable of representing 472 1 million prefix segments per SID numbering space. 474 Rationale: Typically, network operators deploy networks with 475 thousands of prefix segments per SID numbering space, but some 476 network operators may deploy networks that use more prefix segments 477 per SID numbering space. 479 Metric: A proposal that allows 1 million prefix segments per SID 480 numbering space satisfies this requirement. 482 4.4.3. Service Scale 484 Description: The compression proposal MUST be capable of representing 485 1 million services per node. 487 Rationale: Typically, network operators deploy networks with tens to 488 hundreds of thousands of services per node, but some network 489 operators may deploy networks that use more services per node. 491 Metric: A proposal that allows 1 million services per node satisfies 492 this requirement. 494 4.4.4. Compression Levels 496 Description: The compression proposal SHOULD be able to support 497 multiple levels of compression. 499 Rationale: The compression proposal will be deployed in networks of 500 varying size with SID numbering spaces of varying size. Network and 501 service scale can directly impact SID length and the ability of a 502 proposal to compress the SID list. 504 Metric: A compression proposal that supports relatively better 505 compression for smaller SID numbering spaces and service scale 506 satisfies this requirement. 508 5. Protocol Design Requirements 510 5.1. SRv6 Base Coexistence 512 Description: The compression proposal MUST support deployment in 513 existing SRv6 networks. 515 Rationale: SRv6 is deployed today. A compression proposal that 516 interoperates well with SRv6, as deployed, will reduce the overhead 517 and simplify operations. For Network operators who would migrate to 518 compressed SRv6 SID lists, the migration is expected to gradually 519 occur over a period of time as they upgrade networks, domains, device 520 families and software instances. 522 Metric: A compliant compression proposal provides the following 524 o Supports simultaneous deployment at a node with current SRv6 SIDs. 525 o Supports simultaneous deployment at a node with current SRv6 526 control plane. 527 o Supports simultaneous operation of current SRv6 paths with 528 compressed paths. 529 o Supports the behaviors in 530 [I-D.ietf-spring-srv6-network-programming]. 531 o Does not require removal of existing IPv6 address planning. 533 5.2. PS or BCP Compliance 535 Description: The compression mechanism SHOULD comply with any 536 proposed standard or BCP. If it does not comply with any PS or BCP 537 it SHOULD update the related document. 539 Rationale: Compliance with existing standards makes the internet more 540 robust. 542 Metric: A solution that complies with PS or BCP, or updates PS or BCP 543 satisfies this requirement. The PS or BCP document may be updated at 544 any time before the publication of the document specifying the 545 compression mechanism. 547 6. Security Requirements 549 6.1. Security Mechanisms 551 Description: The compression solution SHOULD be able to address 552 security issues that it introduces, using existing security 553 mechanisms. 555 Rationale: It is important to identify security issues and how to 556 address them in any specification. 558 Metric: A compression solution that does not introduce unresolved 559 security issues meets this requirement. 561 6.2. SR Domain Protection 563 Description: A compression solution must not require nodes outside 564 the SR domain to know SID values within the SR domain, and it must 565 provide the ability to block nodes outside an SR domain from 566 accessing SIDS. 568 Rationale: The unauthorized use of SIDs within the SR domain by nodes 569 outside the domain can disrupt an operators' network. 571 Metric: A compliant solution describes how access to SIDs within the 572 SR domain is denied to nodes outside the SR domain. 574 7. IANA Considerations 576 This document has no requests to IANA. 578 8. Security Considerations 580 TBD 582 9. Contributors 584 The following individuals contributed to this draft 586 Sanders Steffann, SJM Steffann Consultancy, sander@steffann.nl 588 10. Normative References 590 [I-D.ietf-6man-spring-srv6-oam] 591 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 592 Chen, "Operations, Administration, and Maintenance (OAM) 593 in Segment Routing Networks with IPv6 Data plane (SRv6)", 594 draft-ietf-6man-spring-srv6-oam-08 (work in progress), 595 October 2020. 597 [I-D.ietf-bess-srv6-services] 598 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 599 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 600 Overlay services", draft-ietf-bess-srv6-services-05 (work 601 in progress), November 2020. 603 [I-D.ietf-idr-bgpls-srv6-ext] 604 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 605 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 606 State Extensions for SRv6", draft-ietf-idr-bgpls- 607 srv6-ext-05 (work in progress), November 2020. 609 [I-D.ietf-lsr-flex-algo] 610 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 611 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 612 algo-13 (work in progress), October 2020. 614 [I-D.ietf-lsr-isis-srv6-extensions] 615 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 616 Z. Hu, "IS-IS Extension to Support Segment Routing over 617 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 618 (work in progress), October 2020. 620 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 621 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 622 and D. Voyer, "Topology Independent Fast Reroute using 623 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 624 lfa-05 (work in progress), November 2020. 626 [I-D.ietf-spring-segment-routing-policy] 627 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 628 P. Mattes, "Segment Routing Policy Architecture", draft- 629 ietf-spring-segment-routing-policy-09 (work in progress), 630 November 2020. 632 [I-D.ietf-spring-sr-service-programming] 633 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 634 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 635 Henderickx, W., and S. Salsano, "Service Programming with 636 Segment Routing", draft-ietf-spring-sr-service- 637 programming-03 (work in progress), September 2020. 639 [I-D.ietf-spring-srv6-network-programming] 640 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 641 Matsushima, S., and Z. Li, "SRv6 Network Programming", 642 draft-ietf-spring-srv6-network-programming-28 (work in 643 progress), December 2020. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 655 Decraene, B., Litkowski, S., and R. Shakir, "Segment 656 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 657 July 2018, . 659 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 660 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 661 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 662 . 664 Appendix A. Proposed Requirements 666 This appendix contains requirements that the design team discussed 667 but could not be agreed upon. 669 A.1. IPv6 Based 671 Description: The compression mechanism requires every node along the 672 packet's delivery path to be IPv6-capable. It MUST not require any 673 node along the packet's forwarding path to support any other 674 forwarding plane (e.g., IPv4, MPLS) 676 Rational: According to RFC 8402, SRv6 is an instantiation of the SR 677 Architecture over the IPv6 data plane. 679 Metric: A compliant solution requires every node along the packet's 680 delivery path to be IPv6-capable. It does not not require any node 681 along the packet's forwarding path to support any other forwarding 682 plane (e.g., IPv4, MPLS) 684 A.2. Point to Multipoint 686 Description: The compression mechanism SHOULD support point-to- 687 multipoint SR paths. 689 Rationale: Many VPN services require point-to-multipoint SR paths. 691 Metric: A compliant proposal can encode a multicast address in the 692 ultimate segment of the segment list. 694 A.3. Parsability 696 Description: The compression mechanism MUST be parsable. That is, 697 the node that consumes the compressed SID list must be able to decode 698 the active and next segment. Parsing information MAY be conveyed in 699 either the forwarding or control plane. 701 Rationale: Failure to parse the compressed SID list leads to 702 undesired behaviors. 704 Metric: In the nominal case the producer and consumer of the SID list 705 agree on the active segment and next segment. In forseeable failure 706 modes it is possible to determine why the producer and consumer don't 707 agree. 709 Authors' Addresses 711 Weiqiang Cheng 712 China Mobile 714 Email: chengweiqiang@chinamobile.com 716 Chongfeng Xie 717 China Telecom 719 Email: xiechf@chinatelecom.cn 721 Ron Bonica 722 Juniper 724 Email: rbonica@juniper.net 726 Darren Dukes 727 Cisco Systems 729 Email: ddukes@cisco.com 731 Cheng Li 732 Huawei 734 Email: c.l@huawei.com 736 Peng Shaofu 737 ZTE 739 Email: peng.shaofu@zte.com.cn 740 Wim Henderickx 741 Nokia 743 Email: wim.henderickx@nokia.com