<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="info" consensus="true"
     docName="draft-ietf-sfc-oam-framework-15" ipr="trust200902"> number="8924" ipr="trust200902"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4"
     symRefs="true" sortRefs="true" version="3">

  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" xml2rfc v2v3 conversion 2.46.0 -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="SFC OAM Framework">
Service Framework">Service Function Chaining (SFC) Operations,&nbsp;Administration&nbsp;and&nbsp;Maintenance&nbsp;(OAM) Framework
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->
    Operations, Administration, and Maintenance (OAM)
    Framework</title>
    <seriesInfo name="RFC" value="8924"/>

    <author fullname="Sam K. Aldrin" initials="S." surname="Aldrin">
      <organization>Google</organization>
      <address>
        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>
    <author role="editor" fullname="Carlos Pignataro" initials="C." surname="Pignataro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>
    <author role="editor" fullname="Nagendra Kumar" initials="N." surname="Kumar">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <email>naikumar@cisco.com</email>
      </address>
    </author>
    <author fullname="Ram Krishnan" initials="R." surname="Krishnan">
      <organization>VMware</organization>
      <address>
        <email>ramkri123@gmail.com</email>
      </address>
    </author>
    <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
      <organization>Dell</organization>
      <address>
        <email>anoop@alumni.duke.edu</email>
      </address>
    </author>
    <date  />

    <area>SFC Working Group</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
    IETF is fine for individual submissions.
	If this element is not present, the default is "Network Working Group",
    which is used by the RFC Editor as a nod to the history of the IETF. --> year="2020" month="October"/>
    <area>RTG</area>
    <workgroup>SFC</workgroup>

    <keyword>SFC</keyword>
    <keyword>OAM</keyword>
    <keyword>Framework</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document provides a reference framework for Operations, Administration
      Administration, and Maintenance (OAM) for Service Function Chaining
      (SFC).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Service Function Chaining (SFC) enables the creation of composite
      services that consist of an ordered set of Service Functions (SF) (SFs) that
      are to be applied to any traffic selected as a result of classification
      <xref target="RFC7665" />. format="default"/>. 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:

<list style="symbols">

<t>SFC
      documents:</t>
      <ul spacing="normal">
        <li>SFC Problem Statement <xref target="RFC7498" /></t>
<t>SFC format="default"/></li>
        <li>SFC Architecture <xref target="RFC7665" /></t>

</list>

 The format="default"/></li>
      </ul>
      <t>The reader is assumed to be familiar with the material in <xref
      target="RFC7665" />.
</t><t>

This format="default"/>.</t>
      <t>This document provides a reference framework for Operations, Administration
      Administration, and Maintenance (OAM, (OAM) <xref target="RFC6291" />)
      format="default"/> of SFC. Specifically, this document provides:

<list style="symbols">

<t>In <xref target="_SFC_Layer" />, an provides:</t>
      <ul spacing="normal">
        <li>an SFC layering model;</t>
<t>In <xref target="_SFC_OAM_Comp" />, aspects model (<xref target="_SFC_Layer" format="default"/>),</li>
        <li>aspects monitored by SFC OAM;</t>
<t>In <xref target="_SFC_OAM_Func" />, functional OAM (<xref target="_SFC_OAM_Comp"
	format="default"/>),</li>
        <li>functional requirements for SFC OAM;</t>
<t>In <xref target="_Gap" />, a OAM (<xref
	target="_SFC_OAM_Func" format="default"/>),</li>
        <li>a gap analysis for SFC OAM.</t>
<t>In <xref target="OPS_ASPECTS" />, operational OAM (<xref target="_Gap" format="default"/>),</li>
        <li>operational aspects of SFC OAM at the service layer.</t>
<t>In <xref target="_SFC_OAM_MODEL" />, applicability layer (<xref
	target="OPS_ASPECTS" format="default"/>),</li>
        <li>applicability of various OAM tools.</t>
<t>In <xref target="Manageability" />, manageability tools (<xref
	target="_SFC_OAM_MODEL" format="default"/>), and</li>
        <li>manageability considerations for SF and SFC. </t>

</list>

</t> SFC (<xref
	target="Manageability" format="default"/>). </li>
      </ul>
      <t>SFC OAM solution documents should refer to this document to indicate
      the SFC OAM component and the functionality they target.
</t> target.</t>
      <t>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.
