doc: Add RFC documents

1 files changed, 1081 insertions, 0 deletions

diff --git a/doc/rfc/rfc8924.txt b/doc/rfc/rfc8924.txt
new file mode 100644
index 0000000..972afd6
--- /dev/null
+++ b/doc/rfc/rfc8924.txt
@@ -0,0 +1,1081 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Aldrin
+Request for Comments: 8924                                        Google
+Category: Informational                                C. Pignataro, Ed.
+ISSN: 2070-1721                                            N. Kumar, Ed.
+                                                                   Cisco
+                                                             R. Krishnan
+                                                                  VMware
+                                                             A. Ghanwani
+                                                                    Dell
+                                                            October 2020
+
+
+    Service Function Chaining (SFC) Operations, Administration, and
+                      Maintenance (OAM) Framework
+
+Abstract
+
+   This document provides a reference framework for Operations,
+   Administration, and Maintenance (OAM) for Service Function Chaining
+   (SFC).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8924.
+
+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
+   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
+     1.1.  Document Scope
+     1.2.  Acronyms and Terminology
+       1.2.1.  Acronyms
+       1.2.2.  Terminology
+   2.  SFC Layering Model
+   3.  SFC OAM Components
+     3.1.  The SF Component
+       3.1.1.  SF Availability
+       3.1.2.  SF Performance Measurement
+     3.2.  The SFC Component
+       3.2.1.  SFC Availability
+       3.2.2.  SFC Performance Measurement
+     3.3.  Classifier Component
+     3.4.  Underlay Network
+     3.5.  Overlay Network
+   4.  SFC OAM Functions
+     4.1.  Connectivity Functions
+     4.2.  Continuity Functions
+     4.3.  Trace Functions
+     4.4.  Performance Measurement Functions
+   5.  Gap Analysis
+     5.1.  Existing OAM Functions
+     5.2.  Missing OAM Functions
+     5.3.  Required OAM Functions
+   6.  Operational Aspects of SFC OAM at the Service Layer
+     6.1.  SFC OAM Packet Marker
+     6.2.  OAM Packet Processing and Forwarding Semantic
+     6.3.  OAM Function Types
+   7.  Candidate SFC OAM Tools
+     7.1.  ICMP
+     7.2.  BFD / Seamless BFD
+     7.3.  In Situ OAM
+     7.4.  SFC Traceroute
+   8.  Manageability Considerations
+   9.  Security Considerations
+   10. IANA Considerations
+   11. Informative References
+   Acknowledgements
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   Service Function Chaining (SFC) enables the creation of composite
+   services that consist of an ordered set of Service Functions (SFs)
+   that are to be applied to any traffic selected as a result of
+   classification [RFC7665].  SFC is a concept that provides for more
+   than just the application of an ordered set of SFs to selected
+   traffic; rather, it describes a method for deploying SFs in a way
+   that enables dynamic ordering and topological independence of those
+   SFs as well as the exchange of metadata between participating
+   entities.  The foundations of SFC are described in the following
+   documents:
+
+   *  SFC Problem Statement [RFC7498]
+
+   *  SFC Architecture [RFC7665]
+
+   The reader is assumed to be familiar with the material in [RFC7665].
+
+   This document provides a reference framework for Operations,
+   Administration, and Maintenance (OAM) [RFC6291] of SFC.
+   Specifically, this document provides:
+
+   *  an SFC layering model (Section 2),
+
+   *  aspects monitored by SFC OAM (Section 3),
+
+   *  functional requirements for SFC OAM (Section 4),
+
+   *  a gap analysis for SFC OAM (Section 5),
+
+   *  operational aspects of SFC OAM at the service layer (Section 6),
+
+   *  applicability of various OAM tools (Section 7), and
+
+   *  manageability considerations for SF and SFC (Section 8).
+
+   SFC OAM solution documents should refer to this document to indicate
+   the SFC OAM component and the functionality they target.
+
+   OAM controllers are SFC-aware network devices that are capable of
+   generating OAM packets.  They should be within the same
+   administrative domain as the target SFC-enabled domain.
+
+1.1.  Document Scope
+
+   The focus of this document is to provide an architectural framework
+   for SFC OAM, particularly focused on the aspect of the Operations
+   component within OAM.  Actual solutions and mechanisms are outside
+   the scope of this document.
+
+1.2.  Acronyms and Terminology
+
+1.2.1.  Acronyms
+
+   BFD        Bidirectional Forwarding Detection
+
+   CLI        Command-Line Interface
+
+   DWDM       Dense Wavelength Division Multiplexing
+
+   E-OAM      Ethernet OAM
+
+   hSFC       Hierarchical Service Function Chaining
+
+   IBN        Internal Boundary Node
+
+   IPPM       IP Performance Metrics
+
+   MPLS       Multiprotocol Label Switching
+
+   MPLS_PM    MPLS Performance Measurement
+
+   NETCONF    Network Configuration Protocol
+
+   NSH        Network Service Header
+
+   NVO3       Network Virtualization over Layer 3
+
+   OAM        Operations, Administration, and Maintenance
+
+   POS        Packet over SONET
+
+   RSP        Rendered Service Path
+
+   SF         Service Function
+
+   SFC        Service Function Chain
+
+   SFF        Service Function Forwarder
+
+   SFP        Service Function Path
+
+   SNMP       Simple Network Management Protocol
+
+   TRILL      Transparent Interconnection of Lots of Links
+
+   VM         Virtual Machine
+
+1.2.2.  Terminology
+
+   This document uses the terminology defined in [RFC7665] and
+   [RFC8300], and readers are expected to be familiar with it.
+
+2.  SFC Layering Model
+
+   Multiple layers come into play for implementing the SFC.  These
+   include the service layer and the underlying layers (network layer,
+   link layer, etc.).
+
+   *  The service layer consists of SFC data-plane elements that include
+      classifiers, Service Functions (SFs), Service Function Forwarders
+      (SFF), and SFC Proxies.  This layer uses the overlay network layer
+      for ensuring connectivity between SFC data-plane elements.
+
+   *  The overlay network layer leverages various overlay network
+      technologies (e.g., Virtual eXtensible Local Area Network (VXLAN))
+      for interconnecting SFC data-plane elements and allows
+      establishing Service Function Paths (SFPs).  This layer is mostly
+      transparent to the SFC data-plane elements, as not all the data-
+      plane elements process the overlay header.
+
+   *  The underlay network layer is dictated by the networking
+      technology deployed within a network (e.g., IP, MPLS).
+
+   *  The link layer is tightly coupled with the physical technology
+      used.  Ethernet is one such choice for this layer, but other
+      alternatives may be deployed (e.g., POS and DWDM).  In a virtual
+      environment, virtualized I/O technologies, such as Single Root I/O
+      Virtualization (SR-IOV) or similar, are also applicable for this
+      layer.  The same or distinct link layer technologies may be used
+      in each leg shown in Figure 1.
+
+
+      o----------------------Service Layer----------------------o
+
+   +------+   +---+   +---+   +---+   +---+   +---+   +---+   +---+
+   |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7|
+   |fier  |   +---+   +---+   +---+   +---+   +---+   +---+   +---+
+   +------+
+                <------VM1------>       <--VM2-->       <--VM3-->
+
+      ^-----------------^-------------------^---------------^  Overlay
+                                                               Network
+
+      o-----------------o-------------------o---------------o  Underlay
+                                                               Network
+
+      o--------o--------o--------o----------o-------o-------o  Link
+
+                       Figure 1: SFC Layering Example
+
+   In Figure 1, the service-layer elements, such as classifier and SF,
+   are depicted as virtual entities that are interconnected using an
+   overlay network.  The underlay network may comprise multiple
+   intermediate nodes not shown in the figure that provide underlay
+   connectivity between the service-layer elements.
+
+   While Figure 1 depicts an example where SFs are enabled as virtual
+   entities, the SFC architecture does not make any assumptions on how
+   the SFC data-plane elements are deployed.  The SFC architecture is
+   flexible and accommodates physical or virtual entity deployment.  SFC
+   OAM accounts for this flexibility, and accordingly it is applicable
+   whether SFC data-plane elements are deployed directly on physical
+   hardware, as one or more virtual entities, or any combination
+   thereof.
+
+3.  SFC OAM Components
+
+   The SFC operates at the service layer.  For the purpose of defining
+   the OAM framework, the service layer is broken up into three distinct
+   components:
+
+   SF component:
+      OAM functions applicable at this component include testing the SFs
+      from any SFC-aware network device (e.g., classifiers, controllers,
+      and other service nodes).  Testing an SF may be more expansive
+      than just checking connectivity to the SF, such as checking if the
+      SF is providing its intended service.  Refer to Section 3.1.1 for
+      a more detailed discussion.
+
+   SFC component:
+      OAM functions applicable at this component include (but are not
+      limited to) testing the SFCs and the SFPs, validation of the
+      correlation between an SFC and the actual forwarding path followed
+      by a packet matching that SFC, i.e., the Rendered Service Path
+      (RSP).  Some of the hops of an SFC may not be visible when
+      Hierarchical Service Function Chaining (hSFC) [RFC8459] is in use.
+      In such schemes, it is the responsibility of the Internal Boundary
+      Node (IBN) to glue the connectivity between different levels for
+      end-to-end OAM functionality.
+
+   Classifier component:
+      OAM functions applicable at this component include testing the
+      validity of the classification rules and detecting any incoherence
+      among the rules installed when more than one classifier is used,
+      as explained in Section 2.2 of [RFC7665].
+
+   Figure 2 illustrates an example where OAM for the three defined
+   components are used within the SFC environment.
+
+
+ +-Classifier  +-Service Function Chain OAM
+ | OAM         |
+ |             |        ___________________________________________
+ |              \      /\          Service Function Chain          \
+ |               \    /  \      +---+      +---+     +-----+  +---+ \
+ |                \  /    \     |SF1|      |SF2|     |Proxy|--|SF3|  \
+ |      +------+   \/      \    +---+      +---+     +-----+  +---+   \
+ +----> |      |...(+->     )     |          |         |               )
+        |Classi|    \      /   +-----+    +-----+    +-----+          /
+        |fier  |     \    /    | SFF1|----| SFF2|----| SFF3|         /
+        |      |      \  /     +--^--+    +-----+    +-----+        /
+        +----|-+       \/_________|________________________________/
+             |                    |
+             +-------SF_OAM-------+
+                                      +---+   +---+
+                              +SF_OAM>|SF3|   |SF5|
+                              |       +-^-+   +-^-+
+                       +------|---+     |       |
+                       |Controller|     +-SF_OAM+
+                       +----------+
+                            Service Function OAM (SF_OAM)
+
+                      Figure 2: SFC OAM Components
+
+   It is expected that multiple SFC OAM solutions will be defined, each
+   targeting one specific component of the service layer.  However, it
+   is critical that SFC OAM solutions together provide the coverage of
+   all three SFC OAM components: the SF component, the SFC component,
+   and the classifier component.
+
+3.1.  The SF Component
+
+3.1.1.  SF Availability
+
+   One SFC OAM requirement for the SF component is to allow an SFC-aware
+   network device to check the availability of a specific SF (instance),
+   located on the same or different network device(s).  For cases where
+   multiple instances of an SF are used to realize a given SF for the
+   purpose of load sharing, SF availability can be performed by checking
+   the availability of any one of those instances, or the availability
+   check may be targeted at a specific instance.  SF availability is an
+   aspect that raises an interesting question: How does one determine
+   that an SF is available?  At one end of the spectrum, one might argue
+   that an SF is sufficiently available if the service node (physical or
+   virtual) hosting the SF is available and is functional.  At the other
+   end of the spectrum, one might argue that the SF's availability can
+   only be deduced if the packet, after passing through the SF, was
+   examined and it was verified that the packet did indeed get the
+   expected service.
+
+   The former approach will likely not provide sufficient confidence
+   about the actual SF availability, i.e., a service node and an SF are
+   two different entities.  The latter approach is capable of providing
+   an extensive verification but comes at a cost.  Some SFs make direct
+   modifications to packets, while others do not.  Additionally, the
+   purpose of some SFs may be to drop certain packets intentionally.  In
+   such cases, it is normal behavior that certain packets will not be
+   egressing out from the SF.  The OAM mechanism needs to take into
+   account such SF specifics when assessing SF availability.  Note that
+   there are many flavors of SFs available and many more that are likely
+   be introduced in the future.  Even a given SF may introduce a new
+   functionality (e.g., a new signature in a firewall).  The cost of
+   this approach is that the OAM mechanism for some SF will need to be
+   continuously modified in order to "keep up" with new functionality
+   being introduced.
+
+   The SF availability check can be performed using a generalized
+   approach, i.e., at an adequate granularity to provide a basic SF
+   service.  The task of evaluating the true availability of an SF is a
+   complex activity, currently having no simple, unified solution.
+   There is currently no standard means of doing so.  Any such mechanism
+   would be far from a typical OAM function, so it is not explored as
+   part of the analysis in Sections 4 and 5.
+
+3.1.2.  SF Performance Measurement
+
+   The second SFC OAM requirement for the SF component is to allow an
+   SFC-aware network device to check the performance metrics, such as
+   loss and delay induced by a specific SF for processing legitimate
+   traffic.  Performance measurement can be passive by using live
+   traffic, an active measurement by using synthetic probe packets, or a
+   hybrid method that uses a combination of active and passive
+   measurement.  More details about this OAM function is explained in
+   Section 4.4.
+
+   On the one hand, the performance of any specific SF can be quantified
+   by measuring the loss and delay metrics of the traffic from the SFF
+   to the respective SF, while on the other hand, the performance can be
+   measured by leveraging the loss and delay metrics from the respective
+   SFs.  The latter requires SF involvement to perform the measurement,
+   while the former does not.  For cases where multiple instances of an
+   SF are used to realize a given SF for the purpose of load sharing, SF
+   performance can be quantified by measuring the metrics for any one
+   instance of SF or by measuring the metrics for a specific instance.
+
+   The metrics measured to quantify the performance of the SF component
+   are not just limited to loss and delay.  Other metrics, such as
+   throughput, also exist and the choice of metrics for performance
+   measurement is outside the scope of this document.
+
+3.2.  The SFC Component
+
+3.2.1.  SFC Availability
+
+   An SFC could comprise varying SFs, and so the OAM layer is required
+   to perform validation and verification of SFs within an SFP, in
+   addition to connectivity verification and fault isolation.
+
+   In order to perform service connectivity verification of an SFC/SFP,
+   the OAM functions could be initiated from any SFC-aware network
+   device of an SFC-enabled domain for end-to-end paths, or partial
+   paths terminating on a specific SF, within the SFC/SFP.  The goal of
+   this OAM function is to ensure the SFs chained together have
+   connectivity, as was intended at the time when the SFC was
+   established.  The necessary return codes should be defined for
+   sending back in the response to the OAM packet, in order to complete
+   the verification.
+
+   When ECMP is in use at the service layer for any given SFC, there
+   must be the ability to discover and traverse all available paths.
+
+   A detailed explanation of the mechanism is outside the scope of this
+   document and is expected to be included in the actual solution
+   document.
+
+3.2.2.  SFC Performance Measurement
+
+   Any SFC-aware network device should have the ability to make
+   performance measurements over the entire SFC (i.e., end-to-end) or on
+   a specific segment of SFs within the SFC.
+
+3.3.  Classifier Component
+
+   A classifier maintains the classification rules that map a flow to a
+   specific SFC.  It is vital that the classifier is correctly
+   configured with updated classification rules and is functioning as
+   expected.  The SFC OAM must be able to validate the classification
+   rules by assessing whether a flow is appropriately mapped to the
+   relevant SFC and detect any misclassification.  Sample OAM packets
+   can be presented to the classifiers to assess the behavior with
+   regard to a given classification entry.
+
+   The classifier availability check may be performed to check the
+   availability of the classifier to apply the rules and classify the
+   traffic flows.  Any SFC-aware network device should have the ability
+   to perform availability checking of the classifier component for each
+   SFC.
+
+   Any SFC-aware network device should have the ability to perform
+   performance measurement of the classifier component for each SFC.
+   The performance can be quantified by measuring the performance
+   metrics of the traffic from the classifier for each SFC/SFP.
+
+3.4.  Underlay Network
+
+   The underlay network provides connectivity between the SFC
+   components, so the availability or the performance of the underlay
+   network directly impacts the SFC OAM.
+
+   Any SFC-aware network device may have the ability to perform an
+   availability check or performance measurement of the underlay network
+   using any existing OAM functions listed in Section 5.1.
+
+3.5.  Overlay Network
+
+   The overlay network provides connectivity for the service plane
+   between the SFC components and is mostly transparent to the SFC data-
+   plane elements.
+
+   Any SFC-aware network device may have the ability to perform an
+   availability check or performance measurement of the overlay network
+   using any existing OAM functions listed in Section 5.1.
+
+4.  SFC OAM Functions
+
+   Section 3 described SFC OAM components and the associated OAM
+   operations on each of them.  This section explores SFC OAM functions
+   that are applicable for more than one SFC component.
+
+   The various SFC OAM requirements listed in Section 3 highlight the
+   need for various OAM functions at the service layer.  As listed in
+   Section 5.1, various OAM functions are in existence that are defined
+   to perform OAM functionality at different layers.  In order to apply
+   such OAM functions at the service layer, they need to be enhanced to
+   operate on a single SF/SFF or multiple SFs/SFFs spanning across one
+   or more SFCs.
+
+4.1.  Connectivity Functions
+
+   Connectivity is mainly an on-demand function to verify that
+   connectivity exists between certain network elements and that the SFs
+   are available.  For example, Label Switched Path (LSP) Ping [RFC8029]
+   is a common tool used to perform this function for an MPLS network.
+   Some of the OAM functions performed by connectivity functions are as
+   follows:
+
+   *  Verify the Path MTU from a source to the destination SF or through
+      the SFC.  This requires the ability for the OAM packet to be of
+      variable length.
+
+   *  Detect any packet reordering and corruption.
+
+   *  Verify that an SFC or SF is applying the expected policy.
+
+   *  Verify and validate forwarding paths.
+
+   *  Proactively test alternate or protected paths to ensure
+      reliability of network configurations.
+
+4.2.  Continuity Functions
+
+   Continuity is a model where OAM messages are sent periodically to
+   validate or verify the reachability of a given SF within an SFC or
+   for the entire SFC.  This allows a monitoring network device (such as
+   the classifier or controller) to quickly detect failures, such as
+   link failures, network element failures, SF outages, or SFC outages.
+   BFD [RFC5880] is one such protocol that helps in detecting failures
+   quickly.  OAM functions supported by continuity functions are as
+   follows:
+
+   *  Provision a continuity check to a given SF within an SFC or for
+      the entire SFC.
+
+   *  Proactively test alternate or protected paths to ensure
+      reliability of network configurations.
+
+   *  Notifying other OAM functions or applications of the detected
+      failures so they can take appropriate action.
+
+4.3.  Trace Functions
+
+   Tracing is an OAM function that allows the operation to trigger an
+   action (e.g., response generation) from every transit device (e.g.,
+   SFF, SF, and SFC Proxy) on the tested layer.  This function is
+   typically useful for gathering information from every transit device
+   or for isolating the failure point to a specific SF within an SFC or
+   for an entire SFC.  Some of the OAM functions supported by trace
+   functions are:
+
+   *  the ability to trigger an action from every transit device at the
+      SFC layer, using TTL or other means,
+
+   *  the ability to trigger every transit device at the SFC layer to
+      generate a response with OAM code(s) using TTL or other means,
+
+   *  the ability to discover and traverse ECMP paths within an SFC, and
+
+   *  the ability to skip SFs that do not support OAM while tracing SFs
+      in an SFC.
+
+4.4.  Performance Measurement Functions
+
+   Performance measurement functions involve measuring of packet loss,
+   delay, delay variance, etc.  These performance metrics may be
+   measured proactively or on demand.
+
+   SFC OAM should provide the ability to measure packet loss for an SFC.
+   On-demand measurement can be used to estimate packet loss using
+   statistical methods.  To ensure accurate estimations, one needs to
+   ensure that OAM packets are treated the same and also share the same
+   fate as regular data traffic.
+
+   Delay within an SFC could be measured based on the time it takes for
+   a packet to traverse the SFC from the ingress SFC node to the egress
+   SFF.  Measurement protocols, such as the One-Way Active Measurement
+   Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement
+   Protocol (TWAMP) [RFC5357], can be used to measure delay
+   characteristics.  As SFCs are unidirectional in nature, measurement
+   of one-way delay [RFC7679] is important.  In order to measure one-way
+   delay, time synchronization must be supported by means such as NTP,
+   GPS, Precision Time Protocol (PTP), etc.
+
+   One-way delay variation [RFC3393] could also be calculated by sending
+   OAM packets and measuring the jitter for traffic passing through an
+   SFC.
+
+   Some of the OAM functions supported by the performance measurement
+   functions are:
+
+   *  the ability to measure the packet processing delay induced by a
+      single SF or the one-way delay to traverse an SFP bound to a given
+      SFC, and
+
+   *  the ability to measure the packet loss [RFC7680] within an SF or
+      an SFP bound to a given SFC.
+
+5.  Gap Analysis
+
+   This section identifies various OAM functions available at different
+   layers introduced in Section 2.  It also identifies various gaps that
+   exist within the current toolset for performing OAM functions
+   required for SFC.
+
+5.1.  Existing OAM Functions
+
+   There are various OAM toolsets available to perform OAM functions
+   within various layers.  These OAM functions may be used to validate
+   some of the underlay and overlay networks.  Tools like ping and trace
+   are in existence to perform connectivity checks and trace
+   intermediate hops in a network.  These tools support different
+   network types, like IP, MPLS, TRILL, etc.  Ethernet OAM (E-OAM)
+   [Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] offer
+   OAM mechanisms, such as a continuity check for Ethernet links.  There
+   is an effort around NVO3 OAM to provide connectivity and continuity
+   checks for networks that use NVO3.  BFD is used for the detection of
+   data-plane forwarding failures.  The IPPM framework [RFC2330] offers
+   tools such as OWAMP [RFC4656] and TWAMP [RFC5357] (collectively
+   referred to as IPPM in this section) to measure various performance
+   metrics.  MPLS Packet Loss Measurement (LM) and Packet Delay
+   Measurement (DM) (collectively referred to as MPLS_PM in this
+   section) [RFC6374] offer the ability to measure performance metrics
+   in MPLS networks.  There is also an effort to extend the toolset to
+   provide connectivity and continuity checks within overlay networks.
+   BFD is another tool that helps in detecting data forwarding failures.
+   Table 1 below is not exhaustive.
+
+
+     +============+==============+============+=======+=============+
+     | Layer      | Connectivity | Continuity | Trace | Performance |
+     +============+==============+============+=======+=============+
+     | Underlay   | Ping         | E-OAM, BFD | Trace | IPPM,       |
+     | network    |              |            |       | MPLS_PM     |
+     +------------+--------------+------------+-------+-------------+
+     | Overlay    | Ping         | BFD, NVO3  | Trace | IPPM        |
+     | network    |              | OAM        |       |             |
+     +------------+--------------+------------+-------+-------------+
+     | Classifier | Ping         | BFD        | Trace | None        |
+     +------------+--------------+------------+-------+-------------+
+     | SF         | None         | None       | None  | None        |
+     +------------+--------------+------------+-------+-------------+
+     | SFC        | None         | None       | None  | None        |
+     +------------+--------------+------------+-------+-------------+
+
+                      Table 1: OAM Tool Gap Analysis
+
+5.2.  Missing OAM Functions
+
+   As shown in Table 1, there are no standards-based tools available at
+   the time of this writing that can be used natively (i.e., without
+   enhancement) for the verification of SFs and SFCs.
+
+5.3.  Required OAM Functions
+
+   Primary OAM functions exist for underlying layers.  Tools like ping,
+   trace, BFD, etc. exist in order to perform these OAM functions.
+
+   As depicted in Table 1, toolsets and solutions are required to
+   perform the OAM functions at the service layer.
+
+6.  Operational Aspects of SFC OAM at the Service Layer
+
+   This section describes the operational aspects of SFC OAM at the
+   service layer to perform the SFC OAM function defined in Section 4
+   and analyzes the applicability of various existing OAM toolsets in
+   the service layer.
+
+6.1.  SFC OAM Packet Marker
+
+   SFC OAM messages should be encapsulated with the necessary SFC header
+   and with OAM markings when testing the SFC component.  SFC OAM
+   messages may be encapsulated with the necessary SFC header and with
+   OAM markings when testing the SF component.
+
+   The SFC OAM function described in Section 4 performed at the service
+   layer or overlay network layer must mark the packet as an OAM packet
+   so that relevant nodes can differentiate OAM packets from data
+   packets.  The base header defined in Section 2.2 of [RFC8300] assigns
+   a bit to indicate OAM packets.  When NSH encapsulation is used at the
+   service layer, the O bit must be set to differentiate the OAM packet.
+   Any other overlay encapsulations used at the service layer must have
+   a way to mark the packet as an OAM packet.
+
+6.2.  OAM Packet Processing and Forwarding Semantic
+
+   Upon receiving an OAM packet, an SFC-aware SF may choose to discard
+   the packet if it does not support OAM functionality or if the local
+   policy prevents it from processing the OAM packet.  When an SF
+   supports OAM functionality, it is desirable to process the packet and
+   provide an appropriate response to allow end-to-end verification.  To
+   limit performance impact due to OAM, SFC-aware SFs should rate-limit
+   the number of OAM packets processed.
+
+   An SFF may choose to not forward the OAM packet to an SF if the SF
+   does not support OAM or if the policy does not allow the forwarding
+   of OAM packets to that SF.  The SFF may choose to skip the SF, modify
+   the packet's header, and forward the packet to the next SFC node in
+   the chain.  It should be noted that skipping an SF might have
+   implications on some OAM functions (e.g., the delay measurement may
+   not be accurate).  The method by which an SFF detects if the
+   connected SF supports or is allowed to process OAM packets is outside
+   the scope of this document.  It could be a configuration parameter
+   instructed by the controller, or it can be done by dynamic
+   negotiation between the SF and SFF.
+
+   If the SFF receiving the OAM packet bound to a given SFC is the last
+   SFF in the chain, it must send a relevant response to the initiator
+   of the OAM packet.  Depending on the type of OAM solution and toolset
+   used, the response could be a simple response (such as ICMP reply) or
+   could include additional data from the received OAM packet (like
+   statistical data consolidated along the path).  The details are
+   expected to be covered in the solution documents.
+
+   Any SFC-aware node that initiates an OAM packet must set the OAM
+   marker in the overlay encapsulation.
+
+6.3.  OAM Function Types
+
+   As described in Section 4, there are different OAM functions that may
+   require different OAM solutions.  While the presence of the OAM
+   marker in the overlay header (e.g., O bit in the NSH header)
+   indicates it as an OAM packet, it is not sufficient to indicate what
+   OAM function the packet is intended for.  The Next Protocol field in
+   the NSH header may be used to indicate what OAM function is intended
+   or what toolset is used.  Any other overlay encapsulations used at
+   the service layer must have a similar way to indicate the intended
+   OAM function.
+
+7.  Candidate SFC OAM Tools
+
+   As described in Section 5.1, there are different toolsets available
+   to perform OAM functions at different layers.  This section describe
+   the applicability of some of the available toolsets in the service
+   layer.
+
+7.1.  ICMP
+
+   [RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6
+   networks respectively.  It explains how ICMP messages can be used to
+   test the network reachability between different end points and
+   perform basic network diagnostics.
+
+   ICMP could be leveraged for connectivity functions (defined in
+   Section 4.1) to verify the availability of an SF or SFC.  The
+   initiator can generate an ICMP echo request message and control the
+   service-layer encapsulation header to get the response from the
+   relevant node.  For example, a classifier initiating OAM can generate
+   an ICMP echo request message, set the TTL field in the NSH header
+   [RFC8300] to 63 to get the response from the last SFF, and thereby
+   test the SFC availability.  Alternatively, the initiator can set the
+   TTL to some other value to get the response from a specific SF and
+   thereby partially test SFC availability, or the initiator could send
+   OAM packets with sequentially incrementing TTL in the NSH to trace
+   the SFP.
+
+   It could be observed that ICMP as currently defined may not be able
+   to perform all required SFC OAM functions, but as explained above, it
+   can be used for some of the connectivity functions.
+
+7.2.  BFD / Seamless BFD
+
+   [RFC5880] defines the Bidirectional Forwarding Detection (BFD)
+   mechanism for failure detection.  [RFC5881] and [RFC5884] define the
+   applicability of BFD in IPv4, IPv6, and MPLS networks.  [RFC7880]
+   defines Seamless BFD (S-BFD), a simplified mechanism of using BFD.
+   [RFC7881] explains its applicability in IPv4, IPv6, and MPLS
+   networks.
+
+   BFD or S-BFD could be leveraged to perform the continuity function
+   for SF or SFC.  An initiator could generate a BFD control packet and
+   set the "Your Discriminator" value in the control packet to identify
+   the last SFF.  Upon receiving the control packet, the last SFF in the
+   SFC will reply back with the relevant DIAG code.  The TTL field in
+   the NSH header could be used to perform a partial SFC availability
+   check.  For example, the initiator can set the "Your Discriminator"
+   value to identify the SF that is intended to be tested and set the
+   TTL field in the NSH header in a way that it expires at the relevant
+   SF.  How the initiator gets the Discriminator value to identify the
+   SF is outside the scope of this document.
+
+7.3.  In Situ OAM
+
+   [IOAM-NSH] defines how In situ OAM data fields [IPPM-IOAM-DATA] are
+   transported using the NSH header.  [PROOF-OF-TRANSIT] defines a
+   mechanism to perform proof of transit to securely verify if a packet
+   traversed the relevant SFP or SFC.  While the mechanism is defined
+   inband (i.e., it will be included in data packets), IOAM Option-
+   Types, such as IOAM Trace Option-Types, can also be used to perform
+   other SFC OAM functions, such as SFC tracing.
+
+   In situ OAM could be leveraged to perform SF availability and SFC
+   availability or performance measurement.  For example, if SFC is
+   realized using NSH, the O bit in the NSH header could be set to
+   indicate the OAM traffic, as defined in Section 4.2 of [IOAM-NSH].
+
+7.4.  SFC Traceroute
+
+   [SFC-TRACE] defines a protocol that checks for path liveliness and
+   traces the service hops in any SFP.  Section 3 of [SFC-TRACE] defines
+   the SFC trace packet format, while Sections 4 and 5 of [SFC-TRACE]
+   define the behavior of SF and SFF respectively.  While [SFC-TRACE]
+   has expired, the proposal is implemented in Open Daylight and is
+   available.
+
+   An initiator can control the Service Index Limit (SIL) in an SFC
+   trace packet to perform SF and SFC availability tests.
+
+8.  Manageability Considerations
+
+   This document does not define any new manageability tools but
+   consolidates the manageability tool gap analysis for SF and SFC.
+   Table 2 below is not exhaustive.
+
+
+   +===========+===============+===============+========+==============+
+   |Layer      | Configuration | Orchestration |Topology|Notification  |
+   +===========+===============+===============+========+==============+
+   |Underlay   | CLI, NETCONF  | CLI, NETCONF  |SNMP    |SNMP, Syslog, |
+   |network    |               |               |        |NETCONF       |
+   +-----------+---------------+---------------+--------+--------------+
+   |Overlay    | CLI, NETCONF  | CLI, NETCONF  |SNMP    |SNMP, Syslog, |
+   |network    |               |               |        |NETCONF       |
+   +-----------+---------------+---------------+--------+--------------+
+   |Classifier | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
+   +-----------+---------------+---------------+--------+--------------+
+   |SF         | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
+   +-----------+---------------+---------------+--------+--------------+
+   |SFC        | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
+   +-----------+---------------+---------------+--------+--------------+
+
+                       Table 2: OAM Tool Gap Analysis
+
+   Configuration, orchestration, and other manageability tasks of SF and
+   SFC could be performed using CLI, NETCONF [RFC6241], etc.
+
+   While the NETCONF capabilities are readily available, as depicted in
+   Table 2, the information and data models are needed for
+   configuration, manageability, and orchestration for SFC.  With
+   virtualized SF and SFC, manageability needs to be done
+   programmatically.
+
+9.  Security Considerations
+
+   Any security considerations defined in [RFC7665] and [RFC8300] are
+   applicable for this document.
+
+   The OAM information from the service layer at different components
+   may collectively or independently reveal sensitive information.  The
+   information may reveal the type of service functions hosted in the
+   network, the classification rules and the associated service chains,
+   specific service function paths, etc.  The sensitivity of the
+   information from the SFC layer raises a need for careful security
+   considerations.
+
+   The mapping and the rules information at the classifier component may
+   reveal the traffic rules and the traffic mapped to the SFC.  The SFC
+   information collected at an SFC component may reveal the SFs
+   associated within each chain, and this information together with
+   classifier rules may be used to manipulate the header of synthetic
+   attack packets that may be used to bypass the SFC and trigger any
+   internal attacks.
+
+   The SF information at the SF component may be used by a malicious
+   user to trigger a Denial of Service (DoS) attack by overloading any
+   specific SF using rogue OAM traffic.
+
+   To address the above concerns, SFC and SF OAM should provide
+   mechanisms for mitigating:
+
+   *  misuse of the OAM channel for denial of services,
+
+   *  leakage of OAM packets across SFC instances, and
+
+   *  leakage of SFC information beyond the SFC domain.
+
+   The documents proposing the OAM solution for SF components should
+   provide rate-limiting the OAM probes at a frequency guided by the
+   implementation choice.  Rate-limiting may be applied at the
+   classifier, SFF, or the SF.  The OAM initiator may not receive a
+   response for the probes that are rate-limited resulting in false
+   negatives, and the implementation should be aware of this.  To
+   mitigate any attacks that leverage OAM packets, future documents
+   proposing OAM solutions should describe the use of any technique to
+   detect and mitigate anomalies and various security attacks.
+
+   The documents proposing the OAM solution for any service-layer
+   components should consider some form of message filtering to control
+   the OAM packets entering the administrative domain or prevent leaking
+   any internal service-layer information outside the administrative
+   domain.
+
+10.  IANA Considerations
+
+   This document has no IANA actions.
+
+11.  Informative References
+
+   [DOT1Q]    IEEE, "IEEE Standard for Local and metropolitan area
+              networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
+              DOI 10.1109/IEEESTD.2014.6991462, November 2014,
+              <https://doi.org/10.1109/IEEESTD.2014.6991462>.
+
+   [EFM]      IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018,
+              DOI 10.1109/IEEESTD.2018.8457469, June 2018,
+              <https://doi.org/10.1109/IEEESTD.2018.8457469>.
+
+   [IOAM-NSH] Brockners, F. and S. Bhandari, "Network Service Header
+              (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in
+              Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16
+              June 2020,
+              <https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-04>.
+
+   [IPPM-IOAM-DATA]
+              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
+              for In-situ OAM", Work in Progress, Internet-Draft, draft-
+              ietf-ippm-ioam-data-10, 13 July 2020,
+              <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-
+              10>.
+
+   [PROOF-OF-TRANSIT]
+              Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
+              Youell, "Proof of Transit", Work in Progress, Internet-
+              Draft, draft-ietf-sfc-proof-of-transit-06, 16 June 2020,
+              <https://tools.ietf.org/html/draft-ietf-sfc-proof-of-
+              transit-06>.
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, DOI 10.17487/RFC0792, September 1981,
+              <https://www.rfc-editor.org/info/rfc792>.
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              DOI 10.17487/RFC2330, May 1998,
+              <https://www.rfc-editor.org/info/rfc2330>.
+
+   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
+              Metric for IP Performance Metrics (IPPM)", RFC 3393,
+              DOI 10.17487/RFC3393, November 2002,
+              <https://www.rfc-editor.org/info/rfc3393>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", STD 89,
+              RFC 4443, DOI 10.17487/RFC4443, March 2006,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
+              Zekauskas, "A One-way Active Measurement Protocol
+              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
+              <https://www.rfc-editor.org/info/rfc4656>.
+
+   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
+              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
+              RFC 5357, DOI 10.17487/RFC5357, October 2008,
+              <https://www.rfc-editor.org/info/rfc5357>.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <https://www.rfc-editor.org/info/rfc5880>.
+
+   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
+              DOI 10.17487/RFC5881, June 2010,
+              <https://www.rfc-editor.org/info/rfc5881>.
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
+              June 2010, <https://www.rfc-editor.org/info/rfc5884>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
+              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
+              Acronym in the IETF", BCP 161, RFC 6291,
+              DOI 10.17487/RFC6291, June 2011,
+              <https://www.rfc-editor.org/info/rfc6291>.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374,
+              DOI 10.17487/RFC6374, September 2011,
+              <https://www.rfc-editor.org/info/rfc6374>.
+
+   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
+              Service Function Chaining", RFC 7498,
+              DOI 10.17487/RFC7498, April 2015,
+              <https://www.rfc-editor.org/info/rfc7498>.
+
+   [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>.
+
+   [RFC7679]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
+              Ed., "A One-Way Delay Metric for IP Performance Metrics
+              (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
+              2016, <https://www.rfc-editor.org/info/rfc7679>.
+
+   [RFC7680]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
+              Ed., "A One-Way Loss Metric for IP Performance Metrics
+              (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
+              2016, <https://www.rfc-editor.org/info/rfc7680>.
+
+   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
+              Pallagatti, "Seamless Bidirectional Forwarding Detection
+              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
+              <https://www.rfc-editor.org/info/rfc7880>.
+
+   [RFC7881]  Pignataro, C., Ward, D., and N. Akiya, "Seamless
+              Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
+              and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
+              <https://www.rfc-editor.org/info/rfc7881>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [SFC-TRACE]
+              Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
+              "Services Function Chaining Traceroute", Work in Progress,
+              Internet-Draft, draft-penno-sfc-trace-03, 30 September
+              2015,
+              <https://tools.ietf.org/html/draft-penno-sfc-trace-03>.
+
+   [Y.1731]   ITU-T, "G.8013: Operations, administration and maintenance
+              (OAM) functions and mechanisms for Ethernet-based
+              networks", August 2015,
+              <https://www.itu.int/rec/T-REC-G.8013-201508-I/en>.
+
+Acknowledgements
+
+   We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky,
+   Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados,
+   Martin Duke, Barry Leiba, Éric Vyncke, Roman Danyliw, Erik Kline,
+   Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray
+   Kucherawy, and Alissa Cooper for their review and comments.
+
+Contributors
+
+   Nobo Akiya
+   Ericsson
+
+   Email: nobo.akiya.dev@gmail.com
+
+
+Authors' Addresses
+
+   Sam K. Aldrin
+   Google
+
+   Email: aldrin.ietf@gmail.com
+
+
+   Carlos Pignataro (editor)
+   Cisco Systems, Inc.
+
+   Email: cpignata@cisco.com
+
+
+   Nagendra Kumar (editor)
+   Cisco Systems, Inc.
+
+   Email: naikumar@cisco.com
+
+
+   Ram Krishnan
+   VMware
+
+   Email: ramkri123@gmail.com
+
+
+   Anoop Ghanwani
+   Dell
+
+   Email: anoop@alumni.duke.edu