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

Joe Touch <touch@isi.edu> Fri, 17 February 2017 06:57 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 D545D1293F0; Thu, 16 Feb 2017 22:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 X2vrFb5u9W5E; Thu, 16 Feb 2017 22:57:48 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 82D83128874; Thu, 16 Feb 2017 22:57:48 -0800 (PST)
Received: from [192.168.1.158] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1H6vVG3015216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Feb 2017 22:57:33 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@isi.edu>
X-Mailer: iPad Mail (14D27)
In-Reply-To: <CALx6S37_j+4j5jEKaWPn6fRTwNDdQqquS_BOUe8TpOhzE7JNBw@mail.gmail.com>
Date: Thu, 16 Feb 2017 22:57:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <86188559-031F-4AE2-AAD3-2FF618DE8D45@isi.edu>
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> <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> <c827d88a-3e79-114f-0! 111-0d0528adf744@isi.edu> <CALx6S37_j+4j5jEKaWPn6fRTwNDdQqquS_BOUe8TpOhzE7JNBw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-MailScanner-ID: v1H6vVG3015216
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/-h7aCR5aH8-q2QnwZ3UUnjyJQvQ>
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 06:57:50 -0000


> On Feb 16, 2017, at 6:17 PM, Tom Herbert <tom@herbertland.com> wrote:
> 
>> On Thu, Feb 16, 2017 at 4:48 PM, Joe Touch <touch@isi.edu> wrote:
>> 
>> 
>>> On 2/16/2017 4:39 PM, Tom Herbert wrote:
>>> The operational issues we see with TLVs in terms of performance and
>>> DDOS are not aberrations, they are fundamental issues we face in
>>> deployment.
>> Agreed, in the case where TLV sets are not fixed for a given path. The
>> same is also true for bitfields: Ethernet uses a different Ethertypes
>> for IPv4 and IPv6, even though they're intended to be treated as a
>> single protocol class with internal versioning indicated by bitfields.
>> 
>> Unknowns are the cause of the problem - in either case.
>> 
> Joe,
> 
> I agree with that, however there are fewer unknowns to deal with when
> using bit-fields as opposed to TLVs. Once the sender and receiver
> agree on options to be used, with bit-fields the order and length are
> fixed.

I gave an example above where that's not the case. A value in a single bit field can redefine other fields - and that can't be avoided as a possibility unless all values of all fields are known in advance and don't do so.

> With TLVs these are variables that need to be considered with
> each packet.

Incorrect - the same is true for TLV. If you specify the order, then they're ordered. If you specify which are required, then they're required. They're just different size bit fields.

> This is why bit-fields naturally yield the simpler and
> more feasible implementation.

This is the conclusion that cannot be reached. If you want to pick bitfields arbitrarily, fine. If you have another reason, present it. But the same rules apply to bitfields and TLVs - known patterns are equally easy, and unknowns are equally hard.

TLVs make the difficulties easier to see, but not more difficult to avoid.

Joe