Hi Uma, From: Uma Chunduri [mailto:[email protected]] Sent: Monday, March 17, 2014 12:20 PM To: Alia Atlas; Stephane Litkowski Cc: [email protected]; [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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
