Re: [nvo3] Number assignments

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 <worley@ariadne.com> wrote:

> Donald Eastlake <d3e3e3@gmail.com> writes:
> > 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.
>
> 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.
>
> > 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.
>
> Anoop Ghanwani <anoop@alumni.duke.edu> writes:
> > 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.
>
> 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
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>