Subject: Why we consider the method of "label sharing for fast PE protection"

From: Mingui Zhang <[email-masked]>
Date: Thu, 7 Nov 2013 19:40:28 +0000

Hi,

As a choice of fast PE protection,

1. This solution is simple and light-weight. We need not introduce the complex context label table in PE routers. So label table need not be stored repeatedly on RG members.

2. Also, it’s easy to be deployed. It does not bring any change to P routers (control plane & data plane). It even does not change the data plane of PE routers.

3. In addition, it does not bear the restriction of “no penultimate-hop-popping”.

Thanks,
Mingui

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 7 Nov 2013 21:50:33 +0000

Several people at the mike asked this question:
How do you make sure that the PEs allocate the same label?

This needs to be part of the document, because it is quite important.
If an external entity allocates the labels, the protocol
between the PEs and that entity needs to be standardized.
Since this is a feature that provides redundancy, the
label allocating entity also needs to be backed up by a
redundant entity. The protocol between the redundant
label allocators needs to be standardized.

--

Jakob Heitz.

________________________________
From: [email-masked] [[email-masked]] on behalf of Mingui Zhang [[email-masked]]
Sent: Thursday, 07 November 2013 11:40 AM
To: [email-masked]
Subject: Why we consider the method of "label sharing for fast PE protection"

Hi,

Thanks,
Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 7 Nov 2013 22:15:10 +0000

Hi Jakob,

There are three ways,

1. Always, this label can be configured.

2. We do have a companion draft to realize this. Please look at http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00 . We already presented this draft in pwe3. (Let me copy this track to the pwe3 mailing list.) With the ICCP connection established, PEs can negotiate this label.

2. The last choice is to use a global label if it was supported.

Thanks,
Mingui
________________________________
From: Jakob Heitz [[email-masked]]
Sent: Friday, November 08, 2013 5:50
To: Mingui Zhang; [email-masked]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

--

Jakob Heitz.

Hi,

Thanks,
Mingui

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Nov 2013 07:20:27 +0100

Hi Mingui,

If your implementation configures a same VPN label across N sites
manual or by SDN magic you are free to advertise it along with VPNv4
routes. I am not sure why any draft is needed for that at all. After
all it is your implementation.

To the best of my knowledge L3VPN spec does not prohibit in any RFC to
advertise the same label across N PEs. In fact it does not mandate any
correlation of label value across PEs so you are pretty free to go.

However if you go that path please notice that this is not just about
.. "let's configure same VPN label".

We do have three types of VPN labels:

- per vrf
- per next hop
- per prefix

I am a bit implicitly assuming you are talking about per vrf label
only. Other modes of label allocation would be rather cumbersome to be
done manually or even programmatically as their appearance and
allocation must be coordinated with new CE or new VPN advertisement in
any VPN site and across existence of already provisioned sites.

As Eric mentioned today devil is in details and where you go down to
actually implement robust solution I can bet that you will start very
much to like to concept of context labels for protection and
independent VPN (or for that matter any other application - pwe3/l2vpn
etc) label allocation pardigm :)

Best regards,
R.

On Thu, Nov 7, 2013 at 11:15 PM, Mingui Zhang <[email-masked]> wrote:
> 2. We do have a companion draft to realize this. Please look at
> http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00 . We
> already presented this draft in pwe3. (Let me copy this track to the pwe3
> mailing list.) With the ICCP connection established, PEs can negotiate this
> label.
>
>
>
> 1. This solution is simple and light-weight. We need not introduce the
> complex context label table in PE routers. So label table need not be stored
> repeatedly on RG members.
>
>
> 2. Also, it’s easy to be deployed. It does not bring any change to P routers
> (control plane & data plane). It even does not change the data plane of PE
> routers.
>
>

---

From: Mingui Zhang <[email-masked]>
Date: Sat, 9 Nov 2013 08:32:57 +0000

Hi Robert,

Thanks for your comments!

>all it is your implementation.

[ZMG] The point is that each PE used to allocate the VPN label for each VRF locally without knowing what label has been assigned by other PEs. Now, we need them “happen to” allocate the same label for each VRF. 
>correlation of label value across PEs so you are pretty free to go.

[ZMG] Or you can speak in this way. It’s free for this draft to mandate a REQ to the label allocation that PEs in a Redundant Group always allocate the same label for each VRF.

<snip>
>only. 

[ZMG] Yes, you are right. We are assuming the “per VRF” allocation in our draft for the sake of scalability. 

>Other modes of label allocation would be rather cumbersome 

[ZMG] I agree with you. Other two finer grained label allocations are not recommended. 

<snip>
>etc) label allocation pardigm :)

[ZMG] I believe when Eric made that statement, he assumed the label allocation was done by a “SDN central controller”. I guess that was simply an abstraction caused by the chaos of the “central controlled” conception. 

[ZMG] To make the discussion clear, let’s forget about the “central controlled” like stuff from now on. We proposed the draft leveraging ICCP connection to do the label negotiation. Please focus on that choice.  ICCP has already provided that robustness. Why reinvent the wheel? :)

Regards,
Mingui

________________________________________
From: [email-masked] [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Saturday, November 09, 2013 14:20
To: Mingui Zhang
Cc: Jakob Heitz; [email-masked]; [email-masked]
Subject: Re: Why we consider the method of "label sharing for fast PE protection"

Hi Mingui,

- per vrf
- per next hop
- per prefix

Best regards,
R.

---

From: <[email-masked]>
Date: Tue, 12 Nov 2013 15:59:37 +0000

Hi Mingui,

Please see comments inlined. #Bruno

Plus some comments below on the draft:

1)      The document does not describe the scaling impact on the core as it creates, in the core IGP, states on a per CE (customers'site) basis. For large SP, this will represent a significant impact on the IGP and will degrade the IGP convergence time. ( o(number of important IGP prefixes to rewrite) )

2)  > A master PE is elected in the same way the DR is selected (see section 7.3 of [RFC2328]<http://tools.ietf.org/html/rfc2328#section-7.3>), or the DIS is selected [ISIS<http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01#ref-ISIS>].

I don't think that this is directly applicable. You may need to elaborate on this and specify the corner cases (e.g. CE starts and advertise its routes to both PE at the same time. Hence both PE believes they are the first one and hence are the master.) Also in BGP VPN or IGP there is no advertisement of "Router Priority". I guess that this can always be specified, but this remains to be done.

3)  "   Suppose PE3 fails and the packet with VPN route label 1100 is

   redirected to PE4. PE4 can recognize this shared label. It simply

   looks up the packet's destination address in the VRF identified by

   this label. As specified in Section 5 of [RFC4364]<http://tools.ietf.org/html/rfc4364#section-5>, PE4 will be able

   to determine, the attachment circuit over which the packet should be

   transmitted (to the CE) as well as the data link layer header for

   that interface. In this way, the failed egress PE is smoothly

   protected. >

 "It simply

   looks up the packet's destination address in the VRF identified by

   this label". IMHO additional elaboration may be required as the nominal PE may be the nominal because it has advertised a more specific route. Hence a look up in the VRF will match the more specific route from the nominal/failed PE. Not sure how a vanilia PE implementation would react. The issue is that when receiving the packet, the backup PE does not know whether the nominal is dead or not. In contrast to draft-minto for which the PE know whether it's used as backup or not, thanks to the contextual label.

Regards,
Bruno

From: Mingui Zhang Sent: Thursday, November 07, 2013 8:40 PM

Hi,

1. This solution is simple and light-weight. We need not introduce the complex context label table in PE routers.

#Bruno: draft-minto-2547-egress-node-fast-protection<http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02> is simple and light-weight ;-) More seriously:

- Draft minto does not need to define a new protocol (ICCP) in order to learn the labels of the backup PE. BGP already provides this. While ICCP is a 79 pages draft, plus 11 for the extension.

- Draft zhang relies on the having the same label on redundant PE. While this is doable, this is a significant change compared to the existing deployed model.

- regarding context label tabel

                  - From a standardization standpoint, context-specific label space is already defined in RFC 5331, so nothing new.

                  - From an implementation standpoint, I agree that this requires some additional resources in the forwarding plane. But draft minto does not require that all PE support this. This can be performed by a protector PE if some PE do not support it.

So label table need not be stored repeatedly on RG members.
#Bruno: agreed.

2. Also, it's easy to be deployed. It does not bring any change to P routers (control plane & data plane). It even does not change the data plane of PE routers.
#Bruno: It's not easy to deploy as it mandates to update all PE routers, both nominal and backup. While with draft-minto-2547-egress-node-fast-protection<http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02> the deployment of a single protector PE can fast protect all PE of the AS with no change on existing PE.

