| Message ID | 1448287125-17925-1-git-send-email-bschanmu@redhat.com |
|---|---|
| State | Rejected |
| Headers | show |
I think we'll need more rationale than that. BFD is expensive without a good reason.
On 11/23/2015 10:49 AM, Ben Pfaff wrote: > I think we'll need more rationale than that. BFD is expensive without a > good reason. It was on the ovn/TODO list, at least. :-) > * Use BFD as tunnel monitor. > > Both ovn-controller and ovn-contorller-vtep should use BFD to > monitor the tunnel liveness. Both ovs-vswitchd schema and > VTEP schema supports BFD.
On 11/23/2015 10:49 AM, Ben Pfaff wrote: > I think we'll need more rationale than that. BFD is expensive without a > good reason. It was on the ovn/TODO list, at least. :-) > * Use BFD as tunnel monitor. > > Both ovn-controller and ovn-contorller-vtep should use BFD to > monitor the tunnel liveness. Both ovs-vswitchd schema and > VTEP schema supports BFD.
On Mon, Nov 23, 2015 at 10:56:34AM -0500, Russell Bryant wrote: > On 11/23/2015 10:49 AM, Ben Pfaff wrote: > > I think we'll need more rationale than that. BFD is expensive without a > > good reason. > > It was on the ovn/TODO list, at least. :-) > > > * Use BFD as tunnel monitor. I think I wrote that. It came from an NVP mindset. In NVP, the hypervisors use a set of "service nodes" to implement broadcast: a hypervisor sends a broadcast packet to a service node, then the service node replicates it and sends it to all of the destination hypervisors. In that design, it's really important for the hypervisors to have BFD set up between the hypervisors and the service nodes, because if one service node goes down the hypervisors need to shift to using a different service node to ensure availability. The same goes for the "gateway nodes" that provide access to physical networks. For OVN, we're not using service nodes (which simplifies the system a great deal; service nodes were never well-motivated), so we don't need BFD for that reason. We'll need something for the OVN gateways when we start supporting HA for gateways, and that something will probably involve BFD. For hypervisor-to-hypervisor tunnels, it's much less important to have tunnel monitoring (such as BFD), because when the tunnel goes down there's no alternative to switch to. If there's someone working on some kind of monitoring system for OVN, then it might make sense to turn on BFD (probably at a slow rate) to allow monitoring of the physical network. But absent that I don't think it's really worth the cost. Anyway, that's my story and I'm sticking to it ;-)
On 11/23/2015 11:11 AM, Ben Pfaff wrote: > On Mon, Nov 23, 2015 at 10:56:34AM -0500, Russell Bryant wrote: >> On 11/23/2015 10:49 AM, Ben Pfaff wrote: >>> I think we'll need more rationale than that. BFD is expensive without a >>> good reason. >> >> It was on the ovn/TODO list, at least. :-) >> >>> * Use BFD as tunnel monitor. > > I think I wrote that. It came from an NVP mindset. In NVP, the > hypervisors use a set of "service nodes" to implement broadcast: a > hypervisor sends a broadcast packet to a service node, then the service > node replicates it and sends it to all of the destination hypervisors. > In that design, it's really important for the hypervisors to have BFD > set up between the hypervisors and the service nodes, because if one > service node goes down the hypervisors need to shift to using a > different service node to ensure availability. The same goes for the > "gateway nodes" that provide access to physical networks. > > For OVN, we're not using service nodes (which simplifies the system a > great deal; service nodes were never well-motivated), so we don't need > BFD for that reason. We'll need something for the OVN gateways when we > start supporting HA for gateways, and that something will probably > involve BFD. > > For hypervisor-to-hypervisor tunnels, it's much less important to have > tunnel monitoring (such as BFD), because when the tunnel goes down > there's no alternative to switch to. If there's someone working on some > kind of monitoring system for OVN, then it might make sense to turn on > BFD (probably at a slow rate) to allow monitoring of the physical > network. But absent that I don't think it's really worth the cost. > > Anyway, that's my story and I'm sticking to it ;-) > Thanks for that explanation. It makes sense to me. I'll see if I can incorporate that into the TODO item.
diff --git a/ovn/controller/encaps.c b/ovn/controller/encaps.c index dfb11c0..c8744a0 100644 --- a/ovn/controller/encaps.c +++ b/ovn/controller/encaps.c @@ -150,6 +150,7 @@ tunnel_add(struct tunnel_ctx *tc, const char *new_chassis_id, /* No such port, so add one. */ struct smap options = SMAP_INITIALIZER(&options); + struct smap bfd = SMAP_INITIALIZER(&bfd); struct ovsrec_port *port, **ports; struct ovsrec_interface *iface; char *port_name; @@ -168,7 +169,11 @@ tunnel_add(struct tunnel_ctx *tc, const char *new_chassis_id, smap_add(&options, "remote_ip", encap->ip); smap_add(&options, "key", "flow"); ovsrec_interface_set_options(iface, &options); + smap_add(&bfd, "enable", "true"); + ovsrec_interface_set_bfd(iface, &bfd); + smap_destroy(&options); + smap_destroy(&bfd); port = ovsrec_port_insert(tc->ovs_txn); ovsrec_port_set_name(port, port_name); diff --git a/ovn/controller/ovn-controller.c b/ovn/controller/ovn-controller.c index 3f29b25..5eaf18c 100644 --- a/ovn/controller/ovn-controller.c +++ b/ovn/controller/ovn-controller.c @@ -237,6 +237,7 @@ main(int argc, char *argv[]) ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_interface_col_name); ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_interface_col_type); ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_interface_col_options); + ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_interface_col_bfd); ovsdb_idl_add_table(ovs_idl_loop.idl, &ovsrec_table_port); ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_port_col_name); ovsdb_idl_add_column(ovs_idl_loop.idl, &ovsrec_port_col_interfaces);