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

Tom Herbert <> Thu, 09 February 2017 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4EBF129C72 for <>; Thu, 9 Feb 2017 11:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] 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 WoeLhTi1Bi3X for <>; Thu, 9 Feb 2017 11:33:21 -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 A4E8B129C61 for <>; Thu, 9 Feb 2017 11:33:21 -0800 (PST)
Received: by with SMTP id s140so15974436qke.0 for <>; Thu, 09 Feb 2017 11:33:21 -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=9HRK/HRRVcuAa5USjhjEX0BsiycYNSu42trf7T/PCAQ=; b=V6EK8KDV1tjh5BHllW024+zq1f+LHAbJrnisVZDTOf6Tjo4jzNL0bplr4PRxScpdTJ M5jzFBlkajrk0C99i5VkuhblGqr3kjHcbSYghTZPJ2xFAji02C0x1REHn+Xrf6L5CGwD FKndDmci2W7kpvlqz5j8uM0KEhq3L1sUstoDoRCSKJmRzL8sMYGrF5vilAK+GU3Ir455 Z/dDMoZ/7vTJeYaRcEDMATllMMEbZKS7LXXshdOr3BhDz3w/K18M+UGcf4cYIsqtWDlc OKkGKVw9cDSOuKX+a0HlklqFGcKPijSMi8WDMyHdWPEktSN7Lg/vw2SYn2icRcy85QXe Q5Yg==
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=9HRK/HRRVcuAa5USjhjEX0BsiycYNSu42trf7T/PCAQ=; b=tk9h/AL+mHM4LkWsz/39/C7FneJVd70ms4MJH2956hLTH8NNGedd8dKGodkTfUHPlp mrEb2x/BDHfm5gwpnazVyZoNGJriFl4EF+AvQMbChoVcW+ZIRt5cjs7PLtOR4WMMf0b8 smAqsylyTsYZhQ/ArQGYWRuhUmntKcG01X9pTFkGIlKuzhMhdP9KXVeCdasDXRUvvlEH GWxdAhcBi9Xf/dI5oMt1FaivEw6FySO8Ywa8tKcbOSLevX0o2uUlH/TQ86rQyHqk6cNm wl7cSabvspHzN71EKjUIt8IMqf5nirw/uwcAbf2kHhgxiZSxnqGEVjo/gxr6DuYwnM+g +aSw==
X-Gm-Message-State: AMke39mpP74XgbyTW865uZebz+TUAce32B7P08hr+5UqA2dK75JvczqG36mSZJTs+jYdfdW83KWMd2tL2VlnCw==
X-Received: by with SMTP id p76mr4478823qkl.241.1486668800672; Thu, 09 Feb 2017 11:33:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Feb 2017 11:33:20 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Tom Herbert <>
Date: Thu, 9 Feb 2017 11:33:20 -0800
Message-ID: <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
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:33:24 -0000

On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <> wrote:
> Hi, all,
> I found this document to have useful context for discussion for the most
> part.
> Some notes below:
> - it would be useful to provide a summary of the unique requirements of NVO3
> that necessitate a new encapsulation protocol
> - there are many encapsulation issues not addressed, e.g., MTUs,
> frag/reassembly and fragment ID size, etc.
> -  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. 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?).

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.


> - A "jump over" option is trivially possible in any TLV system, but begs the
> question of why the internal packet  flow information needs to be examined
> (vs using the flow info in the outermost header). Why is this an NVO3
> requirement?
> - TLV == bitfield for the first TLV field; i.e., TLV is a trivial way to
> extend bitfield to multiple bitfields if needed. That might be worth
> considering.
> - It might be useful to note that bitfields are much more difficult to
> handle optionally (e.g., it would require multiple bits, one for the value
> and several to tag the capability as "drop if not supported", "ignore if not
> supported", etc.).
> - I disagree with MUST support a minimum of 64 bytes of options; making that
> requirement effectively limits everyone to using only 64. IMO, that number
> is both too small and sets the protocol up to have "dead wood" (i.e., larger
> option space is specified but can't be relied upon so might never gain
> traction).
> Joe
> On 2/9/2017 9:03 AM, Sam Aldrin wrote:
> Hello NVo3 WG,
> NVo3 Design Team for encap has put in quite a bit of effort to meet, discuss
> and hashout various requirements and issues and coming up with a draft on
> proposed encap. Thanks to all who have participated and made it possible.
> This document could be found at
> URL:
> Status:
> Htmlized:
> Kindly go through the document and review thoroughly and provide your
> comments.
> This will enable DT to close any issues or pending gaps.
> cheers
> Sam & Matthew
> _______________________________________________
> nvo3 mailing list
> _______________________________________________
> nvo3 mailing list