Andras I think that you omitted to note that RLFA supports incremental deployment well, and in particular needs no new protocols. This is in contrast to all of the alternatives that have been put on the table, which require the on-repair-path nodes to change.
The approach proposed here is to publish RLFA in order to provide a solution for those networks that find LFA too limiting, but need a solution that they can deploy in the short term. Meanwhile we should take another look at the relative merits of MRT, not-via etc and understand whether any of them offer the sort of overwhelming advantage that would justify the deployment of a new approach that requires routing domain wide deployment. On 31/05/2012 09:33, [email protected] wrote:
(F3) Even if an operator tunes its topo to have high RLFA coverage, a topo change might ruin it (e.g. failures, etc.). So, what would be very useful is to see numbers on various topologies how a high coverage value changes with a small modification of the topology (e.g. one or two failures...) [SLI] This is clearly a good point, I think most people are already aware of (I hope :) ), as it concerns already LFA ... If you have a good coverage with your nominal topo, a backup topology may not have a good coverage ...
Let's be careful here, it's not at all clear how the well the various virtual topology approaches will behave under multiple failures, since you need to concurrently manage the traffic patterns in both topologies. In any case I think that we can always construct pathological repair topologies which whilst they technically work, have properties that would be unacceptable to an operator. Rings were mentioned, and RLFA handles rings just fine. Remember that RLFA is really the viable subset of draft-bryant-ipfrr-tunnels-03, a draft where we have already explored a lot of the corner cases. The RLFA draft is a pragmatic approach that say's lets take the simple bits of the PQ technology, noting that it can be incrementally deployed, and then we have more time to think about what to do about the corner cases that LFA + RLFA cannot address. Stewart (as an RLFA author)
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
