RE: fn-transport/ipfrr drafts

Hi,

Probably you are more interested in the opinion of the rest of the community, but anyway:

a) yes, especially for those applications that target quick changing of active dataplane routes to alternative routes when something happens in the network (as for now this could be FRR, where event=failure). It could be also very useful in split DP-CP environments (such as FORCES and OpenFlow), where event specific alternative routes could be activated by forwarding elements without consulting the CP.

b) I'm not an author of the ospf-fn draft but in my opinion it could be useful in those cases when regular OSPF flooding is a noticable part of the overall convergence. This may be the case with modern routers where the existing convergence bottlenecks are greatly reduced (SPF calc is not long anymore, RIB-to-FIB download bottleneck is getting optimised by incremental updates and a few updates causing many route updates in the FIB)

c) We should come back definitely with more numbers on (copy/pasting from the email I just sent responding to Curtis):
- 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?

Some initial estimations you can find in the Appendix of the ipfrr-fn draft.

An important note: You don't have to download alternative routes for each failure for each destination! Only those that matter:
1. Failure is on shortest path towards the destination
2. Failure results in route change

This is much less.

Will come back with more numbers.

Kind regards,
András

> -----Original Message-----
> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] 
> On Behalf Of mike shand
> Sent: 2011. április 6. 11:25
> To: rtgwg@ietf.org
> Subject: Re: fn-transport/ipfrr drafts
> 
> Alia,
> 
>      My quick replies would be
> 
> a) possibly, but I'm not sure of the application. Certainly not (b).
> b) I don't think so
> c) I'd be very concerned about the scaling issues of doing that
> 
>      Mike
> 
> 
> On 06/04/2011 02:00, Alia Atlas wrote:
> > Curtis,
> >
> > Andras is familiar with the problem IPFRR is trying to solve.
> >
> > As I understand it, there are 3 separate questions:
> >     a) Is a multicast distribution mechanism that can 
> report bad news
> > quickly&  survive single failures useful?
> >     b) Is this useful for an IGP to speed network convergence?
> >     c) If one assumes very rapid ( speed of light)  delays 
> for remote
> > failures, what pre-computation and FIB installation could 
> be possible?
> >
> > I have not heard requirements and rationale sufficient yet.
> > Security is also a concern - but the first questions are whether any
> > mechanism is  desirable.
> >
> > Alia
> >
> > 2011/4/5 Curtis Villamizar<curtis@occnc.com>:
> >> In 
> message<8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS036
> 3.eemea.ericsson.se>
> >> András Császár writes:
> >>> Dear All,
> >>>
> >>> Note that fn-transport already is at version 01. Links to 
> the docs:
> >>>
> >>> 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.
> >>
> >> Curtis
> >>
> >>
> >>>> -----Original Message-----
> >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]
> >>>> On Behalf Of Jeff Tantsura
> >>>> Sent: 2011. március 29. 14:58
> >>>> To: rtgwg@ietf.org
> >>>> Subject: fn-transport/ipfrr drafts
> >>>>
> >>>> Hi rtgwg,
> >>>>
> >>>> The authors would like to solicit comments from the workgroup.
> >>>>
> >>>> draft-lu-fn-transport-00
> >>>> draft-csaszar-ipfrr-fn-00
> >>>>
> >>>> Thank you in advance!
> >>>>
> >>>> Regards,
> >>>> Jeff
> >> _______________________________________________
> >> rtgwg mailing list
> >> rtgwg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtgwg
> >>
> >>
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
> >
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
> 