Subject: Re: [middisc] middisc specification update

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 2 Mar 2012 16:42:39 -0800

Hi Wes/David,

I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a
result of all the discussions we have had among the stakeholders. What
are the next steps?  Is any presentation needed? I assume this is
treated as an individual submission and not targeted to any WG and
directly IESG would review it (Based on what you hinted last time, Wes)

Sorry it took time, but better late than never I guess. Thanks to all
for their discussions, review and feedback.
Thanks,
Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Anantha Ramaiah (ananth)
> Sent: Tuesday, January 17, 2012 1:30 PM
> To: David Harrington; Wesley Eddy; [email-masked]
> Subject: Re: [middisc] middisc specification update
> 
> I hope to get something out (based on the discussions so far) before
> the
> IETF deadlines. I'll start looking into this very soon.  I assume we
> are
> talking about the -00- cutoff deadline here and the IETF page says it
> is
> March 5th.
> -Anantha
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of David Harrington
> > Sent: Tuesday, January 17, 2012 12:16 PM
> > To: 'Wesley Eddy'; [email-masked]
> > Subject: Re: [middisc] middisc specification update
> >
> > three months later and a new deadline is approaching.
> > Any chance of seeing progress on a draft?
> >
> > David Harrington
> > Director, IETF Transport Area
> > [email-masked] (preferred for ietf)
> > [email-masked]
> > +1 603 828 1401 (cell)
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Wesley Eddy
> > > Sent: Sunday, October 09, 2011 5:53 PM
> > > To: [email-masked]
> > > Subject: [middisc] middisc specification update
> > >
> > > Hi folks, this is a reminder that there are cut-off dates
> > approaching
> > > for draft submission prior to the next IETF meeting.  If I
> > understand
> > > correctly, Andrew has the pen and should be working on either a
new
> > or
> > > updated document based on prior discussions.  If it's at all
> > possible
> > > to get that in before the relevant cut-off date, that would be
very
> > > encouraging.
> > >
> > > --
> > > Wes Eddy
> > > MTI Systems
> > > _______________________________________________
> > > middisc mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/middisc
> > >
> >
> > _______________________________________________
> > middisc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/middisc
> _______________________________________________
> middisc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 5 Mar 2012 09:32:24 +0000

Hi,

On Mar 3, 2012, at 1:42, Anantha Ramaiah (ananth) wrote:
> result of all the discussions we have had among the stakeholders.

