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

[Gábor Sándor Enyedi <[e-mail]>]

Hi Stephane,

When there is bidirectional traffic (which is the common case), it is possible that you can correct a failure only in one direction. Did you take that into consideration?
BR,

Gabor

From: rtgwg [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, March 18, 2014 6:47 PM
To: Pushpasis Sarkar; DECRAENE Bruno IMT/OLN; [e-mail]
Cc: [e-mail]
Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection

Here are primarly fresh results on 10 topologies with postconvergence path enforcement using only LFA/rLFA or LFA/rLFA+dLFA (1hop adj) :

LFA+rLFA

LFA+rLFA+dLFA

87,07961

95,77624278

88,68371

93,94736589

88,98679

90,51039143

81,66041

87,89868668

83,05648

95,43189369

88,27434

95,13274336

94,60468

100

99,66204

100

99,54467

99,6987133

99,55152

100


The table present % of TI-LFA repair list.

For example for topology 1 (first line), 87% of repair_list could be encoded on postconvergence path using only LFA and rLFA , we can extend this to 95% by adding dLFA (just one Adjacency segment).


De : Pushpasis Sarkar [mailto:[e-mail]]
Envoyé : mardi 18 mars 2014 18:12
À : DECRAENE Bruno IMT/OLN; [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[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.