Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

["Luyuan Fang (lufang)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, July 22, 2013 9:51 PM
To: Luyuan Fang <[e-mail]>, "UTTARO, JAMES" <[e-mail]>,
Yakov Rekhter <[e-mail]>, "[e-mail]"
<[e-mail]>
Cc: L3VPN <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: re: The possibility of using global MPLS labels as VNIs ... for
l3vpn

>
>
>> -----邮件原件-----
>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>> Luyuan Fang (lufang)
>> 发送时间: 2013年7月23日 0:19
>> 收件人: UTTARO, JAMES; Yakov Rekhter; [e-mail]
>> 抄送: 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 <[e-mail]>
>> Date: Friday, July 19, 2013 12:49 PM
>> To: Yakov Rekhter <[e-mail]>, "[e-mail]"
>> <[e-mail]>
>> Cc: L3VPN <[e-mail]>
>> Subject: RE: The possibility of using global MPLS labels as VNIs ... for
>> l3vpn
>> 
>> >Comments In-Line..
>> >
>> >Jim Uttaro
>> >
>> >-----Original Message-----
>> >From: [e-mail] [mailto:[e-mail]] On Behalf
>>Of
>> >Yakov Rekhter
>> >Sent: Friday, July 19, 2013 9:23 AM
>> >To: [e-mail]
>> >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.
>> >>
>> >>
>> >
>