<Speaking as individual contributor> BFD YANG spec doesn't currently support multipoint, what I recall is that the DT had agreed to wait for the multipoint draft to become RFC.
I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be modified/augmented to support this capability? Regards, Reshad. From: Rtg-bfd <rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org>> on behalf of Jeff Haas <jh...@juniper.net<mailto:jh...@juniper.net>> Date: Wednesday, January 20, 2016 at 10:10 AM To: "Nitish Gupta (nitisgup)" <nitis...@cisco.com<mailto:nitis...@cisco.com>> Cc: "Aditya Dogra (addogra)" <addo...@cisco.com<mailto:addo...@cisco.com>>, "co...@doch.org.uk<mailto:co...@doch.org.uk>" <co...@doch.org.uk<mailto:co...@doch.org.uk>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "rt...@ietf.org<mailto:rt...@ietf.org>" <rt...@ietf.org<mailto:rt...@ietf.org>> Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <nitis...@cisco.com<mailto:nitis...@cisco.com>> wrote: The other thing I want to make sure if there is any particular configuration requirement from a BFD YANG model perspective. I understand that you are using the fast timer in BFD to detect next-hop IP address liveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p2mp BFD configuration as yet. Depending on how that discussion proceeds we might want to look at that also. [nitish] There is no particular requirement that we can see from BFD YANG model perspective. As VRRP should interface with BFD as another protocol using BFD as a means of fast failure detection of its peer. The desired behavior we're looking for in yang is ideally making use of the groupings exported by the BFD yang module. This permits a simple maintainable place to put BFD session parameters. There are two issues Mahesh is alluding to: 1. Multipoint is currently not in the BFD yang spec. Thus, the BFD yang team has homework to provide support for that option to allow modules such as a vrrp module supporting this feature to import it. 2. VRRP would only utilize this in *some* circumstances; namely the master/backup scenario rather than each backup. Configuration state would likely be consistent, but ti does make the operational state a bit trickier. The session is provisioned, but may not be started - and it may not even be *instantiated* depending on the implementation and whether the priority of the VRRP router is lower than the first available backup. -- Jeff