3. In addition, it does not bear the restriction of "no penultimate-hop-popping".
#Bruno: ultimate hop poping is only required for the label associated with the context table of the backup PE. This is required to identify the context-specific label space. This is not an additional argument compared to 1 (context label table).

Thanks,
Mingui

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information 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 this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 14 Nov 2013 04:57:23 +0000

Hi Bruno, 

My comments inline below. [Mingui]

>1)      The document does not describe the scaling impact on the core as it
>creates, in the core IGP, states on a per CE (customers'site) basis. For large SP,
>this will represent a significant impact on the IGP and will degrade the IGP
>convergence time. ( o(number of important IGP prefixes to rewrite) )

[Mingui] Here, I need to point out that the vNH is not created per CE. If multiple CEs are connected to an RG, one vNH is enough. When you read the first sentence of Section 2.1, you will be clear.
[Mingui] "A vNH router is created in IGP to represent the set of CEs which are dual-homed to the same egress PEs in the Service Provider's backbone".
[Mingui] Exactly, it's per RG basis. In a real network, the numbers of RGs is comparable to the number of PEs, so it's similar to the per PE basis choice (the best choice) in draft-minto.

>2)  > A master PE is elected in the same way the DR is selected (see section 7.3
>of [RFC2328] <http://tools.ietf.org/html/rfc2328#section-7.3> ), or the DIS is
>selected [ISIS
><http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01#ref-ISIS> ].
>I don't think that this is directly applicable. You may need to elaborate on this
>and specify the corner cases (e.g. CE starts and advertise its routes to both PE
>at the same time. Hence both PE believes they are the first one and hence are
>the master.) Also in BGP VPN or IGP there is no advertisement of "Router
>Priority". I guess that this can always be specified, but this remains to be done.

[Mingui] That's a valid point. We did define the "Priority" in the "vNH TLV" in Section 2.3.3 of the companion draft (http://tools.ietf.org/html/draft-zhang-pwe3-iccp-label-sharing-00). We can change the words to fix this inconsistence.

<snip>
>IMHO additional elaboration may be required as the nominal PE
>may be the nominal because it has advertised a more specific route. Hence a
>look up in the VRF will match the more specific route from the nominal/failed PE.
>Not sure how a vanilia PE implementation would react. The issue is that when
>receiving the packet, the backup PE does not know whether the nominal is dead
>or not. In contrast to draft-minto for which the PE know whether it's used as
>backup or not, thanks to the contextual label.

[Mingui] So you propose the scenario that the backup PE directs packets to the primary PE since the primary PE advertised a more specific route. This makes the primary PE be an inevitable point on all forwarding paths to the CE. Eric ever used "BGP LOCAL_PREF" to compose a similar scenario (http://www.ietf.org/mail-archive/web/l3vpn/current/msg03691.html).

[Mingui] For this subtle case, the redundant connection is not utilized in the first place. If customers prefer resilience to more specific routes, the backup PE should not use the primary PE as the next hop. 

[Mingui] All in all, if customers really want the resilience, those routes via the primary PE SHOULD NOT be installed in the FIBs of backup PEs. 

[Mingui] By the way, the scenario you designed may suffer from transient loop issue. Imagine that the more specific routes fails on the primary PE, the primary PE will resort to the backup PE. At that time, it's probably that the backup PE is unaware of the failure. It will send packet back to the primary PE. Oops, loop occurs. Following the above "SHOULD NOT be installed" requirement, such kind of loops can be avoided.

<snip>
>More seriously:
>- Draft minto does not need to define a new protocol (ICCP) in order to learn the
>labels of the backup PE. BGP already provides this. While ICCP is a 79 pages
>draft, plus 11 for the extension.
>- Draft zhang relies on the having the same label on redundant PE. While this is
>doable, this is a significant change compared to the existing deployed model.
>                  - From a standardization standpoint, context-specific label
>space is already defined in RFC 5331, so nothing new.
>                  - From an implementation standpoint, I agree that this
>requires some additional resources in the forwarding plane. But draft minto
>does not require that all PE support this. This can be performed by a protector
>PE if some PE do not support it.

[Mingui] If nothing new for protocols, this becomes an implementation issue. Then, should this be considered in IETF? :-)

[Mingui] We do not define ICCP, we make use of it. If we can have a solution happen in purely the control plane, as IETFers, we should be happy. If customers want this feature, I promise you will see this feature supported by products in several months. For vendors who have already implemented ICCP, it can be faster. More importantly, this is a "once for all" effort compared to the redundant forwarding tables. 

[Mingui] As Robert and I discussed previously, existing deploy model does not prohibit PE to advertise the same label. I don't think this changes the existing deploy model.

>2. Also, it's easy to be deployed. It does not bring any change to P routers
>#Bruno: It's not easy to deploy as it mandates to update all PE routers, both
>nominal and backup. While with draft-minto-2547-egress-node-fast-protection
><http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02>
>the deployment of a single protector PE can fast protect all PE of the AS with no
>change on existing PE.

[Mingui] As I explained above, the update to the control plane should be OK.

[Mingui] OK. Let me give an analysis of the draft-minto-2547-egress-node-fast-protection. I hope this is constructive when the draft is updated.

[Mingui] a.	The co-located and hybrid models require configuration, which is error prone and increases a management burden to operators.
[Mingui] b.	The centralized model is not robust. How do you handle the failure of the centralized protector itself? This problem had been proposed for the "central controller" stuff. 
[Mingui] c.	The delegation of protector is topology dependent. I guess the number of possible alternative paths held by the protector is a much smaller set of all possible alternative paths. 
[Mingui] d.	The centralized protector has to manage the context label assignment and maintain multiple forwarding tables for all RGs. I am afraid this model is not scalable. 
[Mingui] e.	There is a brief description on Fast ReRoute in Section 5.3. For the "RSVP" choice, it depends on another individual draft [http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02]. Does this draft mandates update on P and PE routers? For the "LDP" choice, it's not clear how IGP can find alternative paths (I find the "beyond the scope" words.). I think the coverage of alternative paths cannot be very good, especially when the centralized protector is used.

>#Bruno: ultimate hop poping is only required for the label associated with the
>context table of the backup PE. This is required to identify the context-specific
>label space. This is not an additional argument compared to 1 (context label
>table).

[Mingui] I agree. 

Thanks,
Mingui

---

From: <[email-masked]>
Date: Thu, 14 Nov 2013 10:12:21 +0000

Hi Mingui,

Thanks for the answers.
You have added pwe in cc. I'm not sure why as I'm following up on your presentation during L3 VPN WG on L3 VPN PE protection.

My comments inline below [Bruno]

>From: >Mingui Zhang >Sent: Thursday, November 14, 2013 5:57 AM
>
>Hi Bruno,
>
>[Mingui] Here, I need to point out that the vNH is not created per CE. If
>multiple CEs are connected to an RG, one vNH is enough. When you read the
>first sentence of Section 2.1, you will be clear.
>[Mingui] "A vNH router is created in IGP to represent the set of CEs which
>are dual-homed to the same egress PEs in the Service Provider's backbone".

[Bruno] Agreed. 

>[Mingui] Exactly, it's per RG basis. In a real network, the numbers of RGs
>is comparable to the number of PEs, so it's similar to the per PE basis
>choice (the best choice) in draft-minto.

[Bruno] First, consider that in a "POP" there may be multiple PE, i.e. more than the 2 required for the dual homing. Let's say 5 PE.
The number of RG is flexible, but this also comes with drawbacks.
One option is to have a single RG. In this case, you indeed need a single vNH but you require global label allocation for the perimeter of those 5 PE. Which roughly divide the available label space by 5. Then if this represents a scaling issue, I guess you can call for bigger labels, e.g. by stacking 2 labels. But this requires more lookup work in the forwarding plane. Roughly equivalent to the label context space that you did not want in the first time...
Another option is to have one RG per couple of PE. In this case you need 10 vNH (IINM). That's roughly the number of PE but that's still *3 the number of states in the IGP so I think the document should talk about this.

>[Mingui] That's a valid point. We did define the "Priority" in the "vNH TLV"
>in Section 2.3.3 of the companion draft (http://tools.ietf.org/html/draft-
>zhang-pwe3-iccp-label-sharing-00). We can change the words to fix this
>inconsistence.

[Bruno] Ack. 

>[Mingui] So you propose the scenario that the backup PE directs packets to
>the primary PE since the primary PE advertised a more specific route. This
>makes the primary PE be an inevitable point on all forwarding paths to the
>CE. Eric ever used "BGP LOCAL_PREF" to compose a similar scenario
>(http://www.ietf.org/mail-archive/web/l3vpn/current/msg03691.html).
>
>[Mingui] For this subtle case, the redundant connection is not utilized in
>the first place. If customers prefer resilience to more specific routes, the
>backup PE should not use the primary PE as the next hop.

[Bruno] IMO this is a normal routing behavior which needs to be supported. It doesn't mean that the redundant is not utilized because another more specific prefix could be "attached" to this redundant connection. It probably means that the CE/customer is using TE to better load balance the flows across both connections.

>[Mingui] All in all, if customers really want the resilience, those routes
>via the primary PE SHOULD NOT be installed in the FIBs of backup PEs.

[Bruno] Good point. So you probably should add this to the document.

>[Mingui] By the way, the scenario you designed may suffer from transient
>loop issue. Imagine that the more specific routes fails on the primary PE,
>the primary PE will resort to the backup PE. At that time, it's probably
>that the backup PE is unaware of the failure. It will send packet back to
>the primary PE. Oops, loop occurs. Following the above "SHOULD NOT be
>installed" requirement, such kind of loops can be avoided.

[Bruno] You are right. I suspect that RFC 4364 implies that a PE should not reflect back to the core, a VPN packet received from the core. But I haven't checked.

>[Mingui] If nothing new for protocols, this becomes an implementation issue.
>Then, should this be considered in IETF? :-)

[Bruno] That's not a local implementation issue as this is a global behavior/feature at the network level. And to allow this behavior we need all implementations to implement this feature.
Note that all IETF documents do not describe change of the bits sent on the wire.
Finally, one protocol changed will be required.

>[Mingui] We do not define ICCP, we make use of it.

[Bruno] idem for context label :-)

> If we can have a solution happen in purely the control plane, as IETFers, we should be happy. 

[Bruno] Sure. But the solution relies on global VPN labels which is not what is deployed today. So it all depends on whether you will be able to deploy such change before. Which will requires all implementations to do it while draft minto has no such dependency.

> If customers want this feature, I promise you will see this feature supported
>by products in several months.

[Bruno] Ok. But I guess you mean a subset of the products currently deployed. There may be multiple vendors/implementations in a given network. And some implementations are sometimes even considered as legacy (by the vendor).

> For vendors who have already implemented
>ICCP, it can be faster. More importantly, this is a "once for all" effort
>compared to the redundant forwarding tables.
>
>[Mingui] As Robert and I discussed previously, existing deploy model does
>not prohibit PE to advertise the same label. 

[Bruno] Agreed.

> I don't think this changes the existing deploy model.

[Bruno] I think it does.

>[Mingui] OK. Let me give an analysis of the draft-minto-2547-egress-node-
>fast-protection. I hope this is constructive when the draft is updated.
>
>[Mingui] a.	The co-located and hybrid models require configuration, which is
>error prone and increases a management burden to operators.

#Bruno: You need to configure the pairs of PE. But this is a one time configuration on a per PE basis when the PE is provisioned. I don't think per VPN configuration is required as by listening to BGP routes, the backup PE can discover that it needs to back up the nominal one. Your proposition probably need the same configuration effort (configuring RG and vNH)

>[Mingui] b.	The centralized model is not robust. How do you handle the
>failure of the centralized protector itself? This problem had been proposed
>for the "central controller" stuff.

#Bruno: If one wants to protect the protection one may use a second (redundant) protector. 
However, as the protector is expected to be in use only few seconds per day at most, I'm not sure people would consider such specific case of double failure.

>[Mingui] c.	The delegation of protector is topology dependent. I guess the
>number of possible alternative paths held by the protector is a much smaller
>set of all possible alternative paths.

#Bruno: Indeed, currently the location of the protector is topology independent. Simply because this relies on the existing FRR mechanism used in the core and this FRR may have coverage limitations (e.g. LFA). There are plans to remove this limitation.
I'm not sure to understand your second point (second sentence).

>[Mingui] d.	The centralized protector has to manage the context label
>assignment and maintain multiple forwarding tables for all RGs. I am afraid
>this model is not scalable.

#Bruno: Just like a PE does (maintain multiple forwarding tables) so I think this is just as scalable as 4364 VPNs are. Besides, we are talking about dedicated protector PE so it can be choosen to scale in that direction (just like for VPN BGP RR)

>[Mingui] e.	There is a brief description on Fast ReRoute in Section 5.3. For
>the "RSVP" choice, it depends on another individual draft
>[http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-
>02]. Does this draft mandates update on P and PE routers? For the "LDP"
>choice, it's not clear how IGP can find alternative paths (I find the
>"beyond the scope" words.). I think the coverage of alternative paths cannot
>be very good, especially when the centralized protector is used.

