[rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence
Acee Lindem <acee.ietf@gmail.com> Fri, 21 March 2025 11:52 UTC
Return-Path: <acee.ietf@gmail.com>
X-Original-To: rtgwg@mail2.ietf.org
Delivered-To: rtgwg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 448ED1086B5D; Fri, 21 Mar 2025 04:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNiWjuLNJ7WV; Fri, 21 Mar 2025 04:52:04 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id CFC061086B58; Fri, 21 Mar 2025 04:52:04 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-7c07cd527e4so183038485a.3; Fri, 21 Mar 2025 04:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742557924; x=1743162724; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O3jajAvyHp9NgmCMGK9qSN72nFGVC3bF9AplOXDlZ+w=; b=WmiECb2rg8F/u5DZMQ/NCKLEvgmtnfTDU0GyacFwO2IBjC1Jzr3PpgpMMe/eslsFn5 /BYHA6wgISpFsVGC3ruDt324lihO4YSf+HzeJSbQQ6RFWiGYVbg5Y9j+2Jrnu74xwA1E WmFyobWj0Y0GgY7stLYLDsyN2AqdmiAXc7mEYU3CMAArc68SxDIoX1qp6NFVjbB+VZI6 I17++Nvh8iQ15OgE9R1okocum/4aiRbVOqqxmXH5F4/cQcDhVXxuTQngFjyLWlz8gUh8 CywHvJXKbqBL88em4DId35grZPfPdz8+nO0a5a4LbGas1fwzs1rPNmFOJ/V/wrm18DPc kteg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742557924; x=1743162724; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O3jajAvyHp9NgmCMGK9qSN72nFGVC3bF9AplOXDlZ+w=; b=N97QcKO0qPmzoaHw6mC4Tn05Kx5PFtc4Fn5Cot/Ei/htcmclgacwKS8Yb9I2qXVfTX zShj8hONhsyZIJPHzJpluN073xt7cXbrWT/mT3NfnpUk4D8LjUTl31az2uIPDpKSxiyO 6fIqjAIfBKe5i2AwyohXS18tBZhElllCV96bnCF2IhS7qYbTdh1/EXNwhQkWlcdctqvN LFLM7eXd4xt6sSz9fDorXxbY2TKMPrt//RJi/0OPVYmQI7+2Mb7r8lGDknDxTx3laFJa uNEHnEjhrPWYLTgsnPHCN2mNObSGalLYafoseaREPsPKPIxEmdw7lB0eEdoUpT/W0Rfi VcpA==
X-Forwarded-Encrypted: i=1; AJvYcCU1wj1TfoOhslGoBKw/Nmzs8z83ODEnOzuCqvub0sNoH+sLzpwnw4MqtOm2Sg15EAFKflMMQoB+Aro0oDQoBD1S6N18IPQrdKG2x+jGOQ==@ietf.org, AJvYcCViXmE5JRaRDkzWujpXc+JmEBdw2jaO9K6PvwyyeZVNodoy9mPuk2xdk0zUyQtMVwjhJr9VPZ0cGqaJ+F+ZSpOiTNlc641nbYh5KK45w8bN@ietf.org
X-Gm-Message-State: AOJu0YyAdWC4PyWnY2Ycp823sYDU3ldAK/jmlEseViE/BOBhtEIeKPZB AR1o8yFjJ7vZTykeGo2hoVZFVI3fP3yWDUCuZQPBaDjTHogarUzF
X-Gm-Gg: ASbGncud803XFqRNaUHo8QEzJZ90TdBHB2WOWtIQ/cVAjNN0hfxOHFk5y3eGPs7ENMr rSSmlHEDpA4CfpRX+Uz/1cnblwXs7izY625rS8ieH5m9usNfC/6RLeYARHc5zD7S8iZnG/ECcjw LEtX39LuNfBv3sgoiNCx4NX0n3Hs49bjdBQ2M3RZRIayEEYyuXrz8YnPuRY0xJK6uZdXDgiWnCz LcbcrMkDnQdyotVTNFnZLdPLUzD1jK3RYXCveT5Deh69wQFDt2KE3MnBEVX6hvWecOCnoPpjJ4D flW5EJHy/CNxN3zeQ2ylHHHWnZ2gLCQNcqrvXjH5tr7F6tiB3u6OrSTW8oxY
X-Google-Smtp-Source: AGHT+IFQfunHViqI2zNk2fQF2ctKdlVwBFFhcj9jqHASfC/QelXI9pGa4o9Mjt+pkRrB22dv2nFxzw==
X-Received: by 2002:a05:620a:2943:b0:7c5:94b2:99da with SMTP id af79cd13be357-7c5ba183ac5mr328817385a.28.1742557924154; Fri, 21 Mar 2025 04:52:04 -0700 (PDT)
Received: from smtpclient.apple ([136.56.90.242]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c5b935846dsm122393885a.98.2025.03.21.04.52.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Mar 2025 04:52:03 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
Message-ID-Hash: L32VP47D5ZP6G3PCNRNLFWFB7DKQSNIC
X-Message-ID-Hash: L32VP47D5ZP6G3PCNRNLFWFB7DKQSNIC
X-MailFrom: acee.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtgwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: RTGWG <rtgwg@ietf.org>, draft-ietf-rtgwg-vrrp-bfd-p2p@ietf.org, draft-ietf-rtgwg-vrrp-p2mp-bfd@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rtgwg] Re: Moving forward BFD-based solutions for faster VRRP convergence
List-Id: Routing Area Working Group <rtgwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/Wz3ent8SeGapgv996zvmAX6CDY8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Owner: <mailto:rtgwg-owner@ietf.org>
List-Post: <mailto:rtgwg@ietf.org>
List-Subscribe: <mailto:rtgwg-join@ietf.org>
List-Unsubscribe: <mailto:rtgwg-leave@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 <acee.ietf@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 <gregimirsky@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-leave@ietf.org >
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Moving forward BFD-based solutions for fa… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Yingzhen Qu
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky
- [rtgwg] Re: Moving forward BFD-based solutions fo… Yingzhen Qu
- [rtgwg] Re: Moving forward BFD-based solutions fo… Acee Lindem
- [rtgwg] Re: Moving forward BFD-based solutions fo… Greg Mirsky