> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Luyuan Fang (lufang) > 发送时间: 2013年7月23日 0:19 > 收件人: UTTARO, JAMES; Yakov Rekhter; [email protected] > 抄送: 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 <[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. > >> > >> > >