#Bruno: For LDP, cf 2 points above.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Nov 2013 13:51:34 +0000

Isn't the normal problem that the two systems will be
independently allocating labels from their default
label table, possibly with different hardware base
and range, so there may not be a common label
available that can be allocated by both.

- Stewart

On 07/11/2013 21:50, Jakob Heitz wrote:
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of 
> Mingui Zhang [[email-masked]]
> *Sent:* Thursday, 07 November 2013 11:40 AM
> *To:* [email-masked]
> *Subject:* Why we consider the method of "label sharing for fast PE 
> protection"
>
> Hi,
>
> complex context label table in PE routers. So label table need not be 
> stored repeatedly on RG members.
>
>
> 2. Also, it’s easy to be deployed. It does not bring any change to P 
> routers (control plane & data plane). It even does not change the data 
> plane of PE routers.
>
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 18 Nov 2013 09:31:41 +0000

Hi Bruno,

Please find my comments inline below [Mingui].

>You have added pwe in cc. I'm not sure why as I'm following up on your
>presentation during L3 VPN WG on L3 VPN PE protection.

[Mingui] Sorry that I didn't explain the reason every time. There was a companion draft presented in pwe3 for this l3vpn-PE-protection draft. Pwe3 WG determined they also need know the progress of this l3vpn draft.

>[Bruno] First, consider that in a "POP" there may be multiple PE, i.e. more than
>the 2 required for the dual homing. Let's say 5 PE.
>One option is to have a single RG. In this case, you indeed need a single vNH but
>you require global label allocation for the perimeter of those 5 PE. Which roughly
>divide the available label space by 5. 

[Mingui] That is a misinterpretation. Actually, all 5 PEs share the same label range (e.g., 1~1100) rather than dividing the label space. There is no scaling issue.

>Then if this represents a scaling issue, I
>guess you can call for bigger labels, e.g. by stacking 2 labels. But this requires
>more lookup work in the forwarding plane. 

[Mingui] As explained above, it does not need multiple lookup. Remember, we do not want to change the forwarding plane.

>Roughly equivalent to the label
>context space that you did not want in the first time...
>Another option is to have one RG per couple of PE. In this case you need 10 vNH
>(IINM). That's roughly the number of PE but that's still *3 the number of states
>in the IGP so I think the document should talk about this.

[Mingui] On one hand, the above extreme case happens only in theory. The reason we scope the document to talk about 2 PEs is that duel homing is the BCP. Think about the real deployment, I believe most POPs will use two PEs for the redundant connection. On the other hand, even if you have 5 PEs in one POP, just put them into one RG. Therefore, the increase of the number of states in the IGP is not so big.

[Mingui] But I agree with your advice that we can spend some words to address this scaling issue in the document.

<snip>
>>[Mingui] All in all, if customers really want the resilience, those
>>routes via the primary PE SHOULD NOT be installed in the FIBs of backup PEs.
>

[Mingui] Sure.

>>[Mingui] By the way, the scenario you designed may suffer from
>>transient loop issue. Imagine that the more specific routes fails on
>>the primary PE, the primary PE will resort to the backup PE. At that
>>time, it's probably that the backup PE is unaware of the failure. It
>>will send packet back to the primary PE. Oops, loop occurs. Following
>>the above "SHOULD NOT be installed" requirement, such kind of loops can be
>avoided.
>
>[Bruno] You are right. I suspect that RFC 4364 implies that a PE should not
>reflect back to the core, a VPN packet received from the core. But I haven't
>checked.

[Mingui] OK. How about the local-repair and label-retention technique? With that technique, the primary PE may cache the route advertised by the backup PE and use it when the route it learns from the CE fails. I guess this issue is kind of off the track. We can talk more about it between us two.

>[Bruno] Sure. But the solution relies on global VPN labels which is not what is
>deployed today. So it all depends on whether you will be able to deploy such
>change before. Which will requires all implementations to do it while draft minto
>has no such dependency.

[Mingui] The solution does not rely on *global* VPN labels. They are still locally assigned in the scope of the RG.

>> If customers want this feature, I promise you will see this feature
>>supported by products in several months.
>
>[Bruno] Ok. But I guess you mean a subset of the products currently deployed.
>There may be multiple vendors/implementations in a given network. And some
>implementations are sometimes even considered as legacy (by the vendor).

[Mingui] For those legacy products, operators can update their software. If bare legacy PEs and label-sharing PEs are interconnected, ICCP connection will not be established. It allows PEs falls back to the non-redundant connection. For those label-sharing PEs from different vendors, if they implement the same RFC, they are supposed to be interoperable.

