Re: [middisc] TCP middlebox option requirements

[Andrew Knutsen <[e-mail]>]

    Anantha, what do you see as the advantage of adding a sub-type to 
the type code, which follows the vendor ID?

Andrew

On 5/24/2011 9:03 AM, Anantha Ramaiah (ananth) wrote:
> Hi David,
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of David Harrington
>> Sent: Tuesday, May 24, 2011 6:13 AM
>> To: 'Eddy,Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]'; 'Ron Frederick';
>> 'Mark Day'
>> Cc: [e-mail]
>> Subject: Re: [middisc] TCP middlebox option requirements
>>
>> Hi,
>>
>> I also have no skin in this game. and I'm looking at this list after
>> months of ignoring it, so I'm way behind in the discussions.
>>
>> I am concerned that unless severely limited in what it can be used
>> for, this will lead to other vendor-specific options.
>> Whether that is good or bad I'll leave to other people to decide, such
>> as my co-area director Wes, the IETF community and the IESG that will
>> need to approve any document produced as a result of this discussion.
>>
>> I will observe that many IETF protocols developed for a limited use
>> "escape into the wild". This happens ofetn when people decide to
>> develop a weak or non- security solution and claim it will be only be
>> used within an enterprise, but it then gains use in the Internet. I
>> don't know if there is anything you can do to prevent this from
>> becoming a generic option for vendor-specific features if you design
>> in a vendor code. The best way to avoid that is to reach agreement on
>> a standard that does not include a vendor code (which means accepting
>> that your current products continue to not be compliant to the new
>> standard).
> This thread has been quiet for sometime and last week I had sent an
> email describing the current status and the steps moving forward to
> reach consensus.
> I agree with your concerns in the above paragraph and I am sure we need
> to have a section (applicability section ) which exactly spells out the
> scope of the middlebox option, caveats etc.,  I am afraid this is best
> that can be done, we can talk and debate about it but the reality is
> multiple vendors already have WAN opt options and it is non-goal of this
> effort to interoperate among vendors.
>
>> If you do have vendor-specific options, it will be important to make
>> sure that each vendor is uniquely identified, so we don't have two
>> vendors fighting over a vendor code. I recommend registering vendor
>> codes with IANA to make sure this doesn't happen.
> Actually I had asked this question (about IANA managing the vendor
> codes) earlier in this thread. It sounds very useful to me.
>
>> IANA already maintains an Enterprise Number registry that is used for
>> many IETF standards. It is a widely used ***standard*** in IETF
>> standards for identifying vendors using a code number.
>> http://www.iana.org/assignments/enterprise-numbers.
> Good to know.
>
>> Maybe you can convince the IESG that having another set of codes to
>> identify vendors is important, and that a given vendor will likely
>> have a different code in your vendor code list than that used by other
>> standards. It doesn't sound very convincing to me.
> One of the issues is the limited space of TCP options currently
> available,  having a standard vendor code would cause it to eat more TCP
> option space which would impact the usability of this option. Given that
> we have an handful of vendors ( I suspect this number to grow for the
> use case of WAN optimization anytime), it is probably ok to go ahead
> with a shorter vendor code point.
>
>> If expansion CAN take place in the future, and now you need 0xff plus
>> an OUI, you will also have added complexity to TCP, requiring suppoort
>> for one-byte vendor codes plus OUI support. and you will have added a
>> new list of vendor codes (whether maintained by IANA or not), and
>> you'll need to convince IESG all this extra complexity is justified.
> Actually sometime back I had mentioned the other use cases like the
> following draft by Dan Wing :-
> http://tools.ietf.org/html/draft-wing-nat-reveal-option-01
>
> Actually it would be expedient to make the middlebox  option extensible
> to accommodate use cases like the above. As far as the WAN optimization
> option goes, there are a very handful of vendors today and allocating a
> whole byte is overkill and we can sub-divide that portion to accommodate
> other use cases like the above. But this is something we want to do if
> there is a consensus, at the minimum the goal of this effort is to get a
> TCP option for WAN optimization allocated. (which is the original
> intent)
>
> To make things clear I am talking about the following format (which was
> one of the choices listed which the group came up with)
> Case 3:
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +---------------+---------------+---------------+---------------+
> | Opt kind=TBD  |    Opt len    | sub-type + Vendor  |          |
> +---------------+---------------+--------------------+----------|
> |                                                               |
> | ...Optional vendor payload data dependent on vend typecode... |
> |                                                               |
> +---------------+---------------+---------------+---------------+
>
> In the above we have a option sub-type which can be 3 bits long :-
>
> 000 - WAN opt.
> 001  - NAT reveal
>
> This gives vendor codes 5 bits which is more than enough as far as this
> option goes. The point here is putting the OUI information is up to the
> vendor and that belongs to the vendor specific metadata. All that is
> required is a type code for middlebox option and have this format as
> generic as possible so that multiple vendors requirements (currently as
> we speak there is Bluecoat, Riverbed, Cisco and maybe Citrix)
>
> Adding Dan in the loop.
>
> -Anantha
>> I recommend you consider simply using an existing IETF standard
>> registry already supported by IANA, such as Enterprise Numbers, for
>> your vendor codes. OR don't support vendor codes at all, and agree on
>> a single standard.
>>
>> David Harrington
>> Director, IETF Transport Area
>> [e-mail] (preferred for ietf)
>> [e-mail]
>> [phone] (cell)
>>
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Eddy, Wesley
>>> M. (GRC-MS00)[ASRC AEROSPACE CORP]
>>> Sent: Thursday, May 27, 2010 12:53 PM
>>> To: Ron Frederick; Mark Day
>>> Cc: [e-mail]
>>> Subject: Re: [middisc] TCP middlebox option requirements
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Ron Frederick
>>>> Sent: Thursday, May 27, 2010 12:44 PM
>>>> To: Mark Day
>>>> Cc: [e-mail]
>>>> Subject: Re: [middisc] TCP middlebox option requirements
>>>>
>>>> ...
>>>>
>>>> If this is really the case, it would be a mistake to limit the
>> total
>>>> number of type codes across all vendors to 256. We'd basically be
>>>> repeating the mistake that led to this effort in the first
>>> place, where
>>>> TCP options as a whole have a space of 256 options and we're
>>> currently
>>>> using multiple of those to solve this problem.
>>>
>>> I don't have skin in the game, but on reading this thread, my
>>> thought was that it's probably possible to use a single byte,
>>> but define one codepoint (like 0xFF) to mean "use a full OUI
>>> which follows".  This way you can start with using a single
>>> byte given the relatively small number of vendors today, and
>>> have a way to accommodate larger numbers in the future, if
>>> the need arises.
>>>
>>> This only works if the means of extending to a full OUI is
>>> part of the base specification and everyone has to support
>>> it, otherwise there are backwards-compatibility issues when
>>> someone tries to use it in the future.
>>>
>>> --
>>> Wes Eddy
>>> MTI Systems
>>>
>>>
>>> _______________________________________________
>>> middisc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/middisc
>>>
>> _______________________________________________
>> middisc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/middisc
> _______________________________________________
> middisc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/middisc