Internet Engineering Task Force                              N. Serafini
Internet-Draft                                                Individual
Updates: 3768, 9568 (if approved)                        27 January 2025
Intended status: Experimental                                           
Expires: 31 July 2025


               Fast failure detection in VRRP with S-BFD
                        draft-nser-vrrp-sbfd-01

Abstract

   The Virtual Router Redundancy Protocol (VRRP) protocol depends on the
   availability of layer three (3) IPvX connectivity between redundant
   peers and it can interact with the variant of Seamless Bidirectional
   Forwarding Detection (S-BFD) protocol to achieve a much faster
   failure detection.

   This document describes how to extend the VRRP protocol to support
   S-BFD as a detection system for Primary Router failures.  To announce
   the use of this implementation, a new VRRP packet type and a new
   timer are defined.  To facilitate and increase the user experience
   while deploying this implementation, an auto-calculation algorithm
   for the S-BFD Discriminators is also implemented.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Serafini                  Expires 31 July 2025                  [Page 1]

Internet-Draft               VRRP and S-BFD                 January 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   4.  Required Features . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Timers for Primary election . . . . . . . . . . . . . . .   4
     4.2.  Local S-BFD Discriminator generation  . . . . . . . . . .   4
     4.3.  Remote S-BFD Discriminator generation . . . . . . . . . .   4
     4.4.  S-BFD Discriminator length  . . . . . . . . . . . . . . .   5
     4.5.  VRRP support  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Known Limitations . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Inconsistency . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  VRRP state machine and S-BFD operational mode . . . . . . . .   7
   8.  VRRP and S-BFD state machines interoperability  . . . . . . .   7
   9.  Relation maintenance  . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Relation requirements . . . . . . . . . . . . . . . . . .   8
       9.1.1.  Primary state . . . . . . . . . . . . . . . . . . . .   8
       9.1.2.  Backup state  . . . . . . . . . . . . . . . . . . . .   8
       9.1.3.  Initialize state  . . . . . . . . . . . . . . . . . .   9
   10. S-BFD Discriminator calculation . . . . . . . . . . . . . . .   9
     10.1.  Pairing function . . . . . . . . . . . . . . . . . . . .   9
     10.2.  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.3.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.4.  Recursive calculation  . . . . . . . . . . . . . . . . .  10
     10.5.  Learning the SBFDInitiator Your Discriminator field  . .  10
   11. Timers  . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   12. Operational requirements  . . . . . . . . . . . . . . . . . .  10
     12.1.  Initialize state . . . . . . . . . . . . . . . . . . . .  10
     12.2.  VRRP Backup state  . . . . . . . . . . . . . . . . . . .  12
     12.3.  Primary state  . . . . . . . . . . . . . . . . . . . . .  15
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  18
   Appendix A.  Previous works . . . . . . . . . . . . . . . . . . .  19
   Appendix B.  Tools  . . . . . . . . . . . . . . . . . . . . . . .  19
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19



Serafini                  Expires 31 July 2025                  [Page 2]

Internet-Draft               VRRP and S-BFD                 January 2025


   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Bidirectional Forwarding Detection (BFD) defined in [RFC5880] is a
   specialized protocol to detect failures between a pair of systems in
   microseconds; [RFC5881] extends [RFC5880] to IPvX addresses in
   single-hop.  BFD has a lot of implementations and they are the
   standard for the industry.  As an extension of BFD, the Seamless
   Bidirectional Forwarding Detection (S-BFD) protocol defined in
   [RFC7880] was developed to allow a simplified mechanism for using BFD
   with a large proportion of negotiation aspects eliminated, thus
   providing benefits such as quick provisioning, as well as improved
   control and flexibility for network nodes initiating path monitoring;
   [RFC7881] is the extension of [RFC7880] for IPvX and MPLS networks.

   The Virtual Router Redundancy Protocol (VRRP) protocol is the actual
   open standard for the First Hop Redundancy Protocol (FHRP)
   implementation in IPvX networks; it's version two (2) is defined in
   [RFC3768] and the version three (3) is defined in [RFC9568]; VRRP
   provides an algoritmh for Primary election and also a standard for
   interoperability between vendors.  VRRP version two (2) defined in
   [RFC3768] can detect failures in second and its succesor [RFC9568] in
   centisecond.

   [RFC7881] meets [RFC3768] and [RFC9568] when the failure in a IPvX
   networks MUST be detected in microseconds or milliseconds.

