Re: [middisc] middisc specification update
"Anantha Ramaiah (ananth)" <ananth@cisco.com> Wed, 07 March 2012 07:55 UTC
Return-Path: <ananth@cisco.com>
X-Original-To: middisc@ietfa.amsl.com
Delivered-To: middisc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0607D21E8094 for <middisc@ietfa.amsl.com>; Tue, 6 Mar 2012 23:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.659
X-Spam-Level:
X-Spam-Status: No, score=-9.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltifBYYLYAG8 for <middisc@ietfa.amsl.com>; Tue, 6 Mar 2012 23:55:31 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6B21E8091 for <middisc@ietf.org>; Tue, 6 Mar 2012 23:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3358; q=dns/txt; s=iport; t=1331106928; x=1332316528; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=R2imJhRnvtPJaQM9JDW8sypjpkwzSRch4dOLlGyynCA=; b=h40QSWVor0VfjQr0bfuM5LEo2vCSVVXF4GAZMRgkvwWsDn7c4F2yRr/e 3nlPMkNpI4xpS1tzfmV0t8mniwKZL5HE0h+vBSYg15syC1rkTJ2hfL5c2 wxUpl5JCqj+mXHSYizvv5p0bZ6soS30jH/59x5UrmJbNrybVQMuc681am s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAEMTV0+rRDoJ/2dsb2JhbABDtQyBB4F9AQEBAwESAR0KPwULAgEIIgYYBgFWAgQTCBqHYASadgGfEZANYwSIUp0DgwQ
X-IronPort-AV: E=Sophos;i="4.73,544,1325462400"; d="scan'208";a="32333034"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Mar 2012 07:55:28 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q277tSXS008425; Wed, 7 Mar 2012 07:55:28 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 23:55:28 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Mar 2012 23:55:23 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [middisc] middisc specification update
Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFA
References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <C304DB494AC0C04C87C6A6E2FF5603DB5ACE4EFBB5@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Frederick, Ron" <ron.frederick@bluecoat.com>
X-OriginalArrivalTime: 07 Mar 2012 07:55:28.0455 (UTC) FILETIME=[A987C570:01CCFC37]
Cc: middisc@ietf.org
Subject: Re: [middisc] middisc specification update
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/middisc>, <mailto:middisc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/middisc>
List-Post: <mailto:middisc@ietf.org>
List-Help: <mailto:middisc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2012 07:55:32 -0000
Hi Ron, <snip> > I'm generally good with the latest draft, but there are a few items > that I think we need to address: > > 1) I think it would be good to rename the option to make it clear that > it can be used for more than just discovery. The text already describes > being able to use the option to provide information to other > middleboxes on the path. I think we just need to emphasize that a bit > more and make it clear that discovery is only one potential use for the > option. Yes, I had proposed this long time back but somehow did not hear an explicit support. Ok, how about naming the draft as "TCP middlebox option" and the current use case is about middlebox discovery. There are handful of vendors doing WAN optimization today and a 255 byte vendor code is a whole lot. Hence if we make this option generic looking, other use cases can be handled as well. I need to make one thing clear : it is the not the intention of the draft to encourage middlebox insertions and uses, just to make this option extensible, so that at the discretion of IETF if there exists a strong use case tomorrow, this option can come to rescue. > > 2) The current text explicitly discourages end hosts from participating > in this exchange. I think that's a mistake. In some cases, a "soft" > implementation of a middlebox could run directly on a client or a > server, and it would want to be able to interoperate with other > physical middleboxes that expect to see this option. We want to be able > to support that use case by allowing the soft middlebox on one of the > end hosts to add or respond to this option. Middlebox can run inside the host as well, I guess middlebox definition is something that sits in the middle of the connection, if you run something that snoops on selected connections and does something to the TCP traffic it is still a middlebox. Maybe can note this in the terminology section. > > 3) I'm good with supporting the single byte vendor code with vendor- > specific payload data after it, but I think we should at least leave > some provision in there for the other two cases we previously discussed > of standard type codes and an escape of some kind for a longer vendor > code if we're wrong about the adoption of this and we run out of space > in the single byte. Fair enough. We can note that some vendor codes are going to be reserved (FF to F0). These can be used to extend as needed tomorrow. Would that address your concern? > > I think we can address #2 here by reserving vendor code 0xFF for an You mean #3 above ? > extended vendor code that could be based on something like an OUI. If > that's too big, we could also do something like say that setting the > high-bit in the vendor code expands it to 16 bits. So, the first 128 > vendor codes are one byte, and then we get another ~32K of them which > are two bytes. Well, I am happy with reserving some extended vendor codes for future extension. I think envisioning a 32 bit vendor code at this point seems very dubious to me at best. I also think we can use your MSB trick above to separate vendor codes from other codes if there is a need to have this option used for some other cases like NAT reveal etc., Thanks, Anantha > -- > Ron Frederick > ronf@bluecoat.com
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- [middisc] middisc specification update Wesley Eddy
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update David Harrington
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Andrew Knutsen
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Andrew Knutsen
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Eggert, Lars
- Re: [middisc] middisc specification update Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Frederick, Ron
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Eggert, Lars
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Mani Ramasamy (mani)
- Re: [middisc] middisc specification update David Harrington
- Re: [middisc] middisc specification update Frederick, Ron
- Re: [middisc] middisc specification update Andrew Knutsen
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)
- Re: [middisc] middisc specification update Frederick, Ron
- Re: [middisc] middisc specification update Wesley Eddy
- Re: [middisc] middisc specification update Knutsen, Andrew
- Re: [middisc] middisc specification update Anantha Ramaiah (ananth)