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 <acee.i...@gmail.com> wrote: > 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. GIM>> One disadvantage of the S-BFD approach, in my opinion, is that the number of BFD control packets injected into the network is twice as high as if p2mp BFD is used. That may become a significant obstacle in VRRP deployments where there are multiple VRRP groups with several Backup Routers per Active Router. > > > Thanks, > Acee > > > On Mar 21, 2025, at 6:21 AM, Acee Lindem <acee.i...@gmail.com> 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 <gregimir...@gmail.com> 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 -- rtgwg@ietf.org > >> To unsubscribe send an email to rtgwg-le...@ietf.org > > > >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