</t> SFC-enabled domain.</t>
      <section title="Document Scope"> numbered="true" toc="default">
        <name>Document Scope</name>
        <t>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.</t>
      </section>
      <section title="Acronyms numbered="true" toc="default">
        <name>Acronyms and Terminology"> Terminology</name>
        <section title="Acronyms">
    		<t>SFC:		Service Function Chain</t>
    		<t>SFF:		Service Function Forwarder</t>
    		<t>SF:		Service Function</t>
    		<t>SFP: numbered="true" toc="default">
          <name>Acronyms</name>
	  <dl newline="false" spacing="normal" indent="11">
          <dt>BFD</dt>
	  <dd>Bidirectional Forwarding Detection</dd>
          <dt>CLI</dt>
	  <dd>Command-Line Interface</dd>
          <dt>DWDM</dt>
	  <dd>Dense Wavelength Division Multiplexing</dd>
          <dt>E-OAM</dt>
	  <dd>Ethernet OAM</dd>
          <dt>hSFC</dt>
	  <dd>Hierarchical Service Function Path</t>
    		<t>RSP:		Rendered Service Path</t>
    		<t>NSH:		Network Service Header</t>
    		<t>VM:		Virtual Machines</t>
    		<t>OAM:		Operations, Administration and Maintenance</t>
    		<t>IPPM:	IP Chaining</dd>
          <dt>IBN</dt>
	  <dd>Internal Boundary Node</dd>
          <dt>IPPM</dt>
	  <dd>IP Performance Measurement</t>
    		<t>BFD:		Bidirectional Forwarding Detection</t>
    		<t>NVO3:	Network Metrics</dd>
          <dt>MPLS</dt>
	  <dd>Multiprotocol Label Switching</dd>
          <dt>MPLS_PM</dt>
	  <dd>MPLS Performance Measurement</dd>
          <dt>NETCONF</dt>
	  <dd>Network Configuration Protocol</dd>
          <dt>NSH</dt>
	  <dd>Network Service Header</dd>
          <dt>NVO3</dt>
	  <dd>Network Virtualization over Layer3</t>
    		<t>SNMP:	Simple Network Management Protocol</t>
    		<t>NETCONF:	Network Configuration Protocol</t>
    		<t>E-OAM:	Ethernet OAM</t>
    		<t>MPLS_PM:	MPLS Performance Measurement</t>
    		<t>POS:	    Packet Layer 3</dd>
          <dt>OAM</dt>
	  <dd>Operations, Administration, and Maintenance</dd>
          <dt>POS</dt>
	  <dd>Packet over SONET</t>
    		<t>DWDM:   	Dense Wavelength Division Multiplexing</t>
    		<t>hSFC:   	Hierarchical SONET</dd>
          <dt>RSP</dt>
	  <dd>Rendered Service Path</dd>
          <dt>SF</dt>
	  <dd>Service Function</dd>
          <dt>SFC</dt>
	  <dd>Service Function Chaining</t>
    		<t>IBN:    	Internal Boundary Node</t>
    		<t>MPLS:    Multiprotocol Label Switching</t>
    		<t>TRILL:   Transparent Chain</dd>
          <dt>SFF</dt>
	  <dd>Service Function Forwarder</dd>
          <dt>SFP</dt>
	  <dd>Service Function Path</dd>
          <dt>SNMP</dt>
	  <dd>Simple Network Management Protocol</dd>
          <dt>TRILL</dt>
	  <dd>Transparent Interconnection of Lots of Links</t>
    		<t>CLI:     Command Line Interface</t> Links</dd>
          <dt>VM</dt>
	  <dd>Virtual Machine</dd>

	  </dl>
        </section>
        <section title="Terminology"> numbered="true" toc="default">
          <name>Terminology</name>
          <t>This document uses the terminologies terminology defined in <xref
	  target="RFC7665" />, format="default"/> and <xref target="RFC8300" />,
	  format="default"/>, and so the readers are expected to be familiar
	  with the terminologies.
    	</t> it.</t>
        </section>
      </section>
    </section>
    <section title="SFC anchor="_SFC_Layer" numbered="true" toc="default">
      <name>SFC Layering Model" anchor="_SFC_Layer"> Model</name>
      <t>Multiple layers come into play for implementing the SFC. These
      include the service layer and the underlying layers (Network Layer, Link Layer, etc.).

<list style="symbols">

<t>The service (network layer, which link
      layer, etc.).</t>
      <ul spacing="normal">
        <li>The service layer consists of SFC data plane data-plane elements that includes
	include classifiers, Service Functions (SF), (SFs), Service Function
	Forwarders (SFF), and SFC Proxies. This layer uses the overlay network
	layer for ensuring connectivity between SFC data plane elements.</t>

<t>The data-plane elements.</li>
        <li>The overlay network layer, which layer leverages various overlay network
	technologies (e.g., VxLAN)interconnecting Virtual eXtensible Local Area Network
	(VXLAN)) for interconnecting SFC data plane data-plane elements and
	allows establishing Service Function Paths (SFPs). This layer is
	mostly transparent to the SFC data plane elements data-plane elements, as not all the data plane data-plane elements process the overlay header.</t>

<t>The header.</li>
        <li>The underlay network layer, which layer is dictated by the networking
	technology deployed within a network (e.g., IP, MPLS)</t>

