Re: [nvo3] Number assignments

"Andrew G. Malis" <agmalis@gmail.com> Sat, 22 July 2017 03:30 UTC

Return-Path: <agmalis@gmail.com>
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 C62AF129ADD for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 20:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GCNR7ffe323B for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 20:30:23 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1276C12EC06 for <nvo3@ietf.org>; Fri, 21 Jul 2017 20:30:23 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id q4so65662763oif.1 for <nvo3@ietf.org>; Fri, 21 Jul 2017 20:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LA9ki+AuMKs4H92KTdMmwmEzNTv1UM5eOfnWPkt2c8E=; b=bQqOxiX+rz1e+KnT0zi9QNf9jUExGVY8HYMVxa/B4wp14ZZ37lGxC8AwaHkfuGKgC/ yIN9tLT/wYOVlT+wVMLGs+Yxd4CG9i3rbI/4EQbBXiS7V0irVuLpjpR5wMnyRN00v6MZ CCKQMsLZqYSh6KaK2/m8tWs+KdkRGxgrmqyu+oMsXooLiQPiGvv+fjdZSNGRF/8Sx6CB 9C7lPIhM69roDToIGo7FU8/Fu6y8y6+e7XqqKiZva6A3dXYmIHFQj4POv+QTTmmOxEa3 yfvldOIlt9pNXDBMgdo7lPiiwA+g2sJgwwF4NL3cYsfWVW8f/sUg5rlF5r7Jivch4Qpu 1NuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LA9ki+AuMKs4H92KTdMmwmEzNTv1UM5eOfnWPkt2c8E=; b=qhRP9umQWWUcYpvmMAIivyOzkGs3RDtkZv9zLJ9yxQ1vbVSQ4j6Dz0OOlEH3wKYlV3 lMuMYiuaAlvhk0t2fUCIFRHh1hpgo4JajaJa+K0lw52KlwN39mffYU19QW7S3RjejozO BFNVASbOWyJaqfEoWvP9E/c61FKKDRl0gQQCKP/2s4/00D6Oh6Dkd1LV0lWILXW05Tp1 OF6Vw92TX8rdfN9RGEX0cCF3CMg8cDGdj+fSMV7gwfPs+vVUjtsQh29JUCYN3QVz/RK1 RWpXXXcJ8+peLS+AmP0YKL9ugk24Kuje320r6b6FJr7iAz4cdBYvVv8ADukDVR+19evW NT9A==
X-Gm-Message-State: AIVw1130kh4UpV8KwYkwNhFe8KeyXs8AbmWdKvT2eWlsu/4rLqAStioT H7+mv0v2A8i35WsIXaGi20cjqTp3wYd1
X-Received: by 10.202.69.197 with SMTP id s188mr3930145oia.148.1500694222425; Fri, 21 Jul 2017 20:30:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.232.34 with HTTP; Fri, 21 Jul 2017 20:30:02 -0700 (PDT)
In-Reply-To: <87fudpjjxh.fsf@hobgoblin.ariadne.com>
References: <87fudpjjxh.fsf@hobgoblin.ariadne.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Sat, 22 Jul 2017 05:30:02 +0200
Message-ID: <CAA=duU39mTUPR5PGuKcYxd2N0CaMze3fsE9B1tJ8k6W3jrmXTQ@mail.gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dd3be0b57730554df9ae3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/L6sRJRo0ehsEWB2jSmjm2ihgAr4>
Subject: Re: [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 03:30:26 -0000

Dale,

Ethertypes are allocated not by IANA, but IEEE. See
https://standards.ieee.org/develop/regauth/ethertype/ for further
information.

Cheers,
Andy


On Sat, Jul 22, 2017 at 4:15 AM, Dale R. Worley <worley@ariadne.com> wrote:

> 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
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>