Hi Alia, Pls find comments inline.
De : Alia Atlas [mailto:[email protected]] Envoyé : samedi 15 mars 2014 13:57 À : LITKOWSKI Stephane DTF/DERX Cc : Uma Chunduri; Alvaro Retana (aretana); [email protected]; [email protected] Objet : 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. [SLI] Agree, that why simulation results are interresting. 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), [SLI] Right, SPRING would make things simpler. But SPRING is SPRING, no more IP routed networks :) We already know, that some legacy platforms may never support SPRING (not ony for technical reason) but LFA/rLFA can be enhanced for such equipments that may be kept in networks for years. I don't really agree about adding complexity there, what we require here is just running few fSPFs, and as Pushpasis mentioned,it's peanut in term of computation load even on old platforms. Compare the complexity with some routers having 100's of RSVP-TE tunnels with CSPF ... Now, you pointed a very good question. As SPRING would be there, do we still need to work on IP FRR enhancements ? IMHO, both can be kept in parallel. Maybe some people may not want to deploy SPRING. Moreover, I think that it may be good to finish the work on LFA/rLFA with node protection addings. Good way to close the work on the subject. That said, I know this is the path that you are all going down and that you see the trade-offs as acceptable. [SLI] Current IP FRR mechanism are all subjects to tradeoff ... LFA/rLFA, even MRT ... Regards, Alia On Sat, Mar 15, 2014 at 4:39 AM, <[email protected]<mailto:[email protected]>> wrote: Hi Uma, Why do you say that the gain is very minimal ? The gain is major, and it's not just a question of numbers ... With basic rLFA specification you cannot guarantee node protection. Even if based on statistics, node protection exists with basic spec, and NP coverage may be quite good depending of topology, it's not guaranteed. For a service provider requiring NP, it's really important to guarantee the NP without relying on statistics or defacto node protection. Would be also interested in why do you think the solution is complex ? Thanks ! Stephane De : Uma Chunduri [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 14 mars 2014 20:02 À : Alvaro Retana (aretana); [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> Objet : RE: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Support in principle.. Will post detailed comments later. But .. 1. Would like to definitely see IPR claims on this 2. It's important to note, this is adding additional complexity into the system on OTO rLFA and it's not yielding any/very-minimal gain for 60-70% of topologies and remaining 30% it's giving around ~10-12% coverage gain. -- Uma C. From: rtgwg [mailto:[email protected]] On Behalf Of Alvaro Retana (aretana) Sent: Thursday, March 13, 2014 10:02 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: WG Adoption Call for draft-psarkar-rtgwg-rlfa-node-protection Hi! During the meeting in London the authors asked for the WG to adopt this draft. This message officially starts the call for adoption for draft-psarkar-rtgwg-rlfa-node-protection. Please indicate your position about adopting it by end-of-day on March 28, 2014. http://tools.ietf.org/html/draft-psarkar-rtgwg-rlfa-node-protection Thanks! Alvaro. _________________________________________________________________________________________________________________________ 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg _________________________________________________________________________________________________________________________ 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
