Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label

<stephane.litkowski@orange.com> Sat, 03 August 2013 19:08 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4321E809E for <rtgwg@ietfa.amsl.com>; Sat, 3 Aug 2013 12:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.111
X-Spam-Level:
X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=2.055, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q0=0.303, 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 uNULuQcSdQlP for <rtgwg@ietfa.amsl.com>; Sat, 3 Aug 2013 12:08:32 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 82E3C21F9FC8 for <rtgwg@ietf.org>; Sat, 3 Aug 2013 12:08:31 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4F78422CD8C; Sat, 3 Aug 2013 21:08:30 +0200 (CEST)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 327E24C171; Sat, 3 Aug 2013 21:08:30 +0200 (CEST)
Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Sat, 3 Aug 2013 21:08:30 +0200
From: stephane.litkowski@orange.com
To: "stbryant@cisco.com" <stbryant@cisco.com>
Date: Sat, 03 Aug 2013 21:08:25 +0200
Subject: Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label
Thread-Topic: Remote LFA path length to PQ : draft-shen-mpls-ldp-nnhop-label
Thread-Index: Ac6QfNRY+GaCPX6xRiSIxGxZ7qr/Ag==
Message-ID: <7058_1375556910_51FD552E_7058_10647_1_EEE55384044474429A926C625D0FCC81095908C351@PUEXCB2F.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81095908C351PUEXCB2Fnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.3.173916
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2013 19:08:37 -0000

Hi Stewart,


Regarding your comment during RTGWG on resurrecting draft-shen-mpls-ldp-nnhop-label, here are the results of the path length to the best PQ using remote LFA node protection draft algorithm :

Path len to PQ  T1      T2      T3      T4      T5      T6
2 hops  98,78%  90,63%  90,55%  83,90%  99,86%  100,00%

The results are pretty good, showing that most of the time the PQ is two hops away, but there is still some situations where the PQ is more far, leading to the need of tldp session. The analysis was done on 6 topologies (different network size, network design ...), but may be the results could be worst on some other types of topologies.

IMHO, it would not be a good idea to mix two different mechanism with remote LFA (establishing TLDP session or using nnhop label) as it may complexify the code. Moreover using nnhop label, we could imagine some situation where first the PQ is two hops way leading the PLR to request NNHOP label and then due to an event (metric change ?), the path to the PQ becomes 3 or 4 hops away. This kind of situation would be hard to manage, so I would propose as simplicity to keep TLDP. Moreover implementing segment routing procedures would permit to avoid TLDP sessions in a near future as described in STATUS BOF.


Best Regards,

Stephane

_________________________________________________________________________________________________________________________

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.