2.  Terminology

   VRRP
      Virtual Router Redundancy Protocol

   BFD
      Bidirectional Forwarding Detection

   S-BFD
      Seamless Bidirectional Forwarding Detection

   FHRP
      First Hop Redundancy Protocol

   SBFD_Handler
      New handler added to the Virtual Router.  It is triggered when
      S-BFD in Initiator operational mode detects a failure.





Serafini                  Expires 31 July 2025                  [Page 3]

Internet-Draft               VRRP and S-BFD                 January 2025


   SBFD_My_Discriminator
      New state variable added to the Virtual Router when it aims to use
      S-BFD as failure detection system.  Depending on the S-BFD
      operating mode, this value has different meanings.

   SBFD_Your_Discriminator
      New state variable added to the Virtual Router when it aims to use
      S-BFD as failure detection system.  This values is only used when
      VRRP aims to use S-BFD as Initiator.

   SBFD_Primary_Down_Timer
      New timer added to the Virtual Router.  It starts when S-BFD
      triggers the SBFD_Handler and is used as election algorithm.

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Required Features

   This section outlines the set of features that were considered
   mandatory and that guided the design of this document.

   There is no particular order and all required features listed below
   MUST be supported by this implementation.

4.1.  Timers for Primary election

   When required, this implementation MUST allow S-BFD to bypass the
   VRRP timers.

4.2.  Local S-BFD Discriminator generation

   All Router member of a specified VRRP domain MUST be able to
   calculate and generate a local S-BFD Discriminator that MUST be used
   as SBFDInitiator or SBFDReflector without previous knowledge of the
   other members, aknowledge or data exchange in the network.

4.3.  Remote S-BFD Discriminator generation

   While in VRRP Backup state machine, all Routers member of a specified
   VRRP domain MUST be able to calculate and generate the remote S-BFD
   Discriminator for the VRRP Primary Router acting as SBFDReflector
   with the standard VRRP packet type two (2) defined in this document.



Serafini                  Expires 31 July 2025                  [Page 4]

Internet-Draft               VRRP and S-BFD                 January 2025


4.4.  S-BFD Discriminator length

   The auto generated S-BFD Discriminator MUST have a length of 32-bit,
   as defined in [RFC5880].

4.5.  VRRP support

   This implementation MUST support both version of VRRP, version two
   (2) and three (3); therefore, it MUST support IPv4 and IPv6.

5.  Known Limitations

   Before using S-BFD as failure detection system with VRRP the
   following limitations MUST be considered.

5.1.  Inconsistency

   The application that implements this specification SHOULD be
   responsable for triggering an even when an inconsistency is detected
   between the state machine of VRRP and the S-BFD operational mode.

6.  Overview

   Each VRRP Router that wants to use S-BFD as failure detection system
   MUST calculate it's local S-BFD Discriminator and depending on the
   VRRP state machine it MUST act as SBFDReflector or SBFDInitiator.

   When VRRP is in Primary state and want the others to monitor this
   entity, it MUST start a new SBFDReflector session with the previous
   generated local S-BFD Discriminator and MUST annunce the use of this
   implementation by sending a VRRP advertisement packet type two (2).
   When VRRP is in Backup state and it wants to monitor the Primary it
   MUST start a SBFDInitiator session againt this one.


















Serafini                  Expires 31 July 2025                  [Page 5]

