Feature request - BFD for BGP with route servers

[apolyr]

Bird (and other route severs) supports BFD for BGP for quite a while.

Under "Edit VLAN Interface", please add a "Enable BFD" checkbox (preferably this should be greyed out when "Route Server Client" is deselected).

This value should be exposed to the templates that produce the RS configuration, so as to activate BFD only on BFD-enabled peers.

[rasssta]

Great suggestion! +1 from me :)

[apolyr]

Just for completeness, let me just add that you might want to have different checkboxes for v4/v6 bfd, but since there is only one checkbox for "route server client", it might make more sense to keep one checkbox for bfd as well.

[barryo]

Adding a checkbox is not a big deal - it's really how far do we want to take it. So, we would need to flesh out:

1. a separate checkbox for v4 and v6: I think no on this as bfd is not generally enabled separately on a per protocol basis / run in parallel for v4 and v6. If a BFD test for v4 succeeds then the link is sound and should also apply for v6 (and vice versa).

2. we have a MD5 configuration option for BGP and when set, it applies to as112 / route collector and route server sessions. Should the same MD5 be used for BFD when set? Or a new field? The former aids simplicity but the latter adds flexibility to allow for enabling authentication for one and not the other. Or should the check box for BFD be a dropdown with: No / Yes, no authentication / Yes, authentication ?

3. How do we distinguish whether bfd should be enabled for as112 / route collector / route servers? We can easily add a checkbox to the router database entry that says bfd is supported or not and would then be configured if supported. What if a member has bfd support on route servers but not route collectors? Trying to solve these edge cases in the current schema is quite difficult.

4. Of course the only critical service here is really route servers and so do we just limit the overall scope to that by default? (noting that much can be done on an IXP by IXP basis via templating).

[apolyr]

We have a different approach for as112: AS112 peers only with our route servers (static config, not produced by IXPmanager); then other peers use the existing tools (i.e. communities) to reach/exclude AS112. IMHO, AS112 is outside the scope of IXPManager...

We do not use a route collector either (but I do consider this in scope), It seems to me that RC and RS could share the same bfd/md5 config for simplicity -- apparently separating them would be more complete. I do not have a strong opinion here.

With regard to v4/v6 separation, your point is valid, but when it comes to implementation I believe that you cannot associate a v6 peering with a v4 bfd... To be more honest, I have not tried it (we still use different daemon instances for v4/v6). In any case, for simplicity, I agree to have common parameters for both protocols.

[rasssta]

My 5c:

One combined setting for v4/v6 and only enable it for RS. Don't bother with auth.

[nickhilliard]

simpler is better, so I'd also be in favour of combined ipv4 / ipv6, only for RS and no new auth token.

[rfc1036]

The problem with a combined v4/v6 setting for BFD is that some platforms (e.g. Cisco 6500 with 12.2S) only implemented it for IPv4.

[nickhilliard]

bgp should still come up if one side is disabled/notimplemented, no?

[rfc1036]

Yes, it does.

[nickhilliard]

so separate tokens for v4/v6 don't add anything in this situation :-)

[rasssta]

Any news regarding this one? :)