Diff: rfc8924xml2.original.xml

	rfc8924xml2.original.xml	rfc8924.xml

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


	<!-- used by XSLT processors -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	<!-- For a complete list and description of processing instructions (PIs),	category="info" consensus="true"
	please see http://xml.resource.org/authoring/README.html. -->	docName="draft-ietf-sfc-oam-framework-15" number="8924" ipr="trust200902"
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds	obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4"
	might want to use.	symRefs="true" sortRefs="true" version="3">
	(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 -->


	<rfc category="info" docName="draft-ietf-sfc-oam-framework-15" ipr="trust200902"	<!-- xml2rfc v2v3 conversion 2.46.0 -->
	>
	<!-- 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)" -->

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

	<front>	<front>

	<title abbrev="SFC OAM Framework">	<title abbrev="SFC OAM Framework">Service Function Chaining (SFC)
	Service Function Chaining (SFC) Operations, Administration and Ma	Operations, Administration, and Maintenance (OAM)
	intenance (OAM) Framework	Framework</title>
	</title>	<seriesInfo name="RFC" value="8924"/>

	<!-- add 'role="editor"' below for the editors if appropriate -->
	<!-- Another author who claims to be an editor -->


	<author fullname="Sam K. Aldrin" initials="S."	<author fullname="Sam K. Aldrin" initials="S." surname="Aldrin">
	surname="Aldrin">
	<organization>Google</organization>	<organization>Google</organization>
	<address>	<address>
	<email>aldrin.ietf@gmail.com</email>	<email>aldrin.ietf@gmail.com</email>
	</address>	</address>
	</author>	</author>

		<author role="editor" fullname="Carlos Pignataro" initials="C." surname="Pig
	<author role="editor" fullname="Carlos Pignataro" initials="C."	nataro">
	surname="Pignataro">
	<organization abbrev="Cisco">Cisco Systems, Inc.</organization>	<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
	<address>	<address>
	<email>cpignata@cisco.com</email>	<email>cpignata@cisco.com</email>
	</address>	</address>
	</author>	</author>

		<author role="editor" fullname="Nagendra Kumar" initials="N." surname="Kumar
	<author role="editor" fullname="Nagendra Kumar" initials="N."	">
	surname="Kumar">
	<organization abbrev="Cisco">Cisco Systems, Inc.</organization>	<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
	<address>	<address>
	<email>naikumar@cisco.com</email>	<email>naikumar@cisco.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Ram Krishnan" initials="R." surname="Krishnan">
	<author fullname="Ram Krishnan" initials="R."
	surname="Krishnan">
	<organization>VMware</organization>	<organization>VMware</organization>
	<address>	<address>
	<email>ramkri123@gmail.com</email>	<email>ramkri123@gmail.com</email>
	</address>	</address>
	</author>	</author>

		<author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
	<author fullname="Anoop Ghanwani" initials="A."
	surname="Ghanwani">
	<organization>Dell</organization>	<organization>Dell</organization>
	<address>	<address>
	<email>anoop@alumni.duke.edu</email>	<email>anoop@alumni.duke.edu</email>
	</address>	</address>
	</author>	</author>

		<date year="2020" month="October"/>
	<date />	<area>RTG</area>
		<workgroup>SFC</workgroup>
	<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. -->

	<keyword>SFC</keyword>	<keyword>SFC</keyword>
	<keyword>OAM</keyword>	<keyword>OAM</keyword>
	<keyword>Framework</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>	<abstract>

		<t>This document provides a reference framework for Operations,
	<t>This document provides a reference framework for Operations, Administra	Administration, and Maintenance (OAM) for Service Function Chaining
	tion and Maintenance (OAM) for Service Function Chaining (SFC).</t>	(SFC).</t>

	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

		<section 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 (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:</t>
		<ul spacing="normal">
		<li>SFC Problem Statement <xref target="RFC7498" format="default"/></li>
		<li>SFC Architecture <xref target="RFC7665" format="default"/></li>
		</ul>
		<t>The reader is assumed to be familiar with the material in <xref
		target="RFC7665" format="default"/>.</t>
		<t>This document provides a reference framework for Operations,
		Administration, and Maintenance (OAM) <xref target="RFC6291"
		format="default"/> of SFC. Specifically, this document provides:</t>
		<ul spacing="normal">
		<li>an SFC layering model (<xref target="_SFC_Layer" format="default"/>)
		,</li>
		<li>aspects monitored by SFC OAM (<xref target="_SFC_OAM_Comp"
		format="default"/>),</li>
		<li>functional requirements for SFC OAM (<xref
		target="_SFC_OAM_Func" format="default"/>),</li>
		<li>a gap analysis for SFC OAM (<xref target="_Gap" format="default"/>),
		</li>
		<li>operational aspects of SFC OAM at the service layer (<xref
		target="OPS_ASPECTS" format="default"/>),</li>
		<li>applicability of various OAM tools (<xref
		target="_SFC_OAM_MODEL" format="default"/>), and</li>
		<li>manageability considerations for SF and 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>
		<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>
		<section 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 numbered="true" toc="default">
		<name>Acronyms and Terminology</name>
		<section 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 Chaining</dd>
		<dt>IBN</dt>
		<dd>Internal Boundary Node</dd>
		<dt>IPPM</dt>
		<dd>IP Performance 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 Layer 3</dd>
		<dt>OAM</dt>
		<dd>Operations, Administration, and Maintenance</dd>
		<dt>POS</dt>
		<dd>Packet over SONET</dd>
		<dt>RSP</dt>
		<dd>Rendered Service Path</dd>
		<dt>SF</dt>
		<dd>Service Function</dd>
		<dt>SFC</dt>
		<dd>Service Function 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</dd>
		<dt>VM</dt>
		<dd>Virtual Machine</dd>


	<section title="Introduction">	</dl>
		</section>
	<t>Service Function Chaining (SFC) enables the creation of composite services th	<section numbered="true" toc="default">
	at consist of an ordered set of Service Functions (SF) that are to be applied to	<name>Terminology</name>
	any traffic selected as a result of classification <xref target="RFC7665" />. S	<t>This document uses the terminology defined in <xref
	FC is a concept that provides for more than just the application of an ordered s	target="RFC7665" format="default"/> and <xref target="RFC8300"
	et of SFs to selected traffic; rather, it describes a method for deploying SFs i	format="default"/>, and readers are expected to be familiar
	n a way that enables dynamic ordering and topological independence of those SFs	with it.</t>
	as well as the exchange of metadata between participating entities. The foundati	</section>
	ons of SFC are described in the following documents:	</section>

	<list style="symbols">

	<t>SFC Problem Statement <xref target="RFC7498" /></t>
	<t>SFC Architecture <xref target="RFC7665" /></t>

	</list>

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

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

	<list style="symbols">

	<t>In <xref target="_SFC_Layer" />, an SFC layering model;</t>
	<t>In <xref target="_SFC_OAM_Comp" />, aspects monitored by SFC OAM;</t>
	<t>In <xref target="_SFC_OAM_Func" />, functional requirements for SFC OAM;</t>
	<t>In <xref target="_Gap" />, a gap analysis for SFC OAM.</t>
	<t>In <xref target="OPS_ASPECTS" />, operational aspects of SFC OAM at the servi
	ce layer.</t>
	<t>In <xref target="_SFC_OAM_MODEL" />, applicability of various OAM tools.</t>
	<t>In <xref target="Manageability" />, manageability considerations for SF and S
	FC. </t>

	</list>

	</t>

	<t>SFC OAM solution documents should refer to this document to indicate the SFC
	OAM component and the functionality they 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>

	<section title="Document Scope">

	<t>The focus of this document is to provide an architectural framework for SFC O
	AM, particularly focused on the aspect of the Operations component within OAM. A
	ctual solutions and mechanisms are outside the scope of this document.</t>

	</section>

	<section title="Acronyms and Terminology">
	<section title="Acronyms">
	<t>SFC: Service Function Chain</t>
	<t>SFF: Service Function Forwarder</t>
	<t>SF: Service Function</t>
	<t>SFP: 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 Performance Measurement</t>
	<t>BFD: Bidirectional Forwarding Detection</t>
	<t>NVO3: 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 over SONET</t>
	<t>DWDM: Dense Wavelength Division Multiplexing</t>
	<t>hSFC: Hierarchical Service Function Chaining</t>
	<t>IBN: Internal Boundary Node</t>
	<t>MPLS: Multiprotocol Label Switching</t>
	<t>TRILL: Transparent Interconnection of Lots of Links</t>
	<t>CLI: Command Line Interface</t>

	</section>

	<section title="Terminology">
	<t>This document uses the terminologies defined in <xref target="RFC7665"
	/>,
	<xref target="RFC8300" />,
	and so the readers are expected to be familiar with the terminologies.
	</t>
	</section>
	</section>	</section>

		<section anchor="_SFC_Layer" numbered="true" toc="default">
	</section>	<name>SFC Layering Model</name>
		<t>Multiple layers come into play for implementing the SFC. These
	<section title="SFC Layering Model" anchor="_SFC_Layer">	include the service layer and the underlying layers (network layer, link
		layer, etc.).</t>
	<t>Multiple layers come into play for implementing the SFC. These include the se	<ul spacing="normal">
	rvice layer and the underlying layers (Network Layer, Link Layer, etc.).	<li>The service layer consists of SFC data-plane elements that
		include classifiers, Service Functions (SFs), Service Function
	<list style="symbols">	Forwarders (SFF), and SFC Proxies. This layer uses the overlay network
		layer for ensuring connectivity between SFC data-plane elements.</li>
	<t>The service layer, which consists of SFC data plane elements that includes cl	<li>The overlay network layer leverages various overlay network
	assifiers, Service Functions (SF), Service Function Forwarders (SFF), and SFC Pr	technologies (e.g., Virtual eXtensible Local Area Network
	oxies. This layer uses the overlay network layer for ensuring connectivity betwe	(VXLAN)) for interconnecting SFC data-plane elements and
	en SFC data plane elements.</t>	allows establishing Service Function Paths (SFPs). This layer is
		mostly transparent to the SFC data-plane elements, as not all the data-pl
	<t>The overlay network layer, which leverages various overlay network technologi	ane elements process the overlay header.</li>
	es (e.g., VxLAN)interconnecting SFC data plane elements and allows establishing	<li>The underlay network layer is dictated by the networking
	Service Function Paths (SFPs). This layer is mostly transparent to the SFC data	technology deployed within a network (e.g., IP, MPLS).</li>
	plane elements as not all the data plane elements process the overlay header.</t	<li>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 environme
	<t>The underlay network layer, which is dictated by the networking technology de	nt,
	ployed within a network (e.g., IP, MPLS)</t>	virtualized I/O technologies, such as Single Root I/O Virtualization
		(SR-IOV) or similar, are also
	<t>The link layer, which is tightly coupled with the physical technology used. E	applicable for this layer. The same or distinct link layer
	thernet is one such choice for this layer, but other alternatives are deployed (	technologies may be used in each leg shown in <xref
	e.g. POS, DWDM). In a virtual environment, virtualized I/O technologies such as	target="SFC-example"/>.</li>
	SR-IOV or similar are also applicable for this layer. The same or distinct link	</ul>
	layer technologies may be used in each leg shown in Figure 1.</t>	<t keepWithNext="true"/>
		<figure anchor="SFC-example">
	</list>	<name>SFC Layering Example</name>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
	o----------------------Service Layer----------------------o	o----------------------Service Layer----------------------o

	+------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+	+------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
	\|Classi\|---\|SF1\|---\|SF2\|---\|SF3\|---\|SF4\|---\|SF5\|---\|SF6\|---\|SF7\|	\|Classi\|---\|SF1\|---\|SF2\|---\|SF3\|---\|SF4\|---\|SF5\|---\|SF6\|---\|SF7\|
	\|fier \| +---+ +---+ +---+ +---+ +---+ +---+ +---+	\|fier \| +---+ +---+ +---+ +---+ +---+ +---+ +---+
	+------+	+------+
	<------VM1------> <--VM2--> <--VM3-->	<------VM1------> <--VM2--> <--VM3-->

	^-----------------^-------------------^---------------^ Overlay	^-----------------^-------------------^---------------^ Overlay
	Network	Network

	o-----------------o-------------------o---------------o Underlay	o-----------------o-------------------o---------------o Underlay
	Network	Network

	o--------o--------o--------o----------o-------o-------o Link	o--------o--------o--------o----------o-------o-------o Link

		]]></artwork>
	Figure 1: SFC Layering Example	</figure>
	]]></artwork></figure>	<t>In <xref target="SFC-example"/>, the service-layer elements, such as
		classifier and SF, are depicted as virtual entities that are
	</t>	interconnected using an overlay network. The underlay network may
		comprise multiple intermediate nodes not shown in the figure that
	<t>In Figure 1, the service layer elements such as classifier and SF are depicte	provide underlay connectivity between the service-layer elements.</t>
	d as virtual entities that are interconnected using an overlay network. The unde	<t>While <xref target="SFC-example"/> depicts an example where SFs are
	rlay network may comprise multiple intermediate nodes not shown in the figure th	enabled as virtual entities, the SFC architecture does not make any
	at provide underlay connectivity between the service layer elements.	assumptions on how the SFC data-plane elements are deployed. The SFC
	</t>	architecture is flexible and accommodates physical or virtual entity
		deployment. SFC OAM accounts for this flexibility, and accordingly it is
	<t>While Figure 1 depicts an example where SFs are enabled as virtual entities,	applicable whether SFC data-plane elements are deployed directly on
	the SFC architecture does not make any assumptions on how the SFC data plane ele	physical hardware, as one or more virtual entities, or any combination
	ments are deployed. The SFC architecture is flexible and accommodates physical o	thereof.</t>
	r virtual entity deployment. SFC OAM accounts for this flexibility and according	</section>
	ly it is applicable whether SFC data plane elements are deployed directly on phy	<section anchor="_SFC_OAM_Comp" numbered="true" toc="default">
	sical hardware, as one or more Virtual entities, or any combination thereof.	<name>SFC OAM Components</name>
	</t>	<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
	</section>	components:</t>
		<dl newline="true" spacing="normal">
	<section title="SFC OAM Components" anchor="_SFC_OAM_Comp">	<dt>SF component:</dt>
		<dd>OAM functions applicable at this component include
	<t>The SFC operates at the service layer. For the purpose of defining the OAM fr	testing the SFs from any SFC-aware network device (e.g., classifiers,
	amework, the service layer is broken up into three distinct components:	controllers, and other service nodes). Testing an SF may be more expansiv
		e
	<list style="numbers">	than just checking connectivity to the SF, such as checking if the SF
		is providing its intended service. Refer to <xref target="SF-avail"/>
	<t>SF component: OAM functions applicable at this component include testing the	for a more detailed discussion.</dd>
	SFs from any SFC-aware network device (e.g., classifiers, controllers, other ser	<dt>SFC component:</dt>
	vice nodes). Testing an SF may be more expansive than just checking connectivity	<dd>OAM functions applicable at this component include
	to the SF such as checking if the SF is providing its intended service. Refer t	(but are not limited to) testing the SFCs and the
	o Section 3.1.1 for a more detailed discussion.</t>	SFPs, validation of the correlation between an SFC and the actual
		forwarding path followed by a packet matching that SFC, i.e., the
	<t>SFC component: OAM functions applicable at this component include (but are no	Rendered Service Path (RSP). Some of the hops of an SFC may not be
	t limited to) testing the service function chains and the SFPs, validation of th	visible when Hierarchical Service Function Chaining (hSFC) <xref
	e correlation between an SFC and the actual forwarding path followed by a packet	target="RFC8459" format="default"/> is in use. In such schemes, it is
	matching that SFC, i.e. the Rendered Service Path (RSP). Some of the hops of an	the responsibility of the Internal Boundary Node (IBN) to glue the
	SFC may not be visible when Hierarchical Service Function Chaining (hSFC) <xref	connectivity between different levels for end-to-end OAM
	target="RFC8459" /> is in use. In such schemes, it is the responsibility of the	functionality.</dd>
	Internal Boundary Node (IBN) to glue the connectivity between different levels	<dt>Classifier component:</dt>
	for end-to-end OAM functionality.</t>	<dd>OAM functions applicable at this component
		include testing the validity of the classification rules and detecting
	<t>Classifier component: OAM functions applicable at this component include test	any incoherence among the rules installed when more than one
	ing the validity of the classification rules and detecting any incoherence among	classifier is used, as explained in <xref
	the rules installed when more than one classifier is used as explained in Secti	target="RFC7665" sectionFormat="of" section="2.2"/>.</dd>
	on 2.2 of	</dl>
	<xref target="RFC7665" /> .</t>	<t><xref target="SFC-OAM"/> illustrates an example where OAM for the
		three defined components are used within the SFC environment.</t>
	</list>	<t keepWithNext="true"/>
		<figure anchor="SFC-OAM">
	Figure 2 illustrates an example where OAM for the three defined components are u	<name>SFC OAM Components</name>
	sed within the SFC environment.	<artwork align="left" name="" type="" alt=""><![CDATA[

	<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
	+-Classifier +-Service Function Chain OAM	+-Classifier +-Service Function Chain OAM
	\| OAM \|	\| OAM \|
	\| \| ___________________________________________	\| \| ___________________________________________
	\| \ /\ Service Function Chain \	\| \ /\ Service Function Chain \
	\| \ / \ +---+ +---+ +-----+ +---+ \	\| \ / \ +---+ +---+ +-----+ +---+ \
	\| \ / \ \|SF1\| \|SF2\| \|Proxy\|--\|SF3\| \	\| \ / \ \|SF1\| \|SF2\| \|Proxy\|--\|SF3\| \
	\| +------+ \/ \ +---+ +---+ +-----+ +---+ \	\| +------+ \/ \ +---+ +---+ +-----+ +---+ \

	+----> \| \|....(+-> ) \| \| \| )	+----> \| \|...(+-> ) \| \| \| )
	\|Classi\| \ / +-----+ +-----+ +-----+ /	\|Classi\| \ / +-----+ +-----+ +-----+ /
	\|fier \| \ / \| SFF1\|----\| SFF2\|----\| SFF3\| /	\|fier \| \ / \| SFF1\|----\| SFF2\|----\| SFF3\| /
	\| \| \ / +--^--+ +-----+ +-----+ /	\| \| \ / +--^--+ +-----+ +-----+ /
	+----\|-+ \/_________\|________________________________/	+----\|-+ \/_________\|________________________________/
	\| \|	\| \|
	+-------SF_OAM-------+	+-------SF_OAM-------+
	+---+ +---+	+---+ +---+
	+SF_OAM>\|SF3\| \|SF5\|	+SF_OAM>\|SF3\| \|SF5\|
	\| +-^-+ +-^-+	\| +-^-+ +-^-+
	+------\|---+ \| \|	+------\|---+ \| \|
	\|Controller\| +-SF_OAM+	\|Controller\| +-SF_OAM+
	+----------+	+----------+
	Service Function OAM (SF_OAM)	Service Function OAM (SF_OAM)

		]]></artwork>


	Figure 2: SFC OAM Components	</figure>
	]]></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
	It is expected that multiple SFC OAM solutions will be defined, each targeting o	critical that SFC OAM solutions together provide the coverage of all
	ne specific component of the service layer. However, it is critical that SFC OAM	three SFC OAM components: the SF component, the SFC component, and the
	solutions together provide the coverage of all three SFC OAM components: the SF	classifier component.</t>
	component, the SFC component, and the classifier component.</t>	<section numbered="true" toc="default">
		<name>The SF Component</name>
	<section title="The SF Component">	<section anchor="SF-avail" numbered="true" toc="default">
		<name>SF Availability</name>
	<section title="SF Availability">	<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
	<t>One SFC OAM requirement for the SF component is to allow an SFC-aware network	(instance), located on the same or different network device(s). For
	device to check the availability of a specific SF (instance), located on the sa	cases where multiple instances of an SF are used to realize a given
	me or different network device(s). For cases where multiple instances of an SF a	SF for the purpose of load sharing, SF availability can be performed
	re used to realize a given SF for the purpose of load sharing, SF availability c	by checking the availability of any one of those instances, or the
	an be performed by checking the availability of any one of those instances, or t	availability check may be targeted at a specific instance. SF
	he availability check may be targeted at a specific instance. SF availability is	availability is an aspect that raises an interesting question: How
	an aspect that raises an interesting question: How does one determine that a se	does one determine that an SF is available? At one end
	rvice function is available? On one end of the spectrum, one might argue that a	of the spectrum, one might argue that an SF is sufficiently
	n SF is sufficiently available if the service node (physical or virtual) hosting	available if the service node (physical or virtual) hosting the SF
	the SF is available and is functional. On the other end of the spectrum, one m	is available and is functional. At the other end of the spectrum,
	ight argue that the SF's availability can only be concluded if the packet, after	one might argue that the SF's availability can only be deduced if
	passing through the SF, was examined and it was verified that the packet did in	the packet, after passing through the SF, was examined and it was
	deed get the expected service.</t>	verified that the packet did indeed get the expected service.</t>
		<t>The former approach will likely not provide sufficient confidence
	<t>The former approach will likely not provide sufficient confidence to the actu	about the actual SF availability, i.e., a service node and an SF are tw
	al SF availability, i.e. a service node and an SF are two different entities. T	o
	he latter approach is capable of providing an extensive verification, but comes	different entities. The latter approach is capable of providing an
	at a cost. Some SFs make direct modifications to packets, while others do not.	extensive verification but comes at a cost. Some SFs make direct
	Additionally, the purpose of some SFs may be to, conditionally, drop packets in	modifications to packets, while others do not. Additionally, the
	tentionally. In such cases, it is normal behavior that certain packets will not	purpose of some SFs may be to drop certain packets
	be egressing out from the service function. The OAM mechanism needs to take in	intentionally. In such cases, it is normal behavior that certain
	to account such SF specifics when assessing SF availability. Note that there are	packets will not be egressing out from the SF. The
	many flavors of SFs available, and many more that are likely be introduced in f	OAM mechanism needs to take into account such SF specifics when
	uture. Even a given SF may introduce a new functionality (e.g., a new signature	assessing SF availability. Note that there are many flavors of SFs
	in a firewall). The cost of this approach is that the OAM mechanism for some S	available and many more that are likely be introduced in the future.
	F will need to be continuously modified in order to "keep up" with new	Even a given SF may introduce a new functionality (e.g., a new
	functionality being introduced: lack of extensibility.</t>	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
	<t>The SF availability check can be performed using a generalized approach (i.e.	to "keep up" with new functionality being introduced.</t>
	, an adequate granularity to provide a basic SF service). The task of evaluatin	<t>The SF availability check can be performed using a generalized
	g the true availability of a Service Function is a complex activity, currently h	approach, i.e., at an adequate granularity to provide a basic SF
	aving no simple, unified solution. There is currently no standard means of doin	service. The task of evaluating the true availability of an SF is a co
	g so. Any such mechanism would be far from a typical OAM function, so it is not	mplex activity, currently having no simple, unified
	explored as part of the analysis in Sections 4 and 5.</t>	solution. There is currently no standard means of doing so. Any
		such mechanism would be far from a typical OAM function, so it is
	</section>	not explored as part of the analysis in Sections <xref
		target="_SFC_OAM_Func" format="counter"/> and <xref target="_Gap"
	<section title="SF Performance Measurement">	format="counter"/>.</t>
		</section>
	<t>The second SFC OAM requirement for the SF component is to allow an	<section numbered="true" toc="default">
	SFC-aware network device to check the performance metrics such as loss an	<name>SF Performance Measurement</name>
	d delay	<t>The second SFC OAM requirement for the SF component is to allow
	induced by a specific SF for processing legitimate traffic. The performan	an SFC-aware network device to check the performance metrics, such as
	ce can be a passive measurement by using live traffic, an active measurement by	loss and delay induced by a specific SF for processing legitimate
	using synthetic probe packets or can be a hybrid method that use a combination	traffic. Performance measurement can be passive by using live
	of active and passive measurement. More details about this OAM function is expla	traffic, an active measurement by using synthetic probe packets, or
	ined in Section 4.4.	a hybrid method that uses a combination of active and passive
	</t>	measurement. More details about this OAM function is explained in
		<xref target="Perform_Funct"/>.</t>
	<t>On the one hand, the performance of any specific SF can be quantified	<t>On the one hand, the performance of any specific SF can be quantifi
	by	ed by
	measuring the loss and delay metrics of the traffic from SFF to the respe	measuring the loss and delay metrics of the traffic from the SFF to the r
	ctive	espective
	SF, while on the other hand, the performance can be measured by	SF, while on the other hand, the performance can be measured by
	leveraging the loss and delay metrics from the respective SFs. The	leveraging the loss and delay metrics from the respective SFs. The

	latter requires SF involvement to perform the measurement while 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	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 quantifie d by	given SF for the purpose of load sharing, SF performance can be quantifie d by
	measuring the metrics for any one instance of SF or by measuring the metr ics for	measuring the metrics for any one instance of SF or by measuring the metr ics for

	a specific instance.	a specific instance.</t>
	</t>	<t>The metrics measured to quantify the performance of the SF
		component are not just limited to loss and delay. Other metrics, such
	<t>The metrics measured to quantify the performance of the SF component a	as throughput, also exist and the choice of metrics for performance
	re not just	measurement is outside the scope of this document.</t>
	limited to loss and delay. Other metrics such as throughput also exist an	</section>
	d the choice	</section>
	of metrics for performance measurement is outside the scope of this docum	<section numbered="true" toc="default">
	ent.	<name>The SFC Component</name>
	</t>	<section numbered="true" toc="default">
		<name>SFC Availability</name>
	</section>	<t>An SFC could comprise varying SFs, and so the OAM layer is
		required to perform validation and verification of SFs within an
	</section>	SFP, in addition to connectivity verification and fault
		isolation.</t>
	<section title="The SFC Component">	<t>In order to perform service connectivity verification of an
		SFC/SFP, the OAM functions could be initiated from any SFC-aware
	<section title="SFC Availability">	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
	<t>An SFC could comprise varying SFs and so the OAM layer is required to perform	goal of this OAM function is to ensure the SFs chained together have
	validation and verification of SFs within an SFP, in addition to connectivity v	connectivity, as was intended at the time when the SFC was
	erification and fault isolation.</t>	established. The necessary return codes should be defined for
		sending back in the response to the OAM packet, in order to complete
	<t>In order to perform service connectivity verification of an SFC/SFP, the OAM	the verification.</t>
	functions could be initiated from any SFC-aware network device of an SFC-enabled	<t>When ECMP is in use at the service layer for any given SFC, there
	domain for end-to-end paths, or partial paths terminating on a specific SF, wit	must be the ability to discover and traverse all available
	hin the SFC/SFP. The goal of this OAM function is to ensure the SFs chained toge	paths.</t>
	ther have connectivity as was intended at the time when the SFC was established.	<t>A detailed explanation of the mechanism is outside the scope of
	The necessary return codes should be defined for sending back in the response t	this document and is expected to be included in the actual solution
	o the OAM packet, in order to complete the verification.</t>	document.</t>
		</section>
	<t>When ECMP is in use at the service layer for any given SFC, there must be the	<section numbered="true" toc="default">
	ability to discover and traverse all available paths.</t>	<name>SFC Performance Measurement</name>
		<t>Any SFC-aware network device should have the ability to make
	<t>A detailed explanation of the mechanism is outside the scope of this document	performance measurements over the entire SFC (i.e., end-to-end) or
	and is	on a specific segment of SFs within the SFC.</t>
	expected to be included in the actual solution document.</t>	</section>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Classifier Component</name>
	<section title="SFC Performance Measurement">	<t>A classifier maintains the classification rules that map a flow to
		a specific SFC. It is vital that the classifier is correctly
	<t>Any SFC-aware network device should have the ability to make performance meas	configured with updated classification rules and is functioning as
	urements over the entire SFC (i.e., end-to-end) or to a specific segment of SFs	expected. The SFC OAM must be able to validate the classification
	within the SFC.</t>	rules by assessing whether a flow is appropriately mapped to the
		relevant SFC and detect any misclassification. Sample OAM packets can
	</section>	be presented to the classifiers to assess the behavior with regard to
		a given classification entry.</t>
	</section>	<t>The classifier availability check may be performed to check the
		availability of the classifier to apply the rules and classify the
	<section title="Classifier Component">	traffic flows. Any SFC-aware network device should have the ability to
		perform availability checking of the classifier component for each
	<t>A classifier maintains the classification rules that map a flow to a specific	SFC. </t>
	SFC. It is vital that the classifier is correctly configured with updated class	<t>Any SFC-aware network device should have the ability to perform
	ification rules and is functioning as expected. The SFC OAM must be able to vali	performance measurement of the classifier component for each SFC. The
	date the classification rules by assessing whether a flow is appropriately mappe	performance can be quantified by measuring the performance metrics of
	d to the relevant SFC and detect any misclassification. Sample OAM packets can b	the traffic from the classifier for each SFC/SFP.</t>
	e presented to the classifiers to assess the behavior with regard to a given cla	</section>
	ssification entry.</t>	<section numbered="true" toc="default">
		<name>Underlay Network</name>
	<t>The classifier availability check may be performed to check the availability	<t>The underlay network provides connectivity between the SFC
	of the classifier to apply the rules and classify the traffic flows. Any SFC-awa	components, so the availability or the performance of the underlay
	re network device should have the ability to perform availability checking of th	network directly impacts the SFC OAM.</t>
	e classifier component for each SFC.
	</t>

	<t>Any SFC-aware network device should have the ability to perform performance m
	easurement of the classifier component for each SFC. The performance can be quan
	tified by measuring
	the performance metrics of the traffic from the classifier for each SFC/SFP.
	</t>

	</section>

	<section title="Underlay Network">
	<t>The underlay network provides connectivity between the SFC components
	so the availability or the performance of the underlay network directly impacts
	the SFC OAM.
	</t>

	<t>Any SFC-aware network device may have the ability to perform availabil
	ity check or performance measurement of the underlay network using any existing
	OAM functions listed in Section 5.1.
	</t>
	</section>

	<section title="Overlay Network">
	<t>The overlay network provides connectivity for service plane between th
	e SFC components and is mostly transparent to the SFC data plane elements.
	</t>

	<t>Any SFC-aware network device may have the ability to perform availabil
	ity check or performance measurement of the overlay network using any existing O
	AM functions listed in Section 5.1.
	</t>
	</section>

	</section>

	<section title="SFC OAM Functions" anchor="_SFC_OAM_Func">

	<t><xref target="_SFC_OAM_Comp" /> described SFC OAM components and the associat
	ed 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" /> hi
	ghlighted 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 t
	he service layer, they need to be enhanced to operate a single SF/SFF to multipl
	e SFs/SFFs spanning across one or more SFCs.</t>

	<section title="Connectivity Functions">

	<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 exam
	ple, LSP Ping <xref target="RFC8029" /> is a common tool used to perform this fu
	nction for an MPLS network. Some of the OAM functions performed by connectivity
	functions are as follows:

	<list style="symbols">

	<t>Verify the Path MTU from a source to the destination SF or through the SFC. T
	his requires the ability for the OAM packet to be of variable length.</t>

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

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

	<t>Verification and validation of forwarding paths.</t>

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

	</list>

	</t>

	</section>

	<section title="Continuity Functions">

	<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 qu
	ickly detect failures such as link failures, network element failures, SF outage
	s, or SFC outages. BFD <xref target="RFC5880" /> is one such function which help
	s in detecting failures quickly. OAM functions supported by continuity functions
	are as follows:

	<list style="symbols">

	<t>Ability to provision a continuity check to a given SF within an SFC or for th
	e entire SFC.</t>

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

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

	</list>

	</t>

	</section>

	<section title="Trace Functions">

	<t>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, SFC Proxy) on t
	he tested layer. This function is typically useful for gathering information fro
	m every transit device or for isolating the failure point to a specific SF withi
	n an SFC or for an entire SFC. Some of the OAM functions supported by trace func
	tions are:

	<list style="symbols">

	<t>Ability to trigger an action from every transit device at the SFC layer, usin
	g TTL or other means.</t>

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

	<t>Ability to discover and traverse ECMP paths within an SFC.</t>

	<t>Ability to skip SFs that do not support OAM while tracing SFs in an SFC.</t>

	</list>

	</t>

	</section>

	<section title="Performance Measurement Functions">

	<t>Performance measurement functions involve measuring of packet loss, delay, de
	lay variance, etc. These performance metrics may be measured pro-actively or on-
	demand.</t>

	<t>SFC OAM should provide the ability to measure packet loss for an SFC. On-dema
	nd measurement can be used to estimate packet loss using statistical methods. To
	ensure accurate estimations, one needs to ensure that OAM packets are treated t
	he 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 pr
	otocols such as One-way Active Measurement Protocol (OWAMP) <xref target="RFC465
	6" /> and Two-way Active Measurement Protocol (TWAMP) <xref target="RFC5357" />
	can be used to measure the characteristics. As SFCs are unidirectional in nature
	, measurement of one-way delay <xref target="RFC7679" /> is important. In order
	to measure one-way delay, time synchronization must be supported by means such a
	s NTP, GPS, Precision Time Protocol (PTP), etc.</t>

	<t>One-way delay variation <xref target="RFC3393" /> 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 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 to measure the packet loss <xref target="RFC7680" /> within an SF or
	an SFP bound to a given SFC.</t>

	</list>

	</t>

	</section>

	</section>

	<section title="Gap Analysis" anchor="_Gap">

	<t>This section identifies various OAM functions available at different layers i
	ntroduced in Section 2. It also identifies various gaps that exist within the cu
	rrent toolset for performing OAM functions required for SFC.</t>

	<section title="Existing OAM Functions" anchor="_Exist_FUNC">

	<t>There are various OAM tool sets available to perform OAM functions within var
	ious layers. These OAM functions may be used to validate some of the underlay an
	d overlay networks. Tools like ping and trace are in existence to perform connec
	tivity check and tracing of intermediate hops in a network. These tools support
	different network types like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) <xref ta
	rget="Y.1731"/>
	<xref target="EFM"/> and Connectivity Fault Management (CFM) <xref target="DOT1Q
	"/> offer OAM
	mechanisms such as an Ethernet continuity check for Ethernet links. There is an
	effort around NVO3 OAM to provide connectivity and continuity checks for network
	s that use NVO3. BFD is used for the detection of data plane forwarding failure
	s. The IPPM framework <xref target="RFC2330" /> offers tools such as OWAMP <xref
	target="RFC4656" /> and TWAMP
	<xref target="RFC5357" /> (collectively referred as IPPM in this section) to mea
	sure various performance metrics. MPLS Packet Loss Measurement (LM) and Packet D
	elay Measurement (DM) (collectively referred as MPLS_PM in this section) <xref t
	arget="RFC6374" /> offers the ability to measure performance metrics in MPLS net
	work. There is also an effort to extend the tool set to provide connectivity and
	continuity checks within overlay networks. BFD is another tool which helps in d
	etecting data forwarding failures. Table 3 below is not exhaustive.

	<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
	Table 3: 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, \| \| \|
	\| \| \| NVO3 OAM \| Trace \| IPPM \|
	+----------------+--------------+-------------+--------+------------+
	\| Classifier \| Ping \| BFD \| Trace \| None \|
	+----------------+--------------+-------------+--------+------------+
	\| SF \| None \| None \| None \| None \|
	+----------------+--------------+-------------+--------+------------+
	\| SFC \| None \| None \| None \| None \|
	+----------------+--------------+-------------+--------+------------+

	]]></artwork></figure>

	</t>

	</section>

	<section title="Missing OAM Functions">

	<t>As shown in Table 3, there are no standards-based tools available at the time
	of this writing that can be used natively (i.e. without enhancement) for the ve
	rification of SFs and SFCs.</t>

	</section>

	<section title="Required OAM Functions">

	<t>Primary OAM functions exist for underlying layers. Tools like ping, trace, BF
	D, etc. exist in order to perform these OAM functions.</t>

	<t>As depicted in Table 3, toolsets and solutions are required to perform the OA
	M functions at the service layer.
	</t>

	</section>

	</section>

	<section title="Operational Aspects of SFC OAM at the Service Layer" anchor="OPS
	_ASPECTS">
	<t>This section describes the operational aspects of SFC OAM at the servi
	ce layer to perform the SFC OAM function defined in <xref target="_SFC_OAM_Func"
	/> and analyzes the applicability of various existing OAM toolsets in the servi
	ce layer.
	</t>

	<section title="SFC OAM Packet Marker">
	<t>SFC OAM messages should be encapsulated with necessary SFC hea
	der and with OAM markings when testing the SFC component. SFC OAM messages may b
	e encapsulated with the necessary SFC header and with OAM markings when testing
	the SF component.
	</t>

	<t>The SFC OAM function described in <xref target="_SFC_OAM_Func"
	/> 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 from da
	ta packets. The base header defined in Section 2.2 of <xref target="RFC8300" />
	assigns a bit to indicate OAM packets. When NSH encapsulation is used at the ser
	vice layer, the O bit must be set to differentiate the OAM packet. Any other ove
	rlay encapsulations used at the service layer must have a way to mark the packet
	as OAM packet.
	</t>
	</section>

	<section title="OAM Packet Processing and Forwarding Semantic">
	<t>Upon receiving an OAM packet, SFC-aware SFs may choose to disc
	ard the packet if it does not support OAM functionality or if the local policy p
	revents them from processing the OAM packet. When an SF supports OAM functionali
	ty, 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-awar
	e SFs should rate limit the number of OAM packets processed.

	</t>
	<t>An SFF may choose not to forward the OAM packet to an SF if th
	e SF does not support OAM or if the policy does not allow to forward OAM packets
	to an SF. The SFF may choose to skip the SF, modify the header and forward to t
	he 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 accur
	ate). The method by which an SFF detects if the connected SF supports or is allo
	wed 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 dynami
	c negotiation between the SF and SFF.
	</t>

	<t>If the SFF receiving the OAM packet bound to a given SFC is th
	e last SFF in the chain, it must send a relevant response to the initiator of th
	e OAM packet. Depending on the type of OAM solution and tool set used, the respo
	nse 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>

	<t>Any SFC-aware node that initiates an OAM packet must set the O
	AM marker in the overlay encapsulation.
	</t>
	</section>

	<section title="OAM Function Types">
	<t>As described in <xref target="_SFC_OAM_Func" />, there are dif
	ferent OAM functions that may require different OAM solutions. While the presenc
	e of the OAM marker in the overlay header (e.g., O bit in the NSH header) indica
	tes 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 overl
	ay encapsulations used at the service
	layer must have a similar way to indicate the intended OAM function.

	</t>
	</section>

	</section>

	<section title="Candidate SFC OAM Tools" anchor="_SFC_OAM_MODEL">
	<t>As described in <xref target="_Exist_FUNC" />, there are diffe
	rent tool sets
	available to perform OAM functions at different layers. This sec
	tion describe
	the applicability of some of the available toolsets in the servic
	e layer.
	</t>

	<section title="ICMP">
	<t><xref target="RFC0792" /> and <xref target="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 differen
	t end points and
	perform basic network diagnostics.
	</t>

	<t>ICMP could be leveraged for connectivity functions (de
	fined 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 encapsul
	ation header to get the response from the relevant node. For example, a classifi
	er initiating OAM can generate an ICMP echo request message, can set the TTL fie
	ld in the NSH header <xref target="RFC8300" /> to 63 to get the response from th
	e 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 and
	thereby partially test SFC availability or the initiator could send OAM packets
	with sequentially incrementing TTL in the NSH to trace the SFP.
	</t>

	<t>It could be observed that ICMP at its current stage ma
	y 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>

	</section>

	<section title="BFD/Seamless-BFD">
	<t><xref target="RFC5880" /> defines the Bidirectional Fo
	rwarding Detection (BFD) mechanism for failure detection. <xref target="RFC5881"
	/> and <xref target="RFC5884" /> define the applicability of BFD in IPv4, IPv6
	and MPLS networks. <xref target="RFC7880" /> defines Seamless BFD (S-BFD), a sim
	plified mechanism of using BFD. <xref target="RFC7881" /> explains its applicabi
	lity in IPv4, IPv6 and MPLS network.
	</t>

	<t>BFD or S-BFD could be leveraged to perform the continu
	ity function for SF or SFC. An initiator could generate a BFD control packet and
	set the "Your Discriminator" value to identify the last SFF in the control pack
	et. Upon receiving the control packet, the last SFF in the SFC will reply back w
	ith the relevant DIAG code. The TTL field in the NSH header could be used to per
	form 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 s
	et 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>
	</section>

	<section title="In-Situ OAM">
	<t><xref target="I-D.ietf-sfc-ioam-nsh" /> defines how In
	-Situ OAM data fields <xref target="I-D.ietf-ippm-ioam-data" /> are transported
	using the NSH header. <xref target="I-D.ietf-sfc-proof-of-transit" /> defines a
	mechanism to perform proof of transit to securely verify if a packet traversed t
	he relevant SFP or SFC. While the mechanism is defined inband (i.e., it will be
	included in data packets), IOA Option-Types such as IOAM Trace Option-Types can
	also be used to perform other SFC OAM function such as SFC tracing.
	</t>

	<t>In-Situ OAM could be leveraged to perform SF availabil
	ity and SFC availability or performance measurement. For example, if SFC is rea
	lized using NSH, the O-bit in the NSH header could be set to indicate the OAM tr
	affic as defined in Section 4.2 <xref target="I-D.ietf-sfc-ioam-nsh" />.
	</t>
	</section>

	<section title="SFC Traceroute">
	<t><xref target="I-D.penno-sfc-trace" /> defines a protoc
	ol that checks for path liveliness and traces the service hops in any SFP. Secti
	on 3 of <xref target="I-D.penno-sfc-trace" /> defines the SFC trace packet form
	at while Sections 4 and 5 of <xref target="I-D.penno-sfc-trace" /> defines the
	behavior of SF and SFF respectively. While <xref target="I-D.penno-sfc-trace" />
	has expired, the proposal is implemented in Open Daylight and is available.
	</t>

	<t>An initiator can control the Service Index Limit (SIL)
	in SFC trace packet to perform SF and SFC availability test.
	</t>
	</section>

	</section>

	<section anchor="Manageability" title="Manageability Considerations">

	<t>This document does not define any new manageability tools but consolid
	ates the manageability tool gap analysis for SF and SFC. Table 4 below is not ex
	haustive.
	</t>
	<t>
	<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
	Table 4: 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>
	<t>Configuration, orchestration and other manageability tasks of SF and S
	FC could be
	performed using CLI, NETCONF <xref target="RFC6241" /> , etc.
	</t>

	<t>While the NETCONF capabilities are readily available as depicted in Ta
	ble 4, the information and data models are needed for configuration, manageabili
	ty and orchestration for SFC. With virtualized SF and SFC, manageability needs t
	o be done programmatically.</t>

	</section>

	<section anchor="Security" title="Security Considerations">

	<t>Any security considerations defined in <xref target="RFC7665" /> and <xref ta
	rget="RFC8300" /> is applicable for this document.
	</t>

	<t>The OAM information from the service layer at different components may collec
	tively or independently reveal sensitive information. The information may reveal
	the type of service functions hosted in the network, the classification rules a
	nd the associated service chains, specific service function paths, etc. The sens
	itivity of the information from the SFC layer raises a need for careful security
	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 collect
	ed 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 i
	nternal attacks.
	</t>

	<t>The SF information at the SF component may be used by a malicious user to tri
	gger Denial of Service (DoS) attack by overloading any specific SF using rogue O
	AM traffic.
	</t>

	<t>To address the above concerns, SFC and SF OAM should provide mechanisms for m
	itigating:

	<list style="symbols">
	<t>Misuse of the OAM channel for denial-of-services,</t>
	<t>Leakage of OAM packets across SFC instances, and</t>
	<t>Leakage of SFC information beyond the SFC domain.</t>
	</list>

	</t>

	<t>The documents proposing the OAM solution for SF components should provide rat
	e-limiting the OAM probes at a frequency guided by the implementation choice. Ra
	te-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 fal
	se negatives and the implementation should be aware of this. To mitigate any att
	acks that leverage OAM packets, future documents proposing OAM solutions should
	describe the use of any technique to detect and mitigate anomalies and various s
	ecurity attacks.
	</t>

	<t>The documents proposing the OAM solution for any service layer components sho
	uld consider some form of message filtering to control the OAM packets entering
	the administrative domain or prevent leaking any internal service layer informat
	ion outside the administrative domain.
	</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>
		</section>
		<section numbered="true" toc="default">
		<name>Overlay Network</name>
		<t>The overlay network provides connectivity for the service plane betwe
		en
		the SFC components and is mostly transparent to the SFC 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 <xref
		target="_Exist_FUNC"/>.</t>
		</section>
	</section>	</section>

		<section anchor="_SFC_OAM_Func" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>SFC OAM Functions</name>
		<t><xref target="_SFC_OAM_Comp" format="default"/> described SFC OAM
	<t>No action is required by IANA for this document.</t>	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" format="default"/> highlight the need for
		various OAM functions at the service layer. As listed in <xref target="_Ex
		ist_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 or multiple SFs/SFFs spanning across one or more SFCs.</t>
		<section anchor="Connect_Func" numbered="true" toc="default">
		<name>Connectivity Functions</name>
		<t>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 <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:</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.</li>
		<li>Detect any packet reordering and corruption.</li>
		<li>Verify that an SFC or SF is applying the expected policy.</li>
		<li>Verify and validate forwarding paths.</li>
		<li>Proactively test alternate or protected paths to ensure
		reliability of network configurations.</li>
		</ul>
		</section>
		<section 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, such as link
		failures, network element failures, SF outages, or SFC outages. BFD
		<xref target="RFC5880" format="default"/> is one such protocol that
		helps in detecting failures quickly. OAM functions supported by
		continuity functions are as follows:</t>
		<ul spacing="normal">
		<li>Provision a continuity check to a given SF within an
		SFC or for the entire SFC.</li>
		<li>Proactively test alternate or protected paths to ensure
		reliability of network configurations.</li>
		<li>Notifying other OAM functions or applications of the detected
		failures so they can take appropriate action.</li>
		</ul>
		</section>
		<section numbered="true" toc="default">
		<name>Trace Functions</name>
		<t>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:</t>
		<ul spacing="normal">
		<li>the ability to trigger an action from every transit device at the
		SFC layer, using TTL or other means,</li>
		<li>the ability to trigger every transit device at the SFC layer to
		generate a response with OAM code(s) using TTL or other means,</li>
		<li>the ability to discover and traverse ECMP paths within an SFC, and
		</li>
		<li>the ability to skip SFs that do not support OAM while tracing SFs
		in an SFC.</li>
		</ul>
		</section>
		<section anchor="Perform_Funct" numbered="true" toc="default">
		<name>Performance Measurement Functions</name>
		<t>Performance measurement functions involve measuring of packet loss,
		delay, delay variance, etc. These performance metrics may be measured
		proactively or 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, such as the One-Way Active Measurement
		Protocol (OWAMP) <xref target="RFC4656" format="default"/> and the Two-Wa
		y
		Active Measurement Protocol (TWAMP) <xref target="RFC5357"
		format="default"/>, can be used to measure 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:</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, 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.</li>
		</ul>
		</section>
	</section>	</section>

		<section anchor="_Gap" numbered="true" toc="default">
	<section title="Acknowledgements">	<name>Gap Analysis</name>
		<t>This section identifies various OAM functions available at different
	<t>We would like to thank Mohamed Boucadair, Adrian Farrel, Greg Mirsky, T	layers introduced in <xref target="_SFC_Layer"/>. It also identifies vario
	al	us gaps that
	Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados, Martin Duk	exist within the current toolset for performing OAM functions required
	e, Barry Leiba, Eric Vyncke, Roman Danyliw, Erik Kline, Benjamin Kaduk, Robert W	for SFC.</t>
	ilton, Frank Brockner, Alvaro Retana, Murray Kucherawy, and Alissa Cooper for th	<section anchor="_Exist_FUNC" numbered="true" toc="default">
	eir review and comments.</t>	<name>Existing OAM Functions</name>
		<t>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) <xref
		target="Y.1731" format="default"/> <xref target="EFM"
		format="default"/> and Connectivity Fault Management (CFM) <xref
		target="DOT1Q" format="default"/> 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 <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" format="default"/> 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. <xref target="OAM-Analysis"/>
		below is not exhaustive.</t>
		<t keepWithNext="true"/>
		<table anchor="OAM-Analysis" align="center">
		<name>OAM Tool 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</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 numbered="true" toc="default">
		<name>Missing OAM Functions</name>
		<t>As shown in <xref target="OAM-Analysis"/>, 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.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Required OAM 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 <xref target="OAM-Analysis"/>, toolsets and solutions
		are required to
		perform the OAM functions at the service layer.</t>
		</section>
	</section>	</section>

		<section anchor="OPS_ASPECTS" numbered="true" toc="default">
		<name>Operational Aspects of SFC OAM at the Service 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>
		<section numbered="true" toc="default">
		<name>SFC OAM Packet 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>
		<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 OAM packets from data packets. The base header defined
		in <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>
		</section>
		<section numbered="true" toc="default">
		<name>OAM Packet Processing and Forwarding Semantic</name>
		<t>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. </t>
		<t>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 OA
		M
		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 no
		ted 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.</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
		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>
		<t>Any SFC-aware node that initiates an OAM packet must set the OAM
		marker in the overlay encapsulation.</t>
		</section>
		<section numbered="true" toc="default">
		<name>OAM Function 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>
		</section>
		</section>
		<section anchor="_SFC_OAM_MODEL" numbered="true" toc="default">
		<name>Candidate SFC OAM Tools</name>
		<t>As described in <xref target="_Exist_FUNC" format="default"/>, 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.</t>
		<section 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>
		<t>ICMP could be leveraged for connectivity functions (defined in
		<xref target="Connect_Func"/>) to verify the availability of an SF or
		SFC. The initiator
		can generate an ICMP echo request message and control the service-layer e
		ncapsulation 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 <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 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.</t>
		<t>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.</t>
		</section>
		<section 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, 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, and MPLS 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. Upon receiving the control packe
		t, 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>
		</section>
		<section numbered="true" toc="default">
		<name>In Situ OAM</name>


	<section title="Contributing Authors">	<t><xref target="I-D.ietf-sfc-ioam-nsh" format="default"/> defines how
	<t>Nobo Akiya	In situ OAM data fields <xref target="I-D.ietf-ippm-ioam-data"
	<vspace blankLines="0" />	format="default"/> are transported using the NSH header. <xref
	Ericsson	target="I-D.ietf-sfc-proof-of-transit" format="default"/> defines a
	<vspace blankLines="0" />	mechanism to perform proof of transit to securely verify if a packet
	Email: nobo.akiya.dev@gmail.com</t>	traversed the relevant SFP or SFC. While the mechanism is defined
	</section>	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.</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 in the NSH header could be set to
		indicate the OAM traffic, as defined in <xref
		target="I-D.ietf-sfc-ioam-nsh" sectionFormat="of" section="4.2"/>.</t>
		</section>
		<section 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. <xref target="I-D.penno-sfc-trace"
		sectionFormat="of" section="3"/> defines the SFC trace packet format,
		while Sections <xref target="I-D.penno-sfc-trace" section="4"
		sectionFormat="bare"/> and <xref target="I-D.penno-sfc-trace"
		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>
		<t>An initiator can control the Service Index Limit (SIL) in an SFC trac
		e
		packet to perform SF and SFC availability tests.</t>
		</section>
		</section>
		<section anchor="Manageability" 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. <xref
		target="OAM-Analysis-2"/> below is not exhaustive.</t>
		<t keepWithNext="true"/>
		<table anchor="OAM-Analysis-2" align="center">
		<name>OAM Tool 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, and other manageability tasks of SF and
		SFC could be performed using CLI, NETCONF <xref target="RFC6241"
		format="default"/>, etc.</t>
		<t>While the NETCONF capabilities are readily available, as depicted in
		<xref target="OAM-Analysis-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.</
		t>
		</section>
		<section anchor="Security" numbered="true" toc="default">
		<name>Security Considerations</name>
		<t>Any security considerations defined in <xref target="RFC7665"
		format="default"/> and <xref target="RFC8300" format="default"/> are
		applicable for this 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>
		<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, 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>
		<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>
		<t>To address the above concerns, SFC and SF OAM should provide
		mechanisms for mitigating:</t>
		<ul spacing="normal">
		<li>misuse of the OAM channel for denial of services,</li>
		<li>leakage of OAM packets across SFC instances, and</li>
		<li>leakage of SFC information beyond the SFC 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, 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.</t>
		<t>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.</t>
		</section>
		<section anchor="IANA" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>This document has no IANA actions.</t>
		</section>
	</middle>	</middle>


	<!-- ***BACK MATTER *** -->	<!-- ***BACK MATTER *** -->

	<back>	<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 split into informative and normative -->


	<references title="Informative References">	<references>
	<?rfc include="reference.RFC.2330"?>	<name>Informative References</name>
	<?rfc include="reference.RFC.0792"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.3393"?>	ce.RFC.2330.xml"/>
	<?rfc include="reference.RFC.7665"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.8300"?>	ce.RFC.0792.xml"/>
	<?rfc include="reference.RFC.4443"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.4656"?>	ce.RFC.3393.xml"/>
	<?rfc include="reference.RFC.5357"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.6374"?>	ce.RFC.7665.xml"/>
	<?rfc include="reference.RFC.6241"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.7498"?>	ce.RFC.8300.xml"/>
	<?rfc include="reference.RFC.7680"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.7679"?>	ce.RFC.4443.xml"/>
	<?rfc include="reference.RFC.8459"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.6291"?>	ce.RFC.4656.xml"/>
	<?rfc include="reference.RFC.5880"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.5881"?>	ce.RFC.5357.xml"/>
	<?rfc include="reference.RFC.5884"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.7880"?>	ce.RFC.6374.xml"/>
	<?rfc include="reference.RFC.7881"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.RFC.8029"?>	ce.RFC.6241.xml"/>
	<?rfc include="reference.I-D.ietf-sfc-proof-of-transit"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.I-D.ietf-sfc-ioam-nsh"?>	ce.RFC.7498.xml"/>
	<?rfc include="reference.I-D.ietf-ippm-ioam-data"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	<?rfc include="reference.I-D.penno-sfc-trace"?>	ce.RFC.7680.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.7679.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.8459.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.6291.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.5880.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.5881.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.5884.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.7880.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.7881.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
		ce.RFC.8029.xml"/>


	<reference anchor="Y.1731" target="https://www.itu.int/rec/T-REC-G.8013	<xi:include
	-201508-I/en">	href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-p
	<front>	roof-of-transit.xml"/>
	<title>OAM Functions and mechanisms for Ethernet based networks</title>
	<author><organization>ITU-T</organization></author>
	<date/>
	</front>
	</reference>


	<reference anchor="EFM">	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
	<front>	etf-sfc-ioam-nsh.xml"/>
	<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/>
	</front>
	</reference>


	<reference anchor="DOT1Q">	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
	<front>	etf-ippm-ioam-data.xml"/>
	<title>Standard for Local and Metropolitan Area Networks--Bridges
	and Bridged Networks, IEEE Std 802.1Q-2014, November 2014</title>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.p
	<author><organization>IEEE</organization></author>	enno-sfc-trace.xml"/>
	<date/>
	</front>	<reference anchor="Y.1731" target="https://www.itu.int/rec/T-REC-G.8013-20
	</reference>	1508-I/en">
		<front>
		<title>G.8013: Operations, administration and maintenance (OAM)
		functions and mechanisms for Ethernet-based networks</title>
		<author>
		<organization>ITU-T</organization>
		</author>
		<date month="August" year="2015"/>
		</front>
		</reference>


		<reference anchor="EFM">
		<front>
		<title>IEEE Standard for 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>IEEE Standard for Local and metropolitan area
		networks--Bridges and Bridged 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>	</references>


	<!-- Change Log	<section numbered="false" toc="default">
	v00-a 2014-06-28a Nobo: Initial version	<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>	</back>
	</rfc>	</rfc>

End of changes. 36 change blocks.
	976 lines changed or deleted	955 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/