idnits 2.17.1 draft-ao-sfc-scalability-analysis-04.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 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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: '... Id field MUST be presented in the N...' RFC 2119 keyword, line 197: '...he Flow Id field MUST be presented in ...' RFC 2119 keyword, line 222: '...the upstream SFF MUST be notified that...' RFC 2119 keyword, line 238: '... SFPID, but also MAY use Flow ID to se...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2018) is 2014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D.ietf-sfc-architecture' on line 323 looks like a reference -- Missing reference section? 'I-D.ietf-sfc-long-lived-flow-use-cases' on line 328 looks like a reference -- Missing reference section? 'I-D.ietf-sfc-nsh' on line 334 looks like a reference -- Missing reference section? 'I-D.ietf-sfc-offloads' on line 339 looks like a reference -- Missing reference section? 'RFC7498' on line 344 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG T. Ao 3 Internet-Draft ZTE Corporation 4 Intended status: Informational G. Mirsky 5 Expires: April 22, 2019 ZTE Corp. 6 October 19, 2018 8 Analysis of the SFC scalability 9 draft-ao-sfc-scalability-analysis-04 11 Abstract 13 SFC is an ordered set of service function, should be scalable to meet 14 broad range of requirements. The scalability of SFC can be 15 interpreted as ability of the SFC to accommodate one or more SFs 16 joining the SFC , or leaving the SFC without significant impact to 17 SFC performance. 19 This document presents four aspects on SFC scalability, and provide 20 analysis of the data plane and the control plane to implement the 21 scalable SFC. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 22, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Four Use cases for scale-out/scale-in . . . . . . . . . . . . 3 60 3.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2.1. SF Redundancy . . . . . . . . . . . . . . . . . . . . 3 63 3.2.2. SFC Redundancy . . . . . . . . . . . . . . . . . . . 4 64 3.3. By-pass . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Failure or Remove . . . . . . . . . . . . . . . . . . . . 5 66 4. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 6 67 5. Control Plane Requirements . . . . . . . . . . . . . . . . . 6 68 5.1. Centralized CP . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Distributed CP . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. Information References . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Service Function Chain (SFC) is the chain with a series of ordered 78 Service Functions(SF). The SFC maybe changed because of load balance 79 , failure, or other management requirement. We call it SFC 80 scalability. The SFC being scalable means that the Service Functions 81 can be added or removed from the path of this SFC without impact on 82 other SFCs and minimal impact in the SFC being modified. With this 83 capability, SFC is more flexible and elastic to adapt all kinds of 84 requirements. 86 In this document, we will present four use cases on SFC scale-out and 87 scale-in, and analysis some requirements to support SFC scalability. 89 2. Terminology 91 SFC(Service Function Chain): An ordered set of some abstract SFs. 93 SFC Scale-out: One or more SFs are added into the path of the SFC for 94 the sake of load balance, protection or other new services 95 requirement. 97 SFC Scale-in: One or more SFs are removed from the path of the SFC 98 for the sake of the SFs are by-passed or the SFs are failed. 100 3. Four Use cases for scale-out/scale-in 102 Following describes four use cases to illustrate the scalability of 103 the SFC. 105 3.1. Join 107 This is SFC horizontal scale-out use case. One or more new SFs must 108 be added to a certain SFC for the traffic that has been classified to 109 require application of new SF(s). This case is the reverse scenario 110 to the by-pass. In this case one or more SFs that were by-passed 111 need to be re-inserted into the SFC. And the SFC itself can be 112 characterized as being scaled out. 114 There are two sub-cases of an SF joining the SFC. One when both the 115 SF and corresponding SFF are new to the SFC. The second is when the 116 SF attaches to an existing SFF. In the first scenario, control plane 117 needs to notify the upstream SFF to modify its next hop to point to 118 the new SFF and configure the new SFF's forwarding information. In 119 the second scenario control plane needs to configure the existing 120 SFF's forwarding information. In this scenario, SFF forwards the 121 packets not only according to the SFPID but also according to the 122 metadata in the SFC header. 124 3.2. Redundancy 126 3.2.1. SF Redundancy 128 This is an example of SFC vertical scale-out use case. One or more 129 SFs are added into the SFC to meet the redundancy or load balance 130 requirements for some certain SFs. This case is different from the 131 Join case (section 3.1) in which the SF in this case is the same with 132 one of the SF that is on the path of the SFC. The new SF have the 133 same function with the existing SF, so that the new SF is added into 134 the SFC to protect the existing corresponding SF and to load balance 135 the existing corresponding SF. Figure 1 is the illustration about SF 136 redundancy. In this figure, SF2' is the redundency of SF2, so that 137 when SF2 is down, SF2' can keep working. 139 +-----------+ 140 | SFC | +----+ +----+ +----+ 141 |Classifier |---->|SFF1|----->|SFF2|------->|SFF3| 142 | Node | | | | | | | 143 +-----------+ +----+ +----+ +----+ 144 | | | 145 | -------- | 146 | | | +-----------+ 147 +----+ +----+ +----+ | SFC Proxy | 148 | SF1| | SF2| |SF2'| +-----------+ 149 +----+ +----+ +----+ 150 Figure 1 152 In this case, control plane need to notify the upstream SFF that a 153 new SF joins the SFC as a redundancy SF for protection or load 154 balance, and its next hop should be a protection group or ECMP group. 155 For the purpose of load balance to ensure proper forwarding, the Flow 156 Id field MUST be presented in the NSH as expression of entropy so 157 that SFF can select an SF from the group according to the Flow Id. 158 In the above figure, SFF2 knows that it is connecting a group of SFs 159 and when it foward the packet, it would use Flow id in NSH. 161 3.2.2. SFC Redundancy 163 This is also an example of SFC vertical scal-out use case, namely 164 Reduncancy. In this case, SFC is scaled out to two SFP paths. One 165 SFP is redundant to another SFP, and the two SFPs are for protection 166 or load balance. They belongs to a SFC, but have different SFP. The 167 two SFPs are forming a group. Figure 2 is the illustration about the 168 SFC redundancy. In this figure, we can see that SF1', SF2', SFC 169 proxy' are the backup of the SF1, SF2, SFC Proxy seperately. The two 170 SFPs are a group for the Classifier. All these nodes can be joint at 171 some nodes and can be disjoint as well. In the figure 2, all the 172 nodes are disjoint. 174 +-----+ +-----+ +-----------+ 175 | SF1 | | SF2 | | SFC Proxy | 176 +-----+ +-----+ +-----------+ 177 +-----------+ | | | 178 | SFC | +-----+ +---- + +-----+ 179 |Classifier |---->|SFF1 |----->|SFF2 |------->|SFF3 | 180 | Node | | | | | | | 181 +-----------+ +-----+ +-----+ +-----+ 182 | 183 | 184 | +-----+ +-----+ +-----+ 185 ----------->|SFF1'|----->|SFF2'|------->|SFF3'| 186 | | | | | | 187 +-----+ +-----+ +-----+ 188 | | | 189 +-----+ +-----+ +-----------+ 190 | SF1'| | SF2'| | SFC Proxy'| 191 +-----+ +-----+ +-----------+ 192 Figure 2 194 In this case, control plane need to notify the Classifier that the 195 SFC is a group which contains two SFPs. The group can be used as 196 protection or load balance. For the purpose of load balance, to 197 ensure proper forwarding, the Flow Id field MUST be presented in the 198 NSH as expression of entropy so that the forwarder in the classifier 199 can select an SFP from the group according to the Flow Id. For the 200 case of joint, the joint node also need to have capability to forward 201 the traffic accroding to the Flow ID. 203 3.3. By-pass 205 This is an example of horizontal scale-in case. In this scenario 206 some SFs are not removed from the SFC but just by-passed by the 207 traffic so that the packets will not be processed by these SFs. Use 208 cases for this scenario are described in [draft-ietf-sfc-long-lived- 209 flow-use-cases] and [draft-ietf-sfc-offloads] . In these two drafts, 210 the SF is offloaded because it is not necessary to steer the traffic 211 to the SFs to improve the forwarding performance. 213 The corresponding solution is also provided in the above drafts. 215 3.4. Failure or Remove 217 This is a vertical SFC scale-in case. This happens only when the SFC 218 is being protected or load balanced. When SF of one SFC has failed 219 or needs to be removed because it is no longer needed to do the 220 pretection, the ability of the SFC to scale-in is excercised. 222 In this case, the upstream SFF MUST be notified that its next hop has 223 been changed to the next SF of the SF. 225 From the cases described we can conclude that no matter if is SFC 226 scale-out case or scale-in cases, there are some requirements to SFC 227 control protocol. And for some cases, there are requirements to data 228 plane as well. 230 4. Data Plane Requirements 232 For the cases of load balancing or protection switchover of SFC 233 scalability, it is highly beneficial to have an entropy field in the 234 SFC header NSH. The entropy may be presented in the dedicated field 235 named as Flow ID which be part of SFC encapsulation. 237 This means that SFF not only forwards the traffic based on different 238 SFPID, but also MAY use Flow ID to select particular SF out of set of 239 SFs of the same type. 241 According to the NSH draft in draft--ietf-sfc-nsh-27, we propose to 242 extend NSH to include the entropy field. Two options can be 243 considered. One is to use existing field, for example, some reserved 244 bits. Suggested extended field in NSH Service Path Header is showed 245 in Figure 3. 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Service Path Identifier (SPI) | Service Index | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Reserved | Flow ID | 252 +-----------------------------------------------+---------------+ 253 Figure 3 255 Another is to extend a new metadata to meet the requirement. Which 256 has been described in the section 8 of the draft-quinn-sfc-nsh-tlv-04 257 . 259 5. Control Plane Requirements 261 5.1. Centralized CP 263 SFC Controller is required to: 265 a) Send a message to SFF that the joined SF connected to set the 266 correct SFPID and its next hop. 268 b) Send register message to upstream SFF or classifier with some 269 information. The information not only includes next hop locator, but 270 also includes an indicator if the next hop is a new joined SF or a 271 group that a new SF that added into. If the indicator is a new 272 joined SF, it means the new SF will join the SFC. If the indicator 273 is a group, it means a new SF or a new SFP will be added into this 274 group for load balance or protection. 276 c) Send de-register message to upstream SFF or classifier with some 277 information. The information not only includes next hop locator, but 278 also includes an indicator that if the next hop is by-passed, or the 279 next hop is removed from a group. If the indicator is the by-passed 280 SF, it means the current SF is by-passed or is leaving from the SFC. 281 If the indicator is a group SF, it means the current SF or SFP will 282 be removed from a protection group that is for load balance or 283 protection. 285 5.2. Distributed CP 287 Distributed SFC CP can be used in Plug-and-Play scenario. 288 Distributed SFC CP required: 290 a) The SF that needs to join into the SFC or be by-passed by the SFC 291 should explicitly notify the SFF it is associated with. 293 b) Once get the connection notification from the SF, the associated 294 SFF should send a register message to the upstream SFF with some 295 information. Such information not only includes next hop locator, 296 but also includes an indicator that if the next hop is a new joined 297 SF or the next hop is a new SF that added into a group. If the 298 indicator is a new joined SF, it means a new SF will join the SFC. 299 If the indicator is a group, it means a new SF will be added into a 300 group for load balance or protection. 302 c) The SFF send de-register message to upstream SFF with some 303 information. Such information not only includes next hop locator, 304 but also includes an indicator that if the next hop is the next SF 305 because the current SF is by-passed, or the next hop is the SF that 306 is removed from a group. If the indicator is the by-passed SF, it 307 means the current SF is by-passed or is leaving from the SFC. If the 308 indicator is group SF, it means the current SF will be removed into a 309 protection group that is for load balance or protection. 311 6. Security Considerations 313 For the scalability of the SFC, security is very important to be 314 considered. Before allow the SF to join to the SFC, it is required 315 to make sure the SF's security first. 317 7. IANA Considerations 319 TBD 321 8. Information References 323 [I-D.ietf-sfc-architecture] 324 Halpern, J. and C. Pignataro, "Service Function Chaining 325 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 326 in progress), July 2015. 328 [I-D.ietf-sfc-long-lived-flow-use-cases] 329 Krishnan, R., Ghanwani, A., Halpern, J., Kini, S., and D. 330 Lopez, "SFC Long-lived Flow Use Cases", draft-ietf-sfc- 331 long-lived-flow-use-cases-03 (work in progress), February 332 2015. 334 [I-D.ietf-sfc-nsh] 335 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 336 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 337 November 2017. 339 [I-D.ietf-sfc-offloads] 340 Kumar, S., Guichard, J., Quinn, P., Halpern, J., and S. 341 Majee, "Service Function Simple Offloads", draft-ietf-sfc- 342 offloads-00 (work in progress), April 2017. 344 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 345 Service Function Chaining", RFC 7498, 346 DOI 10.17487/RFC7498, April 2015, 347 . 349 Authors' Addresses 351 Ting Ao 352 ZTE Corporation 353 No.889, BiBo Road 354 Shanghai 201203 355 China 357 Phone: +86 21 68897642 358 Email: ao.ting@zte.com.cn 359 Greg Mirsky 360 ZTE Corp. 361 1900 McCarthy Blvd. #205 362 Milpitas, CA 95035 363 USA 365 Email: gregimirsky@gmail.com