Protocol extension and mechanism for fused service function chain
draft-dai-sfc-fused-protocol-and-mechanism-00

Document Type Active Internet-Draft (individual)
Authors Jinyou Dai  , Xueshun Wang  , Dongping Deng  , Xiaoyun Zhang 
Last updated 2021-09-08
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                             J. Dai
INTERNET-DRAFT                                                   CICT, PCL
Intended Status: standard                                        X. Wang 
Expires:  March 08, 2022                                       D. Deng
                                                                 X. Zhang
                                                               Fiberhome                  
                                                        
                                                            September 08, 2021

 Protocol extension and mechanism for fused service function chain 
            draft-dai-sfc-fused-protocol-and-mechanism-00

    
Abstract

   This document discusses the protocol extension and procedure that are  
   used to implement the fused service function chain. Fused service 
   function chain means that two or more service function chains are fused 
   to become a single service function chain from the view of data plane 
   and control plane. Fused service function chain is a extension for 
   service function chain.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors. All rights reserved.

  
Dai, et al.              Expires March 08, 2022                 [Page 1]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with 
   respect to this document. Code Components extracted from this 
   document must include Simplified BSD License text as described in 
   Section 4.e of the Trust Legal Provisions and are provided without 
   warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Overview of the Architecture of Fused Service Function Chain. .  3
   3  Protocol Extention for Network Service Header   . . . . . . . .  5
     3.1. The original formation of Network Service Header  . . . . .  5
     3.2. Extension for NSH   . . . . . . . . . . . . . . . . . . . .  6
     3.3. SPI in NSH . . . . . . .  . . . . . . . . . . . . . . . . .  6
   4  Additional Requirements for Fused Service Function Chain. . . .  7
     4.1 Candidate solutions for information exchanging . . .  . . .   7
     4.2 Central controller based solution   .  . . . . . . .  . . .   7
     4.3 BGP based solution    . . . . . .  . . .  . . . . . . . . .   8
   5. Actions for SFC components. . . . . . . . . . . . . . . . . .    8
   6. Transport layer envelopment for F-SFC . . . . . . . . . . . .   10
   7. Some candidate mechanisms appropriate for fusing member SFCs .  10
     7.1 Overview of fusing member SFCs . . .  . . . . . . . . . . .  10
     7.2 VPN       .  . . . . . . .  . . . . . . . . . . . . . . . .  10
     7.3 NVO3      . . . . . .  . . .  . . . . . . . . . . . . . . .  11
   8. Extension for management/control plane . . . . . . . . . . . .  12
   9  Security Considerations  . . . . . . . . . . . . . . . . . . .  12
   10  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   11  Acknowledgements   . . . . . . . . . . . . . . . . . . . . . . 13
   12  References   . . . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1  Normative References   . . . . . . . . . . . . . . . . . . 13
     12.2  Informative References   . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

1.  Introduction

   The delivery of end-to-end services often requires various service
   functions.  These include traditional network service functions such
   as firewalls and traditional IP Network Address Translators (NATs),

Dai, et al.              Expires March 08, 2022                 [Page 2]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   as well as application-specific functions.  The definition and
   instantiation of an ordered set of service functions and subsequent
   "steering" of traffic through them is termed Service Function
   Chaining (SFC).[RFC7665]. [RFC7498] describes the motive for 
   service function chain. 
   
    o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .  +--------------+                  +------------------~~~
      .  |   Service    |       SFC        |  Service  +---+   +---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +---+   +---+
      .  +--------------+                  +------------------~~~
      . SFC-enabled Domain
    o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
   
        Figure 1: Architecture of service function chain
   
   There are many application scenarios that can use technologies or 
   methods related to service function chain (see RFC 7665). However, 
   some application scenarios have not yet been covered by RFC 7665. 
   For example, RFC 8459 illustrates an application scenario 
   corresponding to large, geographically dispersed network and SFC 
   for that application scenario is called Hierarchical service 
   function chain.

   Hierarchical service function chain described in RFC 8459 is only 
   one of the application scenarios that have not been covered by 
   RFC 7665. Many other application scenarios that can be enhanced by
   service function chain can't yet be covered by RFC 8459. I_D_fused-
   architecture-and-scenario has illustrated some of the afore-mentioned. 
   application scenarios.

   However, in order to carry out  the fused service function chain, 
   extension for the relevant protocol and new methods or procedure are 
   necessary, and it is the target of this draft.    

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Overview of the Architecture of Fused Service Function Chain

   As is described in clause 1, there is a need to fuse two or more 
   service fucntion chain to form a single service chain when service
  

