MPLS Working Group                                             A. Farrel
Internet-Draft                                        Old Dog Consulting
Intended status: Standards Track                               S. Bryant
Expires: August 16, 2019                                          Huawei
                                                                J. Drake
                                                        Juniper Networks
                                                       February 12, 2019


      An MPLS-Based Forwarding Plane for Service Function Chaining
                         draft-ietf-mpls-sfc-05

Abstract

   Service Function Chaining (SFC) is the process of directing packets
   through a network so that they can be acted on by an ordered set of
   abstract service functions before being delivered to the intended
   destination.  An architecture for SFC is defined in RFC7665.

   The Network Service Header (NSH) can be inserted into packets to
   steer them along a specific path to realize a Service Function Chain.

   Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
   technology that uses labels placed in a packet in a label stack to
   identify the forwarding actions to be taken at each hop through a
   network.  Actions may include swapping or popping the labels as well,
   as using the labels to determine the next hop for forwarding the
   packet.  Labels may also be used to establish the context under which
   the packet is forwarded.

   This document describes how Service Function Chaining can be achieved
   in an MPLS network by means of a logical representation of the NSH in
   an MPLS label stack.  That is, the NSH is not used, but the fields of
   the NSH are mapped to fields in the MPLS label stack.  It does not
   deprecate or replace the NSH, but acknowledges that there may be a
   need for an interim deployment of SFC functionality in brownfield
   networks.

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




Farrel, et al.           Expires August 16, 2019                [Page 1]


Internet-Draft                  MPLS SFC                   February 2019


   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 August 16, 2019.

Copyright Notice

   Copyright (c) 2019 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Choice of Data Plane SPI/SI Representation  . . . . . . . . .   4
   4.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Label Swapping for Logical NSH  . . . . . . . . . . . . .   5
     4.2.  Hierarchical Encapsulation  . . . . . . . . . . . . . . .   5
     4.3.  Fine Control of Service Function Instances  . . . . . . .   6
     4.4.  Micro Chains and Label Stacking . . . . . . . . . . . . .   6
     4.5.  SFC and Segment Routing . . . . . . . . . . . . . . . . .   6
   5.  Basic Unit of Representation  . . . . . . . . . . . . . . . .   6
   6.  MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . .   8
   7.  MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . .  10
   8.  Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . .  12
   9.  A Note on Service Function Capabilities and SFC Proxies . . .  13
   10. Control Plane Considerations  . . . . . . . . . . . . . . . .  13
   11. Use of the Entropy Label  . . . . . . . . . . . . . . . . . .  14
   12. Metadata  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Indicating Metadata in User Data Packets . . . . . . . .  15
     12.2.  Inband Programming of Metadata . . . . . . . . . . . . .  17
   13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . .  20
   14. Implementation Notes  . . . . . . . . . . . . . . . . . . . .  24
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  25
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   17. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26



Farrel, et al.           Expires August 16, 2019                [Page 2]


Internet-Draft                  MPLS SFC                   February 2019


   18. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  27
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     19.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     19.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   Service Function Chaining (SFC) is the process of directing packets
   through a network so that they can be acted on by an ordered set of
   abstract service functions before being delivered to the intended
   destination.  An architecture for SFC is defined in [RFC7665].

   When applying a particular Service Function Chain to the traffic
   selected by a service classifier, the traffic needs to be steered
   through an ordered set of Service Functions (SFs) in the network.
   This ordered set of SFs is termed a Service Function Path (SFP), and
   the traffic is passed between Service Function Forwarders (SFFs) that
   are responsible for delivering the packets to the SFs and for
   forwarding them onward to the next SFF.

   In order to steer the selected traffic between SFFs and to the
   correct SFs the service classifier needs to attach information to
   each packet.  This information indicates the SFP on which the packet
   is being forwarded and hence the SFs to which it must be delivered.
   The information also indicates the progress the packet has already
   made along the SFP.

   The Network Service Header (NSH) [RFC8300] has been defined to carry
   the necessary information for Service Function Chaining in packets.
   The NSH can be inserted into packets and contains various information
   including a Service Path Indicator (SPI), a Service Index (SI), and a
   Time To Live (TTL) counter.

   Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed
   forwarding technology that uses labels placed in a packet in a label
   stack to identify the forwarding actions to be taken at each hop
   through a network.  Actions may include swapping or popping the
   labels as well, as using the labels to determine the next hop for
   forwarding the packet.  Labels may also be used to establish the
   context under which the packet is forwarded.  In many cases, MPLS
   will be used as a tunneling technology to carry packets through
   networks between SFFs.

   This document describes how Service Function Chaining can be achieved
   in an MPLS network by means of a logical representation of the NSH in
   an MPLS label stack.  This approach is applicable to all forms of
   MPLS forwarding (where labels are looked up at each hop, and swapped



Farrel, et al.           Expires August 16, 2019                [Page 3]


Internet-Draft                  MPLS SFC                   February 2019


   or popped [RFC3031]).  It does not deprecate or replace the NSH, but
   acknowledges that there may be a need for an interim deployment of
   SFC functionality in brownfield networks.  The mechanisms described
   in this document are a compromise between the full function that can
   be achieved using the NSH, and the benefits of reusing the existing
   MPLS forwarding paradigms.

   Section 4 provides a short overview of several use case scenarios
   that help to explain the relationship between the MPLS label
   operations (swapping, popping, stacking) and the MPLS encoding of the
   logical NSH described in this document).

   It is assumed that the reader is fully familiar with the terms and
   concepts introduced in [RFC7665] and [RFC8300].

   Note that one of the features of the SFC architecture described in
   [RFC7665] is the "SFC proxy" that exists to include legacy SFs that
   are not able to process NSH-encapsulated packets.  This issue is
   equally applicable to the use of MPLS-encapsulated packets that
   encode a logical representation of an NSH.  It is discussed further
   in Section 9.

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

