From ananth@cisco.com Fri May 21 02:06:52 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F03A3A7AF5 for ; Fri, 21 May 2010 02:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.766 X-Spam-Level: X-Spam-Status: No, score=-8.766 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYcJFGgdmKp6 for ; Fri, 21 May 2010 02:06:51 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 914CD3A7D28 for ; Thu, 20 May 2010 23:32:17 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAPzF9UurR7Hu/2dsb2JhbACSBowacaNNmUWCWYI5BINA X-IronPort-AV: E=Sophos;i="4.53,276,1272844800"; d="scan'208";a="132817398" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 May 2010 06:32:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4L6WBCD013099 for ; Fri, 21 May 2010 06:32:11 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.3959); Thu, 20 May 2010 23:32:11 -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: Thu, 20 May 2010 23:32:10 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP middlebox option requirements Thread-Index: Acr4r1dR7jCphXynRIuv4YZC49ei3g== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 21 May 2010 06:32:11.0198 (UTC) FILETIME=[57F2DDE0:01CAF8AF] Subject: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 21 May 2010 09:06:52 -0000 Hi, I am just taking the liberty to post the first email on this mailing list. During our last call there was talk about the requirements of this TCP option. From our pov, the following would be the general requirements of the TCP option. Reason for TCP option : - A standard TCP option is needed because every vendor cannot have one option for the same purpose of auto-discovery and capability exchange. By standardizing the TCP option, firewalls etc., are aware of this option and problems can be avoided. 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=20 different. - 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. My guess is that these requirements may be common for all the vendors or there may be some additional requirements not covered by this post. In either case we can continue the discussion and come to some conclusions. -Anantha From andrew.knutsen@bluecoat.com Fri May 21 13:43:23 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CE43A691A for ; Fri, 21 May 2010 13:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC0dEuffu-AN for ; Fri, 21 May 2010 13:43:22 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 5BB6B3A6CF5 for ; Fri, 21 May 2010 13:11:34 -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 o4LINBBd020577; Fri, 21 May 2010 11:23:11 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 11:23:06 -0700 Message-ID: <4BF6CF8A.5030707@bluecoat.com> Date: Fri, 21 May 2010 11:23:06 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: middisc@ietf.org References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2010 18:23:06.0118 (UTC) FILETIME=[A8432260:01CAF912] Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 21 May 2010 20:43:23 -0000 Thanks Ananth. One possibility that Jamshid and I talked about addresses concerns about using 3 bytes for the OUI. We could skip it (and the P bit), and break up the 15 bits or so of "device capability" into an IANA-assigned vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific type. There could be one or more "standard" vendor codes for multi-vendor interoperability (ie, IANA-assigned types), and an extension code if we run out of room. Perhaps we also need to define the requirements for getting a vendor code or a standard type -- for instance, we might not want any individual to be able to get a vendor code, since they are limited; and the standard types would need some documentation, but perhaps not as widely reviewed as for a top-level option kind. Andrew Anantha Ramaiah (ananth) wrote: > Hi, > I am just taking the liberty to post the first email on this mailing > list. During our last call there was talk about the requirements of this > TCP option. From our pov, the following would be the general > requirements of the TCP option. > > > Reason for TCP option : > > - A standard TCP option is needed because every vendor cannot have one > option for the same purpose of auto-discovery and capability exchange. > By standardizing the TCP option, firewalls etc., are aware of this > option and problems can be avoided. > > 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. > > - 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. > > > My guess is that these requirements may be common for all the vendors or > there may be some additional requirements not covered by this post. In > either case we can continue the discussion and come to some conclusions. > > -Anantha > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > From Mark.Day@riverbed.com Mon May 24 06:26:24 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069263A6BE1 for ; Mon, 24 May 2010 06:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFgKLK8ASb1a for ; Mon, 24 May 2010 06:26:23 -0700 (PDT) Received: from smtp2.riverbed.com (smtp.riverbed.com [208.70.196.44]) by core3.amsl.com (Postfix) with ESMTP id 1657F3A6BD1 for ; Mon, 24 May 2010 06:26:20 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 24 May 2010 06:26:12 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.0.165]) with mapi; Mon, 24 May 2010 06:26:12 -0700 From: Mark Day To: Andrew Knutsen , "middisc@ietf.org" Date: Mon, 24 May 2010 06:26:09 -0700 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr5Jj8pYyUARQUxRdKUNqMbiZ2WpwCGZdjg Message-ID: References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> In-Reply-To: <4BF6CF8A.5030707@bluecoat.com> 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 Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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, 24 May 2010 13:26:24 -0000 The size of any option is very limited. Only 40 bytes of the TCP header are= available for options. It is not difficult to be in a situation where othe= r options consume 20 bytes of the available space in the header, so I'd lik= e to suggest that a realistic design goal for practical deployment is 20 by= tes or less. =20 The longest current Riverbed option usage does consume 20 bytes. The bulk = of that is 3 IPv4 addresses (12 bytes total), a port number (2 bytes), the = option number (1 byte) and option length (1 byte). We also use a byte for a= loop-detection mechanism. That leaves us only 3 bytes total for figuring o= ut which vendor/version/message this is, as well as any other flags or data= . That's likely to be feasible (barely), but not at all straightforward. If we don't focus ruthlessly on making the vendor-id piece as small as poss= ible, there will be an increase of two kinds of avoidable inefficiency: 1. Situations where a single round-trip has to become two or more round tri= ps. Rather than integrating the necessary coordination into the 3-way hands= hake, more messages have to be exchanged. In strict autodiscovery terms thi= s doesn't much matter, but the most economically-significant current usage = of autodiscovery is in WAN optimization, where there's a good likelihood th= at the network has high latency and an extra round trip is a concern. 2. Situations where the standardized autodiscovery mechanism fails entirely= because there's no room left in the header for an option of that size. Esp= ecially on enterprise networks, this would probably prompt a fallback to sm= aller vendor-proprietary schemes rather than allowing autodiscovery to simp= ly break.=20 --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen Sent: Friday, May 21, 2010 2:23 PM To: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements Thanks Ananth. One possibility that Jamshid and I talked about addresses concerns=20 about using 3 bytes for the OUI. We could skip it (and the P bit), and=20 break up the 15 bits or so of "device capability" into an IANA-assigned=20 vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific=20 type. There could be one or more "standard" vendor codes for=20 multi-vendor interoperability (ie, IANA-assigned types), and an=20 extension code if we run out of room. Perhaps we also need to define the requirements for getting a vendor=20 code or a standard type -- for instance, we might not want any=20 individual to be able to get a vendor code, since they are limited; and=20 the standard types would need some documentation, but perhaps not as=20 widely reviewed as for a top-level option kind. Andrew Anantha Ramaiah (ananth) wrote: > Hi, > I am just taking the liberty to post the first email on this mailing > list. During our last call there was talk about the requirements of this > TCP option. From our pov, the following would be the general > requirements of the TCP option. > > > Reason for TCP option : > > - A standard TCP option is needed because every vendor cannot have one > option for the same purpose of auto-discovery and capability exchange. > By standardizing the TCP option, firewalls etc., are aware of this > option and problems can be avoided. > > 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=20 > different. > > - 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. > > > My guess is that these requirements may be common for all the vendors or > there may be some additional requirements not covered by this post. In > either case we can continue the discussion and come to some conclusions. > > -Anantha > _______________________________________________ > 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 Mark.Day@riverbed.com Mon May 24 06:41:01 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FEC3A6BEC for ; Mon, 24 May 2010 06:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jQ43+589zbm for ; Mon, 24 May 2010 06:41:00 -0700 (PDT) Received: from smtp2.riverbed.com (eng.riverbed.com [208.70.196.44]) by core3.amsl.com (Postfix) with ESMTP id 370C63A6BA2 for ; Mon, 24 May 2010 06:41:00 -0700 (PDT) Received: from unknown (HELO exhub1.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 24 May 2010 06:40:52 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub1.nbttech.com ([10.16.0.163]) with mapi; Mon, 24 May 2010 06:40:52 -0700 From: Mark Day To: Andrew Knutsen , "middisc@ietf.org" Date: Mon, 24 May 2010 06:40:50 -0700 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr5Jj8pYyUARQUxRdKUNqMbiZ2WpwCHnlYw Message-ID: References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> In-Reply-To: <4BF6CF8A.5030707@bluecoat.com> 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 Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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, 24 May 2010 13:41:01 -0000 Two additional issues seem worth clarifying since I'm not sure how others w= ould view them. 1. Are we concerned strictly with autodiscovery options, or are we attempti= ng to understand the requirements for options usage generally among current= symmetric middleboxes? For example, Riverbed uses a different option for = some forms of addressing information in situations after the two communicat= ing peers have been established by autodiscovery. It wouldn't surprise me = to learn that other vendors have other similar schemes. 2. Don't we also need to consider requirements for autodiscovery options in= IPv6 environments? =20 In both cases, I can see a pragmatic argument for focusing narrowly vs. an = architectural argument for considering broader issues. IPv4 autodiscovery i= s the clear existing interoperability/coexistence problem and may be solvab= le by simply agreeing on an option number and vendor id scheme, while the o= ther areas might not yet have enough experience and implementations to just= ify a standard. And yet it feels to me like we might solve one option-rela= ted problem just to trip across another similar one soon afterward. --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen Sent: Friday, May 21, 2010 2:23 PM To: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements Thanks Ananth. One possibility that Jamshid and I talked about addresses concerns=20 about using 3 bytes for the OUI. We could skip it (and the P bit), and=20 break up the 15 bits or so of "device capability" into an IANA-assigned=20 vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific=20 type. There could be one or more "standard" vendor codes for=20 multi-vendor interoperability (ie, IANA-assigned types), and an=20 extension code if we run out of room. Perhaps we also need to define the requirements for getting a vendor=20 code or a standard type -- for instance, we might not want any=20 individual to be able to get a vendor code, since they are limited; and=20 the standard types would need some documentation, but perhaps not as=20 widely reviewed as for a top-level option kind. Andrew Anantha Ramaiah (ananth) wrote: > Hi, > I am just taking the liberty to post the first email on this mailing > list. During our last call there was talk about the requirements of this > TCP option. From our pov, the following would be the general > requirements of the TCP option. > > > Reason for TCP option : > > - A standard TCP option is needed because every vendor cannot have one > option for the same purpose of auto-discovery and capability exchange. > By standardizing the TCP option, firewalls etc., are aware of this > option and problems can be avoided. > > 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=20 > different. > > - 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. > > > My guess is that these requirements may be common for all the vendors or > there may be some additional requirements not covered by this post. In > either case we can continue the discussion and come to some conclusions. > > -Anantha > _______________________________________________ > 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 lars.eggert@nokia.com Mon May 24 07:04:28 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FEB3A6C0E for ; Mon, 24 May 2010 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.481 X-Spam-Level: X-Spam-Status: No, score=-5.481 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VekJw6C6LTJ for ; Mon, 24 May 2010 07:04:26 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 74D6E3A6C0A for ; Mon, 24 May 2010 07:04:26 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4OE3vOA015789 for ; Mon, 24 May 2010 17:04:13 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 17:03:45 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 17:03:45 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4OE3irJ023415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 May 2010 17:03:44 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-23-49872195; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 24 May 2010 10:03:35 -0400 Message-Id: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> To: middisc@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Mon, 24 May 2010 17:03:38 +0300 (EEST) X-OriginalArrivalTime: 24 May 2010 14:03:45.0743 (UTC) FILETIME=[ECCB95F0:01CAFB49] X-Nokia-AV: Clean Subject: [middisc] currently used TCP option numbers X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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, 24 May 2010 14:04:28 -0000 --Apple-Mail-23-49872195 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, in order to avoid clashes between options that the IETF assigns in the = near future and ones that are currently being used without proper = registration, would you let me know which option numbers your products = use and - if you are aware of it - which numbers may be used by other = vendors? I will then instruct IANA to mark them as "user without proper = registration" (or something like this) in the IANA table at = http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml=20 My main motivation is that we've just assigned option #29, and I have = heard that some vendors are using numbers in the low 30s. Because IANA = typically assigns numbers incrementally, there may be a clash in the not = too far future. I'd really like to avoid those clashes from happening. = IANA can skip those numbers that are used without proper registration, = if they know about them. Thanks, Lars= --Apple-Mail-23-49872195 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDUyNDE0MDMzNVowIwYJKoZIhvcNAQkEMRYEFA3gPeIn6+qUAI0fLOctkVle3J5iMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAOMN+u8AY3SFN6INj2ZPG9/PWhOLE7BUkqf10KEa2apEXNSo0KaSYTqxfvChH2WzQa1v9H JFMvMpqjJrw/vWA3bIQ+4jon2LLAFGhMiS0mz1rIzo1nHUiIaCj+FIrUb2gP9IYU35sz9JZoaEeh 7ZwNcWny/Mtpz/Ip5H+EKbmkGfcSjflgYzC2XpSatA9/GPW2VkxwdvSlwPSGIfpHkq2v4YkUFnwl VqH9Hf2ww5nlpiiT0z+FLxqVVAqrHjW5Teeqt22Xkr8IhuWitTk3gWW1Uh6lNdSfXGHuilJpRdZu HWmnTLUa9gpUMRDlcMMihF0MBcYgoiD3imYuGoNfJwFJAAAAAAAA --Apple-Mail-23-49872195-- From andrew.knutsen@bluecoat.com Tue May 25 17:47:54 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BB93A6829 for ; Tue, 25 May 2010 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bF2+bsPY991 for ; Tue, 25 May 2010 17:47:52 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 651473A6B95 for ; Tue, 25 May 2010 17:28:39 -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 o4Q0SV2a008319; Tue, 25 May 2010 17:28:31 -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, 25 May 2010 17:28:26 -0700 Message-ID: <4BFC6B29.1080706@bluecoat.com> Date: Tue, 25 May 2010 17:28:25 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Day References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030903040803040504010306" X-OriginalArrivalTime: 26 May 2010 00:28:26.0359 (UTC) FILETIME=[5B657870:01CAFC6A] Cc: Ron Frederick , "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 May 2010 00:47:54 -0000 This is a multi-part message in MIME format. --------------030903040803040504010306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way. Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards. Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism. I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work. I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including: 1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific. 2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format. 3) Removing the requirement that the option only be present with the SYN bit set. 4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors. This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option. Opinions? Andrew Mark Day wrote: > Two additional issues seem worth clarifying since I'm not sure how others would view them. > > 1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes? For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery. It wouldn't surprise me to learn that other vendors have other similar schemes. > > 2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments? > > In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard. And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward. > > --Mark > > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen > Sent: Friday, May 21, 2010 2:23 PM > To: middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements > > > Thanks Ananth. > > One possibility that Jamshid and I talked about addresses concerns > about using 3 bytes for the OUI. We could skip it (and the P bit), and > break up the 15 bits or so of "device capability" into an IANA-assigned > vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific > type. There could be one or more "standard" vendor codes for > multi-vendor interoperability (ie, IANA-assigned types), and an > extension code if we run out of room. > > Perhaps we also need to define the requirements for getting a vendor > code or a standard type -- for instance, we might not want any > individual to be able to get a vendor code, since they are limited; and > the standard types would need some documentation, but perhaps not as > widely reviewed as for a top-level option kind. > > Andrew > > Anantha Ramaiah (ananth) wrote: > >> Hi, >> I am just taking the liberty to post the first email on this mailing >> list. During our last call there was talk about the requirements of this >> TCP option. From our pov, the following would be the general >> requirements of the TCP option. >> >> >> Reason for TCP option : >> >> - A standard TCP option is needed because every vendor cannot have one >> option for the same purpose of auto-discovery and capability exchange. >> By standardizing the TCP option, firewalls etc., are aware of this >> option and problems can be avoided. >> >> 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. >> >> - 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. >> >> >> My guess is that these requirements may be common for all the vendors or >> there may be some additional requirements not covered by this post. In >> either case we can continue the discussion and come to some conclusions. >> >> -Anantha >> _______________________________________________ >> 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 > --------------030903040803040504010306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way.

   Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards.  Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work.

   I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be present with the SYN bit set.
    4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors.

    This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option.

    Opinions?

Andrew

Mark Day wrote: 
Two additional issues seem worth clarifying since I'm not sure how others would view them.

1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes?  For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery.  It wouldn't surprise me to learn that other vendors have other similar schemes.

2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments?  

In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard.  And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward.

--Mark

-----Original Message-----
From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements


    Thanks Ananth.

    One possibility that Jamshid and I talked about addresses concerns 
about using 3 bytes for the OUI. We could skip it (and the P bit), and 
break up the 15 bits or so of "device capability" into an IANA-assigned 
vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific 
type. There could be one or more "standard" vendor codes for 
multi-vendor interoperability (ie, IANA-assigned types), and an 
extension code if we run out of room.

    Perhaps we also need to define the requirements for getting a vendor 
code or a standard type -- for instance, we might not want any 
individual to be able to get a vendor code, since they are limited; and 
the standard types would need some documentation, but perhaps not as 
widely reviewed as for a top-level option kind.

Andrew

Anantha Ramaiah (ananth) wrote:
  
Hi,
   I am just taking the liberty to post the first email on this mailing
list. During our last call there was talk about the requirements of this
TCP option. From our pov, the following would be the general
requirements of the TCP option.


Reason for TCP option :

- A standard TCP option is needed because every vendor cannot have one
option for the same purpose of auto-discovery and capability exchange.
By standardizing the TCP option, firewalls etc., are aware of this
option and problems can be avoided.

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.

- 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.


My guess is that these requirements may be common for all the vendors or
there may be some additional requirements not covered by this post. In
either case we can continue the discussion and come to some conclusions.

-Anantha
_______________________________________________
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

--------------030903040803040504010306-- From Mark.Day@riverbed.com Tue May 25 17:53:00 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB283A67B2 for ; Tue, 25 May 2010 17:53:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUnvit8OhH-k for ; Tue, 25 May 2010 17:52:50 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by core3.amsl.com (Postfix) with ESMTP id 4FAB33A635F for ; Tue, 25 May 2010 17:52:49 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 25 May 2010 17:52:40 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.0.165]) with mapi; Tue, 25 May 2010 17:52:40 -0700 From: Mark Day To: Andrew Knutsen Date: Tue, 25 May 2010 17:52:38 -0700 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr8amEoRBrSL0vfSJmthLLjZuRoLQAAYbSA Message-ID: References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> In-Reply-To: <4BFC6B29.1080706@bluecoat.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_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D125MAILBOXES2nbtte_" MIME-Version: 1.0 Cc: Ron Frederick , "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 May 2010 00:53:00 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D125MAILBOXES2nbtte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Specifying a single-byte vendor code, with some reserved "standard" value(s= ) of that byte, sounds good. I also agree that we need to define what this= is intended for so it doesn't become the all-purpose option. As a practical matter the "t-word" (tunnel) may be problematic. Any of you = who are not exposed to the competitive side of this market may find it mind= -boggling, but there has been a lot of thrashing around on the topic of whe= ther tunnels are evil and whether a given product does or doesn't use tunne= ls. (Some of this has involved misunderstanding or mischaracterizing other= vendors' products). Accordingly it seems unwise to write a high-level gen= eric statement of purpose in terms of establishing or maintaining "tunnels"= . Can we say instead that this option is about discovering some other middleb= ox and maintaining communication with that discovered middlebox? --Mark From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] Sent: Tuesday, May 25, 2010 8:28 PM To: Mark Day Cc: middisc@ietf.org; Ron Frederick; Qing Li Subject: Re: [middisc] TCP middlebox option requirements It seems to me that if we do limit our goal here to agreeing on an opti= on number and vendor ID scheme, we haven't really limited ourselves to auto= discovery except in the requirements we state for getting a vendor ID (ie, = agreements on use). Mostly this would involve removing the requirement that= the option only be present with the SYN bit. We added this requirement pri= marily due to concerns about reliable transmission, but in later discussion= s we came up with a midstream discovery requirement and mechanism where tha= t isn't an issue, so I don't think we're particularly attached to it. Also,= we probably don't have to require everyone to encode the vendor-specific t= ype information in the same way. Another implication of that goal is that we wouldn't be making a standar= d per se; rather we'd be making a first step towards a set of standards. T= hats the purpose of the "P" bit in the current proposal, and the "standard = vendor" codes in the proposal for removing the OUI in my message below. The= idea is that as the technology matures, we can move towards a standard mec= hanism. I'm not familiar with IPv6 options, but at this point what we're doing s= ounds so simple it should work. I'm getting the impression that to make this alternate option useful to = everyone here, we have to change the proposal in a few ways, including: 1) Removing the OUI, and having a single byte of vendor code. The optio= n format would be vendor-specific. 2) Replacing the P bit with a "standard" vendor code or codes -- perhap= s one code per interoperable option format. 3) Removing the requirement that the option only be present with the SY= N bit set. 4) It sounds like the R bit may be redundant with other, more complex s= chemes already implemented by some vendors. This would mean the option format would only specify a single byte of v= endor ID after the option length. We would need some stipulations on the op= tion's use (making and maintaining tunnels, perhaps). Vendors would have to= agree to these stipulations to get a code, so we aren't making a "catch-al= l" option. Opinions? Andrew Mark Day wrote: Two additional issues seem worth clarifying since I'm not sure how others w= ould view them. 1. Are we concerned strictly with autodiscovery options, or are we attempti= ng to understand the requirements for options usage generally among current= symmetric middleboxes? For example, Riverbed uses a different option for = some forms of addressing information in situations after the two communicat= ing peers have been established by autodiscovery. It wouldn't surprise me = to learn that other vendors have other similar schemes. 2. Don't we also need to consider requirements for autodiscovery options in= IPv6 environments? In both cases, I can see a pragmatic argument for focusing narrowly vs. an = architectural argument for considering broader issues. IPv4 autodiscovery i= s the clear existing interoperability/coexistence problem and may be solvab= le by simply agreeing on an option number and vendor id scheme, while the o= ther areas might not yet have enough experience and implementations to just= ify a standard. And yet it feels to me like we might solve one option-rela= ted problem just to trip across another similar one soon afterward. --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:mid= disc-bounces@ietf.org] On Behalf Of Andrew Knutsen Sent: Friday, May 21, 2010 2:23 PM To: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements Thanks Ananth. One possibility that Jamshid and I talked about addresses concerns about using 3 bytes for the OUI. We could skip it (and the P bit), and break up the 15 bits or so of "device capability" into an IANA-assigned vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific type. There could be one or more "standard" vendor codes for multi-vendor interoperability (ie, IANA-assigned types), and an extension code if we run out of room. Perhaps we also need to define the requirements for getting a vendor code or a standard type -- for instance, we might not want any individual to be able to get a vendor code, since they are limited; and the standard types would need some documentation, but perhaps not as widely reviewed as for a top-level option kind. Andrew Anantha Ramaiah (ananth) wrote: Hi, I am just taking the liberty to post the first email on this mailing list. During our last call there was talk about the requirements of this TCP option. From our pov, the following would be the general requirements of the TCP option. Reason for TCP option : - A standard TCP option is needed because every vendor cannot have one option for the same purpose of auto-discovery and capability exchange. By standardizing the TCP option, firewalls etc., are aware of this option and problems can be avoided. 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. - 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. My guess is that these requirements may be common for all the vendors or there may be some additional requirements not covered by this post. In either case we can continue the discussion and come to some conclusions. -Anantha _______________________________________________ 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 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D125MAILBOXES2nbtte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Specifying a single-byte vendor code, with some reserved = 220;standard” value(s) of that byte, sounds good.  I also agree that we need to defi= ne what this is intended for so it doesn’t become the all-purpose option= .

 

