Internet Engineering Task Force N. Serafini Internet-Draft Individual Updates: 3768, 9568 (if approved) 11 December 2024 Intended status: Experimental Expires: 14 June 2025 Fast failure detection in VRRP with S-BFD draft-nser-vrrp-sbfd-00 Abstract Since the VRRP protocol depends on the availability of Layer 3 IPvX connectivity between redundant peers, the VRRP protocol can interact with the variant of S-BFD as described in [RFC7881] to achieve a much faster failure detection. This document describes how to extend the Virtual Router Redundancy Protocol (VRRP) to support Seamless Bidirectional Forwarding Detection (S-BFD) as a detection system for Primary Router failure. To announce the use of this implementation, a new type (Section 5.2.2.) of VRRP packet and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the SBFD 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 14 June 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Serafini Expires 14 June 2025 [Page 1] Internet-Draft VRRP and S-BFD December 2024 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 4.6. Interoperability . . . . . . . . . . . . . . . . . . . . 5 5. Known Limitations . . . . . . . . . . . . . . . . . . . . . . 5 5.1. State machines inconsistency . . . . . . . . . . . . . . 5 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. VRRP state machine and S-BFD operational mode . . . . . . . . 6 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. Secondary state . . . . . . . . . . . . . . . . . . . 8 9.1.3. Initialize state . . . . . . . . . . . . . . . . . . 9 10. S-BFD Discriminator calculation . . . . . . . . . . . . . . . 9 10.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.3. Recursive calculation . . . . . . . . . . . . . . . . . 10 10.4. Learning the SBFDInitiator Your Discriminator field . . 10 11. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. VRRP timers for S-BFD . . . . . . . . . . . . . . . . . 11 12. Operational requirements . . . . . . . . . . . . . . . . . . 11 12.1. Initialize state . . . . . . . . . . . . . . . . . . . . 11 12.2. VRRP Secondary state . . . . . . . . . . . . . . . . . . 12 12.3. Primary state . . . . . . . . . . . . . . . . . . . . . 16 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Previous works . . . . . . . . . . . . . . . . . . . 20 Appendix B. Tools . . . . . . . . . . . . . . . . . . . . . . . 20 Serafini Expires 14 June 2025 [Page 2] Internet-Draft VRRP and S-BFD December 2024 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. 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. 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. 2. Introduction BFD [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 extension of BFD, [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. Serafini Expires 14 June 2025 [Page 3] Internet-Draft VRRP and S-BFD December 2024 VRRP is the actual open standard for the FHRP implementation in IPvX networks; it's version two is defined in [RFC3768] and the version three is defined in [RFC9568]. VRRP provides an algoritmh for Primary election and also a standard for interoperability between vendors. VRRPv2 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 network MUST be detected in microseconds or milliseconds. 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 and replace the VRRP timers to achive a more fast Primary election. 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 Secondary machine state, 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 14 June 2025 [Page 4] Internet-Draft VRRP and S-BFD December 2024 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 2 and 3; therefore, it MUST support IPv4 and IPv6. 4.6. Interoperability This implementation MUST allow VRRPv2 and VRRPv3 to interoperate when using this specification or not. 5. Known Limitations Before using S-BFD as failure detection system with VRRP the following limitations MUST be considered. 5.1. State machines inconsistency The application that implements this specification SHOULD be responsable for monitoring the availability of both services and trigger an even when a potential inconsistency is detected between the state machine of VRRP and S-BFD. 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 machine state it MUST act as SBFDReflector or SBFDInitiator. When VRRP is in Primary state and want the others to monitor this entity MUST start a SBFDReflector session with the previous generated local S-BFD Discriminator and MUST annunce the use of this implementation by sending a VRRP packet Type Two (2) defined below. When VRRP is in Secondary state, and it want to monitor the Primary it MUST start a SBFDInitiator session againt this one. To start a new session, the SBFDInitiator MUST learn the Primary SBFDReflector Discriminator and source IPvX troughthout the VRRP packet with Type Two (2) that it receives while in VRRP Seconday 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 Serafini Expires 14 June 2025 [Page 5] Internet-Draft VRRP and S-BFD December 2024 the Your Discriminator field in the table describing S-BFD Discriminators. The SBFDReflector allocate this value before transmitting the VRRP Primary packet. The guidelines 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 - the formula is also discussed. 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. +---------------------+ +------------------------+ | Secondary | | 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 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. Serafini Expires 14 June 2025 [Page 6] Internet-Draft VRRP and S-BFD December 2024 VRRP is in Primary state, it MUST initialize a SBFDReflector session with the local auto calculated S-BFD Discriminator; when it acts as Secondary Router, it MUST initialize a SBFDInitiator session with the local auto calculated S-BFD 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 (Secondary) for VRRP packets. 8. VRRP and S-BFD state machines interoperability As defined in [RFC7880], S-BFS has also a machine state and it MUST not be confused with the operational mode; when S-BFD applies his machine state in SBFDInitiator operational mode it has three states: UP, DOWN and AdminDown; the AdminDown state is triggered when received from the remote Reflector session. The SBFDReflector has only two states machine: 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 except when the S-BFD session goes into AdminDown itself; in such case, S-BFD MUST notify VRRP and this one MUST trigger the Secondary state. This behavior is NOT RECCOMENDED and SHOULD always be VRRP to turn S-BFD state machine changes. When VRRP is in Secondary 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. When VRRP is in Primary state and wants to send a priority zero (0) advertisement packet for releasing its state, it MUST first turn into AdminDown the corresponding S-BFD session and then it MUST send the advertisement with priority zero (0) as defined in the VRRP standard. The application that implements this specifican is responsable for monitoring the availability of VRRP and S-BFD if aims to use this implementation. When one module fails, it MUST be threaded as inconsistency. This specification does not define how VRRP and S-BFT are integrated; is up to the application that implements this document to decide how these protocols communicate their state changes one to the other. The interoperability between state machines is discussed in detail in Section 12. Serafini Expires 14 June 2025 [Page 7] Internet-Draft VRRP and S-BFD December 2024 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 machine state; 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 machine state. To be able to create an association, VRRP MUST save those state variables on its Virtual Router instance and use those values to create o 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. Secondary state SBFD_My_Discriminator Required - SBFDInitiator Discriminator. SBFD_Your_Discriminator Required - SBFDReflector Discriminator learnt for this VRRP instance. Serafini Expires 14 June 2025 [Page 8] Internet-Draft VRRP and S-BFD December 2024 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 the "VRRP and S-BFD state machines interoperability" section 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. IPv4 From its binary format, each 16-bit of the IPv4 address are separated into two slices of 8bits 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 Cantor pairing function (in decimal format) 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 computed to the Cantor pairing function (in decimal format) and the result MUST be added to the total. The following example may clarify the formula for IPv4. ( ((x+y)*(x+y+1)/2 + y) + ((x1+y1)*(x1+y1+1)/2 + y1) + ((vrid+vrrp_version)*(vrid+vrrp_version+1)/2 + vrrp_version) ) Serafini Expires 14 June 2025 [Page 9] Internet-Draft VRRP and S-BFD December 2024 10.2. 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. Always from its binary format, each 16-bit of the IPv6 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 and those two integers of one octet are then computed to the Cantor pairing function (in decimal format) 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 computed to the Cantor pairing function (in decimal format) and the result MUST be added to the total. If IPv6, also a static integer value of 294534 MUST also be added at the end. 10.3. Recursive calculation The pairing function is not used in recursive mode for three main reasons: the first 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.4. 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 de advertisement interval (VRRP failure detection mechanism) and cannot directly be used to implement this specification. To avoid collisions, a dedicated S-BFD timer MUST be imlemented inside VRRP to be able to comply with this specification. This timer MUST be pre calculated and started only when the S-BFD in Initiator operational mode triggers the VRRP SBFD_Handler for a DOWN or AdminDown change on the Reflector. Serafini Expires 14 June 2025 [Page 10] Internet-Draft VRRP and S-BFD December 2024 11.1. VRRP timers for S-BFD VRRP in Secondary state machine MUST start this timer when the SBFDInitiator triggers the SBFD_Handler for a particual S-BFD session; when this happens, the timer SBFD_Primary_Down_Timer MUST replace the Primary_Down_Timer of VRRP specification in Secondary state. This new timer is definde below and its behavior is also described in the Operationl Requirement section. SBFD_Primary_Down_Timer Caluclated as: (256 - Priority) / 256 The result of this calculation is almost the same as VRRP, except for the advertisement and the static tolerance multipler. The short difference in the SBFD_Primary_Down_Timer timer when two or more Secondary Routers are deployed can be a problem if those Routers are not able to receive the Primary VRRP packet before their timer fire; in that case, they will become Primary with a potencial service disruption. To avoid this situation when using two or more Secondary Routers, is RECCOMENDED to use a difference between each Secondary Router priority enougth to permit the Routers to receive the Primary packet before raising the SBFD_Primary_Down_Timer timer. 12. Operational requirements This section define the operational requirements of this specification and how these protocols are integrated. 12.1. Initialize state + 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? Serafini Expires 14 June 2025 [Page 11] Internet-Draft VRRP and S-BFD December 2024 - 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 - Set the Primary_Down_Timer to Primary_Down_Interval [>] + If S-BFD is required, then: [>] [>] - Set the SBFD_Primary_Down_Timer. [>] [>] + endif // is S-BFD required? - Transition to the {Secondary} state + endif // was priority 255? + endif // Startup event was received 12.2. VRRP Secondary state Serafini Expires 14 June 2025 [Page 12] Internet-Draft VRRP and S-BFD December 2024 While in Secondary 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. [>] [>] - 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: [>] [>] - Set the Primary_Down_Timer to SBFD_Primary_Down_Timer. [>] [>] + endif // SBFD_Handler event received + If the Primary_Down_Timer fires, then: Serafini Expires 14 June 2025 [Page 13] Internet-Draft VRRP and S-BFD December 2024 [>] + If S-BFD is required, then: [>] [>] - Destroy the previous session as SBFDInitiator. [>] [>] - Set 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 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. [>] Serafini Expires 14 June 2025 [Page 14] Internet-Draft VRRP and S-BFD December 2024 [>] + 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 session as SBFDInitiator 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. [>] [>] [>] + 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 - 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 Serafini Expires 14 June 2025 [Page 15] Internet-Draft VRRP and S-BFD December 2024 + endif // was priority 0? + endif // was advertisement received? endwhile // Secondary 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 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: [>] Serafini Expires 14 June 2025 [Page 16] Internet-Draft VRRP and S-BFD December 2024 [>] - Put in AdminDown the SBFDReflector session. [>] [>] - 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: + 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? Serafini Expires 14 June 2025 [Page 17] Internet-Draft VRRP and S-BFD December 2024 - 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 [>] + If S-BFD is required, then: [>] [>] - Turn in AdminDown the SBFDReflector session. [>] [>] + endif // is S-BFD required? - Transition to the {Secondary} state + else // new Primary Router logic - Discard the ADVERTISEMENT [>] + 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 immediately to assert Serafini Expires 14 June 2025 [Page 18] Internet-Draft VRRP and S-BFD December 2024 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 no 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, . [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . Serafini Expires 14 June 2025 [Page 19] Internet-Draft VRRP and S-BFD December 2024 [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 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/ Secondary 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. 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. Serafini Expires 14 June 2025 [Page 20] Internet-Draft VRRP and S-BFD December 2024 Contributors Contributions are welcome. Author's Address Nicola Serafini Individual Email: n.serafini@tutanota.com Serafini Expires 14 June 2025 [Page 21]