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

[Jeffrey Haas <[e-mail]>]

Nitish,

On Thu, Jun 18, 2015 at 08:40:42AM +0000, Nitish Gupta (nitisgup) wrote:
> Since VRRP might run in the control-plane like other routing protocols.
> It would be required that a faster failure mechanism (than its Protocol
> Hello messages) be used, and BFD serves the purpose very well.

Depending on a router's implementation, BFD may also run in the control
plane.  While not trying to be pedantic, I'd suggest that you need to
include in your use case that BFD in this proposal should NOT be implemented
in the control plane.  If both BFD and VRRP are implemented in software,
VRRP in a standalone fashion is likely more appropriate.

> To automate this operation, this draft proposes a mechanism where the VRRP
> devices can learn about its peers.
> Once learnt the peers can form the BFD session automatically (point to
> point or Multipoint).

It is a great tradition that BFD sessions can be bootstrapped through other
protocols.  This part is fine, whether it is single-hop or multipoint.

Since BFD is capable of being dynamically boostrapped, it may be also worth
pointing out that you can make this scale better by both provisioning fewer
BFD sessions and also being less aggressive about your timers.

For example, you could only bring up BFD sessions for the master and the
first likely backup for a given virtual router.  The additional backups need
not even be provisioned immediately.  You could also provision the backup to
use less aggressive timers until it becomes the master, after which you may
have BFD adjust its interval to the more aggressive timestamp.  Both of
these changes accommodates the common scaling considerations of BFD:
aggressiveness of the timers, and total number of sessions.

> We will incorporate your points about multipoint BFD in next version of
> our draft.

I'll look forward to it.  I'd also suggest copying [e-mail] for
further comment.

-- Jeff