Re: [nvo3] Number assignments

<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

On Fri, Jul 21, 2017 at 7:15 PM, 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
>