Re: FW: New Version Notification for draft-nitish-vrrp-bfd-00.txt

[Jeffrey Haas <[e-mail]>]

Nitish,

On Mon, Jun 15, 2015 at 01:37:04PM +0000, Nitish Gupta (nitisgup) wrote:
> We are proposing a peer learning mode in VRRP which will help in seamless
> integration of VRRP with BFD.
> We are looking forward to your comments on the draft.

I have some concerns about this draft.

My biggest concern is that if the system or network is unable to sustain the
appropriate centi-second rate for a single VRRP master, how will it handle
the potentially faster full-mesh BFD sessions presumably at a higher rate?

One possibility might be that you're considering VRRP to be implemented on a
portion of the network element that scales less nicely than BFD does on the
same network element.

A second concern I have is that the control paths being protected are not
necessarily the same.  VRRP is utilizing multicast to disseminate its state.
The BFD sessions in your proposal are unicast.  While protecting the unicast
addresses of the VRRP interfaces might be a useful feature, having the fate
not shared between the two detection mechanisms seems potentially hazardous.

Which brings up a different possibility: Why not utilize BFD multipoint to
protect the service?  This would involve some amount of innovation on that
feature, but might be a better match than unicast BFD sessions.  However,
protecting the same multicast address may run into implementation issues if
the receiver can't handle the BFD-speed multicast load.

In general, I question some of the motivation of this work but believe that
if the use case is appropriate there may be some potential to address the
technical issues.

-- Jeff