[OPS-DIR]Re: draft-ietf-rtgwg-vrrp-p2mp-bfd-14 early Opsdir review

[Greg Mirsky <[e-mail]>]

Hi Joe,
thank you for the discussion; much appreciated. I will upload the new
version shortly.

Regards,
Greg

On Sun, Aug 2, 2026 at 10:28 AM Joe Clarke (jclarke) <[e-mail]>
wrote:

> This reads much better to me.  This would put the doc in the Ready state
> to me.
>
> Joe
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Sunday, August 2, 2026 at 13:16
> *To: *Joe Clarke (jclarke) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>
> *Subject: *Re: draft-ietf-rtgwg-vrrp-p2mp-bfd-14 early Opsdir review
>
> Hi Joe,
> thank you for the detailed explanation. Would the following update reflect
> your idea:
> OLD TEXT:
>    Operators should ensure that VRRP Advertisement intervals and BFD
>    timer values are coordinated so that the expected convergence
>    behavior is well understood.
> NEW TEXT:
>    In a VRRP group where both VRRP-native and BFD-based mechanisms are
>    used for detecting failure of the Active Router, the system can be
>    viewed as a multi-layer OAM environment, with p2mp BFD operating as a
>    lower-layer and faster failure-detection mechanism.  In such an
>    environment, operators should ensure that VRRP Advertisement
>    intervals and BFD timer values are coordinated so that the expected
>    convergence behavior is well understood.
>
>    Consistent with multi-layer OAM design principles, the failure-
>    detection interval at the lower layer is typically configured to be
>    at least three times shorter than the failure-detection interval at
>    the layer above it.  This relationship ensures that the faster
>    mechanism (p2mp BFD) reliably triggers failover before the VRRP-
>    native mechanism, while still allowing VRRP Advertisements to provide
>    a backup detection method.
>
> WDYT?
>
> Regards,
> Greg
>
> On Sat, Aug 1, 2026 at 5:15 PM Joe Clarke (jclarke) <[e-mail]>
> wrote:
>
> The text I was suggesting was to replace the somewhat vague, "Operators
> should ensure that VRRP Advertisement intervals and BFD timer values are
> coordinated so that the expected convergence behavior is well understood.”
>  I wasn’t sure your text was sufficient to instruct operators what to do,
> which is why I suggested a more concrete approach.
>
> Joe
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, July 31, 2026 at 20:34
> *To: *Joe Clarke (jclarke) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>
> *Subject: *Re: draft-ietf-rtgwg-vrrp-p2mp-bfd-14 early Opsdir review
>
> Hi Joe,
> thank you for your kind words. If an operator uses the p2mp BFD to ensure
> sub-second Active router failure detection, then the BFD Detection Time
> should be significantly shorter than the VRRP Active_Down_Interval. As both
> parameters are calculated based on configured values, the text refers to
> the VRRP Advertisement interval (Advertisement_Interval) and the BFD
> transmission interval. I tried to convey that in Section 5.1 as:
>    Operators should ensure that VRRP Advertisement intervals and BFD
>    timer values are coordinated so that the expected convergence
>    behavior is well understood.
>
> What text would you suggest?
>
> Regards,
> Greg
>
> On Fri, Jul 31, 2026 at 5:04 PM Joe Clarke (jclarke) <[e-mail]>
> wrote:
>
> These additions are great, Greg.  I appreciate the Ops Con section, too 😊
> .
>
> Is it worth being a bit more concrete in the timer suggestion in the
> second paragraph of 5.1?  Maybe something like:
>
> Operators should configure the p2mp BFD Detection Time to be equal to or
> shorter than the VRRP Master_Down_Interval.
>
> Joe
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, July 31, 2026 at 18:08
> *To: *Joe Clarke (jclarke) <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>
> *Subject: *Re: draft-ietf-rtgwg-vrrp-p2mp-bfd-14 early Opsdir review
>
> Hi Joe,
> Thank you again for your thoughtful questions. I propose adding a new
> Operational Considerations section as follows:
> 5.  Operational Considerations
>
> 5.1.  Mixed-mode Operation
>
>    In deployments where a VRRP group contains routers that support the
>    use of p2mp BFD as described in this specification and others that do
>    not, the mechanism continues to operate correctly, but convergence
>    characteristics will differ among routers.  Routers that support p2mp
>    BFD will detect failure of the Active Router based on BFD session
>    state and may transition to Active more quickly than routers relying
>    solely on VRRP Advertisement timers.  Conversely, if the Active
>    Router does not support p2mp BFD, all routers—regardless of BFD
>    capability—will converge based on VRRP Advertisement timeout.
>
>    Operators should ensure that VRRP Advertisement intervals and BFD
>    timer values are coordinated so that the expected convergence
>    behavior is well understood.  In mixed-mode deployments, routers
>    within the VRRP group may detect failure of the Active Router at
>    different times, depending on whether they rely on p2mp BFD or VRRP
>    Advertisements.  From the host’s perspective, however, failover is
>    determined by the fastest detection mechanism that results in a new
>    Active Router being elected and advertising the virtual router
>    address.
>
> 5.2.  Scaling Considerations in Multi-tenant Environment
>
>    In multi-tenant deployments, multiple VRRP groups may exist on the
>    same segment, each maintaining its own p2mp BFD session.  The scaling
>    impact depends primarily on the operator’s convergence objectives.
>    If sub-second convergence is required, an operator may choose either
>    sub-second VRRP Advertisement intervals or sub-second BFD
>    transmission intervals.  Using p2mp BFD for failure detection allows
>    VRRP Advertisement intervals to remain relatively large (e.g., one
>    second), thereby reducing the overall volume of VRRP control traffic
>    even when many VRRP groups are present.
>
>    Because p2mp BFD uses a single multipoint session per VRRP group, the
>    incremental overhead scales linearly with the number of groups.  In
>    environments with a large number of VRRP groups, operators should
>    ensure that BFD transmission intervals and VRRP Advertisement
>    intervals are configured to balance convergence requirements with the
>    control plane load.
>
> I attached the working version of the draft.
>
> Regards,
> Greg
>
> On Wed, Jul 29, 2026 at 11:24 AM Greg Mirsky <[e-mail]>
> wrote:
>
> Hi Joe,
> Thank you for your kind words and thoughtful questions. Please find my
> notes below, tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Jul 29, 2026 at 11:02 AM Joe Clarke via Datatracker <
> [e-mail]> wrote:
>
> Document: draft-ietf-rtgwg-vrrp-p2mp-bfd
> Title: Applicability of Bidirectional Forwarding Detection (BFD) for
> Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)
> Reviewer: Joe
> Clarke Review result: Clarification Needed
>
> 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.
>
> GIM>> A very good question that reflects a realistic scenario. I think
> that if a VRRP group is heterogeneous in regard to this draft, then it is
> important that BFD and VRRP timers are coordinated. I imagine that BFD
> timers will be at least three times shorter than VRRP Hello timers. Then,
> if the Active Router that uses p2mp BFD as described in the draft goes
> down, VRRP routers that were listening to BFD would converge faster and
> select the new Active Router. But if the Active Router doesn't support p2mp
> BFD, then convergence time will be determined by the VRRP Hello timer.
>
>
> 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?
>
> GIM>> If the goal is to support a sub-second convergence within a VRRP
> group, then an operator can use sub-second VRRP Hello interval or
> sub-second interval between BFD control messages with VRRP Hello
> transmitted, e.g., at single seconds intervals. Hence, in my opinion, using
> p2mp BFD to ensure faster convergence may significantly reduce the amount
> of VRRP Hello messages if the VRRP group is composed of several VRRP
> routers.
>
>
> 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."
>
> GIM>> Thanks! Will fix it in the next version.
>
>