Re: [nvo3] Update on encapsulation design team
Fabio Maino <fmaino@cisco.com> Tue, 25 October 2016 00:46 UTC
Return-Path: <fmaino@cisco.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D8129525 for <nvo3@ietfa.amsl.com>; Mon, 24 Oct 2016 17:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.951
X-Spam-Level:
X-Spam-Status: No, score=-14.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4O74vOqdFMsj for <nvo3@ietfa.amsl.com>; Mon, 24 Oct 2016 17:46:22 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999BE126CD8 for <nvo3@ietf.org>; Mon, 24 Oct 2016 17:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90050; q=dns/txt; s=iport; t=1477356382; x=1478565982; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Mg83F180eqDy/BTqX+JTPMiDGVupjWIXbVqXFZQrCII=; b=LTnXskvxM7mVUwmCvpKnyjx6wzQFnRLM0W+wzX71MivfMnwsUhJAjnwM OT8v6fPWh9P1hykNpfgtxb6jXF5IaQkBaUvq8UnpTscnrieTdnCUZzR9/ ufjCkAIiegqZbOvGMbEDviidG+3cGU03MyJE8xCn0xaT5VP5H57Jlg7eq s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BWAgADqg5Y/4oNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgyoBAQEBAR1YKlONNJZ9h16MYYIEAxwBCoV6AoFsPxQBAgEBAQEBAQFiKIRiAQEBAwEBAQEXCUQHCwULCw4EBiABBgMCAiEGHwMOBg0GAgEBF4gdAw8IDrRfiQINg2kBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY9gX0IglCCR4UEglsFj0GEdoUoNYYqhlCDGYFuhG2DF4RpgSeHF4FVhBqEAR42UAYIglk4AxyBch40hS0rggIBAQE
X-IronPort-AV: E=Sophos;i="5.31,544,1473120000"; d="scan'208,217";a="165589893"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2016 00:46:20 +0000
Received: from [10.154.248.235] ([10.154.248.235]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9P0kJkP008066; Tue, 25 Oct 2016 00:46:20 GMT
To: Alia Atlas <akatlas@gmail.com>
References: <173AF2C8-D67A-429D-B748-648B8D3FDBA2@nokia.com> <97a4f0d5-333c-0d69-b2ce-5c392bf5d7e7@cisco.com> <17474D02-9C99-4A13-B89C-7B80AAE774E2@gmail.com> <CA+-tSzwVK7gCsziEUs_c-f8tZFnFt5x-Xq5h9Rf8w+N0XqX1qQ@mail.gmail.com> <CAG4d1rcfpajK9xRu0GdvhtfW1=7Z-dm81P7LvU8sb7Tp3cP+yg@mail.gmail.com> <CA+-tSzwcdoWH9AJFdz-og2aYc-ws2MQ6=+H1S5Z5cLaGFj--Yw@mail.gmail.com> <CAG4d1re=_nQQHxajdh3Ed-YwsREHxjWTRDZGV-7pvWHASETK3A@mail.gmail.com> <CA+-tSzwb0=O00c5Zt1fqoL-zAD3s=W1y-jTbDdW1kSkcq-_bKQ@mail.gmail.com> <f889fa6e-71aa-212a-8ce4-ddae9de0be35@cisco.com> <CAG4d1rfsgpOb7Lf4pwKnc4PPwrfFCxb+PrqaNcboPrPVx7eRrw@mail.gmail.com>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <ea6b0524-3040-5102-a820-ac40e3525eb5@cisco.com>
Date: Mon, 24 Oct 2016 17:46:19 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAG4d1rfsgpOb7Lf4pwKnc4PPwrfFCxb+PrqaNcboPrPVx7eRrw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------47B1193C1C3F33A33B46BCCD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Ul95DnLk6npvTco76mRmiaBbiMI>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Dino Farinacci <farinacci@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Update on encapsulation design team
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 00:46:26 -0000
Hi Alia, please see below. On 10/24/16 1:44 PM, Alia Atlas wrote: > Fabio, > > On Mon, Oct 24, 2016 at 3:54 PM, Fabio Maino <fmaino@cisco.com > <mailto:fmaino@cisco.com>> wrote: > > > I think it will be useful for the design team to articulate > clearly and motivate those objections, and present it to the WG > for formal discussion BEFORE starting the new design. That should > help consolidate the requirements for the design of the new encap. > > A separate technical document will help evaluate in depth the > objections raised, rather than rely on hundreds of emails and > their different interpretation. > > > The WG raised the various objections and I have not seen any efforts > to claim that specific ones are not accurate technical objections nor > that the WG should ignore particular objections. > > I think I have seen quite a lot of disagreement around the > objection themselves. > > For example, wrt GPE extensibility the summary reported that > > "- GPE is insufficiently extensible. Numerous extensions and > options have been designed for GUE and Geneve. Note that these > have not yet been validated by the WG." > > That assertion seems to ignore (as it has been pointed out > multiple time in the mailing list) what has been done with NSH, or > other proposed encodings for carrying metadata with VXLAN-GPE > such as: > https://tools.ietf.org/html/draft-ietf-sfc-nsh-10 > <https://tools.ietf.org/html/draft-ietf-sfc-nsh-10> > https://tools.ietf.org/html/draft-brockners-inband-oam-data > <https://tools.ietf.org/html/draft-brockners-inband-oam-data> > > I would like the WG to articulate why, from a technical point of > view, proper layering can't be used to extend GPE (as recommended > by the GPE draft itself), as it is certainly possible (and done) > in the two drafts indicated above. > > > It is not the responsibility of the WG to explain why different > approaches that were not even written down in detail (i.e. an > internet-draft) are not acceptable solutions. If you wish to claim > that layering with NSH is a solution, that may be something > interesting to discuss. However, NSH provides for both fixed MD-Type 1 > meta-data as well as MD-Type 2 meta-data; it assumes a control-plane > that communicates what meta-data is to be carried and how. > Obviously, an approach that only supports MD-Type 1 meta-data will > not have the flexibility that I believe was requested for extensibility. So, an additional requirement that I infer from your text above is that the encap should flexibly allow transport of metadata, even in the absence of a control plane. I can't see that requirement spelled out in the summary. This is one example of what I hope will be part of a detailed analysis of what are the requirements of the encap that should be designed. This will also help determining what requirements the proposed encaps are not matching. > > I will note that any issues around properly attributing ICMP messages > to the triggering sender will still exist with large headers. I do > not currently understand, from your suggestion, what would be > different as far as concerns about header size and processing by > having extra bytes for the NSH header. > > I think we are all quite familiar with the alleged simplicity of the > hand-waved design option. Right, that's why I'm suggesting to avoid to hand-wave requirements. > Same goes for the security objection to GPE. > > > Frankly, I can't parse this other than assuming you mean that security > is not required. Again, if you do not think the WG should agree with > this technical objection, then you need to be able to clearly explain > why and see if there is WG consensus. > > I'm quite sure the authors of the other two proposals have similar > view on the objections raised to their proposals. > > > Then they - and others - are and have been welcome to clearly express > on the NVO3 mailing list why those objections should be ignored. > That is an option - if there is WG consensus on it. PLEASE reread RFC > 7282. > > A separate document, in my opinion, would help understanding what > needs to be addressed before we start with the new design. > > > Do you want to have an IETF standard in this space? It doesn't have to become a standard, but I think it should be done, and discussed in the WG, before the design begins. Having it as a separate draft might help. If then you want to merge it or morph it into the design doc that will be fine. > > I understand the desire to stall progress in favor of proprietary > implementations. If you are referring to my desires, I'm afraid you are grossly misunderstanding. > I would prefer that the IETF not fail to provide standards in this space. Right, we just happen to disagree on how those standards would look like, and how we can get there. FWIW, I'm just answering to the call of the chairs to "hear opinions and confirmation or disagreement on interest in creating a DP encapsulation that addresses the various technical concerns". Thanks, Fabio > I am not willing to leave open a WG that is determinedly failing to > make progress on its charter. > > Regards, > Alia > > > Thanks, > Fabio > > > On 10/24/16 12:51 PM, Anoop Ghanwani wrote: >> Hi Alia, >> >> Ideally I would rather not go there at all as expressed in the >> first part of Fabio's note. Assuming we must go there, having a >> section that documents why the WG thought we needed a new one >> would be good enough for me. >> >> Anoop >> >> On Mon, Oct 24, 2016 at 11:46 AM, Alia Atlas <akatlas@gmail.com >> <mailto:akatlas@gmail.com>> wrote: >> >> Hi Anoop, >> >> On Mon, Oct 24, 2016 at 2:43 PM, Anoop Ghanwani >> <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> wrote: >> >> Alia, >> >> I think it will provide an official reference which will >> be helpful since all the encaps will be around a long >> time and we can point people to that document when we are >> asked the question "why did they develop yet another encap?". >> >> >> So what you are asking for is a section in the overall draft >> that talks about the motivations and improvements? >> There's a trade-off of speed and getting a solution done >> versus doing process work for a theoretical future that won't >> happen if we don't get the technical work finished. >> >> Regards, >> Alia >> >> Thanks, >> Anoop >> >> On Mon, Oct 24, 2016 at 11:30 AM, Alia Atlas >> <akatlas@gmail.com <mailto:akatlas@gmail.com>> wrote: >> >> Anoop & Fabiio, >> >> On Mon, Oct 24, 2016 at 2:26 PM, Anoop Ghanwani >> <anoop@alumni.duke.edu >> <mailto:anoop@alumni.duke.edu>> wrote: >> >> Agree with Fabio (including the suggestion for an >> interim deliverable on shortcomings). If the WG >> doesn't agree on the shortcomings, chances are >> they may not like the 4th encap. >> >> >> What do you expect to be different from the summary >> of technical objections that came out of the last >> discussion? Are you looking for more detail? >> I didn't see disagreement about the accuracy of the >> technical objections. >> >> Regards, >> Alia >> >> Anoop >> >> On Thu, Oct 20, 2016 at 12:10 PM, Dino Farinacci >> <farinacci@gmail.com >> <mailto:farinacci@gmail.com>> wrote: >> >> I agree with Fabio. >> >> Choosing a single encapsulation that is not 1 >> of the 3, creates a 4th one that no one wants. >> >> And guess what, you make all 3 authors >> unhappy where none of them will endorse (or >> implement) the 4th one. >> >> Dino >> >> > On Oct 20, 2016, at 12:02 PM, Fabio Maino >> <fmaino@cisco.com <mailto:fmaino@cisco.com>> >> wrote: >> > >> > (for full disclosure I'm one of the authors >> of VXLAN-GPE) >> > >> > Matt, Sam, Alia, >> > I've expressed multiple times and in >> multiple venues my adversity (and the >> motivations) to set this group to design yet >> another encapsulation. I won't repeat it here >> once again, but I want to re-assert that it's >> still were I stand. >> > >> > I've seen quite a few people in the mailing >> list here expressing similar concerns, but I >> see that it has not changed the opinion of >> the chairs and the AD on what they believe is >> the best way to move forward. >> > >> > That said, here are my comments to the charter. >> > >> > I think the design team first goal should >> be to clearly articulate the shortcomings of >> the current encapsulations proposed to the >> WG. This should be the very first deliverable >> of the design team. The actual design work >> should start only once the WG has reached >> consensus on that document. Especially >> considering that some of the encapsulations >> proposed are being deployed, I think >> articulating the shortcomings will help to >> make the best choice in term of (1) selecting >> which one will need to be extended, and (2) >> designing the actual extensions. >> > >> > Below are my proposals on how to modify the >> wording of the charter. >> > >> > >> > >> > On 10/20/16 1:37 AM, Bocci, Matthew (Nokia >> - GB) wrote: >> >> WG, >> >> >> >> We would like to give you an update on the >> process in the WG for progressing the issue >> of a data plane encapsulation. The chairs and >> Alia believe that the best way forward is to >> progress a single encapsulation format that >> addresses the technical concerns raised on >> the list in the recent discussions. This >> would address the clear overall consensus of >> the Berlin meeting and list for a single >> encapsulation. >> >> >> >> The strategy should be to take one of the >> three existing encapsulations and enhance it >> to address these concerns. This would become >> the standards track output of the WG. The >> existing three drafts (GENEVE, GUE and >> VXLAN-GPE) should be forwarded to the IESG as >> informational after the standards track draft >> specifying the single encapsulation. This >> provides an opportunity for those >> encapsulations to be documented and maintained. >> >> >> >> The single encapsulation should be viewed >> as one that the WG and industry can converge >> around for the future. >> >> >> >> We have created a design team to progress >> work on a single encapsulation that can form >> the basis or work going forward. The design >> team members are: Michael Schmidt, Uri Elzur, >> Ilango Ganga, Erik Nordmark, Rajeev Manur, >> Prankaj Garg. Many thanks to these >> individuals for their help. >> >> >> >> Please see below for a draft charter for >> the design team. Please review the charter >> and send comments to the list by 2nd November >> 2016. >> >> >> >> Regards, >> >> >> >> Matthew and Sam >> >> >> >> >> >> ==== >> >> NVO3 Encapsulation Design team 2016 >> >> >> >> Problem Statement >> >> The NVO3 WG charter states that it may >> produce requirements for network >> virtualization data planes based on >> encapsulation of virtual network traffic over >> an IP-based underlay data plane. Such >> requirements should consider OAM and >> security. Based on these requirements the WG >> will select, extend, and/or develop one or >> more data plane encapsulation format(s). >> >> >> >> This has led to drafts describing three >> encapsulations being adopted by the working >> group: >> >> - draft-ietf-nvo3-geneve-03 >> >> - draft-ietf-nvo3-gue-04 >> >> - draft-ietf-nvo3-vxlan-gpe-02 >> >> >> >> Discussion on the list and in face-to-face >> meetings has identified a number of technical >> problems with each of these encapsulations. >> Furthermore, there was clear consensus at the >> IETF meeting in Berlin that it is undesirable >> for the working group to progress more than >> one data plane encapsulation. Although >> consensus could not be reached on the list, >> the overall consensus was for a single >> encapsulation (RFC2418, Section 3.3). >> Nonetheless there has been resistance to >> converging on a single encapsulation format, >> although doing so would provide the best >> benefit to the industry. >> > >> > The portion of the last sentence that >> follows the comma ("although doing so would >> provide the best benefit to the industry") >> doesn't seem to be adding anything to the >> charter. I'd suggest it could be removed. >> > >> >> >> >> Design Team Goals >> > The design team should clearly articulate >> in a draft which are the shortcomings of the >> proposed encapsulations, and where they fall >> short in addressing the NVO3 architectural >> requirements. >> > >> > Once the 'shortcomings' draft has reached >> consensus of the WG, >> >> The design team should take one of the >> proposed encapsulations and enhance it to >> address the technical concerns. >> >> Backwards compatibility with the chosen >> encapsulation and the simple evolution of >> deployed networks as well as applicability to >> all locations in the NVO3 architecture >> > , together with the design goals >> articulated in the 'shortcoming' draft, >> > >> >> are goals. The DT should specifically >> avoid a design that is burdensome on hardware >> implementations, but should allow future >> extensibility. The chosen design should also >> operate well with ICMP and in ECMP >> environments. If further extensibility is >> required, then it should be done in such a >> manner that it does not require the consent >> of an entity outside of the IETF. >> >> >> >> Timeline >> >> The design team should >> > first produce the 'shortcomings' draft, get >> it adopted by the WG, and then >> > >> >> produce a first draft describing the >> proposal by end of January 2017. Target >> adoption by the WG by March 2017 IETF. >> >> >> > (those two dates may need to be adjusted >> accordingly) >> > >> > >> > Thanks, >> > Fabio >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> nvo3 mailing list >> >> >> >> nvo3@ietf.org <mailto:nvo3@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/nvo3 >> <https://www.ietf.org/mailman/listinfo/nvo3> >> > >> > >> > _______________________________________________ >> > nvo3 mailing list >> > nvo3@ietf.org <mailto:nvo3@ietf.org> >> > https://www.ietf.org/mailman/listinfo/nvo3 >> <https://www.ietf.org/mailman/listinfo/nvo3> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org <mailto:nvo3@ietf.org> >> https://www.ietf.org/mailman/listinfo/nvo3 >> <https://www.ietf.org/mailman/listinfo/nvo3> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org <mailto:nvo3@ietf.org> >> https://www.ietf.org/mailman/listinfo/nvo3 >> <https://www.ietf.org/mailman/listinfo/nvo3> >> >> >> >> >> > >
- [nvo3] Update on encapsulation design team Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Update on encapsulation design team Fabio Maino
- Re: [nvo3] Update on encapsulation design team Dino Farinacci
- Re: [nvo3] Update on encapsulation design team Tom Herbert
- Re: [nvo3] Update on encapsulation design team Dino Farinacci
- Re: [nvo3] Update on encapsulation design team Lizhong Jin
- Re: [nvo3] Update on encapsulation design team Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Update on encapsulation design team Behcet Sarikaya
- Re: [nvo3] Update on encapsulation design team Lucy yong
- Re: [nvo3] Update on encapsulation design team Anoop Ghanwani
- Re: [nvo3] Update on encapsulation design team Alia Atlas
- Re: [nvo3] Update on encapsulation design team Anoop Ghanwani
- Re: [nvo3] Update on encapsulation design team Alia Atlas
- Re: [nvo3] Update on encapsulation design team Anoop Ghanwani
- Re: [nvo3] Update on encapsulation design team Fabio Maino
- Re: [nvo3] Update on encapsulation design team Tom Herbert
- Re: [nvo3] Update on encapsulation design team Alia Atlas
- Re: [nvo3] Update on encapsulation design team Fabio Maino
- Re: [nvo3] Update on encapsulation design team Alia Atlas
- Re: [nvo3] Update on encapsulation design team Tom Herbert
- Re: [nvo3] Update on encapsulation design team Joe Touch