idnits 2.17.00 (12 Aug 2021) /tmp/idnits16533/draft-nitish-vrrp-bfd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2016) is 2103 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4291' is mentioned on line 919, but not defined == Outdated reference: draft-ietf-bfd-multipoint has been published as RFC 8562 ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Gupta 3 Internet-Draft A. Dogra 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 11, 2017 C. Docherty 7 G. Mirsky 8 Ericsson 9 J. Tantsura 10 Individual 11 August 10, 2016 13 Fast failure detection in VRRP with BFD 14 draft-nitish-vrrp-bfd-04 16 Abstract 18 This document describes how Bidirectional Forwarding Detection (BFD) 19 can be used to support sub-second detection of a Master Router 20 failure in the Virtual Router Redundancy Protocol (VRRP). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 11, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Applicability of Single-hop BFD . . . . . . . . . . . . . . . 3 59 3.1. Extension to VRRP protocol . . . . . . . . . . . . . . . 4 60 3.2. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 5 62 3.4. Sample configuration . . . . . . . . . . . . . . . . . . 5 63 3.5. Critical BFD session . . . . . . . . . . . . . . . . . . 7 64 3.6. Protocol State Machine . . . . . . . . . . . . . . . . . 7 65 3.6.1. Parameters Per Virtual Router . . . . . . . . . . . . 7 66 3.6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.6.3. VRRP State Machine with BFD . . . . . . . . . . . . . 8 68 4. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 17 69 4.1. VRRP State Machine with p2mp BFD . . . . . . . . . . . . 18 70 4.1.1. Initialize . . . . . . . . . . . . . . . . . . . . . 18 71 4.1.2. Backup . . . . . . . . . . . . . . . . . . . . . . . 19 72 4.1.3. Master . . . . . . . . . . . . . . . . . . . . . . . 22 73 5. Scalability Considerations . . . . . . . . . . . . . . . . . 24 74 6. Operational Considerations . . . . . . . . . . . . . . . . . 24 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 76 7.1. A New Name Space for VRRP Packet Types . . . . . . . . . 25 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 79 10. Normative References . . . . . . . . . . . . . . . . . . . . 25 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 82 1. Introduction 84 The Virtual Router Redundancy Protocol (VRRP) provides redundant 85 Virtual gateways in the Local Area Network (LAN), which is typically 86 the first point of failure for end-hosts sending traffic out of the 87 LAN. Fast failure detection of VRRP Master is critical in supporting 88 high availability of services and improved Quality of Experience to 89 users. In VRRP [RFC5798] specification, Backup routers depend on 90 VRRP packets generated at a regular interval by the Master router, to 91 detect the health of the VRRP Master. Faster failure detection can 92 be achieved within VRRP protocol by reducing the Advertisement 93 Interval and hold down timers. However, aggressive timers can put 94 extra load on CPU and the network bandwidth which may not be 95 desirable. 97 Since the VRRP protocol depends on the availability of Layer 3 IPv4 98 or IPv6 connectivity between redundant peers, the VRRP protocol can 99 interact with the Layer 3 variant of BFD as described in [RFC5881] 100 or [I-D.draft-ietf-bfd-multipoint] to achieve a much faster failure 101 detection of the VRRP Master on the LAN. BFD, as specified by the 102 [RFC5880] or [I-D.draft-ietf-bfd-multipoint] can provide a much 103 faster failure detection in the range of 150ms, if implemented in the 104 part of a Network device which scales better than VRRP when 105 aggressive timers are used. 107 2. Requirements Language 109 In this document, several words are used to signify the requirements 110 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 111 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 112 and "OPTIONAL" in this document are to be interpreted as described in 113 RFC 2119. [RFC2119] 115 3. Applicability of Single-hop BFD 117 BFD for IPv4 or IPv6 (Single Hop) [RFC5881] requires that in order 118 for a BFD session to be formed both peers participating in a BFD 119 session need to know its peer IPv4 or IPV6 address. This poses a 120 unique problem with the definition of the VRRP protocol, that makes 121 the use of BFD for IPv4 or IPv6 [RFC5881] more challenging. In VRRP 122 it is only the Master router that sends Advert packets. This means 123 that a Master router is not aware of any Backup routers, and Backup 124 routers are only aware of the Master router. This also means that a 125 Backup router is not aware of any other Backup routers in the 126 Network. 128 Since BFD for IPv4 or IPv6 [RFC5881] requires that a session be 129 formed by both peers using a full destination and source address, 130 there needs to be some external means to provide this information to 131 BFD on behalf of VRRP. Once the peer information is made available, 132 VRRP can form BFD sessions with its peer Virtual Router. The BFD 133 session for a given Virtual Router is identified as the Critical Path 134 BFD Session, which is the session that forms between the current VRRP 135 Master router, and the highest priority Backup router. When the 136 Critical Path BFD Session identified by VRRP as having changed state 137 from Up to Down, then this will be interpreted by the VRRP state 138 machine on the highest priority Backup router as a Master Down event. 139 A Master Down event means that the highest priority Backup peer will 140 immediately become the new Master for the Virtual Router. 142 NOTE: At all times, the normal fail-over mechanism defined in the 143 VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism 144 will always resort to normal VRRP fail-over. 146 This draft defines the mechanism used by the VRRP protocol to build a 147 peer table that will help in forming of BFD session and the detection 148 of Critical Path BFD session. If the Critical Path BFD session were 149 to go down, it will signal a Master Down event and make the most 150 preferred Backup router as the VRRP Master router. This requires an 151 extension to the VRRP protocol. 153 This can be achieved by defining a new type in the VRRP Advert 154 packet, and allowing VRRP peers to build a peer table in any of the 155 operational state, Master or Backup. 157 3.1. Extension to VRRP protocol 159 In this mode of operation VRRP peers learn the adjacent routers, and 160 form BFD session between the learnt routers. In order to build the 161 peer table, all routers send VRRP Advert packets whilst in any of the 162 operational states (Master or Backup). Normally VRRP peers only send 163 Advert packets whilst in the Master state, however in this mode VRRP 164 Backup peers will also send Advert packets with the type field set to 165 BACKUP ADVERTISEMENT type defined in Section 3.3 of this document. 166 The VRRP Master router will still continue to send packets with the 167 Advert type as ADVERTISEMENT as defined in the VRRP protocol. This 168 is to maintain inter-operability with peers complying to VRRP 169 protocol. 171 Additionally, Advert packets sent from Backup Peers must not use the 172 Virtual router MAC address as the source address. Instead it must 173 use the Interface MAC address as the source address from which the 174 packet is sent from. This is because the source MAC override feature 175 is used by the Master to send Advert packets from the Virtual Router 176 MAC address, which is used to keep the bridging cache on LAN switches 177 and bridging devices refreshed with the destination port for the 178 Virtual Router MAC. 180 3.2. VRRP Peer Table 182 VRRP peers can now form the peer table by learning the source address 183 in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP 184 Master or Backup peers. This allows peers to create BFD sessions 185 with other operational peers. 187 A peer entry should be removed from the peer table if Advert is not 188 received from a peer for a period of (3 * the Advert interval). 190 3.3. VRRP BACKUP ADVERTISEMENT Packet Type 192 The following figure shows the VRRP packet as defined in VRRP 193 [RFC5798] RFC. 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | IPv4 Fields or IPv6 Fields | 199 ... ... 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |(rsvd) | Max Advert Int | Checksum | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 + + 208 | IPvX Address(es) | 209 + + 210 + + 211 + + 212 + + 213 | | 214 + + 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 The type field specifies the type of this VRRP packet. The type 219 field can have two values. Type 1 (ADVERTISEMENT) is used by the 220 VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the 221 VRRP Backup router. This is to distinguish the packets sent by the 222 VRRP backup Router. VRRP Backup fills Backup_Advertisement_Interval 223 in the Max Advert Int of BACKUP ADVERTISEMENT packet. Rest of the 224 fields in Advert packet remain the same. 226 1 ADVERTISEMENT 227 2 BACKUP ADVERTISEMENT 229 A packet with unknown type MUST be discarded. 231 3.4. Sample configuration 232 The following figure shows a simple network with three VRRP routers 233 implementing one virtual router. 235 +-----------+ +-----------+ +-----------+ 236 | Rtr1 | | Rtr2 | | Rtr3 | 237 |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| 238 | (PR=200) | | (PR=150) | | (PR=100) | 239 | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | 240 +-----------+ +-----------+ +-----------+ 241 B C D 242 | | | 243 | | | 244 | | | 245 ---------+--------+--------+---------+--------+--------- 246 Legend: 247 ---+---+---+-- = Ethernet, Token Ring, or FDDI 248 MR = Master Router 249 BR = Backup Router 250 PR = VRRP Router priority 251 VRID = VRRP Router ID 252 VRIPVX= IPv4 or IPv6 address protected by 253 the VRRP Router 254 B,C,D = Interface IPv4 or IPv6 address of 255 the Virtual Router 257 In the above configuration there are three routers on the LAN 258 protecting an IPv4 or IPv6 address associated to a Virtual Router ID 259 1. Rtr1 is the Master router since it has the highest priority 260 compared to Rtr2 and Rtr3. Now if peer learning extension is enabled 261 on all the peers. Rtr1 will send the Advert packet with type field 262 set to 1. While Rtr2 and Rtr3 will send the Advert packet with type 263 field set to 2. In the above configuration the peer table built at 264 each router is shown below: 266 Rtr1 Peer table 268 +------------------------------------+ 269 | Peer Address | Priority | 270 +------------------------------------+ 271 | C | 150 | 272 +------------------------------------+ 273 | D | 100 | 274 +------------------------------------+ 275 Rtr2 Peer table 277 +------------------------------------+ 278 | Peer Address | Priority | 279 +------------------------------------+ 280 | B | 200 | 281 +------------------------------------+ 282 | D | 100 | 283 +------------------------------------+ 285 Rtr3 Peer table 287 +------------------------------------+ 288 | Peer Address | Priority | 289 +------------------------------------+ 290 | B | 200 | 291 +------------------------------------+ 292 | C | 150 | 293 +------------------------------------+ 295 Once the peer tables are formed, VRRP on each router can form a BFD 296 sessions with the learnt peers. 298 3.5. Critical BFD session 300 The Critical BFD Session is determined to be the session between the 301 VRRP Master and the next best VRRP Backup. Failure of the Critical 302 BFD session indicates that the Master is no longer available and the 303 most preferred Backup will now become Master. 305 In the above example the Critical BFD session is shared between Rtr1 306 and Rtr2. If the BFD Session goes from Up to Down state, Rtr2 can 307 treat it as a Master down event and immediately assume the role of 308 VRRP Master router for VRID 1 and Rtr3 will become the critical 309 Backup. If the priorities of two Backup routers are same then the 310 primary IPvX Address of the sender is used to determine the highest 311 priority Backup. Where higher IPvX address has higher priority. 313 3.6. Protocol State Machine 315 3.6.1. Parameters Per Virtual Router 317 Following parameters are added to the VRRP protocol to support this 318 mode of operation. 320 Backup_Advertisement_Interval Time interval between 321 BACKUP ADVERTISEMENTS 322 (centiseconds). Default is 100 323 centiseconds (1 second). 325 Backup_Adver_Interval Advertisement interval contained in 326 BACKUP ADVERTISEMENTS received from 327 the Backup (centiseconds). This 328 value is saved by virtual routers 329 used, to compute Backup_Down_Interval. 331 Backup_Down_Interval Time interval for VRRP instance 332 to declare Backup down 333 (centiseconds). Calculated as 334 (3 * Backup_Adver_Interval) for 335 each VRRP Backup. 337 Critical_Backup Procedure outlined in section 3.4 338 of this document is used to 339 determine the Critical_Backup at 340 each VRRP Instance. 342 Critical_BFD_Session The Critical BFD Session is 343 the session between 344 the VRRP Master and Critical_Backup. 346 3.6.2. Timers 348 Following timers are added to the VRRP protocol to support this mode 349 of operation. 351 Backup_Down_Timer Timer that fires when BACKUP ADVERTISEMENT 352 has not been heard from a backup peer for 353 Backup_Down_Interval. 355 Backup_Adver_Timer Timer that fires to trigger sending of 356 BACKUP ADVERTISEMENT based on 357 Backup_Advertisement_Interval. 359 3.6.3. VRRP State Machine with BFD 361 Following State Machine replaces the state Machine outlined in 362 section 6.4 of the VRRP protocol [RFC5798] to support this mode of 363 operation. Please refer to the section 6.4 of [RFC5798] for State 364 description. 366 3.6.3.1. Initialize 368 Following state machine replaces the state machine outlined in 369 section 6.4.1 of [RFC5798] 371 (100) If a Startup event is received, then: 373 (105) - If the Priority = 255 (i.e., the router owns the IPvX 374 address associated with the virtual router), then: 376 (110) + Send an ADVERTISEMENT 378 (115) + If the protected IPvX address is an IPv4 address, then: 380 (120) * Broadcast a gratuitous ARP request containing the 381 virtual router MAC address for each IP address associated 382 with the virtual router. 384 (125) + else // IPv6 386 (130) * For each IPv6 address associated with the virtual 387 router, send an unsolicited ND Neighbor Advertisement with 388 the Router Flag (R) set, the Solicited Flag (S) unset, the 389 Override flag (O) set, the target address set to the IPv6 390 address of the virtual router, and the target link-layer 391 address set to the virtual router MAC address. 393 (135) +endif // was protected addr IPv4? 395 (140) + Set the Adver_Timer to Advertisement_Interval 397 (145) + Transition to the {Master} state 399 (150) - else // rtr does not own virt addr 401 (155) + Set Master_Adver_Interval to Advertisement_Interval 403 (160) + Set the Master_Down_Timer to Master_Down_Interval 405 (165) + Set Backup_Adver_Timer to Backup_Advertisement_Interval 407 (170) + Transition to the {Backup} state 409 (175) -endif // priority was not 255 411 (180) endif // startup event was recv 413 3.6.3.2. Backup 415 Following state machine replaces the state machine outlined in 416 section 6.4.2 of [RFC5798] 418 (300) While in this state, a VRRP router MUST do the following: 420 (305) - If the protected IPvX address is an IPv4 address, then: 422 (310) + MUST NOT respond to ARP requests for the IPv4 423 address(es) associated with the virtual router. 425 (315) - else // protected addr is IPv6 427 (320) + MUST NOT respond to ND Neighbor Solicitation messages 428 for the IPv6 address(es) associated with the virtual router. 430 (325) + MUST NOT send ND Router Advertisement messages for the 431 virtual router. 433 (330) -endif // was protected addr IPv4? 435 (335) - MUST discard packets with a destination link-layer MAC 436 address equal to the virtual router MAC address. 438 (340) - MUST NOT accept packets addressed to the 439 IPvX address(es) associated with the virtual router. 441 (345) - If a Shutdown event is received, then: 443 (350) + Cancel the Master_Down_Timer. 445 (355) + Cancel the Backup_Adver_Timer. 447 (360) + Cancel Backup_Down_Timers. 449 (365) + Remove Peer table. 451 (370) + If Critical_BFD_Session Exists: 453 (375) * Tear down the Critical_BFD_Session. 455 (380) + endif // Critical_BFD_Session Exists? 457 (385) + Send a BACKUP ADVERTISEMENT with Priority = 0. 459 (390) + Transition to the {Initialize} state. 461 (395) -endif // shutdown recv 463 (400) - If the Master_Down_Timer fires or 464 If Critical_BFD_Session transitions from UP to DOWN, then: 466 (405) + Send an ADVERTISEMENT 468 (415) + If the protected IPvX address is an IPv4 address, then: 470 (420) * Broadcast a gratuitous ARP request on that interface 471 containing the virtual router MAC address for each IPv4 472 address associated with the virtual router. 474 (425) + else // ipv6 476 (430) * Compute and join the Solicited-Node multicast 477 address [RFC4291] for the IPv6 address(es) associated with 478 the virtual router. 480 (435) * For each IPv6 address associated with the virtual 481 router, send an unsolicited ND Neighbor Advertisement with 482 the Router Flag (R) set, the Solicited Flag (S) unset, the 483 Override flag (O) set, the target address set to the IPv6 484 address of the virtual router, and the target link-layer 485 address set to the virtual router MAC address. 487 (440) +endif // was protected addr ipv4? 489 (445) + Set the Adver_Timer to Advertisement_Interval. 491 (450) + If the Critical_BFD_Session exists: 493 (455) @ Tear Critical_BFD_Session. 495 (460) + endif // Critical_BFD_Session exists 497 (465) + Calculate the Critical_Backup. 499 (470) + If the Critical_Backup exists: 501 (475) * BootStrap Critical_BFD_Session with the 502 Critical_Backup. 504 (480) + endif //Critical_Backup exists? 506 (485) + Transition to the {Master} state. 508 (490) -endif // Master_Down_Timer fired 509 (485) - If an ADVERTISEMENT is received, then: 511 (490) + If the Priority in the ADVERTISEMENT is zero, then: 513 (495) * Set the Master_Down_Timer to Skew_Time. 515 (500) * If the Critical_BFD_Session exists: 517 (505) * Tear Critical_BFD_Session with the Master. 519 (510) * endIf // Critical_BFD_Session exists 521 (515) + else // priority non-zero 523 (520) * If Preempt_Mode is False, or if the Priority in the 524 ADVERTISEMENT is greater than or equal to the local 525 Priority, then: 527 (525) @ Set Master_Adver_Interval to Adver Interval 528 contained in the ADVERTISEMENT. 530 (530) @ Recompute the Master_Down_Interval. 532 (535) @ Reset the Master_Down_Timer to 533 Master_Down_Interval. 535 (540) @ Determine Critical_Backup. 537 (545) @ If Critical_BFD_Session does not exists and this 538 instance is the Critical_Backup: 540 (550) @+ BootStrap Critical_BFD_Session with Master. 542 (555) @ endif //Critical_BFD_Session exists check 544 (560) * else // preempt was true or priority was less 546 (565) @ Discard the ADVERTISEMENT. 548 (570) *endif // preempt test 550 (575) +endif // was priority zero? 552 (580) -endif // was advertisement recv? 554 (585) - If a BACKUP ADVERTISEMENT is received, then: 556 (590) + If the Priority in the BACKUP ADVERTISEMENT is zero, 557 then: 559 (595) * Cancel Backup_Down_Timer. 561 (600) * Remove the Peer from Peer table. 563 (605) + else // priority non-zero 565 (610) * Update the peer table with peer information. 567 (615) * Set Backup_Adver_Interval to Adver Interval 568 contained in the BACKUP ADVERTISEMENT. 570 (620) * Recompute the Backup_Down_Interval. 572 (625) * Reset the Backup_Down_Timer to Backup_Down_Interval. 574 (630) +endif // was priority zero? 576 (635) + Recalculate Critical_Backup. 578 (640) + If Critical_BFD_Session exists and this 579 instance is not the Critical_Backup: 581 (645) * Tear Down the Critical_BFD_Session. 583 (650) + else If Critical_BFD_Session doesnot exists and this 584 instance is the Critical_Backup: 586 (655) * BootStrap Critical_BFD_Session with Master. 588 (660) + endif // Critical_Backup change 590 (665) -endif // was backup advertisement recv? 592 (670) - If Backup_Down_Timer fires, then: 594 (675) + Remove the Peer from Peer table. 596 (680) + If Critical_BFD_Session does not exist: 598 (685) @ Recalculate Critical_Backup. 600 (690) @ If This instance is the Critical_Backup: 602 (695) +@ BootStrap Critical_BFD_Session with Master. 604 (700) @ endif // Critical_Backup change 606 (705) + endif // Critical_BFD_Session does not exist? 608 (710) -endif // Backup_Down_Timer fires? 610 (715) - If Backup_Adver_Timer fires, then: 612 (720) + Send a BACKUP ADVERTISEMENT. 614 (725) + Reset the Backup_Adver_Timer to 615 Backup_Advertisement_Interval. 617 (730) -endif // Backup_Down_Timer fires? 619 (735) endwhile // Backup state 621 3.6.3.3. Master 623 Following state machine replaces the state machine outlined in 624 section 6.4.3 of [RFC5798] 626 (800) While in this state, a VRRP router MUST do the following: 628 (805) - If the protected IPvX address is an IPv4 address, then: 630 (810) + MUST respond to ARP requests for the IPv4 address(es) 631 associated with the virtual router. 633 (815) - else // ipv6 635 (820) + MUST be a member of the Solicited-Node multicast 636 address for the IPv6 address(es) associated with the virtual 637 router. 639 (825) + MUST respond to ND Neighbor Solicitation message for 640 the IPv6 address(es) associated with the virtual router. 642 (830) + MUST send ND Router Advertisements for the virtual 643 router. 645 (835) + If Accept_Mode is False: MUST NOT drop IPv6 646 Neighbor Solicitations and Neighbor Advertisements. 648 (840) -endif // ipv4? 650 (845) - MUST forward packets with a destination link-layer MAC 651 address equal to the virtual router MAC address. 653 (850) - MUST accept packets addressed to the IPvX address(es) 654 associated with the virtual router if it is the IPvX address 655 owner or if Accept_Mode is True. Otherwise, MUST NOT accept 656 these packets. 658 (855) - If a Shutdown event is received, then: 660 (860) + Cancel the Adver_Timer. 662 (865) + Send an ADVERTISEMENT with Priority = 0, 664 (870) + Cancel Backup_Down_Timers. 666 (875) + Remove Peer table. 668 (880) + If Critical_BFD_Session Exists: 670 (885) * Tear down Critical_BFD_Session 672 (890) + endif // If Critical_BFD_Session Exists 674 (895) + Transition to the {Initialize} state. 676 (900) -endif // shutdown recv 678 (905) - If the Adver_Timer fires, then: 680 (910) + Send an ADVERTISEMENT. 682 (915) + Reset the Adver_Timer to Advertisement_Interval. 684 (920) -endif // advertisement timer fired 686 (925) - If an ADVERTISEMENT is received, then: 688 (930) -+ If the Priority in the ADVERTISEMENT is zero, then: 690 (935) -* Send an ADVERTISEMENT. 692 (940) -* Reset the Adver_Timer to Advertisement_Interval. 694 (945) -+ else // priority was non-zero 696 (950) -* If the Priority in the ADVERTISEMENT is greater 697 than the local Priority, 699 (955) -* or 700 (960) -* If the Priority in the ADVERTISEMENT is equal to 701 the local Priority and the primary IPvX Address of the 702 sender is greater than the local primary IPvX Address, then: 704 (965) -@ Cancel Adver_Timer 706 (970) -@ Set Master_Adver_Interval to Adver Interval 707 contained in the ADVERTISEMENT 709 (975) -@ Recompute the Skew_Time 711 (980) @ Recompute the Master_Down_Interval 713 (985) @ Set Master_Down_Timer to Master_Down_Interval 715 (990) If Critical_BFD_Session Exists: 717 (995) @+ Tear Critical_BFD_Session 719 (960) @ endif //Critical_BFD_Session Exists? 721 (965) @ Calculate Critical_Backup. 723 (970) @ If this instance is Critical_Backup: 725 (975) @+ BootStrap Critical_BFD_Session with new 726 Master. 728 (980) @ endif // am i Critical_Backup? 730 (985) @ Transition to the {Backup} state 732 (990) * else // new Master logic 734 (995) @ Discard ADVERTISEMENT 736 (1000) *endif // new Master detected 738 (1005) +endif // was priority zero? 740 (1010) -endif // advert recv 742 (1015) - If a BACKUP ADVERTISEMENT is received, then: 744 (1020) + If the Priority in the BACKUP ADVERTISEMENT is 745 zero, then: 747 (1025) * Remove the Peer from peer table. 749 (1030) + else: // priority non-zero 751 (1035) * Update the Peer info in peer table. 753 (1040) * Recompute the Backup_Down_Interval 755 (1045) * Reset the Backup_Down_Timer to 756 Backup_Down_Interval 758 (1050) + endif // priority in backup advert zero 760 (1055) + Calculate the Critical_Backup 762 (1060) + If Critical_BFD_Session doesnot exist: 764 (1065) * BootStrap Critical_BFD_Session 766 (1070) + else if Critical_BFD_Session exist and 767 Critical_Backup changes: 769 (1075) + Tear Critical_BFD_Session with old Backup 771 (1080) + BootStrap Critical_BFD_Session with Critical_Backup 773 (1085) + endif // Critical_BFD_Session check? 775 (1090) - endif // backup advert recv 777 (1095) - If Critical_BFD_Session transitions from UP to DOWN, 778 then: 779 (1100) + Cancel Backup_Down_Timer 781 (1105) + Delete the Peer info from peer table 783 (1200) + Calculate the Critical_Backup 785 (1205) + BootStrap Critical_BFD_Session with Critical_Backup 787 (1210) - endif // BFD session transition 789 (1215) endwhile // in Master 791 4. Applicability of p2mp BFD 793 [I-D.draft-ietf-bfd-multipoint] describes extensions to the BFD 794 protocol for its use in multipoint and multicast networks. With 795 these extensions p2mp BFD can support sub-second failure detection of 796 the root by tail nodes. In fact, a redundancy group may be viewed as 797 p2mp BFD session with its Master being the root and Backup routers 798 being tail nodes. Once Master selection process is completed, the 799 Master router starts transmitting BFD control packets with IPvX 800 address associated with the VRID as source IPvX address. Backup 801 router demultiplexes p2mp BFD tail sessions based on IPvX source 802 address associated with the virtual router that it been configured 803 with. Once Backup router accepts p2mp session from the new Master 804 router, the Backup router MAY use My Discriminator from received p2mp 805 BFD control packet to demultiplex p2mp BFD sessions. When a Backup 806 router detects failure of the Master router it re-evaluates its role 807 in the VRID. As result, the Backup router may become the Master 808 router of the given VRID or continue as a Backup router. If the 809 former is the case, then the new Master router MUST select My 810 Discriminator and start transmitting p2mp BFD control packets using 811 Master IPvX address as source IPvX address for p2mp BFD control 812 packets. If the latter is the case, then the Backup router MUST wait 813 for p2mp BFD control packet with source IPvX address set to IPvX 814 address associated with the VRID. 816 4.1. VRRP State Machine with p2mp BFD 818 Following section outlines the interaction between VRRP protocol 819 [RFC5798] state machine and p2mp BFD. Please refer to the section 820 6.4 of [RFC5798] for State description. 822 4.1.1. Initialize 824 Following state machine replaces the state machine outlined in 825 section 6.4.1 of [RFC5798] 826 (100) If a Startup event is received, then: 828 (105) - If the Priority = 255 (i.e., the router owns the IPvX 829 address associated with the virtual router), then: 831 (110) + Send an ADVERTISEMENT 833 (115) + If the protected IPvX address is an IPv4 address, then: 835 (120) * Broadcast a gratuitous ARP request containing the 836 virtual router MAC address for each IP address associated 837 with the virtual router. 839 (125) + else // IPv6 841 (130) * For each IPv6 address associated with the virtual 842 router, send an unsolicited ND Neighbor Advertisement with 843 the Router Flag (R) set, the Solicited Flag (S) unset, the 844 Override flag (O) set, the target address set to the IPv6 845 address of the virtual router, and the target link-layer 846 address set to the virtual router MAC address. 848 (135) +endif // was protected addr IPv4? 850 (140) + Set the Adver_Timer to Advertisement_Interval 852 (145) + Transition to the {Master} state 854 (150) - else // rtr does not own virt addr 856 (155) + Set Master_Adver_Interval to Advertisement_Interval 858 (160) + Set the Master_Down_Timer to Master_Down_Interval 860 (165) + BootStrap BFD MultipointTail Session 862 (170) + Transition to the {Backup} state 864 (175) -endif // priority was not 255 866 (180) endif // startup event was recv 868 4.1.2. Backup 870 Following state machine replaces the state machine outlined in 871 section 6.4.2 of [RFC5798] 873 (300) While in this state, a VRRP router MUST do the following: 875 (305) - If the protected IPvX address is an IPv4 address, then: 877 (310) + MUST NOT respond to ARP requests for the IPv4 878 address(es) associated with the virtual router. 880 (315) - else // protected addr is IPv6 882 (320) + MUST NOT respond to ND Neighbor Solicitation messages 883 for the IPv6 address(es) associated with the virtual router. 885 (325) + MUST NOT send ND Router Advertisement messages for the 886 virtual router. 888 (330) -endif // was protected addr IPv4? 890 (335) - MUST discard packets with a destination link-layer MAC 891 address equal to the virtual router MAC address. 893 (340) - MUST NOT accept packets addressed to the IPvX address(es) 894 associated with the virtual router. 896 (345) - If a Shutdown event is received, then: 898 (350) + Cancel the Master_Down_Timer 900 (355) + Transition to the {Initialize} state 902 (360) -endif // shutdown recv 904 (365) - If the Master_Down_Timer fires or 905 BFD MultipointTail session transitions from UP to DOWN, 906 then: 908 (370) + Send an ADVERTISEMENT 910 (375) + If the protected IPvX address is an IPv4 address, then: 912 (380) * Broadcast a gratuitous ARP request on that interface 913 containing the virtual router MAC address for each IPv4 914 address associated with the virtual router. 916 (385) + else // ipv6 918 (390) * Compute and join the Solicited-Node multicast 919 address [RFC4291] for the IPv6 address(es) associated with 920 the virtual router. 922 (395) * For each IPv6 address associated with the virtual 923 router, send an unsolicited ND Neighbor Advertisement with 924 the Router Flag (R) set, the Solicited Flag (S) unset, the 925 Override flag (O) set, the target address set to the IPv6 926 address of the virtual router, and the target link-layer 927 address set to the virtual router MAC address. 929 (400) +endif // was protected addr ipv4? 931 (405) + Set the Adver_Timer to Advertisement_Interval 933 (410) + Tear down BFD MultipointTail Session 935 (415) + BootStrap BFD MultipointHead Session 937 (420) + Transition to the {Master} state 939 (425) -endif // Master_Down_Timer fired 941 (430) - If an ADVERTISEMENT is received, then: 943 (435) + If the Priority in the ADVERTISEMENT is zero, then: 945 (440) * Set the Master_Down_Timer to Skew_Time 947 (445) + else // priority non-zero 949 (450) * If Preempt_Mode is False, or if the Priority in the 950 ADVERTISEMENT is greater than or equal to the local 951 Priority, then: 953 (455) @ Set Master_Adver_Interval to Adver Interval 954 contained in the ADVERTISEMENT 956 (460) @ Recompute the Master_Down_Interval 958 (465) @ Reset the Master_Down_Timer to 959 Master_Down_Interval 961 (470) * else // preempt was true or priority was less 963 (475) @ Discard the ADVERTISEMENT 965 (480) *endif // preempt test 967 (485) +endif // was priority zero? 969 (490) -endif // was advertisement recv? 971 (495) endwhile // Backup state 973 4.1.3. Master 975 Following state machine replaces the state machine outlined in 976 section 6.4.3 of [RFC5798] 978 (600) While in this state, a VRRP router MUST do the following: 979 (605) - If the protected IPvX address is an IPv4 address, then: 981 (610) + MUST respond to ARP requests for the IPv4 address(es) 982 associated with the virtual router. 984 (615) - else // ipv6 986 (620) + MUST be a member of the Solicited-Node multicast 987 address for the IPv6 address(es) associated with the virtual 988 router. 990 (625) + MUST respond to ND Neighbor Solicitation message for 991 the IPv6 address(es) associated with the virtual router. 993 (630) ++ MUST send ND Router Advertisements for the virtual 994 router. 996 (635) ++ If Accept_Mode is False: MUST NOT drop IPv6 Neighbor 997 Solicitations and Neighbor Advertisements. 999 (640) +-endif // ipv4? 1001 (645) - MUST forward packets with a destination link-layer MAC 1002 address equal to the virtual router MAC address. 1004 (650) - MUST accept packets addressed to the IPvX address(es) 1005 associated with the virtual router if it is the IPvX address owner 1006 or if Accept_Mode is True. Otherwise, MUST NOT accept these 1007 packets. 1009 (655) - If a Shutdown event is received, then: 1011 (660) + Cancel the Adver_Timer 1013 (665) + Send an ADVERTISEMENT with Priority = 0 1015 (670) + Tear down BFD MultipointHead Session 1017 (675) + Transition to the {Initialize} state 1019 (680) -endif // shutdown recv 1021 (685) - If the Adver_Timer fires, then: 1023 (690) + Send an ADVERTISEMENT 1025 (695) + Reset the Adver_Timer to Advertisement_Interval 1027 (700) -endif // advertisement timer fired 1029 (705) - If an ADVERTISEMENT is received, then: 1031 (710) -+ If the Priority in the ADVERTISEMENT is zero, then: 1033 (715) -* Send an ADVERTISEMENT 1035 (720) -* Reset the Adver_Timer to Advertisement_Interval 1037 (725) -+ else // priority was non-zero 1039 (730) -* If the Priority in the ADVERTISEMENT is greater 1040 than the local Priority, 1042 (735) -* or 1044 (740) -* If the Priority in the ADVERTISEMENT is equal to 1045 the local Priority and the primary IPvX Address of the 1046 sender is greater than the local primary IPvX Address, then: 1048 (745) -@ Cancel Adver_Timer 1050 (750) -@ Set Master_Adver_Interval to Adver Interval 1051 contained in the ADVERTISEMENT 1053 (755) -@ Recompute the Skew_Time 1055 (760) @ Recompute the Master_Down_Interval 1057 (765) @ Set Master_Down_Timer to Master_Down_Interval 1059 (770) + Tear down BFD MultipointHead Session 1061 (775) + BootStrap BFD MultipointTail Session 1063 (780) @ Transition to the {Backup} state 1065 (785) * else // new Master logic 1066 (790) @ Discard ADVERTISEMENT 1068 (795) *endif // new Master detected 1070 (800) +endif // was priority zero? 1072 (805) -endif // advert recv 1074 (810) endwhile // in Master 1076 5. Scalability Considerations 1078 To reduce the number of packets generated at a regular interval, 1079 Backup Advert packets may be sent at a reduced rate as compared to 1080 Advert packets sent by the VRRP Master. 1082 In a Data Centre with VXLAN extending the Layer 2 network, when 1083 implementing Section 4 of this document, inherently multicast traffic 1084 is flooded or replicated to all the Virtual Tunneling End Points by 1085 means of multicast traffic in the underlay network. The amount of 1086 replication or flooding depends on the number of Virtual Tunneling 1087 End Points connected to the VXLAN network. VRRP is typically 1088 deployed on the Virtual Tunneling End Points. If Multipoint BFD is 1089 used for tracking the state of VRRP Master Router the Multipoint BFD 1090 packets will get carried over the Layer 2 Overlay, this can lead to a 1091 lot of traffic getting flooded on the overlay as the rate at which 1092 BFD packets are generated will be typically in sub second range. 1093 Which is the problem if VRRP is configured with sub second timers. 1094 So in such scenarios where flooding of Multicast traffic is a 1095 concern, it is recommended to use Point to Point BFD sessions to 1096 avoid inherent flooding of Multicast traffic and configure VRRP to 1097 default or slow timers. 1099 6. Operational Considerations 1101 A VRRP peer that forms a member of this Virtual Router, but does not 1102 support this feature or extension must be configured with the lowest 1103 priority, and will only operate as the Router of last resort on 1104 failure of all other VRRP routers supporting this functionality. 1106 It is recommended that mechanism defined by this draft, to interface 1107 VRRP with BFD should be used when BFD can support more aggressive 1108 monitoring timers than VRRP. Otherwise it is desirable not to 1109 interface VRRP with BFD for determining the health of VRRP Master. 1111 This Draft does not preclude the possibility of the peer table being 1112 populated by means of manual configuration, instead of using the 1113 BACKUP ADVERTISEMENT as defined by the Draft. 1115 7. IANA Considerations 1117 This document requests IANA to create a new name space that is to be 1118 managed by IANA. The document defines a new VRRP Packet Type. The 1119 VRRP Packet Types are discussed below. 1121 a) Type 1 (ADVERTISEMENT) defined in section 5.2.2 of [RFC5798] 1122 b) Type 2 (BACKUP ADVERTISEMENT) defined in section 3.3 of this 1123 document 1125 7.1. A New Name Space for VRRP Packet Types 1127 This document defines in Section 3.3 a "BACKUP ADVERTISEMENT" VRRP 1128 Packet Type. The new name space has to be created by the IANA and 1129 they will maintain this new name space. The field for this namespace 1130 is 4-Bits, and IANA guidelines for assignments for this field are as 1131 follows: 1133 ADVERTISEMENT 1 1134 BACKUP ADVERTISEMENT 2 1136 Future allocations of values in this name space are to be assigned by 1137 IANA using the "Specification Required" policy defined in [IANA-CONS] 1139 8. Security Considerations 1141 Security considerations discussed in [RFC5798], [RFC5880] and 1142 [I-D.draft-ietf-bfd-multipoint], apply to this document. There are 1143 no additional security considerations identified by this draft. 1145 9. Acknowledgements 1147 The authors gratefully acknowledge the contributions of Gerry Meyer, 1148 and Mouli Chandramouli, for their contributions to the draft. The 1149 authors will also like to thank Jeffrey Haas, Maik Pfeil, Chris 1150 Bowers and Vengada Prasad Govindan for their comments and 1151 suggestions. 1153 10. Normative References 1155 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1156 (BFD)", RFC 5880, 2010. 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", RFC 2119, 1997. 1161 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1162 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 2010. 1164 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 1165 Version 3 for IPv4 and IPv6", RFC 5798, 2010. 1167 [I-D.draft-ietf-bfd-multipoint] 1168 Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint 1169 Networks", Work in Progress draft-ietf-bfd-multipoint-07, 1170 2015. 1172 [IANA-CONS] 1173 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1174 IANA Considerations Section in RFCs", RFC 2434, 1998. 1176 Authors' Addresses 1178 Nitish Gupta 1179 Cisco Systems, Inc. 1180 Sarjapur Outer Ring Road 1181 Bangalore 560103 1182 India 1184 Phone: +91 80 4429 2530 1185 Email: nitisgup@cisco.com 1186 URI: http://www.cisco.com/ 1188 Aditya Dogra 1189 Cisco Systems, Inc. 1190 Sarjapur Outer Ring Road 1191 Bangalore 560103 1192 India 1194 Phone: +91 80 4429 2166 1195 Email: addogra@cisco.com 1196 URI: http://www.cisco.com/ 1198 Colin Docherty 1199 25 George Grieve Way 1200 Tranent 1201 East Lothian, Scotland EH332QT 1202 United Kingdom 1204 Email: colin@doch.org.uk 1205 Greg Mirsky 1206 Ericsson 1208 Email: gregory.mirsky@ericsson.com 1210 Jeff Tantsura 1211 Individual 1213 Email: jefftant.ietf@gmail.com