Re: [middisc] middisc specification update

"Frederick, Ron" <ron.frederick@bluecoat.com> Wed, 07 March 2012 03:22 UTC

Return-Path: <ron.frederick@bluecoat.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 A8A8B21E8039 for <middisc@ietfa.amsl.com>; Tue, 6 Mar 2012 19:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 fS9xfisFpN1l for <middisc@ietfa.amsl.com>; Tue, 6 Mar 2012 19:22:38 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 175C921E8013 for <middisc@ietf.org>; Tue, 6 Mar 2012 19:22:38 -0800 (PST)
Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id q273MZQI008396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Mar 2012 19:22:35 -0800 (PST)
Received: from PWSVL-EXCMBX-03.internal.cacheflow.com ([fe80::f1c6:61a6:35aa:6971]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 6 Mar 2012 19:22:29 -0800
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [middisc] middisc specification update
Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgA==
Date: Wed, 07 Mar 2012 03:22:29 +0000
Message-ID: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com>
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>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.2.106]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <83872CCB0080B748B9B2212E30E581F9@bluecoat.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "middisc@ietf.org" <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 03:22:38 -0000

On Mar 5, 2012, at 10:56 AM, Anantha Ramaiah (ananth) wrote:
>> -----Original Message-----
>> From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> [mailto:wesley.m.eddy@nasa.gov]
>> Sent: Monday, March 05, 2012 10:42 AM
>> To: Anantha Ramaiah (ananth); David Harrington; Wesley Eddy;
>> middisc@ietf.org
>> Subject: RE: [middisc] middisc specification update
>> 
>> Thanks for posting the draft.
>> 
>> The intention is to handle this as an AD-sponsored document,
>> not via an IETF working group.
>> 
>> No presentation is needed.
>> 
>> When all of the authors have agreed on it and consider it to
> 
> From my point of view, I am done. Other stakeholders also have reviewed
> this document and they seem ok with it (as far as I can tell).  They can
> comment in any case.

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

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

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

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

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