As a practical matter the “t-word” (tunnel) may = be problematic. Any of you who are not exposed to the competitive side of this market may find it mind-boggling, but there has been a lot of thrashing aro= und on the topic of whether tunnels are evil and whether a given product does or d= oesn’t use tunnels.  (Some of this has involved misunderstanding or mischaracterizing other vendors’ products).  Accordingly it seem= s unwise to write a high-level generic statement of purpose in terms of establishing or maintaining “tunnels”.

 

Can we say instead that this option is about discovering som= e other middlebox and maintaining communication with that discovered middlebox?

 

--Mark

 

 

From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
Sent: Tuesday, May 25, 2010 8:28 PM
To: Mark Day
Cc: middisc@ietf.org; Ron Frederick; Qing Li
Subject: Re: [middisc] TCP middlebox option requirements<= /span>

 


    It seems to me that if we do limit our goal here to agre= eing on an option number and vendor ID scheme, we haven't really limited ourselv= es to autodiscovery except in the requirements we state for getting a vendor I= D (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discuss= ions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, w= e probably don't have to require everyone to encode the vendor-specific type information in the same way.

   Another implication of that goal is that we wouldn't be making= a standard per se; rather we'd be making a first step towards a set of standards.  Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what we'= re doing sounds so simple it should work.

   I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendo= r code or codes -- perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be pres= ent with the SYN bit set.
    4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors.

    This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren= 't making a "catch-all" option.

    Opinions?

