RE: discussion on fast notification work

[András Császár <[e-mail]>]

Hi Alia,

> > The problem is clear: how to do fast fail-over in IP and 
> LDP with full failure coverage in
> > arbitrary network topologies. Several other ongoing 
> proposals are targeting the same
> > problem (just to mention Not-Via or MRT). So, I think there 
> is consensus that the problem
> > needs solving.
> 
> Not-Via, MRT, and LFA are all mechanism for a router to do local
> repair in response to a local failure.
> 
> This proposal is an effort to take the idea to the next step and
> attempt to have all the routers converge to the new topology very very
> quickly.

Please note that in IPFRR-FN (http://tools.ietf.org/html/draft-csaszar-ipfrr-fn) 
we are NOT suggesting ANY modification to IGPs.
So, in fact we are not changing the convergence properties of ISIS or OSPF at all. (This has been suggested in http://tools.ietf.org/html/draft-kini-ospf-fast-notification but this thread should NOT be about that. It's an OSPF WG matter.)

Looking at IPFRR-FN, while it does not affect IGP convergence, it can be said that IPFRR-FN lets the routers converge onto a consistent backup forwarding state, which is actually mostly identical to what the IGP will calculate once it converges. (Since the pre-calculation was also done on the IGP topo database.)


> The scaling, computation, and speed are real concerns with this
> approach.  I was quite interested to see your numbers.  Thanks for
> doing that work.  One issue, of course, is that there is a large
> installed base of routers that are not NP-based; I'm not sure of the
> practicality there.

Please note that our prototype/measurements are not based on NP-based linecard either. By mentioning NP, which is a completely different platform from ours, I was just highlighting that after discussing with a guy more familiar with programming NP we believe that there is no hinderniss for IPFRR-FN to be implemented on NP, either.

András