Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

Joe Touch <touch@isi.edu> Thu, 16 February 2017 23:52 UTC

Return-Path: <touch@isi.edu>
X-Original-To: nvo3-dt-encap@ietfa.amsl.com
Delivered-To: nvo3-dt-encap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FBF1293EE; Thu, 16 Feb 2017 15:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVfWwG6rrnot; Thu, 16 Feb 2017 15:52:48 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14FF1293DA; Thu, 16 Feb 2017 15:52:48 -0800 (PST)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GNqPCU013216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 15:52:25 -0800 (PST)
To: Tom Herbert <tom@herbertland.com>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com> <CALx6S37AeS8QEtm1SJsFe9dAnEoCdPZodPJyr7jfYxxEnM040g@mail.gmail.com> <F80D14D0-57B0-4768-9405-4AF99526E439@vmware.com> <CALx6S35eYxWXCK3TsESedJ8g3zQDWHYyyJXObAJ4VMnC9Q1aQQ@mail.gmail.com> <65CC369B-CB65-40FC-8F7E-A805B554B8FD@vmware.com> <CALx6S34oFSkQ_bL=ike_5UNxk5P3UpB2cW0F4WSz=Vp0DotLZQ@mail.gmail.com> <53f0c27c-22c0-4ce9-d05b-6de44e6aa97d@isi.edu> <CALx6S35HKupQ+vOa9HqraeOEgo9M+zGtOs4SHsuOEoVoYCV=bA@mail.gmail.com> <b2dec453-46ed-3602-4c0e-92e8e3b1f3cb@isi.edu> <CALx6S36XqDYQYChewVPN5KXLFGVvYgvT7KoYhAwgo+MBcSh9ow@mail.gmail.com> <43e548d6-45c4-bcfc-a295-120f5f5940de@isi.edu> <CALx6S36BO-+MQqKBDG8h=KDL-mDd_6TXneL3Hf+4hHeKQkKhUg@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <ca3c0a43-4610-5b28-5825-6be74fa41fb8@isi.edu>
Date: Thu, 16 Feb 2017 15:52:23 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CALx6S36BO-+MQqKBDG8h=KDL-mDd_6TXneL3Hf+4hHeKQkKhUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/1MIlC6z0KYlrtKYqh25E2ccK-hg>
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, Sami Boutros <sboutros@vmware.com>, "nvo3-dt-encap@ietf.org" <nvo3-dt-encap@ietf.org>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-BeenThere: nvo3-dt-encap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <nvo3-dt-encap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3-dt-encap/>
List-Post: <mailto:nvo3-dt-encap@ietf.org>
List-Help: <mailto:nvo3-dt-encap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 23:52:50 -0000


On 2/16/2017 3:45 PM, Tom Herbert wrote:
> On Thu, Feb 16, 2017 at 3:30 PM, Joe Touch <touch@isi.edu> wrote:
>>
>> On 2/16/2017 3:26 PM, Tom Herbert wrote:
>>> Admittedly, without any actual TLVs defined in Geneve all of this is
>>> all just speculation on my part!
>>>
>>> Tom
>> Agreed, and more specifically, regardless of the flexibility of TLVs in
>> general, if the negotiation protocol specifies a fixed set of them, each
>> with fixed, known length, then even though the TLV allows flexibility in
>> what COULD appear, a given pair of endpoints can rely on a fixed set
>> that is easy to parse in parallel.
>>
> Sure, if you require protocol negotiation to precede use of the
> dataplane then not only can we define the required order of TLVs, but
> we can also define the allowable set of TLVs that each side can send.
> The concept of having ignorable TLVs could just go away (that is a
> good thing IMO). Option negotiation is probably one of things that
> mades TCP options deployable and avoids the concept of ignoring
> options after negotiation.
>
> But, as I said this idea creates a new dependency on a control plane
> which is TBD. I'm afraid this could be a opening a Pandora's box of
> new complexity that the group didn't bargain for...
You need a control plane to setup the endpoints of a tunnel anyway.
Indicating a fixed set of features for that tunnel is as easy as "use
Bob", where "Bob" is defined elsewhere.

Joe