[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]