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. Luyuan -----Original Message----- From: <UTTARO>, JAMES <[email protected]> Date: Friday, July 19, 2013 12:49 PM To: Yakov Rekhter <[email protected]>, "[email protected]" <[email protected]> Cc: L3VPN <[email protected]> Subject: RE: The possibility of using global MPLS labels as VNIs ... for l3vpn >Comments In-Line.. > >Jim Uttaro > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Yakov Rekhter >Sent: Friday, July 19, 2013 9:23 AM >To: [email protected] >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. >> >> >
