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

Tom Herbert <tom@herbertland.com> Fri, 10 February 2017 21:23 UTC

Return-Path: <tom@herbertland.com>
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 8C144129C47 for <nvo3-dt-encap@ietfa.amsl.com>; Fri, 10 Feb 2017 13:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 Eb_V_tVumNFh for <nvo3-dt-encap@ietfa.amsl.com>; Fri, 10 Feb 2017 13:23:27 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 A91DA129C4A for <nvo3-dt-encap@ietf.org>; Fri, 10 Feb 2017 13:23:25 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id k15so47234756qtg.3 for <nvo3-dt-encap@ietf.org>; Fri, 10 Feb 2017 13:23:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CJBH33NoItv7VyxtqmjDq/moq4LjGvqKE7iQOyBzKNI=; b=FfcQqpb+g0mqiuHXldLDqqoxGTmAyOtVH3t6vi1BZhlgyWNIC2OfMJKkUpOlONOERl pE475KHzPz9F/pOm6taOnmrEs5EXWPcRPsF+d46UaOgUz866X3X/XXs+s4pUnx59m29N 7UGuXmh0DQKiY6tQry2zsZblQ+akHBTDUGHJUDAnSluoPPUztGqJM8mKjhI+ZrSTUD9q ohkxDeZndIGbCDT664PQOgNS0lTCpKk7MvXFVcnRssRl5Tx0iDc4FYUHQrYHicUjnbeg Mc3Sb4jVycU6JxbwCk7hBXXqCBJw8YqP6f7s2jDktGWhpWGXDW6dvC8Wtg+gTlBWAXdC 5j2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CJBH33NoItv7VyxtqmjDq/moq4LjGvqKE7iQOyBzKNI=; b=UPnqEMm1Xl0hfFAH5OeRAIomyK9jUeuFk9g/Mr94rOC8UfrXdV9+EhuLCL43ZnVnOU TFuUeWKEfiKyAWgZioQtRGR1Q4b+28AB+eN8CoLHwV5xdJQ0AL/83UvYYWU23CXn8Fvt sk8LwTEDmoe9hr1WqeA5K1mdT6LAjLNaXqdx6IFMz1EwWaHdB27P1W523ySnLQdq6Kbz gLsFZVLU8u4EovaHoC3PtRidRuMQ98rWteTbZFrL2gAYYB3AAkjv5ig3A/HkrT4zpxcL XwIgnCrZzO+6TyJlJdMCNvkcXbF4jAw8+950eHBSzbkCl1IleQ62O6A3JQIeb5lMieKP B7LQ==
X-Gm-Message-State: AMke39n+E1sO83hEfPuq31qt40Zp21LNel7tWIf3VXZiES0qIK0TUN5x1+gH++0zwgcPhFwbWhe96vMUPtIW0g==
X-Received: by 10.237.35.84 with SMTP id i20mr11209837qtc.247.1486761804614; Fri, 10 Feb 2017 13:23:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.43.227 with HTTP; Fri, 10 Feb 2017 13:23:24 -0800 (PST)
In-Reply-To: <c7bdff0f-2f6a-c6e6-8bc5-15859b376ab8@isi.edu>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com> <c7bdff0f-2f6a-c6e6-8bc5-15859b376ab8@isi.edu>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 10 Feb 2017 13:23:24 -0800
Message-ID: <CALx6S35WZn69U2F=XRwd55foVfBQHW=+aRYyv5YL+tJiuqOSMQ@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/yt64A5jPzB7Z3xqXFCy62XiCdUw>
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: Fri, 10 Feb 2017 21:23:28 -0000

On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <touch@isi.edu> 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.
>
> - 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).
>
Having both a minimum and a different maximum value is superfluous.
The minimum value is the maximum value in practice. Consider that we
deploy a solution using various vendors each of which support a
different number of bytes in options. As long as we configure
something less than the minimum number of option bytes then everyone
is happy. The second we try to use more than the minimum number things
start to break. Even though the vendors can claim compliance with the
protocol we have lost interoperability.

Tom

> 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
> Status:         https://datatracker.ietf.org/doc/draft-dt-nvo3-encap/
> Htmlized:       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
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>