SFC WG T. Ao Internet-Draft ZTE Corporation Intended status: Standards Track G. Mirsky Expires: December 31, 2017 ZTE Corp. Z. Chen China Telecom June 29, 2017 Controlled Return Path for Service Function Chain (SFC) OAM draft-ao-sfc-oam-return-path-specified-00 Abstract This document defines extensions to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enable control of the Echo Reply return path by specifying it as Reverse Service Function Path. Enforcing the specific return path can be used to verify bidirectional connectivity of SFC and increase 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 http://datatracker.ietf.org/drafts/current/. 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 December 31, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Ao, et al. Expires December 31, 2017 [Page 1] Internet-Draft Controlled Return Path for SFC OAM June 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SFC Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 4 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 5.1. Case of Bi-directional SFC . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6 7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction While Echo Request, defined in [I-D.ooamdt-rtgwg-demand-cc-cv], always traverses the Service Function Chain (SFC) it directed to, the corresponding Echo Reply is sent over IP network [I-D.wang-sfc-multi-layer-oam]. There are scenarios when it is beneficial to direct the responder to use path other than the IP network. This document defines extensions to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enable control of the Echo Reply return path by specifying it as Reply Service Function Path. This document defines a new Type- Length-Value (TLV), Reply Service Function Path TLV, for Reply via Specified Path mode of Overlay Echo Reply (Section 4). The Reply Service Function Path TLV provides efficient mechanism to test bidirectional and hybrid SFCs, as these were defined in Section 2.2 [RFC7665], that allows an operator to test both directions of the bidirectional or hybrid SFP with a single Overlay Echo Request/Echo Reply operation. Ao, et al. Expires December 31, 2017 [Page 2] Internet-Draft Controlled Return Path for SFC OAM June 2017 2. Conventions used in this document 2.1. Terminology 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 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 Following reply modes had been defined in [I-D.ooamdt-rtgwg-demand-cc-cv]: o Do Not Reply o Reply via an IPv4/IPv6 UDP Packet o Reply via Application Level Control Channel o Reply via Specified Path The Reply via Specified Path mode is intended to enforce use of the particular return path specified in the included TLV. This mode may help to verify bidirectional continuity or increase robustness of the monitoring of the SFC by selecting more stable path. In case of SFC, the sender of Echo Request instructs the egress SFF to send Echo Reply message along the SFP specified in the SFC Reply Path TLV Section 4. Ao, et al. Expires December 31, 2017 [Page 3] Internet-Draft Controlled Return Path for SFC OAM June 2017 4. SFC Reply Path TLV The SFC Reply Path TLV carries the information that sufficiently identifies the return SFP that the Overlay Echo Reply message is expected to follow. The format of SFC Reply Path TLV is display 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 Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply Service Function Path | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SFC Reply TLV Format where: o Reply Path TLV Type: is 2 octets long, indicates the TLV that contains a information about the SFC Reply path. o Length: is 2 octets long, MUST be equal to 4 o Reply Service Function Path is used to describe the return path that an Overlay Echo Reply is requested to follow. 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 Path Identifier | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Reply Service Function Path Field Format where: o Reply Service Path Identifier: is SFP identifier for the path that the Overlay Echo Reply message is requested to be sent over. o Service Index: used for forwarding in the reply SFP. Ao, et al. Expires December 31, 2017 [Page 4] Internet-Draft Controlled Return Path for SFC OAM June 2017 5. Theory of Operation [RFC7110] defined mechanism to control return path for MPLS LSP Echo Reply. In case of SFC, the return path is a SFP along which Overlay Echo Reply message MUST be transmitted. Hence, the SFC Reply Path TLV included in the Overlay Echo Request message MUST sufficiently identify the SFP that the sender of the Echo Request message expects the receiver to use for the corresponding Overlay 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.ooamdt-rtgwg-demand-cc-cv], and MUST include SFC Reply Path TLV. The SFC Reply Path TLV includes identifier of the reverse SFP and an appropriate Service Index. Echo Reply is expected to be sent by the egress SFF of the SFP being tested or by the SFF at which SFC TTL expires as defined [I-D.ietf-sfc-nsh]. Processing described below equally applies in both cases and referred 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 requested SFP it MUST send Echo Reply with Return Code set to "Reply SFP was not found" and include the SFC Reply Path TLV from the Echo Request message. 5.1. Case of Bi-directional SFC Ability to specify the return path to be used for Echo Reply is very useful in bi-directional SFC. For bi-directional SFC, since the last SFF of the forward SFP may not co-locate with classifier of the reverse SFP,it is assumed that last SFF doesn't know the reply path of a SFC. So even for bi-directional SFC, a reverse SFP also need to be indicated in reply path TLV in echo request message. 6. Security Considerations Will be added in the future updates. 7. IANA Considerations Ao, et al. Expires December 31, 2017 [Page 5] Internet-Draft Controlled Return Path for SFC OAM June 2017 7.1. SFC Return Path Type IANA is requested to assign from its Overlay Echo Request/Echo Reply TLV registry new type as following: +-------+----------------------+---------------+ | Value | Description | Reference | +-------+----------------------+---------------+ | TBA1 | SFC Reply Path Type | This document | +-------+----------------------+---------------+ Table 1: SFC Return Path Type 7.2. New Return Codes IANA is requested to assign new return codes from the Overlay Echo Request/Echo Reply Return Codes registry as following: +-------+----------------------------+---------------+ | Value | Description | Reference | +-------+----------------------------+---------------+ | TBA2 | Reply Path TLV is missing | This document | | TBA3 | Reply SFP was not found | This document | +-------+----------------------------+---------------+ Table 2: SFC Overlay Echo Reply Return Codes 8. References 8.1. Normative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-12 (work in progress), February 2017. [I-D.ooamdt-rtgwg-demand-cc-cv] Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L., and D. Dolson, "Echo Request and Echo Reply for Overlay Networks", draft-ooamdt-rtgwg-demand-cc-cv-03 (work in progress), March 2017. [I-D.wang-sfc-multi-layer-oam] Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi- Layer OAM for Service Function Chains in Networks", draft- wang-sfc-multi-layer-oam-09 (work in progress), June 2017. Ao, et al. Expires December 31, 2017 [Page 6] Internet-Draft Controlled Return Path for SFC OAM June 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC7110] 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, January 2014, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . Authors' Addresses Ting Ao ZTE Corporation No.889, BiBo Road Shanghai 201203 China Phone: +86 21 68897642 Email: ao.ting@zte.com.cn Greg Mirsky ZTE Corp. 1900 McCarthy Blvd. #205 Milpitas, CA 95035 USA Email: gregimirsky@gmail.com Ao, et al. Expires December 31, 2017 [Page 7] Internet-Draft Controlled Return Path for SFC OAM June 2017 Zhonghua Chen China Telecom No.1835, South PuDong Road Shanghai 201203 China Phone: +86 18918588897 Email: 18918588897@189.cn Ao, et al. Expires December 31, 2017 [Page 8]