Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Xuxiaohu <xuxiaohu@huawei.com> Tue, 23 July 2013 01:51 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 6EEA921F9C82; Mon, 22 Jul 2013 18:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.502
X-Spam-Level:
X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=-2.645, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy8CkkjUVjRL; Mon, 22 Jul 2013 18:51:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C421F9CAD; Mon, 22 Jul 2013 18:51:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR60126; Tue, 23 Jul 2013 01:51:33 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 02:50:36 +0100
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 02:51:12 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.175]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 09:51:07 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Luyuan Fang (lufang)" <lufang@cisco.com>, "UTTARO, JAMES" <ju1738@att.com>, Yakov Rekhter <yakov@juniper.net>, "thomas.morin@orange.com" <thomas.morin@orange.com>
Thread-Topic: The possibility of using global MPLS labels as VNIs ... for l3vpn
Thread-Index: AQHOhIJ1yIlB/WUnJ0iGPHkvmxyIC5lrdxmAgAA5jICABK6pgIABGz7g
Date: Tue, 23 Jul 2013 01:51:06 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081D80F2@NKGEML512-MBS.china.huawei.com>
References: <B17A6910EEDD1F45980687268941550F0623E26C@MISOUT7MSGUSR9I.ITServices.sbc.com> <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com>
In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD931044FBDC@xmb-rcd-x03.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.130]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, L3VPN <l3vpn@ietf.org>
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 23 Jul 2013 01:51:45 -0000


> -----邮件原件-----
> 发件人: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] 代表
> Luyuan Fang (lufang)
> 发送时间: 2013年7月23日 0:19
> 收件人: UTTARO, JAMES; Yakov Rekhter; thomas.morin@orange.com
> 抄送: L3VPN
> 主题: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn
> 
> As I remember, the global VPN-ID was discussed/debated in L3VPN WG around
> 2003-2006, the global VPN-ID was proposed in the vr draft. The general
> consensus of the WG was that the L3VPN solution would be more flexible and
> scalable without the global VPN-ID, as the way RFC4364/2547 handling it.
> 
> I don't believe this has changed since then. In fact, the extensive large
> scale global deployments of 4364 L3VPNs over the past 15 years provide
> good living testimony of it.

I fully agree that we should make the most of the existing and proven technologies if possible. The reason that I started this discussion is to make sure whether the Virtual Network Context Identification contained in the data packet is REALLY required to be globally unique in some cases.

Best regards,
Xiaohu 

> Luyuan
> 
> -----Original Message-----
> From: <UTTARO>, JAMES <ju1738@att.com>
> Date: Friday, July 19, 2013 12:49 PM
> To: Yakov Rekhter <yakov@juniper.net>, "thomas.morin@orange.com"
> <thomas.morin@orange.com>
> Cc: L3VPN <l3vpn@ietf.org>
> Subject: RE: The possibility of using global MPLS labels as VNIs ... for
> l3vpn
> 
> >Comments In-Line..
> >
> >Jim Uttaro
> >
> >-----Original Message-----
> >From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of
> >Yakov Rekhter
> >Sent: Friday, July 19, 2013 9:23 AM
> >To: thomas.morin@orange.com
> >Cc: L3VPN
> >Subject: Re: The possibility of using global MPLS labels as VNIs ... for
> >l3vpn
> >
> >Thomas,
> >
> >> 2013-07-18, Xuxiaohu:
> >> >
> >> > Till now, it seem that the only remaining technical reason for some
> >> > people to prefer VXLAN/NVGRE encapsulation format to
> >> > MAC-in-MPLS-in-IP encapsulation format for network virtualization
> >> > overlay is the former has global VNIs while the latter doesn't have.
> >> > If this reason is true, why can't we consider the possibility of
> >> > using global MPLS labels to achieve the same goal?
> >>
> >> IMHO, examining *why* someone would want a "global VNI" should be the
> >> start of the discussion, rather than possible solutions.
> >>
> >> I could possibly see at least one reason *not* to try to have a
> >> dedicated identifier in the dataplane common for all flows of "a VPN".
> >> It is not related to the encapsulation, but to the fact that RFC4364
> >> has, in fact, no strict notion of "a VPN", but only of how connectivity
> >> is established betweens set of VRFs.
> >
> >Moreover, connectivity between set of VRFs is not "cast in concrete".
> >To the contrary it could change, as extranets are formed/dissolved,
> >and the process of forming/dissolving extranets could be fairly
> >dynamic.
> >[Jim U>] This happens today..
> >
> >Yakov.
> >
> >>
> >> -Thomas
> >>
> >>
> >>______________________________________________________________
> ___________
> >>_____
> >___________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >>confidentie
> >lles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> >>recu ce
> > message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> >>messages elect
> >roniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete altere, deforme
> >>ou fal
> >sifie. Merci.
> >>
> >> This message and its attachments may contain confidential or privileged
> >>inform
> >ation that may be protected by law;
> >> they should not be distributed, used or copied without authorisation.
> >If you have received this email in error, please notify the sender and
> >delete th
> >is message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have
> >>been mod
> >ified, changed or falsified.
> >> Thank you.
> >>
> >>
> >