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 protected]> wrote: > Donald Eastlake <[email protected]> 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
