RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

<bruno.decraene@orange.com> Tue, 18 March 2014 16:37 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE4F1A06EA for <rtgwg@ietfa.amsl.com>; Tue, 18 Mar 2014 09:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yT2L_L3ImYpK for <rtgwg@ietfa.amsl.com>; Tue, 18 Mar 2014 09:37:26 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D29DF1A06F6 for <rtgwg@ietf.org>; Tue, 18 Mar 2014 09:37:25 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id D928EC022A; Tue, 18 Mar 2014 17:37:16 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BC4FC18004F; Tue, 18 Mar 2014 17:37:16 +0100 (CET)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 17:37:16 +0100
From: bruno.decraene@orange.com
To: "draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org" <draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org>
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection
Thread-Topic: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection
Thread-Index: AQHPP0J+1fYrM2rA6Ui8swo42YsDw5rm7aHQ
Date: Tue, 18 Mar 2014 16:37:15 +0000
Message-ID: <20825_1395160636_5328763C_20825_2806_1_53C29892C857584299CBF5D05346208A07119F80@PEXCVZYM11.corporate.adroot.infra.ftgroup>
References: <CF480575.5095C%aretana@cisco.com>
In-Reply-To: <CF480575.5095C%aretana@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A07119F80PEXCVZYM11corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.18.134216
Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/4uvuVlRe1xldeUnlzXTe64TWNdo
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Mar 2014 16:37:29 -0000

Hi authors,

This is an interesting work, thanks for the draft and the rtgwg presentation.


1)      Regarding node protection, have you considered/evaluated the use of the algorithm proposed in TI-LFA (draft-francois-segment-routing-ti-lfa)?
Namely: computing the backup path with a (C)SPF (without the protected node), and enforcing this explicit path using multiple segments/labels?
Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible. But this is also not possible with draft-psarkar. It's a priori not clear to me if the coverage would be increased or decreased. On the pro side, the use of multiple segments increases the coverage by allowing reaching more Q nodes. On the con side, the additional constraints added during the computation (namely enforcing the post convergence path (only)) decreases the coverage as this specific path may require an adjacency segment to cross a high metric link.
Evaluating this option would probably be interesting (in term of coverage, control plane computation, label stack depth, routing optimality, number of T-LDP sessions).


2)      On a related note, a possible heuristic for draft-psarkar to pick a node protecting PQ, would be to pick the PQ on the post convergence SPF (as per above/TI-LFA). That's simple, computationally not expensive (one SPF), and reduce the set of Candidate Node-Protecting PQ to a single element at most (not considering ECMP, to simply). If the set has one node, a node protecting PQ node has been found (on the optimal path, as a free property). If the set is empty, you may choose to fall back on draft-psarkar (picking a subset of PQ using heuristic and running SPF on those PQ).

Thanks,
Regards,
Bruno

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Friday, March 14, 2014 6:02 AM
To: rtgwg@ietf.org
Cc: draft-psarkar-rtgwg-rlfa-node-protection@tools.ietf.org
Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi!

During the meeting in London the authors asked for the WG to adopt this draft.

This message officially starts the call for adoption for draft-psarkar-rtgwg-rlfa-node-protection.  Please indicate your position about adopting it by end-of-day on March 28, 2014.

http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection

Thanks!

Alvaro.

_________________________________________________________________________________________________________________________

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.