[Uma]: So we do few hundreds of fSPF from each neighbor for base LFA then few hundreds for Q space rSPFs and few more hundreds for rSPFs from PQ nodes depending on the network/heuristics for each primary SPF right. Did you see your 1msec is multiplied few multiple hundred times here. [Pushpasis] Few hundreds fSPFS for PQnodes are not necessary. 8-16 PQ nodes selected using the default heuristic in this draft provide quite a good amount of coverage.
From: Uma Chunduri [mailto:[email protected]] Sent: Monday, March 17, 2014 11:24 PM To: [email protected]; Pushpasis Sarkar; Alia Atlas Cc: [email protected]; [email protected]; Chris Bowers Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Stephane, Comments in-line [Uma] -- Uma C. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Monday, March 17, 2014 1:47 AM To: Pushpasis Sarkar; Uma Chunduri; Alia Atlas Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Chris Bowers Subject: RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Agree with Pushpasis. [Pushpasis] 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? [Uma]:I think we all know and this and we already took advantage of the modern CPUs Pushpasis mentioning and we added a bunch of additional computations in layers till now. ..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). [Uma]: So we do few hundreds of fSPF from each neighbor for base LFA then few hundreds for Q space rSPFs and few more hundreds for rSPFs from PQ nodes depending on the network/heuristics for each primary SPF right. Did you see your 1msec is multiplied few multiple hundred times here. If really don't care about this additional fSPFs from candidate PQs, why do you bother to reduce the same through heuristics proposed? Did you see your contradiction already? Pushpasis pointed a good point while talking about NSR/GR. [Uma]: As I said it's good to document this. >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. [Uma]: Stephane, I think this is the real contradiction you are talking! GR/NSR is not new to lot of vendors/customers and it's there from long back for lot of vendors. If you say deploying the same with one command is complex, tuning, simulating rLFA NP configuration as per topology is orders of magnitude complex. Trust me am just debugging an issue on of the (tier 1) customer node and AFAICT much more simpler things are still not handled well and what we are talking here is way far off than the practical reality on the ground. As Pushpasis mentioned, yes, there is no 100% node protection, and there is a need of tradeoff as for all IPFRR solutions today ... [Uma]: I agree. As I said earlier I support this, but some discussion ought to happen on this topic and heuristics as well as the path characteristics mentioned in the draft. You said above - "a lot of features in service provider lab and Service Providers want to keep their core as simple and stable as possible." I think for this sake at least we need to simplify solutions where ever possible at least. I will share detailed comments later. Good luck! -- Uma C.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
