idnits 2.17.1 draft-ietf-spring-compression-analysis-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '...ression proposal MUST reduce the size ...' RFC 2119 keyword, line 223: '...ression proposal SHOULD minimize the n...' RFC 2119 keyword, line 346: '...ression proposal SHOULD minimize the a...' RFC 2119 keyword, line 443: '...s SRv6 SID Lists SHOULD be based on th...' RFC 2119 keyword, line 445: '... MAY be based on a different data pl...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2022) is 758 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'B5' is mentioned on line 129, but not defined == Missing Reference: 'B7' is mentioned on line 129, but not defined == Missing Reference: 'B6' is mentioned on line 131, but not defined == Missing Reference: 'B8' is mentioned on line 131, but not defined -- Looks like a reference, but probably isn't: '1' on line 1095 -- Looks like a reference, but probably isn't: '0' on line 1096 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-27 == Outdated reference: A later version (-21) exists of draft-bonica-6man-vpn-dest-opt-17 == Outdated reference: A later version (-07) exists of draft-cl-spring-generalized-srv6-for-cmpr-04 == Outdated reference: A later version (-16) exists of draft-filsfils-spring-net-pgm-extension-srv6-usid-12 == 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 (-17) exists of draft-ietf-lsr-ip-flexalgo-04 == 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: 3 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING R. Bonica 3 Internet-Draft Juniper 4 Intended status: Informational W. Cheng 5 Expires: September 30, 2022 China Mobile 6 D. Dukes, Ed. 7 Cisco Systems 8 W. Henderickx 9 Nokia 10 C. Li 11 Huawei 12 P. Shaofu 13 ZTE 14 C. Xie 15 China Telecom 16 March 29, 2022 18 Compressed SRv6 SID List Analysis 19 draft-ietf-spring-compression-analysis-01 21 Abstract 23 Several mechanisms have been proposed to compress the SRv6 SID list. 24 This document analyzes each mechanism with regard to the requirements 25 stated in the companion requirements document. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 30, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. SRv6 Compression Requirements . . . . . . . . . . . . . . . . 3 63 2.1. Encapsulation Header Size . . . . . . . . . . . . . . . . 4 64 2.1.1. Reference Scenarios . . . . . . . . . . . . . . . . . 4 65 2.2. Forwarding Efficiency . . . . . . . . . . . . . . . . . . 5 66 2.2.1. Headers Parsed . . . . . . . . . . . . . . . . . . . 5 67 2.2.2. Lookups Performed (LKU) . . . . . . . . . . . . . . . 7 68 2.3. State Efficiency . . . . . . . . . . . . . . . . . . . . 8 69 3. SRv6 Specific Requirements . . . . . . . . . . . . . . . . . 10 70 3.1. SRv6 Based . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.2. Functional Requirements . . . . . . . . . . . . . . . . . 11 72 3.2.1. SRv6 Functionality . . . . . . . . . . . . . . . . . 11 73 3.2.2. Heterogeneous SID Lists . . . . . . . . . . . . . . . 14 74 3.2.3. SID List Length . . . . . . . . . . . . . . . . . . . 15 75 3.2.4. SID Summarization . . . . . . . . . . . . . . . . . . 15 76 3.3. Operational Requirements . . . . . . . . . . . . . . . . 15 77 3.3.1. Lossless Compression . . . . . . . . . . . . . . . . 16 78 3.3.2. Preservation of non-routing information . . . . . . . 16 79 3.3.3. Address Planning . . . . . . . . . . . . . . . . . . 16 80 3.4. Scalability Requirements . . . . . . . . . . . . . . . . 17 81 3.4.1. Compression Levels . . . . . . . . . . . . . . . . . 18 82 4. Protocol Design Requirements . . . . . . . . . . . . . . . . 18 83 4.1. SRv6 Base Coexistence . . . . . . . . . . . . . . . . . . 18 84 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 19 85 5.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 19 86 5.2. SR Domain Protection . . . . . . . . . . . . . . . . . . 19 87 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7. Normative References . . . . . . . . . . . . . . . . . . . . 21 89 Appendix A. Encapsulation analysis . . . . . . . . . . . . . . . 24 90 A.1. CRH note . . . . . . . . . . . . . . . . . . . . . . . . 24 91 A.2. Analysis results . . . . . . . . . . . . . . . . . . . . 25 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 The following mechanisms are proposed to compress the SRv6 SID list: 98 o CSID - [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] - Describes 99 two new SRv6 SID flavors, a combination of SID flavors from 100 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and 101 [I-D.cl-spring-generalized-srv6-for-cmpr] 102 o CRH - [I-D.bonica-6man-comp-rtg-hdr] - Requires two new routing 103 header types and a label mapping technique. 104 o VSID - [I-D.decraene-spring-srv6-vlsid] - Defines a set of SID 105 behaviors to access smaller SIDs within the SR header. 106 o UIDSR - [I-D.mirsky-6man-unified-id-sr] - Extends the SRH to carry 107 MPLS labels or IPv6 addresses. 109 This document analyzes each mechanism against the requirements stated 110 in [I-D.srcompdt-spring-compression-requirement]. Each section of 111 this document corresponds to a similarly named section in 112 [I-D.srcompdt-spring-compression-requirement]. Each section 113 reiterates corresponding requirements and analyzes each proposal 114 against the those requirements. 116 The terms compression mechanism, compression solution, and 117 compression proposal are used interchangeably within this document. 119 2. SRv6 Compression Requirements 121 An SR domain consisting of 3 sub-domains is shown to illustrate the 122 scenarios associated with encapsulation header size, forwarding 123 efficiency and state efficiency. 125 + * * * * * * * * * * * * * * * * * * * * * * * * * * + 126 * * 127 * - - - - - - - - + - - - - - - - - + - - - - - - - - * 128 * | | * 129 * [M1_0] [B5] [C_0] [B7] [M2_0] * 130 [H1]--[E3] | | [E4]---[H2] 131 * [M1_i] [B6] [C_j] [B8] [M2_k] * 132 * | | * 133 * Metro 1 | Core | Metro 2 * 134 *- - - - - - - - - - - - - - - - - - - - - - - - - - -* 135 * * 136 * SR domain * 137 + * * * * * * * * * * * * * * * * * * * * * * * * * * + 139 Figure 1: Sample SR Domain 141 o H1 and H2 are hosts outside the SR domain 142 o E3 and E4 are SR domain edge routers 143 o Metro 1, Core and Metro 2 are sub-domains with independent IGP 144 instances 145 o B5 and B6 are border routers between the Metro 1 and Core 146 o B7 and B8 are border routers between the Metro 2 and Core 147 o M1_1..M1_i are routers in Metro 1 148 o C_1..C_j are routers in Core 149 o M2_1..M2_k are routers in Metro 2 150 o If Metro and Core are different AS's the border routers (B5 to B8) 151 may be replaced by pairs of ASBRs 152 o Flexible algorithms may be deployed within each sub-domain 154 2.1. Encapsulation Header Size 156 The compression proposal MUST reduce the size of the SRv6 157 encapsulation header. 159 Encapsulation header size is evaluated against a set of reference 160 scenarios. 162 2.1.1. Reference Scenarios 164 A service provider offers a VPN service with underlay optimization in 165 the SR domain. 167 o Hosts H1 and H2 are located in two different sites of a VPN 168 customer. 169 o Edge nodes E3 and E4 encapsulate/decapsulate traffic between H1 170 and H2 to provide the VPN service. 171 o The encapsulation consists of a VPN SID (V) (eg END.DT etc) and an 172 SR policy with between 0 and 15 transport segments (T) (eg END or 173 END.X) 174 o The SR domain has a block size (B) of 48 bits 175 o These independent variables are used to uniquely identify each 176 scenario. For example 178 * A scenario with 48bit block size, 3 transport segments and a 179 VPN segment is named 48B.3T.V 181 Proposals are evaluated against the set of scenarios to calculate the 182 encapsulation in octets (E) and the encapsulation savings (ES) as a 183 fraction of the SRv6 base encapsulation in octets. 185 E and ES were evaluated for: 187 o each proposal in two variants 189 * 16-bit SID 190 * 32-bit SID 191 o 48-bit SRv6 block, 0 to 15 transport segments and a VPN segment 192 (expressed in short form as 48B.0-15T.V) 194 The average encapsulation savings for each proposal is shown below. 195 The complete analysis is recorded in Appendix: 197 +-------------+-------+-------+---------+-------+-------+ 198 | 16-bit SIDs | CSID | CRH | CRH+TPF | VSID | UIDSR | 199 +-------------+-------+-------+---------+-------+-------+ 200 | Average ES | 54.3% | 54.2% | 50.4% | 51.6% | 49.2% | 201 +-------------+-------+-------+---------+-------+-------+ 203 Table 1: Average ES, 16-bit SIDs, 48B.0-15T.V 205 +-------------+-------+-------+---------+-------+-------+ 206 | 32-bit SIDs | CSID | CRH | CRH+TPF | VSID | UIDSR | 207 +-------------+-------+-------+---------+-------+-------+ 208 | Average ES | 42.5% | 45.5% | 43.2% | 45.5% | 42.5% | 209 +-------------+-------+-------+---------+-------+-------+ 211 Table 2: Average ES, 32-bit SIDs, 48B.0-15T.V 213 E and ES are also evaluated for 32bit and 64bit SRv6 block sizes. 214 The CSID 16-bit ES averages 57.4% for 32-bit blocks and 49.9% for 215 64-bit blocks, other proposals are unchanged. 217 Conclusion: All proposals meet the requirement to reduce the size of 218 the SRv6 encapsulation header. Variances between proposals are 219 negligible. 221 2.2. Forwarding Efficiency 223 The compression proposal SHOULD minimize the number of required 224 hardware resources accessed to process a segment. 226 2.2.1. Headers Parsed 228 Forwarding efficiency is calculated against the reference scenarios 229 above, recording and summarizing the differences in header parsing 230 for different segment lists. 232 The following tables indicate the number of headers parsed for each 233 proposal. 235 +-------------------+------+------+---------+------+-------+ 236 | 16-bit | CSID | CRH | CRH+TPF | VSID | UIDSR | 237 +-------------------+------+------+---------+------+-------+ 238 | PRS(48B.0T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 239 | | | | | | | 240 | PRS(48B.1-4T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 241 | | | CRH | CRH | SRH | SRH | 242 | | | | | | | 243 | PRS(48B.5-15T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 244 | | SRH | CRH | CRH | SRH | SRH | 245 | | | | | | | 246 +-------------------+------+------+---------+------+-------+ 248 Table 3: Headers parsed on non-decapsulating SR segment endpoint 249 nodes, 16-bit SIDs, 48B.0-15T.V 251 +-------------------+------+------+---------+------+-------+ 252 | 16-bit | CSID | CRH | CRH+TPF | VSID | UIDSR | 253 +-------------------+------+------+---------+------+-------+ 254 | PRS(48B.0T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 255 | | | | | | | 256 | PRS(48B.1-4T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 257 | | | CRH | CRH | SRH | SRH | 258 | | | | TPF | | | 259 | | | | | | | 260 | PRS(48B.5-15T).V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 261 | | SRH | CRH | CRH | SRH | SRH | 262 | | | | TPF | | | 263 +-------------------+------+------+---------+------+-------+ 265 Table 4: Headers parsed on decapsulating SR segment endpoint nodes, 266 16-bit SIDs, 48B.0-15T.V 268 +------------------+------+------+---------+------+-------+ 269 | 32-bit | CSID | CRH | CRH+TPF | VSID | UIDSR | 270 +------------------+------+------+---------+------+-------+ 271 | PRS(48B.0T.V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 272 | | | | | | | 273 | PRS(48B.1-15T.V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 274 | | SRH | CRH | CRH | SRH | SRH | 275 +------------------+------+------+---------+------+-------+ 277 Table 5: Headers parsed on non-decapsulating SR segment endpoint 278 nodes, 32-bit SIDs, 48B.0-15T.V 280 +------------------+------+------+---------+------+-------+ 281 | 32-bit | CSID | CRH | CRH+TPF | VSID | UIDSR | 282 +------------------+------+------+---------+------+-------+ 283 | PRS(48B.0T.V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 284 | | | | | | | 285 | PRS(48B.1-15T.V) | IPv6 | IPv6 | IPv6 | IPv6 | IPv6 | 286 | | SRH | CRH | CRH | SRH | SRH | 287 | | | | TPF | | | 288 +------------------+------+------+---------+------+-------+ 290 Table 6: Headers parsed on decapsulating SR segment endpoint nodes, 291 32-bit SIDs, 48B.0-15T.V 293 Conclusion: Overall, the CSID parses the fewest headers. When per 294 packet state is processed per segment, CSID, VSID and UIDSR proposals 295 may include it in the routing header, CRH may include it in a 296 destination option preceding the CRH. 298 2.2.2. Lookups Performed (LKU) 300 Some proposals require a different number of lookups per packet, 301 depending on the active segment in a segment list. 303 An implementation may perform lookups as longest prefix match (LPM) 304 or exact match (EM). CSID, VSID and UIDSR describe SRv6 SID lookup 305 from the IPv6 destination address as an LPM, however an 306 implementation may use either an LPM or EM lookup for SRv6 SIDs. CRH 307 implementations must always uses an exact match for CRH SID lookups. 309 The following table describes the number of lookups per proposal per 310 segment type. 312 +-----------------+---------+----------+---------+---------+ 313 | | CSID | CRH | VSID | UIDSR | 314 +-----------------+---------+----------+---------+---------+ 315 | Adjacency and | LPM (a) | LPM (a) | LPM (a) | LPM (a) | 316 | VPN Segments | | EM (b) | | | 317 | | | EM (b,c) | | | 318 | | | | | | 319 | Prefix Segments | LPM (a) | LPM (a) | LPM (a) | LPM (a) | 320 | | LPM (d) | EM (b) | LPM (d) | LPM (d) | 321 | | | | | | 322 +-----------------+---------+----------+---------+---------+ 324 Table 7: Lookups 326 o [a] On active SID, appearing in the IPv6 Destination address 327 o [b] On SID in CRH header 328 o [c] This lookup is required only when the IPv6 next hop node is 329 not non-CRH aware 330 o [d] On next SID, appearing in the IPv6 destination address 332 Note: [I-D.filsfils-spring-net-pgm-extension-srv6-usid] Section 5 333 describes an optional local implementation to reduce CSID 16-bit 334 lookups, in some cases, by adding local forwarding state. The 335 analysis of this implementation option is not included in this 336 version of the document. 338 Conclusion: CSID, VSID, and UIDSR require a single lookup to process 339 an adjacency or VPN segment. CRH always requires 2 lookups for VPN 340 segments, and 2 and sometimes 3 lookups for adjacency segments. All 341 proposals require two lookups to process a prefix segment and the 342 next segment. 344 2.3. State Efficiency 346 The compression proposal SHOULD minimize the amount of additional 347 forwarding state stored at a node. 349 State efficiency is analyzed in a sub-domain of the SR domain, with 350 the following parameters: 352 o N: the number of SRv6 nodes in the sub-domain 353 o I: the number of IGP algorithms [I-D.ietf-lsr-flex-algo] 354 configured 355 o A: the number of local adjacency SIDs at a node 356 o D: the number of attached SR sub-domains at a border node 357 o V: the number of VPN services at edge nodes 359 For a sub-domain consisting of: 361 o 1000 SRv6 nodes (N=1000) with some number of non-SRv6 nodes 362 o 2 IGP algorithms (I=2) 363 o 100 adjacencies per SRv6 node (A=100) 364 o up to 10 attached sub-domains per border node (D=10) 365 o 1000 VPN service segments per edge (V=1000) 367 The number of forwarding entries at a node is calculated for any 368 node, a border node, and an edge node. 370 UIDSR, CSID and VSID require the following entries: 372 o a FIB entry for the node's prefix segment (1), per algorithm 373 (I=2). 374 o a FIB entry per local adjacency SID (A=100) **Note1 375 o At border nodes (or any SRv6 nodes) either: 377 * A.1) a FIB entry per domain (D=10) to swap the IPv6 destination 378 address prefix. 379 * A.2) no additional FIB entries, and the SR source places a 380 128-bit SID in the segment list of a packet if needed. 381 o At edge nodes, a FIB entry per VPN segment (V=1000) 383 CRH requires: 385 o a CFIB entry per CRH node per IGP algorithm for local and remote 386 prefix segments (N*I=2000) 387 o a CFIB entry per local adjacency segment (A=100) **Note1 389 * When non-CRH adjacent nodes are present, additional state is 390 required for CRH as per [I-D.bonica-6man-comp-rtg-hdr] 391 Appendix B (note, only the second option in the appendix is 392 considered feasible due to state explosion) 394 + B.1) Up to one CFIB entry per next endpoint and an 395 additional CFIB entry per adjacency to support non-CRH 396 adjacent endpoints, assuming IP flex algo is not implemented 397 on non-CRH nodes (I=1) ((N+A)*I=1200). 398 o At border nodes, assuming two inter-domain links per adjacent 399 domain for redundancy, additional state is required as per 400 [I-D.bonica-6man-comp-rtg-hdr] Appendix B (note, only the second 401 option in the appendix is considered feasible due to state 402 explosion): 404 * C.1) In a common CRH network topology, the remote sub-domain 405 borders support CRH: a CFIB entry per CRH node per IGP 406 algorithm for local and remote prefix segments (N*I) plus a 407 CFIB entry per local adjacency segment (A) plus a CFIB entry 408 per connected remote border router (20) (N*I+A+20=2120). 409 * C.2) In a poorly designed CRH network topology, the remote sub- 410 domain borders do not support CRH: a CFIB entry per unique 411 endpoint (N*D*I), plus a CFIB entry per local adjacency segment 412 (A), assuming IP flex algo is not implemented on non-CRH border 413 domain (I=1), plus inter-domain adjacency (20) (N*D*I+2=10120). 414 o At edge nodes, V=1000 entries for SRv6 based VPN SIDs and another 415 V=1000 entries for CFIB and TPF VPN SIDs. 417 **Note1: there may be additional adjacency SIDs for protected, 418 unprotected, and per algorithm adjacencies, resulting in some 419 multiple of A. This is common for all compression proposals. 421 +----------------------+---------+-----------+---------+---------+ 422 | 16-bit and 32-bit | CSID | CRH | VSID | UIDSR | 423 +----------------------+---------+-----------+---------+---------+ 424 | S(N1000,I2,A100,D10) | 102 | 2100 | 102 | 102 | 425 | | A.1:112 | | A.1:112 | A.1:112 | 426 | | A.2:102 | | A.2:102 | A.2:102 | 427 | | | B.1:3300 | | | 428 | | | C.1:2120 | | | 429 | | | C.2:10120 | | | 430 | | | | | | 431 | S(V1000) | 1000 | 2000 | 1000 | 1000 | 432 +----------------------+---------+-----------+---------+---------+ 434 Table 8: Forwarding State Maintained 436 Conclusion: CSID, VSID and UIDSR minimize forwarding state stored at 437 a node. CRH moves per segment state from the packet to the FIB. 439 3. SRv6 Specific Requirements 441 3.1. SRv6 Based 443 A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 444 architecture, control plane and data plane. The compression solution 445 MAY be based on a different data plane and control plane, provided 446 that it derives sufficient benefit. 448 This section records the use of SRv6 standards for compression. 450 +-----------+------+---------------+---------------+----------------+ 451 | | CSID | CRH | VSID | UIDSR | 452 +-----------+------+---------------+---------------+----------------+ 453 | U.RFC8402 | Yes | Yes - update | Yes | Yes | 454 | | | required for | | | 455 | | | SRv6 data | | | 456 | | | plane | | | 457 | U.RFC8754 | Yes | No | Yes - update | Yes - update | 458 | | | | required for | for flags and | 459 | | | | segments left | segments left | 460 | U.PGM | Yes | No | Yes - update | Yes | 461 | | | | required for | | 462 | | | | SID behaviors | | 463 | U.IGP | Yes | No | Yes | Yes - | 464 | | | | | additional | 465 | | | | | extensions | 466 | U.BGP | Yes | No | Yes | Yes | 467 | U.POL | Yes | No | Yes | Yes | 468 | U.BLS | Yes | No | Yes | Yes - | 469 | | | | | additional | 470 | | | | | extensions | 471 | U.SVC | Yes | No | Yes | Yes | 472 | U.ALG | Yes | Yes - Adds IP | Yes | Yes | 473 | | | flex Algo | | | 474 | U.OAM | Yes | No | Yes | Yes | 475 +-----------+------+---------------+---------------+----------------+ 477 Table 9: SRv6 Based 479 Conclusion: CSID is SRv6 based, requiring no updates to existing SRv6 480 standards, VSID and UIDSR require updates. CRH is not strictly based 481 on SRv6 but is able to provide equivalent functionality. 483 3.2. Functional Requirements 485 3.2.1. SRv6 Functionality 487 A solution to compress an SRv6 SID list MUST support the 488 functionality of SRv6. This requirement ensures no SRv6 489 functionality is lost. It is particularly important to understand 490 how a proposal, as evaluated in section "SRv6 Based", provides this 491 functionality. 493 Functional requirements and the drafts defining how a proposal 494 provides the functionality are documented in the table below. 496 +-------------------------------------------------------+ 497 | Draft reference Abbreviations | 498 +-------------------------------------------------------+ 499 | RFC8986: [RFC8986] | 500 | SRV6POL: [I-D.ietf-spring-segment-routing-policy] | 501 | SRV6EXT: [I-D.ietf-lsr-isis-srv6-extensions] | 502 | SRV6BGPSVC: [I-D.ietf-bess-srv6-services] | 503 | SRV6BGPLS: [I-D.ietf-idr-bgpls-srv6-ext] | 504 | SRV6SVCP: [I-D.ietf-spring-sr-service-programming] | 505 | SRV6OAM: [I-D.ietf-6man-spring-srv6-oam] | 506 | SRV6FLEXALG: [I-D.ietf-lsr-flex-algo] | 507 | SRV6TILFA: [I-D.ietf-rtgwg-segment-routing-ti-lfa] | 508 | RFC8402: [RFC8402] | 509 | RFC8754: [RFC8754] | 510 | CRH: [I-D.bonica-6man-comp-rtg-hdr] | 511 | VSID: [I-D.decraene-spring-srv6-vlsid] | 512 | UIDSR: [I-D.mirsky-6man-unified-id-sr] | 513 | IPFLEXALG: [I-D.ietf-lsr-ip-flexalgo] | 514 | CRHEXT: [I-D.bonica-lsr-crh-isis-extensions] | 515 | SRM6BGPSVC: [I-D.ssangli-bess-bgp-vpn-srm6] | 516 | CSID: [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] | 517 +-------------------------------------------------------+ 519 Abbreviations 521 +--------+-------------+----------------+-------------+-------------+ 522 | | CSID | CRH | VSID | UIDSR | 523 +--------+-------------+----------------+-------------+-------------+ 524 | F.SID | RFC8402 | CRH | RFC8402 | RFC8402 1 | 525 | F.Scop | RFC8402 | CRH | RFC8402 | RFC8402 1 | 526 | e | | | | | 527 | F.PFX | RFC8402, | CRH | RFC8402, | RFC8402, | 528 | | RFC8986, | | RFC8986, | RFC8986 | 529 | | CSID adds | | VSID | with new | 530 | | an END SID | | updates the | flavor 1 | 531 | | flavor | | End | | 532 | | | | behavior | | 533 | F.ADJ | RFC8402, | CRH | RFC8402, | RFC8402, | 534 | | RFC8986, | | RFC8986, | RFC8986 | 535 | | CSID adds | | VSID | with new | 536 | | an END.X | | updates the | flavor 1 | 537 | | flavor | | End.X | | 538 | | | | behavior | | 539 | F.BIND | RFC8402, | CRH | RFC8402, | RFC8402, | 540 | | RFC8986 | | RFC8986, | RFC8986 | 541 | | | | VSID | with new | 542 | | | | updates the | flavor 1 | 543 | | | | End.B | | 544 | | | | behaviors | | 545 | F.PEER | RFC8402, | CRH | RFC8402, | RFC8402, | 546 | | RFC8986, | | RFC8986, | RFC8986 | 547 | | CSID adds | | VSID | with new | 548 | | an END.X. | | updates the | flavor 1,2 | 549 | | flavor | | End.X | | 550 | | | | behaviors | | 551 | F.SVC | RFC8986 | CRH | RFC8986, | RFC8986 1 | 552 | | | | VSID | | 553 | | | | updates the | | 554 | | | | service | | 555 | | | | segment | | 556 | | | | behaviors | | 557 | F.ALG | SRV6FLEXALG | IPFLEXALG | SRV6FLEXALG | SRV6FLEXALG | 558 | F.TILF | SRV6TILFA | SRV6TILFA | SRV6TILFA | SRV6TILFA 3 | 559 | A | | | | | 560 | F.SEC | RFC8754 | CRH | RFC8754 | RFC8754 | 561 | F.IGP | SRV6EXT | CRH-EXT | SRV6EXT | SRV6EXT 1,4 | 562 | F.BGP | SRV6BGPSVC | SRM6BGPSVC | SRV6BGPSVC | SRV6BGPSVC | 563 | | | | | 1 | 564 | F.POL | SRV6SRPOL | SRV6SRPOL | SRV6SRPOL | SRV6SRPOL | 565 | | | update | | | 566 | | | required | | | 567 | F.BLS | SRV6BGPLS | (specification | SRV6BGPLS | SRV6BGPLS 5 | 568 | | | required) | and | | 569 | | | | addition | | 570 | | | | for VSID | | 571 | | | | Length | | 572 | F.SFC | SRV6SVCP | CRH | SRV6SVC | SRV6SVCP 1 | 573 | F.PING | SRV6OAM | CRH | SRV6OAM | SRv6OAM | 574 +--------+-------------+----------------+-------------+-------------+ 576 Table 10: SRv6 Functionality 578 1. UIDSR with Global Container SID + local index enhancement 579 2. draft-peng-spring-truncates-sid-inter-domain 580 3. For protections described in section 6.1.2.1, 6.1.2.2, and 6.2, 581 to get next-next SID from SRH with the help of draft-pl-spring- 582 compr-path-recover. 583 4. Need more extensions to advertise the capability of U-SID 584 compression (32bits, 16bits, etc.). Note: Global Container SID + 585 local index enhancement. 586 5. IGP extensions 588 Conclusion: CSID supports SRv6 functionality. CRH VSID and UID 589 support SRv6 functionality or equivalent with some new 590 specifications. 592 3.2.2. Heterogeneous SID Lists 594 The compression proposal SHOULD support a combination of compressed 595 and non-compressed segments in a single path. As an example, a 596 solution may satisfy this requirement without being SRv6 based by 597 using a binding SID to impose an additional SRv6 header (IPv6 header 598 plus optional SRH) with non-compressed SID. 600 +-------------------------+------+-----+------+-------+ 601 | | CSID | CRH | VSID | UIDSR | 602 +-------------------------+------+-----+------+-------+ 603 | Heterogeneous SID Lists | Yes | Yes | Yes | Yes | 604 +-------------------------+------+-----+------+-------+ 606 Heterogeneous SID Lists 608 VSID require a binding SID with an additional SRv6 encapsulation to 609 encode non-compressed segments in a single path. VSID changes the 610 interpretation of the SRH Segments Left field, which makes it capable 611 of carrying only compressed segments. 613 The CRH can include a binding SID that imposes a new IPv6 header with 614 an SRH. This is required when the next segment endpoint in the path 615 can process the SRH, but not the CRH. The next segment endpoint or a 616 subsequent endpoint can execute decapsulation, removing the new IPv6 617 header and exposing the old one with its CRH. This is required 618 because an IPv6 packet can carry only one routing header. 620 CSID and UIDSR permit the encoding of, and processing of, any 621 combination of compressed or non-compressed segments in a segment 622 list of an SRH. 624 CSID makes use of the SRH, without modification, to encode CSIDs as 625 128 bits, supporting the use of non-compressed segments within the 626 SRH. 628 UIDSR modifies the interpretation of the SRH Segments Left field at 629 segment endpoint nodes to allow variable segment lengths within a 630 segment list. 632 Conclusion: All proposals support heterogeneous SID lists. CSID and 633 UIDSR support heterogeneous SID lists in the SRH, while CRH and VSID 634 require installation of binding SIDs at midpoint nodes. 636 3.2.3. SID List Length 638 The compression proposal MUST be able to represent SR paths that 639 contain up to 16 segments. 641 +-------------+------+-----+------+-------+ 642 | | CSID | CRH | VSID | UIDSR | 643 +-------------+------+-----+------+-------+ 644 | 16 Segments | Yes | Yes | Yes | Yes | 645 +-------------+------+-----+------+-------+ 647 SID List Length 649 Conclusion: All proposals support segment lists of at least 16 650 segments. 652 3.2.4. SID Summarization 654 The solution MUST be compatible with segment summarization. 656 In inter sub-domain deployments with summarization: 658 o Any node can reach any other node in another sub-domain via a 659 prefix segment. 660 o Prefixes are summarized for advertisement between domains. 662 Without summarization, border router SIDs must be leaked: 664 o An additional global prefix segment is required for each domain 665 border to be traversed. 667 +-------------------+------+-----+------+-------+ 668 | | CSID | CRH | VSID | UIDSR | 669 +-------------------+------+-----+------+-------+ 670 | SID Summarization | Yes | No | Yes | Yes | 671 +-------------------+------+-----+------+-------+ 673 SID Summarization 675 Conclusion: CSID, VSID and UIDSR support segment summarization, CRH 676 does not. 678 3.3. Operational Requirements 679 3.3.1. Lossless Compression 681 A path traversed using a compressed SID list MUST always be the same 682 as the path traversed using the uncompressed SID list if no 683 compression was applied. 685 +----------------------+------+-----+------+-------+ 686 | | CSID | CRH | VSID | UIDSR | 687 +----------------------+------+-----+------+-------+ 688 | Lossless Compression | Yes | Yes | Yes | Yes | 689 +----------------------+------+-----+------+-------+ 691 Lossless Compression 693 Conclusion: All proposals provide lossless compression. 695 3.3.2. Preservation of non-routing information 697 The compression mechanism MUST NOT cause the loss of non-routing 698 information when delivering a packet from the SR ingress node to the 699 egress/penultimate SR node 701 +-----------------------+----------+----------+----------+----------+ 702 | | CSID | CRH | VSID | UIDSR | 703 +-----------------------+----------+----------+----------+----------+ 704 | Preserves Non-Routing | Complies | Complies | Complies | Complies | 705 | Information | | | | | 706 +-----------------------+----------+----------+----------+----------+ 708 Preservation of non-routing information 710 Conclusion: All proposals preserve non-routing information. 712 3.3.3. Address Planning 714 Description: Network operators require addressing plan flexibility, 715 The compression mechanism MUST support flexible IPv6 address 716 planning, it MUST support deployment by using GUA from different 717 address blocks. 719 +---------------------------+------+-----+------+-------+ 720 | | CSID | CRH | VSID | UIDSR | 721 +---------------------------+------+-----+------+-------+ 722 | Flexible Address Planning | Yes | Yes | Yes | Yes | 723 +---------------------------+------+-----+------+-------+ 725 Address Planning 727 All compression mechanisms provide the encapsulation savings 728 described in Tables 1 and 2. CRH provides these encapsulation 729 savings regardless of the IPv6 addressing scheme. CSID adds a CSID 730 container, or one compressed SID (END.X with XPS behavior), for each 731 change in locator block in a segment list. VSID (via XPS behavior) 732 and UIDSR add one compressed SID for each change in locator block in 733 the segment list. 735 The XPS behavior draws the new address block from the control plane. 736 At the time of publication, this control plane behavior is undefined. 737 Therefore XPS impact on the control plane is not entirely understood. 738 While it may be possible to define these mechanisms without impacting 739 the control plane, specifications are not yet available. 741 Conclusion: All proposals support flexible IPv6 planning. 743 3.4. Scalability Requirements 745 The compression proposal MUST be capable of representing 65000 746 adjacency segments per node. 748 The compression proposal MUST be capable of representing 1 million 749 prefix segments per SID numbering space. 751 The compression proposal MUST be capable of representing 1 million 752 services per node. 754 +-------------------------------+------+-----+------+-------+ 755 | | CSID | CRH | VSID | UIDSR | 756 +-------------------------------+------+-----+------+-------+ 757 | Adjacency Segment Scale 65000 | Yes | Yes | Yes | Yes | 758 | Prefix Segment Scale 1000000 | Yes | Yes | Yes | Yes | 759 | Service Scale 1000000 | Yes | Yes | Yes | Yes | 760 +-------------------------------+------+-----+------+-------+ 762 Table 11: Scale Requirements 764 The 32-bit variants of all proposals support this scale of prefix, 765 adjacency and services at a node. 767 Each proposals 16-bit variant supports a lesser scale. All proposals 768 can encode 2^16 prefix, adjacency and service segments. However, 769 each proposal has various ways of supporting some larger scale per 770 node if required. 772 CRH 16-bit proposes the encoding of the ultimate segment in a TPF 773 destination option instead of the CRH. This supports 2^32 service 774 segments per node. 776 VSID proposes the combination of multiple vSIDs, by copying multiple 777 SIDs to a destination address or looking up the next segment in the 778 segment list. This supports more than 2^16 adjacency and service 779 segments per node. 781 CSID 16-bit variant uses a LIB for adjacency and service segments, 782 the LIB allows local definition of SIDs longer than 16-bits when 783 needed. This supports more than 2^16 adjacency and service segments 784 per node. 786 UIDSR defines a segment type that modifies the value of SRH segments 787 left field to support variable segment sizes within the segment list. 788 This supports 2^32 adjacency and service segments per node. 790 Conclusion: All proposals meet scalability requirements. 792 3.4.1. Compression Levels 794 The compression proposal SHOULD be able to support multiple levels of 795 compression. 797 +-----------------------------+------+-----+------+-------+ 798 | | CSID | CRH | VSID | UIDSR | 799 +-----------------------------+------+-----+------+-------+ 800 | Multiple compression Levels | Yes | Yes | Yes | Yes | 801 +-----------------------------+------+-----+------+-------+ 803 Compression Levels 805 Conclusion: All proposals support 16-bit and 32-bit SID variants. 807 4. Protocol Design Requirements 809 4.1. SRv6 Base Coexistence 811 The compression proposal MUST support deployment in SRv6 networks. 813 +-----------------------+------+-----+------+-------+ 814 | | CSID | CRH | VSID | UIDSR | 815 +-----------------------+------+-----+------+-------+ 816 | SRv6 Base Coexistence | Yes | Yes | Yes | Yes | 817 +-----------------------+------+-----+------+-------+ 819 SRv6 Base Coexistence 821 Conclusion: All proposals can be deployed simultaneously with the 822 SRv6 base solution. 824 5. Security Requirements 826 5.1. Security Mechanisms 828 The compression solution SHOULD be able to address security issues 829 that it introduces, using existing security mechanisms. 831 +---------------------+------+-----+------+-------+ 832 | | CSID | CRH | VSID | UIDSR | 833 +---------------------+------+-----+------+-------+ 834 | Security Mechanisms | Yes | Yes | Yes | Yes | 835 +---------------------+------+-----+------+-------+ 837 Security Mechanisms 839 Conclusion: All proposals address security issues they may introduce 840 with existing security mechanisms. 842 5.2. SR Domain Protection 844 A compression solution must not require nodes outside the SR domain 845 to know SID values within the SR domain, and it must provide the 846 ability to block nodes outside an SR domain from accessing SIDS. 848 +----------------------+------+-----+------+-------+ 849 | | CSID | CRH | VSID | UIDSR | 850 +----------------------+------+-----+------+-------+ 851 | SR Domain Protection | Yes | Yes | Yes | Yes | 852 +----------------------+------+-----+------+-------+ 854 SR Domain Protection 856 Conclusion: All proposals protect SIDs within the SR domain. 858 6. Conclusions 860 Encapsulation Header Size 862 o All proposals meet the requirement to reduce the size of the SRv6 863 encapsulation header. Variances between proposals are negligible. 865 Forwarding Efficiency 867 o Overall, the CSID parses the fewest headers. When per packet 868 state is processed per segment, CSID, VSID and UIDSR proposals may 869 include it in the routing header, CRH may include it in a 870 destination option preceding the CRH. 872 o CSID, VSID, and UIDSR require a single lookup to process an 873 adjacency or VPN segment. CRH always requires 2 lookups for VPN 874 segments, and 2 and sometimes 3 lookups for adjacency segments. 875 All proposals require two lookups to process a prefix segment and 876 the next segment. 878 State Efficiency 880 o CSID, VSID and UIDSR minimize forwarding state stored at a node. 881 CRH moves per segment state from the packet to the FIB. 883 SRv6 Based 885 o CSID is SRv6 based, requiring no updates to existing SRv6 886 standards, VSID and UIDSR require updates. CRH is not strictly 887 based on SRv6 but is able to provide equivalent functionality. 889 SRv6 Functionality 891 o CSID supports SRv6 functionality. CRH VSID and UID support SRv6 892 functionality or equivalent with some new specifications. 894 Heterogeneous SID lists 896 o All proposals support heterogeneous SID lists. CSID and UIDSR 897 support heterogeneous SID lists in the SRH, while CRH and VSID 898 require installation of binding SIDs at midpoint nodes. 900 SID List Length 902 o All proposals support segment lists of at least 16 segments. 904 SID Summarization 906 o VSID, CSID and UIDSR support segment summarization, CRH does not. 908 Operational Requirements 910 o All proposals provide lossless compression. 911 o All proposals preserve non-routing information. 912 o All proposals support flexible IPv6 planning. 914 Scalability Requirements 916 o All proposals meet scalability requirements. 917 o All proposals support 16-bit and 32-bit SID variants. 919 Protocol Design Requirements 920 o All proposals can be deployed simultaneously with the SRv6 base 921 solution. 923 Security Requirements 925 o All proposals address security issues they may introduce with 926 existing security mechanisms. 927 o All proposals protect SIDs within the SR domain. 929 7. Normative References 931 [I-D.bonica-6man-comp-rtg-hdr] 932 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 933 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 934 bonica-6man-comp-rtg-hdr-27 (work in progress), November 935 2021. 937 [I-D.bonica-6man-vpn-dest-opt] 938 Bonica, R., Kamite, Y., Jalil, L., Zhou, Y., and G. Chen, 939 "The IPv6 Tunnel Payload Forwarding (TPF) Option", draft- 940 bonica-6man-vpn-dest-opt-17 (work in progress), January 941 2022. 943 [I-D.bonica-lsr-crh-isis-extensions] 944 Kaneriya, P., Shetty, R., Hegde, S., and R. Bonica, "IS-IS 945 Extensions To Support The IPv6 Compressed Routing Header 946 (CRH)", draft-bonica-lsr-crh-isis-extensions-06 (work in 947 progress), February 2022. 949 [I-D.cl-spring-generalized-srv6-for-cmpr] 950 (editor), W. C., Li, Z., (editor), C. L., Clad, F., Liu, 951 A., Xie, C., Liu, Y., and S. Zadok, "Generalized SRv6 952 Network Programming for SRv6 Compression", draft-cl- 953 spring-generalized-srv6-for-cmpr-04 (work in progress), 954 October 2021. 956 [I-D.decraene-spring-srv6-vlsid] 957 Decraene, B., Raszuk, R., Li, Z., and C. Li, "SRv6 vSID: 958 Network Programming extension for variable length SIDs", 959 draft-decraene-spring-srv6-vlsid-07 (work in progress), 960 March 2022. 962 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 963 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 964 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 965 D., Liu, Y., and J. Guichard, "Network Programming 966 extension: SRv6 uSID instruction", draft-filsfils-spring- 967 net-pgm-extension-srv6-usid-12 (work in progress), 968 December 2021. 970 [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] 971 Cheng, W., Filsfils, C., Li, Z., Cai, D., Voyer, D., Clad, 972 F., Zadok, S., Guichard, J. N., and L. Aihua, "Compressed 973 SRv6 Segment List Encoding in SRH", draft-filsfilscheng- 974 spring-srv6-srh-comp-sl-enc-03 (work in progress), May 975 2021. 977 [I-D.ietf-6man-spring-srv6-oam] 978 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 979 Chen, "Operations, Administration, and Maintenance (OAM) 980 in Segment Routing Networks with IPv6 Data plane (SRv6)", 981 draft-ietf-6man-spring-srv6-oam-13 (work in progress), 982 January 2022. 984 [I-D.ietf-bess-srv6-services] 985 Dawra, G., Talaulikar, K., Raszuk, R., Decraene, B., 986 Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay 987 Services", draft-ietf-bess-srv6-services-15 (work in 988 progress), March 2022. 990 [I-D.ietf-idr-bgpls-srv6-ext] 991 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 992 Bernier, D., and B. Decraene, "BGP Link State Extensions 993 for SRv6", draft-ietf-idr-bgpls-srv6-ext-09 (work in 994 progress), November 2021. 996 [I-D.ietf-lsr-flex-algo] 997 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 998 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 999 algo-18 (work in progress), October 2021. 1001 [I-D.ietf-lsr-ip-flexalgo] 1002 Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, 1003 R., and P. Psenak, "IGP Flexible Algorithms (Flex- 1004 Algorithm) In IP Networks", draft-ietf-lsr-ip-flexalgo-04 1005 (work in progress), December 2021. 1007 [I-D.ietf-lsr-isis-srv6-extensions] 1008 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1009 Z. Hu, "IS-IS Extensions to Support Segment Routing over 1010 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 1011 (work in progress), October 2021. 1013 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1014 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1015 Decraene, B., and D. Voyer, "Topology Independent Fast 1016 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1017 routing-ti-lfa-08 (work in progress), January 2022. 1019 [I-D.ietf-spring-segment-routing-policy] 1020 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1021 P. Mattes, "Segment Routing Policy Architecture", draft- 1022 ietf-spring-segment-routing-policy-22 (work in progress), 1023 March 2022. 1025 [I-D.ietf-spring-sr-service-programming] 1026 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1027 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1028 S. Salsano, "Service Programming with Segment Routing", 1029 draft-ietf-spring-sr-service-programming-05 (work in 1030 progress), September 2021. 1032 [I-D.mirsky-6man-unified-id-sr] 1033 Weiqiang, C., Mirsky, G., Shaofu, P., Aihua, L., and G. S. 1034 Mishra, "Unified Identifier in IPv6 Segment Routing 1035 Networks", draft-mirsky-6man-unified-id-sr-10 (work in 1036 progress), September 2021. 1038 [I-D.srcompdt-spring-compression-requirement] 1039 Cheng, W., Xie, C., Bonica, R., Dukes, D., Li, C., Shaofu, 1040 P., and W. Henderickx, "Compressed SRv6 SID List 1041 Requirements", draft-srcompdt-spring-compression- 1042 requirement-07 (work in progress), July 2021. 1044 [I-D.ssangli-bess-bgp-vpn-srm6] 1045 Sangli, S. and R. Bonica, "BGP based Virtual Private 1046 Network (VPN) Services over SRm6 enabled IPv6 networks", 1047 draft-ssangli-bess-bgp-vpn-srm6-02 (work in progress), 1048 September 2020. 1050 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1051 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1052 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1053 July 2018, . 1055 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1056 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1057 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1058 . 1060 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1061 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1062 (SRv6) Network Programming", RFC 8986, 1063 DOI 10.17487/RFC8986, February 2021, 1064 . 1066 Appendix A. Encapsulation analysis 1068 A.1. CRH note 1070 CRH compression efficiency statistics are derived as follows: 1072 If an SR path contains no transport segments and a VPN segment, the 1073 SR path is encoded in a single IPv6 header (40 bytes). The 1074 destination address in the IPv6 header is a classic SRv6 SID (e.g., 1075 END.DT4, END.DT6). 1077 If the SR path contains T transport segments and a VPN segment, and T 1078 is greater than 0, the SR path can be encoded: 1080 o With an IPv6 Tunnel Payload Function (TPF) Option 1081 [I-D.bonica-6man-vpn-dest-opt] 1082 o Without a TPF Option 1084 If the SR path is encoded with a TPF Option, the packet includes a 1085 single IPv6 Header (40 bytes), a CRH (variable length), and a 1086 Destination Options header (8 bytes). The destination address in the 1087 IPv6 header represents the IPv6 address of an interface on the first 1088 transport segment endpoint. The CRH must be large enough to contain 1089 the subsequent T segments. 1091 If the SR path is encoded without a TPF Option, the packet includes a 1092 single IPv6 Header (40 bytes) plus a CRH (variable length). The 1093 destination address in the IPv6 header represents the IPv6 address of 1094 an interface on the first transport segment endpoin . The CRH must be 1095 large enough to contain T+1 segments. In the CRH, SID[1] maps to the 1096 IPv6 address of the PE router. SID[0] maps to a classic SRv6 SID 1097 (e.g., END.DT4) that is instantiated on the PE router. 1099 In some deployment scenarios, each encoding strategy yields better 1100 compression. 1102 A.2. Analysis results 1104 The detailed encapsulation and encapsulation savings per proposal 1105 with one VPN segment and "T" transport segments: 1107 +----+------+-----+---------+------+-------+ 1108 | T | CSID | CRH | CRH+TPF | VSID | UIDSR | 1109 +----+------+-----+---------+------+-------+ 1110 | 0 | 40 | 40 | 40 | 40 | 40 | 1111 | 1 | 40 | 48 | 56 | 56 | 64 | 1112 | 2 | 40 | 56 | 56 | 56 | 64 | 1113 | 3 | 40 | 56 | 64 | 56 | 64 | 1114 | 4 | 64 | 56 | 64 | 64 | 64 | 1115 | 5 | 64 | 56 | 64 | 64 | 64 | 1116 | 6 | 64 | 64 | 64 | 64 | 64 | 1117 | 7 | 64 | 64 | 72 | 64 | 64 | 1118 | 8 | 64 | 64 | 72 | 72 | 64 | 1119 | 9 | 80 | 64 | 72 | 72 | 80 | 1120 | 10 | 80 | 72 | 72 | 72 | 80 | 1121 | 11 | 80 | 72 | 80 | 72 | 80 | 1122 | 12 | 80 | 72 | 80 | 80 | 80 | 1123 | 13 | 80 | 72 | 80 | 80 | 80 | 1124 | 14 | 96 | 80 | 80 | 80 | 80 | 1125 | 15 | 96 | 80 | 88 | 80 | 80 | 1126 +----+------+-----+---------+------+-------+ 1128 Table 12: Encapsulation (E) octets, 16bit SIDS, 48B.0-15T.V 1129 +----+-------+-------+---------+-------+-------+ 1130 | T | CSID | CRH | CRH+TPF | VSID | UIDSR | 1131 +----+-------+-------+---------+-------+-------+ 1132 | 0 | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% | 1133 | 1 | 37.5% | 25.0% | 12.5% | 12.5% | 0.0% | 1134 | 2 | 50.0% | 30.0% | 30.0% | 30.0% | 20.0% | 1135 | 3 | 58.3% | 41.7% | 33.3% | 41.7% | 33.3% | 1136 | 4 | 42.9% | 50.0% | 42.9% | 42.9% | 42.9% | 1137 | 5 | 50.0% | 56.3% | 50.0% | 50.0% | 50.0% | 1138 | 6 | 55.6% | 55.6% | 55.6% | 55.6% | 55.6% | 1139 | 7 | 60.0% | 60.0% | 55.0% | 60.0% | 60.0% | 1140 | 8 | 63.6% | 63.6% | 59.1% | 59.1% | 63.6% | 1141 | 9 | 58.3% | 66.7% | 62.5% | 62.5% | 58.3% | 1142 | 10 | 61.5% | 65.4% | 65.4% | 65.4% | 61.5% | 1143 | 11 | 64.3% | 67.9% | 64.3% | 67.9% | 64.3% | 1144 | 12 | 66.7% | 70.0% | 66.7% | 66.7% | 66.7% | 1145 | 13 | 68.8% | 71.9% | 68.8% | 68.8% | 68.8% | 1146 | 14 | 64.7% | 70.6% | 70.6% | 70.6% | 70.6% | 1147 | 15 | 66.7% | 72.2% | 69.4% | 72.2% | 72.2% | 1148 +----+-------+-------+---------+-------+-------+ 1150 Table 13: Encapsulation Savings (ES), 16bit SIDS, 48B.0-15T.V 1152 +----+------+-----+---------+------+-------+ 1153 | T | CSID | CRH | CRH+TPF | VSID | UIDSR | 1154 +----+------+-----+---------+------+-------+ 1155 | 0 | 40 | 40 | 40 | 40 | 40 | 1156 | 1 | 64 | 56 | 56 | 56 | 64 | 1157 | 2 | 64 | 56 | 64 | 56 | 64 | 1158 | 3 | 64 | 64 | 64 | 64 | 64 | 1159 | 4 | 64 | 64 | 72 | 64 | 64 | 1160 | 5 | 80 | 72 | 72 | 72 | 80 | 1161 | 6 | 80 | 72 | 80 | 72 | 80 | 1162 | 7 | 80 | 80 | 80 | 80 | 80 | 1163 | 8 | 80 | 80 | 88 | 80 | 80 | 1164 | 9 | 96 | 88 | 88 | 88 | 96 | 1165 | 10 | 96 | 88 | 96 | 88 | 96 | 1166 | 11 | 96 | 96 | 96 | 96 | 96 | 1167 | 12 | 96 | 96 | 104 | 96 | 96 | 1168 | 13 | 112 | 104 | 104 | 104 | 112 | 1169 | 14 | 112 | 104 | 112 | 104 | 112 | 1170 | 15 | 112 | 112 | 112 | 112 | 112 | 1171 +----+------+-----+---------+------+-------+ 1173 Table 14: Encapsulation (E) octets, 32bit SIDS, 48B.0-15T.V 1174 +----+-------+-------+---------+-------+-------+ 1175 | T | CSID | CRH | CRH+TPF | VSID | UIDSR | 1176 +----+-------+-------+---------+-------+-------+ 1177 | 0 | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% | 1178 | 1 | 0.0% | 12.5% | 12.5% | 12.5% | 0.0% | 1179 | 2 | 20.0% | 30.0% | 20.0% | 30.0% | 20.0% | 1180 | 3 | 33.3% | 33.3% | 33.3% | 33.3% | 33.3% | 1181 | 4 | 42.9% | 42.9% | 35.7% | 42.9% | 42.9% | 1182 | 5 | 37.5% | 43.8% | 43.8% | 43.8% | 37.5% | 1183 | 6 | 44.4% | 50.0% | 44.4% | 50.0% | 44.4% | 1184 | 7 | 50.0% | 50.0% | 50.0% | 50.0% | 50.0% | 1185 | 8 | 54.5% | 54.5% | 50.0% | 54.5% | 54.5% | 1186 | 9 | 50.0% | 54.2% | 54.2% | 54.2% | 50.0% | 1187 | 10 | 53.8% | 57.7% | 53.8% | 57.7% | 53.8% | 1188 | 11 | 57.1% | 57.1% | 57.1% | 57.1% | 57.1% | 1189 | 12 | 60.0% | 60.0% | 56.7% | 60.0% | 60.0% | 1190 | 13 | 56.3% | 59.4% | 59.4% | 59.4% | 56.3% | 1191 | 14 | 58.8% | 61.8% | 58.8% | 61.8% | 58.8% | 1192 | 15 | 61.1% | 61.1% | 61.1% | 61.1% | 61.1% | 1193 +----+-------+-------+---------+-------+-------+ 1195 Table 15: Encapsulation Savings (ES), 32bit SIDS, 48B.0-15T.V 1197 Authors' Addresses 1199 Ron Bonica 1200 Juniper 1202 Email: rbonica@juniper.net 1204 Weiqiang Cheng 1205 China Mobile 1207 Email: chengweiqiang@chinamobile.com 1209 Darren Dukes (editor) 1210 Cisco Systems 1212 Email: ddukes@cisco.com 1214 Wim Henderickx 1215 Nokia 1217 Email: wim.henderickx@nokia.com 1218 Cheng Li 1219 Huawei 1221 Email: c.l@huawei.com 1223 Peng Shaofu 1224 ZTE 1226 Email: peng.shaofu@zte.com.cn 1228 Chongfeng Xie 1229 China Telecom 1231 Email: xiechf@chinatelecom.cn