]> Individual

n.serafini@tutanota.com

Cisco Systems, Inc.

Sarjapur Outer Ring Road Bangalore 560103 India addogra@cisco.com http://www.cisco.com/

Routing Internet Engineering Task Force VRRP BFD S-BFD The Virtual Router Redundancy Protocol (VRRP) protocol depends on IPv4 or IPv6 connectivity between redundant peers and can use Seamless Bidirectional Forwarding Detection (S-BFD) to detect a Primary Router failure faster than the base VRRP advertisement timers. This document describes an extension that allows VRRP to use S-BFD as an additional failure-detection mechanism. It defines a new VRRP packet type, a dedicated timer, and a mechanism for a VRRP Primary Router to advertise an S-BFD reflector discriminator to Backup Routers. Local discriminator allocation is left to the implementation.

Introduction Bidirectional Forwarding Detection (BFD), defined in , is a protocol for rapid failure detection between a pair of systems. specifies its use for single-hop IPv4 and IPv6 sessions. Seamless BFD (S-BFD), defined in , reduces setup and negotiation overhead and enables simpler provisioning. extends S-BFD to IPv4, IPv6, and MPLS networks. VRRP is a standardized first-hop redundancy protocol for IPv4 and IPv6 networks. VRRP defined in provides a standard election procedure for selecting a Primary Router and interoperable behavior across implementations. In the base protocol, failure detection depends on advertisement processing and associated timers. This document combines S-BFD with VRRP for deployments that need failure detection in the millisecond or sub-second range without relying only on aggressive VRRP advertisement timers. Similar to the S-BFD discriminator advertisements defined for IS-IS in and OSPF in , the extension defined in this document allows a VRRP Primary Router to advertise an S-BFD reflector discriminator that Backup Routers can use to create SBFDInitiator sessions. The selection of local S-BFD discriminators remains implementation specific.

Terminology

VRRP

Virtual Router Redundancy Protocol

BFD

Bidirectional Forwarding Detection

S-BFD

Seamless Bidirectional Forwarding Detection

FHRP

First Hop Redundancy Protocol

SBFD_Handler

Handler in the Virtual Router that is triggered when an S-BFD Initiator session detects a failure.

SBFD_My_Discriminator

State variable maintained by the Virtual Router when S-BFD is used as a failure-detection mechanism. Its meaning depends on the current S-BFD operating mode.

SBFD_Your_Discriminator

State variable maintained by the Virtual Router when it uses S-BFD as an Initiator.

SBFD_Primary_Down_Timer

Timer in the Virtual Router that starts when S-BFD triggers the SBFD_Handler and is used by the election procedure defined in this document.

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 when, and only when, they appear in all capitals, as shown here.

Required Features This section lists the features that guided the design of this specification. There is no implied priority among them, and all of the features below MUST be supported by an implementation of this specification.

Timers for Primary election When enabled, this specification MUST allow S-BFD to accelerate failure detection independently of the normal VRRP advertisement timers.

Local S-BFD Discriminator allocation Every Router in a VRRP domain MUST be able to allocate a local S-BFD discriminator for use as an SBFDInitiator or SBFDReflector. The allocation method is implementation specific, but the selected value MUST satisfy the local uniqueness requirements of and .

Remote S-BFD Discriminator advertisement and learning A Router in VRRP Backup state MUST be able to learn the remote S-BFD discriminator for the VRRP Primary Router acting as an SBFDReflector from the VRRP packet type defined in this document.

S-BFD Discriminator length The locally allocated and remotely advertised S-BFD discriminator MUST be 32 bits long, as defined in .

Known Limitations Before S-BFD is used as a failure-detection mechanism with VRRP, the following limitation MUST be considered.

Inconsistency The implementation SHOULD raise an event when it detects an inconsistency between the VRRP state machine and the corresponding S-BFD operating mode.

Overview Each VRRP Router that uses S-BFD for failure detection MUST allocate a local S-BFD discriminator and MUST operate as an SBFDReflector or SBFDInitiator according to its VRRP state. When VRRP is in Primary state and the router wants other peers to monitor it, it MUST start an SBFDReflector session using the locally allocated discriminator and MUST advertise that discriminator by sending the VRRP packet type defined in this document. When VRRP is in Backup state, the router MUST start an SBFDInitiator session to monitor the Primary Router. To start a new session, the SBFDInitiator MUST learn the Primary Router's SBFDReflector discriminator and source IPvX address from the VRRP S-BFD Advertisement defined in this document. The SBFDInitiator MUST use a locally allocated discriminator as My Discriminator and the learned reflector discriminator as Your Discriminator, and it MUST monitor the learned source address. When the SBFDReflector receives a control packet from an SBFDInitiator, it MUST locate the corresponding SBFDReflector session by using the incoming Your Discriminator value. This document also defines how VRRP and S-BFD state changes interact, how the new handler and timer are used, and how the new packet type advertises the reflector discriminator needed by VRRP peers. This document does not define a deterministic algorithm for deriving S-BFD discriminators from VRRP fields. The following figure illustrates the high-level behavior.

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