Andrew

Mark Day wrote: 

Two additional issues seem worth clarifying since I'm not sure how oth=
ers would view them.
 
1. Ar=
e we concerned strictly with autodiscovery options, or are we attempting to=
 understand the requirements for options usage generally among current symm=
etric middleboxes?  For example, Riverbed uses a different option for =
some forms of addressing information in situations after the two communicat=
ing peers have been established by autodiscovery.  It wouldn't surpris=
e me to learn that other vendors have other similar schemes.
 
2. Don't we also need to consider requir=
ements for autodiscovery options in IPv6 environments?  
 
In both cases, I can see a pragmatic ar=
gument for focusing narrowly vs. an architectural argument for considering =
broader issues. IPv4 autodiscovery is the clear existing interoperability/c=
oexistence problem and may be solvable by simply agreeing on an option numb=
er and vendor id scheme, while the other areas might not yet have enough ex=
perience and implementations to justify a standard.  And yet it feels =
to me like we might solve one option-related problem just to trip across an=
other similar one soon afterward.
 
--Mark
 
-----Origin=
al Message-----
From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2=
010 2:23 PM
To: middisc@ietf.org
=
Subject: Re: [middisc] TCP middlebox option requirements
 
 
  &nbs=
p; Thanks Ananth.
 
 &n=
bsp;  One possibility that Jamshid and I talked about addresses concer=
ns 
about using 3 bytes for the OUI. We could skip it =
(and the P bit), and 
break up the 15 bits or so of &q=
uot;device capability" into an IANA-assigned 
ven=
dor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific <=
/o:p>
type. There could be one or more "standard" vendo=
r codes for 
multi-vendor interoperability (ie, IANA-a=
ssigned types), and an 
extension code if we run out o=
f room.
 
   =
 Perhaps we also need to define the requirements for getting a vendor =

code or a standard type -- for instance, we might not want=
 any 
individual to be able to get a vendor code, sinc=
e they are limited; and 
the standard types would need=
 some documentation, but perhaps not as 
widely review=
ed as for a top-level option kind.
 
Andrew
 
Anantha Ra=
maiah (ananth) wrote:
  



Hi,
   I am just taking the liberty to post the first e=
mail on this mailing
list. During our last call there =
was talk about the requirements of this
TCP option. Fr=
om our pov, the following would be the general
require=
ments of the TCP option.
 
<=
o:p> 
Reason for TCP option :
 
- A standard TCP option is needed because every ve=
ndor cannot have one
option for the same purpose of au=
to-discovery and capability exchange.
By standardizing=
 the TCP option, firewalls etc., are aware of this
opt=
ion and problems can be avoided.
 
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 
di=
fferent.
 
- Already existin=
g non-standardized option numbers (TCP option 33,
rive=
rbed's options no's) for doing auto discovery should not be
allocated for this new TCP option. This is to prevent any confusion.<=
o:p>
 
- The TCP option needs to =
be variable length to permit multiple option
formats s=
ince the option size may vary depending on the vendor.
 
- This TCP option should be advocated for use =
only by middleboxes.
 
=
 
My guess is that these requirements may be common fo=
r all the vendors or
there may be some additional requ=
irements not covered by this post. In
either case we c=
an continue the discussion and come to some conclusions.
 
