Hi, I agree with Alia's analysis of the current state of the draft. I'd propose that someone, perhaps Clarence re-runs RFC6571 to include rLFA.
Regards, Jeff On Aug 12, 2012, at 5:39, "Alia Atlas" <[email protected]> wrote: > 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