VRRP state machine and S-BFD operational mode To facilitate interoperability between the two protocols, this document defines a direct relationship between the VRRP state machine and the S-BFD operating mode. When VRRP is in Primary state, the router MUST initialize an SBFDReflector session using the locally allocated discriminator. When VRRP is in Backup state, the router MUST initialize an SBFDInitiator session using a locally allocated discriminator as My Discriminator and the value advertised by the VRRP Primary Router as Your Discriminator. The destination of the Initiator session is the source IPvX address from which the corresponding VRRP S-BFD Advertisement was received. When VRRP is in Initialize state, no S-BFD session is associated with that Virtual Router instance, including its VRID, VRRP version, address family, and applicable interface, bridge-domain, or VRF context. An implementation that uses this specification is responsible for maintaining the relationship between VRRP and S-BFD. When an inconsistency is detected, it MUST be treated as a critical error.

VRRP and S-BFD state machines interoperability As defined in , S-BFD also has its own state machine. In SBFDInitiator mode, the relevant states are Up and Down. The Down state is entered when a timer expires or when an AdminDown indication is received from the remote Reflector session. In SBFDReflector mode, the session can indicate Up or AdminDown. When VRRP is in Primary state and S-BFD is operating as an SBFDReflector, VRRP MUST drive the associated S-BFD session behavior. When VRRP is in Backup state and S-BFD is operating as an Initiator, S-BFD MUST trigger the SBFD_Handler and VRRP MUST start and monitor the SBFD_Primary_Down_Timer. When VRRP is in Primary state and sends an advertisement with priority 0 in order to relinquish the role, it MUST continue to follow the base VRRP behavior. In that case, the election behavior remains the one defined by the corresponding VRRP version rather than the timer defined in this document. The implementation is responsible for defining how VRRP and S-BFD communicate state changes internally.

Relation maintenance The implementation is responsible for maintaining the relationship among the S-BFD session, the current VRID, the VRRP version, the address family, the applicable interface, bridge-domain, or VRF context, and the applicable S-BFD operating mode. When VRRP changes state, the implementation MUST destroy the old S-BFD session, initialize the new one as needed, and continue to apply the base VRRP state machine behavior. This relationship is maintained by using the two state variables SBFD_My_Discriminator and SBFD_Your_Discriminator. Their precise behavior depends on the current operating mode. When operating as an Initiator, the learned destination IPvX address of the SBFDReflector need not be retained after the S-BFD session has been initialized.

Relation requirements This section clarifies how the relationship and state variables are managed for each VRRP state. To create and maintain the association, VRRP MUST store the state variables in the Virtual Router instance and use them to identify, create, or destroy the corresponding S-BFD session.

Primary state

SBFD_My_Discriminator

SBFDReflector discriminator allocated by the implementation for the Virtual Router instance. This state variable MUST be initialized if the Primary Router wants peers to monitor it through S-BFD and MUST be used to start the corresponding SBFDReflector session as My Discriminator.

Backup state

SBFD_My_Discriminator

Required SBFDInitiator discriminator allocated by the implementation.

SBFD_Your_Discriminator

Required SBFDReflector discriminator learned from the VRRP S-BFD Advertisement for this VRRP instance.

Initialize state In this state, the implementation MUST NOT maintain a relationship, and any previous S-BFD sessions MUST be destroyed. VRRP might terminate abnormally and therefore be unable to notify S-BFD. The behavior for handling such inconsistencies is discussed in .

S-BFD Discriminator advertisement This specification does not define a deterministic algorithm for deriving S-BFD discriminators from the VRID, IP addresses, or other VRRP state. A Router that implements this specification MUST allocate SBFD_My_Discriminator according to local implementation policy and MUST ensure that the selected value is a valid non-zero 32-bit S-BFD discriminator that satisfies the local uniqueness requirements of and . Similar to the S-BFD discriminator advertisements defined for IS-IS in and OSPF in , the VRRP packet type defined in this document explicitly carries the SBFDReflector discriminator selected by the VRRP Primary Router.

Advertisement field A VRRP S-BFD Advertisement reuses the advertisement format of the applicable VRRP version and appends a 32-bit S-BFD Reflector Discriminator field after the protected IPvX address list. All other fields are identical to the corresponding VRRP Advertisement and are processed according to .

VRRP S-BFD Advertisement Extension

The checksum processing for the corresponding VRRP version MUST cover the S-BFD Reflector Discriminator field.

Learning the SBFDInitiator Your Discriminator field When a Backup Router receives a VRRP S-BFD Advertisement, it MUST copy the advertised S-BFD Reflector Discriminator value into SBFD_Your_Discriminator and use that value as the S-BFD Your Discriminator, as defined in Section 7.2 of .

