RFC 8924

Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework

📅 published October 2020, from ietf

RFC 8924: Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework 💖

Okay bestie, here's the deets 🎀. This is RFC 8924, an Informational doc from October 2020, and it's the Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework. The authors are S. Aldrin (Google), C. Pignataro, Ed. (Cisco), N. Kumar, Ed. (Cisco), R. Krishnan (VMware), and A. Ghanwani (Dell). It's published under ISSN 2070-1721 🦋. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

Abstract

This doc gives us a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC) 🧚. It's giving foundation.

Status of This Memo

Real talk first: this is not an Internet Standards Track spec. It's published for informational purposes 📚.

It's an IETF product 💅. It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full picture 🙈.

For the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8924 🌸.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 🔥.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc 💜. Code Components pulled from this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶.

Table of Contents

1.  Introduction
  1.1.  Document Scope
  1.2.  Acronyms and Terminology
    1.2.1.  Acronyms
    1.2.2.  Terminology
2.  SFC Layering Model
3.  SFC OAM Components
  3.1.  The SF Component
    3.1.1.  SF Availability
    3.1.2.  SF Performance Measurement
  3.2.  The SFC Component
    3.2.1.  SFC Availability
    3.2.2.  SFC Performance Measurement
  3.3.  Classifier Component
  3.4.  Underlay Network
  3.5.  Overlay Network
4.  SFC OAM Functions
  4.1.  Connectivity Functions
  4.2.  Continuity Functions
  4.3.  Trace Functions
  4.4.  Performance Measurement Functions
5.  Gap Analysis
  5.1.  Existing OAM Functions
  5.2.  Missing OAM Functions
  5.3.  Required OAM Functions
6.  Operational Aspects of SFC OAM at the Service Layer
  6.1.  SFC OAM Packet Marker
  6.2.  OAM Packet Processing and Forwarding Semantic
  6.3.  OAM Function Types
7.  Candidate SFC OAM Tools
  7.1.  ICMP
  7.2.  BFD / Seamless BFD
  7.3.  In Situ OAM
  7.4.  SFC Traceroute
8.  Manageability Considerations
9.  Security Considerations
10. IANA Considerations
11. Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

Service Function Chaining (SFC) lets you build composite services out of an ordered set of Service Functions (SFs) that get applied to any traffic picked out by classification [RFC7665]. It's more than just running SFs in order on selected traffic. SFC is a way of deploying SFs that allows dynamic ordering, topological independence, and the exchange of metadata between the participating entities 🎀. If you want the foundations, check out these two:

The reader is assumed to already know the material in [RFC7665] 🧚.

This doc is a reference framework for Operations, Administration, and Maintenance (OAM) [RFC6291] of SFC. Specifically, it gives us:

  • an SFC layering model (Section 2),
  • aspects monitored by SFC OAM (Section 3),
  • functional requirements for SFC OAM (Section 4),
  • a gap analysis for SFC OAM (Section 5),
  • operational aspects of SFC OAM at the service layer (Section 6),
  • applicability of various OAM tools (Section 7), and
  • manageability considerations for SF and SFC (Section 8).

SFC OAM solution documents should refer back to this doc to say which SFC OAM component they're targeting and what functionality they cover 💅.

OAM controllers are SFC-aware network devices that can generate OAM packets. They should live in the same administrative domain as the target SFC-enabled domain 🌈.

1.1. Document Scope

This doc is all about giving SFC OAM an architectural framework, with the spotlight on the Operations part of OAM 🦋. The actual solutions and mechanisms? Totally out of scope, so don't look for them here 🙈.

1.2. Acronyms and Terminology

1.2.1. Acronyms

Here's the acronym list, exactly as written:

BFD        Bidirectional Forwarding Detection

CLI        Command-Line Interface

DWDM       Dense Wavelength Division Multiplexing

E-OAM      Ethernet OAM

hSFC       Hierarchical Service Function Chaining

IBN        Internal Boundary Node

IPPM       IP Performance Metrics

MPLS       Multiprotocol Label Switching

MPLS_PM    MPLS Performance Measurement

NETCONF    Network Configuration Protocol

NSH        Network Service Header

NVO3       Network Virtualization over Layer 3

OAM        Operations, Administration, and Maintenance

POS        Packet over SONET

RSP        Rendered Service Path

SF         Service Function

SFC        Service Function Chain

SFF        Service Function Forwarder

SFP        Service Function Path

SNMP       Simple Network Management Protocol

TRILL      Transparent Interconnection of Lots of Links

VM         Virtual Machine

1.2.2. Terminology

This doc uses the terminology from [RFC7665] and [RFC8300], and readers are expected to know it 🧠.

2. SFC Layering Model 🍓

Lots of layers are in play when you implement SFC 🫶. These include the service layer and the layers underneath it (network layer, link layer, and so on).

  • The service layer is made of SFC data-plane elements: classifiers, Service Functions (SFs), Service Function Forwarders (SFF), and SFC Proxies. This layer relies on the overlay network layer to keep those data-plane elements connected 💜.
  • The overlay network layer uses overlay network technologies (for example, Virtual eXtensible Local Area Network (VXLAN)) to interconnect the SFC data-plane elements and to set up Service Function Paths (SFPs). It's mostly invisible to the data-plane elements, since not all of them process the overlay header 🦋.
  • The underlay network layer is set by whatever networking technology is deployed in the network (for example, IP or MPLS) 🌸.
  • The link layer is tightly bound to the physical technology underneath it. Ethernet is one choice, but others can be used too (for example, POS and DWDM). In a virtual environment, virtualized I/O technologies like Single Root I/O Virtualization (SR-IOV) or similar also apply to this layer. The same or different link layer technologies can be used on each leg shown in Figure 1 ✨.
     o----------------------Service Layer----------------------o

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

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

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

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

                      Figure 1: SFC Layering Example

In Figure 1, the service-layer stuff like the classifier and the SFs is shown as virtual entities hooked up through an overlay network 🎀. The underlay network might have a bunch of intermediate nodes that aren't drawn in the figure, and those nodes provide the underlay connectivity between the service-layer elements 🧚.

Figure 1 shows SFs as virtual entities, but the SFC architecture doesn't assume anything about how the SFC data-plane elements get deployed. It's flexible enough for physical or virtual entities, or any mix of the two 🌈. SFC OAM is built to handle that flexibility, so it works whether the data-plane elements run directly on physical hardware, as one or more virtual entities, or in any combination 💖.

3. SFC OAM Components 🎀

Okay so bestie, the SFC operates at the service layer 💅 To define the OAM framework, we chop that service layer into three distinct components ✨

SF component 🧚: OAM functions here include testing the SFs from any SFC-aware network device (think classifiers, controllers, and other service nodes) 💖 Testing an SF can go way beyond just checking connectivity to it. You can check if the SF is actually providing its intended service 🔥 More on that in Section 3.1.1.

