[nvo3] Number assignments

worley@ariadne.com (Dale R. Worley) Sat, 22 July 2017 02:16 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 6F0B3127241 for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 19:16:00 -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 IloSdljkYZQj for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 19:15:59 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 BADD31200ED for <nvo3@ietf.org>; Fri, 21 Jul 2017 19:15:59 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id YjxXd28OJQp3NYjxXdxvmv; Sat, 22 Jul 2017 02:15:59 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id YjxVd93WXUCBoYjxWd6Fz6; Sat, 22 Jul 2017 02:15:58 +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 v6M2FtPF027538 for <nvo3@ietf.org>; Fri, 21 Jul 2017 22:15:56 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v6M2FskB027525; Fri, 21 Jul 2017 22:15:54 -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: Fri, 21 Jul 2017 22:15:54 -0400
Message-ID: <87fudpjjxh.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfIy6UnTUirE23ohiRSH4I142rCPSuRcYWfjJEEITOr9mRklhVWSLBbwCSTS5WCa7qTyiCsAJbISQcQzB3mR4fQJQ+QRDX+MxeXuF8eLO7CChY2ZssNjE mjKEOK11vjspXrmcwTV+4BSq9Se/9o/BL9jRlRdzPpGuZF1aLR2ckL4S
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/qiNI9ml693Pxy5Sjebk4ZqdI9bI>
Subject: [nvo3] Number assignments
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: Sat, 22 Jul 2017 02:16:00 -0000

The concept of Geneve as a generalized encapsulation technique -- or
even the concept of some alternative to Geneve as a generalized
encapsulation technique -- brings very little overhead other than
demands on number assignments.  This message is an exercise to work
through the implications of that idea.

When Geneve is used over layer 4, UDP, then there needs to be an
assigned UDP destination port.  IANA has assigned 6081 as the port
number.

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
space has been allocated in 30 years, so it seems that there's not a lot
of pressure on the number-space.

When Geneve is used over layer 2, Ethernet, it needs an Ethertype
value.  But only 3,500 Ethertypes have been assigned out of a space of
64k.

In theory, Geneve could be used over layer 1, in which case the
underlying protocol doesn't have a next-protocol field, but rather the
layer 2 protocol is configured by the operational environment

The Geneve header contains a next-protocol field, which is an Ethertype,
which signals the overlying protocol.

When layer 2 is used over Geneve, the next-protocol is 6558
(encapsulated Ethernet).

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

When layer 4 is used over Geneve, things are more complicated, 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.

It seems to me that it would be useful to embed the IP protocol/next
header value space into the Ethertype space by allocating a block of 256
Ethertypes, xx00 to xxFF, to IANA, to represent the protocol/next header
values.  This is a large allocation, but the Ethertype space is thinly
allocated and ony 60 or so of the possible first-byte values are used,
leaving over 150 choices to allocate.

Thus, if we are to generalize Geneve (or any similar protocol) to be
used over and under various protocol layers, we need these additional
IANA assignments:

- a protocol/next header value to indicate Geneve

- an Ethertype to indicate Geneve

- a 256-value block of Ethertypes that are assigned to IANA to embed the
  protocol/next header value space

Comments?

Dale