Internet-Draft               VRRP and S-BFD                 January 2025


   To start a new session, the SBFDInitiator MUST learn the Primary
   SBFDReflector Discriminator and source IPvX troughthout the VRRP
   advertisement packet with type two (2) that it receives while in VRRP
   Backup state.  The SBFDInitiator MUST be responsible for compute the
   correct Your Discriminator field and monitor the Primary
   SBFDReflector for the learnt IPvX address.  When the SBFDReflector
   receives the control packet from a SBFDInitiator, it MUST lookup the
   incoming packet to locate a corresponding SBFDReflector session based
   on the value from the Your Discriminator field in the table
   describing S-BFD Discriminators.  The SBFDReflector allocate this
   value before transmitting the VRRP Primary advertisement packet.  The
   guidelines and the formula for the generation of the local and remote
   S-BFD Discriminator for both IPv4 and IPv6 VRRP Routers and how it is
   used to maintain the relation between those protocols states are
   discussed in this document.

   After an S-BFD session is established, if a state machine change of
   VRRP or S-BFD is triggered a Leader/Follower logic is implemented to
   increase the compatibility; this document also aims to clarify how
   strictly VRRP interoperate with the S-BFD operational mode and state
   machine; therefore, a new handler and a new timer are defined in
   conjuction with a new VRRP packet type.

   The following diagram may clarify how this specification works at
   high level.

       +---------------------+                +------------------------+
       |        Backup       |                |         Primary        |
       | +-----------------+ |                |    +-----------------+ |
       | |  SBFDInitiator  |---S-BFD Ctrl pkt----->|  SBFDReflector  | |
       | | +-------------+ |<--S-BFD Ctrl pkt------| +-------------+ | |
       | | |S-BFD Discrim| | |                |    | |S-BFD Discrim| | |
       | | |             | |---S-BFD Echo pkt---+  | |             | | |
       | | +-^-----------+ | |                | |  | +----------^--+ | |
       | +---|-------------+<-------------------+  +------------|----+ |
       |     |               |                |                 |      |
       | +---v----+          |                |             +---v----+ |
       | |  VRID  |          |                |             |  VRID  | |
       | +---^----+          |                |             +----^---+ |
       |     |               |                |                  |     |
       |     +----+          |                |             +----+     |
       |          |          |                |             |          |
       +---------[^]---------+                +------------[v]---------+
                  |                  VRRP                   |
                  +-------------------//--------------------+

                          Figure 1: VRRP and S-BFD




Serafini                  Expires 31 July 2025                  [Page 6]

Internet-Draft               VRRP and S-BFD                 January 2025


7.  VRRP state machine and S-BFD operational mode

   To facilitate the interoperability between this two protocols a
   reverse relation between the state machine of VRRP and the
   operational mode of S-BFD is developed.

   If VRRP is in Primary state, it MUST initialize a SBFDReflector
   session with the local auto calculated S-BFD Discriminator; when it
   acts as Backup Router, it MUST initialize a SBFDInitiator session
   with the local auto calculated S-BFD Discriminator as My
   Discriminator against the Primary Router; the destination of the
   initiator session is always the source IPvX from where the Primary
   VRRP packet with type two (2) is received and the value of Your
   Discriminator is calculated with the logic defined in this
   specification.  When VRRP is in Init state, means there are no S-BFD
   sessions linked with this VRID, VRRP version and IPvX.  This is
   because the S-BFD session can be initialized when trasmitting
   (Primary) or listening (Backup) for VRRP packets.

   The application that implements this specifican is responsable for
   maintaining the relation between VRRP and S-BFD if aims to use this
   specification; when an inconsistency is detected, it MUST be threaded
   as critical error.

