OAM for use in GENEVE
draft-mmbb-nvo3-geneve-oam-01

NVO3  Working Group                                            G. Mirsky
Internet-Draft                                                    X. Min
Intended status: Standards Track                               ZTE Corp.
Expires: July 9, 2020                                         S. Boutros
                                                            VmWare, Inc.
                                                                D. Black
                                                                Dell EMC
                                                         January 6, 2020

                         OAM for use in GENEVE
                     draft-mmbb-nvo3-geneve-oam-01

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 July 9, 2020.

Copyright Notice

   Copyright (c) 2020 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 July 9, 2020                  [Page 1]
Internet-Draft                OAM in GENEVE                 January 2020

   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 July 9, 2020                  [Page 2]
Internet-Draft                OAM in GENEVE                 January 2020

   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 July 9, 2020                  [Page 3]
Internet-Draft                OAM in GENEVE                 January 2020

      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 July 9, 2020                  [Page 4]
Internet-Draft                OAM in GENEVE                 January 2020

   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 July 9, 2020                  [Page 5]
Internet-Draft                OAM in GENEVE                 January 2020

   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 July 9, 2020                  [Page 6]
Internet-Draft                OAM in GENEVE                 January 2020

        +---------------+--------------+-------------------------+
        | 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-14 (work in progress), September 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc4385>.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Mirsky, et al.            Expires July 9, 2020                  [Page 7]
Internet-Draft                OAM in GENEVE                 January 2020

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, <https://www.rfc-editor.org/info/rfc7799>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

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 July 9, 2020                  [Page 8]