[nvo3] OUI Extended Ethertypes as next-protocol

worley@ariadne.com (Dale R. Worley) Sun, 27 August 2017 15:04 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0E132939 for <nvo3@ietfa.amsl.com>; Sun, 27 Aug 2017 08:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEnU7HrZhmZH for <nvo3@ietfa.amsl.com>; Sun, 27 Aug 2017 08:04:04 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796111321B8 for <nvo3@ietf.org>; Sun, 27 Aug 2017 08:04:03 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id lz6VdlsdjDCbZlz6YdmTNk; Sun, 27 Aug 2017 15:04:02 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-06v.sys.comcast.net with SMTP id lz6XdVSHpPVfFlz6XdPdfb; Sun, 27 Aug 2017 15:04:02 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v7RF40wC007658 for <nvo3@ietf.org>; Sun, 27 Aug 2017 11:04:00 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v7RF40B9007655; Sun, 27 Aug 2017 11:04:00 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: nvo3@ietf.org
Sender: worley@ariadne.com
Date: Sun, 27 Aug 2017 11:04:00 -0400
Message-ID: <87tw0tgihr.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfNJ8+pd+5TZiJXoMjnZejX6QKBi+i1tZ5nwn+u4KG8Yr8UCBKSIilDa74t55RWKzj0pH2NlmErFr092BlCQFZ+eKl/YnJH99Ws4QxuRSh6ms/v8xwIn/ nKh7y3euoPltBzl9PdNx3I9gngoFv4c4pl2kLwZuETb/+tXwd67Wmp2F
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/x1GLxk0LNDdJlZRG9CnXyEmMqIM>
Subject: [nvo3] OUI Extended Ethertypes as next-protocol
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Aug 2017 15:04:05 -0000

Don Eastlake mentioned the use of OUI Extended Ethertypes.  Assuming
that Geneve encapsulates an Ethernet header, that header can specify
the 88B7 Ethertype, and be followed by the OUI Extended Ethertype
(sub-)header.

But things get messier if Geneve directly encapsulates a protocol which
is described by an OUI Extended Ethertype, because Geneve only
reserves two octets for the Protocol Type field.

So I thought I would try to design a way of handling the situation
that avoided obvious shortcomings.

Though OUI Ethertypes are often described as an extension of the 802
header, they act as a further header after an 802 header whose
ethertype is 88B7, and is then followed by the payload (that is, the
payload described by the OUI Ethertype):

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Destination MAC Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Destination MAC Address |         Source MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Source MAC Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Ethertype=0x88B7        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Organizationally Unique Identifier       | Ethertype     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ethertype    |
      +-+-+-+-+-+-+-+-+

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

The OUI Ethertype header is essentially the same as the Subnetwork
Access Protocol header.

So the natural way of using OUI Ethertypes as the next-protocol in
Geneve is to put the "OUI Ethertype" Ethertype in Geneve header, and
then follow it with the OUI Ethertype header:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt Len  |O|C|    Rsvd.  |     Protocol Type 88B7        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Virtual Network Identifier (VNI)       |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options ...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Organizationally Unique Identifier       | Ethertype     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Ethertype    |
      +-+-+-+-+-+-+-+-+

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

Unfortunately, that leaves the payload not aligned on a 4-octet
boundary, which is undesirable.  (E.g., draft-dt-nvo3-encap-01,
section 6.4)

The desiderata for the situation seem to be:

1. The Geneve header together with the OUI Ethertype specification must
   be a multiple of 4 octets.
2. The incremental length for an OUI Ethertype should be as small as
   possible.
3. The consumption of currently reserved fields should be minimal.

There are three locations where the OUI Ethertype could be carried:

A. Incorporate the OUI Ethertype into the Geneve fixed part.
B. Incorporate the OUI Ethertype into a Geneve option.
C. The OUI Ethertype follows the Geneve header.

Incorporating the OUI Ethertype into Geneve fixed part aligns with the
attitude that the OUI Ethertype field is an extension of the Ethernet
header.  One possibility for this is:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|  Opt Len  |O|C|    Rsvd.  |   Protocol Type 88B7          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Virtual Network Identifier (VNI)       |    OUI        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OUI                          |   Ethertype                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options ...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A large disadvantage is that this makes the location of the first
Geneve option variable relative to the start of the Geneve header,
conditional on the Protocol Type field, which is not
upward-compatible.  It's also not TCAM-friendly, unless a flag bit is
allocated to indicate an OUI Ethertype, since a test for "not equal
88B7" can't be done with TCAM.  This format also allocates the
reserved octet in the fixed part.

Incorporating the OUI Ethertype into a Geneve option avoids most of
these problems, but the option must be 12 octets long.

So the best choice is putting the OUI Ethertype after the Geneve
header, but using a method which avoids the alignment problem of the
naive method.

In order to avoid adding 3 octets of padding to achieve 4-octet
alignment, we want to reduce the OUI Ethertype header to 4 octets,
which requires placing one octet of it (presumably the first octet of
the OUI) in the Geneve header.  The choices that do not lengthen the
Geneve header are:

F. the reserved octet
G. one octet of the Protocol Type

These interact with the possibilities for signaling that the
next-protocol is OUI Extended Ethertype:

L. Protocol Type equals 88B7
M. allocating a flag bit
N. using a special value (0..5) of the high-order octet of Protocol Type

Choice N. exploits the fact that the high-order octet of an Ethertype
cannot be 0, 1, 2, 3, 4, or 5.  (IEEE 802-2014 section 9.2.1)

Note that choices L. and N. are TCAM-friendly in regard to accessing
the Geneve header itself.

Choice F. is undesirable by desideratum 3 (avoid allocating reserved
fields).  Similarly, choice M. is undesirable, though less so.  Choice
N. also allocates a reserved resource, one of the 6 special values of
the high-order octet of Protocol Type.  However, it does not reduce
the bits available in the Geneve fixed part when using an ordinary
Ethertype.

Choice G. is incompatible with choice L.

This leaves the combination of N. and G. the best available way to
provide a octet for the OUI Extended Ethernet.  Assuming we use 1 as
the reserved value, the combination of Geneve and OUI Ethernet headers
is:

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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    OUI                        |   Ethertype                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Dale