>>number of possible alternative paths held by the protector is a much
>>smaller set of all possible alternative paths.
>
>#Bruno: Indeed, currently the location of the protector is topology independent.
>Simply because this relies on the existing FRR mechanism used in the core and
>this FRR may have coverage limitations (e.g. LFA). There are plans to remove
>this limitation.

[Mingui] The central protector is delegated as the PLR, right? This further reduces the coverage of LFA. As we know, a free LFA can have any router as the PLR.

Thanks,
Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 18 Nov 2013 09:34:29 +0000

Hi Stewart,

Operators can configure the PEs in an RG to reserve the same label range for sharing.

With the ICCP connection established between the primary and backup PE, the primary PE can mandate the sharing label range out of the intersection of the unused label space.

Thanks,
Mingui

>-----Original Message-----
>From: Stewart Bryant [mailto:[email-masked]]
>Sent: Thursday, November 14, 2013 9:52 PM
>To: Jakob Heitz; Mingui Zhang; [email-masked]
>Isn't the normal problem that the two systems will be independently allocating
>labels from their default label table, possibly with different hardware base and
>range, so there may not be a common label available that can be allocated by
>both.
>
>- Stewart
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 18 Nov 2013 12:52:29 +0000

It's not just the range, right?  You have to allocate the same label per VRF.  So you either end up statically allocating labels or making sure you have the same label allocation algorithm on every pair of primary/backup PEs.

eric

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mingui Zhang
> Sent: Monday, November 18, 2013 4:34 AM
> To: Stewart Bryant (stbryant); Jakob Heitz; [email-masked]
> With the ICCP connection established between the primary and backup PE,
> the primary PE can mandate the sharing label range out of the
> intersection of the unused label space.
> 
> Thanks,
> Mingui
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Nov 2013 13:50:36 +0000

That sounds doable ;)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Monday, November 18, 2013 7:52 AM
To: Mingui Zhang; Stewart Bryant (stbryant); Jakob Heitz; [email-masked]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

eric

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Nov 2013 13:51:41 +0000

Not realistic.. How about if I run out of capacity on the primary PE?? What would I do??

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, November 18, 2013 4:34 AM
To: [email-masked]; Jakob Heitz; [email-masked]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

Hi Stewart,

Thanks,
Mingui

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 18 Nov 2013 15:57:23 +0000

"same algorithm" is not good enough on its own. If two routers using the same algorithm boot up at different times and/or with different neighbors, they still won't allocate the same labels.

The algorithm cannot just be "same". It must be restricted in other ways.

--
Jakob Heitz.

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 18 Nov 2013 15:59:41 +0000

Oh, yeah.  I'm not actually proposing that there's a workable solution.  I'm trying to point out that there isn't one.

The problem gets harder, too.

PE1: VRF-A primary, VRF-B backup
PE2: VRF-B primary, VRF-C backup
PE3: VRF-C primary, VRF-A backup

and so forth.

eric

> From: Jakob Heitz [mailto:[email-masked]]
> Sent: Monday, November 18, 2013 10:57 AM
> To: UTTARO, JAMES
> Cc: Eric Osborne (eosborne); Mingui Zhang; Stewart Bryant (stbryant);
> [email-masked]
> "same algorithm" is not good enough on its own. If two routers using the
> same algorithm boot up at different times and/or with different
> neighbors, they still won't allocate the same labels.
> 
> Of Eric Osborne (eosborne)
> > It's not just the range, right?  You have to allocate the same label
> per VRF.  So you either end up statically allocating labels or making
> sure you have the same label allocation algorithm on every pair of
> primary/backup PEs.
> >
> >
> >
> >
> >
> > eric
> >
> >> Operators can configure the PEs in an RG to reserve the same label
> range
> >> for sharing.
> >>
> >>> Subject: Re: Why we consider the method of "label sharing for fast
> PE
> >>> protection"
> >>>
> >>> labels from their default label table, possibly with different
> hardware
> >> base and
> >>>    From: [email-masked] [[email-masked]] on behalf
> of
> >>>    1. This solution is simple and light-weight. We need not
> introduce
> >> the
> >>>    2. Also, it's easy to be deployed. It does not bring any change
> to
> >> P routers
> >>> (control plane & data plane). It even does not change the data plane
> of
> >> PE
> >>> routers.
> >>>
> >>>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Nov 2013 16:00:25 +0000

+1

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Monday, November 18, 2013 11:00 AM
To: Jakob Heitz; UTTARO, JAMES
Cc: Mingui Zhang; Stewart Bryant (stbryant); [email-masked]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

and so forth.

eric

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 18 Nov 2013 16:05:45 +0000

We are on the same page.
I misinterpreted your :)

I guess it could be done at small scale with certain restrictions.
It's definitely not a generic solution.

--
Jakob Heitz.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 18 Nov 2013 18:41:28 +0000

The authors need to take onboard the findings of the SPRING
designers.

If the PE equipments are different the label ranges supported
by h/w may be disjoint.

Stewart

On 18/11/2013 16:05, Jakob Heitz wrote:
> .

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Nov 2013 18:52:17 +0000

IMO solutions need to be deployable.. So, I would like to see some text describing how this solution would work in a real network.

Jim Uttaro

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, November 18, 2013 1:41 PM
To: Jakob Heitz; Eric Osborne (eosborne)
Cc: UTTARO, JAMES; Mingui Zhang; [email-masked]
Subject: Re: Why we consider the method of "label sharing for fast PE protection"

Stewart

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 19 Nov 2013 05:04:27 +0000

Hi,

In a real network, one PE cannot be freely interconnected with any PE in any geographic position to form an RG. In most cases, one PE is connected to the left and right PEs to form the RG. The example you propose is complex enough. For your example, let RG1 = (PE1, PE2), RG2=(PE2, PE3), RG3=(PE1, PE3). Then each label is shared for each VPN in the scope of each RG.

Firstly, statically allocating can always serve as a choice.

The second way is to let both PEs in an RG to have the "same algorithm". Operators reserve a label range for each RG and use a _hashing_ algorithm to allocate each label for each VPN in each RG. This hashing algorithm can be designed independent of the router boot time. Each PE sort the VPNs and then assign labels one by one according to the hashing algorithm. 

Let me introduce the third way: the "synchronization" method. In each RG, one master PE will be elected according to their priorities. The master PE mandates the range and also assign the VPN route label for each VPN in this RG. The backup PE acks the assignment. They can also do periodic synchronization of their label assignment to cope with exceptions. 

Thanks,
Mingui

>Sent: Tuesday, November 19, 2013 12:06 AM
>To: Eric Osborne (eosborne)
>Cc: UTTARO, JAMES; Mingui Zhang; Stewart Bryant (stbryant); [email-masked]
>> Oh, yeah.  I'm not actually proposing that there's a workable solution.  I'm
>trying to point out that there isn't one.
>>
>>> "same algorithm" is not good enough on its own. If two routers using
>>> the same algorithm boot up at different times and/or with different
>>>> Subject: RE: Why we consider the method of "label sharing for fast
>>>> PE
>>> protection"
>>>>
>>>>>> independently
>>>>> allocating

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 19 Nov 2013 10:01:05 +0000

Hi Stewart,

>The authors need to take onboard the findings of the SPRING designers.

I am not sure I've got the point. Are your still talking about the label allocation issue? Could you please explain it more specifically? 

>If the PE equipments are different the label ranges supported by h/w may be
>disjoint.

PEs can reserve some label ranges to be shared before they boot up. Then it becomes easy for an RG to figure out a common range.

Thanks,
Mingui

>Sent: Tuesday, November 19, 2013 2:41 AM
>The authors need to take onboard the findings of the SPRING designers.
>
>If the PE equipments are different the label ranges supported by h/w may be
>disjoint.
>
>Stewart
>
>>>> Cc: Eric Osborne (eosborne); Mingui Zhang; Stewart Bryant
>>>> (stbryant); [email-masked]
>>>> PE protection"
>>>> per VRF.  So you either end up statically allocating labels or
>>>> making sure you have the same label allocation algorithm on every
>>>> pair of primary/backup PEs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> eric
>>>>>
>>>>>> PE protection"
>>>>>> With the ICCP connection established between the primary and
>>>>>> backup
>>>> PE,
>>>>>>> complex context label table in PE routers. So label table need
>>>>>>> not
>>>> be
>>>>>> stored

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Nov 2013 12:30:38 +0100

Hi Mingui,

Imagine PE implementation that has no option to configure label ranges
for LDP, SR, PE protection, RSVP-TE or that even if it does it's
reconfiguration across entire domain to find common block across
required set of devices is not possible. That is what Stewart referred
to as "SPRING lesson" and the solution to play with block + index
hack.

