[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
- [nvo3] OUI Extended Ethertypes as next-protocol Dale R. Worley