Re: [OSPF] draft-kini-ospf-fast-notification-01

Sri,

I spoke to a few people at IETF who have implemented OSPF and I have
deployed OSPF.  Flooding was not considered an issue.

A notfification would normally go out when a LSA is modified to
withdraw an adjacency.  Even a software SHA-256 is not that long a
time in software.

The question was whether anyone running a real network had measuered
flooding delay and found it to be a problem.

Also keep in mind that *modern* IGP implementations reflood first and
then SPF and download routes later.  You might want to look through
the archives of presentations at NANOG related to convergence.  Packet
designs and Qwest did some work on this about 5 years ago or more.
You may be tackling a non-problem.

Curtis

In message <AANLkTimuWm3mXOdWw1qROcRuetSAQJiwPVeqkZA3D5ab@mail.gmail.com>
Sriganesh Kini writes:
>  
> Vishwas,
>  
> Your draft seems to be referring to the end-to-end delay of a packet
> forwarded entirely by data-plane. So those results would be applicable
> to the OSPF fast-notification. It would not be applicable to
> end-to-end delay of OSPF LSA flooding since the LSAs are processed at
> each hop by the control-plane.
>  
> Curtis,
>  
> The control-plane delays you haven't listed include sending LSUpdate
> from data-plane to control-plane and its processing such as
> authenticating, comparing against LSDB, sending LSAck (with potential
> re-transmission), queueing for further flooding (including re-transmit
> if timer expires), re-adding interface specific auth params etc. All
> of these need to be done at each intermediate hop as the LSA gets
> flooded and hence the delay is cumulative. These delays may not seem
> like much but it does add to the overall delay in convergence. The SPF
> by itself does not take that much time in modern CPUs but the download
> of routes certainly increases with number of downloads. However,
> modern forwarding architectures are such that in many failure
> conditions many downloads are not needed. A single download can change
> the nexthop of a large number of routes. In such conditions the
> hop-by-hop control-plane flooding does not remain an insignificant
> component of convergence. There will of course be networks where
> geographic delay itself may be large enough to dwarf all other
> numbers, but there are a lot of networks where that is not true.
>  
> We will be updating the draft to support the assertions.
>  
> Thanks
>  
> On Mon, Apr 4, 2011 at 1:36 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
> > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar <curtis@occnc.com> wrote:
> > Hi Curtis,
> >
> >> Has anyone measured the per hop flooding delay that is incurred in
> >> modern routers?
> >
> > From the few we have worked, it works from 10's of nanoseconds to microseconds.
> >
> > You may see some work on
> > http://tools.ietf.org/html/draft-manral-ospf-te-delay-00. We need to
> > actually add per device delay to make the solution generic, which is
> > what we are trying to work on.
> >
> > Thanks,
> > Vishwas
> > _______________________________________________
> > OSPF mailing list
> > OSPF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf
> >
>  
>  
>  
> -- 
> - Sri