SFC component 🌸: OAM functions here include (but aren't limited to) testing the SFCs and the SFPs, and validating the correlation between an SFC and the actual forwarding path a matching packet takes 👑 That actual path is called the Rendered Service Path (RSP) 🦋 Some hops of an SFC might not be visible when Hierarchical Service Function Chaining (hSFC) [RFC8459] is in use 🙈 In those schemes, the Internal Boundary Node (IBN) is responsible for gluing the connectivity between levels so you get end-to-end OAM functionality 🫶

Classifier component 🌈: OAM functions here include testing that the classification rules are valid and detecting any incoherence among the rules when more than one classifier is used, as explained in Section 2.2 of [RFC7665] 💜

Figure 2 shows an example where OAM for all three components is used in the SFC environment 🍓

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

                      Figure 2: SFC OAM Components

Honestly, it's expected that lots of SFC OAM solutions will get defined, each one targeting a specific component 🎀 BUT the big deal is that all together, the SFC OAM solutions have to cover all three components: the SF component, the SFC component, and the classifier component 😭🔥

3.1. The SF Component

3.1.1. SF Availability ✨

One SFC OAM requirement for the SF component is letting an SFC-aware network device check the availability of a specific SF (instance), whether it lives on the same network device or a different one 🦋 If multiple instances of an SF are used for load sharing, you can check the availability of any one of those instances, or you can target a specific instance 💅 Now here's the interesting question: how do you actually determine that an SF is available? 🤔 On one end, you could argue an SF is available enough if the service node (physical or virtual) hosting it is up and functional 🙄 On the other end, you could argue the SF's availability can only be deduced if the packet was examined after passing through the SF and verified to have gotten the expected service 👀

The first approach won't really give you confidence about the SF's actual availability, because a service node and an SF are two different entities 💀 The second approach can verify a lot more, but it comes at a cost 💸 Some SFs modify packets, while others don't 🧚 And some SFs exist to intentionally drop certain packets, so it's totally normal for certain packets to never come out of the SF 🙈 The OAM mechanism needs to account for those SF specifics when assessing availability 🫶 There are SO many flavors of SFs out there, and more are coming 🌈 Even a single SF can gain new functionality later (like a new signature in a firewall) ✨ So the cost here is that the OAM mechanism for some SFs will need constant updates to "keep up" with new functionality 😭

The SF availability check can use a generalized approach, meaning at a granularity good enough to provide a basic SF service 💖 Evaluating an SF's true availability is genuinely complex, and there's currently no simple, unified solution for it 💜 There's also no standard way to do it yet 🥺 Any mechanism like that would be far from a typical OAM function, so it isn't explored as part of the analysis in Sections 4 and 5 🎀

3.1.2. SF Performance Measurement 🌸

The second SFC OAM requirement for the SF component is letting an SFC-aware network device check performance metrics, like loss and delay induced by a specific SF while processing legitimate traffic 🔥 Performance measurement can be passive (using live traffic), active (using synthetic probe packets), or hybrid (a mix of active and passive) 🦋 More details on this OAM function are in Section 4.4 🧚

You can quantify an SF's performance by measuring the loss and delay of the traffic going from the SFF to that SF 💅 Or you can measure it by leveraging the loss and delay metrics from the SFs themselves 👑 The second way needs SF involvement to measure, while the first doesn't 🙈 When multiple instances of an SF are used for load sharing, you can quantify SF performance by measuring the metrics for any one instance or for a specific instance 🫶

Loss and delay aren't the only metrics that matter 💖 Others, like throughput, exist too, and choosing which metrics to measure is outside the scope of this document 🌈

3.2. The SFC Component

3.2.1. SFC Availability ✨

An SFC could contain varying SFs, so the OAM layer is required to validate and verify the SFs within an SFP, on top of connectivity verification and fault isolation 💅

To verify service connectivity for an SFC/SFP, OAM functions could be started from any SFC-aware network device in an SFC-enabled domain, covering end-to-end paths or partial paths that terminate on a specific SF within the SFC/SFP 🦋 The goal is to make sure the chained SFs have connectivity, just as intended when the SFC was established 💜 The necessary return codes should be defined so they can be sent back in the response to the OAM packet, to complete the verification 🎀

When ECMP is in use at the service layer for any given SFC, there MUST be the ability to discover and traverse all available paths 🔥

A detailed explanation of the mechanism is outside the scope of this document and is expected to be covered in the actual solution document 🧚

3.2.2. SFC Performance Measurement 🌸

Any SFC-aware network device SHOULD have the ability to measure performance over the entire SFC (end-to-end) or over a specific segment of SFs within the SFC 💖

3.3. Classifier Component 🌈

A classifier maintains the classification rules that map a flow to a specific SFC 👑 It's vital that the classifier is configured correctly with updated classification rules and is working as expected 😭 The SFC OAM MUST be able to validate the classification rules by checking whether a flow is mapped to the right SFC, and detect any misclassification 🔥 Sample OAM packets can be presented to classifiers to assess behavior for a given classification entry 🫶

The classifier availability check may be performed to confirm that the classifier is available to apply the rules and classify traffic flows 🦋 Any SFC-aware network device SHOULD have the ability to check the availability of the classifier component for each SFC 💅

Any SFC-aware network device SHOULD have the ability to measure the performance of the classifier component for each SFC 💜 That performance can be quantified by measuring the performance metrics of traffic from the classifier for each SFC/SFP ✨

3.4. Underlay Network 🧚

The underlay network provides connectivity between the SFC components, so the availability or performance of the underlay network directly impacts SFC OAM 💀

Any SFC-aware network device MAY have the ability to perform an availability check or performance measurement of the underlay network using any existing OAM functions listed in Section 5.1 🎀

3.5. Overlay Network 🦋

The overlay network provides connectivity for the service plane between the SFC components and is mostly transparent to the SFC data-plane elements 🌸

Any SFC-aware network device MAY have the ability to perform an availability check or performance measurement of the overlay network using any existing OAM functions listed in Section 5.1 🫶

4. SFC OAM Functions 💅

Section 3 covered the SFC OAM components and the OAM operations on each of them 👑 This section explores SFC OAM functions that apply to more than one SFC component 🔥

The SFC OAM requirements in Section 3 highlight the need for various OAM functions at the service layer 🧚 As listed in Section 5.1, plenty of OAM functions already exist, defined to do OAM at different layers 🦋 To apply them at the service layer, they need to be enhanced so they can operate on a single SF/SFF or on multiple SFs/SFFs spanning one or more SFCs 💖

4.1. Connectivity Functions 🌈

Connectivity is mainly an on-demand function that verifies connectivity between certain network elements and checks that the SFs are available ✨ For example, LSP Ping [RFC8029] is a common tool for this on an MPLS network 💜 Some of the OAM functions connectivity functions perform are:

  • Verify the Path MTU from a source to the destination SF or through the SFC 🎀 This requires the OAM packet to be able to vary in length 🌸
  • Detect any packet reordering and corruption 😭
  • Verify that an SFC or SF is applying the expected policy 🔥
  • Verify and validate forwarding paths 🫶
  • Proactively test alternate or protected paths to make sure network configurations are reliable 💅

4.2. Continuity Functions 💓

Okay bestie, continuity is basically a heartbeat check 💓. OAM messages get sent periodically to check that a given SF inside an SFC (or the whole SFC) is still reachable. That way a monitoring device, like the classifier or controller, can catch trouble fast: link failures, network element failures, SF outages, or SFC outages. BFD [RFC5880] is one protocol that's seriously good at spotting failures quickly 🏃‍♀️💨. Continuity functions can also:

  • Set up a continuity check to a given SF within an SFC, or for the entire SFC 🎀
  • Proactively test alternate or protected paths, so the network configs stay reliable 🛡️
  • Tell other OAM functions or applications about the failures they found, so they can respond 📣

4.3. Trace Functions 🕵️‍♀️

Tracing is an OAM function that lets the operation kick off an action (like generating a response) from every transit device (SFF, SF, and SFC Proxy) on the layer being tested. It's super useful for collecting info from every transit device, or for pinpointing exactly which SF in an SFC (or the entire SFC) is the problem 🔍. Some of the OAM functions trace functions can handle:

  • the ability to trigger an action from every transit device at the SFC layer, using TTL or other means,
  • the ability to trigger every transit device at the SFC layer to generate a response with OAM code(s) using TTL or other means,
  • the ability to discover and traverse ECMP paths within an SFC, and
  • the ability to skip SFs that do not support OAM while tracing SFs in an SFC.

4.4. Performance Measurement Functions 📊

Performance measurement is all about measuring packet loss, delay, delay variance, and so on 💅. These metrics may be measured proactively or on demand.

SFC OAM should give you the power to measure packet loss for an SFC ✨. On-demand measurement can estimate packet loss using statistical methods. For those estimates to be accurate, the OAM packets have to get treated the same way as regular data traffic, and they need to share the same fate as that traffic 🫶.

Delay within an SFC could be measured by timing how long a packet takes to travel the SFC, from the ingress SFC node all the way to the egress SFF ⏱️. Measurement protocols like the One-Way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can measure delay characteristics. Since SFCs are unidirectional, measuring one-way delay [RFC7679] is important 💜. To measure one-way delay, time synchronization must be supported by something like NTP, GPS, Precision Time Protocol (PTP), etc. 🕰️

One-way delay variation [RFC3393] could also be calculated by sending OAM packets and measuring the jitter for traffic passing through an SFC 🦋.

Some of the OAM functions that performance measurement can handle are:

  • the ability to measure the packet processing delay induced by a single SF, or the one-way delay to traverse an SFP bound to a given SFC, and
  • the ability to measure the packet loss [RFC7680] within an SF or an SFP bound to a given SFC.

5. Gap Analysis 🔍

This section looks at the various OAM functions available at the different layers introduced in Section 2. It also calls out the gaps in the current toolset for the OAM functions SFC needs 🧐.

5.1. Existing OAM Functions 🧰

There's a whole bunch of OAM toolsets out there for different layers 🎒. These can be used to validate some of the underlay and overlay networks. Tools like ping and trace handle connectivity checks and tracing intermediate hops, and they support different network types like IP, MPLS, TRILL, etc. Ethernet OAM (E-OAM) [Y.1731] [EFM] and Connectivity Fault Management (CFM) [DOT1Q] bring mechanisms like a continuity check for Ethernet links. There's also work happening on NVO3 OAM, which aims to provide connectivity and continuity checks for networks that use NVO3 🌈. BFD is used to detect data-plane forwarding failures. The IPPM framework [RFC2330] offers tools like OWAMP [RFC4656] and TWAMP [RFC5357] (we're calling these IPPM in this section) to measure various performance metrics. MPLS Packet Loss Measurement (LM) and Packet Delay Measurement (DM) (we're calling these MPLS_PM in this section) [RFC6374] can measure performance metrics in MPLS networks. There's also effort going into extending the toolset for connectivity and continuity checks within overlay networks, and BFD is another tool that helps detect data forwarding failures 💖. Table 1 below is not exhaustive, so don't treat it like the full list 🙈.

  +============+==============+============+=======+=============+
  | Layer      | Connectivity | Continuity | Trace | Performance |
  +============+==============+============+=======+=============+
  | Underlay   | Ping         | E-OAM, BFD | Trace | IPPM,       |
  | network    |              |            |       | MPLS_PM     |
  +------------+--------------+------------+-------+-------------+
  | Overlay    | Ping         | BFD, NVO3  | Trace | IPPM        |
  | network    |              | OAM        |       |             |
  +------------+--------------+------------+-------+-------------+
  | Classifier | Ping         | BFD        | Trace | None        |
  +------------+--------------+------------+-------+-------------+
  | SF         | None         | None       | None  | None        |
  +------------+--------------+------------+-------+-------------+
  | SFC        | None         | None       | None  | None        |
  +------------+--------------+------------+-------+-------------+

                   Table 1: OAM Tool Gap Analysis

5.2. Missing OAM Functions 😭

As Table 1 shows, there are no standards-based tools available at the time of this writing that can be used natively (i.e., without enhancement) to verify SFs and SFCs. Big oof 💀.

5.3. Required OAM Functions 📋

Primary OAM functions already exist for the underlying layers. Tools like ping, trace, BFD, etc. exist to perform these OAM functions 👑.

As Table 1 depicts, toolsets and solutions are required to perform the OAM functions at the service layer 🫠.

6. Operational Aspects of SFC OAM at the Service Layer 🎀

This section covers the operational side of SFC OAM at the service layer, so it can perform the SFC OAM functions defined in Section 4. It also looks at how well the various existing OAM toolsets apply at the service layer 💅.

6.1. SFC OAM Packet Marker 🏷️

SFC OAM messages should be encapsulated with the necessary SFC header and with OAM markings when testing the SFC component. SFC OAM messages may be encapsulated with the necessary SFC header and with OAM markings when testing the SF component.

The SFC OAM function described in Section 4, when performed at the service layer or overlay network layer, must mark the packet as an OAM packet so relevant nodes can tell OAM packets apart from data packets 🔖. The base header defined in Section 2.2 of [RFC8300] assigns a bit to indicate OAM packets. When NSH encapsulation is used at the service layer, the O bit must be set to differentiate the OAM packet. Any other overlay encapsulations used at the service layer must have a way to mark the packet as an OAM packet 🌸.

6.2. OAM Packet Processing and Forwarding Semantic 🚦

When an SFC-aware SF receives an OAM packet, it may choose to discard it if it doesn't support OAM functionality or if local policy stops it from processing OAM packets 🙅‍♀️. When an SF does support OAM functionality, it is desirable to process the packet and send back an appropriate response so end-to-end verification can happen ✅. To keep OAM from hurting performance, SFC-aware SFs should rate-limit the number of OAM packets they process 🐢.

An SFF may choose to not forward the OAM packet to an SF if the SF doesn't support OAM, or if policy doesn't allow OAM packets to be forwarded to that SF. The SFF may choose to skip the SF, modify the packet's header, and forward the packet to the next SFC node in the chain 🦘. It should be noted that skipping an SF might have implications for some OAM functions (e.g., the delay measurement may not be accurate) ⚠️. How an SFF detects whether the connected SF supports OAM packets, or is allowed to process them, is outside the scope of this document 🤷‍♀️. It could be a configuration parameter instructed by the controller, or it can be done through dynamic negotiation between the SF and SFF.

If the SFF receiving the OAM packet bound to a given SFC is the last SFF in the chain, it must send a relevant response to the initiator of the OAM packet 📬. Depending on the OAM solution and toolset used, the response could be a simple one (such as an ICMP reply), or it could include additional data from the received OAM packet (like statistical data gathered along the path). The details are expected to be covered in the solution documents 📄.

Any SFC-aware node that initiates an OAM packet must set the OAM marker in the overlay encapsulation 🫶.

6.3. OAM Function Types 🧩

As described in Section 4, there are different OAM functions that may require different OAM solutions 🌈. The OAM marker in the overlay header (for example, the O bit in the NSH header) tells you the packet is an OAM packet, but that alone isn't enough to show which OAM function the packet is meant for 🤔. The Next Protocol field in the NSH header may be used to indicate which OAM function is intended, or which toolset is being used. Any other overlay encapsulations used at the service layer must have a similar way to indicate the intended OAM function 💜.

7. Candidate SFC OAM Tools 🛠️

As described in Section 5.1, there are different toolsets available to perform OAM functions at different layers. This section describes how some of the available toolsets apply at the service layer 💖.

7.1. ICMP 🏓

[RFC0792] and [RFC4443] describe the use of ICMP in IPv4 and IPv6 networks, respectively. They explain how ICMP messages can be used to test network reachability between different end points and to run basic network diagnostics 🔌.

ICMP could be leveraged for connectivity functions (defined in Section 4.1) to verify the availability of an SF or SFC. The initiator can generate an ICMP echo request message and control the service-layer encapsulation header so the response comes back from the relevant node 🎯. For example, a classifier initiating OAM can generate an ICMP echo request message, set the TTL field in the NSH header [RFC8300] to 63 to get the response from the last SFF, and thereby test the SFC availability 🦋. Alternatively, the initiator can set the TTL to some other value to get the response from a specific SF, and thereby partially test SFC availability. Or the initiator could send OAM packets with sequentially incrementing TTL in the NSH to trace the SFP 🕵️‍♀️.

It could be observed that ICMP as currently defined may not be able to perform all required SFC OAM functions. But as explained above, it can be used for some of the connectivity functions 🥹✨.

7.2. BFD / Seamless BFD

okay bestie, BFD is the failure detection mechanism from [RFC5880] 🦋 and [RFC5881] and [RFC5884] are the parts that say where BFD works, in IPv4, IPv6, and MPLS networks 🌸. Then [RFC7880] brings in Seamless BFD (S-BFD), which is a simpler way of using BFD ✨, and [RFC7881] explains where S-BFD fits in those same IPv4, IPv6, and MPLS networks 💅.

so BFD or S-BFD could be used for the continuity function of an SF or an SFC 🎀. an initiator can generate a BFD control packet and set the Your Discriminator value in that packet to point at the last SFF 👑. when the last SFF gets the control packet, it replies with the relevant DIAG code 💜. the TTL field in the NSH header could also help with a partial SFC availability check 🧚. like, the initiator can set Your Discriminator to identify the SF it wants to test, and then set the TTL field in the NSH header so the packet expires right at that relevant SF 😭🫶. how the initiator gets the Discriminator value that identifies the SF is outside the scope of this document 🙈.

7.3. In Situ OAM

[IOAM-NSH] is the one that defines how In situ OAM data fields [IPPM-IOAM-DATA] get carried in the NSH header 🌈. [PROOF-OF-TRANSIT] defines a mechanism for proof of transit, which lets you securely verify whether a packet actually went through the relevant SFP or SFC 🔐. the proof of transit mechanism is defined inband (so it lives inside the data packets themselves), but IOAM Option-Types, like the IOAM Trace Option-Types, can also be used for other SFC OAM functions, such as SFC tracing 🍓.

in situ OAM could be used for SF availability, SFC availability, or performance measurement ✨. for example, if the SFC is realized using NSH, the O bit in the NSH header could be set to indicate OAM traffic, as defined in Section 4.2 of [IOAM-NSH] 💖.

7.4. SFC Traceroute

[SFC-TRACE] is a protocol that checks path liveliness and traces the service hops in any SFP 🦋. Section 3 of [SFC-TRACE] has the SFC trace packet format 📦, and Sections 4 and 5 of [SFC-TRACE] describe how SF and SFF behave 💅. now, [SFC-TRACE] has expired 💀, but the proposal is implemented in Open Daylight and is available 🌸, so it's still very much around and usable ✨.

an initiator can control the Service Index Limit (SIL) in an SFC trace packet to run SF and SFC availability tests 🎀.

8. Manageability Considerations

this document doesn't define any brand-new manageability tools 🙈. what it does do is bring together the manageability tool gap analysis for SF and SFC 🧚. Table 2 below is not exhaustive, so don't treat it like the full list 💜.

   +===========+===============+===============+========+==============+
   |Layer      | Configuration | Orchestration |Topology|Notification  |
   +===========+===============+===============+========+==============+
   |Underlay   | CLI, NETCONF  | CLI, NETCONF  |SNMP    |SNMP, Syslog, |
   |network    |               |               |        |NETCONF       |
   +-----------+---------------+---------------+--------+--------------+
   |Overlay    | CLI, NETCONF  | CLI, NETCONF  |SNMP    |SNMP, Syslog, |
   |network    |               |               |        |NETCONF       |
   +-----------+---------------+---------------+--------+--------------+
   |Classifier | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
   +-----------+---------------+---------------+--------+--------------+
   |SF         | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
   +-----------+---------------+---------------+--------+--------------+
   |SFC        | CLI, NETCONF  | CLI, NETCONF  |None    |None          |
   +-----------+---------------+---------------+--------+--------------+

                       Table 2: OAM Tool Gap Analysis

configuration, orchestration, and other manageability tasks for SF and SFC could be done using CLI, NETCONF [RFC6241], and so on 🌷.

NETCONF capabilities are already readily available, as Table 2 shows 📊. but the information and data models are still needed for configuration, manageability, and orchestration for SFC 🥺. with virtualized SF and SFC, manageability has to be done programmatically 🤖💕.

9. Security Considerations 🔐

okay this section is serious, so listen up 👀💀.

any security considerations defined in [RFC7665] and [RFC8300] apply to this document too 💅.

the OAM information from the service layer at different components may reveal sensitive information, either collectively or on its own 😱. it could reveal the types of service functions hosted in the network, the classification rules and the service chains tied to them, specific service function paths, and more 🫣. the sensitivity of information from the SFC layer means we really need to think carefully about security 🛡️✨.

the mapping and rules information at the classifier component may reveal the traffic rules and the traffic that gets mapped to the SFC 🗺️. the SFC information collected at an SFC component may reveal which SFs are associated with each chain 🔗. that info, together with the classifier rules, could be used to manipulate the header of synthetic attack packets, which could then be used to bypass the SFC and trigger internal attacks 🚨💀.

the SF information at the SF component could be used by a malicious user to trigger a Denial of Service (DoS) attack 🌩️ by overloading a specific SF with rogue OAM traffic 😤.

to address these concerns, SFC and SF OAM should provide mechanisms for mitigating:

  • misuse of the OAM channel for denial of services,
  • leakage of OAM packets across SFC instances, and
  • leakage of SFC information beyond the SFC domain.

the documents proposing an OAM solution for SF components should provide rate-limiting of 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 probes that are rate-limited, which results 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 any technique used to detect and mitigate anomalies and various security attacks 🕵️‍♀️💜.

the documents proposing an OAM solution for any service-layer components should consider some form of message filtering, so they can control the OAM packets entering the administrative domain or prevent leaking any internal service-layer information outside the administrative domain 🚧🫶.

10. IANA Considerations 🌈

this document has no IANA actions 🎀.

11. Informative References 📚

Okay, bestie, here's the reading list. These are the outside docs this spec leans on, and I'm keeping every single detail so nothing gets lost in translation 🫶

Acknowledgements 🙏

Huge, heartfelt thank-yous to Mohamed Boucadair, Adrian Farrel, Greg Mirsky, Tal Mizrahi, Martin Vigoureux, Tirumaleswar Reddy, Carlos Bernados, Martin Duke, Barry Leiba, Éric Vyncke, Roman Danyliw, Erik Kline, Benjamin Kaduk, Robert Wilton, Frank Brockner, Alvaro Retana, Murray Kucherawy, and Alissa Cooper for reviewing and commenting. You all are literally the reason this is good 💖

Contributors 🌸

Nobo Akiya Ericsson

Email: nobo.akiya.dev@gmail.com

Authors' Addresses 🎀

Sam K. Aldrin Google

Email: aldrin.ietf@gmail.com

Carlos Pignataro (editor) Cisco Systems, Inc.

Email: cpignata@cisco.com

Nagendra Kumar (editor) Cisco Systems, Inc.

Email: naikumar@cisco.com

Ram Krishnan VMware

Email: ramkri123@gmail.com

Anoop Ghanwani Dell

Email: anoop@alumni.duke.edu

📦 where this page comes from