Dai, et al.              Expires March 08, 2022                 [Page 3]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

 
   function chain is applied in some application scenarios. the afore-
   mentioned single service function chain is called fused service   
   function chain (F-SFC). The detailed description about arthitecture 
   for fused service function chain can be seen in [I-D.ietf-sfc-arch
   -fused-sfc].The following is brief introdution for the afore-mentioned
   architecture.

   At first, a F-SFC is composed of two or more service function chains  
   that are logically independent each other and possibly seperate 
   physically. 
       
   Secondly, a F-SFC can be thought as a single service function chain
   from the view of data plane and management plane. That is to say, 
   data packet can be steered through all selected SFs within the F-SFC 
   according to preset configuration. moreover, a F-SFC can be 
   managed by a management entity and the management entity can think 
   the F-SFC as an ordinary service function chain. 

   Thirdly, all service function chains within a F-SFC can still work 
   as an independent service function chain. In other words, if a F-SFC   
   consists of SFC A, SFC B and SFC C, SFCs with the F-SFC such as SFC  
   A can also be used as an independent if it is needed. 

      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
      . +--------------+              +---------------------~~~
      . |   Service    |    SFC       |  Service   +----+    +----+
      . |Classification| Encapsulation| Function  |sf11|...|sf1n|
   +--->|   Function   |+------------>|   Path     +----+    +----+
      . +--------------+              +---------------------~~~
      . 
      .

      . +--------------+                +---------------------~~~
      . |   Service    |    SFC          |  Service  +----+   +----+
      . |Classification| Encapsulation| Function  |sf21|...|sf2m|
   +--->|   Function   |+-----^------>|   Path    +----+   +----+
     |. +--------------+      |         +---------------------~~~
     |      Bypass            |
     +------------------------+
   +--->......
      . +--------------+                +---------------------~~~
      . |   Service    |    SFC          |  Service   +----+   +----+
      . |Classification| Encapsulation| Function  |sfk1|...|sfkl|
   +--->|   Function   |+-----^------>|   Path      +----+   +----+
     |. +--------------+      |         +---------------------~~~
     |      Bypass            |
     +------------------------+
      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

   Figure 2: General architecture for fused service function chain

Dai, et al.              Expires March 08, 2022                 [Page 4]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   Figure 2 describes a general architecture of F-SFC. From the figure,   
   it can be learned that the F-SFC is composed of SFC1, SFC2 ... and 
   SFCj. SFC1 consists SF11, SF12 ... and SF1n. SFC2 consists SF21, 
   SF22 ... and SF2m. ... SFCk consists SFk1, SFk2 ... and SFkl. This
   figure can also be seen in  [I-D.ietf-sfc-arch-fused-sfc].

   All SFs within SFC1, SFC2 ... and SFCj can be used by F-SFC. On the 
   one hand, SFs within SFC(i+1) should be used after SFs within SFC(i) 
   in order to keep the logical order of SFCs. On the other hand, SFs 
   within the same SFC should take action based on logical order of the 
   SFC.  

   It is noted that all CFs (Classification Function) in SFC2 ... SFCk 
   can be configurated to work in By-pass mode in order that SFC2 ...  
   SFCk can action based on the result of the CF in SFC1. It is sure all
   CFs can also work in normal mode.        

   3  Protocol Extention for Network Service Header
   
   3.1 The original formation of Network Service Header

   [RFC 8300] specifies the detailed information of Network Service 
   Header (NSH). A typical NSH is composed of the following three parts:

    Base Header:  Provides information about the service header and the
      payload protocol.

    Service Path Header:  Provides path identification and location
      within a service path.

    Context Header:  Carries metadata (i.e., context data) along a
      service path.
 

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Service Path Identifier              | Service Index |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Context Header                        |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 2: structure for Network Service Header

