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

Tom Herbert <> Fri, 17 February 2017 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F8E0127601 for <>; Fri, 17 Feb 2017 09:04:59 -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 8AwhYnBsFSwY for <>; Fri, 17 Feb 2017 09:04:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F67F1295B5 for <>; Fri, 17 Feb 2017 09:04:57 -0800 (PST)
Received: by with SMTP id u25so49527555qki.2 for <>; Fri, 17 Feb 2017 09:04:57 -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=7wfwztLngH/3dmwEz25F6BEFOPUAevBzA57aRBoJ1TQ=; b=ZV04KeTZ7TBFr8fIgyZ/WcFSEJnmo93SajSx7wH1eHAzZ0lM/XplaiPyET5yzK4pzz cp2prsRGUUC+KoIfsqxPIsiFcFiu6amjzF3iUKu9EJGMUXSaYyVVzAazJIxLbxXG2yfC oLKtit4wnfQ12hT2AePDIHN+YDpDa3Owixc17pgGWMjTPuB4Q+h5CvkeNqI6QjI2QjRI 8SFlIccQtCOIoxduB9T21ogs+6UhCFw/t8Xs9TFs2UoRLBEDosirzYQqGH9L6tk5On+J 1NO3Gr/cRB9urtG11ZMVHl/r59nlxSWpIOpWNF6RDG8OMdcd25kAsAg1ipYRIahQc7m1 5GCw==
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=7wfwztLngH/3dmwEz25F6BEFOPUAevBzA57aRBoJ1TQ=; b=JwJ8GjTUldxXW9yrWABgINx43uoAv84hC0EdjxfgfB+UkF/KjLoC/JgjQCQPvJJUj3 BcmDCCIP3hsevQDbicvBIGA5oQtFDpDdcDasVnCCQFLbgLCgSjt6vGLUoEB2BNCFu2Hw 9CZCsyR+DJ4SIWMRZlkP+0cshBFc6mPpibdLSYntox85g79uQFtD7BjkH0RZksejIuDd IACiXJ2UiiMX+6vrSqqReLe0d617rPNMRhHzmoPh4EX3zQHVzHtAdN+0M+Br719DENrf ro6l+wYr7A9gey+o7qEh7Ly4mIudgV+itSQaEFX1ZSw3llWtwUVOuw+mY2J21XjOgt7D YrLQ==
X-Gm-Message-State: AMke39k8CE9OBlt3JASO4MBupKjBnEPsA2iVHexocLTatOFTcxM46OKsDHsMlcdrARVa9ZhHf3J3W6+IU8fV8g==
X-Received: by with SMTP id u189mr8142180qkb.241.1487351096418; Fri, 17 Feb 2017 09:04:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Feb 2017 09:04:55 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 17 Feb 2017 09:04:55 -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 17:04:59 -0000

>> 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.
We expressly disallow that in GUE. New extensions are always additive
information. From section 3.3.1:

"Flags (or paired flags) are idempotent such that new flags must not
cause reinterpretation of old flags. Also, new flags should not alter
interpretation of other elements in the GUE header nor how the message
is parsed (for instance, in a data message the proto/ctype field
always holds an IP protocol number as an invariant)."

>> 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.

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. There are already
well-deployed protocols with bit-fields such that options order is
invariant (e.g. GRE) and that is characteristic is used to implement
efficient parsing.

>> 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.
I've made pretty much presented all the rationale. Processing a list
of TLVs is demonstrably less efficient than an equivalent set of
bit-fields. In HW we can use TCAM to parse bit fields, in software we
can do it without loops. I've also given the argument for random
access of extensions when processing order is relevant. You can
readily see these characteristics in open source SW implementations.
Last time I checked with HW experts about this they claimed TLVs were
problematic, that was a couple of years ago I suppose someone might
have solved the combinatorics of parsing since then but haven't heard
that from anyone yet.