[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

NVO3                                                           D. Worley
Internet-Draft                                                   Ariadne
Intended status: Informational                             April 5, 2018
Expires: October 7, 2018


                           Geneve Extensions
                    draft-worley-nvo3-geneve-misc-00

Abstract

   TBD

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 October 7, 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.







Worley                   Expires October 7, 2018                [Page 1]


Internet-Draft              Geneve Extensions                 April 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Protocol Numbers  . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Geneve over UDP . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Geneve over IP  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Geneve over Ethernet  . . . . . . . . . . . . . . . . . .   4
   3.  Geneve Protocol Type Numbers  . . . . . . . . . . . . . . . .   5
     3.1.  Ethernet over Geneve  . . . . . . . . . . . . . . . . . .   5
     3.2.  IP over Geneve  . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Layer 4 over Geneve . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  No Payload  . . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Pseudoheaders for Checksums . . . . . . . . . . . . .   6
     3.4.  SNAP Ethertypes over Geneve . . . . . . . . . . . . . . .   6
   4.  Alternate Packet Marking  . . . . . . . . . . . . . . . . . .   7
   5.  Short Header  . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  TCAM Support  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Allocation of Flag Bits . . . . . . . . . . . . . . . . . . .   8
   8.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Packet Spraying . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  OAM Headers . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Revision History  . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  TBD . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document concerns expanding the Geneve encapsulation header to
   the function of a generalized encapsulation.  The current Geneve
   proposal[I-D.ietf-nvo3-geneve] is highly extensible regarding the
   information that can be carried in the Geneve header, but it
   envisions that the encapsulated payload will be either Ethernet or a
   layer 3 protocol and will be carried over UDP within an IPv4 or IPv6
   packet:













Worley                   Expires October 7, 2018                [Page 2]


Internet-Draft              Geneve Extensions                 April 2018


         +---------------+
         |   Ethernet    |
         +---------------+
         |   IP          |
         +---------------+
         |   UDP         |
         +---------------+
         |   Geneve      |
         +---------------+
         |   Ethernet    |
         +---------------+
         |   Layer 3     |
         |   ...         |
         +---------------+

   This document envisions that Geneve header may be used for other
   functions.  These include tunneling at different layers of the stack,
   such as tunneling Ethernet over Ethernet:

         +---------------+
         |   Ethernet    |
         +---------------+
         |   Geneve      |
         +---------------+
         |   Ethernet    |
         +---------------+
         |   Layer 3     |
         |   ...         |
         +---------------+

   or carrying additional information to be processed at various levels
   of the protocol stack:

         +---------------+
         |   Ethernet    |
         +---------------+
         |   IP          |
         +---------------+
         |   Geneve      |
         +---------------+
         |   UDP         |
         +---------------+
         |   application |
         |   data ...    |
         +---------------+

   remarkably little extension is needed to allow Geneve to take on this
   much-expanded role.



Worley                   Expires October 7, 2018                [Page 3]


Internet-Draft              Geneve Extensions                 April 2018


2.  Protocol Numbers

   The most important requirement for the concept of Geneve as a
   generalized encapsulation technique is assigning suitable protocol
   numbers so that Geneve can be demultiplexed at various layers of the
   protocol stack.[number-assignments-msg]

2.1.  Geneve over UDP

   When Geneve is used over layer 4, UDP, then there needs to be an
   assigned UDP destination port to specify that the UDP payload is
   demultiplexed as Geneve.  IANA has assigned 6081 as the port
   number.[I-D.ietf-nvo3-geneve]

2.2.  Geneve over IP

   When Geneve is used over layer 3, IP, it needs a protocol/next header
   value.  Protocol values are only 8 bits, but only a bit over half of
   the protocol values have been allocated in 30 years, so it seems that
   there's not a lot of pressure on the number-space, and it is
   reasonable to request a protocol number assignment for Geneve.
   Currently, the next unused IP Protocol value is
   143.[protocol-numbers]

2.3.  Geneve over Ethernet

   When Geneve is used over layer 2, Ethernet, it needs an Ethertype
   assignment.  An Ethertype assignment could be obtained from
   IEEE,[ieee-ethertype-reg] but it might be more expedient to obtain a
   SNAP Protocol Number from IANA.[RFC7042] Currently, the next unused
   SNAP Protocol Number is 0x0009, yielding the five-octet SNAP
   extension header 00-00-5E-00-09.[snap-protocol-numbers] The SNAP
   extension header appears in the Ethernet frame after the primary
   Ethernet header when the Ethertype in the Ethernet header is the OUI
   Extended EtherType, 0x88B7.

   [IEEE_802-2014] clause 9.2.4 notes

      As discussed in 9.2.3, it is good protocol development practice to
      use a protocol subtype, along with a protocol version identifier
      in order to avoid having to allocate a new protocol identifier
      when a protocol is revised or enhanced.  Users of the OUI Extended
      EtherType are, therefore, encouraged to include protocol subtype
      and version information in the specification of the protocol data
      for their protocols.






Worley                   Expires October 7, 2018                [Page 4]


Internet-Draft              Geneve Extensions                 April 2018


   Geneve satisfies this desideratum through (1) using the first two
   bits of the Geneve header as a version identifier, and (2) carrying
   most of its data in an extensible set of options.

3.  Geneve Protocol Type Numbers

   The Geneve header contains a protocol type field which identifies the
   protocol of the payload of the Geneve header, i.e., the overlying
   protocol.  The protocol type field is defined to be an Ethertype.  To
   allow the Geneve payload to be other than layer 3 protocols (with a
   few layer 2 protocols specifiable through "encapsulated" Ethertypes),
   encodings are needed for a larger space of protocol identifers.

3.1.  Ethernet over Geneve

   When layer 2 is used over Geneve, the protocol type is 0x6558
   (encapsulated Ethernet).

3.2.  IP over Geneve

   When layer 3 is used over Geneve, the protocol type is 0800 (IPv4) or
   86DD (IPv6).

3.3.  Layer 4 over Geneve

   When layer 4 is used over Geneve, Geneve must be extended, because
   there's no defined way of representing an IP protocol/next header
   value directly as an Ethertype, and few or no protocols that can be
   represented as such a value have assigned Ethertypes.

   One approach for carrying layer 4 protocols depends on the fact that
   all Ethertypes must have values of 0x0600 or higher ([IEEE_802-2014]
   clause 9.2.1).  That is because Ethertypes are carried in a two-octet
   field in the Ethernet header, and values of that field smaller than
   0x0600 are defined to specify the length of the Ethernet frame, not
   its Ethertype.  This implies that values of the Geneve protocol type
   field with a first octet of 0x00 to 0x05 are not actually allocated
   at present and can be redefined for other uses.

   This suggests extending the protocol type field so that if the first
   octet is 0x00, then the second octet is an IP protocol number
   describing the payload protocol.

3.3.1.  No Payload

   An additional case is when there is no payload, i.e., the Geneve
   header contains all of the information content of the packet.  In
   this situation, we can take use the next-header value 59, which means



Worley                   Expires October 7, 2018                [Page 5]


Internet-Draft              Geneve Extensions                 April 2018


   "no next header".[RFC8200] Given the encoding for IP protocol
   numbers, "no next header" is encoded by a Geneve protocol type of
   0x003B.

3.3.2.  Pseudoheaders for Checksums

   TBD

3.4.  SNAP Ethertypes over Geneve

   But things get messier if Geneve directly encapsulates a protocol
   which has a SNAP protocol number, because Geneve only reserves two
   octets for the protocol type field.  Likely the best
   solution[extended-msg] is allocate (1) the first octet of the
   protocol type field is an indicator value, 0x02, (2) the second octet
   of the protocol type field is the first octet of the OUI of the SNAP
   protocol number, and (3) as the first four octets of the Geneve
   payload, place the final two octets of the OUI and the two octets of
   the protocol identifier:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|  Opt Len  |O|C|    Rsvd.  |     0x01      |  OUI          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Virtual Network Identifier (VNI)       |    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Options ...                                |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    OUI                        |   Protocol Identifier         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-
       |      Payload ...
       +-+-+-+-+-+-+-+-+-

   This solution allows the format of the Geneve header to remain
   unchanged, and the payload of the inner protocol remains aligned on a
   four-octet boundary.  It does introduce an irregular word between the
   Geneve header and the payload proper, but this is upward-compatible
   with the current Geneve specification: a processor that does not
   understand the SNAP payload convention sees an Ethertype starting
   with 0x02 (which it does not recognize) and a payload that is four
   octets longer than the actual payload (which it knows it does not
   know how to process).





Worley                   Expires October 7, 2018                [Page 6]


Internet-Draft              Geneve Extensions                 April 2018


   (The value 0x02 is chosen as the indicator because numerous
   Ethertypes with high byte 0x01 are listed in the IEEE's registration
   database for "Xerox (Experimental)", despite that they are not
   acceptable as Ethertypes.)

4.  Alternate Packet Marking

   "Alternate packet marking" encompasses a number of methods of
   inserting one or more "marking" bits in packets when they are
   transmitted, and when they are received, measuring the arrival times
   of packets with specific markings to determine flow statistics,
   including delay and jitter.[I-D.fmm-nvo3-pm-alt-mark][I-D.mizrahi-ipp
   m-compact-alternate-marking]

   Alternate marking is mentioned here because even if compact marking
   is used, one of the reserved flag bits needs to be allocated for
   marking.

5.  Short Header

   For some applications, there may be no need for a Virtual Network
   Identifier.  It may be reasonable to allocate one of the header flag
   bits to mean "short", in that the second word of the header is
   suppressed.  Thus, when S = 1, the format of the Geneve header is:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|  Opt Len  |O|C|S|  Rsvd.  |          Protocol Type        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Variable Length Options                    |
       |                    ...                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.  TCAM Support

   My memory is that the question of "TCAM support" was raised a couple
   of IETFs ago.  I take that to mean the question of whether a Geneve
   header can be classified as to whether it conforms to a particular
   "profile" or not by using a ternary-content-addressed memory, that
   is, by examining a fixed set of bits at fixed locations to see if
   they have certain fixed values.  If the profile in question is the
   presence of a particular set of options with particular lengths, the
   classification is possible using TCAM.

   A problem arises if we want to support profiles that allow further
   options beyond the specified set.  It is straightforward to verify
   that the required option class/type values appear in the expected
   locations relative to the Geneve header.  The problem is that there's
   no way to verify that the apparent options are actually within the



Worley                   Expires October 7, 2018                [Page 7]


Internet-Draft              Geneve Extensions                 April 2018


   Geneve header -- to do that would require that the Option Length
   field is greater than or equal to a specified constant, and that test
   can't be done via TCAM.

   One solution is embed in the Geneve header fixed part, and each
   option, a flag telling whether there is a further option in the
   Geneve header.[tcam-msg] Then a Geneve header can be verified to have
   at least N options (when N > 1) when the another-option flag is true
   in the header fixed part and in the first N-1 options.

   (Effectively, the another-option flags represent the number of
   options in the Geneve header in uniary, and using TCAM it is possible
   to compare a number to be greater than a constant if the number is
   represented in unary.)

7.  Allocation of Flag Bits

   The Geneve format reserves eight bits in the first word for flag
   bits.  Accumulating all of these proposals, there are five allocation
   flag bits:

   O (existing)  packet contains OAM information.  The endpoint should
      direct the packet into a control queue.

   C (existing)  critical option is present

   M (new)  traffic marking for measurementSection 4

   A (new)  (in the fixed part) there are one or more options, (in an
      option) this are one or more options following this oneSection 6

   S (new)  short header - the second word of the fixed part is
      absentSection 5

8.  Applications

8.1.  Packet Spraying

   One application of these extensions is described in the draft
   [I-D.xiang-nvo3-geneve-packet-spray] in section 5.3, in which it is
   desirable to put the layer 4 header (TCP or UDP) directly after the
   Geneve header (which carries the "Flow Group ID" and "Sequencing
   Number" in an option).  In these cases, the Geneve protocol type
   field will be 0x0006 (for TCP) or 0x0011 (for UDP).







Worley                   Expires October 7, 2018                [Page 8]


Internet-Draft              Geneve Extensions                 April 2018


8.2.  OAM Headers

   Within this framework, an attractive application is implementing the
   proposed OOAM header as a Geneve header.  The current header
   proposal[I-D.ooamdt-rtgwg-ooam-header] exhibits some of the
   properties that Geneve was designed to avoid, in particular,
   specification of various functions by means of a limited number of
   flag bits in a fixed order.  These limitations can be avoided by
   reformatting the fields of the OOAM header as a Geneve header.

   The OOAM header has three parts: a fixed part, the data blocks
   specified by the Flags field, and an OOAM control message.

   The (potentially) sixteen flags that indicate the data blocks can be
   replaced by sixteen Geneve options, each of which carries as its data
   the data block of the corresponding flag.  This has the disadvantage
   that if a number of flags would be specified in the current format,
   the Geneve header would contain the same number of words to introduce
   the data blocks.  This can be compressed by allocating a group of
   2^16 Geneve option class/type values, each of which encodes a subset
   of the flags, and which has as option data the sequence of data
   blocks for those flags:

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Class      |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Data blocks for the set flags                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This approach does consume 2^16 of the available 2^23 option class/
   type values, but that is less than 1% of the available number space.

   Using the S (short header) bit, the Geneve header is no longer than
   the current OOAM header format:















Worley                   Expires October 7, 2018                [Page 9]


Internet-Draft              Geneve Extensions                 April 2018


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |           Msg Type        |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Flags             |    Reserved   |   Next Prot   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                  OOAM data blocks                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      vs.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt Len  |O|C|B|  Rsvd.  |          Protocol Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Class      |F|F F F F F F F F|C|F F F F F F F|R|R|R| Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 Data blocks for the set flags                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The major limitation of using a Geneve header is that it is limited
   to a 63 words (252 octets) of options.

   The OOAM control message could be carried within a Geneve option,
   although that would limit it to 31 words (124 octets).  The option
   specifies the control message type:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |           Msg Type        |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Flags             |    Reserved   |   Next Prot   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                  OOAM control message                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      vs.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt Len  |O|C|B|  Rsvd.  |          Protocol Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Option Class         |      Type     |R|R|R| Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 OOAM control message                          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An alternative approach that allows longer OOAM control messages is
   to place it after the Geneve header itself and before the Geneve
   header's payload.  The option for the OOAM control message would
   contain only one word of data, carrying the message type and length:




Worley                   Expires October 7, 2018               [Page 10]


Internet-Draft              Geneve Extensions                 April 2018


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | V |           Msg Type        |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Flags             |    Reserved   |   Next Prot   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                  OOAM control message                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      vs.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt Len  |O|C|B|  Rsvd.  |          Protocol Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Option Class         |      Type     |R|R|R| Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Msg Type        |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~          Further Geneve options                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 OOAM control message                          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 Geneve payload                                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In all of these forms, advantage can be taken of Geneve's more easily
   generalized "next protocol" fieldSection 3 and the abililty to
   allocate additional Geneve option class/type values for later
   extensibility.

   However, what does not change with this approach is the fundamental
   work of defining the semantics of the OOAM facilities and control
   messages.

9.  Revision History

   [Note to RFC Editor: Please remove this entire section upon
   publication as an RFC.]

9.1.  TBD

   TBD

10.  References








Worley                   Expires October 7, 2018               [Page 11]


Internet-Draft              Geneve Extensions                 April 2018


10.1.  Normative References

   [I-D.fmm-nvo3-pm-alt-mark]
              Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance
              Measurement (PM) with Alternate Marking in Network
              Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt-
              mark-01 (work in progress), March 2018.

   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-06 (work in progress), March 2018.

   [I-D.mizrahi-ippm-compact-alternate-marking]
              Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen,
              M., Zheng, L., and G. Mirsky, "Compact Alternate Marking
              Methods for Passive and Hybrid Performance Monitoring",
              draft-mizrahi-ippm-compact-alternate-marking-01 (work in
              progress), March 2018.

   [protocol-numbers]
              Internet Assigned Numbers Authority, "Protocol Numbers",
              October 2017, <https://www.iana.org/assignments/protocol-
              numbers/protocol-numbers.xhtml#protocol-numbers-1>.

   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
              IETF Protocol and Documentation Usage for IEEE 802
              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
              October 2013, <https://www.rfc-editor.org/info/rfc7042>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [snap-protocol-numbers]
              Internet Assigned Numbers Authority, "SNAP Protocol
              Numbers", June 2017, <https://www.iana.org/assignments/
              ethernet-numbers/
              ethernet-numbers.xhtml#ethernet-numbers-6>.

10.2.  Informative References

   [extended-msg]
              Worley, D., "OUI Extended Ethertypes as next-protocol",
              IETF NVO3 mailing list msg06235, August 2017,
              <https://www.ietf.org/mail-archive/web/nvo3/current/
              msg06235.html>.



Worley                   Expires October 7, 2018               [Page 12]


Internet-Draft              Geneve Extensions                 April 2018


   [I-D.ooamdt-rtgwg-ooam-header]
              Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L.,
              and D. Dolson, "OAM Header for use in Overlay Networks",
              draft-ooamdt-rtgwg-ooam-header-04 (work in progress),
              March 2018.

   [I-D.xiang-nvo3-geneve-packet-spray]
              Xiang, H., Yu, Y., Congdon, P., and J. Wang, "Packet
              Spraying in Geneve Overlay Network", draft-xiang-nvo3-
              geneve-packet-spray-00 (work in progress), March 2018.

   [ieee-ethertype-reg]
              IEEE Standards Association, "IEEE-SA - Registration
              Authority Ethertype", January 2018,
              <https://standards.ieee.org/develop/regauth/ethertype/
              index.html>.

   [IEEE_802-2014]
              IEEE Computer Society, "802 - IEEE Standard for Local and
              Metropolitan Area Networks: Overview and Architecture",
              June 2014, <https://standards.ieee.org/findstds/
              standard/802-2014.html>.

   [number-assignments-msg]
              Worley, D., "Number assignments", IETF NVO3 mailing
              list msg06219, July 2017, <https://www.ietf.org/mail-
              archive/web/nvo3/current/msg06219.html>.

   [tcam-msg]
              Worley, D., "TCAM compatibility for Geneve", IETF NVO3
              mailing list msg06142, Jun 2017, <https://www.ietf.org/
              mail-archive/web/nvo3/current/msg06142.html>.

Acknowledgments

   Donald Eastlake suggested the use of a SNAP protocol number.

Author's Address

   Dale R. Worley
   Ariadne Internet Services
   738 Main St.
   Waltham, MA  02451
   US

   Email: worley@ariadne.com





Worley                   Expires October 7, 2018               [Page 13]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/