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

[<[e-mail]>]

Hi Pushpasis,

Please find some comments inline with [Bruno]

Thanks,
Bruno


From: Pushpasis Sarkar [mailto:[e-mail]]
Sent: Tuesday, March 18, 2014 6:12 PM
To: DECRAENE Bruno IMT/OLN; [e-mail]
Cc: [e-mail]; Alvaro Retana (aretana)
Subject: 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.
[Bruno] TI-LFA has a 2 steps process:
- find the Post Convergence Path (assuming the protected element (node or link) has failed). This requires  1 CSPF rooted on the PLR, excluding the failed element. This single CSPF gives you the path for all destination (just like the regular IGP one)
- then we need to find how to enforce an explicit route toward each destinations. There are different ways to do this,  which may depend on your existing (r)LFA implementation. But as an example, you can compute the (regular) extended P space. Cost (so far...) is one SPF per neighbor  (just like for LFA). Then you explore your post convergence graph and "intersect" it with your extended P space and you get all the destinations, along the post convergence path, which are reachable with no additional encapsulation (à la LFA).
So far so good. To go further, you can use the RLFA trick: send the packet to a remote destination using encapsulation (IP or MPLS or whatever.) Those destinations are all farest Q nodes, along the post convergence path. Number of those nodes is topology dependent. According to Stéphane simulations, this is very manageable. Then you run a CSPF on those P nodes, so see what you destinations, along the post convergence path, you can reach via this P nodes. You can install those in you FIB, using the encapsulation required to reach the P (a la RLFA). According the Stéphane simultations (just sent) at this step you can expect 81%- 99% coverage, with guaranteed node protection and a single layer of encapsulation (label)
Then you can apply the same RLFA trick recursively, adding a layer of encapsulation each time (to get to the first P, then from the first P to the second...), until you have explored you complete CSPF/post convergence graph. Here, we see that MPLS is a better encapsulation as the header is shorter (4 octets) compared to an IPv4 or IPv6 encapsulation.
Without segment routing, when following your post convergence graph, there are high metrics links, that you will not be able to cross. (e.g. links with "infinity" metrics).

This will need far more computation than 1 forward SPF per PQ-nodes.
[Bruno] The number of CSPF is topology dependant so we will need simulation to compare. If your are limited by SPF computation, but may also prune some path along your post convergence SPF, at the cost of reduced coverage. (e.g. limiting the depth of the number of P nodes required to reach the destination, or pruning the sub-tree that the depth / destinations is too high.
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.
[Bruno] indeed, 16 CSPF is low, but Stéphane could probably get some result on its simulations. Or you could also evaluate yourself the TI-LFA algo on your topologies. Based on simulations I got, this seems manageable, but the more simulations, the better.
Note also the TI-LFA also provide the optimal backup path that RLFA/draft-psarkar does not provides.

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.
[Bruno] A single CSPF is enough to get all the path. Now we need to compute the list of P nodes on the path to each destinations and this requires more SPF. Should be much lower than one for all destinations.
Then we can't have 100% coverage since high metric links can't be crossed using regular IGP routing.
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.
[Bruno] IMO, it would be good to have simulations to compare both approach. But as it's would require you/Stéphane to do the simulation work, it really is up to you.
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.
[Bruno] indeed. But in the end, the performance of the solutions (in term of control plane CPU, coverage, path optimality, number of T-LDP sessions for LDP networks) is topology dependent hence seems difficult to compare without simulations. Hence my original question to see if you had explore this option.

Many thanks,
Bruno


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.