Re: [mpls] maturity of the MRT technology

<stephane.litkowski@orange.com> Thu, 04 December 2014 10:37 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9589E1A01AA; Thu, 4 Dec 2014 02:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtrPPNTYSfl0; Thu, 4 Dec 2014 02:37:10 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79D71A0146; Thu, 4 Dec 2014 02:37:09 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EFAD03B4529; Thu, 4 Dec 2014 11:37:07 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C36A82380A0; Thu, 4 Dec 2014 11:37:07 +0100 (CET)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 11:37:07 +0100
From: stephane.litkowski@orange.com
To: Yakov Rekhter <yakov@juniper.net>
Thread-Topic: [mpls] maturity of the MRT technology
Thread-Index: AQHQDwT05s13BieLpE2AHYP0TmNrfpx/Oe4w
Date: Thu, 04 Dec 2014 10:37:07 +0000
Message-ID: <29576_1417689427_54803953_29576_3299_1_9E32478DFA9976438E7A22F69B08FF920C73E8FF@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <201412031424.sB3EOtR80359@magenta.juniper.net>
In-Reply-To: <201412031424.sB3EOtR80359@magenta.juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.4.95723
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-64HgqImQPMv1zqLl3EPcigNmcw
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-atlas-mpls-ldp-mrt@tools.ietf.org" <draft-atlas-mpls-ldp-mrt@tools.ietf.org>
Subject: Re: [mpls] maturity of the MRT technology
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 10:37:12 -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:yakov@juniper.net] 
Sent: Wednesday, December 03, 2014 15:25
To: LITKOWSKI Stephane SCE/IBNF
Cc: Uma Chunduri; Alia Atlas; Loa Andersson; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-atlas-mpls-ldp-mrt@tools.ietf.org; rtgwg@ietf.org
Subject: Re: [mpls] maturity of the MRT technology 

Stephane,

On 23/11/2014 08:47, stephane.litkowski@orange.com 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.

_________________________________________________________________________________________________________________________

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.