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