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. > >
