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@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

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to