What do you do then with your scheme ?

Ask operator to remove such PEs from the network ?

Best,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 19 Nov 2013 17:21:52 +0000

Hi,

Completely agree with Robert, add to this - operation folks use label
ranges for troubleshooting, i.e. They (their tools) know what label range
to look for is there is a particular issue with LDP or RSVP, etc so
changing the range is not so trivial

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, November 19, 2013 3:30 AM
To: Mingui Zhang <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: Why we consider the method of "label sharing for fast PE
protection"

>> I am not sure I've got the point. Are your still talking about the
>>label allocation issue? Could you please explain it more specifically?
>>
>> PEs can reserve some label ranges to be shared before they boot up.
>>Then it becomes easy for an RG to figure out a common range.
>>
>> Thanks,
>> Mingui
>>

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 21 Nov 2013 02:19:08 +0000

Hi Robert,

>it's reconfiguration across
>entire domain to find common block across required set of devices is not
>possible.

That's the misinterpretation. The proposal never requires a common block in the _entire_ domain.

The common block is required only in the scope of an RG. Imagine the real use cases in IPRAN and MAN, most likely one POP will deploy only two PEs for each RG. Think about other redundant connection techniques, e.g., MC-LAG, two PEs in an RG are even from one vendor in most cases.

Anyway, I think it's able to reserve a common block for just two PEs. 

>Ask operator to remove such PEs from the network ?

Certainly not, the proposal is designed to be incrementally deployable in the network. The trick is confined in the RG. Other P and PE routers are unaware of the change.

I think you didn't follow all the comments. Let me explain the most rigid incremental deployment scenario: a legacy PE and a label sharing PE form an RG. Since the proposal does not require data plane update on PE routers in the RG. Operators need only update the software of the legacy PE. 

Thanks,
Mingui

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
>Raszuk
>Sent: Tuesday, November 19, 2013 7:31 PM
>To: Mingui Zhang
>Cc: [email-masked]; Jakob Heitz; Eric Osborne (eosborne); UTTARO, JAMES;
>[email-masked]
>Imagine PE implementation that has no option to configure label ranges for LDP,
>SR, PE protection, RSVP-TE or that even if it does it's reconfiguration across
>entire domain to find common block across required set of devices is not
>possible. That is what Stewart referred to as "SPRING lesson" and the solution
>to play with block + index hack.
>
>> I am not sure I've got the point. Are your still talking about the label allocation
>issue? Could you please explain it more specifically?
>>
>>>If the PE equipments are different the label ranges supported by h/w
>>>may be disjoint.
>>
>> PEs can reserve some label ranges to be shared before they boot up. Then it
>becomes easy for an RG to figure out a common range.
>>
>> Thanks,
>> Mingui
>>
>>>If the PE equipments are different the label ranges supported by h/w
>>>may be disjoint.
>>>
>>>Stewart
>>>
>>>>>> "same algorithm" is not good enough on its own. If two routers
>>>>>> using the same algorithm boot up at different times and/or with
>>>>>> different neighbors, they still won't allocate the same labels.
>>>>>>
>>>>>>> Subject: RE: Why we consider the method of "label sharing for
>>>>>>> fast PE
>>>>>> protection"
>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.h
>>>>>>>>> tm
>>>>>>>>> l
>>>> .
>>>>
>>>
>>>
>>>--

---

From: Lizhenbin <[email-masked]>
Date: Thu, 21 Nov 2013 02:21:39 +0000

Hi Stewart,
I add following points: 
1. since the protection is based on multi-homing or dual-homing scenarios, according to my experience on the network deployment design of carriers, they always use the devices with similar capacity for the multi-homed PEs. That is, the hardware and label range could be matching. 
2. According to the general L3VPN deployment of carriers, they must guarantee the scalability. That is, they will not use out the label range as many as possible. Instead they will try to save the label range. The possible way includes
1) Only set up LSP for host IP address(/32). There are not too many host IP address in a network.
2) For L3VPN, they use label allocation per instance instead of label allocation per prefix. For one VPN, there only uses 2-3 label per VPN.
By possible ways, there can save enough label according to existing L3VPN deployment scenario. It is not difficult to get a common label range for the multi-homed PEs.
3. According to 1/2, the common label range can be found for the multi-homed PEs. With ICCP extensions to coordinate the label allocation between PEs, the label sharing can work.
4. The above point is for the existing L3VPN scenarios. For the emerging large scale L3VPN deployment scenarios, it just begins to discuss in IETF. Maybe it is necessary to expand the existing MPLS label range which has been proposed in draft-renwei-mpls-big-label-00 and draft-li-mpls-mega-label-00. I think these topics are just in the initial phase in IETF.

Thanks,
Robin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Mingui Zhang
发送时间: 2013年11月18日 17:34
收件人: [email-masked]; Jakob Heitz; [email-masked]
主题: RE: Why we consider the method of "label sharing for fast PE protection"

Hi Stewart,

Thanks,
Mingui

>Isn't the normal problem that the two systems will be independently 
>allocating labels from their default label table, possibly with 
>different hardware base and range, so there may not be a common label 
>	2. Also, it's easy to be deployed. It does not bring any change to P

---

From: Lizhenbin <[email-masked]>
Date: Thu, 21 Nov 2013 02:57:20 +0000

Hi Jakob & Eric,
Regarding your questions, I explain more as follows:
A. Regarding the boot up scenario, maybe we have to discuss by distinguishing different label allocation methods:
1. Statically configure label range and the allocated label for VPN: This is the simplest method. For this method, the algorithm is static configuration. The same label can be guaranteed even if two routers using the same algorithm boot up at different times and/or with different neighbors. 
2. Statically configure label range and ICCP-based label allocation for VPN: The same label range can be guaranteed when routers boot up since it is configured statically. For the same label allocation for VPN when routers boot up, the existing similar process like graceful start or NSR(Non-Stop Routing) can be reused.
3.Global label allocation by the central controller: As I mentioned at the MIKE, draft-li-mpls-global-label-usecases-00 and draft-li-mpls-global-label-framework-00 discuss the use cases and label allocation method for the label sharing method. It can simplify the same label allocation. I think the topic is also in the initial phase in IETF to be discussed. And also YES, the GR or NSR process should be taken into account when routers boot up.

B. Regarding the normal same label allocation mentioned by Eric's "So you either end up statically allocating labels or making sure you have the same label allocation algorithm on every pair of primary/backup PEs.":
It is not like this way. For the ICCP-based label allocation method, the primary PE is allocate the label for VPN by its own label allocation algorithm. The backup PE is just to allocate the label specified by the primary PE. The process is just like label backup. They need not use the same label allocation algorithm.

Thanks
Robin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Jakob Heitz
发送时间: 2013年11月18日 23:57
收件人: UTTARO, JAMES
抄送: [email-masked]; Stewart Bryant (stbryant)
主题: Re: Why we consider the method of "label sharing for fast PE protection"

--
Jakob Heitz.

On Nov 18, 2013, at 5:51 AM, "UTTARO, JAMES" <[email-masked]> wrote:

>> range for sharing.
>> With the ICCP connection established between the primary and backup 
>> PE, the primary PE can mandate the sharing label range out of the 
>>> of Mingui Zhang [[email-masked]]

---

From: Lizhenbin <[email-masked]>
Date: Thu, 21 Nov 2013 03:08:48 +0000

Hi Eric,
You scenario is truly complex which I think it can confuse the service providers if they likes to design such scenarios for their own. Regarding your mentioned scenario, it is not only for VPN, but also for the service providers to configure complex route policy to guarantee it. Even so, the label sharing is just a little additional label allocation for the route distribution controlled by the complex route policies. I just simply to point how to solve the scenario:

PE1: VRF-A primary, VRF-B backup
-- Simulate a shared virtual IP address: IP(AB). Allocate a shared label: Label(AB)
PE2: VRF-B primary, VRF-C backup
-- Simulate a shared virtual IP address: IP(BC). Allocate a shared label: Label(BC)
PE3: VRF-C primary, VRF-A backup
-- Simulate a shared virtual IP address: IP(CA). Allocate a shared label: Label(CA)

Then since the route policy will control what routes in VPN use VRFA/B/C as primary or backup, then they will use different virtual IP address and shared label to advertise the route by BGP. Then it can work.

Thanks,
Robin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Eric Osborne (eosborne)
发送时间: 2013年11月19日 0:00
收件人: Jakob Heitz; UTTARO, JAMES
抄送: [email-masked]; Stewart Bryant (stbryant)
主题: RE: Why we consider the method of "label sharing for fast PE protection"

and so forth.

eric

---

From: Lizhenbin <[email-masked]>
Date: Thu, 21 Nov 2013 03:52:06 +0000

