From ananth@cisco.com Sat May 14 19:23:43 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961A5E06E9 for ; Sat, 14 May 2011 19:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYmeQ-KPln7d for ; Sat, 14 May 2011 19:23:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id AFE04E066E for ; Sat, 14 May 2011 19:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=9450; q=dns/txt; s=iport; t=1305426221; x=1306635821; h=mime-version:subject:date:message-id:from:to:cc; bh=Ba1klorTGNsF5UZ23IBo1S2wylOgK+sWH/2ei6Az8QA=; b=dYmoVwPxMh8bXMLe6a1qFW9E0XkZsZ53cc+Ya8bHjGPALUj+d45yXT2k a4GGxH5viRPLUnnhP5yPDEtuprEaPpNGHxicSnZqf31YjSqo6+AZSnYNu ojIM/NSov2ULw4W90DM5bC3QMLrh9OJ/uJxAx1HDd22WbwrdqIuY2L58o Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIIAOw3z02rRDoI/2dsb2JhbACCY5UtjgV3qWKce4YZBIZQjXmKXQ X-IronPort-AV: E=Sophos;i="4.64,368,1301875200"; d="scan'208,217";a="357189944" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 May 2011 02:23:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4F2Nfm7027810; Sun, 15 May 2011 02:23:41 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 May 2011 19:23:41 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC12A7.1AC78B57" Date: Sat, 14 May 2011 19:23:39 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP middlebox option - Revisted. Thread-Index: AcwSpxovbFamaQqLQq6w70HD5/Xs9g== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 15 May 2011 02:23:41.0108 (UTC) FILETIME=[1B23EF40:01CC12A7] Cc: Wesley Eddy , Steven Campbell Subject: [middisc] TCP middlebox option - Revisted. X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 02:23:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC12A7.1AC78B57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, During the last IETF, we (Steven from Riverbed and myself) briefly chatted with Wes (the new transport AD) . Following needs to happen to move forward :- =20 - We agree upon the option format. 3 choices were proposed. >From my pov, I would stick with the one that is most generic since there is more flexibility and can easily accommodate multiple vendor option formats. - The draft needs some upgrade in terms of describing the problem scope/requirements, add motivation section, interoperability with other TCP options etc., and just list the option format for which we all agree upon. - The draft needs to have contributors (or authors) from each vendor, Bluecoat, Riverbed, Cisco and if possible Citrix. This way it simply reflects that this is joint effort .=20 - Then we can submit this to IESG/IANA and request for the option allocation. =20 Actually it has been a while and it was kind of low priority for all of us, but since we all started with a intention of getting the TCP option allocated , I am thinking that there is no point in losing the momentum. =20 -Anantha ------_=_NextPart_001_01CC12A7.1AC78B57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

     During the last IETF, =  we  (Steven from Riverbed and myself) briefly chatted with = Wes (the new transport AD) . Following needs to happen to move forward = :-

 

-          = We agree upon the option format. 3 choices were = proposed.  From my pov, I would stick with the one that is most = generic since there is more flexibility and can easily accommodate = multiple vendor option formats.

-          = The draft needs some upgrade in terms of = describing the problem scope/requirements, add motivation section,  = interoperability with other TCP options etc., and just list the option = format for which we all agree upon.

-          = The draft needs to have contributors (or = authors) from each vendor, Bluecoat, Riverbed, Cisco and if possible = Citrix.  This way it simply reflects that this is joint effort . =

-          = Then we can submit this to IESG/IANA and request = for the option allocation.

 

Actually it = has been a while and it was kind of low priority for all of us, but = since we all started with a intention of getting the TCP option = allocated , I am thinking that there is no point in losing the momentum. =

 

-Anantha

