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

Joe Touch <> Fri, 17 February 2017 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2149E129585; Thu, 16 Feb 2017 16:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YERHFCbT3KHr; Thu, 16 Feb 2017 16:21:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24A5F129556; Thu, 16 Feb 2017 16:21:18 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1H0KnUV017006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 16:20:49 -0800 (PST)
To: Tom Herbert <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Thu, 16 Feb 2017 16:20: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: <>
Content-Type: multipart/alternative; boundary="------------F0AAA5112B18A2D9075601CF"
X-ISI-4-43-8-MailScanner: Found to be clean
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:21:19 -0000

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.