<t>The MPLS).</li>
        <li>The link layer, which layer is tightly coupled with the physical
	technology used. Ethernet is one such choice for this layer, but other
	alternatives are may be deployed (e.g. POS, (e.g., POS and DWDM). In a virtual environment,
	virtualized I/O technologies technologies, such as SR-IOV Single Root I/O Virtualization
	(SR-IOV) or similar similar, are also
	applicable for this layer. The same or distinct link layer
	technologies may be used in each leg shown in Figure 1.</t>

</list> <xref
	target="SFC-example"/>.</li>
      </ul>
      <t keepWithNext="true"/>
      <figure align="left"><preamble></preamble><artwork align="left"><![CDATA[ anchor="SFC-example">
	<name>SFC Layering Example</name>
      <artwork align="left" name="" type="" alt=""><![CDATA[
   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
]]></artwork></figure>

</t>
]]></artwork>
      </figure>
      <t>In Figure 1, <xref target="SFC-example"/>, the service layer elements service-layer elements, such as
      classifier and SF 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.
</t> service-layer elements.</t>
      <t>While Figure 1 <xref target="SFC-example"/> depicts an example where SFs are
      enabled as virtual entities, the SFC architecture does not make any
      assumptions on how the SFC data plane SFC data-plane elements are deployed. The SFC
      architecture is flexible and accommodates physical or virtual entity
      deployment. SFC OAM accounts for this flexibility flexibility, and accordingly it is
      applicable whether SFC data plane data-plane elements are deployed directly on
      physical hardware, as one or more Virtual virtual entities, or any combination thereof.
</t>
      thereof.</t>
    </section>
    <section title="SFC anchor="_SFC_OAM_Comp" numbered="true" toc="default">
      <name>SFC OAM Components" anchor="_SFC_OAM_Comp"> Components</name>
      <t>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:

<list style="numbers">

<t>SF component: OAM
      components:</t>
      <dl newline="true" spacing="normal">
        <dt>SF component:</dt>
	<dd>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 SF, such as checking if the SF
	is providing its intended service. Refer to Section 3.1.1 <xref target="SF-avail"/>
	for a more detailed discussion.</t>

<t>SFC component: OAM discussion.</dd>
        <dt>SFC component:</dt>
	<dd>OAM functions applicable at this component include
	(but are not limited to) testing the service function chains 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. i.e., the
	Rendered Service Path (RSP). Some of the hops of an SFC may not be
	visible when Hierarchical Service Function Chaining (hSFC) <xref
	target="RFC8459" /> format="default"/> 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.</t>

<t>Classifier component: OAM
	functionality.</dd>
        <dt>Classifier component:</dt>
	<dd>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 used, as explained in Section 2.2 of <xref
	target="RFC7665" /> .</t>

</list>

Figure 2 sectionFormat="of" section="2.2"/>.</dd>
      </dl>
      <t><xref target="SFC-OAM"/> illustrates an example where OAM for the
      three defined components are used within the SFC environment. environment.</t>
      <t keepWithNext="true"/>
      <figure align="left"><preamble></preamble><artwork align="left"><![CDATA[ anchor="SFC-OAM">
	<name>SFC OAM Components</name>
      <artwork align="left" name="" type="" alt=""><![CDATA[
+-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
]]></artwork></figure>

It
]]></artwork>

      </figure>
      <t>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.</t>
      <section title="The numbered="true" toc="default">
        <name>The SF Component"> Component</name>
        <section title="SF Availability"> anchor="SF-avail" numbered="true" toc="default">
          <name>SF Availability</name>
          <t>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 a service function an SF is available?  On  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.  On  At the other end of the spectrum,
	  one might argue that the SF's availability can only be concluded deduced if
	  the packet, after passing through the SF, was examined and it was
	  verified that the packet did indeed get the expected service.</t>
          <t>The former approach will likely not provide sufficient confidence to
	  about the actual SF availability, i.e. i.e., a service node and an SF are two
	  different entities.  The latter approach is capable of providing an
	  extensive verification, 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, conditionally, to drop certain packets
	  intentionally.  In such cases, it is normal behavior that certain
	  packets will not be egressing out from the service function. 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,
	  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 &quot;keep up&quot; "keep up" with new functionality being introduced: lack of extensibility.</t> introduced.</t>
          <t>The SF availability check can be performed using a generalized approach (i.e.,
	  approach, i.e., at an adequate granularity to provide a basic SF service).
	  service.  The task of evaluating the true availability of a Service Function 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 <xref
	  target="_SFC_OAM_Func" format="counter"/> and 5.</t> <xref target="_Gap"
	  format="counter"/>.</t>
        </section>
        <section title="SF numbered="true" toc="default">
          <name>SF Performance Measurement"> Measurement</name>
          <t>The second SFC OAM requirement for the SF component is to allow
	  an SFC-aware network device to check the performance metrics metrics, such as
	  loss and delay induced by a specific SF for processing legitimate
	  traffic. The performance Performance measurement can be a passive measurement by using live
	  traffic, an active measurement by using synthetic probe packets packets, or can be
	  a hybrid method that use uses a combination of active and passive
	  measurement. More details about this OAM function is explained in Section 4.4.
	</t>
	  <xref target="Perform_Funct"/>.</t>
          <t>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 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.
	</t> instance.</t>
          <t>The metrics measured to quantify the performance of the SF
	  component are not just limited to loss and delay. Other metrics metrics, such
	  as throughput throughput, also exist and the choice of metrics for performance
	  measurement is outside the scope of this document.
	</t> document.</t>
        </section>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The SFC Component"> Component</name>
        <section title="SFC Availability"> numbered="true" toc="default">
          <name>SFC Availability</name>
          <t>An SFC could comprise varying SFs 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.</t>
          <t>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
	  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.</t>
          <t>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.</t>
          <t>A detailed explanation of the mechanism is outside the scope of
	  this document and is expected to be included in the actual solution
	  document.</t>
        </section>
        <section title="SFC numbered="true" toc="default">
          <name>SFC Performance Measurement"> Measurement</name>
          <t>Any SFC-aware network device should have the ability to make
	  performance measurements over the entire SFC (i.e., end-to-end) or to
	  on a specific segment of SFs within the SFC.</t>
        </section>
      </section>
      <section title="Classifier Component"> numbered="true" toc="default">
        <name>Classifier Component</name>
        <t>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.</t>
        <t>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. </t>
        <t>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.
</t> SFC/SFP.</t>
      </section>
      <section title="Underlay Network"> numbered="true" toc="default">
        <name>Underlay Network</name>
        <t>The underlay network provides connectivity between the SFC components
	components, so the availability or the performance of the underlay
	network directly impacts the SFC OAM.
	</t> OAM.</t>

        <t>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.
	</t> 5.1.</t>
      </section>
      <section title="Overlay Network"> numbered="true" toc="default">
        <name>Overlay Network</name>
        <t>The overlay network provides connectivity for the service plane between
	the SFC components and is mostly transparent to the SFC data plane elements.
	</t> data-plane
	elements.</t>
        <t>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.
	</t> <xref
	target="_Exist_FUNC"/>.</t>
      </section>
    </section>
    <section title="SFC anchor="_SFC_OAM_Func" numbered="true" toc="default">
      <name>SFC OAM Functions" anchor="_SFC_OAM_Func"> Functions</name>
      <t><xref target="_SFC_OAM_Comp" /> format="default"/> 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.</t>
      <t>The various SFC OAM requirements listed in <xref
      target="_SFC_OAM_Comp" /> highlighted format="default"/> highlight the need for
      various OAM functions at the service layer. As listed in Section 5.1, <xref target="_Exist_FUNC"/>,
      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 to or multiple SFs/SFFs spanning across one or more SFCs.</t>
      <section title="Connectivity Functions"> anchor="Connect_Func" numbered="true" toc="default">
        <name>Connectivity Functions</name>
        <t>Connectivity is mainly an on-demand function to verify that the
	connectivity exists between certain network elements and that the SFs
	are available. For example, LSP Label Switched Path (LSP) Ping <xref target="RFC8029" />
	format="default"/> 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:

<list style="symbols">

<t>Verify follows:</t>
        <ul spacing="normal">
          <li>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.</t>

<t>Detect length.</li>
          <li>Detect any packet re-ordering reordering and corruption.</t>

<t>Verify corruption.</li>
          <li>Verify that an SFC or SF is applying the expected policy.</t>

<t>Verification policy.</li>
          <li>Verify and validation of validate forwarding paths.</t>

<t>Proactively paths.</li>
          <li>Proactively test alternate or protected paths to ensure
	  reliability of network configurations.</t>

</list>

</t> configurations.</li>
        </ul>
      </section>
      <section title="Continuity Functions"> numbered="true" toc="default">
        <name>Continuity Functions</name>
        <t>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 failures, such as link
	failures, network element failures, SF outages, or SFC outages. BFD
	<xref target="RFC5880" /> format="default"/> is one such function which protocol that
	helps in detecting failures quickly. OAM functions supported by
	continuity functions are as follows:

<list style="symbols">

<t>Ability to provision follows:</t>
        <ul spacing="normal">
          <li>Provision a continuity check to a given SF within an
	  SFC or for the entire SFC.</t>

<t>Proactively SFC.</li>
          <li>Proactively test alternate or protected paths to ensure
	  reliability of network configurations.</t>

<t>Notifying configurations.</li>
          <li>Notifying other OAM functions or applications of the detected
	  failures so they can take appropriate action.</t>

</list>

</t> action.</li>
        </ul>
      </section>
      <section title="Trace Functions"> numbered="true" toc="default">
        <name>Trace Functions</name>
        <t>Tracing is an OAM function that allows the operation to trigger an
	action (e.g. (e.g., response generation) from every transit device (e.g. (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:

<list style="symbols">

<t>Ability are:</t>
        <ul spacing="normal">
          <li>the ability to trigger an action from every transit device at the
	  SFC layer, using TTL or other means.</t>

<t>Ability means,</li>
          <li>the ability to trigger every transit device at the SFC layer to
	  generate a response with OAM code(s), code(s) using TTL or other means.</t>

<t>Ability means,</li>
          <li>the ability to discover and traverse ECMP paths within an SFC.</t>

<t>Ability SFC, and</li>
          <li>the ability to skip SFs that do not support OAM while tracing SFs in an SFC.</t>

</list>

</t> SFC.</li>
        </ul>
      </section>
      <section title="Performance anchor="Perform_Funct" numbered="true" toc="default">
        <name>Performance Measurement Functions"> Functions</name>
        <t>Performance measurement functions involve measuring of packet loss,
	delay, delay variance, etc. These performance metrics may be measured pro-actively
	proactively or on-demand.</t> on demand.</t>
        <t>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.</t>
        <t>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 protocols, such as One-way the One-Way Active Measurement
	Protocol (OWAMP) <xref target="RFC4656" /> format="default"/> and Two-way the Two-Way
	Active Measurement Protocol (TWAMP) <xref target="RFC5357" />
	format="default"/>, can be used to measure the delay characteristics. As SFCs
	are unidirectional in nature, measurement of one-way delay <xref
	target="RFC7679" /> format="default"/> 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.</t>
        <t>One-way delay variation <xref target="RFC3393" /> format="default"/>
	could also be calculated by sending OAM packets and measuring the
	jitter for traffic passing through an SFC.</t>
        <t>Some of the OAM functions supported by the performance measurement
	functions are:

<list style="symbols">

<t>Ability are:</t>
        <ul spacing="normal">
    <li>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.</t>

<t>Ability
      SFC, and</li>
          <li>the ability to measure the packet loss <xref target="RFC7680" />
	  format="default"/> within an SF or an SFP bound to a given SFC.</t>

</list>

</t> SFC.</li>
        </ul>
      </section>
    </section>
    <section title="Gap Analysis" anchor="_Gap"> anchor="_Gap" numbered="true" toc="default">
      <name>Gap Analysis</name>
      <t>This section identifies various OAM functions available at different
      layers introduced in Section 2. <xref target="_SFC_Layer"/>. It also identifies various gaps that
      exist within the current toolset for performing OAM functions required
      for SFC.</t>
      <section title="Existing anchor="_Exist_FUNC" numbered="true" toc="default">
        <name>Existing OAM Functions" anchor="_Exist_FUNC"> Functions</name>
        <t>There are various OAM tool sets 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 check checks and tracing of trace
	intermediate hops in a network. These tools support different network types
	types, like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) <xref target="Y.1731"/>
	target="Y.1731" format="default"/> <xref target="EFM"/> target="EFM"
	format="default"/> and Connectivity Fault Management (CFM) <xref target="DOT1Q"/>
	target="DOT1Q" format="default"/> offer OAM
mechanisms mechanisms, such as an Ethernet 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 data-plane
	forwarding failures. The IPPM framework <xref target="RFC2330" />
	format="default"/> offers tools such as OWAMP <xref target="RFC4656" />
	format="default"/> and TWAMP <xref target="RFC5357" /> format="default"/>
	(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) <xref target="RFC6374" /> offers format="default"/> offer the ability
	to measure performance metrics in MPLS network. networks. There is also an
	effort to extend the tool set toolset to provide connectivity and continuity
	checks within overlay networks. BFD is another tool which that helps in
	detecting data forwarding failures. Table 3 <xref target="OAM-Analysis"/>
	below is not exhaustive.

<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
                 Table 3: OAM exhaustive.</t>
        <t keepWithNext="true"/>
<table anchor="OAM-Analysis" align="center">
 <name>OAM Tool GAP Analysis
+----------------+--------------+-------------+--------+------------+
| Layer          | Connectivity |  Continuity |  Trace | Performance|
+----------------+--------------+-------------+--------+------------+
| Underlay N/w   | Ping         |E-OAM, BFD   |  Trace | IPPM,      |
|                |              |             |        | MPLS_PM    |
+----------------+--------------+-------------+--------+------------+
| Overlay N/w    | Ping         | BFD,        |        |            |
|                |              | Gap Analysis</name>
 <thead>
   <tr>
     <th>Layer</th>
     <th>Connectivity</th>
     <th>Continuity</th>
     <th>Trace</th>
     <th>Performance</th>
   </tr>
 </thead>
 <tbody>
   <tr>
     <td>Underlay network</td>
     <td>Ping</td>
     <td>E-OAM, BFD</td>
     <td>Trace</td>
     <td>IPPM, MPLS_PM</td>
   </tr>
   <tr>
     <td>Overlay network</td>
     <td>Ping</td>
     <td>BFD, NVO3 OAM    | Trace  | IPPM       |
+----------------+--------------+-------------+--------+------------+
| Classifier     | Ping         | BFD         | Trace  | None       |
+----------------+--------------+-------------+--------+------------+
| SF             | None         | None        | None   | None       |
+----------------+--------------+-------------+--------+------------+
| SFC            | None         | None        | None   | None       |
+----------------+--------------+-------------+--------+------------+

]]></artwork></figure>

</t> OAM</td>
     <td>Trace</td>
     <td>IPPM</td>
   </tr>
   <tr>
     <td>Classifier</td>
     <td>Ping</td>
     <td>BFD</td>
     <td>Trace</td>
     <td>None</td>
   </tr>
   <tr>
     <td>SF</td>
     <td>None</td>
     <td>None</td>
     <td>None</td>
     <td>None</td>
   </tr>
   <tr>
     <td>SFC</td>
     <td>None</td>
     <td>None</td>
     <td>None</td>
     <td>None</td>
   </tr>
 </tbody>
</table>
      </section>
      <section title="Missing numbered="true" toc="default">
        <name>Missing OAM Functions"> Functions</name>
        <t>As shown in Table 3, <xref target="OAM-Analysis"/>, there are no
	standards-based tools available
	at the time of this writing that can be used natively (i.e. (i.e., without
	enhancement) for the verification of SFs and SFCs.</t>
      </section>
      <section title="Required numbered="true" toc="default">
        <name>Required OAM Functions"> Functions</name>
        <t>Primary OAM functions exist for underlying layers. Tools like ping,
	trace, BFD, etc. exist in order to perform these OAM functions.</t>
        <t>As depicted in Table 3, <xref target="OAM-Analysis"/>, toolsets and solutions are required to
	perform the OAM functions at the service layer.
</t> layer.</t>
      </section>
    </section>
    <section title="Operational anchor="OPS_ASPECTS" numbered="true" toc="default">
      <name>Operational Aspects of SFC OAM at the Service Layer" anchor="OPS_ASPECTS"> Layer</name>
      <t>This section describes the operational aspects of SFC OAM at the
      service layer to perform the SFC OAM function defined in <xref
      target="_SFC_OAM_Func" /> format="default"/> and analyzes the applicability
      of various existing OAM toolsets in the service layer.
	</t> layer.</t>
      <section title="SFC numbered="true" toc="default">
        <name>SFC OAM Packet Marker"> Marker</name>
        <t>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.
		</t> component.</t>
        <t>The SFC OAM function described in <xref target="_SFC_OAM_Func" />
	format="default"/> performed at the service layer or overlay network
	layer must mark the packet as an OAM packet so that relevant nodes can
	differentiate an OAM packet packets from data packets. The base header defined
	in Section 2.2 of <xref target="RFC8300" /> sectionFormat="of" section="2.2"/> 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.
		</t> packet.</t>
      </section>
      <section title="OAM numbered="true" toc="default">
        <name>OAM Packet Processing and Forwarding Semantic"> Semantic</name>
        <t>Upon receiving an OAM packet, an SFC-aware SFs SF may choose to discard
	the packet if it does not support OAM functionality or if the local
	policy prevents them 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 rate-limit
	the number of OAM packets processed. </t>
        <t>An SFF may choose not to not forward the OAM packet to an SF if the SF
	does not support OAM or if the policy does not allow to forward the forwarding of OAM
	packets to an that SF. The SFF may choose to skip the SF, modify the header
	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. (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 controller, or it can be done
	by dynamic negotiation between the SF and SFF.
		</t> SFF.</t>
        <t>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 tool set
	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.
		</t> documents.</t>
        <t>Any SFC-aware node that initiates an OAM packet must set the OAM
	marker in the overlay encapsulation.
		</t> encapsulation.</t>
      </section>
      <section title="OAM numbered="true" toc="default">
        <name>OAM Function Types"> Types</name>
        <t>As described in <xref target="_SFC_OAM_Func" />, format="default"/>,
	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.

		</t> function.</t>
      </section>
    </section>
    <section title="Candidate anchor="_SFC_OAM_MODEL" numbered="true" toc="default">
      <name>Candidate SFC OAM Tools" anchor="_SFC_OAM_MODEL"> Tools</name>
      <t>As described in <xref target="_Exist_FUNC" />, format="default"/>, there
      are different tool sets toolsets available to perform  OAM functions at different
      layers. This section describe the applicability of some of the available
      toolsets in the service layer.
		</t> layer.</t>
      <section title="ICMP"> numbered="true" toc="default">
        <name>ICMP</name>
        <t><xref target="RFC0792" /> format="default"/> and <xref
	target="RFC4443" /> format="default"/> 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.
			</t> diagnostics.</t>
        <t>ICMP could be leveraged for connectivity functions (defined in Section 4.1)
	<xref target="Connect_Func"/>) to verify the availability of an SF or
	SFC. The Initiator initiator
	can generate an ICMP echo request message and control the service layer 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, can set the TTL field in the NSH header <xref
	target="RFC8300" /> format="default"/> 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 SFs SF and thereby partially test SFC availability availability, or the
	initiator could send OAM packets with sequentially incrementing TTL in
	the NSH to trace the SFP.
			</t> SFP.</t>
        <t>It could be observed that ICMP at its current stage 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.
			</t> functions.</t>
      </section>
      <section title="BFD/Seamless-BFD"> numbered="true" toc="default">
        <name>BFD / Seamless BFD</name>
        <t><xref target="RFC5880" /> format="default"/> defines the Bidirectional
	Forwarding Detection (BFD) mechanism for failure detection. <xref
	target="RFC5881" /> format="default"/> and <xref target="RFC5884" />
	format="default"/> define the applicability of BFD in IPv4, IPv6 IPv6, and
	MPLS networks. <xref target="RFC7880" /> format="default"/> defines
	Seamless BFD (S-BFD), a simplified mechanism of using BFD. <xref
	target="RFC7881" /> format="default"/> explains its applicability in
	IPv4, IPv6 IPv6, and MPLS network.
			</t> networks.</t>
        <t>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 in the control packet. 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.
			</t> document.</t>
      </section>
      <section title="In-Situ OAM"> numbered="true" toc="default">
        <name>In Situ OAM</name>

        <t><xref target="I-D.ietf-sfc-ioam-nsh" /> format="default"/> defines how In-Situ
	In situ OAM data fields <xref target="I-D.ietf-ippm-ioam-data" />
	format="default"/> are transported using the NSH header. <xref
	target="I-D.ietf-sfc-proof-of-transit" /> format="default"/> 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), IOA Option-Types IOAM Option-Types,
	such as IOAM Trace Option-Types Option-Types, can also be used to perform other SFC
	OAM function functions, such as SFC tracing.
			</t>

			<t>In-Situ tracing.</t>
        <t>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 O bit in the NSH header could be set to
	indicate the OAM traffic traffic, as defined in Section 4.2 <xref
	target="I-D.ietf-sfc-ioam-nsh" />.
			</t> sectionFormat="of" section="4.2"/>.</t>
      </section>
      <section title="SFC Traceroute"> numbered="true" toc="default">
        <name>SFC Traceroute</name>
        <t><xref target="I-D.penno-sfc-trace" /> format="default"/> defines a
	protocol that checks for path liveliness and traces the service hops
	in any SFP. Section 3 of <xref target="I-D.penno-sfc-trace" />
	sectionFormat="of" section="3"/> defines the SFC trace packet format format,
	while Sections 4 <xref target="I-D.penno-sfc-trace" section="4"
	sectionFormat="bare"/> and 5 of <xref target="I-D.penno-sfc-trace" />  defines
	section="5" sectionFormat="bare"/> of <xref target="I-D.penno-sfc-trace"/>
	define the behavior of SF and SFF respectively. While <xref
	target="I-D.penno-sfc-trace" /> format="default"/> has expired, the
	proposal is implemented in Open Daylight and is available.
			</t> available.</t>
        <t>An initiator can control the Service Index Limit (SIL) in an SFC trace
	packet to perform SF and SFC availability test.
			</t> tests.</t>
      </section>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This document does not define any new manageability tools but
      consolidates the manageability tool gap analysis for SF and SFC. Table 4 <xref
      target="OAM-Analysis-2"/> below is not exhaustive.
	</t>
	<t>
<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
                 Table 4: OAM exhaustive.</t>
      <t keepWithNext="true"/>
<table anchor="OAM-Analysis-2" align="center">
  <name>OAM Tool GAP Analysis
+----------------+--------------+-------------+--------+-------------+
| Layer          |Configuration |Orchestration|Topology|Notification |
+----------------+--------------+-------------+--------+-------------+
| Underlay N/w   |CLI, NETCONF  | CLI, NETCONF| SNMP   |SNMP, Syslog,|
|                |              |             |        |NETCONF      |
+----------------+--------------+-------------+--------+-------------+
| Overlay N/w    |CLI, NETCONF  | CLI, NETCONF| SNMP   |SNMP, Syslog |
|                |              |             |        |NETCONF      |
+----------------+--------------+-------------+--------+-------------+
| Classifier     |CLI, NETCONF  | CLI, NETCONF| None   | None        |
+----------------+--------------+-------------+--------+-------------+
| SF             |CLI, NETCONF  | CLI, NETCONF| None   | None        |
+----------------+--------------+-------------+--------+-------------+
| SFC            |CLI, NETCONF  | CLI, NETCONF| None   | None        |
+----------------+--------------+-------------+--------+-------------+

]]></artwork></figure>
	</t> Gap Analysis</name>
  <thead>
    <tr>
      <th>Layer</th>
      <th>Configuration</th>
      <th>Orchestration</th>
      <th>Topology</th>
      <th>Notification</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Underlay network</td>
      <td>CLI, NETCONF</td>
      <td>CLI, NETCONF</td>
      <td>SNMP</td>
      <td>SNMP, Syslog, NETCONF</td>
    </tr>
    <tr>
      <td>Overlay network</td>
      <td>CLI, NETCONF</td>
      <td>CLI, NETCONF</td>
      <td>SNMP</td>
      <td>SNMP, Syslog, NETCONF</td>
    </tr>
    <tr>
      <td>Classifier</td>
      <td>CLI, NETCONF</td>
      <td>CLI, NETCONF</td>
      <td>None</td>
      <td>None</td>
    </tr>
    <tr>
      <td>SF</td>
      <td>CLI, NETCONF</td>
      <td>CLI, NETCONF</td>
      <td>None</td>
      <td>None</td>
    </tr>
    <tr>
      <td>SFC</td>
      <td>CLI, NETCONF</td>
      <td>CLI, NETCONF</td>
      <td>None</td>
      <td>None</td>
    </tr>
  </tbody>
