Internet-Draft Controlled Return Path for SFC OAM March 2021
Mirsky, et al. Expires 1 October 2021 [Page]
Intended Status:
Standards Track
G. Mirsky
ZTE Corp.
T. Ao
Individual contributor
Z. Chen
China Telecom
G. Mishra
Verizon Inc.

Controlled Return Path for Service Function Chain (SFC) OAM


This document defines an extension to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enables control of the Echo Reply return path directing it over a Reverse Service Function Path. Enforcing the specific return path can be used to verify the bidirectional connectivity of SFC and increase the robustness of SFC OAM.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 1 October 2021.

Table of Contents

1. Introduction

While Service Function Chain (SFC) Echo Request, defined in [I-D.ietf-sfc-multi-layer-oam], always traverses the SFC it directed to, the corresponding Echo Reply is sent over IP network [I-D.ietf-sfc-multi-layer-oam]. There are scenarios when it is beneficial to direct the responder to use a path other than the IP network. This document extends Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) by enabling control of the Echo Reply return path to be directed over a Reply Service Function Path (SFP). Such an extension is based on the analysis of SFC OAM, active OAM protocols, in particular, provided in [RFC8924]. This document defines a new Type-Length-Value (TLV), Reply Service Function Path TLV, for Reply via Specified Path mode of SFC Echo Reply (Section 4).

The Reply Service Function Path TLV can provide an efficient mechanism to test SFCs, such as bidirectional and hybrid SFC, as defined in Section 2.2 [RFC7665]. For example, it allows an operator to test both directions of the bidirectional or hybrid SFP with a single SFC Echo Request/Echo Reply operation.

2. Conventions used in this document

2.1. Acronyms

SF - Service Function

SFF - Service Function Forwarder

SFC - Service Function Chain, an ordered set of some abstract SFs.

SFP - Service Function Path

SPI - Service Path Index

OAM - Operation, Administration, and Maintenance

MAC - Message Authentication Code

2.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Extension

The following reply modes had been defined in [I-D.ietf-sfc-multi-layer-oam]:

The Reply via Specified Path mode is intended to enforce the use of the particular return path specified in the included TLV. This mode may help verify bidirectional continuity or increase SFC monitoring's robustness by selecting a more stable path. In SFC's case, the sender of Echo Request instructs the destination SFF to send Echo Reply message along the SFP specified in the SFC Reply Path TLV, as described in Section 4.

4. SFC Reply Path TLV

The SFC Reply Path TLV carries the information that sufficiently identifies the return SFP that the SFC Echo Reply message is expected to follow. The format of SFC Reply Path TLV is shown in Figure 1.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |SFC Reply Path |    Reserved   |          Length               |
       |                 Reply Service Function Path                   |
Figure 1: SFC Reply TLV Format


The format of the Reply Service Function Path field displayed in Figure 2

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |    Reply Service Function Path Identifier     | Service Index |
Figure 2: Reply Service Function Path Field Format


5. Theory of Operation

[RFC7110] defined mechanism to control return path for MPLS LSP Echo Reply. In SFC's case, the return path is an SFP along which the SFC Echo Reply message MUST be transmitted. Hence, the SFC Reply Path TLV included in the SFC Echo Request message MUST sufficiently identify the SFP that the sender of the Echo Request message expects the receiver to use for the corresponding SFC Echo Reply.

When sending an Echo Request, the sender MUST set the value of Reply Mode field to "Reply via Specified Path", defined in [I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC path, the Request MUST include SFC Reply Path TLV. The SFC Reply Path TLV includes the identifier of the reverse SFP and an appropriate Service Index.

The Message Authentication Code (MAC) Context Header that is defined in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC Echo Request's integrity when using the SFC Return Path TLV. If the NSH of the received SFC Echo Request includes the MAC Context Header, the packet's authentication MUST be verified before using any data. If the verification fails, the receiver MUST stop processing the SFC Return Path TLV and MUST send the SFC Echo Reply with the Return Codes value set to the value Authentication failed from the IANA's Return Codes sub-registry of the SFC Echo Request/Echo Reply Parameters registry.

Echo Reply is expected to be sent by the destination SFF of the SFP being tested or by the SFF at which SFC TTL expires as defined [RFC8300]. The processing described below equally applies to both cases and is referred to as responding SFF.

If the Echo Request message with SFC Reply Path TLV, received by the responding SFF, has Reply Mode value of "Reply via Specified Path" but no SFC Reply Path TLV is present, then the responding SFF MUST send Echo Reply with Return Code set to "Reply Path TLV is missing" value (TBA2). If the responding SFF cannot find the requested SFP it MUST send Echo Reply with Return Code set to "Reply SFP was not found" (TBA3) and include the SFC Reply Path TLV from the Echo Request message.

Suppose the SFC Echo Request receiver cannot determine whether the specified return path SFP has the route to the initiator. In that case, it SHOULD set the value of the Return Codes field to "Unverifiable Reply Path" (TBA4). The receiver MAY drop the Echo Request when it cannot determine whether SFP's return path has the route to the initiator. That means, when sending Echo Request, the sender SHOULD choose a proper source address according to specified return path SFP to help the receiver to make the decision.

5.1. Bi-directional SFC Case

The ability to specify the return path for an Echo Reply might be used in the case of bi-directional SFC. The egress SFF of the forward SFP might not be co-located with a classifier of the reverse SFP, and thus the egress SFF has no information about the reverse path of an SFC. Because of that, even for bi-directional SFC, a reverse SFP needs to be indicated in a Reply Path TLV in the Echo Request message.

6. Security Considerations

Security considerations discussed in [RFC8300] apply to this document.

The SFC Return Path extension, defined in this document, can be used for potential "proxying" attacks. For example, the Echo Request initiator may specify a return path with a destination different from that of the initiator. Such attacks will usually not happen in an SFC domain where the initiators and receivers belong to the same domain, as specified in [RFC7665]. Even if the attack occurs, to prevent using the SFC Return Path extension for proxying any possible attacks, the return path SFP SHOULD have a path to reach the sender of the Echo Request, identified in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam]. The MAC Context Header that is defined in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the integrity of the SFC Echo Request/Reply when using the SFC Return Path TLV.

7. IANA Considerations

7.1. SFC Return Path Type

IANA is requested to assign from its SFC Echo Request/Echo Reply TLV registry new type as follows:

Table 1: SFC Return Path Type
Value Description Reference
TBA1  SFC Reply Path Type  This document

7.2. New Return Codes

IANA is requested to assign new return codes from the SFC Echo Request/Echo Reply Return Codes sub-registry of the SFC Echo Request/Echo Reply Parameters registry as defined in Table 2.

Table 2: SFC Echo Reply Return Codes
Value Description Reference
TBA2  Reply Path TLV is missing  This document
TBA3  Reply SFP was not found  This document
TBA4  Unverifiable Reply Path  This document

8. References

8.1. Normative References

Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active OAM for Service Function Chaining", Work in Progress, Internet-Draft, draft-ietf-sfc-multi-layer-oam-09, , <>.
Boucadair, M., Reddy, T., and D. Wing, "Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, , <>.

8.2. Informative References

Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, , <>.
Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <>.
Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, R., and A. Ghanwani, "Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework", RFC 8924, DOI 10.17487/RFC8924, , <>.

Authors' Addresses

Greg Mirsky
ZTE Corp.
Ting Ao
Individual contributor
No.889, BiBo Road
Zhonghua Chen
China Telecom
No.1835, South PuDong Road
Gyan Mishra
Verizon Inc.