Re: WGLC for draft-rtgwg-mrt-frr-architecture

[Stewart Bryant <[e-mail]>]

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 ([e-mail] 
> <mailto:[e-mail]>) 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.
>