Agree with Pushpasis. IMHO, there is no added complexity because we are just reusing LFA piece of code : new fSPF to compute (as if the router has new neighbors), and node protection equations to check (as in base LFA spec) : computation load added is just as your router would have extra neighbors ... how many ISIS neighbors do you support on your boxes ? (I hope hundreds ... if yes, your box already scale to hundreds of fSPF to compute LFA).
Pushpasis pointed a good point while talking about NSR/GR. >From SP point of view, NSR/GR in the core may not implemented because nodes >are often doubled (two per site) and moreover NSR/GR is really adding a major >complexity in equipments : complexifying testings on a lot of features in >service provider lab and Service Providers want to keep their core as simple >and stable as possible. That's why guaranteed node protection is a requirement and we think there is major gain in this solution rather than relying on statistical or defacto NP. As Pushpasis mentioned, yes, there is no 100% node protection, and there is a need of tradeoff as for all IPFRR solutions today ... The solution we propose here is simple as LFA is. Best Regards, Stephane De : Pushpasis Sarkar [mailto:[email protected]] Envoyé : lundi 17 mars 2014 08:52 À : Uma Chunduri; Alia Atlas; LITKOWSKI Stephane DTF/DERX Cc : [email protected]; [email protected]; Chris Bowers Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Hi Uma, From: Uma Chunduri [mailto:[email protected]] Sent: Monday, March 17, 2014 12:20 PM To: Alia Atlas; Stephane Litkowski Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Hi Stephane, You asked the right questions. But I don't think I can give better/precise answers than the reply we already got. Any ways, let me try - > Why do you say that the gain is very minimal ? (..per base draft, in real SP topologies) 9 out of 14 topologies showed very minimal gain with rLFA NP and the remaining 5 topologies with limited improved coverage. Given the PQ explosion in certain topologies to as many as more than half the number of nodes in the network, I don't think this gain is, in any way matching the complexity of the proposal/performance impact at times in the network .. [Pushpasis] The real motivation behind node-protection has been to protect traffic against node-failures of the 1-hop immediate neighbors. IMO, this can be achieved in two ways only. 1. Deploy node-protection on PLR, Or 2. Deploy NSR/GR on all 1-hop neighbors. Both methods will add computational complexity and it is matter of choice which one will the operator go for. Again IMO, NSR is far more complex than node-protection and adds considerably much more to overall CPU and other resource consumptions than node-protection. For networks where NSR is already deployed, node-protection may not be that critical. But for networks that did not deploy NSR (for whatever reasons, I don't want to speculate), it is quite critical, once again in my opinion. >The gain is major, and it's not just a question of numbers ... I don't think so. I think you have to explain why and how you think it's a major gain. [Pushpasis] Again, for networks that did not deploy NSR, it is quite critical. >.. NP coverage may be quite good depending of topology, it's not guaranteed It's always good to be optimistic but number are speaking the other way. [Pushpasis] I agree that it does not guarantee 100% protection. However, we have seen ~96-98% coverage even when we restricted the number of PQ-nodes between 8 and 16, and that too with a very simple heuristic as suggested in the draft. > Would be also interested in why do you think the solution is complex ? It's pumping complexity in the code base not only in terms of maintainability with competing and interfering solution space on the table from MRT to other technologies but also due to the the heuristics proposed (are indeed fragile as indicated). Secondly, IMO, though it's not mandatory to collect path characteristics (you also expect not only PQs but also all the nodes to upgrade and advertise node admin tags to get these ?) from PQ to destination, overall it is bit of over engineering . This got to be simplified at minimum. Probably this can be discussed later. [Pushpasis] Yes LFA manageability is optional, but if you donot need it then you also donot need to collect the path characteristics. So you save time on that. Without that, all you need is a basic Forward SPF on the PQ-node. On a router with the kind of high performance CPUs used today, a SPF with 1000 node topology, a single SPF runs well under 1ms. How much performance overhead are we really adding then? I don't get your comment in pumping code-complexity. The only extra things we need to do is - Run a Forward SPF on a PQ-node. The same code that was written for LFA can be re-used. Just run it on a PQ-node instead of a 1 hop neighbor. - Alos the existing code for checking inequalities can then be easily re-used/extended to run on the results procured from the above SPF. -- Uma C. From: Alia Atlas [mailto:[email protected]] Sent: Saturday, March 15, 2014 5:57 AM To: Stephane Litkowski Cc: Uma Chunduri; Alvaro Retana (aretana); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Stephane, A solution that requires or desires different heuristics depending upon the network topology is complex and somewhat fragile. I also feel that we are in the realm of attempted partial solutions, each more complex than the previous one. SPRING has the hope of making the rLFA approach simpler and without a concern for the computational load during convergence time (or alternately for the time that is unprotected), That said, I know this is the path that you are all going down and that you see the trade-offs as acceptable. Regards, Alia _________________________________________________________________________________________________________________________ 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.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
