Another issue as I recall, was around the management and administration
of the ID space to avoid conflicts, etc...
--Tom
> 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.
>
>
> 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.
>>>
>>>
>>
>
>