-Anantha
______________=
_________________________________
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
  



 
--_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D125MAILBOXES2nbtte_-- From andrew.knutsen@bluecoat.com Tue May 25 18:38:08 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02A33A677D for ; Tue, 25 May 2010 18:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-A776ZCgZqw for ; Tue, 25 May 2010 18:38:00 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id F39F73A635F for ; Tue, 25 May 2010 18:37: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 o4Q1bpF7017350; Tue, 25 May 2010 18:37:51 -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, 25 May 2010 18:37:46 -0700 Message-ID: <4BFC7B69.6000204@bluecoat.com> Date: Tue, 25 May 2010 18:37:45 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Day References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020905050403000301070502" X-OriginalArrivalTime: 26 May 2010 01:37:46.0114 (UTC) FILETIME=[0ACDB620:01CAFC74] Cc: Ron Frederick , "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 May 2010 01:38:08 -0000 This is a multi-part message in MIME format. --------------020905050403000301070502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with your concern about terminology. I just spent about 6 months trying to get this past TCPM, and although the word "tunnel" didn't raise (many) hairs, the idea of spoofing sure did... And of course transparent tunnels, like proxies, are spoofed (more than once if the customer doesn't even want to see tunnels on their network ;-). Funny thing is I bet almost everyone on that list uses spoofed connections every day. Its not our job to help them with their denial though. If you think we should use the current draft as a starting point, please let us know if you think any part of it is "problematic". I had to make it somewhat explicit in some areas to give folks on the list some context, but we don't have to keep it all. I don't have a problem with adding the "maintaining communication" text. Andrew Mark Day wrote: > > Specifying a single-byte vendor code, with some reserved "standard" > value(s) of that byte, sounds good. I also agree that we need to > define what this is intended for so it doesn't become the all-purpose > option. > > > > As a practical matter the "t-word" (tunnel) may be problematic. Any of > you who are not exposed to the competitive side of this market may > find it mind-boggling, but there has been a lot of thrashing around on > the topic of whether tunnels are evil and whether a given product does > or doesn't use tunnels. (Some of this has involved misunderstanding > or mischaracterizing other vendors' products). Accordingly it seems > unwise to write a high-level generic statement of purpose in terms of > establishing or maintaining "tunnels". > > > > Can we say instead that this option is about discovering some other > middlebox and maintaining communication with that discovered middlebox? > > > > --Mark > > > > > > *From:* Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] > *Sent:* Tuesday, May 25, 2010 8:28 PM > *To:* Mark Day > *Cc:* middisc@ietf.org; Ron Frederick; Qing Li > *Subject:* Re: [middisc] TCP middlebox option requirements > > > > > It seems to me that if we do limit our goal here to agreeing on an > option number and vendor ID scheme, we haven't really limited > ourselves to autodiscovery except in the requirements we state for > getting a vendor ID (ie, agreements on use). Mostly this would involve > removing the requirement that the option only be present with the SYN > bit. We added this requirement primarily due to concerns about > reliable transmission, but in later discussions we came up with a > midstream discovery requirement and mechanism where that isn't an > issue, so I don't think we're particularly attached to it. Also, we > probably don't have to require everyone to encode the vendor-specific > type information in the same way. > > Another implication of that goal is that we wouldn't be making a > standard per se; rather we'd be making a first step towards a set of > standards. Thats the purpose of the "P" bit in the current proposal, > and the "standard vendor" codes in the proposal for removing the OUI > in my message below. The idea is that as the technology matures, we > can move towards a standard mechanism. > > I'm not familiar with IPv6 options, but at this point what we're > doing sounds so simple it should work. > > I'm getting the impression that to make this alternate option > useful to everyone here, we have to change the proposal in a few ways, > including: > > 1) Removing the OUI, and having a single byte of vendor code. The > option format would be vendor-specific. > 2) Replacing the P bit with a "standard" vendor code or codes -- > perhaps one code per interoperable option format. > 3) Removing the requirement that the option only be present with > the SYN bit set. > 4) It sounds like the R bit may be redundant with other, more > complex schemes already implemented by some vendors. > > This would mean the option format would only specify a single byte > of vendor ID after the option length. We would need some stipulations > on the option's use (making and maintaining tunnels, perhaps). Vendors > would have to agree to these stipulations to get a code, so we aren't > making a "catch-all" option. > > Opinions? > > Andrew > > Mark Day wrote: > > Two additional issues seem worth clarifying since I'm not sure how others would view them. > > 1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes? For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery. It wouldn't surprise me to learn that other vendors have other similar schemes. > > 2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments? > > In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard. And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward. > > --Mark > > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen > Sent: Friday, May 21, 2010 2:23 PM > To: middisc@ietf.org > Subject: Re: [middisc] TCP middlebox option requirements > > > Thanks Ananth. > > One possibility that Jamshid and I talked about addresses concerns > about using 3 bytes for the OUI. We could skip it (and the P bit), and > break up the 15 bits or so of "device capability" into an IANA-assigned > vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific > type. There could be one or more "standard" vendor codes for > multi-vendor interoperability (ie, IANA-assigned types), and an > extension code if we run out of room. > > Perhaps we also need to define the requirements for getting a vendor > code or a standard type -- for instance, we might not want any > individual to be able to get a vendor code, since they are limited; and > the standard types would need some documentation, but perhaps not as > widely reviewed as for a top-level option kind. > > Andrew > > Anantha Ramaiah (ananth) wrote: > > > Hi, > > I am just taking the liberty to post the first email on this mailing > > list. During our last call there was talk about the requirements of this > > TCP option. From our pov, the following would be the general > > requirements of the TCP option. > > > > > > Reason for TCP option : > > > > - A standard TCP option is needed because every vendor cannot have one > > option for the same purpose of auto-discovery and capability exchange. > > By standardizing the TCP option, firewalls etc., are aware of this > > option and problems can be avoided. > > > > 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. > > > > - 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. > > > > > > My guess is that these requirements may be common for all the vendors or > > there may be some additional requirements not covered by this post. In > > either case we can continue the discussion and come to some conclusions. > > > > -Anantha > > _______________________________________________ > > 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 > > > > --------------020905050403000301070502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I agree with your concern about terminology.  I just spent about 6 months trying to get this past TCPM, and although the word "tunnel" didn't raise (many) hairs, the idea of spoofing sure did...  And of course transparent tunnels, like proxies, are spoofed (more than once if the customer doesn't even want to see tunnels on their network ;-).  Funny thing is I bet almost everyone on that list uses spoofed connections every day.  Its not our job to help them with their denial though.

    If you think we should use the current draft as a starting point, please let us know if you think any part of it is "problematic". I had to make it somewhat explicit in some areas to give folks on the list some context, but we don't have to keep it all.  I don't have a problem with adding the "maintaining communication" text.

Andrew

Mark Day wrote:

Specifying a single-byte vendor code, with some reserved “standard” value(s) of that byte, sounds good.  I also agree that we need to define what this is intended for so it doesn’t become the all-purpose option.

 

As a practical matter the “t-word” (tunnel) may be problematic. Any of you who are not exposed to the competitive side of this market may find it mind-boggling, but there has been a lot of thrashing around on the topic of whether tunnels are evil and whether a given product does or doesn’t use tunnels.  (Some of this has involved misunderstanding or mischaracterizing other vendors’ products).  Accordingly it seems unwise to write a high-level generic statement of purpose in terms of establishing or maintaining “tunnels”.

 

Can we say instead that this option is about discovering some other middlebox and maintaining communication with that discovered middlebox?

 

--Mark

 

 

From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
Sent: Tuesday, May 25, 2010 8:28 PM
To: Mark Day
Cc: middisc@ietf.org; Ron Frederick; Qing Li
Subject: Re: [middisc] TCP middlebox option requirements

 


    It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way.

   Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards.  Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work.

   I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be present with the SYN bit set.
    4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors.

    This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option.

    Opinions?

Andrew

Mark Day wrote: 

Two additional issues seem worth clarifying since I'm not sure how others would view them.
 
1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes?  For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery.  It wouldn't surprise me to learn that other vendors have other similar schemes.
 
2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments?  
 
In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard.  And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward.
 
--Mark
 
-----Original Message-----
From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements
 
 
    Thanks Ananth.
 
    One possibility that Jamshid and I talked about addresses concerns 
about using 3 bytes for the OUI. We could skip it (and the P bit), and 
break up the 15 bits or so of "device capability" into an IANA-assigned 
vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific 
type. There could be one or more "standard" vendor codes for 
multi-vendor interoperability (ie, IANA-assigned types), and an 
extension code if we run out of room.
 
    Perhaps we also need to define the requirements for getting a vendor 
code or a standard type -- for instance, we might not want any 
individual to be able to get a vendor code, since they are limited; and 
the standard types would need some documentation, but perhaps not as 
widely reviewed as for a top-level option kind.
 
Andrew
 
Anantha Ramaiah (ananth) wrote:
  
Hi,
   I am just taking the liberty to post the first email on this mailing
list. During our last call there was talk about the requirements of this
TCP option. From our pov, the following would be the general
requirements of the TCP option.
 
 
Reason for TCP option :
 
- A standard TCP option is needed because every vendor cannot have one
option for the same purpose of auto-discovery and capability exchange.
By standardizing the TCP option, firewalls etc., are aware of this
option and problems can be avoided.
 
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.
 
- 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.
 
 
My guess is that these requirements may be common for all the vendors or
there may be some additional requirements not covered by this post. In
either case we can continue the discussion and come to some conclusions.
 
-Anantha
_______________________________________________
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
 

 


--------------020905050403000301070502-- From ron.frederick@bluecoat.com Tue May 25 17:51:57 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E0A3A635F for ; Tue, 25 May 2010 17:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFzeNxw3AhM5 for ; Tue, 25 May 2010 17:51:56 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 2A3953A67A4 for ; Tue, 25 May 2010 17:51:54 -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 o4Q0pjxK011271; Tue, 25 May 2010 17:51:45 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 May 2010 17:51:40 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-60-175156359 From: Ron Frederick In-Reply-To: <4BFC6B29.1080706@bluecoat.com> Date: Tue, 25 May 2010 17:51:39 -0700 Message-Id: <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <4BFC6B29.1080706@bluecoat.com> To: Andrew Knutsen X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 26 May 2010 00:51:40.0678 (UTC) FILETIME=[9A79AA60:01CAFC6D] X-Mailman-Approved-At: Tue, 25 May 2010 18:57:14 -0700 Cc: Ron Frederick , middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 May 2010 00:55:32 -0000 --Apple-Mail-60-175156359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 25, 2010, at 5:28 PM, Andrew Knutsen wrote: > It seems to me that if we do limit our goal here to agreeing on an = option number and vendor ID scheme, we haven't really limited ourselves = to autodiscovery except in the requirements we state for getting a = vendor ID (ie, agreements on use). Mostly this would involve removing = the requirement that the option only be present with the SYN bit. We = added this requirement primarily due to concerns about reliable = transmission, but in later discussions we came up with a midstream = discovery requirement and mechanism where that isn't an issue, so I = don't think we're particularly attached to it. Also, we probably don't = have to require everyone to encode the vendor-specific type information = in the same way. >=20 > Another implication of that goal is that we wouldn't be making a = standard per se; rather we'd be making a first step towards a set of = standards. Thats the purpose of the "P" bit in the current proposal, = and the "standard vendor" codes in the proposal for removing the OUI in = my message below. The idea is that as the technology matures, we can = move towards a standard mechanism. >=20 > I'm not familiar with IPv6 options, but at this point what we're = doing sounds so simple it should work. >=20 > I'm getting the impression that to make this alternate option = useful to everyone here, we have to change the proposal in a few ways, = including: >=20 > 1) Removing the OUI, and having a single byte of vendor code. The = option format would be vendor-specific. > 2) Replacing the P bit with a "standard" vendor code or codes -- = perhaps one code per interoperable option format. > 3) Removing the requirement that the option only be present with = the SYN bit set. > 4) It sounds like the R bit may be redundant with other, more = complex schemes already implemented by some vendors. >=20 > This would mean the option format would only specify a single byte = of vendor ID after the option length. We would need some stipulations on = the option's use (making and maintaining tunnels, perhaps). Vendors = would have to agree to these stipulations to get a code, so we aren't = making a "catch-all" option. >=20 > Opinions? [Ron] A single byte for vendor ID clearly will not scale. There can = easily be more than 256 vendors our there who may eventually want to use = this option. I don't see any obvious way to do better space-wise than = what we proposed with the OUI if we want this to be truly extensible to = support all possible vendors. Regarding the P bit, I don't really understand what you mean. We could = have a single vendor code value for all the standard extensions, but = we'd still need another byte for which option it was. If we burn a = vendor code point for each interoperable option, we'd have even fewer = code points left to allow vendor extensibility. If we think we can live = with only 127 possible options (both for standard options and for each = vendor), we could potentially shorten the type field from 2 bytes to 1 = byte, which would then become 4 bytes when you add the OUI when the P = bit is set, but I'm not sure the single byte of savings we get from that = is really worth the flexibility we lose by dropping from 32K options per = vendor to 127. Both of these numbers drop by a factor of 2 if we keep = the R bit, which makes it even more of a poor choice. I'm ok with dropping the requirement that these options are only sent on = the SYN and SYN-ACK, but I would prefer to see an example of sending = such an option mid-stream and some text which describes the known issues = with trying to send an option in such an unsyncrhonized way. Regarding the R bit, I could potentially see folding that into the = vendor-specific data, but I would expect pretty much everyone to need to = deal with this issue, so it seems like it would be best if we had a = single general mechanism which did so. > Mark Day wrote: >>=20 >> Two additional issues seem worth clarifying since I'm not sure how = others would view them. >>=20 >> 1. Are we concerned strictly with autodiscovery options, or are we = attempting to understand the requirements for options usage generally = among current symmetric middleboxes? For example, Riverbed uses a = different option for some forms of addressing information in situations = after the two communicating peers have been established by = autodiscovery. It wouldn't surprise me to learn that other vendors have = other similar schemes. >>=20 >> 2. Don't we also need to consider requirements for autodiscovery = options in IPv6 environments? =20 >>=20 >> In both cases, I can see a pragmatic argument for focusing narrowly = vs. an architectural argument for considering broader issues. IPv4 = autodiscovery is the clear existing interoperability/coexistence problem = and may be solvable by simply agreeing on an option number and vendor id = scheme, while the other areas might not yet have enough experience and = implementations to justify a standard. And yet it feels to me like we = might solve one option-related problem just to trip across another = similar one soon afterward. >>=20 >> --Mark >>=20 >> -----Original Message----- >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On = Behalf Of Andrew Knutsen >> Sent: Friday, May 21, 2010 2:23 PM >> To: middisc@ietf.org >> Subject: Re: [middisc] TCP middlebox option requirements >>=20 >>=20 >> Thanks Ananth. >>=20 >> One possibility that Jamshid and I talked about addresses = concerns=20 >> about using 3 bytes for the OUI. We could skip it (and the P bit), = and=20 >> break up the 15 bits or so of "device capability" into an = IANA-assigned=20 >> vendor code of maybe 7 bits, leaving 8 bits (or so) for = vendor-specific=20 >> type. There could be one or more "standard" vendor codes for=20 >> multi-vendor interoperability (ie, IANA-assigned types), and an=20 >> extension code if we run out of room. >>=20 >> Perhaps we also need to define the requirements for getting a = vendor=20 >> code or a standard type -- for instance, we might not want any=20 >> individual to be able to get a vendor code, since they are limited; = and=20 >> the standard types would need some documentation, but perhaps not as=20= >> widely reviewed as for a top-level option kind. >>=20 >> Andrew >>=20 >> Anantha Ramaiah (ananth) wrote: >> =20 >>> Hi, >>> I am just taking the liberty to post the first email on this = mailing >>> list. During our last call there was talk about the requirements of = this >>> TCP option. =46rom our pov, the following would be the general >>> requirements of the TCP option. >>>=20 >>>=20 >>> Reason for TCP option : >>>=20 >>> - A standard TCP option is needed because every vendor cannot have = one >>> option for the same purpose of auto-discovery and capability = exchange. >>> By standardizing the TCP option, firewalls etc., are aware of this >>> option and problems can be avoided. >>>=20 >>> Requirements of this TCP option : >>>=20 >>> - 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=20 >>> different. >>>=20 >>> - 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. >>>=20 >>> - The TCP option needs to be variable length to permit multiple = option >>> formats since the option size may vary depending on the vendor. >>>=20 >>> - This TCP option should be advocated for use only by middleboxes. >>>=20 >>>=20 >>> My guess is that these requirements may be common for all the = vendors or >>> there may be some additional requirements not covered by this post. = In >>> either case we can continue the discussion and come to some = conclusions. >>>=20 >>> -Anantha --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-60-175156359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    It seems to me that if we do limit our goal here to = agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way.

   Another implication of that goal is that we wouldn't be = making a standard per se; rather we'd be making a first step towards a set of standards.  Thats the purpose of the "P" bit in the current = proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism.

   I'm not familiar with IPv6 options, but at this point what = we're doing sounds so simple it should work.

   I'm getting the impression that to make this alternate = option useful to everyone here, we have to change the proposal in a few ways, including:

    1) Removing the OUI, and having a single byte of = vendor code. The option format would be vendor-specific.
    2) Replacing the P bit with a "standard" vendor code = or codes -- perhaps one code per interoperable option format.
    3) Removing the requirement that the option only be = present with the SYN bit set.
    4) It sounds like the R bit may be redundant with = other, more complex schemes already implemented by some vendors.

    This would mean the option format would only specify = a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option.

    Opinions?

[Ron] A single byte for = vendor ID clearly will not scale. There can easily be more than 256 = vendors our there who may eventually want to use this option. I don't = see any obvious way to do better space-wise than what we proposed with = the OUI if we want this to be truly extensible to support all possible = vendors.

Regarding the P bit, I don't really understand what = you mean. We could have a single vendor code value for all the standard = extensions, but we'd still need another byte for which option it was. If = we burn a vendor code point for each interoperable option, we'd have = even fewer code points left to allow vendor extensibility. If we think = we can live with only 127 possible options (both for standard options = and for each vendor), we could potentially shorten the type field from 2 = bytes to 1 byte, which would then become 4 bytes when you add the OUI = when the P bit is set, but I'm not sure the single byte of savings we = get from that is really worth the flexibility we lose by dropping from = 32K options per vendor to 127. Both of these numbers drop by a = factor of 2 if we keep the R bit, which makes it even more of a poor = choice.

I'm ok with dropping the requirement that these = options are only sent on the SYN and SYN-ACK, but I would prefer to see = an example of sending such an option mid-stream and some text which = describes the known issues with trying to send an option in such an = unsyncrhonized way.

Regarding the R bit, I could potentially see folding = that into the vendor-specific data, but I would expect pretty much = everyone to need to deal with this issue, so it seems like it would be = best if we had a single general mechanism which did = so.

Mark Day wrote: 
Two additional issues seem worth clarifying since I'm =
not sure how others would view them.

1. Are we concerned strictly with autodiscovery options, or are we =
attempting to understand the requirements for options usage generally =
among current symmetric middleboxes?  For example, Riverbed uses a =
different option for some forms of addressing information in situations =
after the two communicating peers have been established by =
autodiscovery.  It wouldn't surprise me to learn that other vendors have =
other similar schemes.

2. Don't we also need to consider requirements for autodiscovery options =
in IPv6 environments? =20

