Subject: Re: [mpls] maturity of the MRT technology

From: Yakov Rekhter <[email-masked]>
Date: Wed, 3 Dec 2014 06:24:55 -0800

Stephane,

On 23/11/2014 08:47, [email-masked] wrote:
 
> Hi Uma,
>
> >Is this because of domain wide deployment requirements MRT brings-in 
> (as elaborated by Stewart?) or you are ok with LFA/rLFA coverage in 
> the network?
>
> No, domain-wide deployment is not an issue. The issue I see in MRT 
> (for my use case) is unoptimality of the FRR path (at least using 
> lowpoint algorithm). But anyway, as I mentioned, I'm not opposed to 
> make MRT progressing at all. It's good to have multiple tools.

While MRT may result in "unoptimality of the FRR path", why this
unoptimality really matters that much, given that FRR suppose to
be used for only a short period of time until IGP convergence?

Yakov.

---

From: <[email-masked]>
Date: Thu, 4 Dec 2014 10:37:07 +0000

Hi Yakov,

Thanks to point this important subject.

Consider the case where you have a link failure, it is easy for our customers to understand that their traffic have been impacted because the traffic was crossing the link that has failed.
Now, if to protect this link, we enable FRR and FRR path uses an "uncontrolled" path. When the link fails, traffic is switched to FRR path and may use some paths that is not well sized to handle this traffic.
This may create congestion on some links. Congestion will affect traffic that is not directly concerned by the failure, so customer will loss some traffic. For sure, the congestion duration will be bound to the convergence time (~seconds), but for some critical applications (that are not essential requiring LLQ -> so QoS may not fully help in this, in customer data class is congestionned), this is not acceptable. And customers cannot understand that they are impacted by an issue in another region of the world. (It's like the well known "Butterfly effect" :) )
This problematic is quite similar to the microloop one. Microloops are impacting traffic which is not directly concerned by the failure. And globally we already had complains for both issues (FRR using bad path and microloops).

Hope it helps to understand our concern.

Best Regards,

Stephane

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2014 15:25
To: LITKOWSKI Stephane SCE/IBNF
Cc: Uma Chunduri; Alia Atlas; Loa Andersson; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] maturity of the MRT technology 

Stephane,

> make MRT progressing at all. It's good to have multiple tools.

While MRT may result in "unoptimality of the FRR path", why this unoptimality really matters that much, given that FRR suppose to be used for only a short period of time until IGP convergence?

Yakov.

_________________________________________________________________________________________________________________________

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.