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

I am aware of at least one implementation from the 2002/2004 time frame with a per node OSPF flooding transit time of O(10 uSecs);  this implementation was a port of a commercially available OSPF stack rather than a custom implementation. 

Sent from my iPhone

> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of
> Curtis Villamizar
> Sent: Monday, April 04, 2011 7:15 PM
> To: Sriganesh Kini
> Cc: ospf@ietf.org
> Subject: 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
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf