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

[<[e-mail]>]

The TI-LFA draft is not really clear today about the Mathematics :)
At least it requires one SPF rooted at PLR per neighbor considering the neighbor has failed.

De : Pushpasis Sarkar [mailto:[e-mail]]
Envoyé : mardi 18 mars 2014 18:12
À : DECRAENE Bruno IMT/OLN; [e-mail]
Cc : [e-mail]; Alvaro Retana (aretana)
Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Hi Bruno,

Many many thanks for your thoughts. Please find some comments inline with [Pushpasis]

Thanks
-Pushpasis

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Tuesday, March 18, 2014 10:07 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Alvaro Retana (aretana)
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

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?
[Pushpasis] We have gone through the TI-LFA and draft, and to the best of my understanding this requires a CSPF for each destination node in the network with the primary link as well as primary-nexthop node as exclude constraints for finding a backup path(if feasible) all the way to the destination. This will need far more computation than 1 forward SPF per PQ-nodes. Obviously it has the advantage of finding 100% of all possible node-protecting backup paths. With 16 PQ-nodes selected on the basis of the default heuristic suggested in this draft it was seen to find ~96-97% of all possible node-protecting backup paths on some of the common SP topologies we have run a simulation on. Adding so much of extra computation to achieve rest 3% of feasible node-protecting backup paths seemed insignificant and not worth exploring.

Clearly, using TI-LFA in the absence of Segment Routing (more precisely the absence of adjacency segments/labels), 100% coverage is not possible.
[Pushpasis] My understanding is that since with TI-LFA we are going to run CSPF for each destination, we will find 100% of all the feasible node-protecting paths to each destination. There may be destinations for which there are no feasible/possible node-protecting backup paths at all. Those destinations cannot be covered because there is no possible node-protecting backup paths for them.

But this is also not possible with draft-psarkar.
[Pushpasis] True. Like Stephane mentioned already, it is a tradeoff :)

It's a priori not clear to me if the coverage would be increased or decreased.
[Pushpasis] Obviously with TI-LFA will provide more coverage, like I explained above. But that will come at the cost of lot of extra computational overhead of running a lot of CSPFs.
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).
[Pushpasis]Looks like you are referring to protection of MPLS traffic. I hope you remember that this draft also applies to IP-FRR.


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).
[Pushpasis] Not sure if I got what you are trying to say here. But, I think it will be best to not bring in TI-LFA in this. This draft was intended to cover the lack of node-protection in the original RLFA draft and address the need of some of the network deployments which still need node-protection to be guaranteed. The intention of using a heuristic is to choose a subset of all PQ-nodes found in the network and restrict the number of FSPFs to a maximum number, and still achieve a hight percentage of coverage with the same subset of PQ-nodes.

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[e-mail]] On Behalf Of Alvaro Retana (aretana)
Sent: Friday, March 14, 2014 6:02 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.

_________________________________________________________________________________________________________________________

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.