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

Joe Touch <touch@isi.edu> Thu, 09 February 2017 19:43 UTC

Return-Path: <touch@isi.edu>
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 92AF2129C50; Thu, 9 Feb 2017 11:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdA5Rw4b7MHC; Thu, 9 Feb 2017 11:42:59 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 82A0412957F; Thu, 9 Feb 2017 11:42:59 -0800 (PST)
Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (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 <tom@herbertland.com>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com> <c7bdff0f-2f6a-c6e6-8bc5-15859b376ab8@isi.edu> <CALx6S37N7Gt5zcCOj0OXSQLXaRc=fvC_LjkbRzppSnNA=fD7PA@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <9b06d694-4931-17a8-d721-c7971fe6b662@isi.edu>
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: <CALx6S37N7Gt5zcCOj0OXSQLXaRc=fvC_LjkbRzppSnNA=fD7PA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/JKmYYIQKajIPjLY_o704rvh7JS4>
X-Mailman-Approved-At: Sun, 12 Feb 2017 08:30:24 -0800
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, nvo3-chairs@ietf.org, nvo3-dt-encap@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: 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 <touch@isi.edu> 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.

Joe