a few comments on the ID. (Also CC'ing Martin as the incoming AD.)

Lars

  I think you need to add some text that says that although TCP is
  end-to-end and therefore network infrastructure was supposed to not
  mess with the TCP headers, current deployment practice has resulted in
  middleboxes that do in fact "violate" the original architecture in
  order to address a perceived need. This shouldn't say whether that's
  good or bad, but merely acknowledges reality and encourages use of a
  shared documented option number for such uses.

INTRODUCTION, paragraph 1:
> Intended status: Informational

  You need to make this PS. Or do you want to ask for IESG Approval of
  the option number?

INTRODUCTION, paragraph 5:
>    This document describes a TCP option for use by middleboxes to
>    facilitate transparent detection of other middleboxes along the path
>    of the TCP connection during the connection initiation phase.  The
>    option has no effect if an appropriate middlebox is not present on
>    the path.

  I'd move all the rest of the abstract to the introduction; not appropriate
  for the abstract.

Section 6., paragraph 4:
>    The TCP-MDO option is incompatible with TCP options which aim to
>    protect the integrity of the TCP SYN.  An example of such an option
>    is the TCP MD5 signature option[RFC2385].  Such TCP options are not
>    commonly seen by current WAN optimization systems, so the restriction
>    should not pose any worries.

  Also, more importantly, TCP-AO.

Section 7., paragraph 3:
>    IANA is also requested to assign an 8 bit vendor code that can be
>    used to differentiate multiple vendors and to maintain an associated
>    registry.

  Insufficient information to define the registry. Please read RFC5226
  on how to write an IANA considerations section.

Section 7., paragraph 5:
>        Vendor               TCP option number
>        --------------------------------------
>        Bluecoat             253
>        Cisco                33

  I thought we also knew about Riverbed and Citrix?

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 5 Mar 2012 12:42:25 -0600

Thanks for posting the draft.

The intention is to handle this as an AD-sponsored document,
not via an IETF working group.

No presentation is needed.

When all of the authors have agreed on it and consider it to
be done, I will ask for a shepherd to do a writeup on it, and
I will do an AD review.  If it's acceptable, I'll send it
to IETF Last Call and through the rest of the IESG at that point.

At that point, I also think it will be good to notify TSVAREA
of it so that people have the opportunity to check it out during
the IETF LC.

--
Wes Eddy
MTI Systems

>Sent: Friday, March 02, 2012 7:43 PM

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 5 Mar 2012 10:56:31 -0800

Wes,

> From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 10:42 AM
> To: Anantha Ramaiah (ananth); David Harrington; Wesley Eddy;
> [email-masked]
> Subject: RE: [middisc] middisc specification update
> 

>From my point of view, I am done. Other stakeholders also have reviewed
this document and they seem ok with it (as far as I can tell).  They can
comment in any case.

> to IETF Last Call and through the rest of the IESG at that point.

Great.

> of it so that people have the opportunity to check it out during

Sure, that makes sense. 

One process question though, what would be the "intended status" of this
document?. If it was IETF WG doc, it would have been a standards
track... since it is taking the AD sponsored route, I am assuming it
needs to be informational.. not sure. Short question is : "is it ok to
have a TCP option allocation request draft to be categorized as a
non-standards track?"

Thanks,
-Anantha
What

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 5 Mar 2012 13:19:21 -0600

Since we want vendors to move off of other codepoints and onto
whatever one may be allocated for this, I think Informational
may not be quite right.

Experimental could capture this well.  We want vendors to
implement it and try it out.  The "experiment" is really to
see if people will use this or not, and whether it succeeds in
relieving some of the chaos of unallocated options in use.  I
think this would also require making sure there's clear
discussion in the document of why the existing experimental
codepoints aren't felt to be sufficient for this (especially
since one has already been successfully used by one vendor!).

>From: Anantha Ramaiah (ananth) [mailto:[email-masked]]
>Sent: Monday, March 05, 2012 1:57 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington;
>Wesley Eddy; [email-masked]

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 5 Mar 2012 11:44:25 -0800

Wes,

> Sent: Monday, March 05, 2012 11:19 AM

Ok.

> relieving some of the chaos of unallocated options in use.  I

Right, from vendors pov, experimental may sound fine. But from IETF
standards pov, this sort of an effort is aimed at reducing unauthorized
TCP option poaching and if such a draft exists it would both act as a
recommendation and for vendors to not use unauthorized options. In such
cases would experimental convey the "strong" message. May be some text
needs to be added to the draft echoing what you alluded above...

> since one has already been successfully used by one vendor!).

- in some cases existing code points would work, provided they are not
used by other purposes and not allocated by IANA for other purposes.
- in some cases where experimental TCP option code points are used
(Bluecoat?) they would collide with other experimental TCP option code
points.

So, in any case having a single TCP option code point eliminates these
surprises and also would be considered as a step forward for even going
down the road of interoperability among various vendors (wishful
thinking but always start with a better hope...)

I am not sure these things are spelled out clearly in the draft, but the
message is spread across and may be if there is a need for making it
more clear, please let us know.

Also if the status is experimental, I am assuming that we would still
get a regular TCP option code point and not the TCP experimental option
code point. I am assuming when you said experiment above it is more on
the lines of multiple vendors dis-continuing and using the standard TCP
option number that is allocated for this purpose.

