The "shared label" does not equal to "global label". It is still a local label allocated by each PE.
Yes, the context label has been adopted. But it does not mean protection approaches based on it have been adopted. I agree with your point that there is always pros/cons of each solution. Coexistence may be not unacceptable. I add the pwe3 mailing list since this document is related to the following draft submitted for pwe3. ICCP Application TLVs for VPN Route Label Sharing http://www.ietf.org/internet-drafts/draft-zhang-pwe3-iccp-label-sharing-00.txt Thanks, Mingui >-----Original Message----- >From: Henderickx, Wim (Wim) [mailto:[email protected]] >Sent: Tuesday, July 23, 2013 2:54 AM >To: Mingui Zhang; Nagendra Kumar (naikumar); [email protected] >Subject: Re: New Version Notification for >draft-zhang-l3vpn-label-sharing-00.txt > >There is always pros/cons of each solution but when the global label was >discussed in the past in L3VPN because it was less flexible compared to >current available approaches which have been adopted successfully. > >On 22/07/13 07:58, "Mingui Zhang" <[email protected]> wrote: > >>Hi Wim, >> >>There should be alternative methods. But this document tries to provide a >>simple one. >> >>For example, >>a. It does not require multiple label spaces. >>b. It need not store context label tables repeatedly on each RG member. >>c. It does not changes the forwarding process. >>d. It does not bear the restriction of no penultimate-hop-popping. >> >>Thanks, >>Mingui >> >>>-----Original Message----- >>>From: Henderickx, Wim (Wim) [mailto:[email protected]] >>>Sent: Friday, July 19, 2013 7:32 PM >>>To: Mingui Zhang; Nagendra Kumar (naikumar); [email protected] >>>Subject: Re: New Version Notification for >>>draft-zhang-l3vpn-label-sharing-00.txt >>> >>>What you are trying to achieve can be done with Ctxt labels using locally >>>assigned labels. So no need for global labels. >>> >>>On 19/07/13 11:01, "Mingui Zhang" <[email protected]> wrote: >>> >>>>Hi Nagendra, >>>> >>>>It can also be automatically negotiated through signaling among those >>>>egress PEs. I have composed the following draft for this point. >>>>ICCP Application TLVs for VPN Route Label Sharing - Mingui ZHANG >>>>http://www.ietf.org/id/draft-zhang-pwe3-iccp-label-sharing-00.txt >>>> >>>>Thanks, >>>>Mingui >>>> >>>>>-----Original Message----- >>>>>From: Nagendra Kumar (naikumar) [mailto:[email protected]] >>>>>Sent: Friday, July 19, 2013 4:55 PM >>>>>To: Mingui Zhang; [email protected] >>>>>Subject: RE: New Version Notification for >>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>> >>>>>Hi, >>>>> >>>>>Thanks. Is the proposal is to manually assign/configure in each PE?. >>>>> >>>>>-Nagendra >>>>> >>>>>-----Original Message----- >>>>>From: Mingui Zhang [mailto:[email protected]] >>>>>Sent: Friday, July 19, 2013 2:21 PM >>>>>To: Nagendra Kumar (naikumar); [email protected] >>>>>Subject: RE: New Version Notification for >>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>> >>>>>Hi Nagendra, >>>>> >>>>>In the method, the egress PEs in the RG have to use the same VPN route >>>>>label >>>>>for one VPN site (e.g., 1100 for VPN1). >>>>>As for the prefix, all prefixes (e.g., 10.1.1.0/24) learnt from this >>>>>VPN >>>>>site will be >>>>>stored in the corresponding VRF (e.g., VPN1' VPN instance) identified >>>>>by >>>>>the VPN >>>>>route label. >>>>> >>>>>I guess you propose to share the label "per-prefix". It's possible to >>>>>do >>>>>so but not >>>>>as common as the "per-VRF" assignment in current practice. >>>>> >>>>>Thanks, >>>>>Mingui >>>>> >>>>>>-----Original Message----- >>>>>>From: Nagendra Kumar (naikumar) [mailto:[email protected]] >>>>>>Sent: Friday, July 19, 2013 4:15 PM >>>>>>To: Mingui Zhang; [email protected] >>>>>>Subject: RE: New Version Notification for >>>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>>> >>>>>>Hi Mingui, >>>>>> >>>>>>I couldn¹t see any point mentioned in this draft on how egress PEs >>>>>>will >>>>>>assign same VPN label for the prefix. >>>>>> >>>>>>Can you please share the same?. Sorry, if I am missing something in >>>>>>the >>>>>>doc. >>>>>> >>>>>>Regards, >>>>>>nagendra >>>>>> >>>>>>-----Original Message----- >>>>>>From: [email protected] [mailto:[email protected]] On Behalf >>>>>>Of Mingui Zhang >>>>>>Sent: Friday, July 19, 2013 1:16 PM >>>>>>To: [email protected] >>>>>>Subject: FW: New Version Notification for >>>>>>draft-zhang-l3vpn-label-sharing-00.txt >>>>>> >>>>>>Dear all, >>>>>> >>>>>>We have submitted a new draft: Label Sharing for Fast PE Protection. >>>>>> >>>>>> This draft designs a simple method to be used by SPs to achieve >>>>>>fast >>>>>>PE protection, utilizing the deployment of redundant egress PEs. >>>>>> >>>>>>Comments are welcome. >>>>>> >>>>>>Regards, >>>>>>Mingui >>>>>> >>>>>>>-----Original Message----- >>>>>> >>>>>>A new version of I-D, draft-zhang-l3vpn-label-sharing-00.txt >>>>>>has been successfully submitted by Mingui Zhang and posted to the IETF >>>>>>repository. >>>>>> >>>>>>Filename: draft-zhang-l3vpn-label-sharing >>>>>>Revision: 00 >>>>>>Title: Label Sharing for Fast PE Protection >>>>>>Creation date: 2013-07-12 >>>>>>Group: Individual Submission >>>>>>Number of pages: 12 >>>>>>URL: >>>>>>http://www.ietf.org/internet-drafts/draft-zhang-l3vpn-label-sharing-00 >>>>>>. >>>>>>txt >>>>>>Status: >>>>>>http://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing >>>>>>Htmlized: >>>>>http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-00 >>>>>> >>>>>> >>>>>>Abstract: >>>>>> This document describes a method to be used by Service Providers to >>>>>> provide fast protection of VPN connections for a CE. Egress PEs in >>>>>>a >>>>>> redundant group always assign the same label for VPN routes from a >>>>>> VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the >>>>>> domain of the IP/MPLS backbone network as an agent of the CE >>>>>>router. >>>>>> Primary and backup tunnels terminated at the vNH are set up by the >>>>>> BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, >>>>>>the >>>>>> backup egress PEs can recognize the "shared" VPN route label and >>>>>> deliver the failure affected packets accordingly. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>The IETF Secretariat >>
