Yes creating extranets is currently done in L3VPN. I would assume that this is also creating when extending a customers VPN into a VPC ( Virtual Private Cloud ).. IMO NVO3 is focused on only the overlay technology and not on the service realization.
Jim Uttaro -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Xuxiaohu Sent: Sunday, July 21, 2013 9:53 PM To: Yakov Rekhter; [email protected] Cc: [email protected]; L3VPN Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Yakov > Rekhter > 发送时间: 2013年7月19日 21:23 > 收件人: [email protected] > 抄送: L3VPN > 主题: 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. Is extranet is a normal requirement for Layer3 DC network virtualization overlay? I haven't seen any description of this in the NVo3 requirement and framework drafts yet. Best regards, Xiaohu > 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. > > > >
