idnits 2.17.1 draft-filsfils-spring-srv6-interop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2019) is 1880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-03 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils 3 Internet-Draft F. Clad, Ed. 4 Intended status: Informational P. Camarillo, Ed. 5 Expires: September 5, 2019 Cisco Systems, Inc. 6 A. AbdelSalam 7 Gran Sasso Science Institute 8 S. Salsano 9 Universita di Roma "Tor Vergata" 10 O. Bonaventure 11 Universite catholique de Louvain 12 J. Horn 13 J. Liste 14 Cisco 15 March 4, 2019 17 SRv6 interoperability report 18 draft-filsfils-spring-srv6-interop-02 20 Abstract 22 Segment Routing (SR) can be applied to the IPv6 data plane by 23 leveraging a new type of routing extension header, called Segment 24 Routing Header (SRH). An SRH contains an ordered list, or sequence, 25 of segments representing topological or service-based instructions, 26 or any combination of those. 28 This draft provides an overview of IPv6 Segment Routing (SRv6) 29 implementations and interoperability. It makes an inventory of the 30 various pieces of hardware and software that have been demonstrated 31 to support the processing of an SRH, and details some 32 interoperability scenarios that have been showcased at a public 33 event. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 5, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Routing platforms supporting SRH processing . . . . . . . . . 3 70 3. Applications supporting SRH . . . . . . . . . . . . . . . . . 4 71 4. Interoperability testing . . . . . . . . . . . . . . . . . . 4 72 4.1. Testbed configuration . . . . . . . . . . . . . . . . . . 4 73 4.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.2.1. L3 VPN . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.2.2. L3 VPN with traffic engineering . . . . . . . . . . . 6 76 4.2.3. L3 VPN with traffic engineering and service chaining 7 77 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 9. Informative References . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 Segment Routing (SR), defined in [RFC8402], allows a node to steer 87 packets through a controlled sequence of instructions, called 88 segments, by prepending an SR header to the packets. The IPv6 89 instantiation of Segment Routing (SRv6) leverages the Segment Routing 90 Header (SRH), a new type of IPv6 routing extension header defined in 91 [I-D.ietf-6man-segment-routing-header]. 93 As described in [I-D.filsfils-spring-srv6-network-programming], an 94 SRv6 segment is a network instruction composed of a locator and a 95 function that is encoded as an IPv6 address. The segment locator is 96 an IPv6 prefix used by routing devices to steer the packet along the 97 shortest IGP path up to the node that advertises this prefix. Since 98 the active segment is placed in the Destination Address field of the 99 IPv6 header, steering by intermediate devices only involves plain 100 IPv6 forwarding and does not require any SR-specific capability. 101 Once the packet reaches the node indicated by the segment locator, 102 the segment function is identified and the packet is processed 103 accordingly. Although the SR functions are locally defined on each 104 node, a set of general purpose functions have been proposed for 105 standardization in [I-D.filsfils-spring-srv6-network-programming] in 106 order to ease interoperability. This set is further extended with 107 specific purposes functions in [I-D.ietf-dmm-srv6-mobile-uplane] and 108 [I-D.xuclad-spring-sr-service-programming]. 110 2. Routing platforms supporting SRH processing 112 The hardware and software platforms listed below have been 113 demonstrated to support the processing of an SRH as described in 114 [I-D.ietf-6man-segment-routing-header]. This section also indicates 115 the supported SRv6 functions and transit behaviors on open-source 116 software. 118 Open-source platforms: 120 o Linux kernel[ref-1][ref-2]: End, End.X, End.T, End.DX2, End.DX6, 121 End.DX4, End.DT6, End.B6, End.B6.Encaps, T.Insert, T.Encaps, 122 T.Encaps.L2 124 o Linux srext module: End, End.X, End.DX2, End.DX6, End.DX4, End.AD, 125 End.AM 127 o FD.io VPP: End, End.X, End.DX2, End.DX6, End.DX4, End.DT6, 128 End.DT4, End.B6, End.B6.Encaps, End.AS, End.AD, End.AM, T.Insert, 129 T.Encaps, T.Encaps.L2 131 Cisco: 133 o Cisco ASR 1000 with IOS XE engineering code 135 o Cisco ASR 9000 with IOS XR engineering code 137 o Cisco NCS 5500 with IOS XR engineering code 139 Barefoot Networks: 141 o Barefoot Networks Tofino 143 3. Applications supporting SRH 145 In addition to the aforementioned routing platforms, the following 146 open-source applications have been extended to support the processing 147 of IPv6 packets containing an SRH. For Wireshark, tcpdump, iptables 148 and nftables, these extensions have been included in the mainstream 149 version. 151 o Wireshark[ref-3] 153 o tcpdump[ref-4] 155 o iptables[ref-5][ref-6] 157 o nftables[ref-7] 159 o Snort[ref-8] 161 4. Interoperability testing 163 The following interoperability testing scenarios were publicly 164 showcased on August 21-24, 2017 at the SIGCOMM conference. 166 Five different implementations of SRv6 behaviors were used for this 167 testing: 169 o Software implementation in Linux using the srext kernel module 170 created by University of Rome, Tor Vergata, Italy. 172 o Software implementation in the FD.io Vector Packet Processor (VPP) 173 virtual router. 175 o Hardware implementation in Barefoot Networks Tofino NPU using the 176 P4 programming language. 178 o Hardware implementation in Cisco NCS 5500 router using 179 commercially available NPU. 181 o Hardware implementation in Cisco ASR 1000 router using custom 182 ASIC. 184 4.1. Testbed configuration 185 +--------+ +---+ +---+ +---+ +--------+ 186 | Site A +-----+ 1 +--------+ 2 +--------+ 3 +-----+ Site B | 187 +--------+ +-+-+ +---+ +-+-+ +--------+ 188 | | 189 | +---+ +---+ | 190 +-----+ 4 +-----+ 5 +-----+ 191 +-+-+ +-+-+ 192 | | 193 +-+-+ +-+-+ 194 | 6 | | 7 | 195 +-+-+ +-+-+ 196 | | 197 +-+-+ +-+-+ 198 | 8 | | 9 | 199 +---+ +---+ 201 Figure 1: Testbed topology 203 As shown in the figure above, the testbed consisted of 9 different 204 nodes: 206 o Nodes 1 and 3 are Cisco ASR 1000 routers running IOS XE 207 engineering code 209 o Node 2 is a Cisco ASR 9000 router (realizing IPv6 forwarding only) 211 o Node 4 is a Barefoot Wedge 100BF router 213 o Node 5 is a Cisco NCS 5500 router running IOS XR engineering code 215 o Node 6 is a Linux server running the srext kernel module 217 o Node 7 is a Linux server running the FD.io VPP 219 o Node 8 is a Linux container running Snort 221 o Node 9 is a Linux container running iptables 223 On sites A and B the TRex software is used for traffic generation. 225 In addition, after every layer 3 operation in the network, Wireshark 226 traffic analyzer is used to verify proper functionality. 228 4.2. Scenarios 229 4.2.1. L3 VPN 231 This scenario covers simple L3 VPN functionality for IPv6 traffic 232 using the SRv6 behaviors T.Encaps and End.DX6 in conjunction with 233 regular IPv6 routing. 235 o IPv6 traffic is generated in site A and sent towards a destination 236 in site B. 238 o Node 1 performs the T.Encaps operation on the received traffic. 239 Each packet is encapsulated with an IPv6 header and an SRH 240 containing 1 segment, owned by node 3, then forwarded along the 241 shortest path to 3. 243 o Node 2 performs standard IPv6 forwarding. 245 o Node 3 performs the End.DX6 function on the received traffic. 246 Each packet is decapsulated then forwarded on the appropriate 247 interface towards site B. 249 o Traffic generator in site B captures and verifies the received 250 traffic. 252 4.2.2. L3 VPN with traffic engineering 254 This scenario covers L3 VPN overlay with underlay optimization in a 255 single SRv6 encapsulation (IPv6 header + SRH). It leverages the same 256 T.Encaps and End.DX6 behaviors as the first scenario, combined with 257 the End and End.X functions. 259 o IPv6 traffic is generated in site A and sent towards a destination 260 in site B. 262 o Node 1 performs the T.Encaps operation on the received traffic. 263 Each packet is encapsulated with an IPv6 header and an SRH 264 containing 3 segments, respectively owned by nodes 4, 5 and 3. 265 The outer IPv6 Destination Address is set to the first segment and 266 the packets are forwarded accordingly. 268 o Node 4 performs the End function, forwarding the packets on the 269 shortest paths towards node 5. 271 o Node 5 performs the End.X function, forwarding the packets on a 272 specific interface towards node 3. 274 o Node 3 performs the End.DX6, decapsulating and then forwarding 275 each packet on the appropriate interface towards site B. 277 o Traffic generator in site B captures and verifies the received 278 traffic. 280 4.2.3. L3 VPN with traffic engineering and service chaining 282 This scenario covers L3 VPN overlay with underlay optimization and 283 service chaining. Snort and iptables are SR-unaware services in this 284 situation and accessed via SRv6 dynamic proxy endpoint functions 285 implemented on nodes 6 and 7. 287 o IPv6 traffic is generated in site A and sent towards a destination 288 in site B. 290 o Node 1 performs the T.Encaps operation on the received traffic. 291 Each packet is encapsulated with an IPv6 header and an SRH 292 containing 5 segments, respectively owned by nodes 4, 6, 5, 7 and 293 3. The outer IPv6 Destination Address is set to the first segment 294 and the packets are forwarded accordingly. 296 o Node 4 performs the End.X function, forwarding the packets on a 297 specific interface towards node 6. 299 o Node 6 performs the End.AD function, sending the inner IPv6 packet 300 via 8 (Snort) and restoring the encapsulation on the way back. 302 o Node 5 performs the End function, forwarding the packets on the 303 shortest paths towards node 7. 305 o Node 7 performs the End.AD function, sending the inner IPv6 packet 306 via 9 (iptables) and restoring the encapsulation on the way back. 308 o Node 3 performs the End.DX6, decapsulating and then forwarding 309 each packet on the appropriate interface towards site B. 311 o Traffic generator in site B captures and verifies the received 312 traffic. 314 5. Contributors 316 David Lebrun, Prem Jonnalagadda and Milad Sharif substantially 317 contributed to the content of this document. 319 6. Acknowledgements 321 TBD 323 7. IANA Considerations 325 This document does not require any action from IANA. 327 8. Security Considerations 329 This document does not introduce any security consideration. 331 9. Informative References 333 [I-D.filsfils-spring-srv6-network-programming] 334 Filsfils, C., Camarillo, P., Leddy, J., 335 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 336 Network Programming", draft-filsfils-spring-srv6-network- 337 programming-07 (work in progress), February 2019. 339 [I-D.ietf-6man-segment-routing-header] 340 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 341 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 342 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 343 progress), February 2019. 345 [I-D.ietf-dmm-srv6-mobile-uplane] 346 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 347 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 348 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 349 uplane-03 (work in progress), October 2018. 351 [I-D.xuclad-spring-sr-service-programming] 352 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 353 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 354 Henderickx, W., and S. Salsano, "Service Programming with 355 Segment Routing", draft-xuclad-spring-sr-service- 356 programming-01 (work in progress), October 2018. 358 [ref-1] "Implementing IPv6 Segment Routing in the Linux Kernel", 359 July 2017, . 361 [ref-2] "Reaping the Benefits of IPv6 Segment Routing", October 362 2017, . 365 [ref-3] "Add support for Segment Routing (Type 4) Extension 366 Header", June 2016, . 370 [ref-4] "Add support for IPv6 routing header type 4", December 371 2017, . 374 [ref-5] "[net-next,v2] netfilter: add segment routing header 'srh' 375 match", January 2018, 376 . 378 [ref-6] "[iptables,v2] extensions: add support for 'srh' match", 379 January 2018, 380 . 382 [ref-7] "[nft] nftables: Adding support for segment routing header 383 'srh'", March 2018, 384 . 386 [ref-8] "IPv6 Segment Routing (SRv6) aware snort", March 2018, 387 . 389 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 390 Decraene, B., Litkowski, S., and R. Shakir, "Segment 391 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 392 July 2018, . 394 Authors' Addresses 396 Clarence Filsfils 397 Cisco Systems, Inc. 398 Belgium 400 Email: cf@cisco.com 402 Francois Clad (editor) 403 Cisco Systems, Inc. 404 France 406 Email: fclad@cisco.com 408 Pablo Camarillo Garvia (editor) 409 Cisco Systems, Inc. 410 Spain 412 Email: pcamaril@cisco.com 413 Ahmed AbdelSalam 414 Gran Sasso Science Institute 415 Italy 417 Email: ahmed.abdelsalam@gssi.it 419 Stefano Salsano 420 Universita di Roma "Tor Vergata" 421 Italy 423 Email: stefano.salsano@uniroma2.it 425 Olivier Bonaventure 426 Universite catholique de Louvain 427 Belgium 429 Email: olivier.bonaventure@uclouvain.be 431 Jakub Horn 432 Cisco 433 USA 435 Email: jakuhorn@cisco.com 437 Jose Liste 438 Cisco 439 USA 441 Email: jliste@cisco.com