RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt

[Mingui Zhang <[e-mail]>]

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:[e-mail]]
>Sent: Tuesday, July 23, 2013 2:54 AM
>To: Mingui Zhang; Nagendra Kumar (naikumar); [e-mail]
>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" <[e-mail]> 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:[e-mail]]
>>>Sent: Friday, July 19, 2013 7:32 PM
>>>To: Mingui Zhang; Nagendra Kumar (naikumar); [e-mail]
>>>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" <[e-mail]> 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:[e-mail]]
>>>>>Sent: Friday, July 19, 2013 4:55 PM
>>>>>To: Mingui Zhang; [e-mail]
>>>>>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:[e-mail]]
>>>>>Sent: Friday, July 19, 2013 2:21 PM
>>>>>To: Nagendra Kumar (naikumar); [e-mail]
>>>>>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:[e-mail]]
>>>>>>Sent: Friday, July 19, 2013 4:15 PM
>>>>>>To: Mingui Zhang; [e-mail]
>>>>>>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: [e-mail] [mailto:[e-mail]] On Behalf
>>>>>>Of Mingui Zhang
>>>>>>Sent: Friday, July 19, 2013 1:16 PM
>>>>>>To: [e-mail]
>>>>>>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
>>