Hi Acee, could you please help me to understand what you see in draft-ietf-rtgwg-vrrp-p2mp-bfd <https://datatracker.ietf.org/doc/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 <https://datatracker.ietf.org/doc/html/rfc9568> 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