Thanks,
-Anantha
> >> >I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which
is
> a
> >> >> IETF deadlines. I'll start looking into this very soon.  I
assume
> >we
> >> >> are
> >> >> talking about the -00- cutoff deadline here and the IETF page
> says
> >> it
> >> >> is
> >> >> March 5th.
> >> >> -Anantha
> >> >>
> >> >> > From: [email-masked] [mailto:middisc-
> [email-masked]]
> >> On
> >> >> > > correctly, Andrew has the pen and should be working on
either
> a

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 6 Mar 2012 07:17:00 -0800

Hi Lars,
 
 I missed this email and just got to this. Comments inline..

> Behalf Of Eggert, Lars
> Sent: Monday, March 05, 2012 1:32 AM
> To: [email-masked]
> Cc: Martin Stiemerling

Right, to my reply to Wes's other email, I acknowledged that there is
need to add text to cover the aspect of option poaching etc.,

>   You need to make this PS. Or do you want to ask for IESG Approval of

Wes's response to my comment was to make it Experimental. So we have 3
choices : info (current), experimental and PS.
I am not sure, whichever is the fastest route in getting the TCP option
allocated, I'll take that :-) Of course, this is just my opinion. Other
stakeholders may have different opinion.

>   I'd move all the rest of the abstract to the introduction; not

Good point. I'll move the rest to the introduction section.

>   Also, more importantly, TCP-AO.

Right, I just gave an example. I can also list AO as reference.

Ok.

>   I thought we also knew about Riverbed and Citrix?

Right, I know Riverbed's option usage, not sure about Citrix. Does
anyone have a contact point for Citrix?

Thanks,
-Anantha

---

From: "Frederick, Ron" <[email-masked]>
Date: Wed, 7 Mar 2012 03:22:29 +0000

> this document and they seem ok with it (as far as I can tell).  They can

I'm generally good with the latest draft, but there are a few items that I think we need to address:

1) I think it would be good to rename the option to make it clear that it can be used for more than just discovery. The text already describes being able to use the option to provide information to other middleboxes on the path. I think we just need to emphasize that a bit more and make it clear that discovery is only one potential use for the option.

2) The current text explicitly discourages end hosts from participating in this exchange. I think that's a mistake. In some cases, a "soft" implementation of a middlebox could run directly on a client or a server, and it would want to be able to interoperate with other physical middleboxes that expect to see this option. We want to be able to support that use case by allowing the soft middlebox on one of the end hosts to add or respond to this option.

3) I'm good with supporting the single byte vendor code with vendor-specific payload data after it, but I think we should at least leave some provision in there for the other two cases we previously discussed of standard type codes and an escape of some kind for a longer vendor code if we're wrong about the adoption of this and we run out of space in the single byte.

I think we can address #2 here by reserving vendor code 0xFF for an extended vendor code that could be based on something like an OUI. If that's too big, we could also do something like say that setting the high-bit in the vendor code expands it to 16 bits. So, the first 128 vendor codes are one byte, and then we get another ~32K of them which are two bytes.
-- 
Ron Frederick
[email-masked]

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 6 Mar 2012 23:55:23 -0800

Hi Ron,

<snip>

> 1) I think it would be good to rename the option to make it clear that
> it can be used for more than just discovery. The text already
describes
> being able to use the option to provide information to other
> middleboxes on the path. I think we just need to emphasize that a bit
> more and make it clear that discovery is only one potential use for
the
> option.

Yes, I had proposed this long time back but somehow did not hear an
explicit support. Ok, how about naming the draft as "TCP middlebox
option" and the current use case is about middlebox discovery.  There
are handful of vendors doing WAN optimization today and a 255 byte
vendor code is a whole lot. Hence if we make this option generic
looking, other use cases can be handled as well. I need to make one
thing clear : it is the not the intention of the draft to encourage
middlebox insertions and uses, just to make this option extensible, so
that at the discretion of IETF if there exists a strong use case
tomorrow, this option can come to rescue.

