Subject: [rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence
From: Acee Lindem <[email-masked]>
To: Greg Mirsky <[email-masked]>, Aditya Dogra <[email-masked]>, Nick Carlino <[email-masked]>
Cc: RTGWG <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 21 Mar 2025 07:51:52 -0400
List-Id: Routing Area Working Group <rtgwg.ietf.org>

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 takes goes down. However, VRRP attempts to remedy this with skew_time based on priority. The p2p proposal, however, come with the expense of having all the backup advertise when they are down (which I really don't know if it's worth it for this small potential for improvement).

If we can live with not having all the backups know about each other, it seems the proposal of just including an SBFD discriminator in the active's advertisement and have all the  potential backups form an SBFD session is the simplest. And if P2MP BFD is supported, this would be an optimization of this approach. Nick (copied) had previously proposed just using SBFD on the active but I don't think there was ever a draft. 

Thanks,
Acee 

> On Mar 21, 2025, at 6:21 AM, Acee Lindem <[email-masked]> wrote:
> 
> 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, 2025, at 4:34 AM, Greg Mirsky <[email-masked]> wrote:
>> 
>> Dear All,
>> As noted in the RTGWG meeting at IETF-122, two WG documents describe BFD-based solutions in support of faster convergence in the VRRP environment. Although both drafts use BFD mechanisms, these mechanisms are significantly distinct, resulting in very different modifications to the RFC 9568 VRRPv3 specification required by each solution. At some point in the past, a single draft documents both solutions. Since the solutions split, it seems that draft-ietf-rtgwg-vrrp-p2mp-bfd has evolved and is now ready for the WG LC. Hence, the question to the WG:
>>    • Do you object to maintaining and publishing separate documents that document BFD-based solutions in support of faster VRRP convergence?
>> 
>> Regards,
>> Greg
>> _______________________________________________
>> rtgwg mailing list -- [email-masked]
>> To unsubscribe send an email to [email-masked]
>