Re: [middisc] TCP middlebox option requirements

    Thanks Ananth.

    One possibility that Jamshid and I talked about addresses concerns 
about using 3 bytes for the OUI. We could skip it (and the P bit), and 
break up the 15 bits or so of "device capability" into an IANA-assigned 
vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific 
type. There could be one or more "standard" vendor codes for 
multi-vendor interoperability (ie, IANA-assigned types), and an 
extension code if we run out of room.

    Perhaps we also need to define the requirements for getting a vendor 
code or a standard type -- for instance, we might not want any 
individual to be able to get a vendor code, since they are limited; and 
the standard types would need some documentation, but perhaps not as 
widely reviewed as for a top-level option kind.

Andrew

Anantha Ramaiah (ananth) wrote:
> Hi,
>    I am just taking the liberty to post the first email on this mailing
> list. During our last call there was talk about the requirements of this
> TCP option. From our pov, the following would be the general
> requirements of the TCP option.
>
>
> Reason for TCP option :
>
> - A standard TCP option is needed because every vendor cannot have one
> option for the same purpose of auto-discovery and capability exchange.
> By standardizing the TCP option, firewalls etc., are aware of this
> option and problems can be avoided.
>
> Requirements of this TCP option :
>
> - There has to be a vendor ID (OUI) which would identify the specific
> vendor. This is needed because every vendors option format is going to
> be 
> different.
>
> - Already existing non-standardized option numbers (TCP option 33,
> riverbed's options no's) for doing auto discovery should not be
> allocated for this new TCP option. This is to prevent any confusion.
>
> - The TCP option needs to be variable length to permit multiple option
> formats since the option size may vary depending on the vendor.
>
> - This TCP option should be advocated for use only by middleboxes.
>
>
> My guess is that these requirements may be common for all the vendors or
> there may be some additional requirements not covered by this post. In
> either case we can continue the discussion and come to some conclusions.
>
> -Anantha
> _______________________________________________
> middisc mailing list
> middisc@ietf.org
> https://www.ietf.org/mailman/listinfo/middisc
>