> 
> 2) The current text explicitly discourages end hosts from
participating
> in this exchange. I think that's a mistake. In some cases, a "soft"
> implementation of a middlebox could run directly on a client or a
> server, and it would want to be able to interoperate with other
> physical middleboxes that expect to see this option. We want to be
able
> to support that use case by allowing the soft middlebox on one of the
> end hosts to add or respond to this option.

Middlebox can run inside the host as well, I guess middlebox definition
is something that sits in the middle of the connection, if you run
something that snoops on selected connections and does something to the
TCP traffic it is still a middlebox. Maybe can note this in the
terminology section.

> 
> 3) I'm good with supporting the single byte vendor code with vendor-
> specific payload data after it, but I think we should at least leave
> some provision in there for the other two cases we previously
discussed
> of standard type codes and an escape of some kind for a longer vendor
> code if we're wrong about the adoption of this and we run out of space
> in the single byte.

Fair enough.  We can note that some vendor codes are going to be
reserved (FF to F0). These can be used to extend as needed tomorrow.
Would that address your concern?

> 
> I think we can address #2 here by reserving vendor code 0xFF for an

You mean #3 above ?

> extended vendor code that could be based on something like an OUI. If
> that's too big, we could also do something like say that setting the
> high-bit in the vendor code expands it to 16 bits. So, the first 128
> vendor codes are one byte, and then we get another ~32K of them which
> are two bytes.

Well, I am happy with reserving some extended vendor codes for future
extension. I think envisioning a 32 bit vendor code at this point seems
very dubious to me at best. I also think we can use your MSB trick above
to separate vendor codes from other codes if there is a need to have
this option used for some other cases like NAT reveal etc.,

Thanks,
Anantha

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 7 Mar 2012 08:03:42 +0000

> Would that address your concern?

Idle thought: What makes us think that vendors will go through IANA to get one of these codepoints, when they have been squatting on option numbers already?

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 7 Mar 2012 00:18:50 -0800

Lars,
    Actually a good question. My simple answer (as you probably can
guess) is to have some provision made in a hope that any vendor would
try to approach the IETF before trying to adopt other evil means. It is
a just a best effort, I guess :-)
    Funny, since IETF is not a policing agency, but I would be tempted
to think if enough visibility is made on use cases that are "illegal"
then that would force vendors to change, but there seems to be no formal
way of enforcing this other than using some methods like this. Just let
us take the example of the current draft. Mani (Cisco) who was one of
the early architect of the WAN opt solution approached the IANA for
getting this TCP option allocated, but later on got busy and never
followed it up. Then with Bluecoat's draft,  and the formation of
middisc we have multiple vendors participating on this effort and
agreeing in principle to move to the new TCP option. This is definitely
a good progress and I should thank the initiative taken by you and Wes
and David's support for getting this alias formed.

-Anantha

> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 12:04 AM
> To: Anantha Ramaiah (ananth)
> Cc: Frederick, Ron; <[email-masked]>
> Idle thought: What makes us think that vendors will go through IANA to
> get one of these codepoints, when they have been squatting on option
> numbers already?
> 
> Lars

---

From: "Mani Ramasamy (mani)" <[email-masked]>
Date: Wed, 7 Mar 2012 06:31:54 -0800

I agree with Anantha. If the process is light weight with a reasonably
quick turnaround time, I think it would encourage the vendors to get
their code points registered.

Mani.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anantha Ramaiah (ananth)
Sent: Wednesday, March 07, 2012 12:19 AM
To: Eggert, Lars
Cc: Frederick, Ron; [email-masked]
Subject: Re: [middisc] middisc specification update

Lars,

-Anantha

---

From: David Harrington <[email-masked]>
Date: Wed, 07 Mar 2012 10:27:05 -0500

Hi,

I will just observe that the IETF goal is to get cross-vendor
interoperability (and to get vendors to use an assigned code point),
because that helps the Internet run better.

