Re: [middisc] TCP middlebox option requirements

["Frederick, Ron" <[e-mail]>]

On May 24, 2011, at 7:22 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> 
> Hi David, PENs are a good thought in comparison to OUIs for this purpose.
> 
> I don't speak for the authors, but we have to be a bit sympathetic to the fact that there is only very limited amount of space available for TCP options and burning 32-bits for an enterprise number is going to eat away considerably from the space available to do something useful.
> 
> Personally, I would have no problem seeing a compact mechanism that's just big enough to allow expandability to some double-digit multiple of the number of current vendors, and also support falling back to using either a full Private Enterprise Number or an OUI once the more compacted space is exhausted.

Choosing to go with the OUI instead of a PEN here was mainly because OUIs only took 24 bits of space rather than 32 bits. which is the my understanding of the intended size of a PEN. However, even 24 bits was more than we wanted to pay in most cases, and that's what led to the different variants of the option, where the OUI was only used as a fallback.

If there are still objections to using a full byte for vendor code (due to this "wasting" a byte for standard options), I would propose one of the following:

- Allow standard type codes to be allocated starting with 0x00, in an increasing fashion and allow vendor codes to be allocated starting with 0xFE in a decreasing fashion. At some point, if it looks like too many vendor codes are being allocated, IANA can declare that no more are available and that additional vendors must use the 0xFF form with an OUI, leaving the remainder of the space for standard type codes.

or

- Allow both standard type codes and vendor codes to just be allocated in an increasing fashion from 0x00. As Andrew noted, the code determines everything about how to interpret the rest of the payload, so there's really no difference between the two from a decoding perspective.

Either way, I would want to see a rule that IANA would only ever allocate one single-byte vendor code to any vendor and it would be up to that vendor to allocate any necessary additional bits or bytes in the payload as needed to support multiple option types. If a vendor failed to plan ahead in this regard, they would need to either rework their options later to adjust for this or to allocate additional options using the 0xFF variant with their OUI.
-- 
Ron Frederick
[e-mail]