[ovs-dev] [PATCH]: bfd: display last wall clock time of last flap

[Sabyasachi Sengupta]

Hi Ben,

> It's a little unconventional for us to use a wall clock time for this.
> I'd be more inclined to report it as "N seconds ago" or "N ms ago".  Any
> particular reason to use a wall clock time?

I've seen that all BFD other outputs use "now -/+" convention, but just that 
I thought wall clock time was more user readable, especially because last 
flap could be hrs/days ago. If we imagine that this output (last flap time) 
could be parsed through a remote script as to which link went down and when, 
its probably easier for them to see the absolute time rather than having to 
convert it (note that the notion of 'now' could be different in both 
machines?). I'd think that it makes more sense for next/last TX times 
(should continue to) be in milliseconds as that reflects a more ongoing 
activity.


This is how it looked in my system (just for your reference).

[root at rtr-29-225-196-232 ~]# ovs-appctl bfd/show
---- port3.4094 ----
         Forwarding: true
         Detect Multiplier: 3
         Concatenated Path Down: false
         TX Interval: Approx 500ms
         RX Interval: Approx 500ms
         Detect Time: now -1116ms
         Next TX Time: now -436ms
         Last TX Time: now +19ms
         Last Flap Time: 2015-06-25 00:36:22.372

         Local Flags: none
         Local Session State: up
         Local Diagnostic: No Diagnostic
         Local Discriminator: 0x10001
         Local Minimum TX Interval: 500ms
         Local Minimum RX Interval: 500ms

         Remote Flags: none
         Remote Session State: up
         Remote Diagnostic: No Diagnostic
         Remote Discriminator: 0x10001
         Remote Minimum TX Interval: 500ms
         Remote Minimum RX Interval: 500ms

I understand that this will be based on what ovs-vswitchd 'thinks' as to 
when the last flap occurred. Its still not the accurate information as 
ovs-vswitchd might itself have restarted in between the last flap and when 
the user actually reads it. This probably means that we save this info in 
ovsdb and read it through a separate CLI, but probably we can keep it simple 
for now?

> Please also document the new bfd_status feature in vswitchd/vswitch.xml
> near the rest of the bfd_status keys.

I'll send across a v2.

Thanks,
Sabya