Hi Jeff, Thanks for your comments on the draft.
Yes you are correct, the assumption is VRRP may be implemented in control-plane along with other routing protocols. As VRRP depends on Advert(Hello) messages to detect the master Router availability. It might not scale well in case there are large number of VRRP instances on the device and all of them send Advert(Hello) messages at a fast Rate. 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. The motivation behind this draft is to be able to provide a mechanism where this integration can be achieved with less manual intervention or configuration. As we have outlined in the Draft, if VRRP interfaces with BFD, each Router taking part in the VRRP instance needs to know about its peers. In current VRRP specification its only the Master VRRP router that sends Advert(Hello) messages. So the Master is not aware of any backups, also the Backups are not aware of other backups. One potential solution could be to configure the Address of VRRP peers on each peer statically. But with this approach if there is a new device joining the VRRP instance, the information about this new peer would have to be made available to other peers by manual configuration Which can quickly become tedious if there are more device or more Virtual router instances participating in the VRRP instance. Even with multipoint BFD, this config would still need to be done, to statically populate the peer table on each peer. 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). Also if there is another peer joining the network, there will be no manual intervention required. The peer will announce itself when joining the network, as well as learn about its peers already present in the network. As rightly pointed by you, multipoint bfd can simplify the design, instead of point to point connections initiated by VRRP. But as we have outlined with Multi-point BFD as well, VRRP needs a mechanism to learn its peer nodes. Which is what we are purposing in this draft. We will incorporate your points about multipoint BFD in next version of our draft. Thanks, Nitish On 16/06/15 7:48 am, "Jeffrey Haas" <[email protected]> wrote: >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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
