More inline :) De : Uma Chunduri [mailto:[email protected]] Envoyé : lundi 17 mars 2014 18:54 À : LITKOWSKI Stephane DTF/DERX; Pushpasis Sarkar; Alia Atlas Cc : [email protected]; [email protected]; Chris Bowers Objet : 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? [SLI] I'm not saying that we don't care about additional fSPFs at all ... we clearly said during the WG meeting that running fSPF for each candidate PQ is too much computation ... I completely agree on that. But with only few additional fSPFs (~10), we are able to provide a pretty good coverage for guaranteed NP. 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. [SLI] Some bricks of NSR/GR are there from years ... but there are always pieces missing depending on the vendor ... (we always need support for all of our fancy protocols/features ...) Doing simulation/tuning in network is not new , and it's part of network planning. It's not "complex" (it may ...), I would say it's more expensive in time ... I agree that if we can save some time in this area, it would be better, but it's a more an "IP FRR" issue rather than a new issue brought by the node protection rLFA proposal (basic LFA requires simulation , MRT also ... ). I completely agree that we need to keep thing simple in both implementations (simple code, so less buggy code) and operations. But here I think, that what we are adding there is not too much : maybe it depends of your existing code structure, and if yes, we can discuss it offline, in order to better understand your constraints. What would be your proposal to make this more simple ? or do you think we need to give up guaranteed NP for rLFA and use SPRING ? 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. [SLI] Completely inline with the approach, but from now, I don't see how to simplify it more ... but clearly open to any ideas. Good luck! -- Uma C. _________________________________________________________________________________________________________________________ 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
