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

Tom Herbert <> Fri, 17 February 2017 00:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBB051294CF for <>; Thu, 16 Feb 2017 16:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uJ6J0GQDuClD for <>; Thu, 16 Feb 2017 16:10:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0044212944E for <>; Thu, 16 Feb 2017 16:10:11 -0800 (PST)
Received: by with SMTP id x49so28792232qtc.2 for <>; Thu, 16 Feb 2017 16:10:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VVIV81EuLdcTkFwDGhq8XMy/BGSKqTYCNS1A+P+O4LE=; b=kIZHd/QoLks2m1LG64VFoSH1c2B8ayRegm/Xidi0v/NcJGyW0zq0L8nDs9DM9D+PCM kbafj+Fas/6a/Hl3+OOHUvbhyyeoY4H1mtJIa/f2zdnRTBIlwQfntC1Dc82HNz1eLqk4 BrD7Df6Ro1Ge9YhoFjHRzXbr6tvb/U07uDQg7mHI2L1D6AirFnKkZUi2GemBEclpcuU2 dwshsn5KuoyEls8OyhCv0vT88pcUIhXREs5Cvn/5VWh7l11QpZVXVkuysyTQIbaSLkFV oOTbZE3vbU/3RaOPfWjlFjuBjARPpJsy6VQaNMbOnzvOWRE/ZPgkyHqWCVAiU/xf0eC9 M3ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VVIV81EuLdcTkFwDGhq8XMy/BGSKqTYCNS1A+P+O4LE=; b=cZlq/PSVmlmOVzGvB8IcHLLIZyvsDJcdQK8oY+SznJLCy8g44OYHI29C/qbbxZwgS4 KaFvQT42Bi4fMjJKW6pKnbxeOSXS0s/U0qOoYLttAQX7NQyzaIn6u1nmA5vre/YOrmkT 9dxQMPUhGg3XzOp4lGfVISwgO+Ol2rNkDIVkoKEHd0sWCtXQX6dgJP7iSYYfGq+Wpzbd Yq2JMrRgm0HmDhsSSkIguAcO9tKwt9AlpksyJz7PAIAhVq78UQkfNZz5x0zFTt+D9hq9 fNe/0Qtz+/cS3UjxE08xXMSICNcOsqOrvmLcB/WwiOsSGrAzdG+G+nU7q9aX4pWC1AbS S4gg==
X-Gm-Message-State: AMke39koJwyb9YaAwH2S9KsTr+FiGoN8Ix5+CAUQ7bwRFgqtMWNO+ly6sl43NfIZXvMr4aUvwtve6TbLfE0Lmw==
X-Received: by with SMTP id u16mr5232610qtc.105.1487290210988; Thu, 16 Feb 2017 16:10:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Feb 2017 16:10:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Thu, 16 Feb 2017 16:10:10 -0800
Message-ID: <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Sam Aldrin <>, Sami Boutros <>, "" <>, "" <>, "" <>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Feb 2017 00:10:14 -0000

On Thu, Feb 16, 2017 at 3:52 PM, Joe Touch <> wrote:
> On 2/16/2017 3:45 PM, Tom Herbert wrote:
>> On Thu, Feb 16, 2017 at 3:30 PM, Joe Touch <> 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.
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? 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?
Whose ordering requirements take precedence? What about middleboxes
that need to parse TLVs, would they have a say in this negotiation?
What about options in a multicast packet, what ordering of TLVs would
be used for those? And so on...