Hi Jakob,
I do not think so. As I mentioned in the former mail, I can go on to explain the scenarios:
1. Statically configure label range and the allocated label for VPN: For the mobile backhaul network mentioned in draft-li-mpls-seamless-mpls-mbb-00, the mobile traffic model is always HUB-SPOKE which is easy to deploy label sharing. And traditionally NMS is used to deploy service. That is why MPLS-TP is proposed for mobile backhaul network. I think even the simplest configuration method can be widely adopted in mobile backhaul network.
2. Statically configure label range and ICCP-based label allocation for VPN: For the existing partial-mesh network such as metro Ethernet network, MC-TRUNK and ICCP are widely used to provide protection for L2VPN PEs. Similarly the ICCP-based method can also be used for L3VPN.
3.Global label allocation by the central controller: For the full mesh network, RR is always used to simplify BGP peers and route distribution. With the central control point--RR, the global label can be allocated to simplify the label sharing.

As to existing IP network deployment, we think the method can be widely used. Regarding the future label allocation and global label allocation, the similar challenge has been being proposed and solutions are being proposed now in IETF. For example, segment routing proposes the static configuration of label range on network nodes and global label allocated. Comparing SR, label sharing is just to configure PEs instead of all nodes in the network, which is less complex.

Thanks,
Robin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Jakob Heitz
发送时间: 2013年11月19日 0:06
收件人: Eric Osborne (eosborne)
抄送: UTTARO, JAMES; [email-masked]; Stewart Bryant (stbryant)
主题: Re: Why we consider the method of "label sharing for fast PE protection"

We are on the same page.
I misinterpreted your :)

--
Jakob Heitz.

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 21 Nov 2013 20:09:08 +0000

What if the primary PE comes online after the backup?
What label should the backup use if it can not reach the primary?

You need to think about partitioned networks too.
It's not as simple as you think.

-- Jakob.

-----Original Message-----
From: Lizhenbin [mailto:[email-masked]]

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 21 Nov 2013 20:17:16 +0000

As I stated before an operational section that anticipates running the network would be useful in this discussion. I would like to see various scenarios, restrictions, failure modes etc..

Jim Uttaro

-----Original Message-----
From: Jakob Heitz [mailto:[email-masked]] 
Sent: Thursday, November 21, 2013 3:09 PM
To: Lizhenbin; UTTARO, JAMES
Cc: [email-masked]; Stewart Bryant (stbryant)
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

-- Jakob.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 22 Nov 2013 09:55:59 +0000

> I am not sure I've got the point. Are your still talking about the label allocation issue? Could you please explain it more specifically?
Different equipment types and different s/w versions
use different label ranges for a specific purpose.

So, you need the same h/w version and the same
s/w version and a co-ordination policy that may
well need to be domain wide to be able to use
an identical label on two separate PEs.
> PEs can reserve some label ranges to be shared before they boot up. Then it becomes easy for an RG to figure out a common range.

Only if the equipment type is the same. h/w varies
as to label base and range.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 22 Nov 2013 10:00:38 +0000

> 1. since the protection is based on multi-homing or dual-homing scenarios, according to my experience on the network deployment design of carriers, they always use the devices with similar capacity…

That may be the case, assuming that all PEs need the same capacity.

Now consider one generation later, different equipment different
vendors.....

- Stewart

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 25 Nov 2013 07:41:25 +0000

Hi Jim & Jakob,

I think you proposed a valid point. If we continue this proposal, we should include an operational section. I believe this point applies to all such kind of "fast egress PE node protection" schemes. 

>You need to think about partitioned networks too.

If two PEs can reserved a label space to be used as the label range for sharing, the proposal is workable. However, we can slightly relax this constraint, i.e., PEs in an RG MUST reserve one label space for sharing. The PEs in an RG just need a common available label range, right? There are various ways to achieve this. For example, we can divide the label spaces into several blocks beforehand. Give them priorities. When PEs locally allocate labels, blocks with the higher priority will be used earlier. Then PEs in an RG can agree on those common blocks with lower priorities. This relaxation introduces flexibility. Imagine the case that an operator may be not sure about the size of the label space to be reserved at the beginning. In this way, even the primary come online after the backup, it can negotiate a label range for sharing with the backup. 

At last but not least, even if PEs cannot find a common label range in the worst case or the network is partitioned, the ICCP connection will not be established. In this case, the PEs just fall back to the non redundant mode. So the two scenarios proposed by Jakob can be handled.

Anyway, I don't think there is no way to achieve such proposal.

Thanks,
Mingui

>From: L3VPN [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
>Sent: Friday, November 22, 2013 4:17 AM
>To: Jakob Heitz; Lizhenbin
>As I stated before an operational section that anticipates running the network
>would be useful in this discussion. I would like to see various scenarios,
>restrictions, failure modes etc..
>
>Jim Uttaro
>
>It is not like this way. For the ICCP-based label allocation method, the primary PE
>is allocate the label for VPN by its own label allocation algorithm. The backup PE
>is just to allocate the label specified by the primary PE. The process is just like
>label backup. They need not use the same label allocation algorithm.

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 25 Nov 2013 07:41:53 +0000

Hi Stewart,

>as to label base and range.

At least we know that the proposal is feasible for PEs with the same h/w.

For PEs with different h/w, it's still possible that they can find out a common block. 

If they cannot find a common block, the connection between them will end up with failure, then they have to fall back to the non-redundant mode.

Thanks,
Mingui

>Sent: Friday, November 22, 2013 5:56 PM
>To: Mingui Zhang; Jakob Heitz; Eric Osborne (eosborne)
>Cc: UTTARO, JAMES; [email-masked]

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 25 Nov 2013 17:13:24 +0000

You missed my point. I asked about a single label. You answered a label block question.

--
Jakob Heitz.

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 26 Nov 2013 06:18:09 +0000

Hi Jakob,

Oh, sorry for the misunderstanding. 

So you advised we consider how to handle the label allocation exceptions. Compared to the long duration of label usage, the allocation happens instantly. Once the label is allocated, PEs should keep using it even the network is partitioned. Let's distinguish the exceptions happen in label usage and label allocation. Exceptions on label allocation must be rare. For these rare cases, operators are responsible to fix the label allocation exceptions.

>From the side of the network devices, PE should be clear which VPNs should be protected at the first place. When the primary PE allocates the sharing label for each VPN, the backup should acknowledge it. If the allocation fails, an exception should be reported.

[Primary after backup] If the backup PE comes online first and already used some labels without considering the protection. Afterwards, the primary PE comes online and operators must have them work in redundant mode. Then operators should be ready to modify labels allocated by the backup to achieve the label sharing proposal. Let's consider another possibility, suppose operators intentionally need the "backup" PE be online first and the "primary" be online later. The "backup" can locally assign a label from the sharing block. When the "primary" comes online afterwards, it should reuse the label that the "backup" used.
[Network is partitioned so backup cannot reach primary] Suppose operators have the primary and backup online at the same time. The primary and backup are responsible to establish the ICCP connection with each other. If the primary/backup cannot be reached, an exception should be reported.

Please correct me if I'm wrong.

Thanks,
Mingui

>Sent: Tuesday, November 26, 2013 1:13 AM
>To: Mingui Zhang
>Cc: UTTARO, JAMES; Lizhenbin; [email-masked]; Stewart Bryant (stbryant)
>> I think you proposed a valid point. If we continue this proposal, we should
>include an operational section. I believe this point applies to all such kind of "fast
>egress PE node protection" schemes.
>>
>> If two PEs can reserved a label space to be used as the label range for sharing,
>the proposal is workable. However, we can slightly relax this constraint, i.e., PEs
>in an RG MUST reserve one label space for sharing. The PEs in an RG just need a
>common available label range, right? There are various ways to achieve this. For
>example, we can divide the label spaces into several blocks beforehand. Give
>them priorities. When PEs locally allocate labels, blocks with the higher priority
>will be used earlier. Then PEs in an RG can agree on those common blocks with
>lower priorities. This relaxation introduces flexibility. Imagine the case that an
>operator may be not sure about the size of the label space to be reserved at the
>beginning. In this way, even the primary come online after the backup, it can
>negotiate a label range for sharing with the backup.
>>
>> At last but not least, even if PEs cannot find a common label range in the worst
>case or the network is partitioned, the ICCP connection will not be established.
>In this case, the PEs just fall back to the non redundant mode. So the two
>scenarios proposed by Jakob can be handled.
>>
>>> As I stated before an operational section that anticipates running
>>> the network would be useful in this discussion. I would like to see
>>> various scenarios, restrictions, failure modes etc..
>>>
>>> Jim Uttaro
>>>
>>> It is not like this way. For the ICCP-based label allocation method,
>>> the primary PE is allocate the label for VPN by its own label
>>> allocation algorithm. The backup PE is just to allocate the label
>>> specified by the primary PE. The process is just like label backup. They need
>not use the same label allocation algorithm.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 Nov 2013 12:31:42 +0000

> If they cannot find a common block, the connection between them will end up with failure, then they have to fall back to the non-redundant mode.
The success of the IETF protocol suite sits on a policy of
establishing protocol invariants and designing our
protocols withing the constraints of those invariants.

It is an MPLS invariant that: the label range supported
is a private matter, and you seem to wish to break
that invariant. That is a bad idea.

Sure you can make this work if the h/w is compatible
in an unspecified (in MPLS) way, but that mortgages
the future of the network that this will be deployed
in, and I do not think that is something the IETF
should support.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Nov 2013 16:11:42 +0100

Hi Stewart,

> that invariant. That is a bad idea.

Well let's be fair ... there is nothing wrong with using global/domain
wide labels. As you know segment routing mpls forwarding is based on
that too.

I think using same application label for reasons stated before is not
trivial, if so we should ask for given VPN_ID a PCE/SDN like device to
return same label for N PEs attached to such VPN. Maybe for the
disjoined label ranges it would not be supported.

Moreover the granularity could be more then per vrf.

Practically we already have solution for this problem using context
labels and personally I do not find sufficient need for another
solution for the exact same problem.

But I - as someone involved with MPLS for a long time - do not find
the principle of MPLS label to be of only local significance to the
node which allocated it  to be sufficient reason to limit one's
innovation of using mpls label in new and novel ways.

Best regards,
R.

On Tue, Nov 26, 2013 at 1:31 PM, Stewart Bryant <[email-masked]> wrote:
>> If they cannot find a common block, the connection between them will end
>> up with failure, then they have to fall back to the non-redundant mode.
>>

---

From: Eric Gray <[email-masked]>
Date: Tue, 26 Nov 2013 15:17:06 +0000

R,

	I agree with Stewart and find nothing particularly appealing about any form
of "innovation" that makes a proposed approach simpler at a cost of making deployed 
implementations more complex.

--
Eric

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 26, 2013 10:12 AM
To: [email-masked]
Cc: UTTARO, JAMES; [email-masked]
Subject: Re: Why we consider the method of "label sharing for fast PE protection"

Hi Stewart,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Nov 2013 16:20:00 +0100

E,

I think you have misunderstood.

What do you refer as "deployed implementations" as more complex in the
light of using notion of global label in segment routing ?

That was my point regarding innovation in local vs global label
allocation paradigm.

r.

---

From: Eric Gray <[email-masked]>
Date: Tue, 26 Nov 2013 16:02:09 +0000

Possibly, I have misunderstood.  :-)

