[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

MPLS Working Group                                                Y. Liu
Internet-Draft                                                 G. Mirsky
Intended status: Standards Track                         ZTE Corporation
Expires: April 28, 2021                                 October 25, 2020


     MPLS-based Service Function Path(SFP) Consistency Verification
                 draft-lm-mpls-sfc-path-verification-01

Abstract

   This document proposes a method to verify the correlation between
   Service Function Chaining control and/or management plane view of the
   specified Service Function Path and the state of its data.  It works
   for both SR service programming and MPLS-based NSH SFC.

   This document defines the signaling of the Generic Associated Channel
   (G-ACh) over a Service Function Path (SFP) with an MPLS forwarding
   plane using the basic unit defined in RFC 8595.  The document also
   describes the processing of the G-ACh by the elements of the SFP.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 28, 2021.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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



Liu & Mirsky             Expires April 28, 2021                 [Page 1]


Internet-Draft              LSP Ping for SFC                October 2020


   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
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MPLS-based SFP Consistency Verification . . . . . . . . . . .   4
     3.1.  Special-purpose Label in SFC-MPLS Environment . . . . . .   5
       3.1.1.  G-ACh over SFC-MPLS . . . . . . . . . . . . . . . . .   6
     3.2.  MPLS-based SFP Consistency Verification . . . . . . . . .   6
     3.3.  SFC Info Sub-TLV  . . . . . . . . . . . . . . . . . . . .   7
     3.4.  SFC Basic Unit FEC Sub-TLV  . . . . . . . . . . . . . . .   8
     3.5.  Theory of Operation . . . . . . . . . . . . . . . . . . .   9
       3.5.1.  MPLS-based service programming  . . . . . . . . . . .  10
       3.5.2.  Path Consistency in SFC-MPLS  . . . . . . . . . . . .  10
     3.6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  SFC Validation TLV  . . . . . . . . . . . . . . . . . . .  11
       5.1.1.  Sub-TLVs for SFC Validation TLV . . . . . . . . . . .  11
     5.2.  SFC Basic Unit sub-TLV  . . . . . . . . . . . . . . . . .  12
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Service Function Chain (SFC) defined in [RFC7665] as an ordered set
   of service functions (SFs) to be applied to packets and/or frames,
   and/or flows selected as a result of classification.

   SFC can be achieved through a variety of encapsulation methods, such
   as NSH [RFC8300], SR service programming
   [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH SFC
   [RFC8595].

   This document describes extensions to MPLS LSP ping [RFC8029]
   mechanisms to support verification between the control/management
   plane and the data plane state for both SR-MPLS service programming
   and MPLS-based NSH SFC.





Liu & Mirsky             Expires April 28, 2021                 [Page 2]


Internet-Draft              LSP Ping for SFC                October 2020


   An MPLS LSP ping is a component of the MPLS Operation,
   Administration, and Maintenance (OAM) toolset.  OAM packets used to
   monitor a specific Service Function Path (SFP) can be transported
   over a Generic Associated Channel (G-ACh).  This document defines the
   signaling of the G-ACh over an SFP with an MPLS forwarding plane
   using the basic unit defined in [RFC8595].  The document also
   describes the processing of the G-ACh by the elements of the SFP.

2.  Conventions used in this document

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Acronyms

   SFC: Service Function Chain

   SFF: Service Function Forwarder

   SF: Service Function

   SFI: Instance of an SF

   SFP: Service Function Path

   RSP: Rendered Service Path

   SFC-MPLS: SFC over an MPLS forwarding plane

   SPL: Special-Purpose Label

   bSPL: Base SPL

   eSPL: Extended SPL

   GAL: Generic Associated Channel Label

   ELI: Entropy Label Indicator

   OAM: Operation, Administration, and Maintenance

   G-ACh: Generic Associated Channel




Liu & Mirsky             Expires April 28, 2021                 [Page 3]


Internet-Draft              LSP Ping for SFC                October 2020


   GAL: Generic Associated Channel Label

3.  MPLS-based SFP Consistency Verification

   MPLS echo request and reply messages [RFC8029] can be extended to
   support the verification of the consistency of an MPLS-based Service
   Function Path (SFP).

   SR-MPLS/MPLS can be used to realize an SFP.  Two methods have been
   defined:

   o  [I-D.ietf-spring-sr-service-programming] describes how to achieve
      service function chaining in SR-enabled MPLS and IPv6 networks.
      In an SR-MPLS network, each SF is associated with an MPLS label.
      As a result, an SFP can be encoded as a stack of MPLS labels and
      pushed on top of the packet.

   o  [RFC8595] provides another method to realize SFC in an MPLS
      network by means of using a logical representation of the Network
      Service Header (NSH) in an MPLS label stack.  This method,
      throughout this document, is referred to as SFC over an MPLS data
      plane (SFC-MPLS).  When an MPLS label stack is used to carry a
      logical NSH, a basic unit of representation is used, which can be
      present one or more times in the label stack.  This unit comprises
      two MPLS labels, one carries a label to provide a context within
      the SFC scope (the SFC Context Label), and the other carries a
      label to show which SF is to be enacted (the SF Label).  This two-
      label unit is shown in Figure 1.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SFC Context Label           | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SF Label                    | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 1: The Basic Unit of MPLS Label Stack for SFC

   In MPLS Label Switched Paths (LSPs), MPLS LSP ping [RFC8029] is used
   to check the correctness of the data plane functioning and to verify
   the data plane against the control plane.

   The proposed extension of MPLS LSP ping allows verification of the
   correlation between the control/management (if data model-based




Liu & Mirsky             Expires April 28, 2021                 [Page 4]


Internet-Draft              LSP Ping for SFC                October 2020


   central controller used) plane and the data plane state in SR-MPLS/
   MPLS-based SFC.

   Generally, except for the designed specific functions, the packet
   processing functions supported by SFs are limited.  SFs may not
   support control and/or management protocols operated over the G-ACh
   defined n [RFC5586], e.g., MPLS OAM protocols like LSP ping.  To
   avoid such packets mishandled, SFFs are responsible for MPLS echo
   request processing.  To support that processing, the basic unit can
   use the mechanism described in Section 3.1.

3.1.  Special-purpose Label in SFC-MPLS Environment

   When an SFC-MPLS is used, an SFF needs to identify an OAM packet with
   the SFP scope.  To achieve that, this specification first defines the
   use of a base special-purpose label (bSPL) [RFC3032] or an extended
   special-purpose label (eSPL) [RFC7274] (referred in this document as
   SPL Unit) with the basic unit defined in [RFC8595].  And based on
   that, the use of Generic Associated Channel Label (GAL) [RFC5586]
   with the basic unit in the SFC-MPLS environment.

   Special-purpose label (SPL), whether bSPL or eSPL, have special
   significance in the data and control planes.  An ability to use an
   SPL in the basic unit allows for a closer functional match between
   the NSH-based SFC and SFC-MPLS.  For example, Entropy Label Indicator
   (ELI) [RFC6790] with the basic unit can be used as the Flow ID TLV
   [I-D.ietf-sfc-nsh-tlv] to allow an SFF to balance SFC flows among SFs
   of the same type.  An SPL MAY be used with the basic unit in SFC-
   MPLS, as displayed in Figure 2.  Note that an SPL unit MAY be present
   in one or more basic units when MPLS label stacking is used to carry
   the SFC information.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SFC Context Label           | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             SPL Unit                          |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           SF Label                    | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 2: Special-purpose Label Unit with the Basic Unit of MPLS
                            Label Stack for SFC




Liu & Mirsky             Expires April 28, 2021                 [Page 5]


Internet-Draft              LSP Ping for SFC                October 2020


3.1.1.  G-ACh over SFC-MPLS

   SFC-MPLS environment could include instances of an SF (SFI) or SFC
   proxies that cannot properly process control and/or management
   protocol messages that are exchanged between nodes over the G-ACh
   associated with the particular SFP.  To support OAM over G-ACh, it is
   beneficial to avoid handing over a test packet to the SFI or SFC
   proxy.  Hence, this specification defines that if the Generic
   Associated Channel Label (GAL) immediately follows the SFC Context
   label [RFC8595], then the packet is recognized as an SFP OAM packet.

   Below are the processing rules of an SFP OAM packet by an SFF:

   o  An SFF MUST NOT pass the packet to a local SFI or SFC proxy.

   o  The SFF MUST decrement SF Label entry's TTL value.  If the
      resulting value equals zero, the SFF MUST pass the SFP OAM packet
      to the control plane for processing.  An implementation that
      supports this specification MUST provide control to limit the rate
      of SFP OAM packets passed to the control plane for processing.

   o  If the TTL value is not zero, the SFP OAM packet is processed as
      defined in Section 6, Section 7, and Section 8 [RFC8595],
      according to the type of MPLS forwarding used in the SFP.

3.2.  MPLS-based SFP Consistency Verification

   An MPLS SFC validation request/reply is an MPLS echo request/reply
   that includes an SFC validation TLV (shown in Figure 3).

   Nodes examine and process the TLV only if configured to do so; other
   nodes MUST ignore the TLV and process the packet as a standard MPLS
   echo packet.


         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TLV Type=TBA1             |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                    SFC Information Sub-TLV(s)                 |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 3: SFC Validation TLV



Liu & Mirsky             Expires April 28, 2021                 [Page 6]


Internet-Draft              LSP Ping for SFC                October 2020


   SFC Information Sub-TLV: The Sub-TLV, as presented in Figure 4, MUST
   NOT be included in an MPLS SFC validation request.

3.3.  SFC Info Sub-TLV

   Upon receiving the SFC validation request, the SFF MUST respond with
   an echo reply, which includes the SFC detailed information.

   The SFC detailed information is recorded in SFC info sub-TLV.

   Two types of sub-TLVs are defined in this section, and those are used
   in MPLS-based service programming
   [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH [RFC8595]
   respectively.


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      sub-TLV Type=TBA2        |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SFF Label                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SF Label                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SF Type                   |     SR Proxy Type             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 4: SFC Info Sub-TLV for SR-MPLS-based Service Programming

   Type TBA2 sub-TLV: used in SR-MPLS-based service programming

   SFF Label: represents the SID of the SFF

   SF Label: represents the service SID of the SF or SR proxy

   SF Type: indicates the type of SF, such as DPI, firewall, etc.

   SR Proxy Type: It is defined in
   [I-D.ietf-spring-sr-service-programming] and indicates the type of SR
   proxy if it exists.









Liu & Mirsky             Expires April 28, 2021                 [Page 7]


Internet-Draft              LSP Ping for SFC                October 2020


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      sub-TLV Type=TBA3        |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    SFC-FWD Type               |       Reserved                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     SFC context Label                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SF Label                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     SF Type                   |      Reserved                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 5: SFC Info Sub-TLV for MPLS-based NSH

   Figure 5 presents the format of a sub-TLV for MPLS-based NSH.  The
   fields are as follows:

      Type TBA3 sub-TLV: used in MPLS-based NSH

      SFC-FWD Type: indicates the forwarding type of the data plane, and
      has the following values:

      0x10: MPLS-based NSH [RFC8595] label swapping

      0x11: MPLS-based NSH [RFC8595] label stacking

   SFC context Label: The meaning of the SFC context label depends on
   the SFC Type.  If SFC-FWD Type is 0x10, the SFC context Label
   represents SPI.  If SFC-FWD Type is 0x11, the SFC context Label
   represents the context label [RFC8595].

   SF Label: The meaning of the SF label depends on the SFC-FWD Type.
   If SFC Type is 0x10, the SF Label represents SI.  If SFC Type is
   0x11, the SF Label represents the SFI index [RFC8595].

   SF Type: It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and
   indicates the type of SF, such as DPI, firewall, etc.

3.4.  SFC Basic Unit FEC Sub-TLV

   Unlike standard MPLS forwarding, based on a single label, packet
   forwarding defined in [RFC8595] is based on the basic unit of MPLS
   label stack for SFC(SFC Context Label+SF Label).  A new SFC Basic
   Unit FEC sub-TLV with Type value (TBA4) is defined in this document.




Liu & Mirsky             Expires April 28, 2021                 [Page 8]


Internet-Draft              LSP Ping for SFC                October 2020


   The SFC Basic Unit FEC sub-TLV MAY be used to carry the corresponding
   FEC of the basic unit.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Route Distinguisher (RD)                     |
      |                      (8 octets)                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         SF Type               |       Reserved                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 6: SFC Basic Unit sub-TLV

   The format of the basic unit sub-TLV is shown in Figure 6 and
   includes the following fields:

      Route Distinguisher (RD): 8 octets field in SFIR Route Type
      specific NLRI [I-D.ietf-bess-nsh-bgp-control-plane].

      SF Type: 2 octets.  It is defined in [I-D.ietf-bess-nsh-bgp-
      control-plane] and indicates the type of SF, such as DPI,
      firewall, etc.

   SFC Basic Unit sub-TLV is defined for Target FEC Stack TLV(Type 1
   TLV).

   A node that receives an LSP ping with the Target FEC Stack TLV and
   the SFC Basic Unit FEC Sub-TLV included will check if it is its Route
   Distinguisher and whether it advertised that Service Function Type.
   If the validation is not passed, the SFF will generate an MPLS echo
   reply with an error code as defined in [RFC8029].

3.5.  Theory of Operation

   An MPLS SFC validation request is an MPLS echo request with an SFC
   validation TLV, and the echo request is sent with a label stack
   corresponding to the SFP being tested.  To trace SFC-MPLS, the
   Generic Associated Channel Label (GAL) which immediately follows the
   SFC Context label is also included.

   Sending an SFC echo request to the control plane is triggered by one
   of the following packet processing exceptions: IP TTL expiration,
   MPLS TTL expiration, or the receiver is the terminal SFF for an SFP.





Liu & Mirsky             Expires April 28, 2021                 [Page 9]


Internet-Draft              LSP Ping for SFC                October 2020


   After general packet sanity verifying [RFC8029], Section 3.5.1 and
   Section 3.5.2 in this document separately describe the following
   processing procedures in service programming and MPLS-based NSH.

   After all SFFs on the SFP send back MPLS echo reply, the sender
   collects information about all traversed SFFs and SFs on the rendered
   service path (RSP).

3.5.1.  MPLS-based service programming

   [I-D.ietf-spring-sr-service-programming] describes how a service can
   be associated with a SID to achieve service function chaining.  In an
   SR-MPLS network, the SFP is encoded as a stack of MPLS labels.  That
   stack is pushed on top of the packet.

   Before generating an echo relpy, an SFF MUST parse through the label
   stack until the next label is not a local service SID to get all the
   SFs attached to the SFF on the SFP and record the corresponding
   Label-stack-depth.

   The SFF then sends an MPLS echo reply with all the SF information
   recorded in SFC Information Sub-TLV, including the service SID and
   the SF type.

3.5.2.  Path Consistency in SFC-MPLS

   [RFC8595] describes how Service Function Chaining (SFC) can be
   achieved in an MPLS network using a logical representation of the
   Network Service Header (NSH) in an MPLS label stack.

   SFC forwarding can be achieved by label swapping, label stacking, or
   the mix of both.  When an SFF receives a packet containing an MPLS
   label stack, it examines the top basic unit of MPLS label stack for
   SFC, {SPI, SI} or {context label, SFI index}, to determine where to
   send the packet next.

   As described in Section 3.1.1, the packet with GAL is recognized by
   the SFF as an SFP OAM packet.  The SFF then decrements SF Label
   entry's TTL value.  If the resulting value equals zero, the SFF
   passes the SFP OAM packet to the control plane for processing.  The
   system that supports ths specification generates a reply message,
   including in it the SFC info sub-TLV as desribed in Section 3.3.

3.6.  Discussion

   In [RFC8595], it says, "when an SFF receives a packet from any
   component of the SFC system (classifier, SFI, or another SFF), it
   MUST discard any packets with TTL set to zero".  To trace SFC, it



Liu & Mirsky             Expires April 28, 2021                [Page 10]


Internet-Draft              LSP Ping for SFC                October 2020


   should be changed to allow punting the packet to the control plane
   though under throttling control.

4.  Security Considerations

   This specification defines the processing of an SFP OAM packet.  Such
   packets could be used as an attack vector.  A system that supports
   this specification MUST provide control to limit the rate of SFP OAM
   packets sent to the control plane for processing.

5.  IANA Considerations

   This document requests assigning type values for TLVs and sub-TLVs
   from the IANA "Multiprotocol Label Switching (MPLS) Label Switched
   Paths (LSPs) Ping Parameters" registry as described in the sub-
   sections below.

5.1.  SFC Validation TLV

   IANA is requested to assign a type from the Standards Action range of
   the "TLVs" registry according to Table 1:

                +-------+----------------+---------------+
                | Value | Description    | Reference     |
                +-------+----------------+---------------+
                | TBA1  | SFC Validation | This document |
                +-------+----------------+---------------+

                Table 1: Type Value for SFC Validation TLV

5.1.1.  Sub-TLVs for SFC Validation TLV

   Two sub-TLVs of SFC Validation TLV is defined in this document
   according to Table 2.

   +-------+-------------------------------------------+---------------+
   | Value | Description                               | Reference     |
   +-------+-------------------------------------------+---------------+
   |  TBA2 |  Info for SR-MPLS-                        | This document |
   |       | based Service Programming                 |               |
   |  TBA3 | Info for MPLS-based NSH                   | This document |
   +-------+-------------------------------------------+---------------+

              Table 2: Sub-TLV Values for SFC Validation TLV







Liu & Mirsky             Expires April 28, 2021                [Page 11]


Internet-Draft              LSP Ping for SFC                October 2020


5.2.  SFC Basic Unit sub-TLV

   IANA is requested to assign a type from the Standards Action range of
   the "Sub-TLVs for TLV Types 1, 16, and 21" registry according to
   Table 3:

                +-------+----------------+---------------+
                | Value | Description    | Reference     |
                +-------+----------------+---------------+
                | TBA4  | SFC Basic Unit | This document |
                +-------+----------------+---------------+

              Table 3: Type Value for SFC Basic Unit sub-TLV

6.  References

6.1.  Normative References

   [I-D.ietf-bess-nsh-bgp-control-plane]
              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
              Jalil, "BGP Control Plane for the Network Service Header
              in Service Function Chaining", draft-ietf-bess-nsh-bgp-
              control-plane-18 (work in progress), August 2020.

   [I-D.ietf-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Service Programming with
              Segment Routing", draft-ietf-spring-sr-service-
              programming-03 (work in progress), September 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.






Liu & Mirsky             Expires April 28, 2021                [Page 12]


Internet-Draft              LSP Ping for SFC                October 2020


   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC 7274,
              DOI 10.17487/RFC7274, June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8595]  Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
              Forwarding Plane for Service Function Chaining", RFC 8595,
              DOI 10.17487/RFC8595, June 2019,
              <https://www.rfc-editor.org/info/rfc8595>.

6.2.  Informative References

   [I-D.ietf-sfc-nsh-tlv]
              Wei, Y., Elzur, U., and S. Majee, "Network Service Header
              Metadata Type 2 Variable-Length Context Headers", draft-
              ietf-sfc-nsh-tlv-03 (work in progress), May 2020.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

Authors' Addresses








Liu & Mirsky             Expires April 28, 2021                [Page 13]


Internet-Draft              LSP Ping for SFC                October 2020


   Liu Yao
   ZTE Corporation
   No. 50 Software Ave, Yuhuatai Distinct
   Nanjing
   China

   Email: liu.yao71@zte.com.cn


   Greg Mirsky
   ZTE Corporation

   Email: gregimirsky@gmail.com






































Liu & Mirsky             Expires April 28, 2021                [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/