idnits 2.17.1 draft-dai-sfc-fused-protocol-and-mechanism-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 12) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 61 instances of too long lines in the document, the longest one being 6 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 122 has weird spacing: '...rry out the f...' == Line 277 has weird spacing: '...lso has a...' == Line 364 has weird spacing: '... SPI of a mem...' == Line 432 has weird spacing: '...ain and avoid...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 08, 2021) is 953 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-sfc-arch-fused-sfc' is mentioned on line 190, but not defined == Missing Reference: 'RFC 8300' is mentioned on line 412, but not defined == Missing Reference: 'RFC 4110' is mentioned on line 440, but not defined == Missing Reference: 'RFC 4664' is mentioned on line 440, but not defined == Missing Reference: 'RFC 7365' is mentioned on line 475, but not defined == Missing Reference: 'RFC 8014' is mentioned on line 475, but not defined == Unused Reference: 'RFC4360' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC8459' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC4110' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC4664' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC7365' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC8014' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC8393' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-multi-layer-oam' is defined on line 608, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 4360 ** Downref: Normative reference to an Draft Standard RFC: RFC 4760 ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Proposed Standard RFC: RFC 8300 ** Downref: Normative reference to an Experimental RFC: RFC 8459 ** Downref: Normative reference to an Informational RFC: RFC 8924 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-07 Summary: 7 errors (**), 0 flaws (~~), 24 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dai 3 INTERNET-DRAFT CICT, PCL 4 Intended Status: standard X. Wang 5 Expires: March 08, 2022 D. Deng 6 X. Zhang 7 Fiberhome 9 September 08, 2021 11 Protocol extension and mechanism for fused service function chain 12 draft-dai-sfc-fused-protocol-and-mechanism-00 14 Abstract 16 This document discusses the protocol extension and procedure that are 17 used to implement the fused service function chain. Fused service 18 function chain means that two or more service function chains are fused 19 to become a single service function chain from the view of data plane 20 and control plane. Fused service function chain is a extension for 21 service function chain. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright (c) 2020 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 (http://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 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview of the Architecture of Fused Service Function Chain. . 3 62 3 Protocol Extention for Network Service Header . . . . . . . . 5 63 3.1. The original formation of Network Service Header . . . . . 5 64 3.2. Extension for NSH . . . . . . . . . . . . . . . . . . . . 6 65 3.3. SPI in NSH . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4 Additional Requirements for Fused Service Function Chain. . . . 7 67 4.1 Candidate solutions for information exchanging . . . . . . 7 68 4.2 Central controller based solution . . . . . . . . . . . 7 69 4.3 BGP based solution . . . . . . . . . . . . . . . . . . 8 70 5. Actions for SFC components. . . . . . . . . . . . . . . . . . 8 71 6. Transport layer envelopment for F-SFC . . . . . . . . . . . . 10 72 7. Some candidate mechanisms appropriate for fusing member SFCs . 10 73 7.1 Overview of fusing member SFCs . . . . . . . . . . . . . . 10 74 7.2 VPN . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.3 NVO3 . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Extension for management/control plane . . . . . . . . . . . . 12 77 9 Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12.1 Normative References . . . . . . . . . . . . . . . . . . 13 82 12.2 Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The delivery of end-to-end services often requires various service 88 functions. These include traditional network service functions such 89 as firewalls and traditional IP Network Address Translators (NATs), 90 as well as application-specific functions. The definition and 91 instantiation of an ordered set of service functions and subsequent 92 "steering" of traffic through them is termed Service Function 93 Chaining (SFC).[RFC7665]. [RFC7498] describes the motive for 94 service function chain. 96 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 . +--------------+ +------------------~~~ 98 . | Service | SFC | Service +---+ +---+ 99 . |Classification| Encapsulation | Function |sf1|...|sfn| 100 +---->| Function |+---------------->| Path +---+ +---+ 101 . +--------------+ +------------------~~~ 102 . SFC-enabled Domain 103 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Figure 1: Architecture of service function chain 107 There are many application scenarios that can use technologies or 108 methods related to service function chain (see RFC 7665). However, 109 some application scenarios have not yet been covered by RFC 7665. 110 For example, RFC 8459 illustrates an application scenario 111 corresponding to large, geographically dispersed network and SFC 112 for that application scenario is called Hierarchical service 113 function chain. 115 Hierarchical service function chain described in RFC 8459 is only 116 one of the application scenarios that have not been covered by 117 RFC 7665. Many other application scenarios that can be enhanced by 118 service function chain can't yet be covered by RFC 8459. I_D_fused- 119 architecture-and-scenario has illustrated some of the afore-mentioned. 120 application scenarios. 122 However, in order to carry out the fused service function chain, 123 extension for the relevant protocol and new methods or procedure are 124 necessary, and it is the target of this draft. 126 1.1 Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Overview of the Architecture of Fused Service Function Chain 134 As is described in clause 1, there is a need to fuse two or more 135 service fucntion chain to form a single service chain when service 136 function chain is applied in some application scenarios. the afore- 137 mentioned single service function chain is called fused service 138 function chain (F-SFC). The detailed description about arthitecture 139 for fused service function chain can be seen in [I-D.ietf-sfc-arch 140 -fused-sfc].The following is brief introdution for the afore-mentioned 141 architecture. 143 At first, a F-SFC is composed of two or more service function chains 144 that are logically independent each other and possibly seperate 145 physically. 147 Secondly, a F-SFC can be thought as a single service function chain 148 from the view of data plane and management plane. That is to say, 149 data packet can be steered through all selected SFs within the F-SFC 150 according to preset configuration. moreover, a F-SFC can be 151 managed by a management entity and the management entity can think 152 the F-SFC as an ordinary service function chain. 154 Thirdly, all service function chains within a F-SFC can still work 155 as an independent service function chain. In other words, if a F-SFC 156 consists of SFC A, SFC B and SFC C, SFCs with the F-SFC such as SFC 157 A can also be used as an independent if it is needed. 159 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 . +--------------+ +---------------------~~~ 161 . | Service | SFC | Service +----+ +----+ 162 . |Classification| Encapsulation| Function |sf11|...|sf1n| 163 +--->| Function |+------------>| Path +----+ +----+ 164 . +--------------+ +---------------------~~~ 165 . 166 . 168 . +--------------+ +---------------------~~~ 169 . | Service | SFC | Service +----+ +----+ 170 . |Classification| Encapsulation| Function |sf21|...|sf2m| 171 +--->| Function |+-----^------>| Path +----+ +----+ 172 |. +--------------+ | +---------------------~~~ 173 | Bypass | 174 +------------------------+ 175 +--->...... 176 . +--------------+ +---------------------~~~ 177 . | Service | SFC | Service +----+ +----+ 178 . |Classification| Encapsulation| Function |sfk1|...|sfkl| 179 +--->| Function |+-----^------>| Path +----+ +----+ 180 |. +--------------+ | +---------------------~~~ 181 | Bypass | 182 +------------------------+ 183 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Figure 2: General architecture for fused service function chain 186 Figure 2 describes a general architecture of F-SFC. From the figure, 187 it can be learned that the F-SFC is composed of SFC1, SFC2 ... and 188 SFCj. SFC1 consists SF11, SF12 ... and SF1n. SFC2 consists SF21, 189 SF22 ... and SF2m. ... SFCk consists SFk1, SFk2 ... and SFkl. This 190 figure can also be seen in [I-D.ietf-sfc-arch-fused-sfc]. 192 All SFs within SFC1, SFC2 ... and SFCj can be used by F-SFC. On the 193 one hand, SFs within SFC(i+1) should be used after SFs within SFC(i) 194 in order to keep the logical order of SFCs. On the other hand, SFs 195 within the same SFC should take action based on logical order of the 196 SFC. 198 It is noted that all CFs (Classification Function) in SFC2 ... SFCk 199 can be configurated to work in By-pass mode in order that SFC2 ... 200 SFCk can action based on the result of the CF in SFC1. It is sure all 201 CFs can also work in normal mode. 203 3 Protocol Extention for Network Service Header 205 3.1 The original formation of Network Service Header 207 [RFC 8300] specifies the detailed information of Network Service 208 Header (NSH). A typical NSH is composed of the following three parts: 210 Base Header: Provides information about the service header and the 211 payload protocol. 213 Service Path Header: Provides path identification and location 214 within a service path. 216 Context Header: Carries metadata (i.e., context data) along a 217 service path. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Service Path Identifier | Service Index | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 | Context Header | 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: structure for Network Service Header 232 Figure 2 describes the formation of the NSH. The first Row is used 233 to describe 'Base Header' meanwhie the second row is used to specify 234 'Service Path Header'. The third row is 'Context Header'. There five 235 bits marked 'U' in the Base Header of NSH are not defined in 236 [RFC 8300]. 238 3.2 Extension for NSH 240 At first, in order to carry out a fused service function chain, a 241 certain mechanism should be used to tell components within a SFC 242 whether the packet is bound to a common SFC or a fused SFC. 244 Because all inforamtion related to a SFC is enveloped in the NSH, 245 some modification should be taken on the NSH when it is needed to 246 classify packets of a Fused SFC from packets of a common SFC. 248 There are the following two solutions to implement the afore- 249 mentioned classification funciton: 251 .Using one of the five unused bits as the F-SFC bit, and the 252 bit is defined as follows: 254 0: the packet is related to a common SFC. 256 1: the packet is related to a fused SFC. 258 .Encoding 'Service Path Identifier'. 260 some numbers are used for F-SFC meanwhile other numbers are used to 261 represent common SFCs. For example, the packet is bound to a F-SFC 262 when the most significant bit of 'Service Path Identifier' is set, 263 and the other packets are related to a common SFC. 265 It is recommended that the first solution should be used to classify 266 the packets of a F-SFC from the packets of a common SFC. And the 267 third bit of the 'Base Header ' is recommended to be used. 269 3.3 SPI in NSH 271 When a packet related to a F-SFC is sent out from the classifier of 272 the first SFC that belongs to the F-SFC, a NSH will be inserted into 273 the packet and the SPI is related to the F-SFC rather than a common 274 SFC within the F-SFC. A common SFC in the F-SFC is called a member 275 SFC of the F-SFC. 277 On the other hand, every member SFC of the F-SFC also has a 278 corresonding SPI and the SPI of the member SFC is different from SPI 279 of the F-SFC. That will bring some problems to forwarding functions 280 of the SFC components. 282 Generally, within every member SFC of a F-SFC, the packet forwarding 283 action is based on SPI of the member SFC, though the NSH of the 284 forarded packet envelops the SPI of the F-SFC. 286 So, it is needed that some mechnism to be used to realize the 287 function to map from SPI of the F-SFC to SPI of the member SFC. The 288 mapping mechanism of SPI is specified in clause 4. 290 4 Mapping of SPI 292 4.1 Candidate solutions for information exchanging 294 If a functional component of SFC wants to map a SPI A to another SPI 295 B, it needs to know the SPI pairs(for example, A and B is a SPI pair) 296 in advance. Then, the functional component can map SPI A to SPI B or 297 map SPI B to SPI A. 299 There are two solutions for the functional component to get the 300 informaton of SPI pairs: 302 .Using one central controller to configurate the information about 303 SPI pairs. 305 .Exchange the information about SPI pairs among functional components 306 based on BGP. 308 4.2 Central controller based solution 310 When a central controller can exchange information with all functional 311 components of the SFC that needs the information about the SPI paiirs, 312 it is recommended to exchange information about SPI pairs based on the 313 central controller. 315 In this mode, the information of SPI pairs can be encoded with other 316 configuarion information and sent to those relevant functional 317 components. 319 Many management protocol or mechanism such as SNMP and Netconf can be 320 used to dispatch the configuration information. 322 4.3 BGP based solution 324 When there is not a proper central controller that can configurate the 325 SPI pairs to all functional components of the SFC that needs the 326 information about the SPI paiirs, it is better to use the BGP based 327 method to exchange information about SPI pairs. 329 This section specifies how to use BGP extensions to exchange SPI pairs 330 among functional components of the SFC. 332 One feasible solution is using 'BGP Extended Communities Attribute' 333 to envelop the inforamtion of SPI pairs. a new type of BGP extended 334 community called SPI-Pairs Extended Community. It is a transitive 335 extended community with type 0x01 and sub-type TBD. 337 The format of this extended community is shown in Figure 3. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type (0x01) |Sub-Type (TBD) | SPI of the F-SFC | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | SPI of the current member SFC | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | SPI of the neighbouring member SFC | Reserved | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3. SPI-Pairs Extended Community 351 5. Actions for SFC components 353 Because some changes occur to the protocol, the processing actions 354 of the functional components become different from the common SFC. 356 There are three aspects related to the afore-mentioned change of 357 actions that need to be executed by the functional components. 358 The following are those aspects. 360 . SPI mapping: two kinds of mapping are as follows: 362 . Mapping SPI of the F-SFC to SPI of a member SFC when a 363 F-SFC packet enter the member SFC.(A10) 364 . Mapping SPI of a member SFC to SPI of the F-SFC when a 365 F-SFC packet leave the member SFC and will enter another member 366 SFC.(A11). 368 . F-SFC bit processing: 370 . Clearing F-SFC bit when a F-SFC packet enter the member SFC. 371 (A20) 373 . Setting F-SFC bit when a F-SFC packet leave the member SFC 374 and will enter another member SFC.(A11).(A21) 376 . SI processing: 378 . Re-initiate SI when a F-SFC packet enter the member SFC.(A30) 380 . Restore and re-calculate SI when a F-SFC packet leave the 381 member SFC and will enter another member SFC.(A31) 383 . Decrementing the SI.(A32) 385 . Restore and re-calculate SI when a F-SFC packet leave the 386 member SFC and will enter another member SFC.(A31) 388 . Decrementing the SI.(A32) 390 Figure 4 illustrates the actions possibly executed by the functional 391 components of the member SFC. 393 +--------------------+----------------+-------------+---------------+ 394 |Component | SPI processing | F-SFC bit | SI processing | 395 | | | processing | | 396 +--------------------+----------------+-------------+---------------+ 397 |Classifier | A10 | A20 | A30 | 398 +--------------------+----------------+-------------+---------------+ 399 |Service Function | A10&A11 | A20&A21 | A30&A31 | 400 |Forwarder (SFF) | | | | 401 +--------------------+----------------+-------------+---------------+ 402 |Service Function | - | - | A32 | 403 | (SF) | | | | 404 +--------------------+----------------+-------------+---------------+ 405 | SFC Proxy | - | - | A30 | 406 +--------------------+----------------+-------------+---------------+ 408 Figure 4. Actions for SFC components related extended field for F-SFC 410 6. Transport layer envelopment for F-SFC 412 According to [RFC 8300], an outer transport encapsulation is used 413 to forward the packet with a NSH header. And the service header is 414 independent of the transport encapsulation used. 416 Because F-SFC is usually applied in cross-domain scenarios, the outer 417 transport layer envelopment should meet the requirement that the packet 418 with the outer transport layer envelopment can be exchange among the 419 domains in which the member SFCs are deployed. 421 7. Some candidate mechanisms appropriate for fusing member SFCs 423 7.1 Overview of fusing member SFCs 425 For F-SFC, it is a critical issue to steering the packet from one 426 member SFC to another member SFC. Because network traffic related 427 to F-SFC needs to be forwarded domain by domain, problems 428 including security will be brought about when network traffic is 429 transported from a domain to another domain. 431 Some mature technologies can help to steer network traffic domain by 432 domain and avoid possible problems. the next two sections will 433 introduce two candidate mechanisms that can be used for F-SFC. It is 434 noted that the other feasible methods are also proper for F-SFC. 436 7.2 VPN 438 VPN (Virtual Private Network ) is a good solution to connect different 439 member SFCs when member SFCs are set up in different network domains. 440 detailed information of VPN can be seen in [RFC 4110] and [RFC 4664]. 442 For example, L2 VPN can provide two fundamentally different kinds of 443 Layer 2 VPN service that a service provider could offer to a customer: 445 . Virtual Private Wire Service (VPWS). 447 . Virtual Private LAN Service (VPLS). 449 A VPWS is a VPN service that supplies an L2 point-to-point service. 450 Then A VPWS is appropriate for F-SFC. 452 Figure 5 illustrate the scene that two member SFCs are connected by a 453 VPN. 455 ............ ...................... ............... 456 . . . . . . 457 . +---+ +-------+ +----+ +-------+ +---+ +----+ . 458 . | | | | | | | |----|CF |-|SFF | . 459 . | | | | | | | | +---+ +----+ . 460 . +---+ |SFF|----| PE1 |--| P | -- | PE2 | : . 461 . | CF|..| | | | | | | | +---+ . 462 . +---+ | | | | | | | |----|SFF| . 463 . +---+ +-------+ +----+ +-------+ +---+ . 464 . Domain . . Service . . Domain . 465 . 1 . . provider(s) . . 2 . 466 ............ ..................... ................ 468 Figure 5. VPN connects two member SFCs 470 7.3 NVO3 472 Another example for mechanisms that can be used to connect two independent 473 member SFCs is NVO3. and Figure 6 illustartes such a scene. Detail 475 description about NVO3 can be seen in [RFC 7365] and [RFC 8014]. 477 ............ ................ ................ 478 . . . . . . 479 . . . . +---+ +---+ . 480 . +---+ +---+ . . |CF |-|SFF| . 481 . |CF |-| | +-+--+ . . +--+-+---+---+ +---+ . 482 . +---+ |SFF|--- | NVE|--. L3 Overlay .--| NVE| . . 483 . | | | | . . | | +---+ . 484 . +---+ +-+--+ . Network . +--+-+---|SFF| . 485 .Domain . . . +---+ Domain . 486 . 1 . . . . 2 . 487 ............ ................ ............... 489 Figure 6. NVO3 connects two member SFCs 491 8. Extension for management/control plane 493 Functional components in a F-SFC are possibly deployed in different 494 Domains, then multi-controllers are possibly needed, figure 7 495 depicts the logical structure for multi-controllers to cooperate in 496 F-SFC context. 498 There is possibly a need for information to be exchanged among the 499 controllers. It is a feasible solution to use BGP extensions to 500 realize the information exchange functions. 502 +----------+ +---------------+ +------------+ 503 | SFC | | Non SFC | | SFC | 504 |Controller|.........| Controller |........|Controller | 505 | 1 | | | | 2 | 506 +----------+ +---------------+ +------------+ 507 | | | 508 ............ ..................... ............... 509 . . . . . . 510 . +---+ . . +----+ +----+ . 511 . | | . . ----|CF |-|SFF | . 512 . | | . Non SFC . +---+ +----+ . 513 . +---+ |SFF|---- . . . . 514 . | CF|..| | . . +---+ . 515 . +---+ | | . Domain . ----|SFF| . 516 . +---+ . . +---+ . 517 . Domain . . . . Domain . 518 . 1 . . . . 2 . 519 ............ ..................... ............... 521 Figure 7. logical structure for multi-controllers in F-SFC 523 9. Security Considerations 525 The security considerations described throughout [RFC7665] and 526 [RFC8300] apply here as well. 528 Additionally, when a data packet is forwarded from SFC(i) to 529 SFC(i+1), the path between SFC(i) to SFC(i+1) should provide 530 mechanism to guarantee security of the data packet. 532 Moreever, when the CF in SFC(i) is by-passed, it should be assured 533 that the bu-passed path has the same security support as the CF. 535 10. IANA Considerations 537 The IANA is requested to make the assignments for SPI-Pairs 538 Extended Community: 540 +-------+-------------------------------------------+---------------+ 541 | Value | Description | Reference | 542 +-------+-------------------------------------------+---------------+ 543 | TBA1 | IPv4-Address-Specific IFIT Tail Community | This document | 544 +-------+-------------------------------------------+---------------+ 546 11 Acknowledgements 548 This document is written by referring to [RFC7665] authored by J. 549 Halpern and C, Pignataro and [RFC8924] authored by S. Aldrin, C. 550 Pignataro, N. Kumar, R. Krishnan and A. Ghanwani. 552 Many thanks to all the afore-mentioned editors and authors. 554 12 References 556 12.1 Normative References 558 [RFC4360] S. Sangli, D. Tappan and Y. Rekhter, "BGP 559 Extended Communities Attribute", RFC 4360, February 2006. 561 [RFC4760] T. Bates, R. Chandra, D. Katz and Y. Rekhter, 562 "Multiprotocol Extensions for BGP-4 ", RFC 4760, Jenuary 563 2007. 565 [RFC7665] J. Halpern and C. Pignataro, "Service 566 Function Chaining (SFC) Architecture", RFC 7665, October 567 2015. 569 [RFC8300] P. Quinn, U. Elzur and C. Pignataro, "Network 570 Service Header (NSH)", RFC 8300, January 2018. 572 [RFC8459] D. Dolson, S. Homma, D. Lopez and M. Boucadair 573 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 574 September 2018. 576 [RFC8924] S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan 577 and A. Ghanwani, "Service Function Chaining (SFC) 578 Operations, Administration, and Maintenance (OAM) 579 Framework", RFC 8924, October 2020. 581 12.2 Informative References 583 [RFC2119] S. Bradner, "Key words for use in RFCs to 584 Indicate Requirement Levels", RFC 2119, March 1997. 586 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 587 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 588 4110, July 2005. 590 [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 591 Virtual Private Networks (L2VPNs) ", RFC 4664, September 2006. 593 [RFC7365] M. Lasserre, T. Morin, N. Bitar and Y. Rekhter, 594 "Framework for Data Center (DC) Network Virtualization ", 595 RFC 7365, October 2014. 597 [RFC7498] P. Quinn and T. Nadeau, "Problem Statement for 598 Service Function Chaining", RFC 7468, April 2015. 600 [RFC8014] D. Black, J. Hudson, L. Kreeger, M. Lasserre and 601 T. Narten, "An Architecture for Data-Center Network 602 Virtualization over Layer 3 (NVO3) ", RFC 8014, December 2016. 604 [RFC8393] A. Farrel and J. Drake, "Operating the Network 605 Service Header (NSH) with Next Protocol 'None'", RFC 8393, 606 May 2018. 608 [I-D.ietf-sfc-multi-layer-oam] G. Mirsky, W. Meng, B. 609 Khasnabish and C. Wang, "Active OAM for Service Function 610 Chains in Networks", draft-ietf-sfc-multi-layer-oam-07, 611 December 2020. 613 Authors' Addresses 615 Jinyou Dai 616 China Information Communication Technologies Group.,PCL. 617 Gaoxin 4th Road 6# 618 Wuhan, Hubei 430079 619 China 621 Email: djy@fiberhome.com 623 Xueshun Wang 624 China Information Communication Technologies Group. 625 Gaoxin 4th Road 6# 626 Wuhan, Hubei 430079 627 China 629 Email: xswang@fiberhome.com 631 Dongping Deng 632 China Information Communication Technologies Group. 633 Gaoxin 4th Road 6# 634 Wuhan, Hubei 430079 635 China 637 Email: dzb@fiberhome.com 639 Xiaoyun Zhang 640 China Information Communication Technologies Group. 641 Gaoxin 4th Road 6# 642 Wuhan, Hubei 430079 643 China 645 Email: Zhangxy@fiberhome.com