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

Joe Touch <touch@isi.edu> Fri, 17 February 2017 18:00 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 9AB8B129B01; Fri, 17 Feb 2017 10:00:37 -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 2fRXVbOOIL7E; Fri, 17 Feb 2017 10:00:36 -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 9AD00129633; Fri, 17 Feb 2017 10:00:36 -0800 (PST)
Received: from [128.9.184.202] ([128.9.184.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1HHtmGf025629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Feb 2017 09:55:48 -0800 (PST)
To: Tom Herbert <tom@herbertland.com>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@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> <ca3c0a43-4610-5b28-5825-6be74fa41fb8@isi.edu> <CALx6S36tXtGSXpbfzj7pJGiObLaxOhVVQsRfBw1--h1wu=YKgA@mail.gmail.com> <0b6e2d43-dbd1-8024-7d4e-c8863e079037@isi.edu> <CALx6S35zcTWmKbkCbzY2kxi+fa=YceTPoxhGdtzL+btjmAugOw@mail.gmail.com> <CALx6S37_j+4j5jEKaWPn6fRTwNDdQqquS_BOUe8TpOhzE7JNBw@mail.gmail.com> <86188559-031F-4AE2-AAD3-2FF618DE8D45@isi.edu> <CALx6S34Ns6zdxJxZViNLhPbz-w39RzPfGqOPF3g1recyYThE-Q@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <cb85a4eb-8187-910a-1d35-4f726340d722@isi.edu>
Date: Fri, 17 Feb 2017 09:55:47 -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: <CALx6S34Ns6zdxJxZViNLhPbz-w39RzPfGqOPF3g1recyYThE-Q@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/tNCksWJ99vwOsd72i42T8p7FKRw>
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: Fri, 17 Feb 2017 18:00:37 -0000


On 2/17/2017 9:04 AM, Tom Herbert wrote:
> But again, we don't have any examples of a protocol with ordered TLVs
> that does this and there is no concrete proposal for doing this in
> Geneve so this idea is just speculation.
Ordered TLVs are the same thing as bitfields in known orders. The only
difference is whether the protocol allows the flexibility, in alternate
configurations, of supporting alternate fields in alternate orders.

However, the larger issue here is that the doc assumes a requirement for
efficient support in current hardware.

Joe