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

["UTTARO, JAMES" <[e-mail]>]

So the draft speaks to as you say "most cases" and you have determined this by?? Here is another example, there are customers that actually demand multi-homing of attachment circuits to PEs in different POPs to avoid catastrophic outages. There would be additional operational concerns revolving around capacity mgmt. of PEs.  Although I have concerns about scaling, I am as much if not more concerned about how this would add an order of complexity to managing the network. 

Jim Uttaro

-----Original Message-----
From: Zhoupeng (Jewpon) [mailto:[e-mail]] 
Sent: Thursday, November 28, 2013 9:23 PM
To: UTTARO, JAMES; [e-mail]
Cc: [e-mail]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

I don't exclude the case you said. I just said "in most cases".
Because every PEs multi-homed to by a customer even have to allocate a label for the customer without this draft, more PEs in a POP doesn't negate the conclusion: " The labels amount needed will not significant increase due to the draft ".

regards，
Zhou Peng

-----Original Message-----
From: UTTARO, JAMES [mailto:[e-mail]] 
Sent: November 29, 2013 0:20
to: Zhoupeng (Jewpon); [e-mail]
Cc: [e-mail]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

Hmm.. So my first thought here is that we are now basing the performance of this technology on assumptions about how customers are homed to PEs, this essentially becomes a gating factor. I can tell you that there are features that customers utilize which spread attachment circuits for a given VPN among more than two PEs in a POP. Utilizing load balancing and diversification designs attachment circuits for a given VPN to be spread across 6 PEs in a given POP. Have you canvassed SPs about how spreading for a VPN is done or is the scenario described below a hope/wish? Instead of guessing it would be better to get facts.

-----Original Message-----
From: L3VPN [mailto:[e-mail]] On Behalf Of Zhoupeng (Jewpon)
Sent: Thursday, November 28, 2013 6:20 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: Why we consider the method of "label sharing for fast PE protection"

Hi, Bruno,
First, 5 PEs in a POP hardly happens in real world. In most cases, there are two PEs in a POP which usually lie in different places for the sake of disaster tolerant.
Then, the RG can be design as below: 
    PE1 and PE2 in RG1 which server VPN1, VPN1 use label L1,say 100;
    PE2 and PE3 in RG2 which server VPN2, VPN2 use label L2,say 101; Label 100 and 101 can be allocated from pre-allocated label block, say 100-4000.
VPN3 to VPN5 is not dual-homed, so the label are allocated as usual, for example: 
    PE4 allocates label 100011 for VPN3,
    PE5 allocates label 100011 for VPN4,
    PE5 allocates label 100012 for VPN5, The labels used by PE5 for VPN4,VPN5 are not related with labels on PE1 and PE2.
Even if there is VPN6 which is dual-homed to PE3 and PE4, the label 100 can be used for the VPN6 as long as it is not used by other VPN or other services on PE3 and PE4. PE3 and PE4 no need to perceive how PE1/PE2 allocate their labels. So the shared label is only limited to the RG members.

In extreme case, Suppose : 
    VPN1 is dual-homed to PE1 and PE2;
    VPN2 is dual-homed to PE2 and PE3;
    VPN3 is dual-homed to PE3 and PE4;
    VPN4 is dual-homed to PE4 and PE5;
    VPN5 is dual-homed to PE5 and PE1;
We can design as below:
    PE1 and PE2 in RG1 for VPN1 and use label L1,say 100;
    PE2 and PE3 in RG2 for VPN2 and use label L2,say 101;
    PE3 and PE4 in RG3 for VPN3 and use label L1,say 100;
    PE4 and PE5 in RG4 for VPN4 and use label L2,say 101;
    PE5 and PE1 in RG5 for VPN5 and use label L3,say 102; So, PE1 need 2 labels: 100, 102
   PE2 need 2 labels: 100, 101
   PE3 need 2 labels: 100, 101
   PE4 need 2 labels: 100, 101
   PE5 need 2 labels: 101, 102
The label 100 on PE5 cannot be shared between PE1 and PE5,but it can still be used for other RG, for example, RG6 between PE5 and PE3, if there is new VPN dual-homed to PE5 and PE3.

In a word, the shared label is not-so-globe and limited in the specified RG members. The labels amount needed will not significant increase due to the draft.

regards，
Zhou Peng

Date: Thu, 28 Nov 2013 09:38:01 +0000
From: <[e-mail]>
To: Mingui Zhang <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Why we consider the method of "label sharing for fast PE
	protection"
Message-ID:
	<32614_13856314[e-mail]>
	
Content-Type: text/plain; charset="us-ascii"

Hi Mingui,

Please find my comments inline [Bruno2]

>From: Mingui Zhang [mailto:[e-mail]] >Sent: Monday, 
>November 18, 2013 10:32 AM
>
>Hi Bruno,
>
>Please find my comments inline below [Mingui].
>
[...]
>
>>[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.
>
>[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)

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


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

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

[Bruno2] ok, thanks.

><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.
>>
>>[Bruno] Good point. So you probably should add this to the document.
>
>[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.

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

_________________________________________________________________________________________________________________________

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.



------------------------------

Subject: Digest Footer

_______________________________________________
L3VPN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3vpn


------------------------------

End of L3VPN Digest, Vol 113, Issue 32
**************************************