</table>
      <t>Configuration, orchestration orchestration, and other manageability tasks of SF and
      SFC could be performed using CLI, NETCONF <xref target="RFC6241" /> , etc.
	</t>
      format="default"/>, etc.</t>
      <t>While the NETCONF capabilities are readily available available, as depicted in Table 4,
      <xref target="OAM-Analysis-2"/>, the information and data models are
      needed for configuration, manageability manageability, and orchestration for SFC. With
      virtualized SF and SFC, manageability needs to be done programmatically.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Any security considerations defined in <xref target="RFC7665" />
      format="default"/> and <xref target="RFC8300" /> is format="default"/> are
      applicable for this document.
</t> document.</t>
      <t>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.
</t>
      considerations.</t>
      <t>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 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.
</t> attacks.</t>
      <t>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.
</t> traffic.</t>
      <t>To address the above concerns, SFC and SF OAM should provide
      mechanisms for mitigating:

<list style="symbols">
<t>Misuse mitigating:</t>
      <ul spacing="normal">
        <li>misuse of the OAM channel for denial-of-services,</t>
<t>Leakage denial of services,</li>
        <li>leakage of OAM packets across SFC instances, and</t>
<t>Leakage and</li>
        <li>leakage of SFC information beyond the SFC domain.</t>
</list>

