Hi Jeff/Maik, Thanks a lot for your comments and suggestions on the draft. We have incorporated all the below comments and comments given by Maik in the latest version.
URL:https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-01.txt Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-01 I am also including [email protected] as per your request. We are looking forward to hearing from you. Thanks, Nitish On 22/06/15 11:15 pm, "Jeffrey Haas" <[email protected]> wrote: >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