8.  VRRP and S-BFD state machines interoperability

   As defined in [RFC7880], S-BFS has also a state machine; when
   operating in SBFDInitiator mode, it has two states: UP and DOWN; the
   DOWN state is triggered when a timer expires or when an AdminDown
   status is received from the remote Reflector session.  When in
   SBFDReflector operational mode, it can responde with: UP and
   AdminDown.

   In the case of SBFDReflector operational mode and VRRP Primary state
   machine, VRRP MUST be responsable for triggering the change on the
   corresponding S-BFD session.  When VRRP is in Backup state and S-BFD
   in Initiator operational mode, S-BFD MUST be responsable for
   triggering the SBFD_Handler and VRRP MUST be responsable for starting
   the SBFD_Primary_Down_Timer timer and monitor it.

   When VRRP is in Primary state and wants to send a priority zero (0)
   advertisement packet for releasing its state, it MUST relay over it's
   own mechanism defined in the VRRP standard.  The side effects is that
   the election algorithm is the same as the VRRP version used and not
   the one defined in this document.






Serafini                  Expires 31 July 2025                  [Page 7]

Internet-Draft               VRRP and S-BFD                 January 2025


   Is up to the application that implements this specification to decide
   how these protocols communicate their state changes one to each
   other.

9.  Relation maintenance

   The application that implements this specification is responsable for
   maintaining the relation between the S-BFD session, the current VRID
   and VRRP version for a given IPvX, and the operational mode of S-BFD
   for this particular VRRP state machine; in case of VRRP transitions,
   the application MUST relay over S-BFD to destroy the previous session
   and/or initialize a new one and, in case of SBFDInitiator transitions
   it MUST relay over the existing VRRP specification for state changes.

   The maintenance of this relation MUST be done throughout two state
   variables: SBFD_My_Discriminator and SBFD_Your_Discriminator; the
   behavior of these state variables depends on the current operational
   mode and is detailed in the next section.

   When acting as Initiator, the destination IPvX of the SBFDReflector
   learnt with the previous VRRP packet MAY NOT be saved and MAY only be
   used to initialize the S-BFD session.

9.1.  Relation requirements

   This section aims to clarify how the relations and the state
   variables are managed by each VRRP state machine.

   To be able to create an association, VRRP MUST save those state
   variables on its Virtual Router instance and use those values to
   identify, create or destroy the corresponding S-BFD session.

9.1.1.  Primary state

   SBFD_My_Discriminator
      SBFDReflector Discriminator calculated for this Virtual Router.
      This state variable MUST be initialized if the Primary Router
      wants the other to monitor its state throughout S-BFD and MUST be
      used to start the corresponding SBFDReflector session as My
      Discriminator.

9.1.2.  Backup state

   SBFD_My_Discriminator
      Required - SBFDInitiator Discriminator.






Serafini                  Expires 31 July 2025                  [Page 8]

Internet-Draft               VRRP and S-BFD                 January 2025


   SBFD_Your_Discriminator
      Required - SBFDReflector Discriminator learnt for this VRRP
      instance.

9.1.3.  Initialize state

   In this state the implementation MUST NOT maintain a relation and the
   previous sessions MUST be destroyed throughout S-BFD.

   There might be the case where VRRP is abnormally terminated and it is
   not able to notify S-BFD of this change; this behavior is discussed
   in Section 7 of this document.

10.  S-BFD Discriminator calculation

   The calculation used to generate the SBFD_My_Discriminator or
   SBFD_Your_Discriminator state variables is applicable to the remote
   as well to the local Router.  Based on the IPvX that send or receive
   VRRP packets troughthout the VRRP multicast group, the VRID and the
   VRRP version, with the below formula the Router MUST be able to
   calculate those values.  This calculation is implementad to
   facilitate the provision of VRRP with S-BFD without affecting the
   standard packet.

   In the case of IPv6, an exception MUST be applied.

10.1.  Pairing function

   The pairing function used in this document is calculated as follows,
   where x and y are non-negative integer.

   ( (x + y) * ( x + y + 1)/2 + y )