In both cases, I can see a pragmatic argument for focusing narrowly vs. =
an architectural argument for considering broader issues. IPv4 =
autodiscovery is the clear existing interoperability/coexistence problem =
and may be solvable by simply agreeing on an option number and vendor id =
scheme, while the other areas might not yet have enough experience and =
implementations to justify a standard.  And yet it feels to me like we =
might solve one option-related problem just to trip across another =
similar one soon afterward.

--Mark

-----Original Message-----
From: middisc-bounces@ietf.org =
[mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements


    Thanks Ananth.

    One possibility that Jamshid and I talked about addresses concerns=20=

about using 3 bytes for the OUI. We could skip it (and the P bit), and=20=

break up the 15 bits or so of "device capability" into an IANA-assigned=20=

vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific=20=

type. There could be one or more "standard" vendor codes for=20
multi-vendor interoperability (ie, IANA-assigned types), and an=20
extension code if we run out of room.

    Perhaps we also need to define the requirements for getting a vendor=20=

code or a standard type -- for instance, we might not want any=20
individual to be able to get a vendor code, since they are limited; and=20=

the standard types would need some documentation, but perhaps not as=20
widely reviewed as for a top-level option kind.

Andrew

Anantha Ramaiah (ananth) wrote:
  
Hi,
   I am just taking the liberty to post the first email on this mailing
list. During our last call there was talk about the requirements of this
TCP option. =46rom our pov, the following would be the general
requirements of the TCP option.


Reason for TCP option :

- A standard TCP option is needed because every vendor cannot have one
option for the same purpose of auto-discovery and capability exchange.
By standardizing the TCP option, firewalls etc., are aware of this
option and problems can be avoided.

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=20
different.

- 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.


My guess is that these requirements may be common for all the vendors or
there may be some additional requirements not covered by this post. In
either case we can continue the discussion and come to some conclusions.

-Anantha
-- 
Ron = Frederick



= --Apple-Mail-60-175156359-- From ananth@cisco.com Tue May 25 22:59:36 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDF23A685B for ; Tue, 25 May 2010 22:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWRAg3TrCSkB for ; Tue, 25 May 2010 22:59:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 847B63A6872 for ; Tue, 25 May 2010 22:59:34 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEdV/EurRN+K/2dsb2JhbACeGnGlUplyglmCOgSDQh8 X-IronPort-AV: E=Sophos;i="4.53,302,1272844800"; d="scan'208,217";a="135087676" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 May 2010 05:59:25 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4Q5xPGh007169; Wed, 26 May 2010 05:59:26 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 May 2010 22:59:25 -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_01CAFC98.9826477A" Date: Tue, 25 May 2010 22:59:24 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809C77A99@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr8dtwZm6a9SYuNT1C+otsk46jC2AAIJ3NQ References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com><4BF6CF8A.5030707@bluecoat.com><4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> From: "Anantha Ramaiah (ananth)" To: "Ron Frederick" , "Andrew Knutsen" X-OriginalArrivalTime: 26 May 2010 05:59:25.0687 (UTC) FILETIME=[987A7070:01CAFC98] Cc: Ron Frederick , middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 26 May 2010 05:59:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFC98.9826477A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OUI as exists today is standardized and managed and provides unquiness. If we were to define a 1 byte vendor it, it has all issues which Ron mentioned below + the need for standardizing that space, I don't know who is going to manage allocation and maintenance of that field. I don't think IANA would do that. =20 I also wanted to understand the use case of having this option sent in the middle of the connection. FWIW TCP options as exisits today are either "negotiated" one time in the initial 3 way handshake (MSS, Window scale, SACK permitted etc.,) or sent on every packet (TCP MD5, TIMESTAMP etc.,) On demand sendind of the option is something new, so is the concept of variable length TCP option (with the exception of SACK, which itself needs to agreed upon using SACK PERMITTED option during the 3 way HS. =20 -Anantha ________________________________ From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Ron Frederick Sent: Tuesday, May 25, 2010 5:52 PM To: Andrew Knutsen Cc: Ron Frederick; middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements =09 =09 On May 25, 2010, at 5:28 PM, Andrew Knutsen wrote: It seems to me that if we do limit our goal here to agreeing on an option number and vendor ID scheme, we haven't really limited ourselves to autodiscovery except in the requirements we state for getting a vendor ID (ie, agreements on use). Mostly this would involve removing the requirement that the option only be present with the SYN bit. We added this requirement primarily due to concerns about reliable transmission, but in later discussions we came up with a midstream discovery requirement and mechanism where that isn't an issue, so I don't think we're particularly attached to it. Also, we probably don't have to require everyone to encode the vendor-specific type information in the same way. =09 Another implication of that goal is that we wouldn't be making a standard per se; rather we'd be making a first step towards a set of standards. Thats the purpose of the "P" bit in the current proposal, and the "standard vendor" codes in the proposal for removing the OUI in my message below. The idea is that as the technology matures, we can move towards a standard mechanism. =09 I'm not familiar with IPv6 options, but at this point what we're doing sounds so simple it should work. =09 I'm getting the impression that to make this alternate option useful to everyone here, we have to change the proposal in a few ways, including: =09 1) Removing the OUI, and having a single byte of vendor code. The option format would be vendor-specific. 2) Replacing the P bit with a "standard" vendor code or codes -- perhaps one code per interoperable option format. 3) Removing the requirement that the option only be present with the SYN bit set. 4) It sounds like the R bit may be redundant with other, more complex schemes already implemented by some vendors. =09 This would mean the option format would only specify a single byte of vendor ID after the option length. We would need some stipulations on the option's use (making and maintaining tunnels, perhaps). Vendors would have to agree to these stipulations to get a code, so we aren't making a "catch-all" option. =09 Opinions? =09 =09 =09 [Ron] A single byte for vendor ID clearly will not scale. There can easily be more than 256 vendors our there who may eventually want to use this option. I don't see any obvious way to do better space-wise than what we proposed with the OUI if we want this to be truly extensible to support all possible vendors. =09 =09 Regarding the P bit, I don't really understand what you mean. We could have a single vendor code value for all the standard extensions, but we'd still need another byte for which option it was. If we burn a vendor code point for each interoperable option, we'd have even fewer code points left to allow vendor extensibility. If we think we can live with only 127 possible options (both for standard options and for each vendor), we could potentially shorten the type field from 2 bytes to 1 byte, which would then become 4 bytes when you add the OUI when the P bit is set, but I'm not sure the single byte of savings we get from that is really worth the flexibility we lose by dropping from 32K options per vendor to 127. Both of these numbers drop by a factor of 2 if we keep the R bit, which makes it even more of a poor choice. =09 =09 I'm ok with dropping the requirement that these options are only sent on the SYN and SYN-ACK, but I would prefer to see an example of sending such an option mid-stream and some text which describes the known issues with trying to send an option in such an unsyncrhonized way. =09 =09 Regarding the R bit, I could potentially see folding that into the vendor-specific data, but I would expect pretty much everyone to need to deal with this issue, so it seems like it would be best if we had a single general mechanism which did so. =09 =09 Mark Day wrote:=20 Two additional issues seem worth clarifying since I'm not sure how others would view them. =09 1. Are we concerned strictly with autodiscovery options, or are we attempting to understand the requirements for options usage generally among current symmetric middleboxes? For example, Riverbed uses a different option for some forms of addressing information in situations after the two communicating peers have been established by autodiscovery. It wouldn't surprise me to learn that other vendors have other similar schemes. =09 2. Don't we also need to consider requirements for autodiscovery options in IPv6 environments? =20 =09 In both cases, I can see a pragmatic argument for focusing narrowly vs. an architectural argument for considering broader issues. IPv4 autodiscovery is the clear existing interoperability/coexistence problem and may be solvable by simply agreeing on an option number and vendor id scheme, while the other areas might not yet have enough experience and implementations to justify a standard. And yet it feels to me like we might solve one option-related problem just to trip across another similar one soon afterward. =09 --Mark =09 -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Andrew Knutsen Sent: Friday, May 21, 2010 2:23 PM To: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements =09 =09 Thanks Ananth. =09 One possibility that Jamshid and I talked about addresses concerns=20 about using 3 bytes for the OUI. We could skip it (and the P bit), and=20 break up the 15 bits or so of "device capability" into an IANA-assigned=20 vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific=20 type. There could be one or more "standard" vendor codes for=20 multi-vendor interoperability (ie, IANA-assigned types), and an=20 extension code if we run out of room. =09 Perhaps we also need to define the requirements for getting a vendor=20 code or a standard type -- for instance, we might not want any=20 individual to be able to get a vendor code, since they are limited; and=20 the standard types would need some documentation, but perhaps not as=20 widely reviewed as for a top-level option kind. =09 Andrew =09 Anantha Ramaiah (ananth) wrote: =20 Hi, I am just taking the liberty to post the first email on this mailing list. During our last call there was talk about the requirements of this TCP option. From our pov, the following would be the general requirements of the TCP option. =09 =09 Reason for TCP option : =09 - A standard TCP option is needed because every vendor cannot have one option for the same purpose of auto-discovery and capability exchange. By standardizing the TCP option, firewalls etc., are aware of this option and problems can be avoided. =09 Requirements of this TCP option : =09 - 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=20 different. =09 - 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. =09 - The TCP option needs to be variable length to permit multiple option formats since the option size may vary depending on the vendor. =09 - This TCP option should be advocated for use only by middleboxes. =09 =09 My guess is that these requirements may be common for all the vendors or there may be some additional requirements not covered by this post. In either case we can continue the discussion and come to some conclusions. =09 -Anantha =09 --=20 Ron Frederick ronf@bluecoat.com ------_=_NextPart_001_01CAFC98.9826477A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OUI as exists today is standardized and managed = and=20 provides unquiness. If we were to define a 1 byte vendor it, it has all = issues=20 which Ron mentioned below + the need for standardizing that space, I = don't know=20 who is going to manage allocation and maintenance of that field. I don't = think=20 IANA would do that.
 
I also wanted to understand the use case of = having this=20 option sent in the middle of the connection. FWIW TCP options as exisits = today=20 are either "negotiated" one time in the initial 3 way handshake (MSS, = Window=20 scale, SACK permitted etc.,) or sent on every packet (TCP MD5,  = TIMESTAMP=20 etc.,) On demand sendind of the option is something new, so is the = concept of=20 variable length TCP option (with the exception of SACK, which itself = needs to=20 agreed upon using SACK PERMITTED option during the 3 way = HS.
 
-Anantha

From: middisc-bounces@ietf.org=20 [mailto:middisc-bounces@ietf.org] On Behalf Of Ron=20 Frederick
Sent: Tuesday, May 25, 2010 5:52 PM
To: = Andrew=20 Knutsen
Cc: Ron Frederick; = middisc@ietf.org
Subject: Re:=20 [middisc] TCP middlebox option requirements

On May 25, 2010, at 5:28 PM, Andrew Knutsen wrote:
    It = seems to me that=20 if we do limit our goal here to agreeing on an option number and = vendor ID=20 scheme, we haven't really limited ourselves to autodiscovery except = in the=20 requirements we state for getting a vendor ID (ie, agreements on = use).=20 Mostly this would involve removing the requirement that the option = only be=20 present with the SYN bit. We added this requirement primarily due to = concerns about reliable transmission, but in later discussions we = came up=20 with a midstream discovery requirement and mechanism where that = isn't an=20 issue, so I don't think we're particularly attached to it. Also, we = probably=20 don't have to require everyone to encode the vendor-specific type=20 information in the same way.

   Another implication = of that=20 goal is that we wouldn't be making a standard per se; rather we'd be = making=20 a first step towards a set of standards.  Thats the purpose of = the "P"=20 bit in the current proposal, and the "standard vendor" codes in the = proposal=20 for removing the OUI in my message below. The idea is that as the = technology=20 matures, we can move towards a standard = mechanism.

   I'm=20 not familiar with IPv6 options, but at this point what we're doing = sounds so=20 simple it should work.

   I'm getting the = impression that=20 to make this alternate option useful to everyone here, we have to = change the=20 proposal in a few ways, including:

    1) = Removing the=20 OUI, and having a single byte of vendor code. The option format = would be=20 vendor-specific.
    2) Replacing the P bit with a = "standard" vendor code or codes -- perhaps one code per = interoperable option=20 format.
    3) Removing the requirement that the = option=20 only be present with the SYN bit set.
    4) It = sounds=20 like the R bit may be redundant with other, more complex schemes = already=20 implemented by some vendors.

    This would = mean the=20 option format would only specify a single byte of vendor ID after = the option=20 length. We would need some stipulations on the option's use (making = and=20 maintaining tunnels, perhaps). Vendors would have to agree to these=20 stipulations to get a code, so we aren't making a "catch-all"=20 option.

    Opinions?