Stewart made the point that allocation of labels is the business of the device that
needs to interpret them.

I agree with this.

You seemed to argue that this is not necessary, saying that you:

  "do not find the principle of MPLS label to be of only local significance to the
    node which allocated it  to be sufficient reason to limit one's innovation of 
    using mpls label [SIC] in new and novel ways."

The way that I understand this statement is that you feel that it is okay to make
most currently deployed MPLS implementations (which currently operate based on 
the "principle" that they are mostly free to allocate labels on whatever basis they 
later will use to interpret them) change this fundamental operating principle to suit 
arbitrary "novel" approaches.

My further understanding - based on this - is that you feel that complicating existing
and deployed implementations in favor of some arbitrary set of "novel" approaches 
is okay.

Since it is not impossible to support arbitrarily many uses with currently deployed
implementations, it seems likely that the reason to suggest different approaches 
is to simplify some proposed "novel" approach (or set of approaches).

This is certainly not a new idea.  This gets proposed by someone every few months.

So, the ongoing issue with these proposals is simply this: without a very compelling 
reason to do so - specific to any proposal in question - changing the paradigm used 
in allocating labels to suit that proposal should not be given serious consideration.
Otherwise, existing implementations would be continually at risk of being required
to support arbitrary and increasingly complex "novel" semantic interpretations of
the labels they allocate.

In my understanding, the yardstick against which to measure the degree to which 
any "novel" proposal is compelling is to consider it in comparison to similar proposals
made in the past, against the degree to which the proposed approach is actually
needed, against the finite resources that will be consumed (such as demultiplexing
code points - e.g. - Ethertypes, etc.) and the complexity required to support it in an
existing implementation.

To date, the only proposal (I am immediately aware of)  that has measured up using 
this yardstick is the need to provide for upstream allocation to support P2MP LSPs.

If the above understanding is incorrect, please feel free to tell me in what way I have
misunderstood you.

--
Eric

PS - I addressed my previous mail to "R" as that was how you signed the mail to 
which I was responding.  If you wish to address replies to "E", that is fine with me,
but it is not how I have indicated that I wish to be addressed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 26, 2013 10:20 AM
To: Eric Gray
Cc: [email-masked]; UTTARO, JAMES; [email-masked]
Subject: Re: Why we consider the method of "label sharing for fast PE protection"
Importance: High

E,

r.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Nov 2013 17:32:18 +0100

Hi Eric,

> the labels they allocate.

I am actually not sure what you mean by "existing implementations" In
none of the proposals there is any change suggested to "existing
implementations" both control or data plane as far as processing the
labels.

Where I am getting to is that we do see growing need for opening APIs
for label allocations. I2RS is a good protocol example which can
support it. That's it. Today depending on applications labels are
allocated from a local pool via local function call.

The same function call could be remote to SDN controller or PCE and I
do see some benefits. In fact such allocation mode could be push/pull.

This does break original local label significance of MPLS what Stuart
based his point on - and that was what I reacted to as something I do
not agree with in principle.

Best,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 26 Nov 2013 16:56:20 +0000

To my understanding, one reason for the private allocation invariant of MPLS is that all the participating entities can boot up and down in any order or not at all and the system "just works" without any careful configuration.

--
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Nov 2013 18:05:09 +0100

True ..

But one can't escape from "careful configuration" .. imagine if you
would assign wrong IP addresses to interfaces :) So allocating VPN X
for given VRF in the config is at the end not that hard. After all in
any decent size configuration of any router and it's deltas are all
automated and scripted.

I think to conclude if MPLS folks will keep protecting the original
MPLS assumptions we will see more and more transition to VXLAN or
NVGRE where application demux is no longer required to be of the magic
4 letters 20 bits .....

Would that simplify existing products ?

Best,
r.

---

From: Eric Gray <[email-masked]>
Date: Tue, 26 Nov 2013 17:24:16 +0000

Hmmm.  Maybe we're arguing semantics in more than one way.

The simplest (i.e. - proof of concept) approach to label allocation is that an LSR
plugs label interpretation information into a row in a table, and gives the row 
number as the label.  This doesn't necessarily have to happen in this order, but
an LSR cannot properly interpret a label allocated in this way until it has created
the row - hence it will not normally allocate and distribute the label until it has
completed the corresponding row-entry.

Architecturally, this "table" corresponds to (at least) the ILM (RFC 3031).  In a
very simple implementation, this row may combine both ILM and NHLFE.

A very simple implementation (consistent with the model referenced above)
may only support a smaller subset of the possible 1M rows in its table, hence 
asking this implementation to provide a specific label that may fall outside of a
limited range will not work.  In addition, asking this LSR to allocate any specific 
label - even from within the supported range - either risks a collision with that
label (if already allocated for some other purpose) or a sparse population of
table rows and a need to track which labels have already been given, and will
result in complicating the allocation process by fragmenting row population.

One reason to "protect" this reference implementation approach is that it can
(quite quickly) become difficult to justify use of MPLS at all if implementations
using this (or a similar) approach are not allowed (or become significantly less
than optimal) because of subsequent proposals.

If I end up having to do a CAM lookup to find the row corresponding to a label, 
it is not clear at all why I don't just do a CAM lookup for key fields in the IP 
header.

If you're talking about making the (commonly used) internal allocation function
available to a higher-layer entity, that doesn't break this paradigm at all.   But I
would not get that from your earlier mail, nor would I be able to determine -
based on this - how this is inconsistent with Stewart's comment.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 26, 2013 11:32 AM
To: Eric Gray
Cc: [email-masked]; UTTARO, JAMES; [email-masked]
Subject: Re: Why we consider the method of "label sharing for fast PE protection"
Importance: High

Hi Eric,

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Nov 2013 18:53:55 +0100

Hi Eric,

Indeed we are getting into as multi-dimentional thread :)

Stewart comment was to protect local significance of a label. Label X
allocated by node N must be only used by node N. That is something I
commented on.

You on the other hand are more worried about allocation algorithm
chosen by given implementation. I think both are quire orthogonal
aspects. I can see that without breaking any of your model I could
still use label X to be meaningful on more then single node.

