There are several improvements that I would like to see to draft-ietf-rtgwg-remote-lfa-00. I believe at least the first four are necessary to improve the draft sufficiently given its status as Standards Track.
First, if the intent is to restrict this mechanism to ONLY link protection, that belongs at a minimum prominently in the abstract and introduction. It is currently first mentioned only in Section 3. Second, the algorithm description Sec 4.2.1 and Sec 4.2.2 needs significant expansion into a more formal algorithm description, such as is in the LFA spec, RFC 5286. A brief description of the computational complexity would be useful, but the critical part is having it specified clearly. Third, in Sec 4.2.3, there is no preferred or even specified method for selecting among the different PQ options that might be available. Such a method should be specified; as the draft says, there is an advantage from the network management perspective to consistency. It is also required to have agreement on the output of analysis to compare/contrast methods. Fourth, one issue described in RFC 5286 is what happens when a worse failure occurs than the LFA was computed to handle - i.e. if a node failure happens instead of a link failure. In that case, traffic looping can occur. With Remote LFA, I believe that the same issue can exist - but made even worse because there is no effort to look for node-protecting Remote LFAs. This concern needs some description in the draft. Additionally, the equivalent of the Downstream Paths condition should be specified, if possible, that allows such traffic looping to be avoided. Finally, since the argument for Remote LFA is the improved coverage over LFAs, I would like to see the coverage analysis based on simulation to show the coverage when the Downstream Paths equivalent requirement is met vs. when it is relaxed (as currently in the draft). Fifth, for a better understanding of realistic behavior, I would like to see the analysis extended to show the min, average, and max coverage for the 11 specified topologies after each single failure has occurred in the topology. (Of course, the computation should recognize that protecting cut-links isn't feasible and not include those failures.) While I recognize that link failures are significantly more common than node failures, I believe that fast-reroute techniques should be able to cover node failures as well. Technically, I think that Remote LFA can, of course, be extended to provide node coverage - at the cost of computing a reverse-SPF from each next-next-hop of the computing router. As I said early, at a minimum, the abstract and introduction need to clearly specify that Remote LFA only provides link protection and the traffic looping concerns need to be addressed. Since this is now a working group draft, it would be good to see progress and discussion on the draft. Regards, Alia _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