[Ron] A single byte for vendor ID clearly will not = scale. There=20 can easily be more than 256 vendors our there who may eventually want = to use=20 this option. I don't see any obvious way to do better space-wise than = what we=20 proposed with the OUI if we want this to be truly extensible to = support all=20 possible vendors.

Regarding the P = bit, I don't=20 really understand what you mean. We could have a single vendor code = value for=20 all the standard extensions, but we'd still need another byte for = which option=20 it was. If we burn a vendor code point for each interoperable option, = we'd=20 have even fewer code points left to allow vendor extensibility. If we = think we=20 can live with only 127 possible options (both for standard options and = for=20 each vendor), we could potentially shorten the type field from 2 bytes = to 1=20 byte, which would then become 4 bytes when you add the OUI when the P = bit is=20 set, but I'm not sure the single byte of savings we get from that is = really=20 worth the flexibility we lose by dropping from = 32K options per=20 vendor to 127. Both of these numbers drop by a factor of 2 if we keep = the R=20 bit, which makes it even more of a poor choice.

I'm ok with = dropping the=20 requirement that these options are only sent on the SYN and SYN-ACK, = but I=20 would prefer to see an example of sending such an option mid-stream = and some=20 text which describes the known issues with trying to send an option in = such an=20 unsyncrhonized way.

Regarding the R = bit, I could=20 potentially see folding that into the vendor-specific data, but I = would expect=20 pretty much everyone to need to deal with this issue, so it seems like = it=20 would be best if we had a single general mechanism which did = so.
Mark Day wrote:=20 
Two additional issues seem worth =
clarifying since I'm not sure how others would view them.

1. Are we concerned strictly with autodiscovery options, or are we =
attempting to understand the requirements for options usage generally =
among current symmetric middleboxes?  For example, Riverbed uses a =
different option for some forms of addressing information in situations =
after the two communicating peers have been established by =
autodiscovery.  It wouldn't surprise me to learn that other vendors have =
other similar schemes.

2. Don't we also need to consider requirements for autodiscovery options =
in IPv6 environments? =20

In both cases, I can see a pragmatic argument for focusing narrowly vs. =
an architectural argument for considering broader issues. IPv4 =
autodiscovery is the clear existing interoperability/coexistence problem =
and may be solvable by simply agreeing on an option number and vendor id =
scheme, while the other areas might not yet have enough experience and =
implementations to justify a standard.  And yet it feels to me like we =
might solve one option-related problem just to trip across another =
similar one soon afterward.

--Mark

-----Original Message-----
From: middisc-bounces@ietf.org =
[mailto:middisc-bounces@ietf.org<=
/A>] On Behalf Of Andrew Knutsen
Sent: Friday, May 21, 2010 2:23 PM
To: middisc@ietf.org
Subject: Re: [middisc] TCP middlebox option requirements


    Thanks Ananth.

    One possibility that Jamshid and I talked about addresses concerns=20
about using 3 bytes for the OUI. We could skip it (and the P bit), and=20
break up the 15 bits or so of "device capability" into an IANA-assigned=20
vendor code of maybe 7 bits, leaving 8 bits (or so) for vendor-specific=20
type. There could be one or more "standard" vendor codes for=20
multi-vendor interoperability (ie, IANA-assigned types), and an=20
extension code if we run out of room.

    Perhaps we also need to define the requirements for getting a vendor =

code or a standard type -- for instance, we might not want any=20
individual to be able to get a vendor code, since they are limited; and=20
the standard types would need some documentation, but perhaps not as=20
widely reviewed as for a top-level option kind.

Andrew

Anantha Ramaiah (ananth) wrote:
  
Hi,
   I am just taking the liberty to post the first email on this mailing
list. During our last call there was talk about the requirements of this
TCP option. From our pov, the following would be the general
requirements of the TCP option.


Reason for TCP option :

- A standard TCP option is needed because every vendor cannot have one
option for the same purpose of auto-discovery and capability exchange.
By standardizing the TCP option, firewalls etc., are aware of this
option and problems can be avoided.

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=20
different.

- 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.


My guess is that these requirements may be common for all the vendors or
there may be some additional requirements not covered by this post. In
either case we can continue the discussion and come to some conclusions.

-Anantha
-- 
Ron Frederick


------_=_NextPart_001_01CAFC98.9826477A-- From Mark.Day@riverbed.com Wed May 26 20:16:31 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6643A67E2 for ; Wed, 26 May 2010 20:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLssNB3nx-2G for ; Wed, 26 May 2010 20:16:27 -0700 (PDT) Received: from smtp2.riverbed.com (smtp.riverbed.com [208.70.196.44]) by core3.amsl.com (Postfix) with ESMTP id DFC313A677D for ; Wed, 26 May 2010 20:16:21 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 26 May 2010 20:16:10 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.0.165]) with mapi; Wed, 26 May 2010 20:13:55 -0700 From: Mark Day To: Lars Eggert , "middisc@ietf.org" Date: Wed, 26 May 2010 20:13:53 -0700 Thread-Topic: [middisc] currently used TCP option numbers Thread-Index: Acr7SgOAaegSLerER8utha9k9eopCQCAEPVw Message-ID: References: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> In-Reply-To: <55DCF9B6-2694-4D76-9F4A-DCB6AAF9D88C@nokia.com> 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 Subject: Re: [middisc] currently used TCP option numbers X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 03:16:32 -0000 Riverbed currently uses options 76,77, and 78. Our products are configurabl= e to allow changing the option number(s) used, but in practice almost no-on= e changes from the default option numbers. --Mark -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Lars Eggert Sent: Monday, May 24, 2010 10:04 AM To: middisc@ietf.org Subject: [middisc] currently used TCP option numbers Hi, in order to avoid clashes between options that the IETF assigns in the near= future and ones that are currently being used without proper registration,= would you let me know which option numbers your products use and - if you = are aware of it - which numbers may be used by other vendors? I will then i= nstruct IANA to mark them as "user without proper registration" (or somethi= ng like this) in the IANA table at http://www.iana.org/assignments/tcp-para= meters/tcp-parameters.xml=20 My main motivation is that we've just assigned option #29, and I have heard= that some vendors are using numbers in the low 30s. Because IANA typically= assigns numbers incrementally, there may be a clash in the not too far fut= ure. I'd really like to avoid those clashes from happening. IANA can skip t= hose numbers that are used without proper registration, if they know about = them. Thanks, Lars From Mark.Day@riverbed.com Wed May 26 20:29:44 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E443A67B6 for ; Wed, 26 May 2010 20:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.26 X-Spam-Level: * X-Spam-Status: No, score=1.26 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w36SUggoTb3T for ; Wed, 26 May 2010 20:29:39 -0700 (PDT) Received: from smtp2.riverbed.com (eng.riverbed.com [208.70.196.44]) by core3.amsl.com (Postfix) with ESMTP id AE7353A67A3 for ; Wed, 26 May 2010 20:29:39 -0700 (PDT) Received: from unknown (HELO exhub1.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 26 May 2010 20:29:30 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub1.nbttech.com ([10.16.0.163]) with mapi; Wed, 26 May 2010 20:28:02 -0700 From: Mark Day To: Ron Frederick , Andrew Knutsen Date: Wed, 26 May 2010 20:28:00 -0700 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr8bZ47uMD9s9gPSgqXxIG60u4QmAA3Vnww 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> In-Reply-To: <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.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_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6MAILBOXES2nbtte_" MIME-Version: 1.0 Cc: Ron Frederick , "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 03:29:44 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6MAILBOXES2nbtte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Ron] A single byte for vendor ID clearly will not scale. There can easily = be more than 256 vendors our there who may eventually want to use this opti= on. I don't see any obvious way to do better space-wise than what we propos= ed with the OUI if we want this to be truly extensible to support all possi= ble vendors. I may be confused about what we expect will be the future developments in t= his space, but it's not obvious to me that we need to support more than 256= vendors. I suppose the key question here is what we mean by "eventually."= I thought this option-number reconciliation-and-rationalization was envisi= oned as a first step toward taking one (or a small number) of the "vendor" = codes and using them as a basis for a standardized discovery protocol. I'm= not meaning that this particular group should do it, and certainly not tha= t we should try to do it right now - but I did think that was a shared goal= for some point in the future. We currently have a handful of different proprietary discovery protocols th= at we are expecting to reconcile at the level of allowing them to multiplex= a single consistent option code. Do we really think that we'll have hundr= eds of additional discovery protocols between now and when there is agreeme= nt on some kind of open-standard discovery protocol(s)? I just don't see t= hat as a realistic concern, but perhaps I'm misunderstanding. --Mark --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6MAILBOXES2nbtte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Ron] A single byte for vendor ID clearly will not scale. There can easily be more = than 256 vendors our there who may eventually want to use this option. I don't s= ee any obvious way to do better space-wise than what we proposed with the OUI = if we want this to be truly extensible to support all possible vendors.=

 

I may be confused about what we expect will be the future developments in this space, but it’s not obvious to me that we need t= o support more than 256 vendors.  I suppose the key question here is wha= t we mean by “eventually.” I thought this option-number reconciliation-and-rationalization was envisioned as a first step toward ta= king one (or a small number) of the “vendor” codes and using them as= a basis for a standardized discovery protocol.  I’m not meaning that thi= s particular group should do it, and certainly not that we should try to do it right now= – but I did think that was a shared goal for some point in the future.

 

We currently have a handful of different proprietary discove= ry protocols that we are expecting to reconcile at the level of allowing them = to multiplex a single consistent option code.  Do we really think that we= ’ll have hundreds of additional discovery protocols between now and when there = is agreement on some kind of open-standard discovery protocol(s)?  I just= don’t see that as a realistic concern, but perhaps I’m misunderstanding.

 

--Mark

--_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6MAILBOXES2nbtte_-- From ron.frederick@bluecoat.com Thu May 27 09:43:47 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D993A698D for ; Thu, 27 May 2010 09:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM1hWNF3QfQH for ; Thu, 27 May 2010 09:43:46 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id E35B63A6B22 for ; Thu, 27 May 2010 09:43:45 -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 o4RGhamm019359; Thu, 27 May 2010 09:43:36 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 09:43:31 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-96-318667842 From: Ron Frederick In-Reply-To: Date: Thu, 27 May 2010 09:43:31 -0700 Message-Id: <93730462-B3C5-4ACA-8C0A-C69F52BF0822@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> To: Mark Day X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 27 May 2010 16:43:31.0357 (UTC) FILETIME=[BD8174D0:01CAFDBB] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 16:43:47 -0000 --Apple-Mail-96-318667842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 26, 2010, at 8:28 PM, Mark Day wrote: > [Ron] A single byte for vendor ID clearly will not scale. There can = easily be more than 256 vendors our there who may eventually want to use = this option. I don't see any obvious way to do better space-wise than = what we proposed with the OUI if we want this to be truly extensible to = support all possible vendors. > =20 > I may be confused about what we expect will be the future developments = in this space, but it=92s not obvious to me that we need to support more = than 256 vendors. I suppose the key question here is what we mean by = =93eventually.=94 I thought this option-number = reconciliation-and-rationalization was envisioned as a first step toward = taking one (or a small number) of the =93vendor=94 codes and using them = as a basis for a standardized discovery protocol. I=92m not meaning = that this particular group should do it, and certainly not that we = should try to do it right now =96 but I did think that was a shared goal = for some point in the future. > =20 > We currently have a handful of different proprietary discovery = protocols that we are expecting to reconcile at the level of allowing = them to multiplex a single consistent option code. Do we really think = that we=92ll have hundreds of additional discovery protocols between now = and when there is agreement on some kind of open-standard discovery = protocol(s)? I just don=92t see that as a realistic concern, but = perhaps I=92m misunderstanding. My expectation here is that this option will provide a standard way for = all of the current proprietary schemes to share a single TCP option, and = over time there will be specific use cases where middleboxes can = interoperate with one another and switch to one of the "public" type = codes which get defined within this framework, but there would continue = to be good reason to use vendor-specific codes for the foreseeable = future in addition to that. The reason I say this is that latency is of critical importance here, = and many uses of this option will involve at least some vendor-specific = information that needs to be exchanged during the discovery phase. = Solving the discovery problem alone won't be enough. We need to be able = to discover the other middlebox and communicate enough information = during that initial round-trip to begin whatever additional processing = the middleboxes need to perform. So, we'll be able to standardize the = framework for doing the discovery, but not the details of what appears = in the options which are exchanged, at least not for all of our current = use cases. 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. --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-96-318667842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 26, 2010, at 8:28 PM, Mark Day = wrote:

[Ron] A single byte for vendor ID clearly will not scale. = There can easily be more than 256 vendors our there who may eventually = want to use this option. I don't see any obvious way to do better = space-wise than what we proposed with the OUI if we want this to be = truly extensible to support all possible = vendors.
I may = be confused about what we expect will be the future developments in this = space, but it=92s not obvious to me that we need to support more than = 256 vendors.  I suppose the key question here is what we mean by = =93eventually.=94 I thought this option-number = reconciliation-and-rationalization was envisioned as a first step toward = taking one (or a small number) of the =93vendor=94 codes and using them = as a basis for a standardized discovery protocol.  I=92m not = meaning that this particular group should do it, and certainly not that = we should try to do it right now =96 but I did think that was a shared = goal for some point in the future.
 
We currently have a handful of different = proprietary discovery protocols that we are expecting to reconcile at = the level of allowing them to multiplex a single consistent option = code.  Do we really think that we=92ll have hundreds of additional = discovery protocols between now and when there is agreement on some kind = of open-standard discovery protocol(s)?  I just don=92t see that as = a realistic concern, but perhaps I=92m = misunderstanding.

My expectation here is that this option will provide a standard = way for all of the current proprietary schemes to share a single TCP = option, and over time there will be specific use cases where middleboxes = can interoperate with one another and switch to one of the "public" type = codes which get defined within this framework, but there would continue = to be good reason to use vendor-specific codes for the foreseeable = future in addition to that.

The reason I say this is = that latency is of critical importance here, and many uses of this = option will involve at least some vendor-specific information that needs = to be exchanged during the discovery phase. Solving the discovery = problem alone won't be enough. We need to be able to discover the other = middlebox and communicate enough information during that initial = round-trip to begin whatever additional processing the middleboxes need = to perform. So, we'll be able to standardize the framework for doing the = discovery, but not the details of what appears in the options which are = exchanged, at least not for all of our current use = cases.

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.
-- 
Ron = Frederick



= --Apple-Mail-96-318667842-- From wesley.m.eddy@nasa.gov Thu May 27 09:53:07 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C19B3A6B54 for ; Thu, 27 May 2010 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEoHsVUNSKkp for ; Thu, 27 May 2010 09:53:03 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id A366D3A6B36 for ; Thu, 27 May 2010 09:53:03 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7BAF2328413; Thu, 27 May 2010 11:52:54 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o4RGqsIH012912; Thu, 27 May 2010 11:52:54 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 27 May 2010 11:52:54 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Ron Frederick , Mark Day Date: Thu, 27 May 2010 11:52:52 -0500 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3Q 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> In-Reply-To: <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> 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=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-27_03:2010-02-06, 2010-05-27, 2010-05-27 signatures=0 Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 16:53:07 -0000 >-----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 From andrew.knutsen@bluecoat.com Thu May 27 10:18:44 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EE43A6B3C for ; Thu, 27 May 2010 10:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPTfe0xEnZiM for ; Thu, 27 May 2010 10:18:43 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 4F6613A6929 for ; Thu, 27 May 2010 10:18:43 -0700 (PDT) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o4RHIYLa025967; Thu, 27 May 2010 10:18:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 May 2010 10:18:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr9u8C5PzZv+lxUSb2/hIQcsVf6ZwABAXRm 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> From: "Knutsen, Andrew" To: "Ron Frederick" , "Mark Day" Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 17:18:44 -0000 Just clarifying something for Ron... =20 The single byte I'm proposing would be just the vendor. There would = probably be a type in the vendor-specific info. =20 Reserving a vendor code for a following OUI sounds good. Hopefully = never needed, since I hope all this is standardized before there are = that many players. =20 Andrew ________________________________ From: Ron Frederick [mailto:ronf@bluecoat.com] Sent: Thu 5/27/2010 9:43 AM To: Mark Day Cc: Knutsen, Andrew; middisc@ietf.org; Li, Qing Subject: Re: [middisc] TCP middlebox option requirements On May 26, 2010, at 8:28 PM, Mark Day wrote: =09 [Ron] A single byte for vendor ID clearly will not scale. There can = easily be more than 256 vendors our there who may eventually want to use = this option. I don't see any obvious way to do better space-wise than = what we proposed with the OUI if we want this to be truly extensible to = support all possible vendors. =20 I may be confused about what we expect will be the future developments = in this space, but it's not obvious to me that we need to support more = than 256 vendors. I suppose the key question here is what we mean by = "eventually." I thought this option-number = reconciliation-and-rationalization was envisioned as a first step toward = taking one (or a small number) of the "vendor" codes and using them as a = basis for a standardized discovery protocol. I'm not meaning that this = particular group should do it, and certainly not that we should try to = do it right now - but I did think that was a shared goal for some point = in the future. =20 We currently have a handful of different proprietary discovery = protocols that we are expecting to reconcile at the level of allowing = them to multiplex a single consistent option code. Do we really think = that we'll have hundreds of additional discovery protocols between now = and when there is agreement on some kind of open-standard discovery = protocol(s)? I just don't see that as a realistic concern, but perhaps = I'm misunderstanding. My expectation here is that this option will provide a standard way for = all of the current proprietary schemes to share a single TCP option, and = over time there will be specific use cases where middleboxes can = interoperate with one another and switch to one of the "public" type = codes which get defined within this framework, but there would continue = to be good reason to use vendor-specific codes for the foreseeable = future in addition to that.=20 The reason I say this is that latency is of critical importance here, = and many uses of this option will involve at least some vendor-specific = information that needs to be exchanged during the discovery phase. = Solving the discovery problem alone won't be enough. We need to be able = to discover the other middlebox and communicate enough information = during that initial round-trip to begin whatever additional processing = the middleboxes need to perform. So, we'll be able to standardize the = framework for doing the discovery, but not the details of what appears = in the options which are exchanged, at least not for all of our current = use cases. 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. --=20 Ron Frederick ronf@bluecoat.com From andrew.knutsen@bluecoat.com Thu May 27 12:59:44 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A693A67A6 for ; Thu, 27 May 2010 12:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9+ahIG5GyUe for ; Thu, 27 May 2010 12:59:43 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id AA73B3A6937 for ; Thu, 27 May 2010 12:59:43 -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 o4RJxYb9026724; Thu, 27 May 2010 12:59:34 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 12:59:28 -0700 Message-ID: <4BFECF20.5080200@bluecoat.com> Date: Thu, 27 May 2010 12:59:28 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 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: Content-Type: multipart/alternative; boundary="------------030404020006090505030505" X-OriginalArrivalTime: 27 May 2010 19:59:28.0950 (UTC) FILETIME=[1D93C560:01CAFDD7] Cc: "middisc@ietf.org" , Ron Frederick Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 19:59:44 -0000 This is a multi-part message in MIME format. --------------030404020006090505030505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One issue I just remembered with the OUI, and I can't remember who brought it up, is that it opens the option to "safe" (but unsanctioned) use for arbitrary purposes by anyone with an OUI. With vendor codes, we can specify criteria for assignment, so the vendor would be breaking their agreement if they used it for other purposes. It seems like this might be an IESG policy issue. Lars, are you still here? Andrew Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >> -----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 > --------------030404020006090505030505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    One issue I just remembered with the OUI, and I can't remember who brought it up, is that it opens the option to "safe" (but unsanctioned) use for arbitrary purposes by anyone with an OUI. With vendor codes, we can specify criteria for assignment, so the vendor would be breaking their agreement if they used it for other purposes.

    It seems like this might be an IESG policy issue.  Lars, are you still here?

Andrew

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: 
-----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

--------------030404020006090505030505-- From ron.frederick@bluecoat.com Thu May 27 14:43:46 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D712A3A6891 for ; Thu, 27 May 2010 14:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGuv-7FRYCXo for ; Thu, 27 May 2010 14:43:45 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 280463A6999 for ; Thu, 27 May 2010 14:43:45 -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 o4RLhZvB015707 for ; Thu, 27 May 2010 14:43:35 -0700 (PDT) Received: from ronfred.sv.bluecoat.com ([10.2.15.99]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 14:43:30 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-7-336665641 From: Ron Frederick In-Reply-To: Date: Thu, 27 May 2010 14:43:28 -0700 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> To: "Knutsen, Andrew" X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 27 May 2010 21:43:30.0332 (UTC) FILETIME=[A5BB15C0:01CAFDE5] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 21:43:47 -0000 --Apple-Mail-7-336665641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 27, 2010, at 10:18 AM, Knutsen, Andrew wrote: > Just clarifying something for Ron... > =20 > The single byte I'm proposing would be just the vendor. There would = probably be a type in the vendor-specific info. > =20 > Reserving a vendor code for a following OUI sounds good. Hopefully = never needed, since I hope all this is standardized before there are = that many players. This runs the risk of creating two tiers of vendors (those who get in = early and get one-byte assignments and those who don't and are forced to = use the OUI escape hatch vendor ID). However, I agree that this would be = one way to save space. If we assume that there's still a vendor-specific = type code and we pack both the request/response flag and the type into a = single byte rather than two bytes, we could basically save 3 bytes = total. This would give us 254 vendors if we keep one vendor value for = standard options and one for the OUI escape. Each vendor could have 127 = options if they used the 'R' bit. Vendors would also be free to exclude = the type code if they only wanted a single option, exclude the 'R' bit = if they didn't need that, or even go up to a multi-byte type code if = they needed more space (unlikely, I admit). The main question is how = this vendor registration will be handled (see more below on this). I'm also not sure I like the idea of trying to mix both vendor codes and = standard option type codes into the same byte. While that would be a = further 1 byte space savings for the standard options, that really seems = to be overloading that single field too much. Andrew also wrote: > One issue I just remembered with the OUI, and I can't remember who = brought it up, is that it opens the option to "safe" (but unsanctioned) = use for arbitrary purposes by anyone with an OUI. With vendor codes, we = can specify criteria for assignment, so the vendor would be breaking = their agreement if they used it for other purposes. >=20 > It seems like this might be an IESG policy issue. Lars, are you still = here? Who would perform this oversight? This gets into the points Anantha was = raising: > OUI as exists today is standardized and managed and provides = unquiness. If we were to define a 1 byte vendor it, it has all issues = which Ron mentioned below + the need for standardizing that space, I = don't know who is going to manage allocation and maintenance of that = field. I don't think IANA would do that. I could potentially see IANA handling the registrations here, but I = wouldn't expect them to be able to handle the approvals or do any = checking on whether vendors were "breaking their agreement" in the way = they used the option. To be honest, I'm not even sure I know what that = means. What sort of criteria would we be looking for here? This doesn't = seem like something we necessarily want to burden this process with. Anantha also asked: > I also wanted to understand the use case of having this option sent in = the middle of the connection. FWIW TCP options as exisits today are = either "negotiated" one time in the initial 3 way handshake (MSS, Window = scale, SACK permitted etc.,) or sent on every packet (TCP MD5, = TIMESTAMP etc.,) On demand sendind of the option is something new, so is = the concept of variable length TCP option (with the exception of SACK, = which itself needs to agreed upon using SACK PERMITTED option during the = 3 way HS. Variable length options are nothing new. With the exception of the kind = 0 & 1 single octet options representing the end of list and no-op, all = TCP options have a "kind" byte and a "length" byte. While most options = may happen to be a fixed length today, the length byte should allow us = to support a variable length option with no additional effort. Regarding sending options in the middle of a stream, I must admit that = I'm still nervous about that, especially around how the middleboxes = doing this will handle retransmissions of data packets originally sent = with the option. However, I can see legitimate use cases for doing this, = and I can see how an implementation could work if the options were just = treated as essentially best-effort delivery with it being up to the = specific middlebox implementation to handle any reliability concerns = when sending such mid-stream options. --=20 Ron Frederick ronf@bluecoat.com --Apple-Mail-7-336665641 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Just = clarifying something for Ron...
 
