Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <09119318-5F5D-44F6-8544-9231E00758DB@gmail.com>
Date: Fri, 21 Mar 2025 07:51:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC72B3AF-AD90-470D-9BD5-5D7FC33FCF40@gmail.com>
References: 
 <CA+RyBmWZMKP0xwtpGuN1+Eamh7QV7ASOx4ARxKkumz8QRvjXpg@mail.gmail.com>
 <09119318-5F5D-44F6-8544-9231E00758DB@gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>,
 Aditya Dogra <addogra@cisco.com>,
 Nick Carlino <carlino65@msn.com>
Message-ID-Hash: L32VP47D5ZP6G3PCNRNLFWFB7DKQSNIC
CC: RTGWG <rtgwg@ietf.org>, draft-ietf-rtgwg-vrrp-bfd-p2p@ietf.org,
 draft-ietf-rtgwg-vrrp-p2mp-bfd@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Brtgwg=5D_Re=3A_Moving_forward_BFD-based_solutions_for_faster_VR?=
 =?utf-8?q?RP_convergence?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rtgwg/Wz3ent8SeGapgv996zvmAX6CDY8>

At risk of getting this wrong, I've compared the 2 or 3 proposals =
(depending on how you count):=20

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.=20=


Thanks,
Acee=20

> On Mar 21, 2025, at 6:21=E2=80=AFAM, Acee Lindem <acee.ietf@gmail.com> =
wrote:
>=20
> Hi Greg,=20
>=20
> Is P2MP BFD widely deployed or even implemented? I know FRR doesn't =
support it. =20
>=20
> 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)?=20
>=20
> Thanks,
> Acee
>=20
>> On Mar 21, 2025, at 4:34 AM, Greg Mirsky <gregimirsky@gmail.com> =
wrote:
>>=20
>> 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:
>>    =E2=80=A2 Do you object to maintaining and publishing separate =
documents that document BFD-based solutions in support of faster VRRP =
convergence?
>>=20
>> Regards,
>> Greg
>> _______________________________________________
>> rtgwg mailing list -- rtgwg@ietf.org
>> To unsubscribe send an email to rtgwg-leave@ietf.org
>=20