Re: [middisc] middisc specification update

"Frederick, Ron" <ron.frederick@bluecoat.com> Thu, 08 March 2012 20:34 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 6D72821E8051 for <middisc@ietfa.amsl.com>; Thu, 8 Mar 2012 12:34:20 -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 JO1hwhR+ROp2 for <middisc@ietfa.amsl.com>; Thu, 8 Mar 2012 12:34:19 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id B225A21E8050 for <middisc@ietf.org>; Thu, 8 Mar 2012 12:34:19 -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 q28KYFBC025643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Mar 2012 12:34:16 -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; Thu, 8 Mar 2012 12:34:15 -0800
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [middisc] middisc specification update
Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAEsLsQAADcGhoP//rcCA
Date: Thu, 08 Mar 2012 20:34:15 +0000
Message-ID: <F94386BF-D99B-4CD7-A7D9-2C2D11859928@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> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> <C06D0C27-D8F1-4847-BB0A-A1EBF458A55E@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EAB248A@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580EAB248A@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: <17D99CF23A3FA04683055456F2B19578@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: Thu, 08 Mar 2012 20:34:20 -0000

On Mar 8, 2012, at 12:26 PM, Anantha Ramaiah (ananth) wrote:
>>> Allow standard type codes to be allocated starting with 0x00 in an
>> increasing fashion and allow vendor codes to be allocated starting with
>> 0xFE in a decreasing fashion. At some point, if it looks like too many
>> vendor codes are being allocated, IANA can declare that no more are
>> available and that additional vendors must use the 0xFF form with an
>> OUI, leaving the remainder of the space for standard type codes.
>> 
>> What do others think of this?
> 
> Question : when you say vendor code, are you saying one vendor can get
> multiple vendor codes? Or is strictly one per vendor. I assumed the
> latter.

In cases where a vendor wants their own vendor code, my thinking was that they only get one. If they need multiple middlebox option types, they would have to distinguish them using some other bits in the vendor-specific payload. If they didn't make provisions in advance for that, they'd have to either adjust their payload format later to add it, or have their additional options use the 0xFF+OUI version of the header.

> When you say "standard type", what are those? Are those the ones used by
> multiple vendors and really interoperable?
> 
> Just wanted to make sure we both are on the same page w.r.t terminology.

Yes - the notion would be that we could standardize certain payload types which could be used to interoperate between vendors. These would have RFCs associated with them, and they would be assigned a type code by IANA which would come out of the same space as the vendor codes. To keep them organized, though, the standard type codes would be assigned counting up from 0x00 and the vendor codes would be assigned counting down from 0xFE (with 0xFF reserved for longer vendor codes).
-- 
Ron Frederick
ronf@bluecoat.com