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

Joe Touch <touch@isi.edu> Thu, 09 February 2017 18:47 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 E8373128BA2; Thu, 9 Feb 2017 10:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9N2qNv_fWb1K; Thu, 9 Feb 2017 10:47:21 -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 2DBAB127076; Thu, 9 Feb 2017 10:47:21 -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 v19Ikkdk017282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Feb 2017 10:46:49 -0800 (PST)
To: Sam Aldrin <aldrin.ietf@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <c7bdff0f-2f6a-c6e6-8bc5-15859b376ab8@isi.edu>
Date: Thu, 9 Feb 2017 10:46:47 -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: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------86280E8D3E27D2C6F9344BAB"
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/plxHSb1QY31Ob-WhaXjEjNInESw>
X-Mailman-Approved-At: Sun, 12 Feb 2017 08:30:24 -0800
Cc: nvo3-dt-encap@ietf.org, nvo3-chairs@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 18:47:23 -0000

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.

- 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:         
>   https://www.ietf.org/internet-drafts/draft-dt-nvo3-encap-00.txt
> <https://www.ietf.org/internet-drafts/draft-dt-nvo3-encap-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-dt-nvo3-encap/
> <https://datatracker.ietf.org/doc/draft-dt-nvo3-encap/>
> Htmlized:       https://tools.ietf.org/html/draft-dt-nvo3-encap-00
> <https://tools.ietf.org/html/draft-dt-nvo3-encap-00>
>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3