NVO3 Working Group G. Mirsky Internet-Draft X. Min Intended status: Standards Track ZTE Corp. Expires: January 6, 2020 S. Boutros VmWare, Inc. D. Black Dell EMC July 5, 2019 OAM for use in GENEVE draft-mmbb-nvo3-geneve-oam-00 Abstract This document defines encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol. Also, the format and operation of the Echo Request and Echo Reply mechanism in Geneve are defined. 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 January 6, 2020. Copyright Notice Copyright (c) 2019 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 Mirsky, et al. Expires January 6, 2020 [Page 1] Internet-Draft OAM in GENEVE July 2019 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 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 2. OAM Protocols Encapsulation in Geneve Networks . . . . . . . 3 2.1. OAM Encapsulation in Geneve . . . . . . . . . . . . . . . 4 3. Associated Channel in Geneve Networks . . . . . . . . . . . . 5 4. Associate Channel Header in Geneve . . . . . . . . . . . . . 5 4.1. Use of the Geneve ACh Header in Active OAM . . . . . . . 6 5. Echo Request and Echo Reply in Geneve Tunnel . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. Geneve Associated Channel Protocol Types . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Geneve [I-D.ietf-nvo3-geneve] is intended to support various scenarios of network virtualization. In addition to carrying multi- protocol payload, e.g., Ethernet, IPv4/IPv6, the Geneve message includes metadata. Operations, Administration, and Maintenance (OAM) protocols support fault management and performance monitoring functions necessary for comprehensive network operation. Active OAM protocols, as defined in [RFC7799], use specially constructed packets, that are injected into the network. To ensure that the measured performance metric or the detected failure of the transport layer are related to the particular Geneve flow, it is critical that these test packets share fate with overlay data packets when traversing the underlay network. This document describes several options for encapsulation of active OAM protocols in Geneve. These are intended to facilitate the discussion among experts and all interested in both OAM and Geneve subjects. The goal of such analysis is the selection of one encapsulation method and providing Also, a set of generic requirements for active OAM protocols in Geneve overlay network introduced in this document. These should be Mirsky, et al. Expires January 6, 2020 [Page 2] Internet-Draft OAM in GENEVE July 2019 used in selecting the most suitable encapsulation for active OAM in Geneve. 1.1. Conventions used in this document 1.1.1. Terminology CC Continuity Check CV Connectivity Verification FM Fault Management GAL Generic Associated Channel Label G-ACh Generic Associated Channel Header Geneve Generic Network Virtualization Encapsulation NVO3 Network Virtualization Overlays OAM Operations, Administration, and Maintenance ACh Associated Channel 1.1.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. 2. OAM Protocols Encapsulation in Geneve Networks OAM protocols, whether it is part of fault management or performance monitoring, intended to provide reliable information that can be used to detect a failure, identify the defect, localize it, thus helping to apply corrective actions to minimize the negative impact on service. Several OAM protocols will be used to perform these functions, protocols that require demultiplexing at the receiving instance of Geneve. To improve the accuracy of the correlation between the condition experienced by the monitored Geneve tunnel and the state of the OAM protocol the OAM encapsulation is required to comply with the following requirements: REQ#1: Geneve OAM packets SHOULD share the fate with data traffic of the monitored Geneve tunnel, i.e., be in-band with the Mirsky, et al. Expires January 6, 2020 [Page 3] Internet-Draft OAM in GENEVE July 2019 monitored traffic, follow precisely the same overlay and transport path as packets with data payload, in the forward direction, i.e. from ingress toward egress endpoint(s) of the OAM test. REQ#2: Encapsulation of OAM control message and data packets in underlay network MUST be indistinguishable from the underlay network forwarding point of view. REQ#3: Presence of OAM control message in Geneve packet MUST be unambiguously identifiable. REQ#4: It MUST be possible to express entropy for underlay Equal Cost Multipath in Geneve encapsulation to avoid using data packet content by underlay transient nodes. 2.1. OAM Encapsulation in Geneve One of the options is to use IP/UDP encapsulation for active OAM. In this case OAM protocols are identified by destination UDP port number. This approach is well-known and has been used, for example, in MPLS networks. To use IP/UDP encapsulation for an active OAM protocol the Protocol Type field of the Geneve header MUST be set to IPv4 (0x0800) or IPv6 (0x86DD) value. But extra IP/UDP headers that immediately follow the Geneve header adds to processing of OAM message, further disassociates OAM message from the Geneve header, all of which may cause false negative or positive failure reports. Also, the additional IP/UDP header adds noticeable overhead, especially if the underlay is the IPv6 network. Another option is to use the Protocol Type field to demultiplex an active OAM protocols directly. Such method avoids the use of additional intermediate header but requires that each active OAM protocol be assigned unique identifier from the Ether Types registry maintained by IANA. The alternative to using the Protocol Type directly is to use a shim that, in turn, identifies the OAM Protocol and, optionally, includes additional information. [RFC5586] defines how the Generic Associated Channel Label (GAL) can be used to identify that the Associated Channel Header (ACH), defined in [RFC4385], immediately follows the Bottom-of-the-Stack label. Thus the MPLS Generic Associated Channel can be identified, and protocols are demultiplexed based on the value of the Channel Type field. Number of channel types, e.g., for continuity check and performance monitoring, already have been defined and are listed in IANA MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types) registry. To use this approach, the value of the Protocol Type field in the Geneve header MUST be set to MPLS. The Geneve header MUST be Mirsky, et al. Expires January 6, 2020 [Page 4] Internet-Draft OAM in GENEVE July 2019 immediately followed by the GAL label with the S flag set to indicate that GAL is the Bottom-of-the-stack label. Then ACH MUST follow the GAL label and the value of the Channel Type identifies which of active OAM protocols being encapsulated in the packet. Lastly, an associated channel can be defined directly for a Geneve tunnel. This document defines the shim for Geneve is presented in Figure 1 to demultiplex Geneve OAM protocols without much of the overhead. The value of the Protocol Type MAY be set to 0x8902, the value assigned to IEEE 802.1ag Connectivity Fault Management protocol as part of [IEEE.8021Q] and shared by ITU-T G.8013/Y.1731 OAM functions and mechanisms for Ethernet-based networks [ITU-T.1731]. Alternatively, the new value MAY be requested from the Ether Types registry. 3. Associated Channel in Geneve Networks An associated channel in the Geneve network is the channel that, by using the same encapsulation as user traffic, follows the same path through the underlay network as user traffic. In other words, the associated channel is in-band with user traffic. Creating the notion of the associated channel (ACh) in the Geneve network ensures that packets of active OAM protocols carried in the ACh are in-band with user traffic. 4. Associate Channel Header in Geneve ACh Header immediately follows the Geneve header defined in [I-D.ietf-nvo3-geneve] and identifies the type of message carried over the Geneve ACh. The format of the Geneve ACh Header is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Msg Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the Associated Channel Header in Geneve Network The ACh Header consists of the following fields: o V - two bits long field indicates the current version of the ACh Header. The current value is 0b00; o Msg Type - 14 bits long field identifies a protocol. In the case of active OAM, these could be Echo Request/Reply, BFD, Performance Measurement; Mirsky, et al. Expires January 6, 2020 [Page 5] Internet-Draft OAM in GENEVE July 2019 o Length - two octets long field that is the length of the packet in octets; 4.1. Use of the Geneve ACh Header in Active OAM Active OAM methods, whether used for fault management or performance monitoring, generate dedicated test packets [RFC7799]. Format of an OAM test packet in Geneve network presented 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Underlay network encapsulation ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ |Ver| Opt Len |O|C| Rsvd. | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Geneve | Virtual Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header | Variable Length Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ | V | Msg Type | Length | ACh +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------ ~ Active OAM message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Geneve OAM Header in Active OAM Packet 5. Echo Request and Echo Reply in Geneve Tunnel [Ed.note] Will be expanded in the future versions. 6. IANA Considerations IANA is requested to create a new registry called "Geneve Associated Channel". 6.1. Geneve Associated Channel Protocol Types IANA is requested to create new sub-registry called "Geneve Associated Channel Protocol Types" in the "Geneve Associated Channel" registry. All code points in the range 1 through 15615 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 1: Mirsky, et al. Expires January 6, 2020 [Page 6] Internet-Draft OAM in GENEVE July 2019 +---------------+--------------+-------------------------+ | Value | Description | Reference | +---------------+--------------+-------------------------+ | 0 | Reserved | | | 1 - 15615 | Unassigned | IETF Review | | 15616 - 16127 | Unassigned | First Come First Served | | 16128 - 16143 | Experimental | This document | | 16144 - 16382 | Private Use | This document | | 16383 | Reserved | This document | +---------------+--------------+-------------------------+ Table 1: Geneve OAM Protocol type 7. Security Considerations TBD 8. Acknowledgment TBD 9. References 9.1. Normative References [I-D.ietf-nvo3-geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", draft-ietf- nvo3-geneve-13 (work in progress), March 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Mirsky, et al. Expires January 6, 2020 [Page 7] Internet-Draft OAM in GENEVE July 2019 9.2. Informative References [IEEE.8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014. [ITU-T.1731] ITU-T, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T G.8013/Y.1731, August 2015. [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [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, . Authors' Addresses Greg Mirsky ZTE Corp. Email: gregimirsky@gmail.com Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn Sami Boutros VmWare, Inc. Email: sboutros@vmware.com David Black Dell EMC 176 South Street Hopkinton, MA 01748 United States of America Email: david.black@dell.com Mirsky, et al. Expires January 6, 2020 [Page 8]