3.  Choice of Data Plane SPI/SI Representation

   While [RFC8300] defines the NSH that can be used in a number of
   environments, this document provides a mechanism to handle situations
   in which the NSH is not ubiquitously deployed.  In this case it is
   possible to use an alternative data plane representation of the SPI/
   SI by carrying the identical semantics in MPLS labels.

   In order to correctly select the mechanism by which SFC information
   is encoded and carried between SFFs, it may be necessary to configure
   the capabilities and choices either within the whole Service Function
   Overlay Network, or on a hop by hop basis.  It is a requirement that
   both ends of a tunnel over the underlay network (i.e., a pair of SFFs
   adjacent in the SFC) know that the tunnel is used for SFC and know
   what form of NSH representation is used.  A control plane signalling
   approach to achieve these objectives is provided using BGP in
   [I-D.ietf-bess-nsh-bgp-control-plane].




Farrel, et al.           Expires August 16, 2019                [Page 4]


Internet-Draft                  MPLS SFC                   February 2019


   Note that the encoding of the SFC information is independent of the
   choice of tunneling technology used between SFFs.  Thus, an MPLS
   representation of the logical NSH (as defined in this document) may
   be used even if the tunnel between a pair of SFFs is not an MPLS
   tunnel.  Conversely, MPLS tunnels may be used to carry other
   encodings of the logical NSH (specifically, the NSH itself).

4.  Use Case Scenarios

   There are five scenarios that can be considered for the use of an
   MPLS encoding in support of SFC.  These are set out in the following
   sub-sections.

4.1.  Label Swapping for Logical NSH

   The primary use case for SFC is described in [RFC7665] and delivered
   using the NSH which, as described in [RFC8300], uses an encapsulation
   with a position indicator that is modified at each SFC hop along the
   chain to indicate the next hop.

   The label swapping use case scenario effectively replaces the NSH
   with an MPLS encapsulation as described in Section 6.  The MPLS
   labels encode the same information as the NSH to form a logical NSH.
   The labels are modified (swapped per [RFC3031]) at each SFC hop along
   the chain to indicate the next hop.  The processing and forwarding
   state for a chain (i.e., the actions to take on a received label) are
   programmed in to the network using a control plane or management
   plane.

4.2.  Hierarchical Encapsulation

   [RFC8459] describes an architecture for hierarchical encapsulation
   using the NSH.  It facilitates partitioning of SFC domains for
   administrative reasons, and allows concatenation of service function
   chains under the control of a service classifier.

   The same function can be achieved in an MPLS network using an MPLS
   encoding of the logical NSH, and label stacking as defined in
   [RFC3031] and described in Section 7.  In this model, swapping is
   used per Section 4.1 to navigate one chain, and when the end of the
   chain is reached, the final label is popped revealing the label for
   another chain.  Thus, the primary mode is swapping, but stacking is
   used to enable the ingress classifier to control concatenation of
   service function chains.







Farrel, et al.           Expires August 16, 2019                [Page 5]


Internet-Draft                  MPLS SFC                   February 2019


