idnits 2.17.1 draft-upa-srv6-service-chaining-exp-00.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 (October 30, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 188 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgp-ls-sr-service-segments-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-00 == Outdated reference: A later version (-11) exists of draft-ietf0-idr-srv6-flowspec-path-redirect-02 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING R. Nakamura, Ed. 3 Internet-Draft The University of Tokyo 4 Intended status: Informational Y. Ueno 5 Expires: May 2, 2020 NTT Communications Corporation 6 T. Kamata 7 Cisco Systems, Inc. 8 October 30, 2019 10 An Experiment of SRv6 Service Chaining at Interop Tokyo 2019 ShowNet 11 draft-upa-srv6-service-chaining-exp-00 13 Abstract 15 This document reports lessons learned from an experimental deployment 16 of service chaining with Segment Routing over the IPv6 data plane 17 (SRv6) at an event network. The service chaining part of the network 18 was comprised of four SRv6-capable nodes (three products from 19 different vendors), five SRv6 proxy nodes (two products from 20 different vendors and three open source software), and six services. 21 This network was deployed at Interop Tokyo 2019, and it successfully 22 provided network connectivity and services to all the exhibitors and 23 visitors on the event. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 2, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. SRv6 service chaining at Interop Tokyo 2019 ShowNet . . . . . 3 62 4. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Transparency of SRv6 header . . . . . . . . . . . . . . . 5 64 4.2. Services that cannot co-exist with End.AM . . . . . . . . 6 65 4.3. Service liveness detection and conditional advertisement 66 of service segments . . . . . . . . . . . . . . . . . . . 6 67 4.4. TTL Decrement on SRv6 Proxies . . . . . . . . . . . . . . 6 68 4.5. Control Plane Capabilities . . . . . . . . . . . . . . . 7 69 4.6. Match Condition for Applying SRv6 Functions . . . . . . . 7 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Standardizing functionalities for SRv6 service programming is still 80 an ongoing agenda. Meanwhile, some fundamental parts have begun to 81 be implemented: basic transit behaviors, endpoint functions at 82 ingress and egress nodes 83 [I-D.filsfils-spring-srv6-network-programming], and SR proxies for 84 SR-unaware services [I-D.ietf-spring-sr-service-programming]. Trying 85 out such running codes and devices would clarify statuses of recent 86 implementations and provide feedback to current and future 87 standardization processes. 89 To clarify the current status, we conducted an experiment of SRv6 90 service chaining at Interop Tokyo. Interop Tokyo is a large 91 exhibition of networking technologies, and ShowNet is the event 92 network built at Interop Tokyo while demonstrating new technologies 93 and conducting interoperability tests. In 2019, we deployed SRv6 94 service chaining with the latest implementations at ShowNet and 95 provided Internet connectivity for over 200 exhibitors and over 96 155,000 visitors. Through the experiment, we made several 97 observations from both implementation and specification perspectives: 98 transparency of SRv6 header (SRH), services that cannot co-exist with 99 the original masquerading proxy, how to integrate service liveness 100 into advertisement of service segments, behaviors of TTL decrement on 101 the masquerading proxy, necessity of control planes, and behavior of 102 the longest prefix match and SRv6 functions. This document reports 103 and discusses these lessons learned from the experiment of SRv6 104 service chaining. 106 2. Terminology 108 This document leverages the terminology proposed in [RFC8402], 109 [I-D.ietf-spring-segment-routing-policy], and 110 [I-D.ietf-spring-sr-service-programming]. 112 3. SRv6 service chaining at Interop Tokyo 2019 ShowNet 114 The experiment was conducted on Interop Tokyo, from June 12 to June 115 14, 2019. This section describes the overview of SRv6 service 116 chaining at ShowNet 2019. 118 The devices contributed to the experiment are listed below: 120 FUNCTION NAME CONTRIBUTOR 121 --------------------------------------------------------------- 122 T.Insert FX201 Furukawa Electric 123 T.Encaps FX201 Furukawa Electric 124 End.DT4 NCS55A1 Cisco Systems 125 NE40E-F1A Huawei 126 End FX201 Furukawa Electric 127 End.AM FX201 Furukawa Electric 128 Kamuee NTT Communications 129 VPP FD.io 130 End.AN TM VNFS Trend Micro 131 Variant of End.AD Two open source software on Linux 133 The variant of End.AD was the SRv6 tagging proxy designed for IPv4 134 traffic encapsulated in SRv6 and implemented for ShowNet. The detail 135 is described in [I-D.eden-srv6-tagging-proxy]. In addition to the 136 SRv6-capable devices, we deployed six SR-unaware services into the 137 service chaining. These services were applied to user traffic in 138 accordance with service menus. 140 SERVICE NAME CONTRIBUTOR 141 --------------------------------------------------------------- 142 Security FortiGate 3601E Fortinet 143 Lastline Defender Lastline 144 PA-5280 Palo Alto Networks 145 Thunder 3230S CFW A10 Networks 146 TBA 147 CGN Thunder 7440-11 CFW A10 Networks 149 Note that the detailed security services were different depending on 150 each device (e.g., DPI, URL filtering, etc). 152 +------------+ 153 |The Internet| 154 +--------+ +-----+------+ +--------+ 155 |Services| | |Services| 156 +-+----+-+ | +-+----+-+ 157 | | | | | 158 +---+----+---+ /----+-----\ +---+----+---+ 159 |SRv6 Proxies+---+ +---+SRv6 Proxies| 160 +------------+ | | +------------+ 161 | Backbone | 162 | | 163 +---------+ +--------+ 164 | \----------/ | 165 | | 166 +---+---+ +-----+ +-----+ +--+-----+ 167 |NCS55A1+---+FX201| |FX201+---+N40E-F1A| 168 +---+---+ +-----+ +-----+ +--+-----+ 169 | | 170 +--+---+ +--+---+ 171 |Router| |Router| 172 +--+---+ +--+---+ 173 | | 174 /+-+-----------------------------+--+\ 175 + End users + 176 \+----------------------------------+/ 178 Figure 1: Overview of SRv6 Service Chaining at ShowNet 180 Figure 1 illustrates an overview of the experimental topology. End 181 users, i.e., exhibitors and visitors, were accommodated by two non- 182 SR-capable routers. The two FX201 had default routes for users, and 183 the FX201 applied T.Insert and T.Encaps to received IPv6 and IPv4 184 packets from the users, respectively. The packets with the SRH were 185 delivered to the SRv6 proxies by the active service segments. The 186 SRv6 proxies connected to the backbone received the packets and 187 performed the proxy behaviors to take the packets through the 188 services. Lastly, Segment List[0] representing endpoint functions 189 took the packets to FX201 again for End and popping the SRH, or 190 NCS55A1 or NE40E-F1A for End.DT4. 192 From the Internet to users, packets followed a similar path: FX201 193 inserted SRH to the packets, services were applied to the packets in 194 the reverse order, and FX201 removed the SRH from IPv6 packets, or 195 NCS55A1 or NE40E-F1A decapsulated IPv4 packets in the SRH and outer 196 IPv6 headers. 198 The reason why we chose T.Insert instead of T.Encaps for IPv6 packets 199 is to use the masquerading proxy (End.AM). SR proxies excluding 200 End.AM require a proxy instance or an interface for receiving traffic 201 returning from the service (IFACE-IN) for each SR service policy. In 202 the ShowNet, there were over 200 individual users (exhibitors); 203 therefore, there was the possibility that we needed to prepare over 204 200 proxy instances or interfaces for each service. It was possible, 205 however, not reasonable for the temporal network for the three-days 206 event. Therefore, we used T.Insert and End.AM for IPv6 packets to 207 multiplex service chains on a proxy instance for a service. 209 End.AM is applicable to only SRv6 insertion; thus, IPv4 traffic still 210 has the same issue. To address this issue, we designed the SRv6 211 tagging proxy, which is a new variant of End.AD, for IPv4 packets 212 encapsulated in SRv6 [I-D.eden-srv6-tagging-proxy]. An XDP-based 213 implementation was used for delivering all user traffic, and a Linux 214 kernel-based implementation was also tested at ShowNet. 216 Although we faced some challenges described in the next section, this 217 SRv6 service chaining finally fulfilled the role. It delivered all 218 user traffic and applied the services during the period of Interop 219 Tokyo 2019. 221 4. Lessons Learned 223 This section shares lessons learned from the experimental deployment. 225 4.1. Transparency of SRv6 header 227 First, we report that all the services contributed to ShowNet 228 transparently delivered IPv6 packets under the End.AM proxies, 229 although SRH is a new IPv6 extension header. There were no devices 230 that dropped packets due to the unrecognized extension header. 232 4.2. Services that cannot co-exist with End.AM 234 When we designed the ShowNet, we intended to deploy a captive portal 235 at service chaining. However, we could not accomplish that. The 236 masquerading proxy assumes that the service under the proxy can only 237 inspect, drop, or perform limited changes to the packets as noted in 238 [I-D.ietf-spring-sr-service-programming]. Besides, it assumes that 239 the packets returning from IFACE-IN have masqueraded SRH. This means 240 that packets originated by SR-unaware services do not have SRH; 241 therefore, the packets cannot be de-masqueraded. A captive portal is 242 one of the examples that originate packets. These SR-unaware 243 services cannot be integrated with the original masquerading proxy. 245 Instead, the variant 2 of masquerading proxy (Caching) defined in 246 Section 6.4.3 of [I-D.ietf-spring-sr-service-programming] would be 247 capable of handling such services. 249 4.3. Service liveness detection and conditional advertisement of 250 service segments 252 Advertising service segments should be stopped when corresponding 253 services are down to achieve redundancy of services in SRv6 service 254 chaining. It is also expected that SR proxies are capable of 255 stopping service segment advertisements. Meanwhile, the proxies 256 contributed to ShowNet had not implemented such functionality yet 257 because they were focusing on data plane functionalities at that 258 time. 260 Link downs do not always represent service downs; services might be 261 physical appliances behind switches or virtual machines on 262 hypervisors. To detect failures on the services, we suggest that SR 263 proxies should have some probing mechanisms for determining the 264 statuses of services under the proxies and integrate the statuses 265 with the advertisement process of the service segments. For example, 266 Bidirectional Forwarding Detection (BFD) [RFC8562] between IFACE-IN 267 and IFACE-OUT would determine the liveness of the services, and the 268 liveness property could be integrated into triggers for advertising 269 corresponding service segments. 271 4.4. TTL Decrement on SRv6 Proxies 273 We confirmed that there were variations on TTL decrement behaviors of 274 the End.AM proxies. An implementation decreases TTL of outer IPv6 275 headers when sending packets to IFACE-OUT, and another implementation 276 does not decrease TTL on IFACE-OUT. TTL decrement also occurs for 277 forwarding packets from IFACE-IN to the next segments. As a result, 278 TTL values of packets varied depending on the proxy implementations 279 that the packets passed through. The variation of TTL decrement is 280 not a significant matter for just forwarding traffic; however, it 281 would complicate Operation, Administration, and Maintenance (OAM) 282 because traceroute results would also vary depending on 283 implementations. Forwarding packets to IFACE-OUT is also layer-3 284 processing based on IPv6 headers and SRH; therefore, we suggest that 285 TTL should be decreased on IFACE-OUT. 287 4.5. Control Plane Capabilities 289 The SR node implementations in ShowNet were not capable of control 290 planes; therefore, we configured all the SR policies in ShowNet 291 manually. Despite manually configuring SR nodes for service chaining 292 is possible, it is hard to operate in realistic environments. 293 Advertising SR policies via BGP 294 [I-D.ietf-idr-segment-routing-te-policy] is also an essential 295 capability for service chaining that is a work in progress 296 [I-D.dawra-idr-bgp-ls-sr-service-segments]. 298 4.6. Match Condition for Applying SRv6 Functions 300 The SRv6 node implementations contributed to ShowNet applied SRv6 301 functions by the longest prefix match: SRv6 functions are represented 302 by pairs of destination prefixes for segments and functions. Packets 303 from users to the Internet would have arbitrary destinations; 304 therefore, the transit behaviors must be associated with default 305 routes. On the other hand, SR service policies inserted to packets 306 vary depending on users and their service menus. To apply different 307 SR service policies by the transit behaviors with default routes, we 308 used VRFs on FX201 that performed T.Insert and T.Encaps. An SR 309 service policy was associated with a transit behavior for a default 310 route on a VRF. The user networks were attached to VRFs 311 corresponding to their service menus. By this technique, we 312 accomplished per-user service chains at the transit nodes. 314 Per-VRF transit behavior is a practical candidate for SRv6 service 315 chaining. On the other hand, users and their traffic can be 316 distinguished by source addresses of packets. Thus, applying SRv6 317 functions in accordance with source addresses or other fields in 318 packets can also be a candidate implementation. For example, 319 leveraging SRv6 functions as actions of BGP Flowspec [RFC5575] is a 320 possible way for inserting SR policies into packets flexibly. This 321 is a different adaptation of BGP Flowspec to SRv6 in addition to 322 [I-D.ietf0-idr-srv6-flowspec-path-redirect]. 324 5. IANA Considerations 326 This document has no IANA implications. 328 6. Security Considerations 330 The security requirements and mechanisms described in [RFC8402], 331 [I-D.ietf-6man-segment-routing-header] and 332 [I-D.filsfils-spring-srv6-network-programming] also apply to this 333 document. 335 This document does not introduce any new security vulnerabilities. 337 7. Contributors 339 J. Cao (Huawei), T. Fujiwara (Furukawa Network Solution), M. Udaka 340 (Furukawa Network Solution), Y. Oga (Furukawa Network Solution), Y. 341 Ohara (NTT Communications), H. Shirokura (NTT Communications), Y. 342 Yamada (Keysight Technologies), K. Noda (Keysight Technologies), L. 343 Zhou (Spirent), T. Kawada (TOYO Corporation), T. Matsuba (TOYO 344 Corporation), Y. Matsubayashi (Trend Micro), and H. Nishikawa 345 (Trend Micro) substantially contributed to the content of this 346 document. 348 8. Acknowledgements 350 The authors would like to thank all the members and contributors of 351 Interop Tokyo 2019 ShowNet. The authors are thankful to Francois 352 Clad for his comments. 354 9. Normative References 356 [I-D.dawra-idr-bgp-ls-sr-service-segments] 357 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 358 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 359 and K. Talaulikar, "BGP-LS Advertisement of Segment 360 Routing Service Segments", draft-dawra-idr-bgp-ls-sr- 361 service-segments-02 (work in progress), July 2019. 363 [I-D.eden-srv6-tagging-proxy] 364 Ueno, Y., Nakamura, R., and T. Kamata, "SRv6 Tagging 365 proxy", draft-eden-srv6-tagging-proxy-00 (work in 366 progress), October 2019. 368 [I-D.filsfils-spring-srv6-network-programming] 369 Filsfils, C., Camarillo, P., Leddy, J., 370 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 371 Network Programming", draft-filsfils-spring-srv6-network- 372 programming-07 (work in progress), February 2019. 374 [I-D.ietf-6man-segment-routing-header] 375 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 376 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 377 Routing Header (SRH)", draft-ietf-6man-segment-routing- 378 header-26 (work in progress), October 2019. 380 [I-D.ietf-idr-segment-routing-te-policy] 381 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 382 D., and S. Lin, "Advertising Segment Routing Policies in 383 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 384 progress), July 2019. 386 [I-D.ietf-spring-segment-routing-policy] 387 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 388 bogdanov@google.com, b., and P. Mattes, "Segment Routing 389 Policy Architecture", draft-ietf-spring-segment-routing- 390 policy-03 (work in progress), May 2019. 392 [I-D.ietf-spring-sr-service-programming] 393 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 394 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 395 Henderickx, W., and S. Salsano, "Service Programming with 396 Segment Routing", draft-ietf-spring-sr-service- 397 programming-00 (work in progress), October 2019. 399 [I-D.ietf0-idr-srv6-flowspec-path-redirect] 400 Velde, G., Patel, K., Li, Z., and H. Chen, "Flowspec 401 Indirection-id Redirect for SRv6", draft-ietf0-idr-srv6- 402 flowspec-path-redirect-02 (work in progress), July 2019. 404 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 405 and D. McPherson, "Dissemination of Flow Specification 406 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 407 . 409 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 410 Decraene, B., Litkowski, S., and R. Shakir, "Segment 411 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 412 July 2018, . 414 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 415 Ed., "Bidirectional Forwarding Detection (BFD) for 416 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 417 April 2019, . 419 Authors' Addresses 421 Ryo Nakamura (editor) 422 The University of Tokyo 423 Tokyo 424 JP 426 Phone: +81-3-5841-2710 427 Email: upa@haeena.net 429 Yukito Ueno 430 NTT Communications Corporation 431 Tokyo 432 JP 434 Phone: +80 90 3085 5274 435 Email: yukito.ueno@ntt.com 437 Teppei Kamata 438 Cisco Systems, Inc. 439 Tokyo 440 JP 442 Email: tkamata@cisco.com