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

Tom Herbert <tom@herbertland.com> Fri, 17 February 2017 00:39 UTC

Return-Path: <tom@herbertland.com>
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 AADDA12943C for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 16:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 ejUPZ0a3at4y for <nvo3-dt-encap@ietfa.amsl.com>; Thu, 16 Feb 2017 16:39:43 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 561BE1293E3 for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 16:39:42 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id s186so31972816qkb.1 for <nvo3-dt-encap@ietf.org>; Thu, 16 Feb 2017 16:39:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mu5mS/eQXmqkTqcoP+N7H5bBGr5mO0kPM0Q1sgOMr9Y=; b=R7S1iWwVVhovPYSHfYW1dZ2K9q55EqdjZXs3VsW60zK3aams1IXiupDKDnjz+jWv+s ttn1pdaGNSTMBYqj+j1GgR1BJgOB9sgn5Wr3pzdOh4TrjvFG62Jwv2HKJ/vvlHle5xJk V3jrMSUbXksUxE8CyGhffNGs4NEdhLWAy9Z9jJZcgGPlnsl7epHD3jwj+gg2X8ER9U3g U1+i4rLYemZCe9GAOL0OKPm9ZXGepMI8LZK71pGpwcy8m6uyu2LcrZY4cSUQ5kH+I4C4 ODpa6cAsunUcyw1cbUiqbydOG+qEIZMURA1eadALgcdzgjb9r+pmdKq4LSvqiYQvU8KR Vnew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mu5mS/eQXmqkTqcoP+N7H5bBGr5mO0kPM0Q1sgOMr9Y=; b=EkKkxFAKVngw7pFJPcQlGj+QyPqtkCd6j9sZFSIAS5wuZHjvAiFDnZzo4UXmWtTjzo Erk7UcUNyvuRh0uEGQVeBY+NNZkC5zyCjQrZfKa3ZVLYK9NR12XssQ9CSCrm7b3kUczz xKbOvgOwhb4FOqOufr1ZF0GZ4vpCBvdkp+gW/EYnfVLdbEPhtCfF1+0li81XWjuwfbKs Lnm537Pl80W+o02hbQwXKqoHoDNqYHd692DdBYN6C85adRdIsv4hONwoBDxdBEGnqM4q 4RhBsmfOcKXWrLRQuv1H5b3suEIWBifqBgcqYbl/gcplhwiiWhuUvJx7A8jfzQvuw2ht MgaA==
X-Gm-Message-State: AMke39mUzodz/YifOh5UFXlWJSyJVS4DcYKIP8nX+30g0RTjSEgECs9TFfVxCe9JsFgju8BZuZoxpfWFBnCMPw==
X-Received: by 10.55.5.11 with SMTP id 11mr4865037qkf.262.1487291981365; Thu, 16 Feb 2017 16:39:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.43.227 with HTTP; Thu, 16 Feb 2017 16:39:40 -0800 (PST)
In-Reply-To: <0b6e2d43-dbd1-8024-7d4e-c8863e079037@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>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 16 Feb 2017 16:39:40 -0800
Message-ID: <CALx6S35zcTWmKbkCbzY2kxi+fa=YceTPoxhGdtzL+btjmAugOw@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/sC-fJn98rPMHeS0n3zZxpydSXZ8>
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 00:39:44 -0000

On Thu, Feb 16, 2017 at 4:20 PM, Joe Touch <touch@isi.edu> wrote:
> Hi Tom,
>
>
> On 2/16/2017 4:10 PM, Tom Herbert wrote:
>
> 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.
>
> The interaction between the control plane and dataplane will need to
> be explicit in the definition of the protocol as it is in TCP. And
> this method creates new conditions that need to be handled. For
> instance, if Bob says that he'll send option A and then option B, but
> we get a packet from him with option B before option A then what does
> that mean? Is this an error?
>
> It depends on what we define, but IMO that's a silent drop or - at best - a
> rate-limited warning in the log file.
>
> What if Bob wants to send options A,B,C
> in that order, but Sally wants to only receive them in order C,B,A?
>
> I was using "Bob" to refer to the protocol configuration, the way that we
> use strings to refer to such parameterization of more flexible systems for
> security algorithms. You're using Bob to refer to an endpoint, so let's call
> the protocol configuration we want to use "kiwi".
>
> E.g., see the list of encryption transforms for IKE.
>
> In this case, we could define one required protocol that can easily be "X
> with TLVs A, B, C in that order only".
>
> My point is that the protocol used need not be so ossified in its
> specification, e.g., the encapsulation protocol could specify TLVs
> A,B,C,D,E, and F, and allow any order in general. However, the complexity of
> dealing with all possible combinations and orders need not impact NVO3.
>
> Whose ordering requirements take precedence?
>
> The same as any negotiation protocol - there's typically an offer and a
> counter based on a subset. You say you want "kiwk, orange, or grape" (in
> order of preference) and the receiver either picks ONE or refuses. That's
> going to have to happen anyway.
>
> What about middleboxes
> that need to parse TLVs, would they have a say in this negotiation?
>
> Middleboxes don't play by any known rules. They'd have just as much trouble
> with TLV ordering and selection as they would with changes from "don't care"
> to "care" of bits in bitfields.
>
> What about options in a multicast packet, what ordering of TLVs would
> be used for those? And so on...
>
>
> Same issues apply in all cases. TLVs are no different from bitfields. You
> need to negotiate what they mean in both cases for all uses.
>
> I'm not arguing for TLVs, just pointing out that the claimed reasons for
> picking bitfields over TLVs is nonsense.
>

The operational issues we see with TLVs in terms of performance and
DDOS are not aberrations, they are fundamental issues we face in
deployment. Maybe with enough work and new implementation these issues
can be addressed in Geneve, but honestly given the history of similar
protocols in IETF and that of nvo3 I have doubts. It would be great if
I'm proven wrong in this :-).

Thanks for the interesting discussion...

Tom