Hi Pushpasis, you've written: " *[Pushpasis] The real motivation behind node-protection has been to protect traffic against node-failures of the 1-hop immediate neighbors."* I wonder how one can reliably detect that it is immediate neighbor node failure, not link failure. I'd argue that such distinction can not be made dynamically and thus choice of using link protection or node protection is matter of pre-defined interpretation like one done in RSVP FRR (RFC 4090).
Regards, Greg On Mon, Mar 17, 2014 at 12:51 AM, Pushpasis Sarkar <[email protected]>wrote: > 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] <[email protected]>] > *Sent:* Saturday, March 15, 2014 5:57 AM > *To:* Stephane Litkowski > *Cc:* Uma Chunduri; Alvaro Retana (aretana); [email protected]; > [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 > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
