rtgwg N. Kumar Internet-Draft C. Pignataro Intended status: Informational D. Kumar Expires: September 22, 2016 Cisco Systems, Inc. G. Mirsky Ericsson M. Chen Huawei Technologies E. Nordmark Arista Networks S. Pallagatti Juniper Networks D. Mozes Mellanox Technologies Ltd March 21, 2016 Overlay OAM Requirements draft-ooamdt-rtgwg-ooam-requirement-00 Abstract This document describes a list of functional requirements for Operations Administration and Maintenance (OAM) in various Overlay and Service networks like Service Function Chaining (SFC), Bit Index Explicit Replication (BIER), Network Virtualization over Layer 3 (NVO3). 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 September 22, 2016. Kumar, et al. Expires September 22, 2016 [Page 1] Internet-Draft Overlay OAM Requirements March 2016 Copyright Notice Copyright (c) 2016 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 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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Detailed Requirement List . . . . . . . . . . . . . . . . . . 4 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Pro-active Fault Management . . . . . . . . . . . . . 5 4.1.2. On-demand Fault Management . . . . . . . . . . . . . 5 4.2. Performance Management . . . . . . . . . . . . . . . . . 5 4.3. Alarm Indication Suppression . . . . . . . . . . . . . . 6 4.4. Overlay Network Resiliency . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction We have witnessed and participated in design of new paradigms in the networking that are aimed to address network virtualization, service function chaining, and multicast services. New paradigms require new architectural concepts, principles and components. [RFC7365] defines a framework for Data Center Network Virtualization over Layer 3 (NVO3). [RFC7665] describes the architecture for creating and maintaining Service Function Chains (SFCs) in a network. [I-D.ietf-bier-architecture] defines a stateless multicast architecture for optimal multicast packet forwarding using "Bit Index Explicit Replication" (BIER). These frameworks are defined in a Kumar, et al. Expires September 22, 2016 [Page 2] Internet-Draft Overlay OAM Requirements March 2016 flexible manner that they are transport agnostic and may be deployed on various underlay networks such as IPv4, IPv6 and MPLS. The above mentioned new architectural concepts and principles have been combined into new network layers with distinct encapsulation headers. For example, [I-D.ietf-sfc-nsh] defines an encapsulation header as Network Service Header (NSH) to realize Service Function Path. While [RFC7348] (VxLAN) and [RFC7637] (NVGRE) are different encapsulation header proposed for NVO3, [I-D.ietf-nvo3-vxlan-gpe] extends VxLAN further to be used for Service Function Chain (SFC). Similarly, [I-D.ietf-bier-mpls-encapsulation] defines the BIER encapsulation header over MPLS network and [I-D.xu-bier-encapsulation] describes the BIER encapsulation header over IP network. Introduction of the new Overlay networks, sets forth new Operations, Administration and Maintenance (OAM) requirements that can be addressed by enhancing the existing toolset or developing new protocols. For example, [I-D.ietf-sfc-oam-framework] defines the framework for SFC OAM, [I-D.nordmark-nvo3-transcending-traceroute] proposes a way to perform traceroute in NVO3 networks and [I-D.kumarzheng-bier-ping] proposes on-demand connectivity verification and fault isolation procedure (Ping and Trace) on BIER network. The goal of this document is to identify and list the OAM requirements commonly applicable to new Overlay networks which can further be used to analyze the existing OAM tools. The identified gaps can be addressed, either through enhancing existing OAM tools and if necessary, constructing new OAM tools, that can be used as a common unified OAM toolset to support and perform various OAM functions including proactive and on-demand path monitoring and service validation on the new Overlay network. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology ECMP: Equal Cost Multipath UCMP: Unequal Cost Multipath SFC: Service Function Chaining Kumar, et al. Expires September 22, 2016 [Page 3] Internet-Draft Overlay OAM Requirements March 2016 BIER: Bit Index Explicit Replication NVO3: Network Virtualization over L3 OAM: Operations, Administration and Maintenance MPLS: Multiprotocol Label Switching VxLAN: Virtual Extensible Local Area Network NVGRE: Network Virtualization Using Generic Routing Encapsulation 4. Detailed Requirement List This section list the OAM requirement for different Overlay networks. The below listed requirement MUST be supported with any underlay transport network: REQ#1: The listed requirements MUST be supported with any type of transport layer over which the overlay network can be realized REQ#2: It MUST be possible to initialize Overlay OAM session from any node in the overlay network. REQ#3: It SHOULD be possible to initialize an Overlay OAM session from a centralized controller. REQ#4: Overlay OAM MUST support proactive and on-demand OAM monitoring and measurement methods. REQ#5: Overlay OAM MUST support unidirectional OAM methods, both continuity check and performance measurement. REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic, i.e. in-band with the monitored traffic, i.e. follow exactly the same path as data plane traffic, in forward direction, i.e. from ingress toward egress end point(s) of the OAM test session. REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such OAM methods MAY combine in-band monitoring or measurement in forward direction and out-of-band notification in the reverse direction, i.e. from egress to ingress end point of the OAM test session. Kumar, et al. Expires September 22, 2016 [Page 4] Internet-Draft Overlay OAM Requirements March 2016 4.1. Fault Management 4.1.1. Pro-active Fault Management Availability, not as performance metric, is understood as ability to reach the node, i.e. the fact that path between ingress and egress does exist. Such OAM mechanism also referred as Continuity Check. REQ#8: Overlay OAM MUST support pro-active monitoring of any virtual node availability in the given overlay network. REQ#9: Overlay OAM MUST support Reverse Defect Indication (RDI) notification by egress to the ingress, i.e. source of continuity checking. REQ#10: Overlay OAM MUST support connectivity verification. Definition of mis-connectivity defect entry and exit criteria are outside the scope of this document. 4.1.2. On-demand Fault Management REQ#11: Overlay OAM MUST support fault localization of Loss of Continuity check. REQ#12: Overlay OAM MUST support tracing path in overlay network through the virtual nodes. REQ#13: Overlay OAM MAY support verification of the mapping between its data plane state and client layer services. REQ#14: Overlay OAM MUST have the ability to discover and exercise equal cost multipath (ECMP) paths in its transport network. REQ#15: Overlay OAM MUST be able to trigger on-demand FM with responses being directed towards initiator of such proxy request. 4.2. Performance Management REQ#16: Overlay OAM MUST support active one-way packet delay measurement. REQ#17: Overlay OAM MUST support passive one-way packet delay measurement. REQ#18: Overlay OAM MUST support active two-way packet delay measurement. Kumar, et al. Expires September 22, 2016 [Page 5] Internet-Draft Overlay OAM Requirements March 2016 REQ#19: Overlay OAM MUST support packet delay variation measurement. REQ#20: Overlay OAM MUST support active end to end packet loss measurement. REQ#21: Overlay OAM MUST support passive end to end packet loss measurement. REQ#22: Overlay OAM SHOULD support active per-segment packet delay measurement. REQ#23: Overlay OAM SHOULD support passive per-segment packet delay measurement. REQ#24: Overlay OAM SHOULD support active per-segment packet loss measurement. REQ#25: Overlay OAM SHOULD support passive per-segment packet loss measurement. REQ#26: Overlay OAM MUST support delivered packet throughput measurement. 4.3. Alarm Indication Suppression REQ#27: Overlay OAM MUST support defect notification mechanism, like Alarm Indication Signal. REQ#28: Any virtual node in the given overlay network MAY originate a defect notification addressed to any node in that network. 4.4. Overlay Network Resiliency REQ#29: Overlay OAM MUST support methods to enable survivability of an overlay network. These recovery methods MAY use protection switching and restoration. 5. IANA Considerations This document does not propose any IANA consideration. 6. Security Considerations This document list the OAM requirement for various Overlay network and does not raise any security considerations. Kumar, et al. Expires September 22, 2016 [Page 6] Internet-Draft Overlay OAM Requirements March 2016 7. Acknowledgement TBD 8. References 8.1. Normative References [I-D.ietf-bier-architecture] Wijnands, I., Rosen, E., Dolganow, A., P, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-03 (work in progress), January 2016. [I-D.ietf-bier-mpls-encapsulation] Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and S. Aldrin, "Encapsulation for Bit Index Explicit Replication in MPLS Networks", draft-ietf-bier-mpls- encapsulation-03 (work in progress), February 2016. [I-D.ietf-nvo3-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-01 (work in progress), November 2015. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-02 (work in progress), January 2016. [I-D.ietf-sfc-oam-framework] Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. Ghanwani, "Service Function Chaining Operation, Administration and Maintenance Framework", draft-ietf-sfc- oam-framework-01 (work in progress), February 2016. [I-D.kumarzheng-bier-ping] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- bier-ping-02 (work in progress), December 2015. [I-D.nordmark-nvo3-transcending-traceroute] Nordmark, E., Appanna, C., and A. Lo, "Layer-Transcending Traceroute for Overlay Networks like VXLAN", draft- nordmark-nvo3-transcending-traceroute-01 (work in progress), October 2015. Kumar, et al. Expires September 22, 2016 [Page 7] Internet-Draft Overlay OAM Requirements March 2016 [I-D.xu-bier-encapsulation] Xu, X., Somasundaram, S., Jacquenet, C., and R. Raszuk, "BIER Encapsulation", draft-xu-bier-encapsulation-03 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 8.2. Informative References [I-D.ietf-bier-oam-requirements] Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Aldrin, S., Zheng, L., Chen, M., Akiya, N., and J. Networks, "Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer", draft-ietf-bier-oam-requirements-00 (work in progress), September 2015. Authors' Addresses Kumar, et al. Expires September 22, 2016 [Page 8] Internet-Draft Overlay OAM Requirements March 2016 Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709 US Email: naikumar@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 US Email: cpignata@cisco.com Deepak Kumar Cisco Systems, Inc. 3700 Cisco Way SJ US Email: dekumar@cisco.com Greg Mirsky Ericsson Email: gregory.mirsky@ericsson.com Mach Chen Huawei Technologies Email: mach.chen@huawei.com Eric Nordmark Arista Networks Email: nordmark@acm.org Kumar, et al. Expires September 22, 2016 [Page 9] Internet-Draft Overlay OAM Requirements March 2016 Santosh Pallagatti Juniper Networks Email: santosh.pallagatti@gmail.com David Mozes Mellanox Technologies Ltd Email: davidm@mellanox.com Kumar, et al. Expires September 22, 2016 [Page 10]