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

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