IETF Logo Mail Archive

Re: [middisc] TCP middlebox option requirements

"Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <wesley.m.eddy@nasa.gov> Thu, 27 May 2010 16:53 UTC

Return-Path: <wesley.m.eddy@nasa.gov>
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 <middisc@core3.amsl.com>; 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 <middisc@core3.amsl.com>; 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 <middisc@ietf.org>; 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]" <wesley.m.eddy@nasa.gov>
To: Ron Frederick <ronf@bluecoat.com>, Mark Day <Mark.Day@riverbed.com>
Date: Thu, 27 May 2010 11:52:52 -0500
Thread-Topic: [middisc] TCP middlebox option requirements
Thread-Index: Acr9u8KhAqzztGtOS7Ogy2U9es0MEAAAJd3Q
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB47E64A333F@NDJSSCC01.ndc.nasa.gov>
References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADAB3597@MAILBOXES2.nbttech.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6@MAILBOXES2.nbttech.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" <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." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: 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

v2.23.0 | Report a Bug | By Email