10.2.  IPv4

   From its binary format, each 16-bit of the IPv4 address are separated
   into two slices of 8-bit and then each slice converted to decimal;
   the result of this conversation are two integer number between 0 and
   255; those two integers of one octet are then computed to the pairing
   function defined below as x and y; the previous operations MUST be
   repited for each group of 16-bit and the result of each operation
   MUST be added to the previous one.  At the end of the previous
   calculation, the VRID and the VRRP version are also computed (in
   decimal format) to the pairing function previously defined and the
   result MUST be added to the total.

   The following example may clarify the formula for IPv4.




Serafini                  Expires 31 July 2025                  [Page 9]

Internet-Draft               VRRP and S-BFD                 January 2025


   ( ((x+y)*(x+y+1)/2 + y) + ((x1+y1)*(x1+y1+1)/2 + y1) +
   ((vrid+vrrp_version)*(vrid+vrrp_version+1)/2 + vrrp_version) )

10.3.  IPv6

   The logic for the IPv6 addresses is almost the same as for IPv4,
   except for the additional static value added at the end and required
   to differentiate IPV6 from IPv4.  If IPv6, a static integer value of
   294534 MUST also be added at the end.

10.4.  Recursive calculation

   The pairing function defined in above is not used in recursive mode
   for three (3) main reasons: the first one is that we have a fix
   length of values - 32-bit for IPv4 and 128-bit for IPv6 - and it does
   not change, the second is because the result generated from the
   calculation detailed in this document is smaller then the result of a
   recursive calculation where the previous result is paired with the
   next number; finally, in this way the calculation for IPvX requires
   one step less.

10.5.  Learning the SBFDInitiator Your Discriminator field

   The SBFDInitiator Your Discriminator field is managed as defined in
   RFC7880 Section 7.2.

11.  Timers

   The VRRP election algorithm includes the advertisement interval (VRRP
   failure detection mechanism) and cannot directly be used to implement
   this specification.  To avoid collisions, a dedicated S-BFD timer
   called SBFD_Primary_Down_Timer MUST be imlemented inside the VRRP
   Router to be able to comply with this specification.  This timer MUST
   be equal to the Skew_Time for the given VRRP version and MUST be
   started only when S-BFD in the Initiator operational mode triggers
   the VRRP SBFD_Handler for a DOWN or AdminDown change on the
   Reflector.

12.  Operational requirements

   This section define the operational requirements of this
   specification and how these protocols are integrated.

12.1.  Initialize state







Serafini                  Expires 31 July 2025                 [Page 10]

Internet-Draft               VRRP and S-BFD                 January 2025


+ If a Startup event is received, then:

    + If the Priority = 255, i.e., the router owns the IPvX
      address(es) associated with the Virtual Router, then:

[>]     + If S-BFD is required, then:
[>]
[>]       - Compute the SBFD_My_Discriminator.
[>]
[>]       - Start a new SBFDReflector session with SBFD_My_Discriminator as My Discriminator.
[>]
[>]       - Set the VRRP packet type to 2
[>]
[>]    + else
[>]
[>]       - Set the VRRP packet type to 1
[>]
[>]    + endif // is S-BFD required?

       - Send an ADVERTISEMENT

       + If the protected IPvX address is an IPv4 address, then:

         - For each IPv4 address associated with the Virtual
           Router, broadcast a gratuitous ARP message
           containing the Virtual Router MAC address and
           with the target link-layer address set to the
           Virtual Router MAC address.

       + else // IPv6

         - For each IPv6 address associated with the Virtual
           Router, send an unsolicited ND Neighbor
           Advertisement with the Router Flag (R) set, the
           Solicited Flag (S) clear, the Override flag (O)
           set, the target address set to the IPv6 address
           of the Virtual Router, and the target link-layer
           address set to the Virtual Router MAC address.

       + endif // was protected address IPv4?

       - Set the Adver_Timer to Advertisement_Interval

       - Transition to the {Primary} state

    + else // Router is not the address owner

       - Set Primary_Adver_Interval to Advertisement_Interval



Serafini                  Expires 31 July 2025                 [Page 11]

Internet-Draft               VRRP and S-BFD                 January 2025


       - Set the Primary_Down_Timer to Primary_Down_Interval

[>]    + If S-BFD is required, then:
[>]
[>]      - Set the SBFD_Primary_Down_Timer to Skew_Time
[>]
[>]    + endif // is S-BFD required?

       - Transition to the {Backup} state

    + endif // was priority 255?

+ endif // Startup event was received

12.2.  VRRP Backup state

While in Backup state, a VRRP Router MUST do the following:

    + If the protected IPvX address is an IPv4 address,
      then:

       - It MUST NOT respond to ARP requests for the IPv4
         address(es) associated with the Virtual Router.

    + else // protected address is IPv6

       - It MUST NOT respond to ND Neighbor Solicitation messages
         for the IPv6 address(es) associated with the Virtual Router.

       - It MUST NOT send ND Router Advertisement messages
         for the Virtual Router.

    + endif // was protected address IPv4?

    - It MUST discard packets with a destination link-layer
      MAC address equal to the Virtual Router MAC address.

    - It MUST NOT accept packets addressed to the IPvX
      address(es) associated with the Virtual Router.

    + If a Shutdown event is received, then:

       - Cancel the Primary_Down_Timer

[>]    + If S-BFD is required, then:
[>]
[>]       - Destroy the previous SBFDInitiator session.
[>]



Serafini                  Expires 31 July 2025                 [Page 12]

Internet-Draft               VRRP and S-BFD                 January 2025


[>]       - Cancel the SBFD_Primary_Down_Timer.
[>]
[>]    + endif // is S-BFD required?

       - Transition to the {Initialize} state

    + endif // Shutdown event received

[>] + If the SBFD_Handler event is received, then:
[>]
[>]    - Start the SBFD_Primary_Down_Timer.
[>]
[>] + endif // SBFD_Handler event received

[>] + If the Primary_Down_Timer OR the SBFD_Primary_Down_Timer fires, then:

[>]    + If S-BFD is required, then:
[>]
[>]       - Compute the SBFD_My_Discriminator.
[>]
[>]       - Start a new SBFDReflector session with SBFD_My_Discriminator as My Discriminator.
[>]
[>]       - Set the VRRP packet type to 2
[>]
[>]    + else
[>]
[>]       - Set the VRRP packet type to 1
[>]
[>]    + endif // is S-BFD required?

       - Send an ADVERTISEMENT

       + If the protected IPvX address is an IPv4 address, then:

          - For each IPv4 address associated with the Virtual
            Router, broadcast a gratuitous ARP message
            containing the Virtual Router MAC address and
            with the target link-layer address set to the
            Virtual Router MAC address.

       + else // IPv6

          - Compute and join the Solicited-Node multicast
            address [RFC4291] for the IPv6 address(es)
            associated with the Virtual Router.

          - For each IPv6 address associated with the
            Virtual Router, send an unsolicited ND Neighbor



Serafini                  Expires 31 July 2025                 [Page 13]

Internet-Draft               VRRP and S-BFD                 January 2025


            Advertisement with the Router Flag (R) set, the
            Solicited Flag (S) clear, the Override flag (O)
            set, the target address set to the IPv6 address
            of the Virtual Router, and the target link-layer
            address set to the Virtual Router MAC address.

       + endif // was protected address IPv4?

       - Set the Adver_Timer to Advertisement_Interval

[>]    + If S-BFD is required, then:
[>]
[>]       - Cancel the SBFD_Primary_Down_Timer timer.
[>]
[>]    + endif // is S-BFD required?

       - Transition to the {Primary} state

    + endif // Primary_Down_Timer fired

    + If an ADVERTISEMENT is received, then:

[>]    + If VRRP packet type is 2, then:
[>]
[>]       - Set the SBFD_My_Discriminator.
[>]
[>]       - Set the SBFD_Your_Discriminator.
[>]
[>]       - Start a new SBFDInitiator session against the Primary
[>]         Router using SBFD_My_Discriminator as My Discriminator
[>]         and SBFD_Your_Discriminator as Your Discriminator; the destination
[>]         IPvX of the new session is the source IPvX learnt from the
[>]         advertisement packet and the port is the same defined in [RFC7881].
[>]
[>]    + endif // is VRRP packet type 2?

       + If the Priority in the ADVERTISEMENT is 0, then:

          - Set the Primary_Down_Timer to Skew_Time

       + else // priority non-zero

          + If Preempt_Mode is False, or if the Priority in
            the ADVERTISEMENT is greater than or equal to the
            local Priority, then:

             - Set Primary_Adver_Interval to Max Advertise
               Interval contained in the ADVERTISEMENT



Serafini                  Expires 31 July 2025                 [Page 14]

Internet-Draft               VRRP and S-BFD                 January 2025


             - Recompute the Skew_Time

             - Recompute the Primary_Down_Interval,

             - Set the Primary_Down_Timer to Primary_Down_Interval

          + else // preempt was true and priority was less
                    than the local priority

             - Discard the ADVERTISEMENT

          + endif // preempt test

       + endif // was priority 0?

   + endif // was advertisement received?

endwhile // Backup state


12.3.  Primary state

   While in Primary state, a VRRP Router MUST do the following:

       + If the protected IPvX address is an IPv4 address, then:

          - It MUST respond to ARP requests for the IPv4
            address(es) associated with the Virtual Router.

       + else // IPv6

          - It MUST be a member of the Solicited-Node multicast
            address for the IPv6 address(es) associated with the
            Virtual Router.

          - It MUST respond to ND Neighbor Solicitation messages (with
            the Router Flag (R) set) for the IPv6 address(es) associated
            with the Virtual Router.

          - It MUST send ND Router Advertisements for the Virtual
            Router.

          + If Accept_Mode is False:  MUST NOT drop IPv6
            Neighbor Solicitations and Neighbor Advertisements.

       + endif // IPv4?

       - It MUST forward packets with a destination link-layer MAC



Serafini                  Expires 31 July 2025                 [Page 15]

Internet-Draft               VRRP and S-BFD                 January 2025


         address equal to the Virtual Router MAC address.

       - It MUST accept packets addressed to the IPvX address(es)
         associated with the Virtual Router if it is the IPvX
         address owner or if Accept_Mode is True.  Otherwise,
         MUST NOT accept these packets.

      + If a Shutdown event is received, then:

          - Cancel the Adver_Timer

   [>]    + If S-BFD is required, then:
   [>]
   [>]       - Set the VRRP packet type to 2
   [>]
   [>]    + else
   [>]
   [>]       - Set the VRRP packet type to 1
   [>]
   [>]    + endif // is S-BFD required?
   [>]

          - Send an ADVERTISEMENT with Priority = 0

          - Transition to the {Initialize} state

       + endif // shutdown received

       + If the Adver_Timer fires, then:

   [>]    + If S-BFD is required, then:
   [>]
   [>]       - Set the VRRP packet type to 2
   [>]
   [>]    + else
   [>]
   [>]       - Set the VRRP packet type to 1
   [>]
   [>]    + endif // is S-BFD required?

          - Send an ADVERTISEMENT

          - Reset the Adver_Timer to Advertisement_Interval

       + endif // advertisement timer fired

   [>] + If an ADVERTISEMENT type 1 or 2 is received, then:




Serafini                  Expires 31 July 2025                 [Page 16]

