SFC WG T. Ao Internet-Draft ZTE Corporation Intended status: Standards Track G. Mirsky Expires: June 30, 2019 ZTE Corp. Z. Chen China Telecom K. Leung Cisco Dec 27, 2018 SFC OAM for path consistency draft-ao-sfc-oam-path-consistency-04 Abstract Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred in this document as the path consistency of the SFC. This document defines a new SFC OAM method to support SFC consistency check, i.e. verification that all elements of the given SFC are being traversed in the expected order. 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 https://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 June 30, 2019. Ao, et al. Expires June 30, 2019 [Page 1] Internet-Draft SFC OAM for path consistency Dec 2018 Copyright Notice Copyright (c) 2018 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3 3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. SFF Information Record TLV . . . . . . . . . . . . . . . 4 3.3. SF Information Sub-TLV . . . . . . . . . . . . . . . . . 5 3.4. SF Information Sub-TLV Construction . . . . . . . . . . . 6 3.4.1. Multiple SFs as hops of SFP . . . . . . . . . . . . . 6 3.4.2. Multiple SFs for load balance . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 8 5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 8 5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 8 5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informational References . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Service Function Chain (SFC) is a chain with a series of ordered Service Functions (SFs). Service Function Path (SFP) is a path of a SFC. SFC is described in detail in the SFC architecture document [RFC7665]. The SFs in the SFC are ordered and only when one SF processes traffic then it can be processed by the next SF. Otherwise errors may occur. Sometimes, a SF needs to use the metadata from its Ao, et al. Expires June 30, 2019 [Page 2] Internet-Draft SFC OAM for path consistency Dec 2018 upstream SF process. That's why it's very important for the operator to make sure that the order of traversing the SFs is exactly as defined by the control plane or the orchestrator. This document refers to the correspondence between the state of the control plane and the SFP itself as the SFP consistency. This document defines the method to check the path consistency of the SFP. It is an extension of the SFC Echo-request/Echo-reply specified in the [I-D.ietf-sfc-multi-layer-oam]. 2. Conventions used in this document 2.1. Terminology SFC(Service Function Chain): An ordered set of some abstract SFs. SFF: Service Function Forwarder SF: Service Function OAM: Operation, Administration and Maintenance SFP: Service Function Path COAM(Consistency OAM): OAM that can be used to check the consistency of the Service Function Path. 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. Consistency OAM: Theory of Operation Consistency OAM uses two functions: COAM Request and COAM Reply. The SFF, that is ingress of the SFP, transmits COAM Request packet. Every intermediate SFF that receives the COAM Request MUST perform the following actions: o Collect information of traversed by the COAM Request packet SFs and send it to the ingress SFF as COAM Reply packet over IP network [I-D.ietf-sfc-multi-layer-oam]; o Forward the COAM Request to next downstream SFF if the one exists. Ao, et al. Expires June 30, 2019 [Page 3] Internet-Draft SFC OAM for path consistency Dec 2018 As result, the ingress SFF collects information about all traversed SFFs and SFs, information of the actual path the COAM packet has traveled, so that we can verify the path consistency of the SFC. The mechanism for the SFP consistency verification is outside the scope of this document. 3.1. COAM packet Consistency OAM introduces two new types of messages to the SFC Echo request/reply operation [I-D.ietf-sfc-multi-layer-oam] with the following values Section 5.1: o TBA1 - COAM Request o TBA2 - COAM Reply Upon receiving the Consistency OAM(COAM) Request, the SFF MUST respond with the COAM Reply. The SFF MUST include the SFs information, as as described in Section 3.3 and Section 3.2. The COAM packet is displayed in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return S.code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: COAM Packet Header 3.2. SFF Information Record TLV For COAM Request, the SFF MUST include the Information of SFs into the SF Information Record TLV in the COAM Reply message. Every SFF send back one COAM Reply Message with all the SFs that are attaching to the SFF along the SFP indicated by the COAM Request. Ao, et al. Expires June 30, 2019 [Page 4] Internet-Draft SFC OAM for path consistency Dec 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFF Record TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Identifier(SPI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SF Information Sub-TLV | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SFF Information Record TLV Service Path Identifier(SPI): The identifier of SFP to which all the SFs in this TLV belong. SF Information Sub-TLV: The Sub-TLV as defined in Figure 3. 3.3. SF Information Sub-TLV Every SFF receiving COAM Request packet MUST include the SF characteristic data into the COAM Reply packet. The per SF data included in COAM Reply packet as SF Information sub-TLV that is displayed in Figure 3. After the COAM traversed the SFP, all the information of the SFs on the SFP are collected from the TLVs with COAM Reply. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF sub-TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Service Index | SF Type | SF ID Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Identifiers | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Service Function information sub-TLV SF sub-TLV Type: Two octets long field. It indicates that the TLV is a SF TLV which contains the information of one SF. Ao, et al. Expires June 30, 2019 [Page 5] Internet-Draft SFC OAM for path consistency Dec 2018 Length: Two octets long field. The value of the field is the length of the data following the Length field counted in octets. Service Index: Indicates the SF's position on the SFP. SF Type: Two octets long field. It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, e.g., Firewall, Deep Packet Inspection, WAN optimization controller, etc. Reserved: For future use. MUST be zeroed on transmission and MUST be ignored on receipt. SF ID Type: One octet long field with values defined as Section 5.4. SF Identifier: An identifier of the SF. The length of the SF Identifier depends on the type of the SF ID Type. For example, if the SF Identifier is its IPv4 address, the SF Identifier should be 32 bits. SF ID Type and SF Identifier may be a list, indicating the list of the SFs are in load balance group. 3.4. SF Information Sub-TLV Construction Each SFF in the SFP MUST send one and only one COAM Reply corresponding to the COAM Request. If there is only one SF attached to the SFF in such SFP, only one SF information sub-TLV is included in the on COAM Reply. If there are several SFs attached to the SFF in the SFP, SF Information Sub-TLV MUST be constructed as described below in either Section 3.4.1 and Section 3.4.2. 3.4.1. Multiple SFs as hops of SFP Multiple SFs attached to one SFF are the hops of the SFP, the service indexes of these SFs are different. Service function types of these SFs could be different or be the same. Information about all SFs MAY be included in the COAM Reply message. Information about each SF MUST be listed as separate SF Information Sub-TLVs in the COAM Reply message. An example of the COAM procedure for this case is shown in Figure 4. The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1,SF2 and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM Request message is sent to the SFFs in the sequence of the SFP(SFF1->SFF2->SFF1). Every SFF(SFF1,SFF2) replies with the information of SFs belonging to the SFP. The SF information Sub-TLV in Figure 3 contains information for each SF(SF1, SF2,SF3 and SF4). Ao, et al. Expires June 30, 2019 [Page 6] Internet-Draft SFC OAM for path consistency Dec 2018 SF1 SF2 SF4 SF3 +------+------+ | | COAM Req ......> SFF1 ......> SFF2 ......> SFF1 (SPI=x) . . . <............ <.......... <........... COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3) Figure 4: Example 1 for COAM Reply with multiple SFs 3.4.2. Multiple SFs for load balance Multiple SFs may be attached to one SFF to balance the load, in other words, that means that the particular traffic flow will transmit only one of these SFs . These SFs have the same Service Function Type and Service Index. For this case, the SF identifiers and SF ID Type of all these SFs will be listed in the SF Identifiers field and SF ID Type in a single SF information sub-TLV of COAM Reply message. The number of these SFs can be calculated according to SF ID Type and the value of Length field of the sub-TLV. An example of the COAM procedure for this case is shown in Figure 4. The Service Function Path(SPI=x) is SF1a/SF1b->SF2a/SF2b. The Service Functions SF1a and SF1b are attached to SFF1 which are load balance for each other, and the Service Functions SF2a and SF2b are attached to SFF2 which are load balance for each other as well. The COAM Request message is sent to the SFFs in the sequence of the SFP (i.e. SFF1->SFF2). Every SFF(SFF1,SFF2) replies with the information of SFs belonging to the SFP. The SF information Sub-TLV in Figure 3 contains information for all SFs at that hop. /SF1a /SF2a \SF1b \SF2b | | SFF1 SFF2 COAM Req .........> . .........> . (SPI=x) . . <............ <............... COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b}) Figure 5: Example 2 for COAM Reply with multiple SFs 4. Security Considerations Security considerations discussed in [RFC8300] apply to this document. Ao, et al. Expires June 30, 2019 [Page 7] Internet-Draft SFC OAM for path consistency Dec 2018 Also, since Service Function sub-TLV discloses information about the SFP the spoofed COAM Request packet may be used to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of COAM Request messages, specified in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access list before accepting the message. 5. IANA Considerations 5.1. COAM Message Types IANA is requested to assign values from its Message Types sub- registry in SFC Echo Request/Echo Reply Message Types registry as follows: +-------+------------------------------+---------------+ | Value | Description | Reference | +-------+------------------------------+---------------+ | TBA1 | SFP Consistency Echo Request | This document | | TBA2 | SFP Consistency Echo Reply | This document | +-------+------------------------------+---------------+ Table 1: SFP Consistency Echo Request/Echo Reply Message Types 5.2. SFF Information Record TLV Type IANA is requested to assign new type value from SFC OAM TLV Type registry as follows: +-------+-----------------------------+---------------+ | Value | Description | Reference | +-------+-----------------------------+---------------+ | TBA3 | SFF Information Record Type | This document | +-------+-----------------------------+---------------+ Table 2: SFF-Information Record 5.3. SF Information Sub-TLV Type IANA is requested to assign new type value from SFC OAM TLV Type registry as follows: Ao, et al. Expires June 30, 2019 [Page 8] Internet-Draft SFC OAM for path consistency Dec 2018 +-------+----------------+---------------+ | Value | Description | Reference | +-------+----------------+---------------+ | TBA4 | SF Information | This document | +-------+----------------+---------------+ Table 3: SF-Information Sub-TLV Type 5.4. SF Identifier Types IANA is requested create in the registry SF Types the new sub- registry SF Identifier Types. All code points in the range 1 through 191 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126] and assign values as follows: +------------+-------------+-------------------------+ | Value | Description | Reference | +------------+-------------+-------------------------+ | 0 | Reserved | This document | | TBA6 | IPv4 | This document | | TBA7 | IPv6 | This document | | TBA8 | MAC | This document | | TBA8+1-191 | Unassigned | IETF Review | | 192-251 | Unassigned | First Come First Served | | 252-254 | Unassigned | Private Use | | 255 | Reserved | This document | +------------+-------------+-------------------------+ Table 4: SF Identifier Type 6. Acknowledgements Thanks to John Drake for his review and the reference to the work on BGP Control Plane for NSH SFC. Thanks to Joel M. Halpern for their suggestion about the load balance scenario. 7. References 7.1. Normative References [I-D.ietf-bess-nsh-bgp-control-plane] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- nsh-bgp-control-plane-04 (work in progress), July 2018. Ao, et al. Expires June 30, 2019 [Page 9] Internet-Draft SFC OAM for path consistency Dec 2018 [I-D.ietf-sfc-multi-layer-oam] Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active OAM for Service Function Chains in Networks", draft-ietf- sfc-multi-layer-oam-00 (work in progress), November 2018. [I-D.ietf-sfc-nsh-tlv] Quinn, P., Elzur, U., and S. Majee, "Network Service Header TLVs", draft-ietf-sfc-nsh-tlv-00 (work in progress), January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . 7.2. Informational References [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 Ao, et al. Expires June 30, 2019 [Page 10] Internet-Draft SFC OAM for path consistency Dec 2018 Greg Mirsky ZTE Corp. 1900 McCarthy Blvd. #205 Milpitas, CA 95035 USA Email: gregimirsky@gmail.com Zhonghua Chen China Telecom No.1835, South PuDong Road Shanghai 201203 China Phone: +86 18918588897 Email: 18918588897@189.cn Kent Leung Cisco Email: kleung@cisco.com Ao, et al. Expires June 30, 2019 [Page 11]