</t> domain.</li>
      </ul>
      <t>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 classifier,
      SFF, or the SF . SF. The OAM initiator may not receive a response for the
      probes that are rate-limited resulting in false negatives 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.
</t> attacks.</t>
      <t>The documents proposing the OAM solution for any service layer 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 service-layer information outside the administrative domain.
</t>
      domain.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">

      <t>No action is required by numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA for this document.</t>

    </section>

    <section title="Acknowledgements">

      <t>We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, Tal
      Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados, Martin Duke, Barry Leiba, Eric Vyncke, Roman Danyliw, Erik Kline, Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray Kucherawy, and Alissa Cooper for their review and comments.</t>

    </section>

    <section title="Contributing Authors">
		<t>Nobo Akiya
    <vspace blankLines="0" />
	Ericsson
    <vspace blankLines="0" />
    Email: nobo.akiya.dev@gmail.com</t> actions.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>

<displayreference target="I-D.ietf-sfc-proof-of-transit" to="PROOF-OF-TRANSIT"/>
<displayreference target="I-D.ietf-sfc-ioam-nsh" to="IOAM-NSH"/>
<displayreference target="I-D.ietf-ippm-ioam-data" to="IPPM-IOAM-DATA"/>
<displayreference target="I-D.penno-sfc-trace" to="SFC-TRACE"/>

    <!-- References split into informative and normative -->

    <references title="Informative References">
	  <?rfc include="reference.RFC.2330"?>
	  <?rfc include="reference.RFC.0792"?>
	  <?rfc include="reference.RFC.3393"?>
	  <?rfc include="reference.RFC.7665"?>
      <?rfc include="reference.RFC.8300"?>
	  <?rfc include="reference.RFC.4443"?>
	  <?rfc include="reference.RFC.4656"?>
	  <?rfc include="reference.RFC.5357"?>
	  <?rfc include="reference.RFC.6374"?>
	  <?rfc include="reference.RFC.6241"?>
	  <?rfc include="reference.RFC.7498"?>
	  <?rfc include="reference.RFC.7680"?>
	  <?rfc include="reference.RFC.7679"?>
	  <?rfc include="reference.RFC.8459"?>
	  <?rfc include="reference.RFC.6291"?>
	  <?rfc include="reference.RFC.5880"?>
	  <?rfc include="reference.RFC.5881"?>
      <?rfc include="reference.RFC.5884"?>
      <?rfc include="reference.RFC.7880"?>
      <?rfc include="reference.RFC.7881"?>
      <?rfc include="reference.RFC.8029"?>
	  <?rfc include="reference.I-D.ietf-sfc-proof-of-transit"?>
	  <?rfc include="reference.I-D.ietf-sfc-ioam-nsh"?>
	  <?rfc include="reference.I-D.ietf-ippm-ioam-data"?>
	  <?rfc include="reference.I-D.penno-sfc-trace"?>

    <references>
      <name>Informative References</name>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7498.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8459.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5884.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7881.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>

      <xi:include
	  href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-proof-of-transit.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-ioam-nsh.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ippm-ioam-data.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.penno-sfc-trace.xml"/>

      <reference anchor="Y.1731" target="https://www.itu.int/rec/T-REC-G.8013-201508-I/en">
        <front>
    <title>OAM Functions
          <title>G.8013: Operations, administration and maintenance (OAM)
	  functions and mechanisms for Ethernet based Ethernet-based networks</title>
    <author><organization>ITU-T</organization></author>
    <date/>
          <author>
            <organization>ITU-T</organization>
          </author>
          <date month="August" year="2015"/>
        </front>
      </reference>

      <reference anchor="EFM">
        <front>
          <title>IEEE Standard for Ethernet (Clause 57 for Operations,
              Administration, and Maintenance), IEEE Std 802.3-2018,
              June 2018</title>
    <author><organization>IEEE</organization></author>
    <date/> Ethernet</title>
          <author>
            <organization>IEEE</organization>
          </author>
          <date month="June" year="2018"/>
        </front>
	<seriesInfo name="IEEE" value="802.3-2018"/>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
      </reference>

      <reference anchor="DOT1Q">
        <front>
    <title>Standard
          <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges metropolitan area
	  networks--Bridges and Bridged Networks, IEEE Std 802.1Q-2014, November 2014</title>
    <author><organization>IEEE</organization></author>
    <date/> Networks</title>
          <author>
            <organization>IEEE</organization>
          </author>
          <date month="November" year="2014"/>
        </front>
	<seriesInfo name="IEEE" value="802.1Q-2014"/>
	<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6991462"/>
      </reference>
    </references>

    <!-- Change Log
