Re: [middisc] middisc specification update

Andrew Knutsen <andrew.knutsen@bluecoat.com> Thu, 08 March 2012 19:29 UTC

Return-Path: <andrew.knutsen@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 6FC8521E801B for <middisc@ietfa.amsl.com>; Thu, 8 Mar 2012 11:29:30 -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 s0uVFUulPXtq for <middisc@ietfa.amsl.com>; Thu, 8 Mar 2012 11:29:29 -0800 (PST)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2221E8019 for <middisc@ietf.org>; Thu, 8 Mar 2012 11:29:29 -0800 (PST)
Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id q28JTRkr002000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Mar 2012 11:29:27 -0800 (PST)
Received: from [10.9.43.134] (10.2.2.106) by exchange.bluecoat.com (10.2.2.122) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 8 Mar 2012 11:29:22 -0800
Message-ID: <4F590892.5030701@bluecoat.com>
Date: Thu, 08 Mar 2012 11:29:22 -0800
From: Andrew Knutsen <andrew.knutsen@bluecoat.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "middisc@ietf.org" <middisc@ietf.org>
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>
In-Reply-To: <C06D0C27-D8F1-4847-BB0A-A1EBF458A55E@bluecoat.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Frederick, Ron" <ron.frederick@bluecoat.com>
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 19:29:30 -0000

    I like the idea of assigning vendor codes from one end and standard 
codes from the other, with one code reserved for future expansion.  I 
also like the idea of not specifying the expansion mechanism; that can 
wait until more requirements are known.

Andrew

On 3/8/2012 10:54 AM, Frederick, Ron wrote:
> On Mar 6, 2012, at 11:55 PM, Anantha Ramaiah (ananth) wrote:
>>> 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.
> I was thinking of something like "TCP middlebox negotiation option". It's more general than discovery, but it's still getting at the core use cases here which I think are all related to the middleboxes both discovering each other and negotiating a set of transformations they want to apply to the data stream.
>
>>> 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.
> That seems like a reasonable way of looking at it. If this can be clarified in the text, that should cover my objection.
>
>>> 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?
> Given the previous discussion we had on the list of not wanting to use more than one byte for "standard" type codes, I'm not sure that reserving a small range of vendor codes is quite enough here. Originally, I had proposed reserving only 0x00 for standard types and 0xff for extended vendor codes, but that wasn't accepted by the group.
>
>>> I think we can address #2 here by reserving vendor code 0xFF for an
>> You mean #3 above ?
> Yes, sorry - I did. I edited my list of points while composing the mail and forgot to update this reference. :)
>
>>> 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.,
> The OUI would be 24 bits, but with the 0xFF I guess that would turn into 32 bits total. The other option here would be to use the IANA private enterprise number, but I think that's allowed to be up to 32 bits in length (though IANA has only assigned around 40,000 of them so far).
>
> I'm good with reserving 0xFF for extended vendor codes without specifying the rest of the mechanism here, but that still leaves open the question about how we want to make room for standard middlebox message types. As David Harrington pointed out, we should be trying to encourage this, so we should have a good story for how such cases can use this option. Previously I suggested the following:
>
>> 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?