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
