[ovs-dev] BFD integration into FastFailover Group Table

Ben Pfaff blp at nicira.com
Fri Aug 29 21:02:07 UTC 2014


On Fri, Aug 29, 2014 at 01:15:53PM +0000, Niels van Adrichem wrote:
> For some experiments I did around April/May for a paper I wrote I
> changed some sourcecode to ofproto-dpif-xlate.c to have the FastFailover
> Group Table look at the BFD status directly.
> We did this because we found that although the BFD status flags changed
> in time, interface status remained up (which might or might not already
> have been solved by now) and hence the FastFailover rule would not
> select the backup forwarding rule. Furthermore, our experiments showed
> that bringing the interface status down manually could take slightly
> over 50 ms before the FastFailover would kick in [1]. As we wanted "even
> faster" recovery, we decided to have the function odp_port_is_alive()
> also look at the BFD status itself [2]. Doing this also decreased the
> number of packets when an interface became live again, as the Fast
> Failover rule would not revert sending to the primary rule before BFD
> confirmed a live link.
> 
> If you are interested I can rewrite the patch to confirm to the
> appropriate coding lay-out and make sure it applies to the current state
> of the file.

It sounds like a good idea.  I am not sure why that function doesn't
already check BFD and CFM state.  It seems that it should.

It also seems that OVS seems to be missing an implementation of
OFPPS_LIVE in OpenFlow port state.  We should fix that too.

> Perhaps instead of checking the BFD status, I could include a
> *synchronized* per-interface flag that f.e. equals 0x00 when all
> configured link state detection mechanisms detect live links, 0x01 when
> BFD detects an error, 0x02 when Ethernet OAM detects an error, 0x03 when
> both do, etc. In that case you can check status from multiple detection
> mechanisms without the need to iterate through all of them, hence
> improving the throughput of OVS.  How do you think about that?

Code cleanups are always welcome, although I don't entirely understand
this proposal.

Thanks,

Ben.



More information about the dev mailing list