idnits 2.17.1 draft-hegde-spring-sfc-stitched-tunnel-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 96 has weird spacing: '...rations to...' -- The document date (January 7, 2021) is 1198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-pce-pcep-extension-native-ip' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC7498' is defined on line 307, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-pce-pcep-extension-native-ip-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-15 == Outdated reference: A later version (-02) exists of draft-saad-teas-rsvpte-ip-tunnels-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Hegde 3 Internet-Draft C. Barth 4 Intended status: Informational Juniper Networks Inc. 5 Expires: July 11, 2021 January 7, 2021 7 Service Function Chaining with Stitched Tunnels 8 draft-hegde-spring-sfc-stitched-tunnel-00 10 Abstract 12 The term "service function chaining" is used to describe the 13 definition and instantiation of an ordered list of instances of such 14 service functions, and the subsequent "steering" of traffic flows 15 through those service functions.This document describes transport 16 mechanisms that use stitched tunnels to achieve end-to-end service 17 chaining. This document specifies two different types of transport 18 encodings, one based on SR-MPLS and another based on IP tunnels. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 11, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Concept of Stitched Tunnel . . . . . . . . . . . . . . . . . 3 57 4. SR-MPLS based Tunnels . . . . . . . . . . . . . . . . . . . . 6 58 5. IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 11.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Service function chaining requires an ordered set of service 72 functions to be executed on the traffic. The set of service 73 functions could be virtualized functions or physical appliance based 74 functions or in some cases a mix of both. Traffic needs to be 75 steered to the set of service functions in an ordered manner. Based 76 on the the type of traffic, the order of the service functions and 77 the type of service functions that need to be executed may differ. 78 Service functions may not be aware of the transport encodings and 79 hence the transport encodings may have to be removed before passing 80 the packet(s) to the service functions. 82 Section Section 3 describes basic concepts of using stitched tunnels 83 to steer the traffic through the service functions. 84 Section Section 4 describes the transport encodings using SR-MPLS 85 based tunnels [RFC8402]. Section Section 5 describes the transport 86 encodings using IP Tunnels [I-D.saad-teas-rsvpte-ip-tunnels]. 88 This document uses terminology defined in [RFC7665]. 90 2. Terminology 91 This document uses the following terminology 93 o Service Function Orchestrator (SFO): Service Function Orchestrator is 94 responsible for defining the Service Function Chains and the traffic 95 types where the particular service function chains are applicable. 96 SFO is also responsible for making all the required configurations to 97 realize the Service Chain. 99 Figure 1: Terminology 101 3. Concept of Stitched Tunnel 103 Consider a data center environment with virtualized service functions 104 as shown in (See Figure 2). DCGW1 and DCGW2 are Data center Gateway 105 devices that connect the data center to the WAN. SP1 and SP2 are 106 spine devices. TOR1, TOR2 and TOR3 are Top-Of-the-Rack switches that 107 connect to the servers. a1,b1, c1 etc are VLAN interfaces that 108 connect to the servers. A1, B1, C1 etc are the service function 109 instances deployed in the servers. 111 +------------------------------------------------------------+ 112 | +------+ +------+ | 113 | | DCGW1| | DCGW2| | 114 | +------+ +------+ | 115 | | | | 116 | +-----+ +-----+ | 117 | | SP1 |----+ +---------| SP2 | | 118 | +-----+ | | +-----+ | 119 | | | | | | | | 120 | +--------+ | | | | +--------+ | 121 | | +--------|------|-|-----------+ | | 122 | | | +------|-|--------------------+ | | 123 | | | | | | | | 124 | +------+ +------+ +------+ | 125 | | TOR1 | | TOR2 | | TOR3 | | 126 | +------+ +------+ +------+ | 127 | / | \ / | \ / | \ | 128 | a1 b1 c1 a2 b2 c2 a3 b3 c3 | 129 | +---------+ +----------+ +----------+ | 130 | | A1 B1 C1| | A2 B2 C2 | | A3 B3 C3 | | 131 | +---------+ +----------+ +----------+ | 132 | | 133 +------------------------------------------------------------+ 135 Figure 2: Virtualized Service Functions 137 Let us assume certain traffic that originates at A1 and destined to Z 138 (destination attached to remote WAN device not shown in the diagram), 139 needs to visit service functions deployed at A2 and A3. Traffic that 140 originates at B1 and destined to Z needs to visit service functions 141 B2 and B3. The stepwise procedures described below provide the basic 142 constructs involved in creating a stitched tunnel solution for 143 steering traffic through the service functions. 145 Building Tunnels: The traffic that originates at A1 and destined to Z 146 needs to visit A2 and A3. To achieve this, two transport tunnels are 147 built. The first tunnel Tunnel1 from TOR1 to TOR2 exiting on a2 148 VLAN. As the tunnels ends at the TOR2, the transport encapsulation 149 is removed and the original packet is passed to A2. Another tunnel 150 Tunnel2 is built from TOR2 to TOR3 exiting on a3 VLAN. 152 Similarly for the traffic originating at B1 and destined to Z, two 153 more tunnels are built. Tunnel3 from TOR1 to TOR2 exiting on b2 VLAN 154 and Tunnel4 TOR2 to TOR3 exiting from b3 interface 156 These separate tunnels will be stitched together using traffic 157 classification rules as described below 158 Traffic classification and steering: The traffic is classified at the 159 TOR1 based on either 5-tuple or based on other fields in in the 160 packet such as DSCP bits. In the above example, the traffic steering 161 may be based on source and destination address. Traffic from source 162 A1 and destination Z will be steered into Tunnel1. On TOR2, traffic 163 steering policies for source A1 and destination Z will steer the 164 traffic into Tunnel2. 166 Service Function Orchestrator (SFO): SFO is responsible for deploying 167 the service function instances. SFO builds tunnels from TOR1 to TOR2 168 and TOR2 to TOR3 etc as required by the service function chain. SFO 169 is also responsible for defining the traffic steering policies and 170 configuring them on appropriate traffic entry points. For 171 simplicity, the example in this section shows all virtualized service 172 functions, but the concepts equally apply to service functions 173 deployed on physical devices or a mix of physical and virtualized 174 service functions. 176 Bidirectionality: Certain service functions require the order of 177 service chaining to be preserved for the return traffic. In the 178 stitched tunnel based solution, the transport encodings are 179 completely independant and are not aware of the service functions. 180 The SFO should ensure the traffic steering policies on traffic entry 181 points to ensure correct order of service functions for the reverse 182 traffic. For example, the traffic with source Z and destination A1, 183 should be steered to TOR3 , exiting on a3 VLAN and on TOR3, same 184 policy should steer the traffic into a tunnel from TOR3 to TOR2 185 exiting from VLAN a2. 187 Looping service Functions: [RFC7665] describes possibility of looping 188 service functions that require to be applied repeatedly. In the 189 solution based on stitched tunnels, this needs to be orchestrated by 190 the SFO and traffic should be steered into the right tunnel to 191 redirect to the service function that needs to be applied. For 192 example, if the service function at A2 need to be re-applied after 193 servicing A3, the traffic steering policy at TOR3 should steer the 194 traffic through a tunnel from TOR3 to TOR2 existing out of VLAN a2. 196 Meta data handling: The trasnport encodings in stitched tunnel 197 solution is completely independent of meta data handling. There may 198 be SFC encapsulations as described in [RFC8300] or other kinds of 199 packet encapsulations. Transport encodings will see these 200 encapsulations as if it was original packet and hand it over to the 201 service functions. 203 4. SR-MPLS based Tunnels 205 Segment Routing (SR) [RFC8402] is an architecture based on the source 206 routing paradigm. SR can be used with an MPLS or an IPv6 data plane 207 to steer packets through an ordered list of instructions, called 208 segments. [I-D.ietf-spring-segment-routing-policy] describes a 209 mechanism to use a stack of segments to steer the traffic along the 210 explicit path. The Tunnel1 and Tunnel2 described in Section 3 can be 211 built using the segments. For example, the Tunnel1 may be built from 212 TOR1->SP1->TOR2->a2. The path may be represented using Node-SID or 213 Adj-SID as specified in [RFC8402]. At every segment end-point, the 214 segment will be removed and traffic will be forwarded as per the next 215 segment. on TOR2, the segment for a2 should be an Adj-SID. In Data 216 center networks that deploy IGPs, this could be an Adj-SID for the 217 the passive IGP interface. When the traffic hits TOR2, the passive 218 Adj-SID for a2 will be removed and traffic will be sent on a2 V-LAN. 219 As the transport encodings are completely removed from the packet 220 before sending to the Service Function, there is no special handling 221 required for SR-aware and SR-unaware service functions. 223 5. IP Tunnels 225 [I-D.saad-teas-rsvpte-ip-tunnels] is a solution that describes the 226 use of RSVP (Resource Reservation Protocol) to establish Point-to- 227 Point (P2P) Traffic Engineered IP (IP-TE) Label Switched Path (LSP) 228 tunnel(s) for use in native IP forwarding networks. The solution 229 introduces one or more reserved local IP prefixes, referred to as 230 Egress Address Blocks (EABs) per egress router that are dedicated for 231 RSVP to establish IP-TE LSP(s) tunnels. In 232 [I-D.saad-teas-rsvpte-ip-tunnels], EABs are managed by the egress 233 router. To facilitate service chaining, EAB management would be the 234 responsibility of the SFO along with the aforementioned flow steering 235 mentioned above. Further, in draft-saad-teas-rsvpte-ip-tunnels RSVP 236 is responsible for path establishment from ingress router to egress 237 router for a given IP-TE tunnel. In this solution, the SFO would not 238 only serve to calculate the explicit path of the IP-TE tunnel but 239 also to program the per node forwarding state for each IP-TE tunnel. 240 Extensions to the Path Computation Element Protocol (PCEP) as defined 241 in [I-D.ietf-teas-pce-native-ip] and 242 [I-D.ietf-pce-pcep-extension-native-ip]could be leveraged. The 243 Tunnel1 and Tunnel2 described in Section 3 can be built using per ToR 244 per VLAN EAB IP-TE tunnels. For example, the Tunnel1 may be built 245 from TOR1->SP1->TOR2->a2. The path may be represented using the EAB 246 associated with A2 vlan a2. At every IP-TE tunnel end-point, the IP 247 tunnel Encapsulation header will be removed and traffic will be 248 forwarded accordingly. 250 6. Backward Compatibility 252 TBD 254 7. Security Considerations 256 TBD 258 8. IANA Considerations 260 NA 262 9. Acknowledgements 264 TBD 266 10. Contributors 268 11. References 270 11.1. Normative References 272 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 273 Chaining (SFC) Architecture", RFC 7665, 274 DOI 10.17487/RFC7665, October 2015, 275 . 277 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 278 Decraene, B., Litkowski, S., and R. Shakir, "Segment 279 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 280 July 2018, . 282 11.2. Informative References 284 [I-D.ietf-pce-pcep-extension-native-ip] 285 Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu, 286 "PCEP Extension for Native IP Network", draft-ietf-pce- 287 pcep-extension-native-ip-09 (work in progress), October 288 2020. 290 [I-D.ietf-spring-segment-routing-policy] 291 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 292 P. Mattes, "Segment Routing Policy Architecture", draft- 293 ietf-spring-segment-routing-policy-09 (work in progress), 294 November 2020. 296 [I-D.ietf-teas-pce-native-ip] 297 Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path 298 Computation Element (PCE) based Traffic Engineering (TE) 299 in Native IP Networks", draft-ietf-teas-pce-native-ip-15 300 (work in progress), December 2020. 302 [I-D.saad-teas-rsvpte-ip-tunnels] 303 Saad, T. and V. Beeram, "IP RSVP-TE: Extensions to RSVP 304 for P2P IP-TE LSP Tunnels", draft-saad-teas-rsvpte-ip- 305 tunnels-01 (work in progress), November 2019. 307 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 308 Service Function Chaining", RFC 7498, 309 DOI 10.17487/RFC7498, April 2015, 310 . 312 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 313 "Network Service Header (NSH)", RFC 8300, 314 DOI 10.17487/RFC8300, January 2018, 315 . 317 Authors' Addresses 319 Shraddha Hegde 320 Juniper Networks Inc. 321 Exora Business Park 322 Bangalore, KA 560103 323 India 325 Email: shraddha@juniper.net 327 Colby Barth 328 Juniper Networks Inc. 330 Email: cbarth@juniper.net