idnits 2.17.1 draft-dunbar-sfc-path-control-01.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 7 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 391 has weird spacing: '... size eve...' == Line 549 has weird spacing: '... put user ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2015) is 3339 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SRC-arch' is mentioned on line 117, but not defined == Missing Reference: 'SFC-arch' is mentioned on line 427, but not defined == Missing Reference: 'SFF-sequence' is mentioned on line 201, but not defined == Missing Reference: 'SFF-SF-sequence' is mentioned on line 202, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-02 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SFC working group L. Dunbar 2 Internet Draft A. Malis 3 Intended status: Standard Track Huawei 4 Expires: September 2015 6 March 6, 2015 8 Framework for Service Function Path Control 9 draft-dunbar-sfc-path-control-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be 18 modified, and derivative works of it may not be created, except to 19 publish it as an RFC and to translate it into languages other than 20 English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on September 6, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Abstract 58 This draft describes the framework of Service Function Path 59 Control when some service functions on the path fail or need to be 60 replaced. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Conventions used in this document..............................3 66 3. Terminology....................................................3 67 4. Background.....................................................4 68 4.1. Multiple Entities of one Service Function.................4 69 4.2. Rendered Service Path (RSP)...............................5 70 4.2.1. SFF-sequence and SFF-SF-sequence representation......5 71 4.3. Multiple ways of Controlling RSP..........................7 72 4.4. Impact of Virtualized Service Functions to SFP............8 73 5. Steering Policies to SFF.......................................9 74 6. Local Restoration of Service Functions........................10 75 7. Global Restoration of Service functions.......................12 76 7.1. Encoding the Exact SFF-SF-sequence in Data Packets.......12 77 7.2. Dynamic establishment of an RSP..........................13 78 7.3. Out-Of-Band Signaling of changes on SFP..................14 79 7.4. Hybrid Method............................................14 80 8. Regional Restoration of Service Function......................14 81 9. Conclusion and Recommendation.................................15 82 10. Manageability Considerations.................................15 83 11. Security Considerations......................................15 84 12. IANA Considerations..........................................15 85 13. References...................................................16 86 13.1. Normative References....................................16 87 13.2. Informative References..................................16 88 14. Acknowledgments..............................................16 90 1. Introduction 92 This draft describes the framework of Service Function Path (SFP) 93 control when some functions on the path fail or need to be 94 replaced. 96 SFP control for failed/moved/deleted service functions become more 97 crucial in virtualized environments (e.g. ETSI NFV), where service 98 functions are instantiated as VMs on servers. There is higher 99 chance of state changes for those Service functions as the result 100 of being decommissioned or replaced when over-utilized. 102 2. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 106 in this document are to be interpreted as described in RFC-2119 107 [RFC2119]. 109 In this document, these words will appear with that interpretation 110 only when in ALL CAPS. Lower case uses of these words are not to 111 be interpreted as carrying RFC-2119 significance. 113 3. Terminology 115 This draft uses the following terminologies defined by SFC-arch. 117 RSP: Rendered Service Path [SRC-arch] 119 SF: Service Function [SFC-arch]. 121 SFC: Service Function Chain [SFC-arch]. 123 SFF: Service Function Forwarder [SFC-arch]. 125 SFP: Service Function Path [SFC-arch]. 127 Here are the terminologies specific for this draft: 129 VSFI: SFC Visible Service Function Instance. 131 SFIC: Service Function Instance Component. One service 132 function (e.g. NAT44) could have two different service function 133 instantiations, one that applies policy-set-A (NAT44-A) and 134 other that applies policy-set-B (NAT44-B). There could be 135 multiple "entities" of NAT44-B (e.g. one "entity" only has 10G 136 capability), and many "entities" of NAT44-B. Each entity has its 137 own unique address. The "entity" in this context is called 138 "Service Function Instance Component" (SFIC). 140 Service Chain: The sequence of service functions, e.g. Chain#1 141 {s1, s4, s6}, Chain#2{s4, s7} at functional level. Also see the 142 definition of "Service Function Chain" in [SFC-Problem]. 144 Service Chain Instance Path: The actual Service Function 145 Instance Components selected for a service chain. 147 VNF: Virtualized Network Function [NFV-Terminology]. 149 4. Background 151 4.1. Multiple Entities of one Service Function 153 One service function (say, NAT44) could have two different service 154 function instantiations, one that applies to policy-set-A (NAT44- 155 A) and other that applies to policy-set-B (NAT44-B). There could 156 be multiple "entities" of NAT44-A (e.g. one "entity" only has 10G 157 capability), and many "entities" of NAT44-B. Each entity has its 158 own unique address (or Locator in [SFC-Reduction]). The "Entity" 159 in this context is called "Service Function Instance Component" 160 (SFIC). 162 Identical SFICs could be attached to different Service Function 163 Forwarder (SFF) nodes. It is also possible to have multiple 164 identical SFICs attached to one Service Function Forwarder (SFF) 165 node, especially in a Network Function Virtualization (NFV) 166 environment where each SFIC is a virtual service function with 167 limited capacity. 169 At the functional level, the order of service functions, e.g. 170 Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very 171 often which SFIC of the Service Function "s1" is selected for the 172 Chain #1 is not. 174 Some SFICs are visible to Service Chain Path. Sometimes a 175 collection of SFICs can appear as one single entity to the Service 176 Chain Path. When multiple SFICs are attached to one SFF, the 177 collection of all those SFICs can appear as a single Service 178 Function to the Service Chain Path. As described in Section 5.5 of 179 [SFC-arch], the SFF can make local decision in choosing the SFIC 180 among the collection of directly attached identical SFICs. The 181 individual SFIC in this collection doesn't have to be visible to 182 the SFP, the classifier, or orchestration. 184 It is also possible that multiple SFICs of one service function 185 can be reached by different SFF nodes as depicted by Figure 5 of 186 [SFC-arch]. 188 For the ease of description, the term "Service Function Instance" 189 is used in this draft to represent the identical SFICs that are 190 visible to the SFP. The identical SFICs attached to different SFFs 191 are obviously visible to SFP. But the identical SFICs attached to 192 one SFF via different ports can be local to the SFF, i.e. not 193 visible to the SFP. 195 4.2. Rendered Service Path (RSP) 197 [SFC-arch] defines RSP as the constrained specification of where 198 packets assigned to a certain service chain must go. 200 RSP can be logically represented by an ordered sequence of SFF 201 nodes [SFF-sequence] and an ordered sequence of SFs on each SFF of 202 the list [SFF-SF-sequence]. 204 RSP can also be SF-sequence without specifying which SFFs for the 205 SFs. 207 The SFF-SF-sequence can be explicitly encoded in the SFC header 208 for the SFP, or can be passed down, as "traffic steering 209 policies", to the relevant SFF nodes. 211 4.2.1. SFF-sequence and SFF-SF-sequence representation 213 Logically, the SFF-sequence is represented by a list of SFF nodes. 214 For a Chain sf2 -> sf3 -> sf4 over the network depicted by the 215 Figure 5 of SFC-arch (shown below with some minor changes), one 216 RSP could be for packets to traverse sf2 & sf3 attached to sff-a 217 followed by the sf4 attached to SFF-c. The corresponding SFF- 218 sequence for the RSP is [sff-a -> sff-c]. The corresponding SFF- 219 SF-sequence is [(sff-a: sf2->sf3)-> (sff-c: sf4)]. 221 The SFF-sequence and/or SFF-SF-sequence, e.g. {sff-a, sff-c}, can 222 be explicitly encoded in the SFC header for the SFP. 224 Alternatively, the SFF-sequence and/or SFF-SF-sequence can be 225 passed down, as "traffic steering policies", to the "sff-a" and 226 "sff-c" nodes for the SFP. The traffic steering policies can be 227 represented as "matching" & "action". 229 +---+ +---+ +---+ +---+ +---+ +---+ 230 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 231 +---+ +---+ +---+ +---+ +---+ +---+ 232 | | | | | | 233 +-----+-----+ +-----+-----+ 234 | | 235 + + 236 +----+ +-----+ +-----+ +-----+ +-----+ 237 source+-->|sffx|+-->|sff-a|+->|sff-b|+-->|sff-c|+-->|sff-d|+-->destination 238 +----+ +-----+ +-----+ +-----+ +-----+ 239 + + + 240 | | | 241 +---+ +---+ +---+ 242 |sf1| |sf4| |sf3| 243 +---+ +---+ +---+ 244 Figure 1:Service Function Attachment diagram 246 Suppose the SFC ID for this SFP is "yellow", the policy to "sff-a" 247 can be: 249 Matching | Action 250 --------------------------------------+------------------------- 251 SFC ID="yellow"& ingress = sffx-port | next-hop: "sf2" &VID 253 SFC ID = "yellow" & ingress= sf2-port | next-hop: "sf3" &VID 255 SFC ID = "yellow" & ingress=sf3-port | next-hop: sff-b 257 Figure 2:Traffic Steering Policy to a SFF node 259 4.3. Multiple ways of Controlling RSP 261 How SFF-SF-sequence is selected for a given SFP to form the actual 262 RSP is outside the scope of this draft. It is assumed that there 263 is an external entity (e.g. service chain orchestration system) 264 that is responsible for computing the SFF-sequence or SFF-SF- 265 sequence for any given SFC. 267 This document focuses on the framework of replacing service 268 functions for a given SFP/RSP. 270 To make the description easier, the following Service Chain 271 architecture reference is used: 273 Some head end Service Chain Classifier can be configured with (or 274 has the ability to specify) the exact SFF-SF-sequence for a given 275 SFC. Some Classifier may only specify the SFF-sequence for a given 276 SFC. Some Classifier may not specify SFF-sequence for a given SFC. 278 The SFF-SF-sequence or SFF-sequence can be 280 1. encoded in SFC header of every data packet; 281 2. Dynamic establishment of SFF-SF-sequence based on a SF- 282 Sequence, which is almost like a list of IP addresses with 283 each address representing one SF on the list; or 284 3. Dynamically programmed into relevant SFF nodes by a 285 centralized network controller or a network management 286 system, e.g. via I2RS interface. 288 The benefit of the Approach 1) above, i.e. encoding the exact path 289 in every data packet, is no contention when there is change of 290 RSP. The approach 1) above is basically "two dimensional" Source 291 Routing, not only with explicit SFF nodes on the path, but also 292 with exact SF sequence by each SFF node. Here are some issues 293 associated with the Approach 1): 295 - For large flows, i.e. large number of packets in the flow, 296 repeating the SFF-sequence/SFF-SF-sequence encoding in all 297 packets may not be optimal, e.g. it can waste bandwidth which 298 is not suitable for environment where bandwidth is limited. 299 - Whenever there is any state change to the SFs or SFFs on the 300 path, the head end classification node has to be notified to 301 encode a different path in data packets. 303 The approach 2) and 3) above are more appropriate for RSPs that 304 don't change frequently. Not encoding the exact SFF-SF path in 305 every data packet is beneficial to large flows. 307 When the in-band or out-of-band signaling methods are used to send 308 the flow steering policies to the relevant SFF nodes, the packets 309 associated with the SFP don't need to carry the SFF-SF-sequence or 310 SFF-sequence. The forwarding nodes, e.g. SFFs, can establish the 311 proper forwarding based on the steering policies. So they don't 312 need to interpret the sequence carried by each packet. 314 The out-of-band method doesn't require the head end Service Chain 315 Classifier to be configured with, nor has the capability to 316 specify, the exact RSP. The out-of-band steering policies can be 317 sent from an external entity, such as a centralized network 318 controller or service chain orchestration system, e.g. via I2RS 319 interface. Under this scenario, it doesn't require the head end 320 Chain Classifier node to be aware of any change on the RSP. 322 There are times that it might not be feasible for the head end 323 Service Chain Classifier to be notified of the changes of SFF- 324 sequence or SFF-SF-Sequence for a given SFP because of the time 325 taken for the notification and the limited capability of the 326 Classifier nodes. 328 If each Service Function has a large number of SFICs, it scales 329 better if the Classifier node doesn't need to be notified with 330 status of SFICs on a SFP. 332 4.4. Impact of Virtualized Service Functions to SFP 334 When a SFP consists of virtualized service functions, e.g. in an 335 ETSI NFV environment, the likelihood of changes to the 336 corresponding RSP can be higher due to: 338 - Higher failure rate of virtualized service functions because 339 most of them will not have build-in protection mechanism 340 - When a virtualized function is over-utilized, it is 341 relatively easy to replace it by another one (SFIC) or 342 instantiate more SFICs to take over the work load. 344 5. Steering Policies to SFF 346 It is assumed that there is an external service function chain 347 manager or an orchestration system that computes the Service 348 Function Path including the sequence of SFF nodes and the sequence 349 of service functions for flows to traverse within each SFF node. 350 It is beyond the scope of this draft on how the Service Function 351 Chain orchestration system computes the path. This draft focuses 352 on how & what the Service Function Orchestration pass to the 353 Service Function Forwarder node on the specific policies, as shown 354 in Figure below. 356 The SFF nodes are interconnected by tunnels, such as GRE, VxLAN, 357 etc, and the SF are attached to a SFF node via Ethernet link or 358 other link types. Therefore, the steering policies to a SFF node 359 for service function chain depends on if the packet comes from 360 previous SFF or comes from a specific SF. I.e. the SFC Service 361 Layer Steering policies have to be ingress port specific. There 362 are multiple different steering policies for one flow within one 363 SFF and each set of steering policies is specific for an ingress 364 port. 366 The semantics of traffic steering rules is "Match" and "Action", 367 similar to the "route" described in [I-D.ietf-i2rs-rib-info- 368 model]. The "match" & "action" for different ports can be 369 different. The matching criteria for SFF can be more 370 sophisticated. For example, the matching criteria could be any 371 fields in the data packets: 373 - Ingress port 374 - destination MAC, 375 - source MAC, 376 - VLAN_id, 377 - destination IP, 378 - source IP, 379 - TCP port, 380 - UDP port, 381 - QoS field, 382 - packet size, etc, or 383 - combination of any fields above. 385 Ingress Port & match 386 | 387 | 388 +-------+---------+--+----+--------+-------+---------+-------+ 389 | | | | | | | | 390 | | | | | | | | 391 L3Header L2header L4 VLAN VN ID size event .. 393 A SFF node may not support some of the matching criteria listed 394 above. It is important that Service Function Chain Orchestration 395 System can retrieve the supported matching criteria by the SFF 396 nodes. 398 The "Actions" for traffic steering could be to steer to the 399 attached service function or instance via a specific port with 400 specific VLAN-ID added, or next SFF nodes with specific VxLAN 401 header. 403 When steering to the attached service function, the action has to 404 include if additional VLAN-ID has to be added, or some header 405 field of the packets have to be removed (for packets with certain 406 header that is not supported by the attached service functions). 408 Action 409 | 410 | 411 +------------------------+-------------+-------+----- 412 | | | | 413 | | | | 414 Ingress from last SFF Steer to next SF | Egress to next SFF 415 Decapsulate packet header Add MAC header | Encapsulate VxLAN 416 | (SFF header, MPLS header, ..) 417 | 418 Ingress from SF 419 Remove MAC header 420 Encapsulate SFC header 422 6. Local Restoration of Service Functions 424 When one SF Forwarder (SFF) node has multiple Service Function 425 Instance Components (SFICs) of the same service function attached, 426 the SFF can make a local decision on which SFIC is selected for a 427 a given SFP, as described in Section 5.5 of [SFC-arch]. 429 E.g. In the diagram below, The SF Forwarder (SFF) "A" has two 430 instances of Service Function #7(SF7-1 & SF7-2), and 3 instances 431 of Service Function #2 (SF2-2, SF2-4, SF2-5). 433 +----+ +---+ +---+ +---+ 434 | SF2| |SF2| |SF2| |SFx| 435 | -2 | |-4 | |-5 | |-1 | 436 +----+ +---+ +---+ +---+ 437 | | | | 438 +------+-------+-------+ 439 | 440 +----+ +---+ | +---+ +---+ 441 | SF7| |SF7| | |SF5| |SF5| 442 | -1 | |-2 | | |-2 | |-4 | 443 +----+ +---+ | +---+ +---+ 444 : / / / 445 : / / /-----/ 446 \ / / / 447 +--------------+ +---------- +----+ 448 -- >| Chain |-- | SFF |------| SFF| ----> 449 |classifier | | A | | C | 450 +--------------+ +----------+ +----+ 452 Figure 3:Local Restoration of Service Functions 454 For a service function chain that consists of "Service Function 455 #7" followed by "Service Function #2", which is represented by 456 SF7->SF2, the steering policy to SFF "A" could be simply SF7->SF2 457 without specifying which components of SF7 & SF2 are selected. In 458 order for a SFF node to make local decision to choose one of the 459 identical SFICs for a service function, the SFF node has to be 460 aware of the SFICs for a given function on the SFP. The SFF node 461 can be notified or configured with such information: 463 SF7 == {Port# for SF7-1, Port# for SF7-3} 465 SF2 == {Port# for SF2-2, Port# for SF2-4, Port# SF2-5}. 467 The multiple components within the {} represents the equal SFICs 468 that the SFF can select locally. 470 The local protection and restoration is relatively simple and 471 clean. ECMP can be used to balance all the available SFICs 472 attached locally. 474 7. Global Restoration of Service functions 476 Sometimes changing the SFP's RSP involves using SFICs at different 477 SFF nodes. 479 For a Chain sf2 -> sf3 -> sf4 in the Figure 5 of SFC-arch (with 480 some minor changes): 482 +---+ +---+ +---+ +---+ +---+ +---+ 483 |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| 484 +---+ +---+ +---+ +---+ +---+ +---+ 485 | | | | | | 486 +-----+-----+ +-----+-----+ 487 | | 488 + + 489 +---+ +-----+ +-----+ +-----+ +-----+ 490 source+-->|sff|+-->|sff-a|+->|sff-b|+-->|sff-c|+-->|sff-d|+-->destination 491 +---+ +-----+ +-----+ +-----+ +-----+ 492 + + + 493 | | | 494 +---+ +---+ +---+ 495 |sf1| |sf4| |sf3| 496 +---+ +---+ +---+ 497 Figure 4: Global Restoration of Service Functions 499 Original Service Chain path: sf2 & sf3 at SFF-a; sf4 at SFF-c. 501 When the "sf3" attached to "sff-a" fails or over-utilized, the RSP 502 needs to use the sf3 attached to "sff-c". The Path becomes: 504 - sf2 at "sff-a"; sf3 & sf4 at "sff-c". 506 This section examines possible ways to achieve the restoration 507 when the change of SFP involves multiple SFF nodes. 509 7.1. Encoding the Exact SFF-SF-sequence in Data Packets 511 If the detailed SFF-SF-sequence is encoded in data packets, the SC 512 Classifier needs to be notified of the changes of the RSP. The 513 Classifier either gets notified of the exact SFF-SF-sequence from 514 external entity (e.g. controller or orchestration) or has the 515 ability reconstruct the new RSP. The later approach needs protocol 516 for the Classifier to be aware (or updated) of all the visible 517 SFICs' states and their runtime topology. 519 Encoding the exact SFF-SF-sequence in every packet won't cause any 520 contention issue among all the involved nodes when changes occur. 522 As mentioned in the previous section, encoding exact RSP path in 523 every packet has the benefit and the issues of source routing. 524 This approach may not be optimal when the RSP doesn't change very 525 frequently, as in minutes or hours, or bandwidth is limited. 527 7.2. Dynamic establishment of an RSP 529 A similar method to MPLS RSVP-TE [RSVP-TE] signaling can be 530 considered to dynamically establish the SFF-SF-sequence based on 531 the SF-sequence. 533 Here is the overview of this approach. More details will be added 534 later. 536 - The external controller computes the Service Chain Instance 537 Path or Service Chain path at functional level and sent to 538 the head end classifier node. 539 - The (segment) Head end Classifier node uses "Request for 540 Path" signaling (like MPLS's RSVP) to establish the RSP to 541 the nodes that on the path. 542 - All the nodes on the path establish the SF Forwarding Rule 543 to the directly attached service functions (or the service 544 function instances), and the appropriate tunnel from the 545 egress port to the next SFF node for the given SFP. 546 - When the Path Confirmation is received (i.e. all the nodes 547 along the path have completed the SF Forwarding Rule 548 establishment and tunnel establishment), the head end can 549 put user data along the pre-established Tunnel (e.g. 550 VxLAN). 552 The drawback of this approach is that the head end node might 553 receive packets belonging to the service function chain before all 554 the involved nodes (SFF or SF) have made the needed changes. 556 It is very similar to the issues encountered by MPLS Fast Reroute 557 [FRR]. MPLS FRR allows that packets to be dropped when a 558 restoration path is being dynamically signaled because there was 559 not a pre-established backup path. 561 7.3. Out-Of-Band Signaling of changes on SFP 563 If the out-of-band method is used, i.e. sending the updated flow 564 steering policies to indicate the changes of the SFP path, there 565 could be issues of synchronization and race conditions. For 566 example, if the SFF "A" and SFF "C" get flow steering policies at 567 slightly different times, some packets of the flow might miss some 568 service functions on the chain. 570 In SDN or SDN-like environments, changes to a SFP can be 571 dynamically programmed to relevant SFF nodes via out-of-band 572 signal form a central controller or Network Management System (as 573 in I2RS). 575 This approach does not require using end to end signaling protocol 576 among Classier nodes and SFF nodes. But there may be problems 577 introduced (such as loops or dropped packets) if SFF nodes are not 578 updated in the proper order or not at the same time; the nodes 579 should be updated in a similar time scale to the use of a 580 signaling protocol. In addition, the network may have a single 581 point of failure if the controller or NMS is not itself redundant. 583 7.4. Hybrid Method 585 For global restoration of service functions on a SFP, it is 586 worthwhile to explore a hybrid mode, i.e. when there are changes 587 involving using identical SFICs at different SFF nodes, the SC 588 Classifier node is informed to encode the explicit SFFs for each 589 SF in the SFC header of the data packets until all the involved 590 SFF nodes complete the installation of the new steering policy for 591 the path. 593 8. Regional Restoration of Service Function 595 It might not be always be feasible for the head end Service Chain 596 Classifier to be aware of the exact SFICs selected for a given SFP 597 due to too many SFICs for each SF, notifications not being 598 promptly sent to the classifier node, or other reasons. Then 599 Regional restoration should be considered. 601 This is not about multiple same-function SFICs attached to one SFF 602 node. Those SFICs can be handled by the SFF via local load balance 603 as described in SFC-Arch. 605 Regional restoration can take the similar approach as the Global 606 restoration: choosing a regional ingress node that can take over 607 the responsibility of installing the new steering policies to the 608 involved SFF nodes or network nodes. 610 The Regional ingress node should be: 612 - on the data path of the flow of the given service chain; 614 - in front of the relevant the SFF nodes or network nodes that 615 are impacted by the change of the Service Chain Path; 617 - capable of encoding the detailed Service Chain Path to the 618 Service Chain Header of data packets of the identified 619 flow; and 621 - capable of removing the detailed Service Chain Path encoding 622 in data packets after all the impacted SFF nodes and 623 network nodes completed the policy installation. 625 9. Conclusion and Recommendation 627 TBD 629 10. Manageability Considerations 631 TBD 633 11. Security Considerations 635 TBD 637 12. IANA Considerations 639 This document requires no IANA actions. RFC Editor: Please remove 640 this section before publication. 642 13. References 644 13.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 13.2. Informative References 651 [SFC-Problem] P. Quinn, et al, "Service Function Chaining Problem 652 statement", draft-ietf-sfc-problem-statement-02, work in 653 progress, April 2014 655 [NFV-Terminology] ETSI NFV ISG, "Network Functions Virtualisation 656 (NFV); Terminology for Main Concepts in NFV", ETSI GS 657 NFV 003 V1.1.1, Oct. 2013, 658 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.0 659 1.01_60/gs_NFV003v010101p.pdf 661 [SFC-Reduction] R. Parker, "Service Function Chaining: Chain to 662 Path Reduction", draft-parker-sfc-chain-to-path-00, work 663 in progress, Nov. 2013 665 [RSVP-TE] D. Awduche, Berger, L., Gan, D., Li, T., Srinivasan, V., 666 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 667 Tunnels", RFC 3209, December 2001. 669 [FRR] P. Pan, Swallow, G., and Atlas, A., "Fast Reroute 670 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 671 2005 673 14. Acknowledgments 675 Many thanks to Ron Bonica for the discussion in formulating the 676 content for the draft. 678 This document was prepared using 2-Word-v2.0.template.dot. 680 Authors' Addresses 682 Linda Dunbar 683 Huawei Technologies 684 5340 Legacy Drive, Suite 175 685 Plano, TX 75024, USA 686 Phone: (469) 277 5840 687 Email: ldunbar@huawei.com 689 Andrew G. Malis 690 Huawei Technologies 691 USA 692 Email: agmalis@gmail.com