[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, thank you for sharing your thoughts on the applicability of different BFD-based mechanisms to fast failure detection in an VRRP domain. Please find my notes below tagged GIM>>. Regards, Greg On Sat, Jul 5, 2025 at 11:07 AM Acee Lindem wrote: > Hi Yingzhen, Greg, Aditya, et al, > > I've

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Yingzhen, Greg, Aditya, et al, I've been asked offline on the best way forward for using BFD for VRRP Active liveliness detection. My opinion is that NO modifications to VRRP the BFD protocol are required other than generating an Active_Down event when the BFD session goes down. When a V

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Greg, "In my opinion, level of deployment, existing support of the particular protocol might be important metrics during planning product plans compared with the complexity of the solution and its impact on the base specification, but not as a factor influencing the standardization process." Sp

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Yingzhen, thank you for sharing your views on the two proposals (I cannot find any draft that describes applicability of S-BFD for sub-second convergence of VRRP). As I understand it, you consider two characteristic of the proposals: - impact on the VRRP - extent of deployment of the part

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi, Speaking as an individual contributor. I've read both drafts, and here is my understanding, please correct me if I'm wrong. Draft-ietf-rtgwg-vrrp-bfd-p2p extends VRRP with BACKUP ADVERTISEMENT, so a VRRP router can build a peer table, and then the corresponding bidirectional p2p BFD sessions

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, as I understand it, VRRP operates on a LAN segment. Is that correct? If that is the case, then p2mp BFD control messages can use the same IP and Ethernet encapsulations as VRRP packets. Backup Routers demultiplex p2mp BFD sessions using Active Router IP address and the value of My Identifi

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Greg, I'd expect as the editor of https://datatracker.ietf.org/doc/rfc8562/, you'd recognize the requirement for a P2MP delivery mechanism. The most obvious is a p2mp-sr-tree... So, if not a p2mp-sr-tree, what? You're comparing these drafts assuming the P2MP delivery exists when this isn't

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, thank you for your question. In your expert option, what could be the role of p2mp LSP in using p2mp BFD for fast detection of the Active Router in VRRP? Implementation of p2mp BFD was reported and mentioned in the Shepherd's Write-up

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, could you please help me to understand what you see in draft-ietf-rtgwg-vrrp-p2mp-bfd as the requirement for existence of p2mp-sr-tree between VRRP routers? IP encapsulation of BFD Control packets is the same as of VRRP mes

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

At risk of getting this wrong, I've compared the 2 or 3 proposals (depending on how you count): In comparing the two proposals, it seems the p2p proposal could converge slightly faster with multiple backup-routers due to the fact that they'll know which one should take over when the active tak

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

> On Mar 27, 2025, at 5:42 PM, Greg Mirsky wrote: > > Hi Acee, > AFAIK, there's at least one implementation of RFC 8562, which is the type of > p2mp BFD used in this draft. Also, I should note that the failure detection > mechanism in RFC 9026 Multicast VPN Fast Upstream Failover is RFC 8562

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Greg, > On Apr 2, 2025, at 4:21 PM, Greg Mirsky wrote: > > Hi Acee, > thank you for your question. In your expert option, what could be the role of > p2mp LSP in using p2mp BFD for fast detection of the Active Router in VRRP? My comment is that while the P2MP BFD RFC doesn't state require

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, thank you for sharing your analysis of the applicability of BFD mechanisms to ensure faster detection of an Active Router, thus enabling sub-second convergence in the VRRP. Please find my notes below tagged GIM>>. Regards, Greg On Fri, Mar 21, 2025 at 4:52 AM Acee Lindem wrote: > At ri

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Acee, AFAIK, there's at least one implementation of RFC 8562 , which is the type of p2mp BFD used in this draft. Also, I should note that the failure detection mechanism in RFC 9026 Multicast VPN Fast Upstream

[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence

Hi Greg, Is P2MP BFD widely deployed or even implemented? I know FRR doesn't support it. Also, prior to WG last call, can you provide the ietf-vrrp.yang augmentations the draft that would be needed to support this feature (both config and operational state)? Thanks, Acee > On Mar 21, 202