Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

<stephane.litkowski@orange.com> Tue, 27 March 2012 09:05 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D498221F88FC; Tue, 27 Mar 2012 02:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF-KhpxvIPPu; Tue, 27 Mar 2012 02:05:00 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9221F88D4; Tue, 27 Mar 2012 02:04:57 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E9F1622C0BB; Tue, 27 Mar 2012 11:04:56 +0200 (CEST)
Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CF52E23806C; Tue, 27 Mar 2012 11:04:56 +0200 (CEST)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:04:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Mar 2012 11:04:55 +0200
Message-ID: <17281_1332839096_4F7182B8_17281_1356_1_4FC3556A36EE3646A09DAA60429F53350804C794@PUEXCBL0.nanterre.francetelecom.fr>
In-Reply-To: <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation
Thread-Index: AQH3RvAe49uYSLxVSIfvfdRukh0PXAKofSLMlhQac5CAAAOs0A==
References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com>
From: stephane.litkowski@orange.com
To: Ilya Varlashkin <ilya@nobulus.com>, IETF MPLS <mpls@ietf.org>, idr@ietf.org
X-OriginalArrivalTime: 27 Mar 2012 09:04:56.0953 (UTC) FILETIME=[AE691690:01CD0BF8]
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317
Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 27 Mar 2012 09:05:01 -0000

As said to you offline, I would be interrested with discussing about your testing, achieving tns of msec with convergence is something I don't really see in a real world (otherwise why should we implement TE FRR or LFA ??).

Regarding the paradigm of giving VPN info on P, yes I agree with your point, that is something to care about.
Globally the solution proposed, gives a per CE view at P router (not really per VPN) and I have some scaling concerns about it.

Today I'm not pushing this kind of solution as clearly it has some issues and brings concerns , I'm just interrested looking at it and see what could be the improvement that we could provide to some premium customers.
The improvement exists, but it must be clearly measured against scaling concern, interop with current FRR mechanism ...

As we are more discussing about the solution, rather than the LDP evolutions, I propose to move the discussion to IDR mailing list ...


-----Message d'origine-----
De : Ilya Varlashkin [mailto:ilya@nobulus.com] 
Envoyé : mardi 27 mars 2012 10:55
À : LITKOWSKI Stephane DTF/DERX; 'IETF MPLS'
Objet : RE: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation

> -----Original Message-----
> The best current available mechanism is BGP PIC Edge that relay on IGP 
> convergence to detect that remote PE is no longer reachable : PIC Edge
result
> mainly depends on how fast your IGP is converging (sub sec or more).
>

I've been recently measuring convergence on not very fast RP and found that even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlikely to be seen in many networks if in any at all. And for real-world sized nets convergence is like few tens of ms - not really to worry about.
 
> Ahmed solution is an FRR solution so doesn't rely on convergence. As 
> soon
as
> a P router detects that the link to the protected PE fails, it will 
> switch
(using
> pre-programmed backup NHLFE), so there you are in FRR numbers ... 
> 50msec
> - 100msec depending of implementation ...
> 

If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN, PWE, L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that contradicts with original idea of P nodes (they shouldn't care what's inside, only how to get to the edge independent of "payload").

> Clearly the solution is today complex, and I hope it could be a bit
simplified :)
>

Because of previous statement I see proposed solution as complication rather than simplification, and because of above mentioned IGP convergence times the gain seems to be too little when balanced against complexity.
 
/iLya


_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.