v00-a 2014-06-28a Nobo: Initial version
    -->

    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We would like to thank <contact fullname="Mohamed Boucadair"/>,
      <contact fullname="Adrian Farrel"/>, <contact fullname="Greg Mirsky"/>,
      <contact fullname="Tal Mizrahi"/>, <contact fullname="Martin
      Vigoureux"/>, <contact fullname="Tirumaleswar Reddy"/>, <contact
      fullname="Carlos Bernados"/>, <contact fullname="Martin Duke"/>,
      <contact fullname="Barry Leiba"/>, <contact fullname="Éric Vyncke"/>,
      <contact fullname="Roman Danyliw"/>, <contact fullname="Erik Kline"/>,
      <contact fullname="Benjamin Kaduk"/>, <contact fullname="Robert
      Wilton"/>, <contact fullname="Frank Brockner"/>, <contact
      fullname="Alvaro Retana"/>, <contact fullname="Murray Kucherawy"/>,
      and <contact fullname="Alissa Cooper"/> for their review and comments.</t>
    </section>
    <section numbered="false" toc="default">
      <name>Contributors</name>
      <contact fullname="Nobo Akiya">
        <organization>Ericsson</organization>
        <address>
	  <email>nobo.akiya.dev@gmail.com</email>
	</address>
      </contact>
    </section>
  </back>
</rfc>