idnits 2.17.1 draft-voyer-6man-extension-header-insertion-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 19, 2019) is 1591 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 355 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-00 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Voyer, Ed. 3 Internet-Draft Bell Canada 4 Intended status: Informational C. Filsfils 5 Expires: May 22, 2020 D. Dukes, Ed. 6 Cisco Systems, Inc. 7 S. Matsushima 8 Softbank 9 J. Leddy 10 Individual Contributor 11 Z. Li 12 Huawei 13 J. Guichard 14 Futurewei 15 November 19, 2019 17 Deployments With Insertion of IPv6 Segment Routing Headers 18 draft-voyer-6man-extension-header-insertion-08 20 Abstract 22 SRv6 is deployed in multiple provider networks. 24 This document describes the usage of SRH insertion and deletion 25 within the SR domain and how security and end-to-end integrity is 26 guaranteed. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 22, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Deployment Report . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Deployments . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Vendor and Open-Source Support . . . . . . . . . . . . . 3 71 3. Deployment Experience With SRH Header Operarion . . . . . . . 4 72 3.1. The SR Domain . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Baseline Usecase . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Choosing an SRv6 SID Block . . . . . . . . . . . . . . . . . 6 75 6. Securing the SR Domain . . . . . . . . . . . . . . . . . . . 7 76 7. MTU within the SR domain . . . . . . . . . . . . . . . . . . 7 77 8. VPN with SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9. TILFA with SRv6 . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. SRH Insertion Process . . . . . . . . . . . . . . . . . . 8 80 9.2. The Penultimate SID of the Inserted SRH is of PSP flavor 9 81 9.3. MTU-delta . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 13.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 [I-D.matsushima-spring-srv6-deployment-status] records multiple SRv6 93 deployments in multiple networks 94 In each deployment, traffic traversing an SR domain is encapsulated 95 in an outer IPv6 header for its journey through the SR domain. 97 To implement transport services within the SR domain, insertion or 98 removal of an SRH after the outer IPv6 header is performed. Any 99 segment within the SRH is strictly contained within the SR domain. 101 The SR domain always preserves the end-to-end integrity of traffic 102 traversing it. No extension header is manipulated, inserted or 103 removed from an inner transported packet. The packet leaving the SR 104 domain is exactly the same (except for the hop-limit update) as the 105 packet entering the SR domain. 107 The SR domain is designed with link MTU sufficiently greater than the 108 MTU at the ingress edge of the SR domain. 110 2. Deployment Report 112 The following deployments are as of November 2019. 114 2.1. Deployments 116 Six operators have publicly reported SRv6 deployments with commercial 117 traffic supported by linerate hardware. Each deployment follows the 118 network design and SRH add/remove behavior described in this 119 document. 121 Softbank 123 China Telecom 125 Iliad 127 China Unicom 129 CERNET2 131 MTN Uganda Ltd. 133 Further information can be found in 134 [I-D.matsushima-spring-srv6-deployment-status] 136 2.2. Vendor and Open-Source Support 138 Eighteen unique implementations of SRv6 are available from multiple 139 vendors and open source initiatives that support the SRH add/remove 140 behavior described in this document: 142 Cisco ASR 9000 144 Cisco NCS 5500 146 Cisco NCS 560 148 Cisco NCS 540 150 Cisco ASR1000 152 Huawei ATN 154 Huawei CX600 156 Huawei NE40E 158 Hauwei ME60 160 Huawei NE5000E 162 Huawei NE9000 164 Huawei NG-OLT MA5800 166 Barefoot Tofino 1 NPU 168 Barefoot Tofino 2 NPU 170 Broadcom Jericho 1, 1+ 172 Broadcom Jericho 2 174 Linux kernel 176 FD.io VPP 178 Marvell's Prestera Falcon CX 8500 family 180 Intel PAC N3000 182 Further information can be found in 183 [I-D.matsushima-spring-srv6-deployment-status] 185 3. Deployment Experience With SRH Header Operarion 186 3.1. The SR Domain 188 An SR Domain is defined in [RFC8402]. 190 Section 5.2 of [I-D.ietf-6man-segment-routing-header] further 191 describes the SR domain as a single system with delegation among 192 components. It states: 194 All intra SR Domain packets are of the SR Domain. The IPv6 header 195 is originated by a node of the SR Domain, and is destined to a 196 node of the SR Domain. 198 All inter domain packets are encapsulated for the part of the 199 packet journey that is within the SR Domain. The outer IPv6 200 header is originated by a node of the SR Domain, and is destined 201 to a node of the SR Domain. 203 In other words, all packets within the SR domain have a source and 204 destination address within the SR Domain. 206 The SR domain is secured as per Section 5.1 of 207 [I-D.ietf-6man-segment-routing-header] and no external packet can 208 enter the domain with a destination address equal to a segment of the 209 domain. 211 In other words, no node outside the SR domain may send packets to, 212 nor make direct use of, segments within the SR domain. 214 4. Baseline Usecase 216 The following abstract illustration shows the SR Domain, how traffic 217 is encapsulated when traversing the SR domain, and (in subequent 218 sections) how an SRH is inserted and processed for a packet 219 traversing the SR domain. It is representative of all deployments in 220 Section 2.1. 222 + * * * * * * * * * * * * * * * * * * * * + 224 * * 225 [1]----[3]--------[5]----------------[6]---------[4]---[2] 226 * | | * 227 | | 228 * | | * 229 [7]----------------[8] 230 * * 232 + * * * * * * * SR Domain * * * * * * * + 234 Figure 1 236 o 3 and 4 are SR Domain edge routers 238 o 5, 6, 7, and 8 are all SR Domain routers 240 o 1 and 2 are hosts outside the SR Domain 242 Since all inter domain packets are encapsulated for the part of the 243 packet journey that is within the SR Domain, a packet sent from 1 and 244 destined to 2 is encapsulated in an outer IP v6 header between nodes 245 3 and 4. 247 5. Choosing an SRv6 SID Block 249 Without revealing the specifics of each deployment, the following 250 well-known technique can be used: 252 Obtain a GUA block from the respective registry (e.g. 253 PPPP:PPP0::/28) 255 Sub-allocate a block for SID allocation (e.g. 256 PPPP:PPPB:BB00::/40) 258 Allocate a /64 SID locator to each node in the domain that needs 259 to provide network instruction (e.g. node 4 gets 260 PPPP:PPPB:BB00:0004::/64 as a SID locator) 262 Vendors and operators have automated the process of locator 263 selection, the details of which are outside the scope of this 264 document. 266 6. Securing the SR Domain 268 The security measures defined in 269 [I-D.ietf-6man-segment-routing-header] Section 5.1 are applied. 271 Protection level 1: filter external traffic entering the SR domain. 272 For example, node 4 (on its interface from node 2) applies an ingress 273 ACL that drops any packet with DA within the PPPP:PPPB:BB00::/40 274 block. 276 Protection level 2: filter internal traffic. For example, node 4 (on 277 its interface from node 6) applies an ingress ACL that drops any 278 packet with DA in PPPP:PPPB:BB00:0004::/64 block if SA is not within 279 the block PPPP:PPP0::/28 281 Vendors and operators have automated the application of these 282 protection levels, the details of which are outside the scope of this 283 document. 285 7. MTU within the SR domain 287 The deployments, Section 2.1, leverage the extensively used practice 288 of ensuring an MTU within the domain is bigger than the MTU on the 289 external links of the domain. 291 More specifically, the MTU difference (MTU-Delta) is designed to be 292 larger than the maximum encapsulation overhead deemed required by the 293 deployment. 295 The exact number is operator specific and is outside the scope of 296 this document. Some indications on how to plan this are provided in 297 the following sections. 299 Any packet exceeding the MTU of a link generates an IPv6 ICMP error 300 message "packet too big" back to the source of the packet. 302 8. VPN with SRv6 304 The deployments involve the creation of commercial SRv6-based VPN 305 traffic as described in [I-D.ietf-bess-srv6-services]. 307 The salient point to note is that no SRH needs to be inserted to 308 realize an SRv6 VPN service. 310 The ingress PE encapsulates the inner packet in an outer header and 311 sets the outer DA to the END.DT/DX SID signaled by the egress PE. 313 MTU-Delta must be >= 40 bytes to allow for the outer IPv6 314 encapsulation without fragmentation. 316 9. TILFA with SRv6 318 The deployments involve the delivery of sub-50msec TILFA protection 319 to the commercial SRv6-based VPN traffic transported by the operator 320 network [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 322 In these deployments, when a failure is detected, the Point of Local 323 Repair (PLR) inserts an SRH implementing the precomputed TILFA backup 324 path. 326 The following salient points are discussed: 328 SRH insertion process 330 The penultimate SID of the inserted SRH is of PSP flavor 332 MTU-delta planning 334 9.1. SRH Insertion Process 336 When an SRH is inserted by an intermediate node it walks the IPv6 337 header chain to the first header after the IPv6 header and inserts 338 the SRH prior to that header. 340 +---------------+------------ 341 | IPv6 header | IPv4 header 342 | VPN Service | 343 | Next Header = | 344 | IPv4 | 345 +---------------+------------ 346 ^-SRH insertion here 348 Figure 2 350 An SR Policy headend within the SR domain inserts an SRH as follows: 352 1. Determine where to insert the SRH. 354 2. Copy the destination address from the IPv6 header to Segment 355 List[0] of the SRH to be inserted. This ensures the original 356 destination address is restored upon execution of the final 357 segment in the inserted SRH. 359 3. Increase the IPv6 header payload length field by the length in 360 bytes of the inserted SRH. 362 If the resulting payload length exceeds 2^16 bytes generate an 363 ICMP "Packet To Big" error message to the source with an MTU of 364 2^16 minus the length in bytes of the SRH and discard the packet. 365 Note: this does not occur in reported deployments given the MTU 366 design constraint. 368 4. Set the SRH next header field to the value in the next header 369 field of the header that will precede the SRH. 371 5. Set the next header field of the header that will precede the SRH 372 to the routing extension header (43) 374 6. Set the IPv6 destination address to the first segment in the 375 segment list of the SRH to be inserted. This segment may or may 376 not be present in the SRH depending on the use of a reduced SRH, 377 see section 4.1.1 of [I-D.ietf-6man-segment-routing-header]. 379 7. Insert the SRH into the packet at the location it should be 380 inserted and resubmit the packet to the IPv6 module for 381 transmission to the new destination. 383 9.2. The Penultimate SID of the Inserted SRH is of PSP flavor 385 The TILFA protection service is essentially a transparent service: it 386 seeks to make the loss of a link, node or SRLG invisible to the 387 transport service. It is also a very transient service as it only 388 lasts a few hundreds of msec while the IGP converges. 390 Consistent with this transparent service definition, the deployments 391 leverage a TILFA computation that ensures that the penultimate SID of 392 the inserted SRH is of PSP flavor. 394 9.3. MTU-delta 396 The vendors reporting the listed deployments have collectively 397 deployed TILFA in tens of SR-MPLS networks, in 6 SRv6 networks and 398 have simulated their SRv6 algorithm in tens of collected real 399 topologies. The inferred experience is that the probability that a 400 TILFA backup path requires more than 2 SRv6 SIDs is very rare. 402 MTU-Delta must be >= 80 bytes. 404 40 bytes (VPN service) 406 + 8 (SRH) (TILFA) 408 + 2 * 16 (2 TILFA SID's) 410 The maximum encapsulation size of any node within the SR domain is 411 limited to a specific value, this maximum is used to calculate the 412 maximum link MTU of interfaces ingress to the SR domain. 414 10. Security Considerations 416 Section 6 describes the method of securing the SR domain in the 417 deployments listed. 419 All security considerations discussed in 420 [I-D.ietf-6man-segment-routing-header] are equally applicable when an 421 SRH insertion is performed. 423 11. IANA Considerations 425 This document doesn't introduce any IANA request. 427 12. Contributors 429 The authors would like to thank the following for their 430 contributions: Robert Raszuk, Stefano Previdi, Stefano Salsano, 431 Antonio Cianfrani, David Lebrun, Olivier Bonaventure, Prem 432 Jonnalagadda, Milad Sharif, Hani Elmalky, Ahmed Abdelsalam, Arthi 433 Ayyangar, Dirk Steinberg, Wim Henderickx. 435 13. References 437 13.1. Normative References 439 [I-D.ietf-6man-segment-routing-header] 440 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 441 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 442 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 443 progress), October 2019. 445 [I-D.ietf-bess-srv6-services] 446 Dawra, G., Filsfils, C., Brissette, P., Agrawal, S., 447 Leddy, J., Voyer, D., daniel.bernier@bell.ca, d., 448 Steinberg, D., Raszuk, R., Decraene, B., Matsushima, S., 449 Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay 450 services", draft-ietf-bess-srv6-services-00 (work in 451 progress), October 2019. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 459 Decraene, B., Litkowski, S., and R. Shakir, "Segment 460 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 461 July 2018, . 463 13.2. Informative References 465 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 466 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 467 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 468 Camarillo, "Topology Independent Fast Reroute using 469 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 470 lfa-01 (work in progress), March 2019. 472 [I-D.matsushima-spring-srv6-deployment-status] 473 Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 474 Implementation and Deployment Status", draft-matsushima- 475 spring-srv6-deployment-status-02 (work in progress), 476 October 2019. 478 Authors' Addresses 480 Daniel Voyer (editor) 481 Bell Canada 482 Canada 484 Email: daniel.voyer@bell.ca 486 Clarence Filsfils 487 Cisco Systems, Inc. 488 Belgium 490 Email: cfilsfil@cisco.com 492 Darren Dukes (editor) 493 Cisco Systems, Inc. 494 Ottawa 495 Canada 497 Email: ddukes@cisco.com 498 Satoru Matsushima 499 Softbank 500 Japan 502 Email: satoru.matsushima@g.softbank.co.jp 504 John Leddy 505 Individual Contributor 506 USA 508 Email: john@leddy.net 510 Zhenbin Li 511 Huawei 512 China 514 Email: lizhenbin@huawei.com 516 James Guichard 517 Futurewei 518 USA 520 Email: james.n.guichard@futurewei.com