Dai, et al.              Expires March 08, 2022                 [Page 5]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   
   Figure 2 describes the formation of the NSH. The first Row is used
   to describe 'Base Header' meanwhie the second row is used to specify
   'Service Path Header'. The third row is 'Context Header'. There five 
   bits marked 'U' in the Base Header of NSH are not defined in 
   [RFC 8300]. 
     

   3.2 Extension for NSH
   
   At first, in order to carry out a fused service function chain, a 
   certain mechanism should be used to tell components within a SFC 
   whether the packet is bound to a common SFC or a fused SFC.
              
   Because all inforamtion related to a SFC is enveloped in the NSH, 
   some modification should be taken on the NSH when it is needed to 
   classify packets of a Fused SFC from packets of a common SFC. 

   There are the following two solutions to implement the afore-
   mentioned classification funciton:
  
       .Using one of the five unused bits as the F-SFC bit, and the 
   bit is defined as follows:
              
               0: the packet is related to a common SFC.

               1: the packet is related to a fused SFC.

       .Encoding 'Service Path Identifier'.
 
  some numbers are used for F-SFC meanwhile other numbers are used to 
  represent common SFCs.  For example, the packet is bound to a F-SFC  
  when the most significant bit of 'Service Path Identifier' is set, 
  and the other packets are related to a common SFC. 

  It is recommended that the first solution should be used to classify
  the packets of a F-SFC from the packets of a common SFC. And the 
  third bit of the 'Base Header ' is recommended to be used. 

  3.3  SPI in NSH
  
   When a packet related to a F-SFC is sent out from the classifier of 
   the first SFC that belongs to the F-SFC, a NSH will be inserted into
   the packet and the SPI is related to the F-SFC rather than a common 
   SFC within the F-SFC. A common SFC in the F-SFC is called a member 
   SFC of the F-SFC. 

              
Dai, et al.              Expires March 08, 2022                 [Page 6]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   

   On the other hand, every member SFC of the F-SFC also has  a    
   corresonding SPI and the SPI of the member SFC is different from SPI 
   of the F-SFC. That will bring some problems to forwarding functions 
   of the SFC components.

   Generally, within every member SFC of a F-SFC, the packet forwarding
   action is based on SPI of the member SFC, though the NSH of the 
   forarded packet envelops the SPI of the F-SFC.

   So, it is needed that some mechnism to be used to realize the 
   function to map from SPI of the F-SFC to SPI of the member SFC. The 
   mapping mechanism of SPI is specified in clause 4.

4  Mapping of SPI

   4.1 Candidate solutions for information exchanging

   If a functional component of SFC wants to map a SPI A to another SPI
   B, it needs to know the SPI pairs(for example, A and B is a SPI pair)
   in advance. Then, the functional component can map SPI A to SPI B or
   map SPI B to SPI A.
  
   There are two solutions for the functional component to get the 
   informaton of SPI pairs:
    
   .Using one central controller to configurate the information about 
   SPI pairs.
              
   .Exchange the information about SPI pairs among functional components
   based on BGP. 

  
   4.2 Central controller based solution
 
   When a central controller can exchange information with all functional 
   components of the SFC that needs the information about the SPI paiirs,
   it is recommended to exchange information about SPI pairs based on the
   central controller.

   In this mode, the information of SPI pairs can be encoded with other 
   configuarion information and sent to those relevant functional 
   components.

Dai, et al.              Expires March 08, 2022                [Page 7]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   Many management protocol or mechanism such as SNMP and Netconf can be
   used to dispatch the configuration information.   

   4.3 BGP based solution

   When there is not a proper central controller that can configurate the
   SPI pairs to all functional components of the SFC that needs the 
   information about the SPI paiirs, it is better to use the BGP based 
   method to exchange information about SPI pairs.
  
   This section specifies how to use BGP extensions to exchange SPI pairs
   among functional components of the SFC.
 
   One feasible solution is using 'BGP Extended Communities Attribute' 
   to envelop the inforamtion of SPI pairs. a new type of BGP extended
   community called SPI-Pairs Extended Community. It is a transitive 
   extended community with type 0x01 and sub-type TBD.

   The format of this extended community is shown in Figure 3.
  

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (0x01)  |Sub-Type (TBD) |      SPI of the F-SFC         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |     SPI of the current member SFC             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        SPI of the neighbouring member SFC     |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3. SPI-Pairs Extended Community    

