Re: [nvo3] Number assignments

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

On Sat, Jul 22, 2017 at 9:02 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:

> 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
>  d3e3e3@gmail.com
>
>
> On Fri, Jul 21, 2017 at 11:30 PM, Andrew G. Malis <agmalis@gmail.com>
> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org
> > https://www.ietf.org/mailman/listinfo/nvo3
> >
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>