Yep. Thanks, Tom! Certainly another very important reason to avoid global ID, especially considering operational impact which protocol designers sometimes forget.
Luyuan -----Original Message----- From: Thomas Nadeau <[email protected]> Date: Tuesday, July 23, 2013 10:01 AM To: Luyuan Fang <[email protected]> Cc: "UTTARO, JAMES" <[email protected]>, Yakov Rekhter <[email protected]>, "[email protected]" <[email protected]>, L3VPN <[email protected]> Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn > > 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. >>>> >>>> >>> >> >> >
