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

["Bhatia, Manav (Manav)" <[e-mail]>]

 
> 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

You will have more delays even before this. The LSAs need to be picked up from the HW to the CPU and based on your queue scheduling algorithm there could be some delays there. Typically if its strict scheduling then you would drain all the BFDs, EFMs, LACPs, OSPF HELLOs, etc before you get to the LSUpdates. Once you have drained all such packets from the HW they will only be processed once your OSPF task gets a CPU slice. It will then take some time in processing the LSUpdates as it may have Hellos queued up ahead (based on the architecture). Similarly, at the egress there could again be some delays. If there is a central task that's responsible for sending out the packets then it could also be maintaining priority queues and LSUpdates will certainly not get into the highest. While I understand that all these delays are very small, they do start adding up as the LSAs travel hop-by-hop. It also starts getting significant as your router starts becoming busy and the processes have to contend for the CPU cycles. If the router software is not entirely lockless then you would also see processes stalled because some other task has acquired a lock that they're waiting on. So, forwarding them in the HW seems like a good idea provided we can make it work without making the solution too convoluted and complex.

Cheers, Manav

> 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