Internet-Draft               VRRP and S-BFD                 January 2025


          + If the Priority in the ADVERTISEMENT is 0, then:

   [>]       + If an ADVERTISEMENT type 2, then:
   [>]
   [>]          - Set the VRRP packet type to 2
   [>]
   [>]       + else
   [>]
   [>]          - Set the VRRP packet type to 1
   [>]
   [>]       + endif // is ADVERTISEMENT type 2?

             - Send an ADVERTISEMENT

             - Reset the Adver_Timer to Advertisement_Interval

          + else // priority was non-zero

             + If the Priority in the ADVERTISEMENT is greater
               than the local Priority or the Priority in the
               ADVERTISEMENT is equal to the local Priority and
               the primary IPvX Address of the sender is greater
               than the local primary IPvX Address (based on an
               unsigned integer comparison of the IPvX addresses in
               network-byte order), then:

                - Cancel Adver_Timer

                - Set Primary_Adver_Interval to Max Advertise
                  Interval contained in the ADVERTISEMENT

                - Recompute the Skew_Time

                - Recompute the Primary_Down_Interval

                - Set Primary_Down_Timer to Primary_Down_Interval

                - Transition to the {Backup} state

             + else // new Primary Router logic

                - Discard the ADVERTISEMENT

   [>]          + If an ADVERTISEMENT type 2, then:
   [>]
   [>]            - Set the VRRP packet type to 2
   [>]
   [>]          + else



Serafini                  Expires 31 July 2025                 [Page 17]

Internet-Draft               VRRP and S-BFD                 January 2025


   [>]
   [>]            - Set the VRRP packet type to 1
   [>]
   [>]          + endif // is ADVERTISEMENT type 2?

                - Send an ADVERTISEMENT immediately to assert
                  Primary state to the sending VRRP Router and
                  to update any learning bridges with the correct
                  Primary VRRP Router path.

             + endif // new Primary Router detected

          + endif // was priority zero?

       + endif // advert received

   endwhile // in Primary state

13.  IANA Considerations

   This memo includes request to IANA.

14.  Security Considerations

   This document aims to define how to accelerate the detection of a
   failure that affects VRRP functionality using S-BFD.

   The operation of either base protocols is not changed; therefore,
   there are not additional security considerations.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3768]  Hinden, R., Ed., "Virtual Router Redundancy Protocol
              (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004,
              <https://www.rfc-editor.org/info/rfc3768>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.





Serafini                  Expires 31 July 2025                 [Page 18]

Internet-Draft               VRRP and S-BFD                 January 2025


   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
              Pallagatti, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
              <https://www.rfc-editor.org/info/rfc7880>.

   [RFC7881]  Pignataro, C., Ward, D., and N. Akiya, "Seamless
              Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
              and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
              <https://www.rfc-editor.org/info/rfc7881>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9568]  Lindem, A. and A. Dogra, "Virtual Router Redundancy
              Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 9568,
              DOI 10.17487/RFC9568, April 2024,
              <https://www.rfc-editor.org/info/rfc9568>.

Appendix A.  Previous works

   This document was inspired by the previous work on VRRP and BFD done
   here: draft-ietf-rtgwg-vrrp-bfd-p2p-xx and draft-ietf-rtgwg-vrrp-
   p2mp-bfd-xx.

Appendix B.  Tools

   This document is based on templates written by Pekka Savola, Elwyn
   Davies and Henrik Levkowetz and maintened thanks to the open source
   xml2rfc project.

Acknowledgements

   Thanks to the RFC Authors of VRRP for their work on this Primary/
   Backup election protocol which helped since 1998.

   Thanks to the RFC Authors of BFD for their work on this failure
   detection protocol that helped to improve the Internet.

   Thanks to the RFC Authors of S-BFD for their work on this seamless
   BFD implementation that can be used in VRRP for a fast failure
   detection.




Serafini                  Expires 31 July 2025                 [Page 19]

Internet-Draft               VRRP and S-BFD                 January 2025


   Thanks to G.  Mirsky, J.  Tantsura, G.  Mishra, N.  Gupta, A.  Dogra
   and C.  Docherty for their previous work on VRRP and BFD.

   Thanks to the open source mainteners of VRRP and [S]BFD for their
   effort.

Contributors

   Contributions are welcome.

Author's Address

   Nicola Serafini
   Individual
   Email: n.serafini@tutanota.com




































Serafini                  Expires 31 July 2025                 [Page 20]