Subject: [nvo3] Number assignments

From: [email-masked] (Dale R. Worley)
Date: Fri, 21 Jul 2017 22:15:54 -0400

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 22 Jul 2017 05:30:02 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 22 Jul 2017 07:32:55 -0700

Dale,

> represented as such a value have assigned Ethertypes.
That is a good thing, IMO.

> leaving over 150 choices to allocate.
I disagree. As with most codepoints, if you want ONE (e.g., for Geneve
as the next protocol after ethernet) then maybe. If you want more, then
IMO absolutely not.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 22 Jul 2017 12:02:07 -0400

There are cases of the IEEE Registration Authority or an IEEE WG
assigning a block of identifiers to IANA so that IANA can
sub-delegate. See, for example, RFC 7319 and RFC 7042. Also, you
wouldn't quite need 256 since you would continue to use existing
Ethertypes for some protocols such as IPv4 and IPv6.

Nevertheless, it is my opinion that it would be EXTREMELY difficult to
get an allocation of even tens of Ethertypes, let alone hundreds, from
the IEEE Registration Authority. I would suggest a different approach.

Maybe you could use Ethertype 0x88B7. This indicates an extended
Ethertype where the actual type is given by an OUI and a further two
bytes referred to as a SNAP protocol number. IANA already has an OUI
and very few of the SNAP protocols under it have been assigned (see
https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-6)
so it would be easy get a block of 256 SNAP protocol number under the
IANA OUI. However, it is not clear where the OUI+ 2 bytes would go
and, since this is an Ethertype defined by and under the control of
IEEE 802.1, it would be a problem to the extent that this was a
different use.

So, if you wanted to pursue this, I would suggest assuming you could
possibly get one new Ethertype. That Ethertype could indicated that a
currently reserved byte in the Geneve header indicates the payload
type by using the IP next protocol number space...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 23 Jul 2017 23:01:49 -0700

I think the IEEE-recommended way to solve this problem is to use subtyping.

This means IEEE will give IANA just _one_ Ethertype to be used for "Next
Protocol Identification in Geneve".  IANA in turn issue subtypes for as
many protocols as need to be indicated.  The way this works then is that
the Geneve next protocol field would indicate an ethertype of "IANA
assigned subtype" and then we need to look at the next two bytes to figure
out which protocol is being carried in the frame.

So the frames would like:
0x0800 | IP packet
0x86DD | IPv6 packet
XXXX | YYYY | a protocol packet that doesn't have an Ethertype

Where:
XXXX = new ethertype from IEEE
YYYY = subtype from IANA

We can now carry 64K protocols in Geneve with just one Ethertype.

Thanks,
Anoop

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 25 Jul 2017 22:26:04 -0400

> the IEEE Registration Authority. I would suggest a different approach.

I expect that you're right as a bureaucratic matter.  But technically,
it shouldn't be a problem.  There are 3489 Ethertypes assigned
(according to the IEEE's file), which is 5.3% of the number space --
assigned over the 37 years since 1980.  At this rate, they should last
till around 2292 C.E., though my proposal would pull that date in to
2290.

> out which protocol is being carried in the frame.

Another way out of this is suggested by this passage from Wikipedia:

    In order to allow some frames using Ethernet v2 framing and some
    using the original version of 802.3 framing to be used on the same
    Ethernet segment, EtherType values must be greater than or equal to
    1536 (0x0600). 

If that is true, we could carry an IP protocol number in the Geneve
Protocol Type field by putting 00 in the high byte and the IP protocol
number in the low byte, as there are supposed to be no Ethertypes less
than 0600.

(The IEEE registrations allocate all of 0101-01FF to "Xerox
(experimental)"; 0200, 0201, and 0400 as "Private"; and 0500 to "Sprite
RPC" and also to "University of Berkeley" (which seems to mean UC
Berkeley).  But none in the block 00xx.)

Dale

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Jul 2017 14:30:27 -0400

Dale,

As a matter of courtesy to the IEEE, with whom the IETF has a very good
relationship, I see
absolutely no reason that we would not respect their rules and suggestions
for managing their
own code spaces - just as we expect the same courtesy for our IANA managed
registries.

If there's actual interest in going down this path for implementation &
deployment, I would strongly
recommend using the sub-types approach that Donald suggested.  That is the
approach that the
IEEE recommends.

Regards,
Alia

On Tue, Jul 25, 2017 at 10:26 PM, Dale R. Worley <[email-masked]> wrote:

> > https://www.iana.org/assignments/ethernet-numbers/
> ethernet-numbers.xhtml#ethernet-numbers-6)

---

From: Pat Thaler <[email-masked]>
Date: Wed, 26 Jul 2017 13:37:00 -0700

<Pat Thaler with my technical expert from Broadcom hat on>

Just because it would be easy to add something to a specification or
standard, doesn't mean that it is a good idea to add it.

We have reasons that we put Geneve over UDP rather than putting it directly
over IP or layer 2. E.g. better entropy for NVO3 unaware routing devices;
the ability to have a checksum that covers the tunnel headers.

Also, there is a cost to supporting variants, both hardware costs and costs
for additional testing to ensure that all the variants work. Probably some
software and configuration costs too. I haven't seen any use case provided
for throwing additional variants in.

I'd be opposed to adding such variants. It goes way beyond number
assignments.

Sincerely,
Pat

---

From: Pat Thaler <[email-masked]>
Date: Wed, 26 Jul 2017 13:47:42 -0700

<Pat Thaler with my member of the IEEE RAC (Registration Authority
Committee) hat>

If the RAC gave 256 Ethertypes to an IETF protocol, then we would be likely
to also get requests from other entities for multiple allocations. Yes,
 under the current requirement for using subtyping to prevent multiple
allocations, we have been going through Ethertypes very slowly and the
space will last for a very long time. But the alternative of removing that
requirement could allow fast exhaustion of the space. In my opinion, an
exception is extremely unlikely.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 27 Jul 2017 23:16:37 -0400

Alia Atlas <[email-masked]> writes:
> As a matter of courtesy to the IEEE, with whom the IETF has a very
> good relationship, I see absolutely no reason that we would not
> respect their rules and suggestions for managing their own code spaces
> - just as we expect the same courtesy for our IANA managed registries.
>
> If there's actual interest in going down this path for implementation
> & deployment, I would strongly recommend using the sub-types approach
> that Donald suggested.  That is the approach that the IEEE recommends.

I'm not sure how you're parsing the situation.  But of course, we could
not obtain Ethertype(s) unless IEEE assigned it(them), so contravening
IEEE's practices isn't possible, in the strict sense.

At the moment, I'm envisioning that we would redefine the Geneve
"protocol type" field so that values of 256 and larger are to be
interpreted as Ethertypes and values of 255 and less are to be
interpreted as IP protocol numbers.  Clearly, this is overloading the
field, but conveniently, 802.3 forbids Ethertypes less than x0600 or so,
so there is no ambiguity.

>From my point of view, this isn't an abuse of Ethertypes or the IEEE's
policies, it's taking advantage of stated properties in the standard.
But perhaps the IEEE wouldn't look at it that way.

Dale