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

Joe Touch <> Thu, 09 February 2017 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92AF2129C50; Thu, 9 Feb 2017 11:43:00 -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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mdA5Rw4b7MHC; Thu, 9 Feb 2017 11:42:59 -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 82A0412957F; Thu, 9 Feb 2017 11:42:59 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v19JgX9x028593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Feb 2017 11:42:34 -0800 (PST)
To: Tom Herbert <>
References: <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Thu, 9 Feb 2017 11:42:34 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
X-Mailman-Approved-At: Sun, 12 Feb 2017 08:30:24 -0800
Cc: Sam Aldrin <>, "" <>,,
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: Thu, 09 Feb 2017 19:43:00 -0000

Hi, Tom,

On 2/9/2017 11:33 AM, Tom Herbert wrote:
> On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <> wrote:
>> ...
>> -  the discussion of TLV vs. bitfields needs a bit more expansion. E.g., TLV
>> necessarily requires serial processing, whereas bitfields can be processed
>> in parallel.
> It looks like the intent is to have a control plane that defines the
> TLVs that will be used, a required ordering, and the assumption that
> all TLVs are all the same size. If that is true then parsing TLVs can
> be turned into a parallel problem, e.g. that can be accomplished with
> 2^N entries in a TCAM the same as bit fields. 

That's true only if the TLVs in use are known in advance - if that's
true, then the set of TLVs effectively becomes a large, static bitfield
in the context of that tunnel.

If that's true, then easy hardware processing is possible only in the
context of each individual tunnel, which requires a reconfigurable
hardware parser for each tunnel.

Otherwise, the only way to know where the Nth TLV field starts is to
parse through the N-1th, which - recursively - reduces to requiring
iterative processing.

> But, now implies that
> explicit tunnels need to be established by the control plane before
> the data plane can be used, and to be practical probably means that a
> node will expect to receive pretty much the same set of TLVs with the
> same order from all communicating devices (or maybe the intent is to
> have a universal ordering of TLVs?).
(agreed - the "known in advance case, as above)

> It would be good to have a reference to other low layer protocols that
> include TLVs or the like, especially IPv4 and IPv6, and an explanation
> as to how TLVs in nvo3 will address all the issues of those protocols
> that have deterred deployment of TLVs.
Agreed, especially if those are the "inner" headers that might need to
be parsed anyway.