It is not very consistent with IETF goals to define a standard option
through which vendors can add all sorts of proprietary solutions. We
really would like to see industry standardization of middlebox discovery,
not provide a place for vendors to invent a bunch of new non-interoperable
solutions.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 3/6/12 10:22 PM, "Frederick, Ron" <[email-masked]> wrote:

>1) I think it would be good to rename the option to make it clear that it
>can be used for more than just discovery. The text already describes
>being able to use the option to provide information to other middleboxes
>on the path. I think we just need to emphasize that a bit more and make
>it clear that discovery is only one potential use for the option.
>
>2) The current text explicitly discourages end hosts from participating
>implementation of a middlebox could run directly on a client or a server,
>and it would want to be able to interoperate with other physical
>middleboxes that expect to see this option. We want to be able to support
>that use case by allowing the soft middlebox on one of the end hosts to
>add or respond to this option.
>
>3) I'm good with supporting the single byte vendor code with
>vendor-specific payload data after it, but I think we should at least
>leave some provision in there for the other two cases we previously
>discussed of standard type codes and an escape of some kind for a longer
>vendor code if we're wrong about the adoption of this and we run out of
>space in the single byte.
>
>vendor codes are one byte, and then we get another ~32K of them which are
>two bytes.
>-- 
>Ron Frederick
>[email-masked]
>

---

From: "Frederick, Ron" <[email-masked]>
Date: Thu, 8 Mar 2012 18:54:45 +0000

On Mar 6, 2012, at 11:55 PM, Anantha Ramaiah (ananth) wrote:
>> it can be used for more than just discovery. The text already describes
>> more and make it clear that discovery is only one potential use for the
>> option.
> 

I was thinking of something like "TCP middlebox negotiation option". It's more general than discovery, but it's still getting at the core use cases here which I think are all related to the middleboxes both discovering each other and negotiating a set of transformations they want to apply to the data stream.

>> physical middleboxes that expect to see this option. We want to be able

That seems like a reasonable way of looking at it. If this can be clarified in the text, that should cover my objection.

>> some provision in there for the other two cases we previously discussed

Given the previous discussion we had on the list of not wanting to use more than one byte for "standard" type codes, I'm not sure that reserving a small range of vendor codes is quite enough here. Originally, I had proposed reserving only 0x00 for standard types and 0xff for extended vendor codes, but that wasn't accepted by the group.

>> I think we can address #2 here by reserving vendor code 0xFF for an

Yes, sorry - I did. I edited my list of points while composing the mail and forgot to update this reference. :)

> this option used for some other cases like NAT reveal etc.,

The OUI would be 24 bits, but with the 0xFF I guess that would turn into 32 bits total. The other option here would be to use the IANA private enterprise number, but I think that's allowed to be up to 32 bits in length (though IANA has only assigned around 40,000 of them so far).

I'm good with reserving 0xFF for extended vendor codes without specifying the rest of the mechanism here, but that still leaves open the question about how we want to make room for standard middlebox message types. As David Harrington pointed out, we should be trying to encourage this, so we should have a good story for how such cases can use this option. Previously I suggested the following:

> Allow standard type codes to be allocated starting with 0x00 in an increasing fashion and allow vendor codes to be allocated starting with 0xFE in a decreasing fashion. At some point, if it looks like too many vendor codes are being allocated, IANA can declare that no more are available and that additional vendors must use the 0xFF form with an OUI, leaving the remainder of the space for standard type codes.

What do others think of this?
-- 
Ron Frederick
[email-masked]

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 8 Mar 2012 11:29:22 -0800

I like the idea of assigning vendor codes from one end and standard 
codes from the other, with one code reserved for future expansion.  I 
also like the idea of not specifying the expansion mechanism; that can 
wait until more requirements are known.

Andrew

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 8 Mar 2012 12:26:50 -0800

