Chris, Thanks for the clarification around the fact that MRT can be run as part of a multi-technology approach. I wouldn’t endorse such an approach operationally — why run multiple technologies alongside each other that one must understand vs. a single one that could meet multiple requirements - but some operators may find such an approach useful.
On 21 December, 2015 at 2:47:20 PM, Chris Bowers ([email protected]) wrote: I also want to comment on the fact that remote LFA produces multiple alternates to choose from. With respect to determining if an alternate provides node protection or not, the fact that remote LFA computes many possible alternate paths could be viewed as a drawback, as opposed to an advantage. For a given PLR and failure mode and destination, in general it will be the case that many nodes qualify as PQ nodes. In order to determine if the complete repair path from PLR to PQ-node and PQ-node to destination is node-protecting, additional computation is needed. The most efficient approach seems to be to run a forward SPF from the PQ-node being evaluated. In some topologies, it is not uncommon for many nodes to qualify as PQ nodes. In order to avoid spending too much time churning away at running forward SPFs rooted at PQ-nodes, some implementations may find it useful to limit the number of PQ nodes evaluated for node-protection. By comparison, for roughly the computational cost of evaluating three PQ nodes for node-protection, MRT produces a path which is guaranteed to be node-protecting, if node protection is possible. In cases where node-protection and maximum coverage is important, it seems reasonable to give operators the option of having an efficient means of generating a node-protecting path as opposed to the trial and error approach of evaluating large numbers of PQ nodes, which may or may not ultimately provide a node-protecting path. I feel this analysis misses a fundamental point — ‘cost’ does not equate only to the number of cycles that we must spend to find an alternate. Instead we need to consider the whole picture. The question one really needs to consider here is whether the “cost” of using CPU cycles is something that we want to optimise for, over the cost of investing in operational expertise/tooling to ensure manageability and capacity. Much of the work that LFA manageability and TI-LFA do is to make flows align with what is “expected” to happen in the network - such that it is easy to understand for operational personnel, but also, it does not drive investment in new capacity which is used *only* in repair scenarios (such investment is generally required IMHO, in order to not congest and degrade all application traffic during that repair). In my experience (and of course, YMMV), optimising for the latter operational reasons is very much worth spending more cycles on the control-plane, especially now that there are tending to be more resources available there. I think characterisations such as the one above are very academically interesting, but I find that in this case, that has less relevance when we come to actually operating a network. I think there’s interesting work here, but I’ll continue to struggle with whether it really is usable operationally. Regards, r.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
