> IMHO, examining *why* someone would want a "global VNI" should be the > start of the discussion, rather than possible solutions.
+1. > 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. I find http://tools.ietf.org/html/rfc4364#section-1.1 sufficiently describing the notion of VPN (which could be intranet or extranet). Cheers Rajiv -----Original Message----- From: Yakov Rekhter <[email protected]> Date: Friday, July 19, 2013 9:23 AM To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> 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. > >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. >> >> >
