Re: [middisc] TCP middlebox option requirements

[Andrew Knutsen <[e-mail]>]

     If you don't need a vendor code, that means its a standard type, 
which has vendor ID 0 in the current proposal.

Andrew

On 5/24/2011 1:46 PM, Anantha Ramaiah (ananth) wrote:
> Andrew,
>       My primary motivation here was to accommodate other possible use
> cases and at the same time be very sensitive to TCP option bits. Hence I
> thought we could sub-divide the vendor field into 2 pieces. Instead of
> having 8 bits for vendor type and another 8 bits for sub-type. We could
> also have something like if the MSB is set, then it is WAN opt option,
> what follows is vendor information, if 0 it can be used for other
> things.
>      Also to paraphrase what I said earlier : if we want to restrict this
> TCP option allocation proposal's scope to middlebox WAN optimization use
> case alone, I am fine with that too.
> -Anantha
>
>> -----Original Message-----
>> From: Andrew Knutsen [mailto:[e-mail]]
>> Sent: Tuesday, May 24, 2011 1:34 PM
>> To: Anantha Ramaiah (ananth)
>> Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP];
>> Ron Frederick; Mark Day; [e-mail]
>> Subject: Re: [middisc] TCP middlebox option requirements
>>
>>
>>      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