4.3.  Fine Control of Service Function Instances

   It may be that a service function chain (as described in Section 4.1
   allows some leeway in the choice of service function instances along
   the chain.  However, it may be that a service classifier wishes to
   constrain the choice and this can be achieved using chain
   concatenation so that the first chain ends at the point of choice,
   the next label in the stack indicates the specific service function
   instance to be executed, and the next label in the stack starts a new
   chain.  Thus, a mixture of label swapping and stacking is used.

4.4.  Micro Chains and Label Stacking

   The scenario in Section 4.2 may be extended to its logical extreme by
   making each concatenated chain as short as it can be: one service
   function.  Each label in the stack indicates the next service
   function to be executed, and the network is programmed through the
   control plane or management plane to know how to route to the next
   (i.e., first) hop in each chain just as it would be to support the
   scenarios in Section 4.1 and Section 4.2.

   This scenario is functionally identical to the use of MPLS-SR for SFC
   as described Section 4.5, and the discussion in that section applies
   to this section as well.

4.5.  SFC and Segment Routing

   Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a
   stack of MPLS labels to encode information about the path and network
   functions that a packet should traverse.  MPLS-SR is achieved by
   applying control plane and management plane techniques to program the
   MPLS forwarding plane, and by imposing labels on packets at the
   entrance to the MPLS-SR network.

   The application of SR to SFC was considered in early versions of the
   SR architecture [RFC8402] and the MPLS-SR specification
   [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
   of those documents.  An implementation proposal for achieving SFC
   using MPLS-SR can be found in [I-D.xuclad-spring-sr-service-chaining]
   and is not discussed further in this document.

5.  Basic Unit of Representation

   When an MPLS label stack is used to carry a logical NSH, a basic unit
   of representation is used.  This unit comprises two MPLS labels as
   shown below.  The unit may be present one or more times in the label
   stack as explained in subsequent sections.




Farrel, et al.           Expires August 16, 2019                [Page 6]


Internet-Draft                  MPLS SFC                   February 2019


   In order to convey the same information as is present in the NSH, two
   MPLS label stack entries are used.  One carries a label to provide
   context within the SFC scope (the SFC Context Label), and the other
   carries a label to show which service function is to be actioned (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

   The fields of these two label stack entries are encoded as follows:

   Label:  The Label fields contain the values of the SFC Context Label
      and the SF Label encoded as 20 bit integers.  The precise
      semantics of these label fields are dependent on whether the label
      stack entries are used for MPLS label swapping (see Section 6) or
      MPLS label stacking (see Section 7).

   TC:  The TC bits have no meaning.  They SHOULD be set to zero in both
      label stack entries when a packet is sent and MUST be ignored on
      receipt.

   S: The bottom of stack bit has its usual meaning in MPLS.  It MUST be
      clear in the SFC Context label stack entry and MAY be set in the
      SF label stack entry depending on whether the label is the bottom
      of stack.

   TTL:  The TTL field in the SFC Context label stack entry SHOULD be
      set to 1.  The TTL in SF label stack entry (called the SF TTL) is
      set according to its use for MPLS label swapping (see Section 6)
      or MPLS label stacking (see Section 7 and is used to mitigate
      packet loops.

   The sections that follow show how this basic unit of MPLS label stack
   may be used for SFC in the MPLS label swapping case and in the MPLS
   label stacking.  For simplicity, these sections do not describe the
   use of metadata: that is covered separately in Section 12.






Farrel, et al.           Expires August 16, 2019                [Page 7]


Internet-Draft                  MPLS SFC                   February 2019


6.  MPLS Label Swapping

   This section describes how the basic unit of MPLS label stack for SFC
   introduced in Section 5 is used when MPLS label swapping is in use.
   The use case scenario for this approach is introduced in Section 4.1.

   As can be seen from Figure 2, the top of the label stack comprises
   the labels necessary to deliver the packet over the MPLS tunnel
   between SFFs.  Any MPLS encapsulation may be used (i.e., MPLS, MPLS
   in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel
   technology does not need to be MPLS, but that is shown here for
   simplicity.

   An entropy label ([RFC6790]) may also be present as described in
   Section 11

   Under these labels (or other encapsulation) comes a single instance
   of the basic unit of MPLS label stack for SFC.  In addition to the
   interpretation of the fields of these label stack entries provided in
   Section 5 the following meanings are applied:

   SPI Label:  The Label field of the SFC Context label stack entry
      contains the value of the SPI encoded as a 20 bit integer.  The
      semantics of the SPI is exactly as defined in [RFC8300].  Note
      that an SPI as defined by [RFC8300] can be encoded in 3 octets
      (i.e., 24 bits), but that the Label field allows for only 20 bits
      and reserves the values 0 though 15 as 'special purpose' labels
      [RFC7274].  Thus, a system using MPLS representation of the
      logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or
      less than 16.

   SI Label:  The Label field of the SF label stack entry contains the
      value of the SI exactly as defined in [RFC8300].  Since the SI
      requires only 8 bits, and to avoid overlap with the 'special
      purpose' label range of 0 through 15 [RFC7274], the SI is carried
      in the top (most significant) 8 bits of the Label field with the
      low order 12 bits set to zero.

   TC:  The TC fields are as described in Section 5.

   S: The S bits are as described in Section 5.

   TTL:  The TTL field in the SPI label stack entry SHOULD be set to 1
      as stated in Section 5.  The TTL in SF label stack entry is
      decremented once for each forwarding hop in the SFP, i.e., for
      each SFF transited, and so mirrors the TTL field in the NSH.





Farrel, et al.           Expires August 16, 2019                [Page 8]


Internet-Draft                  MPLS SFC                   February 2019


     ---------------
    ~ Tunnel Labels ~
    +---------------+
    ~   Optional    ~
    ~ Entropy Label ~
    +---------------+ - - -
    |   SPI Label   |
    +---------------+  Basic unit of MPLS label stack for SFC
    |   SI Label    |
    +---------------+ - - -
    |               |
    ~    Payload    ~
    |               |
     ---------------


                    Figure 2: The MPLS SFC Label Stack

   The following processing rules apply to the Label fields:

   o  When a classifier inserts a packet onto an SFP it sets the SPI
      Label to indicate the identity of the SFP, and sets the SI Label
      to indicate the first SF in the path.

   o  When a component of the SFC system processes a packet it uses the
      SPI Label to identify the SFP and the SI Label to determine to
      which SFF or instance of an SF (an SFI) to deliver the packet.
      Under normal circumstances (with the exception of branching and
      reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the
      SPI Label value is preserved on all packets.  The SI Label value
      is modified by SFFs and through reclassification to indicate the
      next hop along the SFP.

   The following processing rules apply to the TTL field of the SF label
   stack entry, and are derived from section 2.2 of [RFC8300]:

   o  When a classifier places a packet onto an SFP it MUST set the TTL
      to a value between 1 and 255.  It SHOULD set this according to the
      expected length of the SFP (i.e., the number of SFs on the SFP),
      but it MAY set it to a larger value according to local
      configuration.  The maximum TTL value supported in an NSH is 63,
      and so the practical limit here may also be 63.

   o  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.  It SHOULD log such occurrences, but MUST apply
      rate limiting to any such logs.




Farrel, et al.           Expires August 16, 2019                [Page 9]


Internet-Draft                  MPLS SFC                   February 2019


   o  An SFF MUST decrement the TTL by one each time it performs a
      forwarding lookup.

   o  If an SFF decrements the TTL to zero it MUST NOT send the packet,
      and MUST discard the packet.  It SHOULD log such occurrences, but
      MUST apply rate limiting to any such logs.

   o  SFIs MUST ignore the TTL, but MUST mirror it back to the SFF
      unmodified along with the SI (which may have been changed by local
      reclassification).

   o  If a classifier along the SFP makes any change to the intended
      path of the packet including for looping, jumping, or branching
      (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the
      SI TTL of the packet.  In particular, each component of the SFC
      system MUST NOT increase the SI TTL value otherwise loops may go
      undetected.

7.  MPLS Label Stacking

   This section describes how the basic unit of MPLS label stack for SFC
   introduced in Section 5 is used when MPLS label stacking is used to
   carry information about the SFP and SFs to be executed.  The use case
   scenarios for this approach is introduced in Section 4.

   As can be seen in Figure 3, the top of the label stack comprises the
   labels necessary to deliver the packet over the MPLS tunnel between
   SFFs.  Any MPLS encapsulation may be used.

   An entropy label ([RFC6790]) may also be present as described in
   Section 11

   Under these labels comes one of more instances of the basic unit of
   MPLS label stack for SFC.  In addition to the interpretation of the
   fields of these label stack entries provided in Section 5 the
   following meanings are applied:

   SFC Context Label:  The Label field of the SFC Context label stack
      entry contains a label that delivers SFC context.  This label may
      be used to indicate the SPI encoded as a 20 bit integer using the
      semantics of the SPI is exactly as defined in [RFC8300] and noting
      that in this case a system using MPLS representation of the
      logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or
      less than 16.  This label may also be used to convey other SFC
      context-speific semantics such as indicating how to interpret the
      SF Label or how to forward the packet to the node that offers the
      SF.




Farrel, et al.           Expires August 16, 2019               [Page 10]


Internet-Draft                  MPLS SFC                   February 2019


   SF Label:  The Label field of the SF label stack entry contains a
      value that identifies the next SFI to be actioned for the packet.
      This label may be scoped globally or within the context of the
      preceding SFC Context Label and comes from the range 16 ... 2^20 -
      1.

   TC:  The TC fields are as described in Section 5.

   S: The S bits are as described in Section 5.

   TTL:  The TTL fields in the SFC Context label stack entry SF label
      stack entry SHOULD be set to 1 as stated in Section 5, but MAY be
      set to larger values if the label indicated a forwarding operation
      towards the node that hosts the SF.


     -------------------
    ~   Tunnel Labels   ~
    +-------------------+
    ~     Optional      ~
    ~   Entropy Label   ~
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    ~                   ~
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    |                   |
    ~    Payload        ~
    |                   |
     -------------------


           Figure 3: The MPLS SFC Label Stack for Label Stacking

   The following processing rules apply to the Label fields:

   o  When a classifier inserts a packet onto an SFP it adds a stack
      comprising one or more instances of the basic unit of MPLS label



Farrel, et al.           Expires August 16, 2019               [Page 11]


Internet-Draft                  MPLS SFC                   February 2019


      stack for SFC.  Taken together, this stack defines the SFs to be
      actioned and so defines the SFP that the packet will traverse.

   o  When a component of the SFC system processes a packet it uses the
      top basic unit of label stack for SFC to determine to which SFI to
      next deliver the packet.  When an SFF receives a packet it
      examines the top basic unit of MPLS label stack for SFC to
      determine where to send the packet next.  If the next recipient is
      a local SFI, the SFC strips the basic unit of MPLS label stack for
      SFC before forwarding the packet.

8.  Mixed Mode Forwarding

   The previous sections describe homogeneous networks where SFC
   forwarding is either all label swapping or all label popping
   (stacking).  This simplification helps to clarify the explanation of
   the mechanisms.

   However, as described in Section 4.2, some uses cases may use label
   swapping and stacking at the same time.  Furthermore, it is also
   possible that different parts of the network utilize swapping or
   popping such that an end-to-end service chain has to utilize a
   combination of both techniques.  It is also worth noting that a
   classifier may be content to use an SFP as installed in the network
   by a control plane or management plane and so would use label
   swapping, but that there may be a point in the SFP where a choice of
   SFIs can be made (perhaps for load balancing) and where, in this
   instance, the classifier wishes to exert control over that choice by
   use of a specific entry on the label stack as described in
   Section 4.3.

   When an SFF receives a packet containing an MPLS label stack, it
   checks whether it is processing an {SFP, SI} label pair for label
   swapping or a {context label, SFI index} label pair for label
   stacking.  It then selects the appropriate SFI to which to send the
   packet.  When it receives the packet back from the SFI, it has four
   cases to consider.

   o  If the current hop requires an {SFP, SI} and the next hop requires
      an {SFP, SI}, it selects an instance of the SF to be executed at
      the next hop, sets the SI label to the SI value of the next hop,
      and tunnels the packet to the SFF for that SFI.

   o  If the current hop requires an {SFP, SI} and the next hop requires
      a {context label, SFI label}, it pops the {SFP, SI} from the top
      of the MPLS label stack and tunnels the packet to the SFF
      indicated by the context label.




Farrel, et al.           Expires August 16, 2019               [Page 12]


Internet-Draft                  MPLS SFC                   February 2019


   o  If the current hop requires a {context label, SFI label}, it pops
      the {context label, SFI label} from the top of the MPLS label
      stack.

      *  If the new top of the MPLS label stack contains an {SFP, SI}
         label pair, it selects an SFI to use at the next hop, and
         tunnels the packet to SFF for that SFI.

      *  If the top of the MPLS label stack contains a {context label,
         SFI label}, it tunnels the packet to the SFF indicated by the
         context label.

9.  A Note on Service Function Capabilities and SFC Proxies

   The concept of an "SFC proxy" is introduced in [RFC7665].  An SFC
   proxy is logically located between an SFF and an SFI that is not
   "SFC-aware".  Such SFIs are not capable of handling the SFC
   encapsulation (whether that be NSH or MPLS) and need the
   encapsulation stripped from the packets they are to process.  In many
   cases, legacy SFIs that were once deployed as "bumps in the wire" fit
   into this category until they have been upgraded to be SFC-aware.

   The job of an SFC proxy is to remove and then reimpose SFC
   encapsulation so that the SFF is able to process as though it was
   communication with an SFC-aware SFI, and so that the SFI is unaware
   of the SFC encapsulation.  In this regard, the job of an SFC proxy is
   no different when NSH encapsulation is used and when MPLS
   encapsulation is used as described in this document, although (of
   course) it is different encapsulation bytes that must be removed and
   reimposed.

   It should be noted that the SFC proxy is a logical function.  It
   could be implemented as a separate physical component on the path
   from the SFF to SFI, but it could be coresident with the SFF or it
   could be a component of the SFI.  This is purely an implementation
   choice.

   Note also that the delivery of metadata (see Section 12) requires
   specific processing if an SFC proxy is in use.  This is also no
   different when NSH or the MPLS encoding defined in this document is
   in use, and how it is handled will depend on how (or if) each non-
   SFC-aware SFI can receive metadata.

10.  Control Plane Considerations

   In order that a packet may be forwarded along an SFP several
   functional elements must be executed.




Farrel, et al.           Expires August 16, 2019               [Page 13]


Internet-Draft                  MPLS SFC                   February 2019


   o  Discovery/advertisement of SFIs.

   o  Computation of SFP.

   o  Programming of classifiers.

   o  Advertisement of forwarding instructions.

   Various approaches may be taken.  These include a fully centralized
   model where SFFs report to a central controller the SFIs that they
   support, the central controller computes the SFP and programs the
   classifiers, and (if the label swapping approach is taken) the
   central controller installs forwarding state in the SFFs that lie on
   the SFP.

   Alternatively, a dynamic control plane may be used such as that
   described in [I-D.ietf-bess-nsh-bgp-control-plane].  In this case the
   SFFs use the control plane to advertise the SFIs that they support, a
   central controller computes the SFP and programs the classifiers, and
   (if the label swapping approach is taken) the central controller uses
   the control plane to advertise the SFPs so that SFFs that lie on the
   SFP can install the necessary forwarding state.

11.  Use of the Entropy Label

   Entropy is used in ECMP situations to ensure that packets from the
   same flow travel down the same path, thus avoiding jitter or re-
   ordering issues within a flow.

   Entropy is often determined by hashing on specific fields in a packet
   header such as the "five-tuple" in the IP and transport headers.
   However, when an MPLS label stack is present, the depth of the stack
   could be too large for some processors to correctly determine the
   entropy hash.  This problem is addressed by the inclusion of an
   Entropy Label as described in [RFC6790].

   When entropy is desired for packets as they are carried in MPLS
   tunnels over the underlay network, it is RECOMMENDED that an Entropy
   Label is included in the label stack immediately after the tunnel
   labels and before the SFC labels as shown in Figure 2 and Figure 3.

   If an Entropy Label is present in an MPLS payload, it is RECOMMENDED
   that the initial classifier use that value in an Entropy Label
   inserted in the label stack when the packet is forwarded (on the
   first tunnel) to the first SFF.  In this case it is not necessary to
   remove the Entropy Label from the payload.





Farrel, et al.           Expires August 16, 2019               [Page 14]


Internet-Draft                  MPLS SFC                   February 2019


12.  Metadata

   Metadata is defined in [RFC7665] as providing "the ability to
   exchange context information between classifiers and SFs, and among
   SFs."  [RFC8300] defines how this context information can be directly
   encoded in fields that form part of the NSH encapsulation.

   The next two sections describe how metadata is associated with user
   data packets, and how metadata may be exchanged between SFC nodes in
   the network, when using an MPLS encoding of the logical
   representation of the NSH.

   It should be noted that the MPLS encoding is less functional than the
   direct use of the NSH.  Both methods support metadata that is "per-
   SFP" or "per-packet-flow" (see [RFC8393] for definitions of these
   terms), but "per-packet" metadata (where the metadata must be carried
   on each packet because it differs from one packet to the next even on
   the same flow or SFP) is only supported using the NSH and not using
   the mechanisms defined in this document.

12.1.  Indicating Metadata in User Data Packets

   Metadata is achieved in the MPLS realization of the logical NSH by
   the use of an SFC Metadata Label which uses the Extended Special
   Purpose Label construct [RFC7274].  Thus, three label stack entries
   are present as shown in Figure 4:

   o  The Extension Label (value 15)

   o  An extended special purpose label called the Metadata Label
      Indicator (MLI) (value TBD1 by IANA)

   o  The Metadata Label (ML).


       ----------------
      | Extension = 15 |
      +----------------+
      |      MLI       |
      +----------------+
      | Metadata Label |
       ---------------


                   Figure 4: The MPLS SFC Metadata Label

   The Metadata Label value is an index into a table of metadata that is
   programmed into the network using in-band or out-of-band mechanisms.



Farrel, et al.           Expires August 16, 2019               [Page 15]


Internet-Draft                  MPLS SFC                   February 2019


   Out-of-band mechanisms potentially include management plane and
   control plane solutions (such as
   [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this
   document.  The in-band mechanism is described in Section 12.2

   The SFC Metadata Label (as a set of three labels as indicated in
   Figure 4) may be present zero, one, or more times in an MPLS SFC
   packet.  For MPLS label swapping, the SFC Metadata Labels are placed
   immediately after the basic unit of MPLS label stack for SFC as shown
   in Figure 5.  For MPLS label stacking, the SFC Metadata Labels can be
   present zero, one, or more times and are placed at the bottom of the
   label stack as shown in Figure 6.


       ----------------
      ~ Tunnel Labels  ~
      +----------------+
      ~   Optional     ~
      ~ Entropy Label  ~
      +----------------+
      |   SPI Label    |
      +----------------+
      |   SI Label     |
      +----------------+
      | Extension = 15 |
      +----------------+
      |     MLI        |
      +----------------+
      | Metadata Label |
      +----------------+
      ~     Other      ~
      |    Metadata    |
      ~  Label Triples ~
      +----------------+
      |                |
      ~    Payload     ~
      |                |
       ----------------


    Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata
                                   Label









Farrel, et al.           Expires August 16, 2019               [Page 16]


Internet-Draft                  MPLS SFC                   February 2019


     -------------------
    ~   Tunnel Labels   ~
    +-------------------+
    ~     Optional      ~
    ~   Entropy Label   ~
    +-------------------+
    | SFC Context Label |
    +-------------------+
    |     SF Label      |
    +-------------------+
    ~                   ~
    +-------------------+
    | SFC Context Label |
    +-------------------+
    |     SF Label      |
    +-------------------+
    |   Extension = 15  |
    +-------------------+
    |        MLI        |
    +-------------------+
    |  Metadata Label   |
    +-------------------+
    ~       Other       ~
    |      Metadata     |
    ~   Label Triples   ~
    +-------------------+
    |                   |
    ~    Payload        ~
    |                   |
     -------------------


    Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata
                                   Label

12.2.  Inband Programming of Metadata

   A mechanism for sending metadata associated with an SFP without a
   payload packet is described in [RFC8393].  The same approach can be
   used in an MPLS network where the NSH is logically represented by an
   MPLS label stack.

   The packet header is formed exactly as previously described in this
   document so that the packet will follow the SFP through the SFC
   network.  However, instead of payload data, metadata is included
   after the bottom of the MPLS label stack.  An Extended Special
   Purpose Label is used to indicate that the metadata is present.
   Thus, three label stack entries are present:



Farrel, et al.           Expires August 16, 2019               [Page 17]


Internet-Draft                  MPLS SFC                   February 2019


   o  The Extension Label (value 15)

   o  An extended special purpose label called the Metadata Present
      Indicator (MPI) (value TBD2 by IANA)

   o  The Metadata Label (ML) that is associated with this metadata on
      this SFP and can be used to indicate the use of the metadata as
      described in Section 12.

   The SFC Metadata Present Label, if present, is placed immediately
   after the last basic unit of MPLS label stack for SFC.  The resultant
   label stacks are shown in Figure 7 for the MPLS label swapping case
   and Figure 8 for the MPLS label stacking case.


       ---------------
      ~ Tunnel Labels ~
      +---------------+
      ~   Optional    ~
      ~ Entropy Label ~
      +---------------+
      |   SPI Label   |
      +---------------+
      |   SI Label    |
      +---------------+
      | Extension = 15|
      +---------------+
      |     MPI       |
      +---------------+
      | Metadata Label|
      +---------------+
      |               |
      ~    Metadata   ~
      |               |
       ---------------


      Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying
                                 Metadata












Farrel, et al.           Expires August 16, 2019               [Page 18]


Internet-Draft                  MPLS SFC                   February 2019


     -------------------
    ~   Tunnel Labels   ~
    +-------------------+
    ~     Optional      ~
    ~   Entropy Label   ~
    +-------------------+
    | SFC Context Label |
    +-------------------+
    |     SF Label      |
    +-------------------+
    | SFC Context Label |
    +-------------------+
    |     SF Label      |
    +-------------------+
    ~                   ~
    +-------------------+
    | SFC Context Label |
    +-------------------+
    |     SF Label      |
    +-------------------+
    |   Extension = 15  |
    +-------------------+
    |        MPI        |
    +-------------------+
    |  Metadata Label   |
    +-------------------+
    |                   |
    ~    Metadata       ~
    |                   |
     -------------------


      Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying
                                 Metadata

   In both cases the metadata is formatted as a TLV as shown in
   Figure 9.














Farrel, et al.           Expires August 16, 2019               [Page 19]


Internet-Draft                  MPLS SFC                   February 2019


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |        Metadata Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         Metadata                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 9: The Metadata TLV

   The fields of this TLV are interpreted as follows:

   Length:  The length of the metadata carried in the Metadata field in
      octets not including any padding.

   Metadata Type:  The type of the metadata present.  Values for this
      field are taken from the "MD Types" registry maintained by IANA
      and defined in [RFC8300].

   Metadata:  The actual metadata formatted as described in whatever
      document defines the metadata.  This field is end-padded with zero
      to three octets of zeroes to take it up to a four octet boundary.

13.  Worked Examples

   This section reverts to the simplified descriptions of networks that
   rely wholly on label swapping or label stacking.  As described in
   Section 4, actual deployment scenarios may depend on the use of both
   mechanisms and utilize a mixed mode as described in Section 8.

   Consider the simplistic MPLS SFC overlay network shown in Figure 10.
   A packet is classified for an SFP that will see it pass through two
   Service Functions, SFa and SFb, that are accessed through Service
   Function Forwarders SFFa and SFFb respectively.  The packet is
   ultimately delivered to destination, D.

   Let us assume that the SFP is computed and assigned the SPI of 239.
   The forwarding details of the SFP are distributed (perhaps using the
   mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs
   are programmed with the necessary forwarding instructions.

   The packet progresses as follows:

   a.  The classifier assigns the packet to the SFP and imposes two
       label stack entries comprising a single basic unit of MPLS SFC
       representation:




Farrel, et al.           Expires August 16, 2019               [Page 20]


Internet-Draft                  MPLS SFC                   February 2019


       *  The higher label stack entry contains a label carrying the SPI
          value of 239.

       *  The lower label stack entry contains a label carrying the SI
          value of 255.

       Further labels may be imposed to tunnel the packet from the
       classifier to SFFa.

   b.  When the packet arrives at SFFa it strips any labels associated
       with the tunnel that runs from the classifier to SFFa.  SFFa
       examines the top labels and matches the SPI/SI to identify that
       the packet should be forwarded to SFa.  The packet is forwarded
       to SFa unmodified.

   c.  SFa performs its designated function and returns the packet to
       SFFa.

   d.  SFFa modifies the SI in the lower label stack entry (to 254) and
       uses the SPI/SI to look up the forwarding instructions.  It sends
       the packet with two label stack entries:

       *  The higher label stack entry contains a label carrying the SPI
          value of 239.

       *  The lower label stack entry contains a label carrying the SI
          value of 254.

       Further labels may be imposed to tunnel the packet from the SFFa
       to SFFb.

   e.  When the packet arrives at SFFb it strips any labels associated
       with the tunnel from SFFa.  SFFb examines the top labels and
       matches the SPI/SI to identify that the packet should be
       forwarded to SFb.  The packet is forwarded to SFb unmodified.

   f.  SFb performs its designated function and returns the packet to
       SFFb.

   g.  SFFb modifies the SI in the lower label stack entry (to 253) and
       uses the SPI/SI to lookup up the forwarding instructions.  It
       determines that it is the last SFF in the SFP so it strips the
       two SFC label stack entries and forwards the payload toward D
       using the payload protocol.







Farrel, et al.           Expires August 16, 2019               [Page 21]


Internet-Draft                  MPLS SFC                   February 2019


        +---------------------------------------------------+
        |                   MPLS SFC Network                |
        |                                                   |
        |            +---------+       +---------+          |
        |            |   SFa   |       |   SFb   |          |
        |            +----+----+       +----+----+          |
        |               ^ | |             ^ | |             |
        |            (b)| | |(c)       (e)| | |(f)          |
        |       (a)     | | V     (d)     | | V    (g)      |
   +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
   |Classifier+------+  SFFa   +-------+  SFFb   +------+   D   |
   +----------+      +---------+       +---------+      +-------+
        |                                                   |
        +---------------------------------------------------+


          Figure 10: Service Function Chaining in an MPLS Network

   Alternatively, consider the MPLS SFC overlay network shown in
   Figure 11.  A packet is classified for an SFP that will see it pass
   through two Service Functions, SFx and SFy, that are accessed through
   Service Function Forwarders SFFx and SFFy respectively.  The packet
   is ultimately delivered to destination, D.

   Let us assume that the SFP is computed and assigned the SPI of 239.
   However, the forwarding state for the SFP is not distributed and
   installed in the network.  Instead it will be attached to the
   individual packets using the MPLS label stack.

   The packet progresses as follows:

   1.  The classifier assigns the packet to the SFP and imposes two
       basic units of MPLS SFC representation to describe the full SFP:

       *  The top basic unit comprises two label stack entries as
          follows:

          +  The higher label stack entry contains a label carrying the
             SFC context.

          +  The lower label stack entry contains a label carrying the
             SF indicator for SFx.

       *  The lower basic unit comprises two label stack entries as
          follows:

          +  The higher label stack entry contains a label carrying the
             SFC context.



Farrel, et al.           Expires August 16, 2019               [Page 22]


Internet-Draft                  MPLS SFC                   February 2019


          +  The lower label stack entry contains a label carrying the
             SF indicator for SFy.

       Further labels may be imposed to tunnel the packet from the
       classifier to SFFx.

   2.  When the packet arrives at SFFx it strips any labels associated
       with the tunnel from the classifier.  SFFx examines the top
       labels and matches the context/SF values to identify that the
       packet should be forwarded to SFx.  The packet is forwarded to
       SFx unmodified.

   3.  SFx performs its designated function and returns the packet to
       SFFx.

   4.  SFFx strips the top basic unit of MPLS SFC representation
       revealing the next basic unit.  It then uses the revealed
       context/SF values to determine how to route the packet to the
       next SFF, SFFy.  It sends the packet with just one basic unit of
       MPLS SFC representation comprising two label stack entries:

       *  The higher label stack entry contains a label carrying the SFC
          context.

       *  The lower label stack entry contains a label carrying the SF
          indicator for SFy.

       Further labels may be imposed to tunnel the packet from the SFFx
       to SFFy.

   5.  When the packet arrives at SFFy it strips any labels associated
       with the tunnel from SFFx.  SFFy examines the top labels and
       matches the context/SF values to identify that the packet should
       be forwarded to SFy.  The packet is forwarded to SFy unmodified.

   6.  SFy performs its designated function and returns the packet to
       SFFy.

   7.  SFFy strips the top basic unit of MPLS SFC representation
       revealing the payload packet.  It forwards the payload toward D
       using the payload protocol.










Farrel, et al.           Expires August 16, 2019               [Page 23]


Internet-Draft                  MPLS SFC                   February 2019


        +---------------------------------------------------+
        |                   MPLS SFC Network                |
        |                                                   |
        |            +---------+       +---------+          |
        |            |   SFx   |       |   SFy   |          |
        |            +----+----+       +----+----+          |
        |               ^ | |             ^ | |             |
        |            (2)| | |(3)       (5)| | |(6)          |
        |       (1)     | | V     (4)     | | V    (7)      |
   +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
   |Classifier+------+  SFFx   +-------+  SFFy   +------+   D   |
   +----------+      +---------+       +---------+      +-------+
        |                                                   |
        +---------------------------------------------------+


      Figure 11: Service Function Chaining Using MPLS Label Stacking

14.  Implementation Notes

   It is not the job of an IETF specification to describe the internals
   of an implementation except where that directly impacts upon the bits
   on the wire that change the likelihood of interoperability, or where
   the availability of configuration or security options directly affect
   the utility of an implementation.

   However, in view of the objective of this document to acknowledge
   that there may be a need for an interim deployment of SFC
   functionality in brownfield MPLS networks, this section provides some
   observations about how an SFF might utilize MPLS features that are
   available in existing routers.  This section is not intended to be
   definitive or technically complete, but is indicative.

   Consider the mechanism used to indicate to which Virtual Routing and
   Forwarding (VRF) an incoming MPLS packet should be routed in a Layer
   3 Virtual Private Network (L3VPN) [RFC4364].  In this case, the top
   MPLS label is an indicator of the VRF that is to be used to route the
   payload.

   A similar approach can be taken with the label swapping SFC technique
   described in Section 6 such that the SFC Context Label identifies a
   routing table specific to the SFP.  The SF Label can be looked up in
   the context of this routing table to determine to which SF to direct
   the packet, and how to forward it to the next SFF.

   Advanced features (such as metadata) are not inspected by SFFs.  The
   packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies,




Farrel, et al.           Expires August 16, 2019               [Page 24]


Internet-Draft                  MPLS SFC                   February 2019


   and those components are responsible for handling all metadata
   issues.

   Of course, an actual implementation might make considerable
   optimizations on this approach, but this section should provide hints
   about how MPLS-based SFC might be achieved with relatively small
   modifications to deployed MPLS devices.

15.  Security Considerations

   Discussion of the security properties of SFC networks can be found in
   [RFC7665].  Further security discussion for the NSH and its use is
   present in [RFC8300].  Those documents provide analysis and present a
   set of requirements and recommendations for security, but they do not
   describe any mechanisms for securing NSH systems.

   It is fundamental to the SFC design that the classifier is a trusted
   resource which determines the processing that the packet will be
   subject to, including for example the firewall.  It is also
   fundamental to the MPLS design that packets are routed through the
   network using the path specified by the node imposing the labels, and
   that labels are swapped or popped correctly.  Where an SF is not
   encapsulation aware the encapsulation may be stripped by an SFC proxy
   such that packet may exist as a native packet (perhaps IP) on the
   path between SFC proxy and SF, however this is an intrinsic part of
   the SFC design which needs to define how a packet is protected in
   that environment.

   SFC components are configured and enabled through a management system
   or a control plane.  This document does not make any assumptions
   about what mechanisms are used.  Deployments should, however, be
   aware that vulnerabilities in the management plane or control plane
   of an SFC system imply vulnerabilities in the whole SFC system.
   Thus, control plane solutions (such as
   [I-D.ietf-bess-nsh-bgp-control-plane]) and management plane
   mechanisms must include security measures that can be enable by
   operators to protect their SFC systems.

   An analysis of the security of MPLS systems is provided in [RFC5920].
   That document notes the MPLS forwarding plane has no built-in
   security mechanisms.  Some proposals to add encryption to the MPLS
   forwarding plane have been suggested
   ([I-D.ietf-mpls-opportunistic-encrypt]), but no mechanisms have been
   agreed at the time of publication of this document.  That means that
   procedures described in this document rely on three basic principles:

   o  The MPLS network is often considered to be a closed network such
      that insertion, modification, or inspection of packets by an



Farrel, et al.           Expires August 16, 2019               [Page 25]


Internet-Draft                  MPLS SFC                   February 2019


      outside party is not possible.  This is particularly pertinent in
      the SFC context because [RFC7665] notes that "The architecture
      described herein is assumed to be applicable to a single network
      administrative domain."

   o  The underlying transport mechanisms (such as Ethernet) between
      adjacent MPLS nodes may offer security mechanisms that can be used
      to defend packets "on the wire".

   o  The SFC-capable devices participating in an SFC system are
      responsible for verifying and protecting packets and their
      contents as well as providing other security capabilities that
      might be required in the particular system.

   Additionally, where a tunnel is used to link two non-MPLS domains,
   the tunnel design needs to specify how the tunnel is secured.

   Thus, the security vulnerabilities are addressed (or should be
   addressed) in all the underlying technologies used by this design.
   No known new security vulnerabilities are introduced by this design,
   but if issues are discovered in the future it is expected that they
   will be addressed through modifications to control/management
   components of any solution, or through changes to the underlying
   technology.

16.  IANA Considerations

   This document requests IANA to make allocations from the "Extended
   Special-Purpose MPLS Label Values" subregistry of the "Special-
   Purpose Multiprotocol Label Switching (MPLS) Label Values" registry
   as follows:


      Value  | Description                       |
      -------+-----------------------------------+--------------
      TBD1   | Metadata Label Indicator (MLI)    | [This.I-D]
      TBD2   | Metadata Present Indicator (MPI)  | [This.I-D]


17.  Acknowledgements

   This document derives ideas and text from
   [I-D.ietf-bess-nsh-bgp-control-plane].

   The authors are grateful to all those who contributed to the
   discussions that led to this work: Loa Andersson, Andrew G.  Malis,
   Alexander Vainshtein, Joel M.  Halpern, Tony Przygienda, Stuart




Farrel, et al.           Expires August 16, 2019               [Page 26]


Internet-Draft                  MPLS SFC                   February 2019


   Mackie, Keyur Patel, and Jim Guichard.  Loa Andersson provided
   helpful review comments.

   Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern,
   and Mach Chen for reviews of this text.  Thanks to Russ Mundy for his
   Security Directorate review and to S Moonesamy for useful
   discussions.

   The authors would like to be able to thank the authors of
   [I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original
   work on service chaining and the identification of services using
   SIDs, and conversation with whom helped clarify the application of
   MPLS-SR to SFC.

   Particular thanks to Loa Andersson for conversations and advice about
   working group process.

18.  Contributors

   The following people contributed text to this document:


               Andrew Malis
               Email: agmalis@gmail.com


19.  References

19.1.  Normative References

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

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

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



Farrel, et al.           Expires August 16, 2019               [Page 27]


Internet-Draft                  MPLS SFC                   February 2019


   [RFC8393]  Farrel, A. and J. Drake, "Operating the Network Service
              Header (NSH) with Next Protocol "None"", RFC 8393,
              DOI 10.17487/RFC8393, May 2018,
              <https://www.rfc-editor.org/info/rfc8393>.

19.2.  Informative References

   [I-D.ietf-bess-nsh-bgp-control-plane]
              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
              Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
              nsh-bgp-control-plane-05 (work in progress), January 2019.

   [I-D.ietf-mpls-opportunistic-encrypt]
              Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
              Networks", draft-ietf-mpls-opportunistic-encrypt-03 (work
              in progress), March 2017.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-18
              (work in progress), December 2018.

   [I-D.xuclad-spring-sr-service-chaining]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Segment Routing for
              Service Chaining", draft-xuclad-spring-sr-service-
              chaining-01 (work in progress), March 2018.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/info/rfc5920>.

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




Farrel, et al.           Expires August 16, 2019               [Page 28]


Internet-Draft                  MPLS SFC                   February 2019


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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/info/rfc8459>.

Authors' Addresses

   Adrian Farrel
   Old Dog Consulting

   Email: adrian@olddog.co.uk


   Stewart Bryant
   Huawei

   Email: stewart.bryant@gmail.com


   John Drake
   Juniper Networks

   Email: jdrake@juniper.net


















Farrel, et al.           Expires August 16, 2019               [Page 29]