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 [email protected] for further comment. -- Jeff _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
