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: [email protected] [mailto:[email protected]] On Behalf Of > Curtis Villamizar > Sent: Monday, April 04, 2011 7:15 PM > To: Sriganesh Kini > Cc: [email protected] > 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 > <[email protected]> > 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 > <[email protected]> wrote: > > > On Mon, Apr 4, 2011 at 1:33 PM, Curtis Villamizar > <[email protected]> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > > > > > -- > > - Sri > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
