Re: [middisc] TCP middlebox option requirements

["Anantha Ramaiah (ananth)" <[e-mail]>]

That may be ok, but the issue is, we are using 1 byte (vendor ID = 0)
for explicitly stating that it is a standard type and there can be need
for multiple standard types and then one needs to have sub-type to cater
to multiple use cases. IMO, this is wastage of TCP option bits.

-Anantha

> -----Original Message-----
> From: Andrew Knutsen [mailto:[e-mail]]
> Sent: Tuesday, May 24, 2011 1:57 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
> 
> 
>      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