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

[<[e-mail]>]

Hi Mingui,


Please see inline.

>From: Mingui Zhang [mailto:[e-mail]] >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.
>Please find my comments inline [Mingui].
>
><snip>
>>[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.
>
>[Mingui] Not true. Where we got this constraint? For an explicitly example,
>PE4 can well use label 1,2,4,5.

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)

><snip>
>
>>[Bruno2] not always. There is public/ietf example for this:
>>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. :)

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

_________________________________________________________________________________________________________________________

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.