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

From: Mingui Zhang <[email-masked]>
Date: Fri, 19 Jul 2013 07:46:23 +0000

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

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Fri, 19 Jul 2013 08:15:16 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Friday, July 19, 2013 1:16 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt

Dear all,

Comments are welcome.

Regards,
Mingui

Abstract:

The IETF Secretariat

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 19 Jul 2013 08:50:42 +0000

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

>From: Nagendra Kumar (naikumar) [mailto:[email-masked]]
>Sent: Friday, July 19, 2013 4:15 PM
>To: Mingui Zhang; [email-masked]
>Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt
>
>Hi Mingui,
>
>   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
>
>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

---

From: "Nagendra Kumar (naikumar)" <[email-masked]>
Date: Fri, 19 Jul 2013 08:55:25 +0000

Hi,

Thanks. Is the proposal is to manually assign/configure in each PE?.

-Nagendra

-----Original Message-----
From: Mingui Zhang [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 2:21 PM
To: Nagendra Kumar (naikumar); [email-masked]
Subject: RE: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt

Hi Nagendra,

Thanks,
Mingui

>   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
>

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 19 Jul 2013 09:01:36 +0000

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

>Sent: Friday, July 19, 2013 4:55 PM
>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
>
>>Htmlized:
>http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-00
>>
>>
>>Abstract:

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 19 Jul 2013 11:32:18 +0000

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-masked]> wrote:

>Hi Nagendra,
>
>It can also be automatically negotiated through signaling among those
>egress PEs. I have composed the following draft for this point.
>>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).
>>>I couldn¹t see any point mentioned in this draft on how egress PEs will
>>>assign same VPN label for the prefix.
>>>

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 22 Jul 2013 05:58:19 +0000

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

>From: Henderickx, Wim (Wim) [mailto:[email-masked]]
>Sent: Friday, July 19, 2013 7:32 PM
>To: Mingui Zhang; Nagendra Kumar (naikumar); [email-masked]
>Subject: Re: New Version Notification for draft-zhang-l3vpn-label-sharing-00.txt
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Jul 2013 11:09:36 -0400

As far as I can tell, your scheme only handles the case where the two egress
PEs connect to the exact same set of CEs.  If so, this applicability
restriction should be clearly stated.

In Figure 2.1, you show CE2 connected to PE3 and PE4.  Now suppose we also
have CE4 connected to PE3 and PE5.  If PE3 fails, one might want use PE4 as
a backup for CE2, while using PE5 as a backup for CE4.  Your scheme doesn't
seem to handle this.

Also, even in the case of Figure 2.1, it seems entirely possibly that one
might want PE3's primary route to CE2 to be via the directly attached
interface, while wanting PE4's primary route to CE2 to be via PE3.  Does
your scheme handle this case?

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 22 Jul 2013 18:53:44 +0000

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-masked]> wrote:

>>>>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
>>>>>Can you please share the same?. Sorry, if I am missing something in
>>>>>the
>>>>>doc.
>>>>>
>>>>>Regards,
>>>>>nagendra
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-zhang-l3vpn-label-sharing-00
>>>>>.
>>>>>txt
>>>>>Status:

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 23 Jul 2013 08:21:14 +0000

Hi Eric,

Please see my response in-line below.

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

>From: Eric Rosen [mailto:[email-masked]]
>Sent: Monday, July 22, 2013 11:10 PM
>To: Mingui Zhang
>Cc: [email-masked]; [email-masked]
>Subject: Re: FW: New Version Notification for
>draft-zhang-l3vpn-label-sharing-00.txt
>
>

Not exactly.

If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5 allocate (1101, vNH2) for CE4. The scheme works well. This also answers your first question.

>your scheme handle this case?

Interesting point. 
Yes, it handles. Please see the right part of eq1: Sxy3+M. If the backup tunnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < = Sxy4+S. That means eq1 does not hold.

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 23 Jul 2013 08:38:12 +0000

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.

Thanks,
Mingui

>Sent: Tuesday, July 23, 2013 2:54 AM

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Jul 2013 10:42:21 -0400

Eric> In Figure 2.1, you show CE2 connected to PE3 and PE4.  Now suppose we also
Eric> have CE4 connected to PE3 and PE5.  If PE3 fails, one might want use PE4 as
Eric> a backup for CE2, while using PE5 as a backup for CE4.  Your scheme doesn't
Eric> seem to handle this.

Mingui> If PE3 and PE4 allocate (1100, vNH1) for CE2 while PE3 and PE5
Mingui> allocate (1101, vNH2) for CE4. The scheme works well.

Are you now suggesting to allocate a vNH address and shared label for every
CE?  Since there are many more CEs than PEs, that would make the scaling
properties of the scheme a lot less favorable.

Eric> Also, even in the case of Figure 2.1, it seems entirely possibly that
Eric> one might want PE3's primary route to CE2 to be via the directly
Eric> attached interface, while wanting PE4's primary route to CE2 to be via
Eric> PE3.  Does your scheme handle this case?

Mingui> Yes, it handles. Please see the right part of eq1: Sxy3+M. If the
Mingui> backup tunnel goes through Pxy->PE4->PE3->vNH, then Sxy3+M < =
Mingui> Sxy4+S. That means eq1 does not hold.

I think that equation is based only on the IGP link costs.  A service
provider might use BGP LOCAL_PREF to give the PE3-->CE2 route a higher
degree of preference than the PE4-->CE2 route, in which case PE4's normal
route to CE2 could be via PE3, independent of the IGP link costs.  Of
course, PE4 will switch to the directly attached route when it learns,
through IGP, that PE3 is not reachable.  But in that case you might not meet
the FRR goal.

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 24 Jul 2013 01:50:47 +0000

Hi Eric,

Please see the comments in-line.

Thanks,
Mingui

>Sent: Tuesday, July 23, 2013 10:42 PM
>To: Mingui Zhang
>Cc: [email-masked]; [email-masked]; [email-masked]

That's not true. Please search the following sentence in the draft.
"Egress PEs create a vNH router in IGP to represent the set of CEs dual-homed to the same egress PEs in the Service Provider's backbone."
I don't think this kind of allocation bears scalability issues.

>through IGP, that PE3 is not reachable.  But in that case you might not meet

To achieve the goal of protection, the draft suggested the PEs in the RG use routes that they learn from the CE.
If the service provider insists on using the route from just one PE, he is ready to give up the reliability that can be provided by multiple PEs.