Stephane, I absolutely agree - that current IP FRR mechanisms are all subject to trade-offs, that not all networks will be SPRING, that IP/LDP FRR will be needed for quite some time and it makes sense to finish these off.
Sadly, none of this stops this solution from being incremental with each piece adding more complexity. Engineering is about trade-offs and that can be different for each network and person. Regards, Alia On Mon, Mar 17, 2014 at 4:25 AM, <[email protected]> wrote: > 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 J 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]> 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]] > *Envoyé :* vendredi 14 mars 2014 20:02 > *À :* Alvaro Retana (aretana); [email protected] > *Cc :* [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] <[email protected]>] *On > Behalf Of *Alvaro Retana (aretana) > *Sent:* Thursday, March 13, 2014 10:02 PM > *To:* [email protected] > *Cc:* [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] > 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