Implementation considerations The same VRID can be reused on different interfaces or bridge domains, and overlapping IPv4 or IPv6 addresses can exist in different VRF contexts. Therefore, deriving S-BFD discriminators only from the VRID and IP addressing information is not sufficient to guarantee uniqueness across VRRP deployments. Explicit advertisement avoids this ambiguity and leaves local discriminator allocation to the implementation.

Why explicit advertisement is required A point-to-multipoint BFD solution, such as one based on , can make a different design choice because the Primary Router itself originates BFD Control packets and a Backup Router can demultiplex the received session by using the source IPvX address together with locally defined rules. S-BFD has a different operational model. An SBFDInitiator MUST know the discriminator allocated by the remote SBFDReflector before it can send an S-BFD Control packet with the correct Your Discriminator value, as described in . Because the same VRID can be reused in different interface, bridge-domain, or VRF contexts, and because overlapping IP addressing is possible, this document does not attempt to infer the remote reflector discriminator from VRRP state alone. For that reason, this specification carries the SBFDReflector discriminator explicitly in the VRRP S-BFD Advertisement. A specification that uses point-to-multipoint BFD instead of S-BFD could avoid that advertisement, but it would define a different failure-detection mechanism.

Timers The standard VRRP election procedure uses the advertisement interval as part of its failure-detection behavior and cannot directly provide the behavior required by this specification. To avoid collisions between the two mechanisms, a dedicated timer named SBFD_Primary_Down_Timer MUST be implemented in the VRRP Router. This timer MUST be equal to the Skew_Time for the applicable VRRP version and MUST be started only when an S-BFD Initiator session triggers the VRRP SBFD_Handler because of a Down or AdminDown indication from the Reflector.

Operational requirements This section defines the operational requirements of this specification and summarizes how VRRP and S-BFD are integrated. For IPv6 procedures, the Solicited-Node multicast address is the one defined in .

Initialize state > + If S-BFD is required, then: >> >> - Allocate the SBFD_My_Discriminator according to local >> implementation policy. >> >> - Start a new SBFDReflector session with >> SBFD_My_Discriminator as My Discriminator. >> >> - Set the VRRP packet type to 2 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + 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 - 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 ]]>

VRRP Backup state > + 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: >> >> - 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: >> >> - Allocate the SBFD_My_Discriminator according to local >> implementation policy. >> >> - Start a new SBFDReflector session with >> SBFD_My_Discriminator as My Discriminator. >> >> - Set the VRRP packet type to 2 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + 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 defined in 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. >> >> + 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: >> >> - Allocate the SBFD_My_Discriminator according to local >> implementation policy. >> >> - Set the SBFD_Your_Discriminator to the >> S-BFD Reflector Discriminator field carried in the >> ADVERTISEMENT. >> >> - Create or update the 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 - 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 ]]>

Primary state > + If S-BFD is required, then: >> >> - Set the VRRP packet type to 2 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + 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 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + 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 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + 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 >> >> - Include SBFD_My_Discriminator as the >> S-BFD Reflector Discriminator field >> >> + else >> >> - 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 ]]>

IANA Considerations This document requests IANA to assign a new VRRP packet type for use with S-BFD-enabled VRRP advertisements. The requested value is 2, with a description of "S-BFD Advertisement". If IANA assigns a different value, implementations of this specification MUST use the IANA-assigned value.

Security Considerations This document does not define a new security mechanism. It specifies how VRRP can use S-BFD to accelerate failure detection. Implementations inherit the security considerations of , , , , and . A false or spoofed S-BFD Advertisement can inject an incorrect reflector discriminator or misdirect monitoring traffic, and a false failure indication can still trigger unnecessary VRRP state transitions. For that reason, operators should apply the same filtering, integrity, and control plane protections recommended for the base protocols.

References Normative References RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It obsoletes RFC 5798, which previously specified VRRP (version 3). RFC 5798 obsoleted RFC 3768, which specified VRRP (version 2) for IPv4. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets routed to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK] This document defines Seamless Bidirectional Forwarding Detection (S-BFD), 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. This document updates RFC 5880. This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments. Informative References

Prior Work This document was inspired by earlier work on VRRP and BFD, including draft-ietf-rtgwg-vrrp-bfd-p2p-xx and draft-ietf-rtgwg-vrrp-p2mp-bfd-xx.

Tools This document uses templates written by Pekka Savola, Elwyn Davies, and Henrik Levkowetz and relies on the open source xml2rfc project.

Acknowledgements Thanks to the authors of the VRRP specifications for their work on the Primary and Backup election procedure. Thanks to the authors of the BFD specifications for their work on rapid failure detection. Thanks to the authors of the S-BFD specifications for their work on a streamlined BFD mode that can be applied to VRRP. Thanks to G. Mirsky, J. Tantsura, G. Mishra, N. Gupta, A. Dogra, and C. Docherty for their earlier work on VRRP and BFD. Thanks to the open source maintainers of VRRP and BFD implementations for their efforts.

Contributors Contributions are welcome.