Xiaohu, Thanks. I think we are in agreement. One small subtlety to point out, "existing" is not the reason, "proven" (to scale), yes. It is "right":-), not because it is there.
>whether the Virtual Network Context Identification contained in the data >packet is REALLY required to be globally unique in some cases. Not I know of. Thanks, Luyuan -----Original Message----- From: Xuxiaohu <[email protected]> Date: Monday, July 22, 2013 9:51 PM To: Luyuan Fang <[email protected]>, "UTTARO, JAMES" <[email protected]>, Yakov Rekhter <[email protected]>, "[email protected]" <[email protected]> Cc: L3VPN <[email protected]>, "[email protected]" <[email protected]> Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn > > >> -----邮件原件----- >> 发件人: [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. >> >> >> >> >> > >
