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

Tom Herbert <> Sat, 11 February 2017 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E574129561 for <>; Fri, 10 Feb 2017 17:09:24 -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 oosjg4500jxV for <>; Fri, 10 Feb 2017 17:09:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1672812957D for <>; Fri, 10 Feb 2017 17:09:21 -0800 (PST)
Received: by with SMTP id 11so7235050qkl.0 for <>; Fri, 10 Feb 2017 17:09: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=muZ/uFI7qhYq+IOtuvc60wJRbsnNnkE0usxb00Sc+SQ=; b=Uk7y1Rikg2zLFzuNCBTcgXT8zCORZ1NX7gYU/GH2JfTqBLL5N3SuAHZu7qbbEvOahj DrX/MnFa6z+ASfM+fmkATuUK2mnz9Ba85+vr463wElijfgewkigLzjbHgIjWH9hyhZGa dkLO6ZmQPB5YqHxOsn7SCS17+FPOWr1tvpeSR9UGq/Kwo9/HCeITDUFKjBD808ZsickL g8Jsn/pf6xfB4jXBH3QsOnJu7vBdLLozdqgYhmWsv5Sp0Cyw8k41Zg8IXjxb8YFmpX6R axG6k8fhs7hvNosc+KteUSqGtBwZZlGD2XiyeRemsLpYt83VYGgdFOhqXZhH4dxGMYuS nCpA==
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=muZ/uFI7qhYq+IOtuvc60wJRbsnNnkE0usxb00Sc+SQ=; b=gJBi+g2UyBIrbQdBPb4NcR5EM9B8oWcGi18sVke6tQauZbRiQCOsbwkGk6+ttMqzE0 qdZ8klSMhq9rafOEk9Td7JU5QZodRshSYh/YidnCPd45/EwNX/VOKrLcxyOxQ7Rf9Pgo xrlftuhALkYaxEDnxpcJSMitZ4qonC7YfHRNV/pM9QAHtuufkADTACbuBeOlsOHPvXRb 1+2+hcQtjUnEet5ifFRb9QgTXUMShcipYti6CcVqtBf86PYMXjt9L20XYZAgo6/nwS7+ itj0eHfJAwlIBf9rTY3D633U1UhDfMXpKyrMUNzrtflv8NmieNLQm1+zeKhyKoHy4ker E6bw==
X-Gm-Message-State: AMke39nNQso979X374X6wNE9ovzyWI2IT/xPTrxeF5EV2N78Hu8zESzb84iLQRFbH0w17R0iRCc1CbrF014exg==
X-Received: by with SMTP id b63mr12470747qkd.297.1486775360029; Fri, 10 Feb 2017 17:09:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Feb 2017 17:09:19 -0800 (PST)
In-Reply-To: <>
References: <>
From: Tom Herbert <>
Date: Fri, 10 Feb 2017 17:09:19 -0800
Message-ID: <>
To: Sam Aldrin <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>,,
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: Sat, 11 Feb 2017 01:09:24 -0000

Hi Sam and DT,

Thanks for the work.

A few comments:

>From section 6.6:

"...if options are added over time and different subsets of options
are likely to be implemented in different pieces of hardware, then it
would be hard for the IETF to specify which options should get the
early bit fields."

- Many IETF protocols have flag fields. Please quantify why this is a
particular issue for nvo3, or why getting a bit an flags field is
particularly harder than getting an option number in something like IP
or TCP.

"But transit devices would have issues with future GUE bits being
defined for future options as well."

- I don't believe this is true (albeit "issues" is rather ambiguous).
When a new option is added in GUE their flags can only be added at the
tail of the flag bits. This will in no way impact the ability of
transit devices to process the options it already knows about.

"A benefit of TLVs from a HW perspective is that they are self
describing i.e., all the information is in the TLV."

- There seems to be a running theme in this draft about optimizing for
HW implementation. The nvo3 protocol is not a hardware protocol, the
requirement is that it is hardware friendly. Even if I were to believe
that implementing TLVs in HW was easier than bit fields, which I
don't, TLVs are still much harder and less efficient in when
implemented in software. Please try to strike some balance between the
descriptions of both HW and SW implementation.

-  IMO, this draft is unnecessarily speculative and for forward
looking. There is already a lot of practical experience deploying
protocols with things like TLVs and bit fields which is relevant since
most this draft's content is not specific to network virtualization.
I've already mentioned that the feasibility for using TLVs needs to be
reconciled with the experiences for IP options and IPv6 EH, and
mentioned previously on the list that GRE already provides a example
of a deployed encapsulation protocol that supports bit fields which
are commonly supported in HW for some time.

It would be nice to have some reference draft-ietf-rtgwg-dt-encap-02.
There is a lot of overlap between these drafts although the latter
goes in to significantly more depth for some topics.


On Thu, Feb 9, 2017 at 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