5.  Actions for SFC components

    Because some changes occur to the protocol, the processing actions 
    of the functional components become different from the common SFC.

    There are three aspects related to the afore-mentioned change of 
    actions that need to be executed by the functional components. 
    The following are those aspects.

       . SPI mapping: two kinds of mapping are as follows:
   
          . Mapping SPI of the F-SFC to SPI of a member SFC when a 
    F-SFC packet enter the member SFC.(A10)
    
               

Dai, et al.              Expires March 08, 2022                [Page 8]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   
          . Mapping SPI of  a member SFC to SPI of the F-SFC when a 
    F-SFC packet leave the member SFC and will enter another member 
    SFC.(A11). 
             
       . F-SFC bit processing:

          . Clearing F-SFC bit when a F-SFC packet enter the member SFC.
    (A20)
   
          . Setting F-SFC bit when a F-SFC packet leave the member SFC 
    and will enter another member SFC.(A11).(A21)

       . SI processing:

          . Re-initiate SI when a F-SFC packet enter the member SFC.(A30)
   
          . Restore and re-calculate SI when a F-SFC packet leave the 
    member SFC and will enter another member SFC.(A31) 

          . Decrementing the SI.(A32) 

        . Restore and re-calculate SI when a F-SFC packet leave the 
    member SFC and will enter another member SFC.(A31) 

          . Decrementing the SI.(A32) 

    Figure 4 illustrates the actions possibly executed by the functional 
    components of the member SFC.
    
    +--------------------+----------------+-------------+---------------+
    |Component           | SPI processing |  F-SFC bit  | SI processing |
    |                    |                |  processing |               |
    +--------------------+----------------+-------------+---------------+
    |Classifier          |        A10     |     A20     |      A30      |    
    +--------------------+----------------+-------------+---------------+
    |Service  Function   |      A10&A11   |   A20&A21   |    A30&A31    |   
    |Forwarder (SFF)     |                |             |               |  
    +--------------------+----------------+-------------+---------------+
    |Service   Function  |         -      |       -     |      A32      |   
    |    (SF)            |                |             |               |    
    +--------------------+----------------+-------------+---------------+
    | SFC Proxy          |         -      |       -     |       A30     |       
    +--------------------+----------------+-------------+---------------+

     Figure 4. Actions for SFC components related extended field for F-SFC   

Dai, et al.              Expires March 08, 2022                [Page 9]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

6. Transport layer envelopment for F-SFC

   According to [RFC 8300], an outer transport encapsulation is used
   to forward the packet with a NSH header. And the service header is 
   independent of the transport encapsulation used.

   Because F-SFC is usually applied in cross-domain scenarios, the outer 
   transport layer envelopment should meet the requirement that the packet 
   with the outer transport layer envelopment can be exchange among the 
   domains in which the member SFCs are deployed. 
   

7. Some candidate mechanisms appropriate for fusing member SFCs  

   7.1 Overview of fusing member SFCs
   
   For F-SFC, it is a critical issue to steering the packet from one 
   member SFC to another member SFC. Because network traffic related
   to F-SFC needs to be forwarded domain by domain, problems 
   including security will be brought about when network traffic is 
   transported from a domain to another domain.

   Some mature technologies can help to steer network traffic domain by 
   domain and  avoid possible problems. the next two sections will 
   introduce two candidate mechanisms that can be used for F-SFC. It is
   noted that the other feasible methods are also proper for F-SFC.

  
   7.2 VPN
   
   VPN (Virtual Private Network ) is a good solution to connect different
   member SFCs when member SFCs are set up in different network domains.
   detailed information of VPN can be seen in [RFC 4110] and [RFC 4664].  

   For example, L2 VPN can provide two fundamentally different kinds of 
   Layer 2 VPN service that a service provider could offer to a customer:

     . Virtual Private Wire Service (VPWS).
     
     . Virtual Private LAN Service (VPLS).

   
   A VPWS is a VPN service that supplies an L2 point-to-point service.
   Then A VPWS is appropriate for F-SFC.

