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 VRRP Router transitions to Active, Backup VRRP routers can quickly
initiate BFD sessions with the Active using RFC 9468 - "Unsolicited
Bidirectional Forwarding Detection (BFD) for Sessionless Applications". VRRP
seems like a perfect application of this RFC (copied Enke).
Furthermore, even if one did have to pre-configure the VRRP routers on the
interface requiring BFD, in most cases, you'd only be configuring a single
backup and more than two would be a rarity.
Thanks,
Acee
> On Jun 29, 2025, at 2:36 PM, Yingzhen Qu <yingzhen.i...@gmail.com> wrote:
>
> 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."
> Speaking as an individual contributor, I don't agree with this. I think easy
> deployment and operations should definitely be considered for protocol
> definition and extensions. At this point, I think both solutions have
> advantages and disadvantages.
>
> "Perhaps, as there are two solutions, the WG decides to publish both drafts
> and let the industry decide."
> Speaking as WG chair, we need WG consensus on this. I hope to allocate some
> time in the upcoming RTGWG session at IETF123 to solicit feedback on this
> topic. I will work with the authors from both drafts on this.
>
> Thanks,
> Yingzhen
>
> On Sat, Jun 28, 2025 at 5:59 PM Greg Mirsky <gregimir...@gmail.com> wrote:
> 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 particular flavor of BFD that is is used in
> the solution
> Is my understanding correct? If it is, then I need your help understanding
> the value of the second characteristic. 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. Perhaps, as there are two solutions, the WG decides
> to publish both drafts and let the industry decide. What are your thoughts?
>
> Regards,
> Greg
>
> On Wed, Jun 18, 2025 at 11:12 AM Yingzhen Qu <yingzhen.i...@gmail.com> wrote:
> 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 can be built based on the peer table. The advantage of this
> proposal is that BFD is well deployed and the number of BFD sessions to be
> established can be controlled through a configuration knob or similar
> mechanism, but it does require all backup routers to periodically send
> advertisements.
>
> Draft-ietf-rtg-vrrp-p2mp-bfd is built on top of RFC 8562, and makes use of
> VRRP multicast address ('224.0.0.18' for IPv4 and 'FF02:0:0:0:0:0:0:12' for
> IPv6) as destination IP address. It is simple if RFC 8562 is deployed.
> However, RFC 8562 is unfortunately not widely deployed.
>
> Seamless BFD (S-BFD RFC7880) was suggested as an alternative solution. Does
> anyone know the implementation/deployment status?
>
> Thanks,
> Yingzhen
>
> On Tue, Apr 8, 2025 at 12:58 PM Greg Mirsky <gregimir...@gmail.com> wrote:
> 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 Identifier, advertised by
> the Active Router. Hence, multicast distribution tree is not required for
> using p2mp BFD to detect failure of the Active Router. What am I missing here?
>
> Regards,
> Greg
>
> On Tue, Apr 8, 2025 at 11:54 AM Acee Lindem <acee.i...@gmail.com> wrote:
> 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 a realistic comparison. Where do these P2MP trees rooted at each VRRP
> router come from? They don't just grow on trees....
>
> Acee
>
> > On Apr 2, 2025, at 7:01 PM, Greg Mirsky <gregimir...@gmail.com> wrote:
> >
> > 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 messages described in Section 7.2 of RFC 9568 with
> > only difference that BFD uses UDP. What am I missing?
> >
> > Regards,
> > Greg
> >
> > On Wed, Apr 2, 2025 at 1:56 PM Acee Lindem <acee.i...@gmail.com> wrote:
> > Hi Greg,
> >
> > > On Apr 2, 2025, at 4:21 PM, Greg Mirsky <gregimir...@gmail.com> 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 it, the
> > implementation is based on a p2mp-sr-tree. So, would one require the
> > p2mp-sr-tree between VRRP routers for this to be used for faster VRRP
> > detection using BFD.
> > This seems like the wrong hammer for the job and your comparison is really
> > isn't comparing apples to apples since you're assuming this p2mp-sr-tree
> > exists.
> >
> > However, I don't have the time to debate this ad nauseam.
> >
> > Thanks,
> > Acee
> >
> >
> > >
> > > Implementation of p2mp BFD was reported and mentioned in the Shepherd's
> > > Write-up. Applicability of p2mp BFD according to RFC 8562 and RFC 8563
> > > specified in draft-ietf-mpls-p2mp-bfd. Although extensions defined in
> > > that draft are useful, I can imagine how RFC 8562 can be applied in p2mp
> > > LSP using other methods to bootstrap a p2mp BFD session.
> > >
> > > Regards,
> > > Greg
> > >
> > > On Wed, Apr 2, 2025 at 8:02 AM Acee Lindem <acee.i...@gmail.com> wrote:
> > >
> > >
> > > > On Mar 27, 2025, at 5:42 PM, Greg Mirsky <gregimir...@gmail.com> 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 p2mp BFD.
> > >
> > > Is this P2MP BFD or BFD on P2MP LSPs that someone has implemented? If I'm
> > > correct, then you'd require P2MP LSPs for VRRP?
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > >
> > > >
> > > > Regards,
> > > > Greg
> > > >
> > > > On Fri, Mar 21, 2025 at 3:22 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
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
