Re: [middisc] TCP middlebox option requirements

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

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