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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"Bhatia, Manav (Manav)" writes:
>  
>  
> > 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


Manav,

There is no question that you *can* design and/or code things badly.
There was work done by Packet Designs and Qwest a while back and
reported in NANOG.  After this work, a major router vendor's
implementation was optimized and a lot of delays were removed.  A big
mistake they were making is SPF and route install first and then
reflood.  It is better to get the word out that there is a problem.
After this the two leading core router vendors both had fast reflood
times.

At Avici, the minor core router vendor in its time, the CPU on the
line card (which had no long treads and low interrupt latency) handled
OSPF Hello and LSUpdate processing and only passed changes to the
router processor.

I just want to be sure that we aren't adding (more) baggage to fix a
non-problem or to fix someone's bad software implementation.

Curtis


> > 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
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf