RE: fn-transport/ipfrr drafts

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

> > http://tools.ietf.org/html/draft-lu-fn-transport-01
> > http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00
> >  
> > We'd really appreciate comments and suggestions. 
> >  
> > András
> 
> 
> Same comment as on the OSPF mailing list.  This is attacking a
> non-problem.
> 
> Flooding time is not a problem on modern implementations, unless the
> implementation is badly designed or badly coded.
> 
> IPFRR is intended to eliminate the need for an SPF and route
> download and the need to contact any other router in any way to get an
> initial repair done.  That is a different problem.

LFA does not need contact with other routers, but it cannot provide full coverage.
We explore the possibility of lifting the existing IPFRR constraint that explicit notification is not allowed.

So, instead of saying that explicit notification is not allowed, we think that a fast and lightweight dataplane based notification dissemination protocol could be a way ahead towards full FRR failure coverage.

The questions is then: Can this explicit notification be made quick and simple enough to be feasible? Our answer is yes, this is FN, described in draft-lu-fn-transport-01

IPFRR-FN is then the following: Assuming that there exists a fast notification protocol that can notify each node in the area about any single failure, could we then let the IGP to pre-calculate and pre-install failure specific backup routes? We think yes.

It is clear, though, that we should get back with (more) numbers on practical feasibility:
- What is amount of information needed to prepare backup routes for different local and non-local failures?
- How does this pre-calculation stress the CP?
- How does the CP-to-DP pre-downloading of this backup information stress a node?
- How fast can a linecard in practice change the information in its FIB using this local backup database?

BR,
András