------_=_NextPart_001_01CC12A7.1AC78B57-- From wes@mti-systems.com Sat May 14 20:16:29 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6988E0679 for ; Sat, 14 May 2011 20:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEwo2X7zMblX for ; Sat, 14 May 2011 20:16:29 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 402F3E066E for ; Sat, 14 May 2011 20:16:25 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p4F3GPep011583 for ; Sat, 14 May 2011 23:16:25 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.78.52] ([174.130.78.52:32276] helo=[192.168.1.104]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FE/FF-29199-8854FCD4; Sat, 14 May 2011 23:16:25 -0400 Message-ID: <4DCF458A.5050009@mti-systems.com> Date: Sat, 14 May 2011 23:16:26 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 May 2011 07:12:42 -0700 Cc: middisc@ietf.org, Steven Campbell Subject: Re: [middisc] TCP middlebox option - Revisted. X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 03:16:30 -0000 On 5/14/2011 10:23 PM, Anantha Ramaiah (ananth) wrote: > Guys, > > During the last IETF, we (Steven from Riverbed and myself) briefly > chatted with Wes (the new transport AD) . Following needs to happen to > move forward :- > > -We agree upon the option format. 3 choices were proposed. From my pov, > I would stick with the one that is most generic since there is more > flexibility and can easily accommodate multiple vendor option formats. > > -The draft needs some upgrade in terms of describing the problem > scope/requirements, add motivation section, interoperability with other > TCP options etc., and just list the option format for which we all agree > upon. > > -The draft needs to have contributors (or authors) from each vendor, > Bluecoat, Riverbed, Cisco and if possible Citrix. This way it simply > reflects that this is joint effort . > > -Then we can submit this to IESG/IANA and request for the option allocation. > > Actually it has been a while and it was kind of low priority for all of > us, but since we all started with a intention of getting the TCP option > allocated , I am thinking that there is no point in losing the momentum. > Thanks for sending this. Just one small clarification: I will AD-sponsor this, so I will initiate the IESG review when it's ready. IANA will look at it at that point. The authors do not need to submit anything to the IESG or IANA themselves in regards to publishing this draft. -- Wes Eddy MTI Systems From Mark.Day@riverbed.com Sun May 15 14:09:33 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96D1E069D for ; Sun, 15 May 2011 14:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONq2MG2eNJc5 for ; Sun, 15 May 2011 14:09:32 -0700 (PDT) Received: from smtp1.riverbed.com (eng.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 09B58E06AF for ; Sun, 15 May 2011 14:09:32 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 15 May 2011 14:09:31 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.205.165]) with mapi; Sun, 15 May 2011 14:09:31 -0700 From: Mark Day To: "Anantha Ramaiah (ananth)" , "middisc@ietf.org" Date: Sun, 15 May 2011 14:09:32 -0700 Thread-Topic: TCP middlebox option - Revisted. Thread-Index: AcwSpxovbFamaQqLQq6w70HD5/Xs9gAnKhdw Message-ID: References: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D111C93CBB79EMAILBOXES2nbt_" MIME-Version: 1.0 Cc: Wesley Eddy , Steven Campbell Subject: Re: [middisc] TCP middlebox option - Revisted. X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 21:09:33 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D111C93CBB79EMAILBOXES2nbt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anantha, Thanks for restarting the thread. I'm keen to get going on the tasks you o= utline. My personal opinion is that it would actually be easier and more straightfo= rward to write a new draft capturing the state of the discussion at the poi= nt where things petered out, rather than trying to adjust the existing draf= t which was originally written with a somewhat different goal. However I'm= mostly interested in making progress and so I'm happy to back off that opi= nion if people are keen to move the previous draft forward. Thanks, --Mark From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Anantha Ramaiah (ananth) Sent: Saturday, May 14, 2011 10:24 PM To: middisc@ietf.org Cc: Wesley Eddy; Steven Campbell Subject: [middisc] TCP middlebox option - Revisted. Guys, During the last IETF, we (Steven from Riverbed and myself) briefly c= hatted with Wes (the new transport AD) . Following needs to happen to move = forward :- - We agree upon the option format. 3 choices were proposed. From = my pov, I would stick with the one that is most generic since there is more= flexibility and can easily accommodate multiple vendor option formats. - The draft needs some upgrade in terms of describing the problem = scope/requirements, add motivation section, interoperability with other TC= P options etc., and just list the option format for which we all agree upon= . - The draft needs to have contributors (or authors) from each vend= or, Bluecoat, Riverbed, Cisco and if possible Citrix. This way it simply r= eflects that this is joint effort . - Then we can submit this to IESG/IANA and request for the option = allocation. Actually it has been a while and it was kind of low priority for all of us,= but since we all started with a intention of getting the TCP option alloca= ted , I am thinking that there is no point in losing the momentum. -Anantha --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D111C93CBB79EMAILBOXES2nbt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anantha,

 

Thanks for restarting the thread.  I’= m keen to get going on the tasks you outline. 

<= p class=3DMsoNormal> <= /p>

My personal opinion i= s that it would actually be easier and more straightforward to write a new = draft capturing the state of the discussion at the point where things peter= ed out, rather than trying to adjust the existing draft which was originall= y written with a somewhat different goal.  However I’m mostly in= terested in making progress and so I’m happy to back off that opinion= if people are keen to move the previous draft forward.

 

Thanks,=

 

--Mark

=  

From: middisc-bounc= es@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Anantha R= amaiah (ananth)
Sent: Saturday, May 14, 2011 10:24 PM
To: middisc@ietf.org
Cc: Wesley Eddy; Steven Campbell
Subjec= t: [middisc] TCP middlebox option - Revisted.

 

Guys= ,

     During the la= st IETF,  we  (Steven from Riverbed and myself) briefly chatted w= ith Wes (the new transport AD) . Following needs to happen to move forward = :-

 

-          We agree upon the option format. 3 choices were proposed.=   From my pov, I would stick with the one that is most generic since t= here is more flexibility and can easily accommodate multiple vendor option = formats.

-   &nbs= p;      The draft needs so= me upgrade in terms of describing the problem scope/requirements, add motiv= ation section,  interoperability with other TCP options etc., and just= list the option format for which we all agree upon.

-         = ; The draft needs to have contributors (or authors)= from each vendor, Bluecoat, Riverbed, Cisco and if possible Citrix.  = This way it simply reflects that this is joint effort .

-        &= nbsp; Then we can submit this to IESG/IANA and requ= est for the option allocation.

&nbs= p;

Actually it has been a while and it was ki= nd of low priority for all of us, but since we all started with a intention= of getting the TCP option allocated , I am thinking that there is no point= in losing the momentum.

 

-Anantha

= --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D111C93CBB79EMAILBOXES2nbt_-- From andrew.knutsen@bluecoat.com Mon May 16 13:51:20 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6CE07D5 for ; Mon, 16 May 2011 13:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCgbZLNrjBjp for ; Mon, 16 May 2011 13:51:18 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6449EE079A for ; Mon, 16 May 2011 13:51:16 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4GIOPop006781; Mon, 16 May 2011 11:24:26 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 May 2011 11:24:20 -0700 Message-ID: <4DD16BD3.2080601@bluecoat.com> Date: Mon, 16 May 2011 11:24:19 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Day References: <0C53DCFB700D144284A584F54711EC580CB7D34E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070104020002070808090107" X-OriginalArrivalTime: 16 May 2011 18:24:20.0022 (UTC) FILETIME=[7905FD60:01CC13F6] Cc: Wesley Eddy , "middisc@ietf.org" , Steven Campbell Subject: Re: [middisc] TCP middlebox option - Revisted. X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 20:51:20 -0000 This is a multi-part message in MIME format. --------------070104020002070808090107 Content-Type: multipart/alternative; boundary="------------020405050904090701050901" --------------020405050904090701050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm glad to see interest again too. Every time we do a rev to our protocol, I regret missing the chance to change the code. I agree we should do a new draft. It seems like the consensus was to reduce the amount of specification of the use of the option to the absolute minimum needed to avoid its use as a "catch-all". I've attached Ron's last proposal. Hopefully we can start from there. Andrew On 5/15/2011 2:09 PM, Mark Day wrote: > > Hi Anantha, > > Thanks for restarting the thread. I'm keen to get going on the tasks > you outline. > > My personal opinion is that it would actually be easier and more > straightforward to write a new draft capturing the state of the > discussion at the point where things petered out, rather than trying > to adjust the existing draft which was originally written with a > somewhat different goal. However I'm mostly interested in making > progress and so I'm happy to back off that opinion if people are keen > to move the previous draft forward. > > Thanks, > > --Mark > > *From:*middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] *On > Behalf Of *Anantha Ramaiah (ananth) > *Sent:* Saturday, May 14, 2011 10:24 PM > *To:* middisc@ietf.org > *Cc:* Wesley Eddy; Steven Campbell > *Subject:* [middisc] TCP middlebox option - Revisted. > > Guys, > > During the last IETF, we (Steven from Riverbed and myself) > briefly chatted with Wes (the new transport AD) . Following needs to > happen to move forward :- > > -We agree upon the option format. 3 choices were proposed. From my > pov, I would stick with the one that is most generic since there is > more flexibility and can easily accommodate multiple vendor option > formats. > > -The draft needs some upgrade in terms of describing the problem > scope/requirements, add motivation section, interoperability with > other TCP options etc., and just list the option format for which we > all agree upon. > > -The draft needs to have contributors (or authors) from each vendor, > Bluecoat, Riverbed, Cisco and if possible Citrix. This way it simply > reflects that this is joint effort . > > -Then we can submit this to IESG/IANA and request for the option > allocation. > > Actually it has been a while and it was kind of low priority for all > of us, but since we all started with a intention of getting the TCP > option allocated , I am thinking that there is no point in losing the > momentum. > > -Anantha > > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc --------------020405050904090701050901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
   I'm glad to see interest again too.  Every time we do a rev to our protocol, I regret missing the chance to change the code.

   I agree we should do a new draft.  It seems like the consensus was to reduce the amount of specification of the use of the option to the absolute minimum needed to avoid its use as a "catch-all".

   I've attached Ron's last proposal.  Hopefully we can start from there.

Andrew

On 5/15/2011 2:09 PM, Mark Day wrote:

Hi Anantha,

 

Thanks for restarting the thread.  I’m keen to get going on the tasks you outline. 

 

My personal opinion is that it would actually be easier and more straightforward to write a new draft capturing the state of the discussion at the point where things petered out, rather than trying to adjust the existing draft which was originally written with a somewhat different goal.  However I’m mostly interested in making progress and so I’m happy to back off that opinion if people are keen to move the previous draft forward.

 

Thanks,

 

--Mark

 

From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Anantha Ramaiah (ananth)
Sent: Saturday, May 14, 2011 10:24 PM
To: middisc@ietf.org
Cc: Wesley Eddy; Steven Campbell
Subject: [middisc] TCP middlebox option - Revisted.

 

Guys,

     During the last IETF,  we  (Steven from Riverbed and myself) briefly chatted with Wes (the new transport AD) . Following needs to happen to move forward :-

 

-          We agree upon the option format. 3 choices were proposed.  From my pov, I would stick with the one that is most generic since there is more flexibility and can easily accommodate multiple vendor option formats.

-          The draft needs some upgrade in terms of describing the problem scope/requirements, add motivation section,  interoperability with other TCP options etc., and just list the option format for which we all agree upon.

-          The draft needs to have contributors (or authors) from each vendor, Bluecoat, Riverbed, Cisco and if possible Citrix.  This way it simply reflects that this is joint effort .

-          Then we can submit this to IESG/IANA and request for the option allocation.

 

Actually it has been a while and it was kind of low priority for all of us, but since we all started with a intention of getting the TCP option allocated , I am thinking that there is no point in losing the momentum.

 

-Anantha

_______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc

--------------020405050904090701050901-- --------------070104020002070808090107 Content-Type: message/rfc822; name="Fwd [middisc] Poll re vendor ID format.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Fwd [middisc] Poll re vendor ID format.eml" Received: from exchfront1.internal.cacheflow.com ([10.2.2.114]) by bcs-mail03.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 14:16:20 -0700 Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 14:16:20 -0700 From: Ron Frederick Content-Type: multipart/alternative; boundary=Apple-Mail-336-705669759 Subject: Fwd: [middisc] Poll re vendor ID format Date: Tue, 20 Jul 2010 14:16:20 -0700 References: <2177A9D6-6D49-4E9E-B745-11C15EFDF43E@bluecoat.com> To: Andrew Knutsen Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Return-Path: ronf@bluecoat.com X-OriginalArrivalTime: 20 Jul 2010 21:16:20.0301 (UTC) FILETIME=[CC7697D0:01CB2850] --Apple-Mail-336-705669759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This was the last message -- I never got a reply from anyone on this. Begin forwarded message: > From: Ron Frederick > Date: July 1, 2010 6:37:35 PM PDT > To: Mark Day > Cc: "middisc@ietf.org" > Subject: Re: [middisc] Poll re vendor ID format >=20 > On Jun 30, 2010, at 11:23 AM, Mark Day wrote: >> Yes, I guess so. Not exactly elegant conceptually, I admit.=20 >> =20 >> But if the goal is to have the type byte in a predictable place = across all standard, vendor-ID & OUI usages, while minimizing the number = of bytes of mandatory overhead, I think it=92s the right solution.=20 >=20 > While it's not ideal, I can live with it. So, to summarize, I think = we're proposing the following alternatives as supported: >=20 > Case 1: >=20 > 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=3DTBD | Opt len | Vendor =3D 0x00 | Std type code | > +---------------+---------------+---------------+---------------+ > | | > | ... Optional standard payload data dependent on type code ... | > | | > +---------------+---------------+---------------+---------------+ >=20 > Case 2: >=20 > 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=3DTBD | Opt len | Vendor =3D 0xFF | Vend typecode | > +---------------+---------------+---------------+---------------+ > | Vendor OUI (3 bytes) | | > +---------------+---------------+---------------+ | > | | > | ...Optional vendor payload data dependent on vend typecode... | > | | > +---------------+---------------+---------------+---------------+ >=20 > Case 3: >=20 > 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=3DTBD | Opt len | Vendor=3DOther | | > +---------------+---------------+---------------+ | > | | > | ...Optional vendor payload data dependent on vend typecode... | > | | > +---------------+---------------+---------------+---------------+ >=20 > In case 3, the byte following the Vendor field SHOULD be a vendor type = code, as shown in case 2. However, vendors MAY encode option type = information in other ways for their specific vendor code. >=20 > Is everyone ok with this? --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-336-705669759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Ron Frederick <ronf@bluecoat.com>
Date: July 1, 2010 = 6:37:35 PM PDT
To: Mark Day <Mark.Day@riverbed.com>
=
Subject: Re: [middisc] = Poll re vendor ID format

On Jun 30, 2010, at 11:23 AM, Mark Day = wrote:
Yes, I guess so.  = Not exactly elegant conceptually, I = admit. 
But = if the goal is to have the type byte in a predictable place across all = standard, vendor-ID & OUI usages, while minimizing the number of = bytes of mandatory overhead, I think it=92s the right = solution. 

While it's not ideal, I can live with it. So, to summarize, I think = we're proposing the following alternatives as = supported:

Case = 1:

 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
+---------------+---------------+---------------+---------------+
| = Opt kind=3DTBD  |    Opt len    | Vendor =3D = 0x00 | Std type code |
+---------------+---------------+---------------+---------------+
| =                     =                     =                     =   |
| ... Optional standard payload data dependent on = type code ... |
|             =                     =                     =           |
+---------------+---------------+---------------+---------------+

Case = 2:

 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
+---------------+---------------+---------------+---------------+
| = Opt kind=3DTBD  |    Opt len    | Vendor =3D = 0xFF | Vend typecode |
+---------------+---------------+---------------+---------------+
| =              Vendor OUI (3 bytes) =             |         =       |
+---------------+---------------+---------------+ =               = |
|                   =                     =                     =     |
| ...Optional vendor payload data = dependent on vend typecode... |
| =                     =                     =                     =   |
+---------------+---------------+---------------+---------------+

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+---------------+---------------+---------------+---------------+
| Opt kind=3DTBD =  |    Opt len    | Vendor=3DOther  | =               |
+---------------+---------------+---------------+ =               |
|             =                     =                     =           |
| ...Optional vendor payload data dependent on = vend typecode... |
+---------------+---------------+---------------+---------------+

In case 3, the byte following the Vendor field SHOULD be a = vendor type code, as shown in case 2. However, vendors MAY encode option = type information in other ways for their specific vendor code.

Is everyone ok with = this?
-- 
Ron Frederick
=

= --Apple-Mail-336-705669759-- --------------070104020002070808090107-- From ietfdbh@comcast.net Tue May 24 06:13:25 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA7E066A for ; Tue, 24 May 2011 06:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yst97CMfFCpE for ; Tue, 24 May 2011 06:13:24 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2D3E073E for ; Tue, 24 May 2011 06:13:24 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id nQSh1g0011ap0As55RDQnq; Tue, 24 May 2011 13:13:24 +0000 Received: from davidPC ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id nRDP1g0212JQnJT3iRDPX2; Tue, 24 May 2011 13:13:24 +0000 From: "David Harrington" To: "'Eddy, Wesley M. \(GRC-MS00\)[ASRC AEROSPACE CORP]'" , "'Ron Frederick'" , "'Mark Day'" References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> In-Reply-To: Date: Tue, 24 May 2011 09:13:19 -0400 Message-ID: <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3QRxSuIYA= Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:13:25 -0000 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). 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. 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. 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. 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. 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 ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: middisc-bounces@ietf.org > [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements > > >-----Original Message----- > >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > >Behalf Of Ron Frederick > >Sent: Thursday, May 27, 2010 12:44 PM > >To: Mark Day > >Cc: middisc@ietf.org > >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 > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > From ietfdbh@comcast.net Tue May 24 06:48:21 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF6E06AF for ; Tue, 24 May 2011 06:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYM+5igkL04F for ; Tue, 24 May 2011 06:48:20 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id AF335E0743 for ; Tue, 24 May 2011 06:48:20 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id nQv21g0041vXlb85FRoLH9; Tue, 24 May 2011 13:48:20 +0000 Received: from davidPC ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id nRoL1g00E2JQnJT3dRoL8f; Tue, 24 May 2011 13:48:20 +0000 From: "David Harrington" To: "'Andrew Knutsen'" , "'Anantha Ramaiah \(ananth\)'" References: <3A7359FB-7D3C-4D0F-9AA1-E0E6E5874267@nokia.com><0C53DCFB700D144284A584F54711EC580B1AE8C8@xmb-sjc-21c.amer.cisco.com> <4CD9DB4A.3010107@bluecoat.com> In-Reply-To: <4CD9DB4A.3010107@bluecoat.com> Date: Tue, 24 May 2011 09:48:16 -0400 Message-ID: <8C4962ADC7C5463695F5380854C2393D@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcuAZzzJYtMamIboQA2zfmDQ+jS/MSZrsh6A Cc: middisc@ietf.org Subject: Re: [middisc] status? X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:48:21 -0000 Hi, > Requirements of this TCP option : > > - There has to be a vendor ID (OUI) which would identify the specific > vendor. This is needed because every vendors option format is going to > be > different. This is a recurring theme in my twenty years of IETF work. The purpose of the IETF is to establish **a standard** so different vendor's equipment can interoperate. The purpose of the IETF is NOT to develop a standard that allows every vendor to do things differently, to not interoperate, yet to be able to claim compliance to a "standard". You should be careful about designing a complex solution when a simple one would do. It should NOT be a goal to define a standard "bucket" to support non-interoperable vendor-specific features. and if you design it that way, you should definitely expect strong pushback during IESG evaluation. As I recall, the purpose of this group was to agree on a single standard option number for middisc, not to design an extensible approach to vendor-specific options. I see mission creep in this list of requirements. A note from the list administrator: this mailing list was created to allow you guys to resolve the unauthorized use of option numbers for middisc, preferably by agreeing on a standard option number. The IESG finds that these non-WG mailing lists can diverge into "shadow working groups" where the list members think they can devise whole new features with limited input from the IETF community. That is not the purpose of this mailing list. If you want to develop a new feature for TCP, then this should be discussed in a working group. I am asking you to **focus** on solving the existing problem, which is eliminating the unauthorized use of option numbers for middisc, not on possible future extensions. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > > - Already existing non-standardized option numbers (TCP option 33, > riverbed's options no's) for doing auto discovery should not be > allocated for this new TCP option. This is to prevent any confusion. > > - The TCP option needs to be variable length to permit multiple option > formats since the option size may vary depending on the vendor. > > - This TCP option should be advocated for use only by middleboxes. > > --------------- > > The only changes to these requirements I'm aware of were: > > - Make the overhead minimal > > - Allow evolution to vendor-independent formats > > - Allow options to be sent mid-stream > > These requirements were discussed and led to the current > proposal. > > The "NAT reveal" option, while intended for consumption by the > destination server rather than a middlebox, could use the current > proposed format as far as I can tell (adding 1 or 2 bytes). > However we > may want to tighten up the allowed uses a bit, to be more > specific than > "used by middleboxes". Perhaps something regarding communicating the > state of the middlebox, or information which has been hidden by the > middlebox. (This would permit our and the NAT-reveal uses, as > far as I > know). > > Andrew > > > > > On 11/7/2010 10:32 PM, Anantha Ramaiah (ananth) wrote: > > Lars, > > From my side, it has been real crazy at work and I > couldn't devote > > any time for this effort. I did follow the last few email > exchanges on > > this. Few thoughts I had in mind was :- > > > > - to have a generic middle box option, which not only > caters to the > > needs of middle box discovery, but also to stuff like the > following :- > > > > http://tools.ietf.org/html/draft-wing-nat-reveal-option-00 > > > > (When I did an internal review of Dan's draft, I had suggested the > > same.) > > > > - Have a requirements document for the middisc TCP option. > It appears > > to me that, there is a need for a precursor document to > establish some > > common needs and a rationale for a midisc option. This > would great help > > in getting to a faster consensus and would also help some > new vendors > > who may be want to join this effort to come to the same > page as the rest > > of us. > > > > Also, during the initial meeting, I am remembering that you were > > planning to send an email to the various IETF mailing lists > citing this > > effort and asking if there are any other vendors who do > this middisc and > > may be interested in joining this effort.. any progress on > that front? > > > > thoughts? > > > > Thanks, > > -Anantha > > > > > > -----Original Message----- > > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > > Behalf Of Lars Eggert > > Sent: Sunday, November 07, 2010 9:25 PM > > To: middisc@ietf.org > > Subject: [middisc] status? > > > > Hi, folks, > > > > I'm wondering what the status of this effort is - the list has been > > silent in the last months. > > > > Thanks, > > Lars > > _______________________________________________ > > middisc mailing list > > middisc@ietf.org > > https://www.ietf.org/mailman/listinfo/middisc > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > From wesley.m.eddy@nasa.gov Tue May 24 07:22:38 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5BBE0754 for ; Tue, 24 May 2011 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+abFYBsJXwm for ; Tue, 24 May 2011 07:22:37 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id A4CE8E0761 for ; Tue, 24 May 2011 07:22:36 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D1CD22D8527; Tue, 24 May 2011 09:22:35 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p4OEMZ67025417; Tue, 24 May 2011 09:22:35 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Tue, 24 May 2011 09:22:35 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: David Harrington , "'Ron Frederick'" , "'Mark Day'" Date: Tue, 24 May 2011 09:22:35 -0500 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3QRxSuIYAAA1T3LQ== Message-ID: References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> , <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> In-Reply-To: <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-05-24_05:2011-05-24, 2011-05-24, 1970-01-01 signatures=0 Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:22:38 -0000 Hi David, PENs are a good thought in comparison to OUIs for this purpose. I don't speak for the authors, but we have to be a bit sympathetic to the f= act that there is only very limited amount of space available for TCP optio= ns and burning 32-bits for an enterprise number is going to eat away consid= erably from the space available to do something useful. Personally, I would have no problem seeing a compact mechanism that's just = big enough to allow expandability to some double-digit multiple of the numb= er of current vendors, and also support falling back to using either a full= Private Enterprise Number or an OUI once the more compacted space is exhau= sted. ________________________________________ From: David Harrington [ietfdbh@comcast.net] Sent: Tuesday, May 24, 2011 9:13 AM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; 'Ron Frederick'; 'Mark= Day' Cc: middisc@ietf.org; 'David Harrington' 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). 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. 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. 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. 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. 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 ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: middisc-bounces@ietf.org > [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements > > >-----Original Message----- > >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > >Behalf Of Ron Frederick > >Sent: Thursday, May 27, 2010 12:44 PM > >To: Mark Day > >Cc: middisc@ietf.org > >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 > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc >= From wesley.m.eddy@nasa.gov Tue May 24 07:58:33 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1102AE075C for ; Tue, 24 May 2011 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTc+sNHc3QyR for ; Tue, 24 May 2011 07:58:32 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0EE0752 for ; Tue, 24 May 2011 07:58:31 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 4EE9610814A; Tue, 24 May 2011 09:58:31 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id p4OEwVAh002615; Tue, 24 May 2011 09:58:31 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 24 May 2011 09:58:30 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: David Harrington , "'Andrew Knutsen'" , "'Anantha Ramaiah (ananth)'" Date: Tue, 24 May 2011 09:58:30 -0500 Thread-Topic: [middisc] status? Thread-Index: AcuAZzzJYtMamIboQA2zfmDQ+jS/MSZrsh6AAAJwAig= Message-ID: References: <3A7359FB-7D3C-4D0F-9AA1-E0E6E5874267@nokia.com><0C53DCFB700D144284A584F54711EC580B1AE8C8@xmb-sjc-21c.amer.cisco.com> <4CD9DB4A.3010107@bluecoat.com>, <8C4962ADC7C5463695F5380854C2393D@davidPC> In-Reply-To: <8C4962ADC7C5463695F5380854C2393D@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-05-24_05:2011-05-24, 2011-05-24, 1970-01-01 signatures=0 Cc: "middisc@ietf.org" Subject: Re: [middisc] status? X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:58:33 -0000 Hi David, I partially agree, but would suggest to keep the history and cont= ext in mind. Some of the vendors (the ones reading this email!) are cordial enough to co= nsider moving their in-use middlebox discovery options to a properly alloca= ted option. This option needs to be nice enough in order to convince them = to put the effort into moving there. The engineers understand that this is= "the right thing" to do, but the company won't make any money from this, a= nd will have potential compatibility issues as they transition. Due to thi= s pain, they won't be able to do it simply because there's an RFC, especial= ly if that RFC doesn't meet their business needs. Those business needs may= include carrying opaque bytes of vendor-defined data. The goal of middisc (and the *need* for it) is to get a spec out that a cri= tical mass of these vendors agree is a feasible/desirable thing for them to= use in the future and get them a real option number so that maybe in a dec= ade most of their gear will be using it and we won't discover that half of = what we thought were the remaining options numbers have become unusable due= to poaching. TCPM agreed to not resist this effort, though it had no consensus to do it = in the working group. There should be a strong understanding that this is = only used for "middlebox discovery" and doesn't provide any other features,= but if opaque fields are allowed, then we may not have a whole lot of cont= rol over this. The alternative is to have no control whatsoever and possib= ly hinder the ability to extend TCP long-term. ________________________________________ From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] On Behalf Of Davi= d Harrington [ietfdbh@comcast.net] Sent: Tuesday, May 24, 2011 9:48 AM To: 'Andrew Knutsen'; 'Anantha Ramaiah (ananth)' Cc: middisc@ietf.org Subject: Re: [middisc] status? Hi, > Requirements of this TCP option : > > - There has to be a vendor ID (OUI) which would identify the specific > vendor. This is needed because every vendors option format is going to > be > different. This is a recurring theme in my twenty years of IETF work. The purpose of the IETF is to establish **a standard** so different vendor's equipment can interoperate. The purpose of the IETF is NOT to develop a standard that allows every vendor to do things differently, to not interoperate, yet to be able to claim compliance to a "standard". You should be careful about designing a complex solution when a simple one would do. It should NOT be a goal to define a standard "bucket" to support non-interoperable vendor-specific features. and if you design it that way, you should definitely expect strong pushback during IESG evaluation. As I recall, the purpose of this group was to agree on a single standard option number for middisc, not to design an extensible approach to vendor-specific options. I see mission creep in this list of requirements. A note from the list administrator: this mailing list was created to allow you guys to resolve the unauthorized use of option numbers for middisc, preferably by agreeing on a standard option number. The IESG finds that these non-WG mailing lists can diverge into "shadow working groups" where the list members think they can devise whole new features with limited input from the IETF community. That is not the purpose of this mailing list. If you want to develop a new feature for TCP, then this should be discussed in a working group. I am asking you to **focus** on solving the existing problem, which is eliminating the unauthorized use of option numbers for middisc, not on possible future extensions. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > > - Already existing non-standardized option numbers (TCP option 33, > riverbed's options no's) for doing auto discovery should not be > allocated for this new TCP option. This is to prevent any confusion. > > - The TCP option needs to be variable length to permit multiple option > formats since the option size may vary depending on the vendor. > > - This TCP option should be advocated for use only by middleboxes. > > --------------- > > The only changes to these requirements I'm aware of were: > > - Make the overhead minimal > > - Allow evolution to vendor-independent formats > > - Allow options to be sent mid-stream > > These requirements were discussed and led to the current > proposal. > > The "NAT reveal" option, while intended for consumption by the > destination server rather than a middlebox, could use the current > proposed format as far as I can tell (adding 1 or 2 bytes). > However we > may want to tighten up the allowed uses a bit, to be more > specific than > "used by middleboxes". Perhaps something regarding communicating the > state of the middlebox, or information which has been hidden by the > middlebox. (This would permit our and the NAT-reveal uses, as > far as I > know). > > Andrew > > > > > On 11/7/2010 10:32 PM, Anantha Ramaiah (ananth) wrote: > > Lars, > > From my side, it has been real crazy at work and I > couldn't devote > > any time for this effort. I did follow the last few email > exchanges on > > this. Few thoughts I had in mind was :- > > > > - to have a generic middle box option, which not only > caters to the > > needs of middle box discovery, but also to stuff like the > following :- > > > > http://tools.ietf.org/html/draft-wing-nat-reveal-option-00 > > > > (When I did an internal review of Dan's draft, I had suggested the > > same.) > > > > - Have a requirements document for the middisc TCP option. > It appears > > to me that, there is a need for a precursor document to > establish some > > common needs and a rationale for a midisc option. This > would great help > > in getting to a faster consensus and would also help some > new vendors > > who may be want to join this effort to come to the same > page as the rest > > of us. > > > > Also, during the initial meeting, I am remembering that you were > > planning to send an email to the various IETF mailing lists > citing this > > effort and asking if there are any other vendors who do > this middisc and > > may be interested in joining this effort.. any progress on > that front? > > > > thoughts? > > > > Thanks, > > -Anantha > > > > > > -----Original Message----- > > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > > Behalf Of Lars Eggert > > Sent: Sunday, November 07, 2010 9:25 PM > > To: middisc@ietf.org > > Subject: [middisc] status? > > > > Hi, folks, > > > > I'm wondering what the status of this effort is - the list has been > > silent in the last months. > > > > Thanks, > > Lars > > _______________________________________________ > > middisc mailing list > > middisc@ietf.org > > https://www.ietf.org/mailman/listinfo/middisc > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc= From ananth@cisco.com Tue May 24 09:03:34 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32352E0775 for ; Tue, 24 May 2011 09:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwf8tV3BkYkx for ; Tue, 24 May 2011 09:03:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D5A13E0671 for ; Tue, 24 May 2011 09:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=8264; q=dns/txt; s=iport; t=1306253012; x=1307462612; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=OnO5DPLq8BMqUQHmEKjXDirRE0Qe+8ShQKR5sNtqGbI=; b=TR7UgY7/WiZX+kPMeoy4FjQAybJXBeqlqAHZYYPRo1fhJjzKkuHm+Mu8 Gd24VtFu/yLKhfzEtHaAkF3gK6yg3F/sx509yH4n54o9WOE6TcRQKfFpW scztuIDwcmVcJOfHXF/tgP5iFoW1h8MH0U80BzIp4PtfcQq6+zJ+uSPbj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0AAOfV202rRDoH/2dsb2JhbACXZAGORHeIcKJJnXyDFhqCawSGVo4GimQ X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="363293265" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 24 May 2011 16:03:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4OG3WRJ012456; Tue, 24 May 2011 16:03:32 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 09:03:32 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 09:03:29 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3QRxSuIYAAA/aP0A== References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> From: "Anantha Ramaiah (ananth)" To: "David Harrington" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "Ron Frederick" , "Mark Day" X-OriginalArrivalTime: 24 May 2011 16:03:32.0089 (UTC) FILETIME=[20F7B690:01CC1A2C] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:03:34 -0000 Hi David, > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements >=20 > Hi, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=3DTBD | 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 >=20 > 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. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >=20 > > -----Original Message----- > > From: middisc-bounces@ietf.org > > [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > > Subject: Re: [middisc] TCP middlebox option requirements > > > > >-----Original Message----- > > >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > > >Behalf Of Ron Frederick > > >Sent: Thursday, May 27, 2010 12:44 PM > > >To: Mark Day > > >Cc: middisc@ietf.org > > >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 > > middisc@ietf.org > > https://www.ietf.org/mailman/listinfo/middisc > > >=20 > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue May 24 13:30:55 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA91E069D for ; Tue, 24 May 2011 13:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qlyKAptOclZ for ; Tue, 24 May 2011 13:30:54 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0BE0670 for ; Tue, 24 May 2011 13:30:53 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4OKUkJq021530; Tue, 24 May 2011 13:30:47 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 May 2011 13:30:41 -0700 Message-ID: <4DDC1571.5040406@bluecoat.com> Date: Tue, 24 May 2011 13:30:41 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , David Harrington References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> , <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2011 20:30:41.0626 (UTC) FILETIME=[7350F3A0:01CC1A51] Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:30:55 -0000 Just out of curiosity, what advantage to the PEN's have over OUI's? Perhaps that they're easier to get? If we do use PEN's, I'd suggest using the same three bytes we're using for the OUI now. Or, we could make a three-byte PEN an alternative to the OUI, using vendor 0xFE for example. In any case, I think the single-byte vendor code alternative is still a necessity given the crowding in SYN packets. I expect most "stakeholders" here plan on using that alternative. I'm hoping the inclusion of either a vendor code or a standard type, combined with minimal requirements on what the option is used for in an RFC, will be sufficient to discourage misuse. Andrew On 5/24/2011 7:22 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Hi David, PENs are a good thought in comparison to OUIs for this purpose. > > I don't speak for the authors, but we have to be a bit sympathetic to the fact that there is only very limited amount of space available for TCP options and burning 32-bits for an enterprise number is going to eat away considerably from the space available to do something useful. > > Personally, I would have no problem seeing a compact mechanism that's just big enough to allow expandability to some double-digit multiple of the number of current vendors, and also support falling back to using either a full Private Enterprise Number or an OUI once the more compacted space is exhausted. > > > ________________________________________ > From: David Harrington [ietfdbh@comcast.net] > Sent: Tuesday, May 24, 2011 9:13 AM > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; 'Ron Frederick'; 'Mark Day' > Cc: middisc@ietf.org; 'David Harrington' > 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). > > 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. > > 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. > > 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. > > 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. > > 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 > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > >> -----Original Message----- >> From: middisc-bounces@ietf.org >> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >> Subject: Re: [middisc] TCP middlebox option requirements >> >>> -----Original Message----- >>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >>> Behalf Of Ron Frederick >>> Sent: Thursday, May 27, 2010 12:44 PM >>> To: Mark Day >>> Cc: middisc@ietf.org >>> 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 >> middisc@ietf.org >> https://www.ietf.org/mailman/listinfo/middisc >> > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue May 24 13:34:04 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C357CE0730 for ; Tue, 24 May 2011 13:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cx+zsM52Ean for ; Tue, 24 May 2011 13:33:59 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id BDCD9E0670 for ; Tue, 24 May 2011 13:33:59 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4OKXu6L022417; Tue, 24 May 2011 13:33:57 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 May 2011 13:33:51 -0700 Message-ID: <4DDC162E.5000005@bluecoat.com> Date: Tue, 24 May 2011 13:33:50 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2011 20:33:51.0328 (UTC) FILETIME=[E4632E00:01CC1A51] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:34:04 -0000 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >> 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 >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >> >> >>> -----Original Message----- >>> From: middisc-bounces@ietf.org >>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >>> Subject: Re: [middisc] TCP middlebox option requirements >>> >>>> -----Original Message----- >>>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >>>> Behalf Of Ron Frederick >>>> Sent: Thursday, May 27, 2010 12:44 PM >>>> To: Mark Day >>>> Cc: middisc@ietf.org >>>> 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 >>> middisc@ietf.org >>> https://www.ietf.org/mailman/listinfo/middisc >>> >> _______________________________________________ >> middisc mailing list >> middisc@ietf.org >> https://www.ietf.org/mailman/listinfo/middisc > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc From ananth@cisco.com Tue May 24 13:46:43 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6CE0784 for ; Tue, 24 May 2011 13:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzRiwqvD3vv4 for ; Tue, 24 May 2011 13:46:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB23E0775 for ; Tue, 24 May 2011 13:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=10182; q=dns/txt; s=iport; t=1306270002; x=1307479602; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d1t+ef5lZh5jckYRX4kj+kikgS+n6SaTf6IJaOWBuvA=; b=cr+E5/c/8UDXPwSfiPO4jNe/4ZWUN0ZRVmZ3TGqdZ4HqGBi2l0PvkQGd gAkyK6l6wlZc4kk58/XWBejsKiWd40n89FQH3ocvslF9D44bQo0W9yLEX 01mtHVy1iN6afNAToFwWnwyz3HSWUliSVG1vks7SaQRoXqeNU400fU0PK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAAAIoY3E2rRDoJ/2dsb2JhbACXZAGORHeqep1vgxYagmsEhlaOBopk X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="322747232" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 20:46:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4OKkfFv025496; Tue, 24 May 2011 20:46:41 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 13:46:41 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 13:46:40 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4DDC162E.5000005@bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: AcwaUfG+MsE06VHYRTuSzrlH9tOjuAAABIxA References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> From: "Anantha Ramaiah (ananth)" To: "Andrew Knutsen" X-OriginalArrivalTime: 24 May 2011 20:46:41.0371 (UTC) FILETIME=[AF5E6AB0:01CC1A53] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:46:43 -0000 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.=20 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:andrew.knutsen@bluecoat.com] > 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; middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements >=20 >=20 > Anantha, what do you see as the advantage of adding a sub-type to > the type code, which follows the vendor ID? >=20 > Andrew >=20 > On 5/24/2011 9:03 AM, Anantha Ramaiah (ananth) wrote: > > Hi David, > > > >> -----Original Message----- > >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > >> 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=3DTBD | 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 > >> ietfdbh@comcast.net (preferred for ietf) > >> dbharrington@huaweisymantec.com > >> +1 603 828 1401 (cell) > >> > >> > >>> -----Original Message----- > >>> From: middisc-bounces@ietf.org > >>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > >>> Subject: Re: [middisc] TCP middlebox option requirements > >>> > >>>> -----Original Message----- > >>>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > On > >>>> Behalf Of Ron Frederick > >>>> Sent: Thursday, May 27, 2010 12:44 PM > >>>> To: Mark Day > >>>> Cc: middisc@ietf.org > >>>> 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 > >>> middisc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/middisc > >>> > >> _______________________________________________ > >> middisc mailing list > >> middisc@ietf.org > >> https://www.ietf.org/mailman/listinfo/middisc > > _______________________________________________ > > middisc mailing list > > middisc@ietf.org > > https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue May 24 13:57:02 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104DE0791 for ; Tue, 24 May 2011 13:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpVm+JgAc8g8 for ; Tue, 24 May 2011 13:57:01 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 551CFE0786 for ; Tue, 24 May 2011 13:57:01 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4OKuuSp001903; Tue, 24 May 2011 13:56:57 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 May 2011 13:56:51 -0700 Message-ID: <4DDC1B93.7010605@bluecoat.com> Date: Tue, 24 May 2011 13:56:51 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2011 20:56:51.0412 (UTC) FILETIME=[1AFB4940:01CC1A55] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:57:02 -0000 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:andrew.knutsen@bluecoat.com] >> 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; middisc@ietf.org >> 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >>>> 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 >>>> ietfdbh@comcast.net (preferred for ietf) >>>> dbharrington@huaweisymantec.com >>>> +1 603 828 1401 (cell) >>>> >>>> >>>>> -----Original Message----- >>>>> From: middisc-bounces@ietf.org >>>>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >>>>> Subject: Re: [middisc] TCP middlebox option requirements >>>>> >>>>>> -----Original Message----- >>>>>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] >> On >>>>>> Behalf Of Ron Frederick >>>>>> Sent: Thursday, May 27, 2010 12:44 PM >>>>>> To: Mark Day >>>>>> Cc: middisc@ietf.org >>>>>> 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 >>>>> middisc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/middisc >>>>> >>>> _______________________________________________ >>>> middisc mailing list >>>> middisc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/middisc >>> _______________________________________________ >>> middisc mailing list >>> middisc@ietf.org >>> https://www.ietf.org/mailman/listinfo/middisc From ananth@cisco.com Tue May 24 14:02:10 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F86E078B for ; Tue, 24 May 2011 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XkMSADJmeZO for ; Tue, 24 May 2011 14:02:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6996BE0786 for ; Tue, 24 May 2011 14:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=11676; q=dns/txt; s=iport; t=1306270929; x=1307480529; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bb6auya9Fh/hR8QSJtrfN4dMdaNlzwhIvUmjwupzvJ8=; b=NL7OcfezsHI9xVwnqQVHeBw9yr1Edy5yyzGQ86iZmfYJR4mLPsKnJjcq PZaDDIsecoJcUnnU0V4Bh31kaBVF4cwg8nQ3Op/SKYIcdzJ5dDhibIVLo lQSA00eUtpGvaMMOO5pY5su6sNSN0TmyAEbQrLJ+LysVSzSZf/qe+X7Me s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAAAPIb3E2rRDoH/2dsb2JhbACXZAGORHeqdp1xgxYagmsEhlaOBopk X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="453609206" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 21:02:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4OL28St012483; Tue, 24 May 2011 21:02:08 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 14:02:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 14:02:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4DDC1B93.7010605@bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: AcwaVS+GW5gRYd2qS3Wz//3trIi6DwAACGlw References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> <4DDC1B93.7010605@bluecoat.com> From: "Anantha Ramaiah (ananth)" To: "Andrew Knutsen" X-OriginalArrivalTime: 24 May 2011 21:02:08.0865 (UTC) FILETIME=[D832C510:01CC1A55] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:02:10 -0000 That may be ok, but the issue is, we are using 1 byte (vendor ID =3D 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:andrew.knutsen@bluecoat.com] > 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; middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements >=20 >=20 > If you don't need a vendor code, that means its a standard type, > which has vendor ID 0 in the current proposal. >=20 > Andrew >=20 > 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:andrew.knutsen@bluecoat.com] > >> 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; middisc@ietf.org > >> 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > 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: middisc@ietf.org > >>>> 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=3DTBD | 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 > >>>> ietfdbh@comcast.net (preferred for ietf) > >>>> dbharrington@huaweisymantec.com > >>>> +1 603 828 1401 (cell) > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: middisc-bounces@ietf.org > >>>>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > >>>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > >> On > >>>>>> Behalf Of Ron Frederick > >>>>>> Sent: Thursday, May 27, 2010 12:44 PM > >>>>>> To: Mark Day > >>>>>> Cc: middisc@ietf.org > >>>>>> 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 > >>>>> middisc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/middisc > >>>>> > >>>> _______________________________________________ > >>>> middisc mailing list > >>>> middisc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/middisc > >>> _______________________________________________ > >>> middisc mailing list > >>> middisc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue May 24 14:45:00 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E71E06C0 for ; Tue, 24 May 2011 14:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BktWufWL97zd for ; Tue, 24 May 2011 14:44:59 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 287F1E0670 for ; Tue, 24 May 2011 14:44:58 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4OLitLx019757; Tue, 24 May 2011 14:44:55 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 May 2011 14:44:49 -0700 Message-ID: <4DDC26D1.6010003@bluecoat.com> Date: Tue, 24 May 2011 14:44:49 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> <4DDC1B93.7010605@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2011 21:44:49.0925 (UTC) FILETIME=[CEB58350:01CC1A5B] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:45:00 -0000 I also think having a full 0 byte for standard types is wasteful. So what you're suggesting is using the vendor byte for three bits of standard type or 5 bits of vendor ID, right? And if there is a 33rd vendor, they have to use the 24-bit ID? Two alternatives have occurred to me: - A bit in the vendor byte, indicating whether the byte is a vendor or a standard type. Both get 7 bits. The objection to this was it might be hard to parse in hardware. - Allocating standard types out of the same 8-bit space as the vendor IDs. Andrew On 5/24/2011 2:02 PM, Anantha Ramaiah (ananth) wrote: > 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:andrew.knutsen@bluecoat.com] >> 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; middisc@ietf.org >> 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:andrew.knutsen@bluecoat.com] >>>> 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; middisc@ietf.org >>>> 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] >> 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: middisc@ietf.org >>>>>> 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 >>>>>> ietfdbh@comcast.net (preferred for ietf) >>>>>> dbharrington@huaweisymantec.com >>>>>> +1 603 828 1401 (cell) >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: middisc-bounces@ietf.org >>>>>>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org >>>>>>> Subject: Re: [middisc] TCP middlebox option requirements >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: middisc-bounces@ietf.org > [mailto:middisc-bounces@ietf.org] >>>> On >>>>>>>> Behalf Of Ron Frederick >>>>>>>> Sent: Thursday, May 27, 2010 12:44 PM >>>>>>>> To: Mark Day >>>>>>>> Cc: middisc@ietf.org >>>>>>>> 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 >>>>>>> middisc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/middisc >>>>>>> >>>>>> _______________________________________________ >>>>>> middisc mailing list >>>>>> middisc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/middisc >>>>> _______________________________________________ >>>>> middisc mailing list >>>>> middisc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/middisc From ananth@cisco.com Tue May 24 15:10:17 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3BE07DE for ; Tue, 24 May 2011 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2ayHN5teaH for ; Tue, 24 May 2011 15:09:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4DE07A7 for ; Tue, 24 May 2011 15:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=13689; q=dns/txt; s=iport; t=1306274997; x=1307484597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VzmHc+0onHM9yDbW5whGYJ9js6RdwmZuTg3+ueaU4sw=; b=T0fsPPeIprHrB7+d1+vP6Tttalo5HDTv1eS1DiaaM57PriE2Rj2M0tJr iKB7FL9B//irYueBuWOUCh1qxGty8WcAHo6ecmSsVyLxN9nUAxP2JZAWq ssPVZXbFareG1bHSh6UGE6D/USt0L2w/HnQYJqhCpIVlUF/h84DNyrIxh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAAAGos3E2rRDoI/2dsb2JhbACXZAGORHeIcKFgnXeDFhqCawSGVo4GimQ X-IronPort-AV: E=Sophos;i="4.65,263,1304294400"; d="scan'208";a="322795655" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 24 May 2011 22:09:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4OM9ujn016415; Tue, 24 May 2011 22:09:56 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 15:09:56 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 15:09:55 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580CCD61AE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4DDC26D1.6010003@bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: AcwaW9dvfWcBOOfbTxCIMPJPsmIpvgAAzhew References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> <4DDC1B93.7010605@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> <4DDC26D1.6010003@bluecoat.com> From: "Anantha Ramaiah (ananth)" To: "Andrew Knutsen" X-OriginalArrivalTime: 24 May 2011 22:09:56.0845 (UTC) FILETIME=[50E741D0:01CC1A5F] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:10:17 -0000 > -----Original Message----- > From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > Sent: Tuesday, May 24, 2011 2:45 PM > To: Anantha Ramaiah (ananth) > Cc: David Harrington; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; > Ron Frederick; Mark Day; middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements >=20 >=20 > I also think having a full 0 byte for standard types is wasteful. > So what you're suggesting is using the vendor byte for three bits of > standard type or 5 bits of vendor ID, right? =20 Yes. > And if there is a 33rd vendor, they have to use the 24-bit ID? My feeling is that there won't be 33 vendors doing WAN opt solutions and the need to do option insertion for the same purpose. >=20 > Two alternatives have occurred to me: >=20 > - A bit in the vendor byte, indicating whether the byte is a > vendor > or a standard type. Both get 7 bits. =20 This is what I meant below when I mentioned MSB for demux. > The objection to this was it might be hard to parse in hardware. Agreed, I thought about that as well. >=20 > - Allocating standard types out of the same 8-bit space as the > vendor IDs. Well even then you need to sub-divide the space otherwise how else you would distinguish between them.=20 -Anantha >=20 > On 5/24/2011 2:02 PM, Anantha Ramaiah (ananth) wrote: > > That may be ok, but the issue is, we are using 1 byte (vendor ID =3D 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:andrew.knutsen@bluecoat.com] > >> 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; middisc@ietf.org > >> 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:andrew.knutsen@bluecoat.com] > >>>> 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; middisc@ietf.org > >>>> 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: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > >> 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: middisc@ietf.org > >>>>>> 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=3DTBD | 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 > >>>>>> ietfdbh@comcast.net (preferred for ietf) > >>>>>> dbharrington@huaweisymantec.com > >>>>>> +1 603 828 1401 (cell) > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: middisc-bounces@ietf.org > >>>>>>> [mailto:middisc-bounces@ietf.org] 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: middisc@ietf.org > >>>>>>> Subject: Re: [middisc] TCP middlebox option requirements > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: middisc-bounces@ietf.org > > [mailto:middisc-bounces@ietf.org] > >>>> On > >>>>>>>> Behalf Of Ron Frederick > >>>>>>>> Sent: Thursday, May 27, 2010 12:44 PM > >>>>>>>> To: Mark Day > >>>>>>>> Cc: middisc@ietf.org > >>>>>>>> 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 > >>>>>>> middisc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/middisc > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> middisc mailing list > >>>>>> middisc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/middisc > >>>>> _______________________________________________ > >>>>> middisc mailing list > >>>>> middisc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue May 24 15:37:54 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163BEE07A5 for ; Tue, 24 May 2011 15:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knbAXshUui1S for ; Tue, 24 May 2011 15:37:53 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF49E06AC for ; Tue, 24 May 2011 15:37:53 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4OMbo7u007567; Tue, 24 May 2011 15:37:50 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 May 2011 15:37:45 -0700 Message-ID: <4DDC3338.4070309@bluecoat.com> Date: Tue, 24 May 2011 15:37:44 -0700 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> <0C53DCFB700D144284A584F54711EC580CCD5F61@xmb-sjc-21c.amer.cisco.com> <4DDC162E.5000005@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD6121@xmb-sjc-21c.amer.cisco.com> <4DDC1B93.7010605@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD613F@xmb-sjc-21c.amer.cisco.com> <4DDC26D1.6010003@bluecoat.com> <0C53DCFB700D144284A584F54711EC580CCD61AE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580CCD61AE@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2011 22:37:45.0296 (UTC) FILETIME=[3360AD00:01CC1A63] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:37:54 -0000 On 5/24/2011 3:09 PM, Anantha Ramaiah (ananth) wrote: >> > >> > - Allocating standard types out of the same 8-bit space as the >> > vendor IDs. > Well even then you need to sub-divide the space otherwise how else you > would distinguish between them. > No need to; interpretation of the rest of the option depends on that code, whichever sort it is. Andrew From ron.frederick@bluecoat.com Sat May 28 13:35:39 2011 Return-Path: X-Original-To: middisc@ietfa.amsl.com Delivered-To: middisc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64819E0752 for ; Sat, 28 May 2011 13:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbVZxjA-Xk6A for ; Sat, 28 May 2011 13:35:38 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id D6802E06FD for ; Sat, 28 May 2011 13:35:38 -0700 (PDT) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p4SKZbLK004612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 May 2011 13:35:37 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0255.000; Sat, 28 May 2011 13:35:31 -0700 From: "Frederick, Ron" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3QRxSuIYAAA1T3LQDlQ7EA Date: Sat, 28 May 2011 20:35:31 +0000 Message-ID: <0D3673BF-621F-48B0-AADA-E877A0FD103A@bluecoat.com> References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com><2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com><93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> , <3A2E247DEDD847669D302BFF7ED0E69B@davidPC> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A4BFF406643674FA512A962CE4BC998@bluecoat.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 29 May 2011 19:04:53 -0700 Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussions on TCP option for middlebox discovery." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 20:35:39 -0000 On May 24, 2011, at 7:22 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP= ] wrote: >=20 > Hi David, PENs are a good thought in comparison to OUIs for this purpose. >=20 > I don't speak for the authors, but we have to be a bit sympathetic to the= fact that there is only very limited amount of space available for TCP opt= ions and burning 32-bits for an enterprise number is going to eat away cons= iderably from the space available to do something useful. >=20 > Personally, I would have no problem seeing a compact mechanism that's jus= t big enough to allow expandability to some double-digit multiple of the nu= mber of current vendors, and also support falling back to using either a fu= ll Private Enterprise Number or an OUI once the more compacted space is exh= austed. Choosing to go with the OUI instead of a PEN here was mainly because OUIs o= nly took 24 bits of space rather than 32 bits. which is the my understandin= g of the intended size of a PEN. However, even 24 bits was more than we wan= ted to pay in most cases, and that's what led to the different variants of = the option, where the OUI was only used as a fallback. If there are still objections to using a full byte for vendor code (due to = this "wasting" a byte for standard options), I would propose one of the fol= lowing: - Allow standard type codes to be allocated starting with 0x00, in an incre= asing 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 remainde= r of the space for standard type codes. or - Allow both standard type codes and vendor codes to just be allocated in a= n increasing fashion from 0x00. As Andrew noted, the code determines everyt= hing about how to interpret the rest of the payload, so there's really no d= ifference between the two from a decoding perspective. Either way, I would want to see a rule that IANA would only ever allocate o= ne single-byte vendor code to any vendor and it would be up to that vendor = to allocate any necessary additional bits or bytes in the payload as needed= to support multiple option types. If a vendor failed to plan ahead in this= regard, they would need to either rework their options later to adjust for= this or to allocate additional options using the 0xFF variant with their O= UI. --=20 Ron Frederick ronf@bluecoat.com