Hi Ron,
> 
> > Allow standard type codes to be allocated starting with 0x00 in an
> increasing fashion and allow vendor codes to be allocated starting
with
> 0xFE in a decreasing fashion. At some point, if it looks like too many
> vendor codes are being allocated, IANA can declare that no more are
> available and that additional vendors must use the 0xFF form with an
> OUI, leaving the remainder of the space for standard type codes.
> 

Question : when you say vendor code, are you saying one vendor can get
multiple vendor codes? Or is strictly one per vendor. I assumed the
latter.

When you say "standard type", what are those? Are those the ones used by
multiple vendors and really interoperable?

Just wanted to make sure we both are on the same page w.r.t terminology.

-Anantha

---

From: "Frederick, Ron" <[email-masked]>
Date: Thu, 8 Mar 2012 20:34:15 +0000

On Mar 8, 2012, at 12:26 PM, Anantha Ramaiah (ananth) wrote:
>> increasing fashion and allow vendor codes to be allocated starting with

In cases where a vendor wants their own vendor code, my thinking was that they only get one. If they need multiple middlebox option types, they would have to distinguish them using some other bits in the vendor-specific payload. If they didn't make provisions in advance for that, they'd have to either adjust their payload format later to add it, or have their additional options use the 0xFF+OUI version of the header.

> Just wanted to make sure we both are on the same page w.r.t terminology.

Yes - the notion would be that we could standardize certain payload types which could be used to interoperate between vendors. These would have RFCs associated with them, and they would be assigned a type code by IANA which would come out of the same space as the vendor codes. To keep them organized, though, the standard type codes would be assigned counting up from 0x00 and the vendor codes would be assigned counting down from 0xFE (with 0xFF reserved for longer vendor codes).
-- 
Ron Frederick
[email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 13 Mar 2012 12:24:27 -0400

> needs to be added to the draft echoing what you alluded above...

I have a real problem with Standards Track, given that the middlebox
association seemed to introduce a combination of distaste and
eventual disinterest in TCPM.  Also, based on the slow progress in
getting this specification done, I have some doubt that it will
quickly be integrated into products and deployed.  I think that given
the options we have, Experimental is a reasonable fit, and if it does
wind up in wide use by multiple vendors, we can look at advancing it.

> more clear, please let us know.

I would like it to be very clear.

> option number that is allocated for this purpose.

With IESG approval, a regular option can be allocated, regardless of
whether the document status is Experimental.

-- 
Wes Eddy
MTI Systems

---

From: "Knutsen, Andrew" <[email-masked]>
Date: Tue, 13 Mar 2012 16:37:50 +0000

The ultimate goal is to move towards inter-vendor solutions, which is why we're providing for "standard" types as well as vendor types.  However, this will take some time, so we also have an intermediate goal which is to stop using unassigned option kinds.

Andrew
________________________________________
From: [email-masked] [[email-masked]] on behalf of David Harrington [[email-masked]]
Sent: Wednesday, March 07, 2012 7:27 AM
To: Frederick, Ron; Anantha Ramaiah (ananth)
Cc: [email-masked]
Subject: Re: [middisc] middisc specification update

Hi,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 13 Mar 2012 10:16:16 -0700

Hi Wes,
    Ok, I am on page with the process now and I am fine with the status
being experimental ( I guess it should be ok with others as well). So,
the next steps are I guess is to revise the draft with the comments
received so far, put the intended status to "experimental" and re-submit
it. I guess the IETF submission re-opens after IETF meeting, so I'll
have some time to do this. I'll be coming to IETF this time and we can
chat sometime when you are free.

   Just to add (in response to your concern below): From the various
email discussions there is a lot of interest among multiple vendors
(Bluecoat, Riverbed and Cisco) to move towards the new TCP option when
it gets allocated, but the obvious challenge is going to be backwards
compatibility and eventual EOL of boxes doing the unassigned options. It
will take time for sure but it should eventually happen I guess.

-Anantha

> From: Wesley Eddy [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2012 9:24 AM
> Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington;
> [email-masked]