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
