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

[Curtis Villamizar <[e-mail]>]

Has anyone measured the per hop flooding delay that is incurred in
modern routers?

If this is small compared to geographic delay (speed of light delay)
then there is no need for this work.  Many routers forward packets
directly to a line card CPU and coordinate flooding among line card
CPU processors, a bit like flooding inside the chassis.  Worst case
for a high priority process is about two interrupt times.  Interrupt
times on a modern CPU is about 100 usec.  If there are a lot of LSA
being flooded, then many LSA can be picked up in one system call if
driver code is written to allow this.  Even where this goes to the
CPU, modern code is smart enough to have the SPF run in a different
thread or process, so as not to hold up any further flooding.  There
was a presentation in NANOG on this topic about 5 years ago or more
but I don't have a pointer to the URL at the moment.

The assertion in the abstract that "The delay due to the involvement
of the control-plane adversely affects OSPF convergence" is not
supported in the draft and certainly not in my experience.  The SPF
time is typically long compared to the sum of per hop flooding delays
due to hitting a CPU.

Curtis