On 21/12/2015 15:46, Rob Shakir wrote:
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]
<mailto:[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.
I certainly agree with that statement. Compute limit is much less of a
problem than when any of this work was started.
Stewart
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
