Uma, What simulation numbers are your refering to ? Is it Section 8 of draft-ietf-rtgwg-remote-lfa ? If yes, the number displayed are not applicable to our solution.
NP coverage in Section 8 of draft-ietf-rtgwg-remote-lfa are using the default rLFA tiebreaker : closest PQ and single PQ election per interface. We don't have the topology that CISCO was using in the draft, so we cannot provide numbers with our solution with the same set of topologies. But I think, we could add in the draft, some simulation results showing the improvement of guaranteed NP using our solution compared to basic rLFA spec. Stephane De : Uma Chunduri [mailto:[email protected]] Envoyé : lundi 17 mars 2014 07:50 À : Alia Atlas; LITKOWSKI Stephane DTF/DERX Cc : Alvaro Retana (aretana); [email protected]; [email protected] Objet : 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 .. >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. >.. 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. > 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. -- Uma C. From: Alia Atlas [mailto:[email protected]] Sent: Saturday, March 15, 2014 5:57 AM To: Stephane Litkowski Cc: Uma Chunduri; Alvaro Retana (aretana); [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 _________________________________________________________________________________________________________________________ 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
