Bruno, I agree. Does the following text work to implement your s/Other/All suggestion? "All existing and proposed solutions have tradeoffs. Some of these tradeoffs are described below."
In terms of including other solution comparison metrics, I think that makes sense as well. Would you be able to propose text for the table and descriptions to incorporate other comparison metrics? Thanks, Chris From: [email protected] [mailto:[email protected]] Sent: Wednesday, April 01, 2015 3:12 AM To: Anil Kumar S N (VRP Network BL); Alia Atlas; Robert Kebler; Chris Bowers; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt Hi Chris, authors, Comparing IP FRR methods is a difficult task... The choice of metrics (of comparisons) is difficult and for some (solution, metric) the evaluation is very topology dependent. That being said, it would be interesting to add another metric, related to the "quality" of the routing/placement of the FRR path. e.g. for short: optimality of the FRR path (according to the IGP metric). But others quality may be taken into account e.g. naturally provisioned with enough capacity (in a network having enough capacity to handle single failure), naturally policy friendly (as per LFA policy). Another metric, may be how easy is the solution/FRR path determination for the human brain/network operators. Because ease of computation for computer is a good thing, but in the end computer follows Moore's Law while human brain do not. IMHO it may be interesting to indicate the possibility for the SP to choose between link protection, node protection, and SRLG protection, eventually on a per PLR/protected link basis. Indeed, the bigger protection may not be the best as it's a trade-off impacting the optimality of the detour path. One may prefer link protection only, if the % of node failure is small and the detour to avoid the node is big. The above being considered, the first sentence could probably be slightly modified ( :s/Other/All ) since IMHO MRT has also trade-offs. Thanks, Regards, Bruno From: rtgwg [mailto:[email protected]] On Behalf Of Anil Kumar S N (VRP Network BL) Sent: Saturday, March 28, 2015 12:55 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: draft-ietf-rtgwg-mrt-frr-architecture-05.txt Hi Authors, In "comparison of IP/LDP FRR Methods" section of the document , I feel we should add comparison with TI-LFA (draft-francois-spring-segment-routing-ti-lfa-01) where TI-LFA approach achieves guaranteed coverage against link or node failure, in any IGP network, relying on the flexibility of SR. This will give readers better picture and enables them with more information so that they can choose MRT if they feel it suites their requirement better; compared to IT-LFA. Changes : 1. Introduction : Other existing or proposed solutions are partial solutions or have significant issues, as described below. Summary Comparison of IP/LDP FRR Methods +---------+-------------+-------------+-----------------------------+ | Method | Coverage | Alternate | Computation (in SPFs) | | | | Looping? | | +---------+-------------+-------------+-----------------------------+ | MRT-FRR | 100% | None | less than 3 | | | Link/Node | | | | | | | | | LFA | Partial | Possible | per neighbor | | | Link/Node | | | | | | | | | Remote | Partial | Possible | per neighbor (link) or | | LFA | Link/Node | | neighbor's neighbor (node) | | | | | | | Not-Via | 100% | None | per link and node | | | Link/Node | | | | | | | | | TI-LFA | 100% | Possible | per neighbor (link) or | | | Link/Node | | neighbor's neighbor (node) | | | | | | +---------+-------------+-------------+-----------------------------+ Table 1 TI-LFA: Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing link and node protection of node and adjacency segments within the Segment Routing (SR) framework [draft-francois-spring-segment-routing-ti-lfa-01]. Has improved coverage over LFAs and Remote LFA for link and node protection and also guarantees complete coverage. The trade-off of looping traffic to improve coverage is still made. The computation required is quite high with added complexity. TI-LFA is supported only MPLS data plane with a requirement to carry additional MPLS label stack on the link failure; on certain topologies stack size can grow significantly based repair path. Thanks & Regards Anil S N "Be liberal in what you accept, and conservative in what you send" - Jon Postel _________________________________________________________________________________________________________________________ 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