Simply I allocate a block of L labels (even in the table model by null
prepopulation of the table) and give to higher application to use such
block. That is all fine and I do not think we are in any discussion
breaking that.

Regards,
R.

---

From: <[email-masked]>
Date: Thu, 28 Nov 2013 09:38:01 +0000

Hi Mingui,

Please find my comments inline [Bruno2]

>From: Mingui Zhang [mailto:[email-masked]] >Sent: Monday, November 18, 2013 10:32 AM
>
>Hi Bruno,
>
[...]
>[Mingui] That is a misinterpretation. Actually, all 5 PEs share the same
>label range (e.g., 1~1100) rather than dividing the label space. There is no
>scaling issue.

[Bruno2] Let's assume:
- 5 PE in the group, hence sharing the same range of labels (e.g., 1~1100).
- 5 VPNs in connect to this group of PE, 2 of which being dual-homed (VPN1 & VPN2).

With label sharing:
Label:1	2	3	4	5

PE1	VPN1	x	x	x	x	
PE2	VPN1	VPN2	x	x	x
PE3	x	VPN2	x	x	x	
PE4	x	x	VPN3	x	x
PE5	x	x	x	VPN4	VPN5

All labels marked as "x" are burned/lost because of the label sharing.

Without label sharing:
Label:1	2	3	4	5

PE1	VPN1					
PE2	VPN1	VPN2			
PE3	VPN2	VPN2				
PE4	VPN3	 			 
PE5	VPN4	VPN5	 	 	 

Here no label is lost.

So, in that specific example, 7 labels*PE are used out of 25 while 18 are lost.
Hence you need/use a label space which is 3.5 times bigger. (25/7)

>[Mingui] As explained above, it does not need multiple lookup. Remember, we
>do not want to change the forwarding plane.

[Bruno2] I was referring to a different draft: draft-renwei-l3vpn-big-label-00

>[Mingui] On one hand, the above extreme case happens only in theory. The
>reason we scope the document to talk about 2 PEs is that duel homing is the
>BCP. Think about the real deployment, I believe most POPs will use two PEs
>for the redundant connection. On the other hand, even if you have 5 PEs in
>one POP, just put them into one RG. Therefore, the increase of the number of
>states in the IGP is not so big.
>
>[Mingui] But I agree with your advice that we can spend some words to
>address this scaling issue in the document.

[Bruno2] ok, thanks.

>[Mingui] OK. How about the local-repair and label-retention technique? With
>that technique, the primary PE may cache the route advertised by the backup
>PE and use it when the route it learns from the CE fails. I guess this issue
>is kind of off the track. We can talk more about it between us two.
>
>[Mingui] For those legacy products, operators can update their software.

[Bruno2] not always. There is public/ietf example for this: draft-l3vpn-legacy-rtc-00

Bruno

> If
>bare legacy PEs and label-sharing PEs are interconnected, ICCP connection
>will not be established. It allows PEs falls back to the non-redundant
>connection. For those label-sharing PEs from different vendors, if they
>implement the same RFC, they are supposed to be interoperable.
>
>[Mingui] The central protector is delegated as the PLR, right? This further
>reduces the coverage of LFA. As we know, a free LFA can have any router as
>the PLR.
>
>Thanks,
>Mingui

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 29 Nov 2013 02:16:20 +0000

Hi Bruno, 

So you suppose the label used in an RG cannot be used again out of the RG. That is not correct.
Please find my comments inline [Mingui].

<snip>
>All labels marked as "x" are burned/lost because of the label sharing.

[Mingui] Not true. Where we got this constraint? For an explicitly example, PE4 can well use label 1,2,4,5. 

[Mingui] I anticipate you assume PE1~PE5 are forming an RG, so that once a label is used it is used across the RG. I need to point out that the unit of "RG" is independent of PEs. It depends on the VPN connections. I saw Zhou Peng has already given examples on this point. 

<snip>

>draft-l3vpn-legacy-rtc-00

[Mingui] It's designed to be incrementally deployable in the network. The trick is confined in the RG. Other P and PE routers are unaware of the change.

[Mingui] I guess you may change to imagine the scenario that operator need a legacy PE and a label sharing PE form an RG. Let's consider the analogy that the operator interconnects two switches using LAG while one of them does not support LAG at all. :) 

[Mingui] Thanks for continuing the discussion. I think the discussion about label ranges reservation in another thread is related to our discussion. To my understanding, the conclusion is that it's not OK to require a label block to be supported across multiple PEs. A possible escape is to resort to a higher-layer authorized entity out of the RG to assign the label.

Thanks,
Mingui

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 29 Nov 2013 05:53:45 +0000

I any PE is part of 2 RGs, then those RGs can not have overlapping label spaces. 

--
Jakob Heitz.

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 29 Nov 2013 06:49:27 +0000

Suppose RG1=(PE1,PE2) using label space 1~5, RG2=(PE2, PE3) using label space 6~10. So PE2 is in 2 RGs.
But, PE1 can well use label space 6~10 for other RG, say RG3 and PE3 can use label space 1~5 for RG4. 

Thanks,
Mingui
>Sent: Friday, November 29, 2013 1:54 PM
>To: Mingui Zhang
>Cc: [email-masked]; [email-masked]
>> [Mingui] I anticipate you assume PE1~PE5 are forming an RG, so that once a
>label is used it is used across the RG. I need to point out that the unit of "RG" is
>independent of PEs. It depends on the VPN connections. I saw Zhou Peng has
>already given examples on this point.
>>
>> <snip>
>>
>> [Mingui] It's designed to be incrementally deployable in the network. The trick
>is confined in the RG. Other P and PE routers are unaware of the change.
>>
>> [Mingui] I guess you may change to imagine the scenario that operator
>> need a legacy PE and a label sharing PE form an RG. Let's consider the
>> analogy that the operator interconnects two switches using LAG while
>> one of them does not support LAG at all. :)
>>
>> [Mingui] Thanks for continuing the discussion. I think the discussion about label
>ranges reservation in another thread is related to our discussion. To my
>understanding, the conclusion is that it's not OK to require a label block to be
>supported across multiple PEs. A possible escape is to resort to a higher-layer
>authorized entity out of the RG to assign the label.
>>
>> Thanks,
>> Mingui

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 08:13:45 +0000

Hi Mingui,

Please see inline.

>From: Mingui Zhang [mailto:[email-masked]] >Sent: Friday, November 29, 2013 3:16 AM
>
>Hi Bruno,
>
>So you suppose the label used in an RG cannot be used again out of the RG.

No I'm not. My assumptions were indicated at the beginning of the email. I assumed: "5 PE in the group, hence sharing the same range of labels". By "group" I meant "redundant group" if that was the unclear point.
 
>That is not correct.
>>- 5 VPNs in connect to this group of PE, 2 of which being dual-homed (VPN1
>&
>>VPN2).
>>
>>With label sharing:
>>Label:1	2	3	4	5
>>
>>PE1	VPN1	x	x	x	x
>>PE2	VPN1	VPN2	x	x	x
>>PE3	x	VPN2	x	x	x
>>PE4	x	x	VPN3	x	x
>>PE5	x	x	x	VPN4	VPN5
>>

The 5 PE are in the same RG.

>
>[Mingui] I anticipate you assume PE1~PE5 are forming an RG,

Correct.

> so that once a
>label is used it is used across the RG. I need to point out that the unit of
>"RG" is independent of PEs. It depends on the VPN connections. I saw Zhou
>Peng has already given examples on this point.

OK. I know the proposition is flexible:
- You can increase the number of PE in the RG which, from a scaling standpoint, reduce the number of Virtual Next-Hop which is good, but waste VPN/MPLS label space, which is not good.
- Or you can go the opposite way, with the opposite trade off.

The point is that whatever option you pick, there is a scaling impact in the network. You document should discuss this. (rather than assuming the simple case: there are only 2 PE in the POP, and both support this solution)

>[Mingui] It's designed to be incrementally deployable in the network. The
>trick is confined in the RG. Other P and PE routers are unaware of the
>change.
>
>[Mingui] I guess you may change to imagine the scenario that operator need a
>legacy PE and a label sharing PE form an RG. Let's consider the analogy that
>the operator interconnects two switches using LAG while one of them does not
>support LAG at all. :)

Whatever the analogy, this does not change the fact that your solution requires interoperability with the PE to be protected, not to mention a new label allocation scheme that people are reluctant to use. Hence it will be difficult to deploy in a multi-vendor network having legacy PEs.

Bruno

>[Mingui] Thanks for continuing the discussion. I think the discussion about
>label ranges reservation in another thread is related to our discussion. To
>my understanding, the conclusion is that it's not OK to require a label
>block to be supported across multiple PEs. A possible escape is to resort to
>a higher-layer authorized entity out of the RG to assign the label.
>
>Thanks,
>Mingui