The single byte I'm = proposing would be just the vendor.  There would probably be a type = in the vendor-specific info.
 
Reserving a vendor code = for a following OUI sounds good.  Hopefully never needed, since I = hope all this is standardized before there are that many = players.

This runs = the risk of creating two tiers of vendors (those who get in early and = get one-byte assignments and those who don't and are forced to use the = OUI escape hatch vendor ID). However, I agree that this would be one way = to save space. If we assume that there's still a vendor-specific type = code and we pack both the request/response flag and the type into a = single byte rather than two bytes, we could basically save 3 bytes = total. This would give us 254 vendors if we keep one vendor value for = standard options and one for the OUI escape. Each vendor could have 127 = options if they used the 'R' bit. Vendors would also be free to exclude = the type code if they only wanted a single option, exclude the 'R' bit = if they didn't need that, or even go up to a multi-byte type code if = they needed more space (unlikely, I admit). The main question is how = this vendor registration will be handled (see more below on = this).

I'm also not sure I like the idea of = trying to mix both vendor codes and standard option type codes into the = same byte. While that would be a further 1 byte space savings for the = standard options, that really seems to be overloading that single field = too much.

Andrew also wrote:
One issue I just remembered with the OUI, and I can't = remember who brought it up, is that it opens the option to "safe" (but = unsanctioned) use for arbitrary purposes by anyone with an OUI. With = vendor codes, we can specify criteria for assignment, so the vendor = would be breaking their agreement if they used it for other = purposes.

It seems like this might be an IESG policy issue.  = Lars, are you still here?

Who = would perform this oversight? This gets into the points Anantha was = raising:

OUI as exists = today is standardized and managed and provides unquiness. If we were to = define a 1 byte vendor it, it has all issues which Ron mentioned below + = the need for standardizing that space, I don't know who is going to = manage allocation and maintenance of that field. I don't think IANA = would do that.

I could = potentially see IANA handling the registrations here, but I wouldn't = expect them to be able to handle the approvals or do any checking on = whether vendors were "breaking their agreement" in the way they used the = option. To be honest, I'm not even sure I know what that means. What = sort of criteria would we be looking for here? This doesn't seem like = something we necessarily want to burden this process = with.

Anantha also asked:
I also wanted to = understand the use case of having this option sent in the middle of the = connection. FWIW TCP options as exisits today are either "negotiated" = one time in the initial 3 way handshake (MSS, Window scale, SACK = permitted etc.,) or sent on every packet (TCP MD5,  TIMESTAMP = etc.,) On demand sendind of the option is something new, so is the = concept of variable length TCP option (with the exception of SACK, which = itself needs to agreed upon using SACK PERMITTED option during the 3 way = HS.

Variable length options are = nothing new. With the exception of the kind 0 & 1 single octet = options representing the end of list and no-op, all TCP options have a = "kind" byte and a "length" byte. While most options may happen to be a = fixed length today, the length byte should allow us to support a = variable length option with no additional = effort.

Regarding sending options in the middle = of a stream, I must admit that I'm still nervous about that, especially = around how the middleboxes doing this will handle retransmissions of = data packets originally sent with the option. However, I can see = legitimate use cases for doing this, and I can see how an implementation = could work if the options were just treated as essentially best-effort = delivery with it being up to the specific middlebox implementation to = handle any reliability concerns when sending such mid-stream = options.
-- 
Ron = Frederick



= --Apple-Mail-7-336665641-- From andrew.knutsen@bluecoat.com Thu May 27 15:31:39 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015E43A6BDD for ; Thu, 27 May 2010 15:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trn4KHWbARPw for ; Thu, 27 May 2010 15:31:37 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id C7C7A3A6A1D for ; Thu, 27 May 2010 15:29:42 -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 o4RMTMJp022850 for ; Thu, 27 May 2010 15:29:22 -0700 (PDT) Received: from [10.9.84.250] ([10.9.84.250]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 15:29:17 -0700 Message-ID: <4BFEF23D.5060005@bluecoat.com> Date: Thu, 27 May 2010 15:29:17 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ron Frederick 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: Content-Type: multipart/alternative; boundary="------------070107070500060800070806" X-OriginalArrivalTime: 27 May 2010 22:29:17.0033 (UTC) FILETIME=[0AE46590:01CAFDEC] Cc: middisc@ietf.org Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 27 May 2010 22:31:39 -0000 This is a multi-part message in MIME format. --------------070107070500060800070806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ron Frederick wrote: > Andrew also wrote: >> One issue I just remembered with the OUI, and I can't remember who >> brought it up, is that it opens the option to "safe" (but >> unsanctioned) use for arbitrary purposes by anyone with an OUI. With >> vendor codes, we can specify criteria for assignment, so the vendor >> would be breaking their agreement if they used it for other purposes. >> >> It seems like this might be an IESG policy issue. Lars, are you >> still here? > > Who would perform this oversight? This gets into the points Anantha > was raising: > >> OUI as exists today is standardized and managed and provides >> unquiness. If we were to define a 1 byte vendor it, it has all issues >> which Ron mentioned below + the need for standardizing that space, I >> don't know who is going to manage allocation and maintenance of that >> field. I don't think IANA would do that. > > I could potentially see IANA handling the registrations here, but I > wouldn't expect them to be able to handle the approvals or do any > checking on whether vendors were "breaking their agreement" in the way > they used the option. To be honest, I'm not even sure I know what that > means. What sort of criteria would we be looking for here? This > doesn't seem like something we necessarily want to burden this process > with. What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose. Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement. No police (unless you count the vendor itself), just peer pressure, so to speak. Of, course, if we went with the OUI, the owner of that OUI would be responsible for breaking the spec if the option was used inappropriately. However I've picked up concerns that we need a bit more accountability. Andrew --------------070107070500060800070806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ron Frederick wrote:
Andrew also wrote:
One issue I just remembered with the OUI, and I can't remember who brought it up, is that it opens the option to "safe" (but unsanctioned) use for arbitrary purposes by anyone with an OUI. With vendor codes, we can specify criteria for assignment, so the vendor would be breaking their agreement if they used it for other purposes.

It seems like this might be an IESG policy issue.  Lars, are you still here?

Who would perform this oversight? This gets into the points Anantha was raising:

OUI as exists today is standardized and managed and provides unquiness. If we were to define a 1 byte vendor it, it has all issues which Ron mentioned below + the need for standardizing that space, I don't know who is going to manage allocation and maintenance of that field. I don't think IANA would do that.

I could potentially see IANA handling the registrations here, but I wouldn't expect them to be able to handle the approvals or do any checking on whether vendors were "breaking their agreement" in the way they used the option. To be honest, I'm not even sure I know what that means. What sort of criteria would we be looking for here? This doesn't seem like something we necessarily want to burden this process with.

    What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose.  Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement.  No police (unless you count the vendor itself), just peer pressure, so to speak.

    Of, course, if we went with the OUI, the owner of that OUI would be responsible for breaking the spec if the option was used inappropriately. However I've picked up concerns that we need a bit more accountability.

Andrew

--------------070107070500060800070806-- From Mark.Day@riverbed.com Fri May 28 09:18:55 2010 Return-Path: X-Original-To: middisc@core3.amsl.com Delivered-To: middisc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB9D3A6A44 for ; Fri, 28 May 2010 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.476 X-Spam-Level: * X-Spam-Status: No, score=1.476 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QDexOsiCCX7 for ; Fri, 28 May 2010 09:18:50 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by core3.amsl.com (Postfix) with ESMTP id 4FD263A6A3A for ; Fri, 28 May 2010 09:18:50 -0700 (PDT) Received: from unknown (HELO exhub2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 28 May 2010 09:18:40 -0700 Received: from mailboxes2.nbttech.com ([fe80:0000:0000:0000:99bf:a4d0:243.141.8.211]) by exhub2.nbttech.com ([10.16.0.165]) with mapi; Fri, 28 May 2010 09:18:40 -0700 From: Mark Day To: Ron Frederick , "Knutsen, Andrew" Date: Fri, 28 May 2010 09:17:46 -0700 Thread-Topic: [middisc] TCP middlebox option requirements Thread-Index: Acr95bMQ0YGqutSLTRWeFG1mRRrlIAAltGBw 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> In-Reply-To: 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_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D7B9MAILBOXES2nbtte_" MIME-Version: 1.0 Cc: "middisc@ietf.org" Subject: Re: [middisc] TCP middlebox option requirements X-BeenThere: middisc@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 28 May 2010 16:18:55 -0000 --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D7B9MAILBOXES2nbtte_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding sending options in the middle of a stream, I must admit that I'm = still nervous about that, especially around how the middleboxes doing this = will handle retransmissions of data packets originally sent with the option= . However, I can see legitimate use cases for doing this, and I can see how= an implementation could work if the options were just treated as essential= ly best-effort delivery with it being up to the specific middlebox implemen= tation to handle any reliability concerns when sending such mid-stream opti= ons. I may have inadvertently created this concern, and if so I'd like to clarif= y my position to see if we can get it off the table. I objected to the requirement for restriction of options to headers with th= e SYN bit set, since Riverbed products do use options in other cases. Howe= ver, I don't believe there is any case in which we start adding options in = the middle of a stream. Sometimes an option appears only on a few packets = at the start of a stream and is no longer used after some number of exchang= es; in other cases, an option is used for the entire duration of a connecti= on. I don't believe that we have any need for an option to suddenly appear = midstream on a flow that did not previously use it. As is correctly noted, it would not be reasonable to assume that a packet w= ith a newly-added option will still be able to reach the destination, since= something along the route may suppress it. If the middlebox had added a ne= w option and was not receiving acks from the other side, it's not clear wha= t the right behavior would be. When I think it through a little, all of the= choices seem problematic. It seems like a whole can of worms that is best = avoided. --Mark --_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D7B9MAILBOXES2nbtte_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding sending options i= n the middle of a stream, I must admit that I'm still nervous about that, especia= lly around how the middleboxes doing this will handle retransmissions of data packets originally sent with the option. However, I can see legitimate use cases for doing this, and I can see how an implementation could work if the options were just treated as essentially best-effort delivery with it being= up to the specific middlebox implementation to handle any reliability concerns when sending such mid-stream options.

 

I may have inadvertently created this concern, and if so I&#= 8217;d like to clarify my position to see if we can get it off the table.

 

I objected to the requirement for restriction of options to = headers with the SYN bit set, since Riverbed products do use options in other cases.  However, I don’t believe there is any case in which we s= tart adding options in the middle of a stream.  Sometimes an option appears only on a few packets at the start of a stream and is no longer used after = some number of exchanges; in other cases, an option is used for the entire durat= ion of a connection. I don’t believe that we have any need for an option = to suddenly appear midstream on a flow that did not previously use it.

 

As is correctly noted, it would not be reasonable to assume = that a packet with a newly-added option will still be able to reach the destinat= ion, since something along the route may suppress it. If the middlebox had added= a new option and was not receiving acks from the other side, it’s not c= lear what the right behavior would be. When I think it through a little, all of = the choices seem problematic. It seems like a whole can of worms that is best avoided.

 =

--Mark

--_000_AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D7B9MAILBOXES2nbtte_--