Skip to main content

Early Review of draft-ietf-rtgwg-vrrp-p2mp-bfd-14
review-ietf-rtgwg-vrrp-p2mp-bfd-14-opsdir-early-clarke-2026-07-29-00

Request Review of draft-ietf-rtgwg-vrrp-p2mp-bfd
Requested revision No specific revision (document currently at 15)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2026-08-07
Requested 2026-07-15
Requested by Yingzhen Qu
Authors Greg Mirsky , Jeff Tantsura , Gyan Mishra
I-D last updated 2026-08-02 (Latest revision 2026-08-02)
Completed reviews Opsdir Early review of -06 by Joe Clarke (diff)
Rtgdir Early review of -08 by Emmanuel Baccelli (diff)
Secdir Early review of -08 by Alexey Melnikov (diff)
Opsdir Early review of -14 by Joe Clarke (diff)
Secdir Early review of -15 by Alexey Melnikov
Rtgdir Early review of -14 by Mike McBride (diff)
Comments
The draft has gone through major changes based on the comments received. Please review and see if the draft is ready for WGLC.
Assignment Reviewer Joe Clarke
State Completed
Request Early review on draft-ietf-rtgwg-vrrp-p2mp-bfd by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/29i6samd6Jn-WCeA3xhtC_JeNTc
Reviewed revision 14 (document currently at 15)
Result Clarification Needed
Completed 2026-07-29
review-ietf-rtgwg-vrrp-p2mp-bfd-14-opsdir-early-clarke-2026-07-29-00
I've been asked to re-review this document on behalf of the OPS Directorate. 
I'm pleased to say my previous issues have resolved.  Thanks!  I do have a
couple additional questions, though.

First, the document is unclear on whether mixed mode operation is supported. 
That is, would it be okay with I have a VRRP group with two of the three
routers supporting p2mp BFD but the third does not?  I think some text on this
scenario might be helpful to operators.

Second, what scaling concerns exist in a multi-tenant environment where there
may be multiple VRRP groups per segment, each maintaining their own p2mp BFD
sessions?

I don't think either of this questions are blocking, but I do think operators
would appreciate some guidance on both.

I found one additional nit, too:

Section 1.1.1 still has "Pont-to-Multipoint" instead of "Point-to-Multipoint."