< draft-ietf-sfc-oam-framework-06.txt   draft-ietf-sfc-oam-framework-07.txt >
Internet Engineering Task Force S. Aldrin Internet Engineering Task Force S. Aldrin
Internet-Draft Google Internet-Draft Google
Intended status: Informational C. Pignataro, Ed. Intended status: Informational C. Pignataro, Ed.
Expires: September 26, 2019 N. Kumar, Ed. Expires: December 20, 2019 N. Kumar, Ed.
Cisco Cisco
N. Akiya N. Akiya
Big Switch Networks Big Switch Networks
R. Krishnan R. Krishnan
VMware
A. Ghanwani A. Ghanwani
Dell Dell
March 25, 2019 June 18, 2019
Service Function Chaining (SFC) Service Function Chaining (SFC)
Operation, Administration and Maintenance (OAM) Framework Operations, Administration and Maintenance (OAM) Framework
draft-ietf-sfc-oam-framework-06 draft-ietf-sfc-oam-framework-07
Abstract Abstract
This document provides a reference framework for Operations, This document provides a reference framework for Operations,
Administration and Maintenance (OAM) for Service Function Chaining Administration and Maintenance (OAM) for Service Function Chaining
(SFC). (SFC).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119] RFC 8174 [RFC8174] when and only when, they appear in
all capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4
2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 4 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 4
3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 5 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 5
3.1. Service Function Component . . . . . . . . . . . . . . . 6 3.1. The Service Function Component . . . . . . . . . . . . . 6
3.1.1. Service Function Availability . . . . . . . . . . . . 6 3.1.1. Service Function Availability . . . . . . . . . . . . 6
3.1.2. Service Function Performance Measurement . . . . . . 7 3.1.2. Service Function Performance Measurement . . . . . . 7
3.2. Service Function Chain Component . . . . . . . . . . . . 7 3.2. The Service Function Chain Component . . . . . . . . . . 7
3.2.1. Service Function Chain Availability . . . . . . . . . 7 3.2.1. Service Function Chain Availability . . . . . . . . . 7
3.2.2. Service Function Chain Performance Measurement . . . 8 3.2.2. Service Function Chain Performance Measurement . . . 8
3.3. Classifier Component . . . . . . . . . . . . . . . . . . 8 3.3. The Classifier Component . . . . . . . . . . . . . . . . 8
4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 8 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 9 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 9
4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 9 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 9
4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 9 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 9
4.4. Performance Measurement Function . . . . . . . . . . . . 10 4.4. Performance Management Function . . . . . . . . . . . . . 10
5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 11 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 11
5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 12 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 12
5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 12 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 12
6. SFC OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Candidate SFC OAM Tools . . . . . . . . . . . . . . . . . . . 12
6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 12 6.1. SFC OAM Packet Marker . . . . . . . . . . . . . . . . . . 12
6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 12 6.2. OAM Packet Processing and Forwarding Semantic . . . . . . 13
6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 13 6.3. OAM Function Types . . . . . . . . . . . . . . . . . . . 13
6.4. OAM Toolset applicability . . . . . . . . . . . . . . . . 13 6.4. OAM Toolset applicability . . . . . . . . . . . . . . . . 14
6.4.1. ICMP Applicability . . . . . . . . . . . . . . . . . 13 6.4.1. ICMP Applicability . . . . . . . . . . . . . . . . . 14
6.4.2. Seamless BFD Applicability . . . . . . . . . . . . . 14 6.4.2. BFD/Seamless-BFD Applicability . . . . . . . . . . . 14
6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 14 6.4.3. In-Situ OAM . . . . . . . . . . . . . . . . . . . . . 15
6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 14 6.4.4. SFC Traceroute . . . . . . . . . . . . . . . . . . . 15
6.5. Security Considerations . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Service Function Chaining (SFC) enables the creation of composite Service Function Chaining (SFC) enables the creation of composite
services that consist of an ordered set of Service Functions (SF) services that consist of an ordered set of Service Functions (SF)
that are to be applied to packets and/or frames selected as a result that are to be applied to packets and/or frames selected as a result
of classification [RFC7665]. Service Function Chaining is a concept of classification [RFC7665]. SFC is a concept that provides for more
that provides for more than just the application of an ordered set of than just the application of an ordered set of SFs to selected
SFs to selected traffic; rather, it describes a method for deploying traffic; rather, it describes a method for deploying SFs in a way
SFs in a way that enables dynamic ordering and topological that enables dynamic ordering and topological independence of those
independence of those SFs as well as the exchange of metadata between SFs as well as the exchange of metadata between participating
participating entities. The foundations of SFC are described in the entities. The foundations of SFC are described in the following
following documents: documents:
o SFC Problem Statement [RFC7498] o SFC Problem Statement [RFC7498]
o SFC Architecture [RFC7665] o SFC Architecture [RFC7665]
The reader is assumed to be familiar with the material in these The reader is assumed to be familiar with the material in these
documents. documents.
This document provides a reference framework for Operations, This document provides a reference framework for Operations,
Administration and Maintenance (OAM, [RFC6291]) of SFC. Administration and Maintenance (OAM, [RFC6291]) of SFC.
Specifically, this document provides: Specifically, this document provides:
o In Section 2, an SFC layering model; o In Section 2, an SFC layering model;
o In Section 3, aspects monitored by SFC OAM; o In Section 3, aspects monitored by SFC OAM;
o In Section 4, functional requirements for SFC OAM; o In Section 4, functional requirements for SFC OAM;
o In Section 5, a gap analysis for SFC OAM. o In Section 5, a gap analysis for SFC OAM.
SFC OAM solution documents should refer to this document to indicate
the SFC OAM component and the functionality they target.
OAM controllers are assumed to be within the same administrative
domain as the target SFC enabled domain.
1.1. Document Scope 1.1. Document Scope
The focus of this document is to provide an architectural framework The focus of this document is to provide an architectural framework
for SFC OAM, particularly focused on the aspect of the Operations for SFC OAM, particularly focused on the aspect of the Operations
component within OAM. Actual solutions and mechanisms are outside component within OAM. Actual solutions and mechanisms are outside
the scope of this document. the scope of this document.
2. SFC Layering Model 2. SFC Layering Model
Multiple layers come into play for implementing the SFC. These Multiple layers come into play for implementing the SFC. These
include the service layer and the underlying layers (Network, Link include the service layer and the underlying layers (Network Layer,
etc) Link Layer, etc.).
o The service layer in Figure 1, consists of SFC data plane elements o The service layer, which consists of SFC data plane elements that
that includes classifiers, Service Functions (SF), Service includes classifiers, Service Functions (SF), Service Function
Function Forwarders (SFF), SFC Proxy. This layer uses the overlay Forwarders (SFF), and SFC Proxies. This layer uses the overlay
network for ensuring connectivity between SFC data plane elements. network for ensuring connectivity between SFC data plane elements.
o The overlay network layer in Figure 1, leverages various overlay o The overlay network layer, which leverages various overlay network
network technologies interconnecting SFC data plane elements and technologies interconnecting SFC data plane elements and allows
allows establishing service function paths (SFPs). This layer is establishing Service Function Paths (SFPs). This layer is mostly
mostly transparent to the SFC data plane elements. transparent to the SFC data plane elements.
o The underlay network layer in Figure 1, is dictated by the o The underlay network layer, which is dictated by the networking
networking technology deployed within a network (e.g., IP, MPLS) technology deployed within a network (e.g., IP, MPLS)
o The link layer in Figure 1, is dependent upon the physical o The link layer, which is dependent upon the physical technology
technology used. Ethernet is a popular choice for this layer, but used. Ethernet is a popular choice for this layer, but other
other alternatives are deployed (e.g. POS, DWDM etc...). The alternatives are deployed (e.g. POS, DWDM). The same or distinct
same or distinct link layer technologies may be used in each leg link layer technologies may be used in each leg shown in Figure 1.
shown in figure 1.
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 | +---+ +---+ +---+ +---+ +---+ +---+ +---+
+------+ +------+
o------VM1------o o--VM2--o o--VM3--o o------VM1------o o--VM2--o o--VM3--o
o-----------------o-------------------o---------------o Overlay network o-----------------o-------------------o---------------o Overlay network
o-----------------o-----------------------------------o Underlay network o-----------------o-------------------o---------------o Underlay network
o--------o--------o--------o--------o--------o--------o Link o--------o--------o--------o--------o--------o--------o Link
Figure 1: SFC Layering Example Figure 1: SFC Layering Example
While Figure 1 depicts a sample example where SFs are enabled as While Figure 1 depicts a sample example where SFs are enabled as
virtual entities, the SFC architecture does not make any assumptions virtual entities, the SFC architecture does not make any assumptions
on how SFC data plane elements are deployed. The SFC architecture is on how the SFC data plane elements are deployed. The SFC
flexible to accomodate physical or virtual entity deployment. SFC architecture is flexible and accommodates physical or virtual entity
OAM adheres to this flexibility and accordingly it is applicable deployment. SFC OAM accounts for this flexibility and accordingly it
whether SFC data plane elements are deployed directly on physical is applicable whether SFC data plane elements are deployed directly
hardware, as one or more Virtual Machines, or any combination on physical hardware, as one or more Virtual Machines, or any
thereof. combination thereof.
3. SFC OAM Components 3. SFC OAM Components
The SFC operates at the service layer. For the purpose of defining The SFC operates at the service layer. For the purpose of defining
the OAM framework, the service layer is broken up into three distinct the OAM framework, the service layer is broken up into three distinct
components. components:
1. SF component: OAM solutions for this component include testing 1. SF component: OAM functions applicable at this component includes
the service functions from any SFC-aware network devices (i.e. testing the SFs from any SFC-aware network devices (e.g.,
classifiers, controllers, other service nodes). classifiers, controllers, other service nodes). Testing an SF
may not be restricted to connectivity to the SF, but also whether
the SF is providing its intended service. Refer to Section 3.1.1
for a more detailed discussion.
2. SFC component: OAM solutions for this component include testing 2. SFC component: OAM functions applicable at this component
the service function chains and the SFPs, validate the includes (but are not limited to) testing the service function
correlation between a Service Function Chain and the actual chains and the SFPs, validaion of the correlation between an SFC
forwarding path followed by a packet matching that SFC, etc. and the actual forwarding path followed by a packet matching that
SFC, i.e. the Rendered Service Path (RSP). Some of the hops of
an SFC may not be visible when Hierarchical Service Function
Chaining (hSFC) [RFC8459] is in use. In such schemes, it is the
responsibility of the Internal Boundary Node (IBN) to glue the
connectivity between different levels for end-to-end OAM
functionality.
3. Classifier component: OAM solutions for this component include 3. Classifier component: OAM functions applicable at this component
testing the validity of the classification rules and detecting includes testing the validity of the classification rules and
any incoherence among the rules installed in different detecting any incoherence among the rules installed in different
classifiers. classifiers.
Below figure illustrates an example where OAM for the three defined Figure 2 illustrates an example where OAM for the three defined
components are used within the SFC environment. components are used within the SFC environment.
+-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)
Figure 2: SFC OAM for Three Components Figure 2: SFC OAM Components
It is expected that multiple SFC OAM solutions will be defined, many It is expected that multiple SFC OAM solutions will be defined, each
targeting one specific component of the service layer. However, it targeting one specific component of the service layer. However, it
is critical that SFC OAM solutions together provide the coverage of is critical that SFC OAM solutions together provide the coverage of
all three SFC OAM components: the service function component, the all three SFC OAM components: the SF component, the SFC component,
service function chain component and the classifier component. and the classifier component.
3.1. Service Function Component 3.1. The Service Function Component
3.1.1. Service Function Availability 3.1.1. Service Function Availability
One SFC OAM requirement for the service function component is to One SFC OAM requirement for the SF component is to allow an SFC-aware
allow an SFC-aware network device to check the availability to a network device to check the availability of a specific SF (instance),
specific service function, located on the same or different network located on the same or different network device(s). The SF
devices. Service function availability is an aspect which raises an availability may be performed to check the availability of any
interesting question. How to determine that a service function is instance of a specific SFn or it can be a specific instance of a SF.
available?. On one end of the spectrum, one might argue that a SF availability is an aspect that raises an interesting question --
service function is sufficiently available if the service node How to determine that a service function is available?. On one end
(physical or virtual) hosting the service function is available and of the spectrum, one might argue that an SF is sufficiently available
is functional. On the other end of the spectrum, one might argue if the service node (physical or virtual) hosting the SF is available
that the service function availability can only be concluded if the and is functional. On the other end of the spectrum, one might argue
packet, after passing through the service function, was examined and that the SF's availability can only be concluded if the packet, after
verified that the packet got expected service applied. passing through the SF, was examined and it was verified that the
packet did indeed get the got expected service.
The former approach will likely not provide sufficient confidence to The former approach will likely not provide sufficient confidence to
the actual service function availability, i.e. a service node and a the actual SF availability, i.e. a service node and a SF are two
service function are two different entities. The latter approach is different entities. The latter approach is capable of providing an
capable of providing an extensive verification, but comes with a extensive verification, but comes at a cost. Some SFs make direct
cost. Some service functions make direct modifications to packets, modifications to packets, while others do not. Additionally, the
while other service functions do not make any modifications to purpose of some SFs may be to, conditionally, drop packets
packets. Additionally, purpose of some service functions is to, intentionally. In such cases, it is normal behavior that certain
conditionally, drop packets intentionally. In such case, packets packets will not be egressing out from the service function. The OAM
will not be coming out from the service function. The fact is that mechanism needs to take into account such SF specifics when assessing
there are many flavors of service functions available, and many more SF availability. Note that there are many flavors of SFs available,
flavors of service functions will likely be introduced in future. and many more that are likely be introduced in future. Even a given
Even a given service function may introduce a new functionality SF may introduce a new functionality (e.g., a new signature in a
within a service function (e.g., a new signature in a firewall). The firewall). The cost of this approach is that the OAM mechanism for
cost of this approach is that verifier functions will need to be some SF will need to be continuously modified in order to "keep up"
continuously modified to "keep up" with new services coming out: lack with new functionality being introduced: lack of extendibility.
of extendibility.
This framework document provides a RECOMMENDED architectural model This framework document provides a RECOMMENDED framework where a
where generalized approach is taken to verify that a service function generalized approach is taken to verify that a SF is sufficiently
is sufficiently available. More specifics on the mechanism to available (i.e., an adequate granularity to provide a basic SF
characterize SF-specific OAM to validate the service offering is service). More specifics on the mechanism to characterize SF-
outside the scope of this document. Those mechanism are specific OAM to validate the service offering are outside the scope
implementation and deployment specific. of this document. Those fine-grained mechanisms are implementation-
and deployment-specific.
3.1.2. Service Function Performance Measurement 3.1.2. Service Function Performance Measurement
Second SFC OAM requirement for the service function component is to The second SFC OAM requirement for the SF component is to allow an
allow an SFC aware network device to check the loss and delay induced SFC-aware network device to check the performance metrics such as
by a specific service function. The performance can be a passive loss and delay induced by a specific SF for processing legitimate
measurement by using live traffic or can be active measurement by traffic. The performance can be a passive measurement by using live
using synthetic probe packets. traffic or can be active measurement by using synthetic probe
packets.
On one hand, the performance of any specific service function can be On the one hand, the performance of any specific SF can be quantified
measured by measuring the loss and delay metric of the traffic from by measuring the loss and delay metrics of the traffic from SFF to
service node to the respective service function, while on the other the respective SF, while on the other hand, the performance can be
hand, the performance can be measured by leveraging the loss and measured by leveraging the loss and delay metrics from the respective
delay metrics from the respective service functions. The latter SFs. The latter requires SF involvement to perform the measurement
requires service function involvement to perform the measurement
while the former does not. while the former does not.
3.2. Service Function Chain Component 3.2. The Service Function Chain Component
3.2.1. Service Function Chain Availability 3.2.1. Service Function Chain Availability
Verifying an SFC is a complicated process as the SFC could be An SFC could be comprised of varying SFs and so the OAM layer is
comprised of varying SF's. Thus, SFC requires the OAM layer to required to perform validation and verification of SFs within an SFP,
perform validation and verification of SF's within an SFP, as well as in addition to connectivity verification and fault isolation.
connectivity and fault isolation.
In order to perform service connectivity verification of an SFC, the In order to perform service connectivity verification of an SFC/SFP,
OAM could be initiated from any SFC aware network devices for end-to- the OAM functions could be initiated from any SFC-aware network
end paths or partial path terminating on a specific SF within the devices of an SFC-enabled domain for end-to-end paths, or partial
SFC. The goal of this OAM function is to ensure the SF's chained paths terminating on a specific SF, within the SFC/SFP. The goal of
together has connectivity as it is intended to when SFC was this OAM function is to ensure the SFs chained together have
established. Necessary return code should be defined to be sent back connectivity as was intended at the time when the SFC was
in the response to OAM packet, in order to qualify the verification. established. The necessary return codes should be defined for
sending back in the response to the OAM packet, in order to complete
the verification.
When ECMP is in use at the service layer for any given SFC, there 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. MUST be the ability to discover and traverse all available paths.
Detailed explanation on the mechanism is outside the scope of this A detailed explanation of the mechanism is outside the scope of this
document and will be expected to be included in the actual solution document and is expected to be included in the actual solution
document. document.
3.2.2. Service Function Chain Performance Measurement 3.2.2. Service Function Chain Performance Measurement
Any SFC-aware network device must have the ability to perform loss Any SFC-aware network device SHOULD have the ability to make
and delay measurements over the service function chain as a unit performance measurements over the entire SFC (i.e., end-to-end) or to
(i.e. end-to-end) or to a specific segment of service function a specific segment of SFs within the SFC.
through the SFC.
3.3. Classifier Component 3.3. The Classifier Component
A classifier maintains the classification rules that maps a flow to a A classifier maintains the classification rules that map a flow to a
specific SFC. It is vital that the classifier is correctly specific SFC. It is vital that the classifier is correctly
configured with updated classification rules and functioning configured with updated classification rules and is functioning as
accordingly. The SFC OAM must be able to validate the classification expected. The SFC OAM must be able to validate the classification
rules by assessing whether a flow is appropriately mapped to the rules by assessing whether a flow is appropriately mapped to the
relevant SFC. Sample OAM packets can be presented to the classifiers relevant SFC. Sample OAM packets can be presented to the classifiers
to assess the behavior with regards to a given classification entry. to assess the behavior with regard to a given classification entry.
4. SFC OAM Functions 4. SFC OAM Functions
Section 3 describes SFC OAM operations that is required on each SFC Section 3 described SFC OAM operations that are required on each SFC
component. This section explores the same from the OAM functionality component. This section explores SFC OAM functions that are
point of view, which many will be applicable to multiple SFC applicable for more than one SFC components.
components.
Various SFC OAM requirements listed in Section 3, provides the need The various SFC OAM requirements listed in Section 3 highlighted the
for various OAM functions at different layers. Many of the OAM need for various OAM functions at different layers. As listed in
functions at different layers are already defined and in existence. Section 5.1, various OAM functions are in existence that are defined
In order to apply such OAM functions at service layer, they have to to perform OAM functionality at different layers. In order to apply
be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC such OAM functions at the service layer, they need to be enhanced to
and also in multiple SFCs. operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
multiple SFCs.
4.1. Connectivity Functions 4.1. Connectivity Functions
Connectivity is mainly an on-demand function to verify that the Connectivity is mainly an on-demand function to verify that the
connectivity exists between network elements and the availability connectivity exists between certain network elements and that the SFs
exists to service functions. Ping is a common tool used to perform are available. For example, LSP Ping is a common tool used to
this function. OAM messages SHOULD be encapsulated with necessary perform this function for an MPLS underlay network. OAM messages
SFC header and with OAM markings when testing the service function SHOULD be encapsulated with necessary SFC header and with OAM
chain component. OAM messages MAY be encapsulated with necessary SFC markings when testing the SFC component. OAM messages MAY be
header and with OAM markings when testing the service function encapsulated with the necessary SFC header and with OAM markings when
component. Some of the OAM functions performed by connectivity testing the SF component. Some of the OAM functions performed by
functions are as follows: connectivity functions are as follows:
o Verify the Path MTU from a source to the destination SF or through o Verify the Path MTU from a source to the destination SF or through
the SFC. This requires the ability for OAM packet to take the SFC. This requires the ability for the OAM packet to be of
variable length packet size. variable length packet size.
o Verify the packet re-ordering and corruption. o Verify any packet re-ordering and corruption.
o Verify the policy of an SFC or SF using OAM packet. o Verify the policy of an SFC or SF.
o Verification and validating forwarding paths. o Verification and validation of forwarding paths.
o Proactively test alternate or protected paths to ensure o Proactively test alternate or protected paths to ensure
reliability of network configurations. reliability of network configurations.
4.2. Continuity Functions 4.2. Continuity Functions
Continuity is a model where OAM messages are sent periodically to Continuity is a model where OAM messages are sent periodically to
validate or verify the reachability to a given SF or through a given validate or verify the reachability to a given SF within an SFC or
SFC. This allows monitor network device to quickly detect failures for the entire SFC. This allows a monitoring network device (such as
like link failures, network failures, service function outages or the classifier or controller) to quickly detect failures such as link
service function chain outages. BFD is one such function which helps failures, network element failures, SF outages, or SFC outages. BFD
in detecting failures quickly. OAM functions supported by continuity [RFC5880] is one such function which helps in detecting failures
check are as follows: quickly. OAM functions supported by continuity function are as
follows:
o Ability to provision continuity check to a given SF or through a o Ability to provision continuity check to a given SF within an SFC
given SFC. or for the entire SFC.
o Notifying the failure upon failure detection for other OAM o Notifying the detected failures to other OAM functions or
functions to take appropriate action. applications to take appropriate action.
4.3. Trace Functions 4.3. Trace Functions
Tracing is an important OAM function that allows the operation to Tracing is an OAM function that allows the operation to trigger an
trigger an action (e.g., response generation) from every transit action (e.g. response generation) from every transit device (e.g.
device (e.g., SFF, SF, SFC Proxy etc) on the tested layer. This SFF, SF, SFC Proxy) on the tested layer. This function is typically
function is typically useful to gather information from every transit useful for gathering information from every transit devices or for
devices or to isolate the failure point towards an SF or through an isolating the failure point to a specific SF within an SFC or for an
SFC. Some of the OAM functions supported by trace functions are: entire SFC. Some of the OAM functions supported by trace functions
are:
o Ability to trigger action from every transit device on the tested o Ability to trigger action from every transit device at the SFC
layer towards an SF or through an SFC, using TTL or other means. layer, using TTL or other means.
o Ability to trigger every transit device to generate response with o Ability to trigger every transit device at the SFC layer to
OAM code(s) on the tested layer towards an SF or through an SFC, generate a response with OAM code(s), using TTL or other means.
using TTL or other means.
o Ability to discover and traverse ECMP paths within an SFC. o Ability to discover and traverse ECMP paths within an SFC.
o Ability to skip un-supported SFs while tracing SFs in an SFC. o Ability to skip SFs that do not support OAM while tracing SFs in
an SFC.
4.4. Performance Measurement Function 4.4. Performance Management Function
Performance management functions involve measuring of packet loss, Performance management functions involve measuring of packet loss,
delay, delay variance, etc. These measurements could be measured delay, delay variance, etc. These performance metrics may be
pro-actively and on-demand. measured pro-actively or on-demand.
SFC OAM framework should provide the ability to perform packet loss SFC OAM should provide the ability to measure packet loss for an SFC.
for an SFC. Measuring packet loss is very important function. Using On-demand measurement can be used to estimate packet loss using
on-demand function, the packet loss could be measured using statistical methods. Measuring the loss of OAM packets, an
statistical means. Using OAM packets, the approximation of packet approximation of packet loss for a given SFC can be derived.
loss for a given SFC could be measured.
Delay within an SFC could be measured from the time it takes for a Delay within an SFC could be measured based on the time it takes for
packet to traverse the SFC from ingress SFC node to egress SFF. As a packet to traverse the SFC from the ingress SFC node to the egress
the SFCs are generally unidirectional in nature, measurement of one- SFF. As SFCs are unidirectional in nature, measurement of one-way
way delay [RFC7679] is important. In order to measure one-way delay, delay [RFC7679] is important. In order to measure one-way delay,
time synchronization must be supported by means of NTP, PTP, GPS, time synchronization MUST be supported by means such as NTP, PTP,
etc. GPS, etc.
One-way delay variation [RFC3393] could also be measured by sending One-way delay variation [RFC3393] could also be calculated by sending
OAM packets and measuring the jitter between the packets passing OAM packets and measuring the jitter between the packets passing
through an SFC. through an SFC.
Some of the OAM functions supported by the performance measurement Some of the OAM functions supported by the performance measurement
functions are: functions are:
o Ability to measure the packet processing delay induced by a o Ability to measure the packet processing delay induced by a single
service function or the one-way delay to traverse a service SF or the one-way delay to traverse an SFP bound to a given SFC.
function path along an SFC.
o Ability to measure the packet loss [RFC7680] within a service o Ability to measure the packet loss [RFC7680] within an SF or an
function or a service function path bound to a given SFC. SFP bound to a given SFC.
5. Gap Analysis 5. Gap Analysis
This section identifies various OAM functions available at different This section identifies various OAM functions available at different
levels. It also identifies various gaps, if not all, existing within levels introduced in Section 2. It also identifies various gaps that
the existing toolset, to perform OAM function required for SFC. exist within the current toolset for performing OAM functions
required for SFC.
5.1. Existing OAM Functions 5.1. Existing OAM Functions
There are various OAM tool sets available to perform OAM functions There are various OAM tool sets available to perform OAM functions
within various layers. These OAM functions could validate some of within various layers. These OAM functions may be used to validate
the underlay and overlay networks. Tools like ping and trace are in some of the underlay and overlay networks. Tools like ping and trace
existence to perform connectivity check and tracing intermediate hops are in existence to perform connectivity check and tracing of
in a network. These tools support different network types like IP, intermediate hops in a network. These tools support different
MPLS, TRILL etc. There is also an effort to extend the tool set to network types like IP, MPLS, TRILL, etc. There is also an effort to
provide connectivity and continuity checks within overlay networks. extend the tool set to provide connectivity and continuity checks
BFD is another tool which helps in detecting data forwarding within overlay networks. BFD is another tool which helps in
failures. The following table is not exhaustive. detecting data forwarding failures. [RFC2330] and [RFC6374] defines
the performance metrics measurement in IP and MPLS network
respectively. [RFC8309] defines network and service orchestration
function. Tables 3 and 4 are not exhaustive.
Table 3: OAM Tool GAP Analysis
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
| Layer | Connectivity | Continuity | Trace | Performance| | Layer | Connectivity | Continuity | Trace | Performance|
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
| Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, MPLS | | Underlay N/w | Ping | E-OAM, BFD | Trace | IPPM, |
| | | | | MPLS_PM |
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
| Overlay N/w | Ping | BFD, NVo3 | Trace | IPPM | | Overlay N/w | Ping |BFD, NVo3 OAM| Trace | IPPM |
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
| SF | None + None + None + None | | SF | None + None + None + None |
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
| SFC | None + None + None + None | | SFC | None + None + None + None |
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+------------+
Table 3: OAM Tool GAP Analysis Table 4: OAM Tool GAP Analysis (contd.)
+----------------+--------------+-------------+--------+-------------+
+----------------+--------------+-------------+--------+------------+ | Layer |Configuration |Orchestration|Topology|Notification |
| Layer |Configuration |Orchestration|Topology|Notification| +----------------+--------------+-------------+--------+-------------+
+----------------+--------------+-------------+--------+------------+ | Underlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog,|
| Underlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| | | | | |NETCONF |
+----------------+--------------+-------------+--------+------------+ +----------------+--------------+-------------+--------+-------------+
| Overlay N/w |CLI, Netconf | CLI, Netconf|SNMP |SNMP, Syslog| | Overlay N/w |CLI, NETCONF | CLI, NETCONF|SNMP |SNMP, Syslog |
+----------------+--------------+-------------+--------+------------+ | | | | |NETCONF |
| SF |CLI, Netconf + CLI + None + None | +----------------+--------------+-------------+--------+-------------+
+----------------+--------------+-------------+--------+------------+ | SF |CLI, NETCONF + CLI, NETCONF| None | None |
| SFC |CLI, Netconf + CLI + None + None | +----------------+--------------+-------------+--------+-------------+
+----------------+--------------+-------------+--------+------------+ | SFC |CLI, NETCONF + CLI, NETCONF| None | None |
Table 4: OAM Tool GAP Analysis (contd.) +----------------+--------------+-------------+--------+-------------+
5.2. Missing OAM Functions 5.2. Missing OAM Functions
As shown in Table 3, OAM functions for SFC are not standardized yet. As shown in Table 3, there are no standards-based tools available for
Hence, there are no standard based tools available to verify SF and the verifications of SFs and SFCs.
SFC.
5.3. Required OAM Functions 5.3. Required OAM Functions
Primary OAM functions exist for underlying layers. Tools like ping, Primary OAM functions exist for underlying layers. Tools like ping,
trace, BFD, etc., exist in order to perform these OAM functions. trace, BFD, etc. exist in order to perform these OAM functions.
Configuration, orchestration and manageability of SF and SFC could be Configuration, orchestration and manageability of SF and SFC could be
performed using CLI, NETCONF, etc. performed using CLI, NETCONF, etc.
As depicted in Table 3 and 4, for configuration, manageability and As depicted in Tables 3 and 4, information and data models are needed
orchestration, providing data and information models for SFC is very for configuration, manageability and orchestration for SFC. With
much needed. With virtualized SF and SFC, manageability of these virtualized SF and SFC, manageability needs to be done
functions has to be done programmatically. programmatically.
6. SFC OAM Model 6. Candidate SFC OAM Tools
This section describes the operational aspects of SFC OAM at the This section describes the operational aspects of SFC OAM at the
Service layer to perform the SFC OAM function defined in Section 4 service layer to perform the SFC OAM function defined in Section 4
and analyze the applicability of various existing OAM toolsets in the and analyzes the applicability of various existing OAM toolsets in
service layer. the service layer.
6.1. SFC OAM Packet Marker 6.1. SFC OAM Packet Marker
SFC OAM function described in Section 4 performed at the service The SFC OAM function described in Section 4 performed at the service
layer or overlay network layer must mark the packet as OAM packet so layer or overlay network layer must mark the packet as an OAM packet
that relevant nodes can differentiate an OAM packet from data so that relevant nodes can differentiate an OAM packet from data
packets. The base header defined in Section 2.2 of [RFC8300] assigns packets. The base header defined in Section 2.2 of [RFC8300] assigns
a bit to indicate OAM packets. When NSH encapsulation is used at the 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. service layer, the O bit must be set to differentiate the OAM packet.
Any other overlay encapsulations used in future must have a way to Any other overlay encapsulations used in future must have a way to
mark the packet as OAM packet. mark the packet as OAM packet.
6.2. OAM Packet Processing and Forwarding Semantic 6.2. OAM Packet Processing and Forwarding Semantic
Upon receiving OAM packet, an SFC-aware SFs may choose to discard the Upon receiving an OAM packet, SFC-aware SFs may choose to discard the
packet if it does not support OAM functionality or if the local packet if it does not support OAM functionality or if the local
policy prevent it from processing OAM packet. When SF supports OAM policy prevents them from processing the OAM packet. When an SF
functionality, it is desired to process the packet and respond back supports OAM functionality, it is desirable to process the packet and
accordingly that helps with end-to-end verification. To avoid provide an appropriate response to allow end-to-end verification. To
hitting any performance impact, SFC-aware SFs can rate limit the limit performance impact due to OAM, SFC-aware SFs should rate limit
number of OAM packets processed. the number of OAM packets processed.
Service Function Forwarder (SFF) may choose not to forward the OAM An SFF may choose not to forward the OAM packet to an SF if the SF
packet to an SF if the SF does not support OAM function or if the does not support OAM or if the policy does not allow to forward OAM
policy does not allow to forward OAM packet to an SF. SFF may choose packet to an SF. The SFF may choose to skip the SF, modify the
to skip the SF, modify the header and forward to next SFC node in the header and forward to next SFC node in the chain. It should be noted
chain. Although, skipping an SF might have implication on some OAM that skipping an SF might have implication on some OAM functions
function (e.g., delay measurement may not be accurate). How SFF (e.g. the delay measurement may not be accurate). The method by
detects if the connected SF supports or allowed to process OAM packet which an SFF detects if the connected SF supports or is allowed to
is outside the scope of this document. It could be a configuration process OAM packets is outside the scope of this document. It could
parameter instructed by the controller or can be a dynamic be a configuration parameter instructed by the controller or it can
negotiation between SF and SFF. be done by dynamic negotiation between the SF and SFF.
If the SFF receiving the OAM packet bound to a given SFC is the last 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 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 of the OAM packet. Depending on the type of OAM solution and tool
set used, the response could be a simple response (ICMP reply or BFD set used, the response could be a simple response (such as ICMP
reply packet) or could include additional data from the received OAM reply) or could include additional data from the received OAM packet
packet (like stats data consolidated along the path). The proposed (like statistical data consolidated along the path). The details are
solution should detail it further. expected to be covered in the solution documents.
Any SFC-aware node that initiates OAM packet must set the OAM marker Any SFC-aware node that initiates an OAM packet must set the OAM
in the overlay encapsulation. marker in the overlay encapsulation.
6.3. OAM Function Types 6.3. OAM Function Types
As described in Section 4, there are different OAM functions that may As described in Section 4, there are different OAM functions that may
require different OAM solutions. While the presence of OAM marker in require different OAM solutions. While the presence of the OAM
the overlay header (e.g., O bit in the NSH header) indicates it as marker in the overlay header (e.g., O bit in the NSH header)
OAM packet, it is not sufficient to indicate what OAM function the indicates it as OAM packet, it is not sufficient to indicate what OAM
packet is intended for. The Next Protocol field in NSH header may be function the packet is intended for. The Next Protocol field in NSH
used to indicate what OAM function is it intended to or what toolset header may be used to indicate what OAM function is intended to or
is used. what toolset is used.
6.4. OAM Toolset applicability 6.4. OAM Toolset applicability
As described in Section 5.1, there are different tool sets available As described in Section 5.1, there are different tool sets available
to perform OAM functions at different layers. This section describes to perform OAM functions at different layers. This section describes
the applicability of some of the available toolsets in the service the applicability of some of the available toolsets in the service
layer. layer.
6.4.1. ICMP Applicability 6.4.1. ICMP Applicability
[RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6 [RFC0792] and [RFC4443] describes the use of ICMP in IPv4 and IPv6
network respectively. It explains how ICMP messages can be used to network respectively. It explains how ICMP messages can be used to
test the network reachability between different end points and test the network reachability between different end points and
perform basic network diagnostics. perform basic network diagnostics.
ICMP could be leveraged for basic OAM functions like SF availability ICMP could be leveraged for connectivity function (defined in
or SFC availability. The Initiator can generate ICMP echo request Section 4.1) to verify the availability of SF or SFC. The Initiator
message and control the service layer encapsulation header to get the can generate an ICMP echo request message and control the service
response from relevant node. For example, a classifier initiating layer encapsulation header to get the response from relevant node.
OAM can generate ICMP echo request message, can set the TTL field in For example, a classifier initiating OAM can generate ICMP echo
NSH header to 255 to get the response from last SFF and thereby test request message, can set the TTL field in NSH header to 255 to get
the SFC availability. Alternately, the initiator can set the TTL to the response from last SFF and thereby test the SFC availability.
other value to get the response from specific SFs and there by test Alternately, the initiator can set the TTL to some other value to get
partial SFC availability. Alternately, the initiator could send OAM the response from a specific SFs and there by test partial SFC
packets with sequentially incrementing the TTL in NSH header to trace availability. Alternately, the initiator could send OAM packets with
the SFP. sequentially incrementing the TTL in the NSH to trace the SFP.
It could be observed that ICMP at its current stage may not be able It could be observed that ICMP at its current stage may not be able
to perform all required SFC OAM functions, but as explained above, it to perform all required SFC OAM functions, but as explained above, it
can be used for basic OAM functions. can be used for basic OAM functions.
6.4.2. Seamless BFD Applicability 6.4.2. BFD/Seamless-BFD Applicability
[RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism [RFC5880] defines Bidirectional Forwarding Detection (BFD) mechanism
for fast failure detection. [RFC5881] and [RFC5884] defines the for fast failure detection. [RFC5881] and [RFC5884] defines the
applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880] applicability of BFD in IPv4, IPv6 and MPLS networks. [RFC7880]
defines Seamless BFD (S-BFD), a simplified mechanism of using BFD. defines Seamless BFD (S-BFD), a simplified mechanism of using BFD.
[RFC7881] explains its applicability in IPv4, IPv6 and MPLS network. [RFC7881] explains its applicability in IPv4, IPv6 and MPLS network.
S-BFD could be leveraged to perform SF or SFC availability. An BFD or S-BFD could be leveraged to perform SF or SFC availability.
initiator could generate BFD control packet and set the "Your An initiator could generate a BFD control packet and set the "Your
Discriminator" value as last SFF in the control packet. Upon Discriminator" value as last SFF in the control packet. Upon
receiving the control packet, last SFF will reply back with relevant receiving the control packet, the last SFF in the SFC will reply back
DIAG code. We could also use the TTL field in the NSH header to with relevant DIAG code. The TTL field in the NSH header could be
perform partial SFC availability. For example, the initiator can set used to perform partial SFC availability. For example, the initiator
the "Your Discriminator" value to the SF that is intended to be can set the "Your Discriminator" value to the SF that is intended to
tested and set the TTL field in NSH header in a way that it will be be tested and set the TTL field in NSH header in a way that it expire
expired on the relevant SF. How the initiator gets the Discriminator at the relevant SF. How the initiator gets the Discriminator value
value of the SF is outside the scope of this document. of the SF is outside the scope of this document.
6.4.3. In-Situ OAM 6.4.3. In-Situ OAM
[I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof [I-D.ietf-sfc-proof-of-transit] defines a mechanism to perform proof
of transit to securely verify if a packet traversed the relevant path of transit to securely verify if a packet traversed the relevant SFP
or chain. While the mechanism is defined inband (i.e, it will be or SFC. While the mechanism is defined inband (i.e., it will be
included in data packets), it can be used to perform various SFC OAM included in data packets), it may be used to perform various SFC OAM
functions as well. functions as well.
In-Situ OAM could be used with O bit set and perform SF availability, In-Situ OAM could be used with O bit set to perform SF availability
SFC availability of performance measurement. and SFC availability or performance measurement.
6.4.4. SFC Traceroute 6.4.4. SFC Traceroute
[I-D.penno-sfc-trace] defines a protocol that checks for path [I-D.penno-sfc-trace] defines a protocol that checks for path
liveliness and trace the service hops in any SFP. Section 3 of liveliness and traces the service hops in any SFP. Section 3 of
[I-D.penno-sfc-trace] defines the SFC trace packet format while [I-D.penno-sfc-trace] defines the SFC trace packet format while
section 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF
and SFF respectively. and SFF respectively.
An initiator can control the SIL in SFC trace packet to perform SF An initiator can control the Service Index Limit (SIL) in SFC trace
and SFC availability test. packet to perform SF and SFC availability test.
6.5. Security Considerations 7. Security Considerations
SFC and SF OAM must provide mechanisms for: Any security consideration defined in [RFC7665] and [RFC8300] are
applicable for this document.
o Preventing usage of OAM channel for DDOS attacks. The OAM information from 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 SFC layer raises a need for careful security
considerations
o OAM packets meant for a given SFC should not get leaked beyond The mapping and the rules information at the classifier component may
that SFC. reveal the traffic rules and the traffic mapped to the SFC. The SFC
information collected at an SFC component may reveal the SF
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.
o Prevent OAM packets to leak the information of an SFC beyond its The SF information at the SF component may be used by a malicious
administrative domain. user to trigger Denial of Service (DoS) attack by overloading any
specific SF using rogue OAM traffic.
6.6. IANA Considerations To address the above concerns, SFC and SF OAM may provide mechanism
for:
No action is required by IANA for this document. o Misuse of the OAM channel for denial-of-services,
6.7. Acknowledgements o Leakage of OAM packets across SFC instances, and
We would like to thank Mohamed Boucadair for his review and comments. o Leakage of SFC information beyond the SFC domain.
7. References The documents proposing the OAM solution for SF component should
consider rate-limiting the OAM probes at a frequency guided by the
implementation choice. Rate-limiting may be applied at the 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.
7.1. Normative References The documents proposing the OAM solution for any service layer
components should consider some form of message filtering to prevent
leaking any internal service layer information outside the
administrative domain.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 8. IANA Considerations
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. No action is required by IANA for this document.
9. Acknowledgements
We would like to thank Mohamed Boucadair, Adrian Farrel, and Greg
Mirsky for thier review and comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
Control Message Protocol (ICMPv6) for the Internet "Framework for IP Performance Metrics", RFC 2330,
Protocol Version 6 (IPv6) Specification", STD 89, DOI 10.17487/RFC2330, May 1998,
RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc2330>.
<https://www.rfc-editor.org/info/rfc4443>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Service Function Chaining", RFC 7498, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc6374>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
7.2. Informative References [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>.
10.2. Informative References
[I-D.ietf-sfc-proof-of-transit] [I-D.ietf-sfc-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A., Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Aguado, A.,
and D. Lopez, "Proof of Transit", draft-ietf-sfc-proof-of- and D. Lopez, "Proof of Transit", draft-ietf-sfc-proof-of-
transit-02 (work in progress), March 2019. transit-02 (work in progress), March 2019.
[I-D.penno-sfc-trace] [I-D.penno-sfc-trace]
Penno, R., Quinn, P., Pignataro, C., and D. Zhou, Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
"Services Function Chaining Traceroute", draft-penno-sfc- "Services Function Chaining Traceroute", draft-penno-sfc-
trace-03 (work in progress), September 2015. trace-03 (work in progress), September 2015.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc5881>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <https://www.rfc-editor.org/info/rfc5884>. June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>. <https://www.rfc-editor.org/info/rfc6291>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
skipping to change at page 18, line 15 skipping to change at page 19, line 39
Cisco Systems, Inc. Cisco Systems, Inc.
Email: naikumar@cisco.com Email: naikumar@cisco.com
Nobo Akiya Nobo Akiya
Big Switch Networks Big Switch Networks
Email: nobo.akiya.dev@gmail.com Email: nobo.akiya.dev@gmail.com
Ram Krishnan Ram Krishnan
Dell VMware
Email: ramkri123@gmail.com Email: ramkri123@gmail.com
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Email: anoop@alumni.duke.edu Email: anoop@alumni.duke.edu
 End of changes. 116 change blocks. 
343 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/