Dai, et al.              Expires March 08, 2022                [Page 10]

 
INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

     

   
   Figure 5 illustrate the scene that two member SFCs are connected by a 
   VPN.
 
     ............          ......................          ...............
     .          .          .                    .          .             .
     .        +---+    +-------+  +----+     +-------+    +---+ +----+   .
     .        |   |    |       |  |    |     |       |----|CF |-|SFF |   .
     .        |   |    |       |  |    |     |       |    +---+ +----+   .
     . +---+  |SFF|----|  PE1  |--| P  | --  |  PE2  |      :            .
     . | CF|..|   |    |       |  |    |     |       |    +---+          .
     . +---+  |   |    |       |  |    |     |       |----|SFF|          .
     .        +---+    +-------+  +----+     +-------+    +---+          .
     . Domain   .          .      Service      .          . Domain       .
     .    1     .          .    provider(s)    .          .   2          .
     ............          .....................          ................

                Figure 5. VPN connects two member SFCs
   
   7.3 NVO3

   Another example for mechanisms that can be used to connect two independent
   member SFCs is NVO3. and Figure 6 illustartes such a scene. Detail 

   description about NVO3 can be seen in [RFC 7365] and [RFC 8014].

     ............              ................            ................ 
     .          .              .              .            .              .  
     .          .              .              .           +---+ +---+     .
     .  +---+ +---+            .              .           |CF |-|SFF|     .
     .  |CF |-|   |    +-+--+  .              .  +--+-+---+---+ +---+     .
     .  +---+ |SFF|--- | NVE|--.  L3 Overlay  .--| NVE|    .              .
     .        |   |    |    |  .              .  |    |   +---+           .
     .        +---+    +-+--+  .    Network   .  +--+-+---|SFF|           . 
     .Domain    .              .              .           +---+ Domain    .
     .  1       .              .              .             .   2         .  
     ............              ................             ...............

                 Figure 6. NVO3 connects two member SFCs

   

Dai, et al.              Expires March 08, 2022                [Page 11]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

8.  Extension for management/control plane
   
   Functional components in a F-SFC are possibly deployed in different
   Domains, then multi-controllers are possibly needed, figure 7 
   depicts the logical structure for multi-controllers to cooperate in
   F-SFC context.
  
   There is possibly a need for information to be exchanged among the 
   controllers. It is a feasible solution to use BGP extensions to 
   realize the information exchange functions.

      +----------+         +---------------+        +------------+ 
      |   SFC    |         |   Non  SFC    |        |    SFC     |                 
      |Controller|.........|   Controller  |........|Controller  |     
      |    1     |         |               |        |     2      |
      +----------+         +---------------+        +------------+
           |                      |                       |
      ............       .....................      ...............
      .          .       .                   .      .             .
      .        +---+     .                   .      +----+ +----+ .
      .        |   |     .                   .  ----|CF  |-|SFF | .
      .        |   |     .     Non SFC       .      +---+  +----+ .
      . +---+  |SFF|---- .                   .      .             .
      . | CF|..|   |     .                   .      +---+         .
      . +---+  |   |     .     Domain        .  ----|SFF|         .
      .        +---+     .                   .      +---+         .
      . Domain   .       .                   .      . Domain      .
      .    1     .       .                   .      .   2         .
      ............       .....................      ...............

       Figure 7. logical structure for multi-controllers in F-SFC

9.  Security Considerations

   The security considerations described throughout [RFC7665] and  
   [RFC8300] apply here as well.

   Additionally, when a data packet is forwarded from SFC(i) to 
   SFC(i+1), the path between SFC(i) to SFC(i+1) should provide 
   mechanism to guarantee security of the data packet.
   
   Moreever, when the CF in SFC(i) is by-passed, it should be assured 
   that the bu-passed path has the same security support as the CF.

