Re: [nvo3] Mail regarding NVO3 data plane drafts

Xuxiaohu <xuxiaohu@huawei.com> Fri, 15 July 2016 02:03 UTC

Return-Path: <xuxiaohu@huawei.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 2B0B412D68A for <nvo3@ietfa.amsl.com>; Thu, 14 Jul 2016 19:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 NasLf542q8ou for <nvo3@ietfa.amsl.com>; Thu, 14 Jul 2016 19:03:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2623F12D65F for <nvo3@ietf.org>; Thu, 14 Jul 2016 19:03:28 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNS00118; Fri, 15 Jul 2016 02:03:26 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Jul 2016 03:03:25 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 15 Jul 2016 10:03:18 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Black, David" <david.black@emc.com>, "Manish Kumar (manishkr)" <manishkr@cisco.com>, NVO3 <nvo3@ietf.org>
Thread-Topic: [nvo3] Mail regarding NVO3 data plane drafts
Thread-Index: AQHR3fBLPgyDHO3eUkelnKk1tIllE6AYQakQgABuKFA=
Date: Fri, 15 Jul 2016 02:03:18 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D573FE0@NKGEML515-MBX.china.huawei.com>
References: <249BBA62-FB42-4B03-B4DB-8A15ADFDD190@cisco.com> <CE03DB3D7B45C245BCA0D243277949362F5E3F4E@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F5E3F4E@MX307CL04.corp.emc.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5788446E.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 660258d2b45cedafab3a8ec51abc1cc4
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/JwiHWAA-OgZju3phMFyIOD22XbQ>
Subject: Re: [nvo3] Mail regarding NVO3 data plane drafts
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: Fri, 15 Jul 2016 02:03:31 -0000

IETF has published two informational RFCs dedicated for NVo3 data plane encapsulation, one is RFC7348 (i.e., VXLAN) and the other is RFC7637 (i.e., NVGRE). Both of them have been implemented and deployed. Of course, each has its own flaw. The former has no protocol type field (https://www.ietf.org/mail-archive/web/nvo3/current/msg01520.html) and the latter' ECMP capability is not good enough.  

If the NVo3 WG still wants to publish some RFCs on NVo3 data plane encapsulation, it seems reasonable to build on the above two approaches and fix their flaws accordingly. VXLAN-GPE is designed to fix the flaw of VXLAN although whether or not to use a different port number than VXLAN's port number is still controversial. Personally, I prefer to the approach as defined in (https://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-03#page-3) since it seem much simpler than the current approach as defined in (https://tools.ietf.org/html/draft-quinn-vxlan-gpe-03#page-8). GRE-in-UDP is a very good choice to fix the flow of NVGRE. 

Best regards,
Xiaohu

> -----Original Message-----
> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David
> Sent: Friday, July 15, 2016 2:42 AM
> To: Manish Kumar (manishkr); NVO3
> Subject: Re: [nvo3] Mail regarding NVO3 data plane drafts
> 
> > I believe GRE(+UDP) deserves a discussion as well.
> 
> FYI - over in TSVWG, this GRE/UDP draft is standards track and has completed
> WG Last Call:
> 	https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

> Thanks, --David
> 
> > -----Original Message-----
> > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Manish Kumar
> > (manishkr)
> > Sent: Thursday, July 14, 2016 12:54 PM
> > To: Bocci, Matthew (Nokia - GB); NVO3
> > Subject: Re: [nvo3] Mail regarding NVO3 data plane drafts
> >
> > Hi Matthew,
> >
> > I agree this is an important aspect that’s just lingering around.
> > Although not being adopted and not a part of the WG, if there is a
> > discussion on pros-cons/merits- demerits, I believe GRE(+UDP) deserves
> > a discussion as well. For that matter, it may be worth having a broader
> discussion!
> >
> > Thanks,
> > Manish
> >
> >
> >
> >
> >
> > On 14/07/16 9:51 pm, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)"
> > <nvo3- bounces@ietf.org on behalf of matthew.bocci@nokia.com> wrote:
> >
> > >WG,
> > >
> > >The NVO3 working group has adopted three data plane encapsulations:
> > >-          VXLAN-GPE,
> > >-          Geneve,
> > >-          GUE (although the draft is moving to the Intarea WG, we
> anticipate that
> > NVO3 will still reference this).
> > >
> > >We have discussed this situation with Alia and we feel that there is
> > >little benefit
> > to the community in publishing all three as standards track RFCs.
> > >
> > >We would note that the discussion on the drafts has been relatively
> > >light since
> > their adoption. There has not been serious discussion about their
> > relative pros/cons (if any), or about the actual usefulness of their
> > extensibility or differentiators.
> > >
> > >This leaves two options:
> > >
> > >1) Publish all of them as informational or experimental, potentially
> > >moving one
> > of them to standards track in the future based on
> implementation/deployment.
> > >2) Pick one now based on technical and/or implementation/deployment
> criteria.
> > >
> > >We would therefore like to gain a sense of what the WG would like to
> > >do with
> > these drafts.
> > >
> > >Please post your comments to the list. We also have a slot to on the
> > >NVO3
> > agenda in Berlin where we would like to continue this discussion.
> > >
> > >Best regards,
> > >
> > >
> > >Matthew and Sam
> > >
> > >
> > >_______________________________________________
> > >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
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3