10.  IANA Considerations

      The IANA is requested to make the assignments for SPI-Pairs 
   Extended Community:

Dai, et al.              Expires March 08, 2022                [Page 12]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

 
   +-------+-------------------------------------------+---------------+
   | Value | Description                               | Reference     |
   +-------+-------------------------------------------+---------------+
   | TBA1  | IPv4-Address-Specific IFIT Tail Community | This document |
   +-------+-------------------------------------------+---------------+

11  Acknowledgements

   This document is written by referring to [RFC7665] authored by J. 
   Halpern and C, Pignataro and [RFC8924] authored by S. Aldrin, C. 
   Pignataro, N. Kumar, R. Krishnan and A. Ghanwani. 

   Many thanks to all the afore-mentioned editors and authors.

12  References

   12.1  Normative References
              
              [RFC4360]   S. Sangli, D. Tappan and  Y. Rekhter, "BGP
              Extended Communities Attribute", RFC 4360, February 2006.

              [RFC4760]   T. Bates, R. Chandra, D. Katz and  Y. Rekhter, 
              "Multiprotocol Extensions for BGP-4 ", RFC 4760, Jenuary
              2007.

              [RFC7665]   J. Halpern and  C. Pignataro, "Service 
              Function Chaining (SFC) Architecture", RFC 7665, October
              2015.

              [RFC8300]  P. Quinn, U. Elzur and C. Pignataro, "Network
              Service Header (NSH)",   RFC 8300, January 2018.

              [RFC8459]  D. Dolson, S. Homma, D. Lopez and M. Boucadair 
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 
              September 2018.

              [RFC8924]  S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan
              and A. Ghanwani, "Service Function Chaining (SFC) 
              Operations, Administration, and Maintenance (OAM) 
              Framework", RFC 8924, October 2020.          

   12.2  Informative References

              [RFC2119]  S. Bradner, "Key words for use in RFCs to 
              Indicate Requirement Levels", RFC 2119, March 1997.

Dai, et al.              Expires March 08, 2022                [Page 13]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

         

              [RFC4110]  R. Callon and M. Suzuki, "A Framework for Layer 3
              Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC
              4110, July 2005.

              [RFC4664]  L. Andersson and E. Rosen, "Framework for Layer 2 
              Virtual Private Networks (L2VPNs) ", RFC 4664, September 2006.              

              [RFC7365]  M. Lasserre, T. Morin, N. Bitar and  Y. Rekhter, 
              "Framework for Data Center (DC) Network Virtualization ", 
              RFC 7365, October 2014.   
 
              [RFC7498]  P. Quinn and T. Nadeau, "Problem Statement for 
              Service Function Chaining", RFC 7468, April 2015.

              [RFC8014]  D. Black, J. Hudson, L. Kreeger, M. Lasserre and  
              T. Narten, "An Architecture for Data-Center Network 
              Virtualization over Layer 3 (NVO3) ", RFC 8014, December 2016.          

              [RFC8393]  A. Farrel and J. Drake, "Operating the Network 
              Service Header (NSH) with Next Protocol 'None'", RFC 8393, 
              May 2018.

              [I-D.ietf-sfc-multi-layer-oam]      G. Mirsky, W. Meng, B. 
              Khasnabish and C. Wang, "Active OAM for Service Function 
              Chains in Networks", draft-ietf-sfc-multi-layer-oam-07, 
              December 2020.

Authors' Addresses

   Jinyou Dai
      China Information Communication Technologies Group.,PCL.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China

      Email: djy@fiberhome.com

   Xueshun Wang
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China

      Email: xswang@fiberhome.com

 

Dai, et al.              Expires March 08, 2022                [Page 14]

INTERNET DRAFT     Protocol extension for fused SFC   September 08, 2021

   Dongping Deng
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China
 
      Email: dzb@fiberhome.com

   Xiaoyun Zhang
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China
 
      Email: Zhangxy@fiberhome.com

Dai, et al.              Expires March 08, 2022                [Page 15]