idnits 2.17.1 draft-nitish-vrrp-bfd-p2p-02.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 (January 24, 2018) is 2276 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 473, but not defined ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 2 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: July 28, 2018 C. Docherty 6 AT&T 7 G. Mirsky 8 J. Tantsura 9 Individual 10 January 24, 2018 12 Fast failure detection in VRRP with Point to Point BFD 13 draft-nitish-vrrp-bfd-p2p-02 15 Abstract 17 This document describes how Point to Point Bidirectional Forwarding 18 Detection (BFD) can be used to support sub-second detection of a 19 Master Router failure in the Virtual Router Redundancy Protocol 20 (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 July 28, 2018. 39 Copyright Notice 41 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability of Point to Point BFD . . . . . . . . . . . . . 5 59 3.1. Extension to VRRP protocol . . . . . . . . . . . . . . . . 5 60 3.2. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7 62 3.4. Sample configuration . . . . . . . . . . . . . . . . . . . 8 63 3.5. Critical BFD session . . . . . . . . . . . . . . . . . . . 9 64 3.6. Protocol State Machine . . . . . . . . . . . . . . . . . . 9 65 3.6.1. Parameters Per Virtual Router . . . . . . . . . . . . 9 66 3.6.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.6.3. VRRP State Machine with Point to Point BFD . . . . . . 10 68 4. Scalability Considerations . . . . . . . . . . . . . . . . . . 20 69 5. Operational Considerations . . . . . . . . . . . . . . . . . . 21 70 6. Applicability to VRRPv2 . . . . . . . . . . . . . . . . . . . 22 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 72 7.1. A New Name Space for VRRP Packet Types . . . . . . . . . . 23 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 75 10. Normative References . . . . . . . . . . . . . . . . . . . . . 26 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 78 1. Introduction 80 The Virtual Router Redundancy Protocol (VRRP) provides redundant 81 Virtual gateways in the Local Area Network (LAN), which is typically 82 the first point of failure for end-hosts sending traffic out of the 83 LAN. Fast failure detection of VRRP Master is critical in supporting 84 high availability of services and improved Quality of Experience to 85 users. In VRRP [RFC5798] specification, Backup routers depend on 86 VRRP packets generated at a regular interval by the Master router, to 87 detect the health of the VRRP Master. Faster failure detection can 88 be achieved within VRRP protocol by reducing the Advertisement and 89 Master Down Interval. However, sub second Advert timers, can put 90 extra load on CPU and the network bandwidth which may not be 91 desirable. 93 Since the VRRP protocol depends on the availability of Layer 3 IPv4 94 or IPv6 connectivity between redundant peers, the VRRP protocol can 95 interact with the Layer 3 variant of BFD as described in [RFC5881] to 96 achieve a much faster failure detection of the VRRP Master on the 97 LAN. BFD, as specified by the [RFC5880] can provide a much faster 98 failure detection in the range of 150ms, if implemented in the part 99 of a Network device which scales better than VRRP when sub second 100 Advert timers are used. 102 2. Requirements Language 104 In this document, several words are used to signify the requirements 105 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 106 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 107 and "OPTIONAL" in this document are to be interpreted as described in 108 RFC 2119. [RFC2119] 110 3. Applicability of Point to Point BFD 112 BFD for IPv4 or IPv6 (Single Hop) [RFC5881] requires that in order 113 for a BFD session to be formed both peers participating in a BFD 114 session need to know its peer IPv4 or IPV6 address. This poses a 115 unique problem with the definition of the VRRP protocol, that makes 116 the use of BFD for IPv4 or IPv6 [RFC5881] more challenging. In VRRP 117 it is only the Master router that sends Advert packets. This means 118 that a Master router is not aware of any Backup routers, and Backup 119 routers are only aware of the Master router. This also means that a 120 Backup router is not aware of any other Backup routers in the 121 Network. 123 Since BFD for IPv4 or IPv6 [RFC5881] requires that a session be 124 formed by both peers using a full destination and source address, 125 there needs to be some external means to provide this information to 126 BFD on behalf of VRRP. Once the peer information is made available, 127 VRRP can form BFD sessions with its peer Virtual Router. The BFD 128 session for a given Virtual Router is identified as the Critical Path 129 BFD Session, which is the session that forms between the current VRRP 130 Master router, and the highest priority Backup router. When the 131 Critical Path BFD Session identified by VRRP as having changed state 132 from Up to Down, then this will be interpreted by the VRRP state 133 machine on the highest priority Backup router as a Master Down event. 134 A Master Down event means that the highest priority Backup peer will 135 immediately become the new Master for the Virtual Router. 137 NOTE: At all times, the normal fail-over mechanism defined in the 138 VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism 139 will always resort to normal VRRP fail-over. 141 This draft defines the mechanism used by the VRRP protocol to build a 142 peer table that will help in forming of BFD session and the detection 143 of Critical Path BFD session. If the Critical Path BFD session were 144 to go down, it will signal a Master Down event and make the most 145 preferred Backup router as the VRRP Master router. This requires an 146 extension to the VRRP protocol. 148 This can be achieved by defining a new type in the VRRP Advert 149 packet, and allowing VRRP peers to build a peer table in any of the 150 operational state, Master or Backup. 152 3.1. Extension to VRRP protocol 154 In this mode of operation VRRP peers learn the adjacent routers, and 155 form BFD session between the learnt routers. In order to build the 156 peer table, all routers send VRRP Advert packets whilst in any of the 157 operational states (Master or Backup). Normally VRRP peers only send 158 Advert packets whilst in the Master state, however in this mode VRRP 159 Backup peers will also send Advert packets with the type field set to 160 BACKUP ADVERTISEMENT type defined in Section 3.3 of this document. 161 The VRRP Master router will still continue to send packets with the 162 Advert type as ADVERTISEMENT as defined in the VRRP protocol. This 163 is to maintain inter-operability with peers complying to VRRP 164 protocol. 166 Additionally, Advert packets sent from Backup Peers must not use the 167 Virtual router MAC address as the source address. Instead it must 168 use the Interface MAC address as the source address from which the 169 packet is sent from. This is because the source MAC override feature 170 is used by the Master to send Advert packets from the Virtual Router 171 MAC address, which is used to keep the bridging cache on LAN switches 172 and bridging devices refreshed with the destination port for the 173 Virtual Router MAC. 175 3.2. VRRP Peer Table 177 VRRP peers can now form the peer table by learning the source address 178 in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP 179 Master or Backup peers. This allows peers to create BFD sessions 180 with other operational peers. 182 A peer entry should be removed from the peer table if Advert is not 183 received from a peer for a period of (3 * the Advert interval). 185 3.3. VRRP BACKUP ADVERTISEMENT Packet Type 187 The following figure shows the VRRP packet as defined in VRRP 188 [RFC5798] RFC. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | IPv4 Fields or IPv6 Fields | 194 ... ... 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |(rsvd) | Max Advert Int | Checksum | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 + + 203 | IPvX Address(es) | 204 + + 205 + + 206 + + 207 + + 208 | | 209 + + 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 The type field specifies the type of this VRRP packet. The type 214 field can have two values. Type 1 (ADVERTISEMENT) is used by the 215 VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the 216 VRRP Backup router. This is to distinguish the packets sent by the 217 VRRP backup Router. VRRP Backup fills Backup_Advertisement_Interval 218 in the Max Advert Int of BACKUP ADVERTISEMENT packet. Rest of the 219 fields in Advert packet remain the same. 221 1 ADVERTISEMENT 222 2 BACKUP ADVERTISEMENT 224 A packet with unknown type MUST be discarded. 226 3.4. Sample configuration 228 The following figure shows a simple network with three VRRP routers 229 implementing one virtual router. 231 +-----------+ +-----------+ +-----------+ 232 | Rtr1 | | Rtr2 | | Rtr3 | 233 |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| 234 | (PR=200) | | (PR=150) | | (PR=100) | 235 | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | 236 +-----------+ +-----------+ +-----------+ 237 B C D 238 | | | 239 | | | 240 | | | 241 ---------+--------+--------+---------+--------+--------- 242 Legend: 243 ---+---+---+-- = Ethernet, Token Ring, or FDDI 244 MR = Master Router 245 BR = Backup Router 246 PR = VRRP Router priority 247 VRID = VRRP Router ID 248 VRIPVX= IPv4 or IPv6 address protected by 249 the VRRP Router 250 B,C,D = Interface IPv4 or IPv6 address of 251 the Virtual Router 253 In the above configuration there are three routers on the LAN 254 protecting an IPv4 or IPv6 address associated to a Virtual Router ID 255 1. Rtr1 is the Master router since it has the highest priority 256 compared to Rtr2 and Rtr3. Now if peer learning extension is enabled 257 on all the peers. Rtr1 will send the Advert packet with type field 258 set to 1. While Rtr2 and Rtr3 will send the Advert packet with type 259 field set to 2. In the above configuration the peer table built at 260 each router is shown below: 262 Rtr1 Peer table 264 +------------------------------------+ 265 | Peer Address | Priority | 266 +------------------------------------+ 267 | C | 150 | 268 +------------------------------------+ 269 | D | 100 | 270 +------------------------------------+ 271 Rtr2 Peer table 273 +------------------------------------+ 274 | Peer Address | Priority | 275 +------------------------------------+ 276 | B | 200 | 277 +------------------------------------+ 278 | D | 100 | 279 +------------------------------------+ 281 Rtr3 Peer table 283 +------------------------------------+ 284 | Peer Address | Priority | 285 +------------------------------------+ 286 | B | 200 | 287 +------------------------------------+ 288 | C | 150 | 289 +------------------------------------+ 291 Once the peer tables are formed, VRRP on each router can form a BFD 292 sessions with the learnt peers. 294 3.5. Critical BFD session 296 The Critical BFD Session is determined to be the session between the 297 VRRP Master and the next best VRRP Backup. Failure of the Critical 298 BFD session indicates that the Master is no longer available and the 299 most preferred Backup will now become Master. 301 In the above example the Critical BFD session is shared between Rtr1 302 and Rtr2. If the BFD Session goes from Up to Down state, Rtr2 can 303 treat it as a Master down event and immediately assume the role of 304 VRRP Master router for VRID 1 and Rtr3 will become the critical 305 Backup. If the priorities of two Backup routers are same then the 306 primary IPvX Address of the sender is used to determine the highest 307 priority Backup. Where higher IPvX address has higher priority. 309 3.6. Protocol State Machine 311 3.6.1. Parameters Per Virtual Router 313 Following parameters are added to the VRRP protocol to support this 314 mode of operation. 316 Backup_Advertisement_Interval Time interval between 317 BACKUP ADVERTISEMENTS 318 (centiseconds). Default is 100 319 centiseconds (1 second). 321 Backup_Adver_Interval Advertisement interval contained in 322 BACKUP ADVERTISEMENTS received from 323 the Backup (centiseconds). This 324 value is saved by virtual routers 325 used, to compute Backup_Down_Interval. 327 Backup_Down_Interval Time interval for VRRP instance 328 to declare Backup down 329 (centiseconds). Calculated as 330 (3 * Backup_Adver_Interval) for 331 each VRRP Backup. 333 Critical_Backup Procedure outlined in section 3.4 334 of this document is used to 335 determine the Critical_Backup at 336 each VRRP Instance. 338 Critical_BFD_Session The Critical BFD Session is 339 the session between 340 the VRRP Master and Critical_Backup. 342 3.6.2. Timers 344 Following timers are added to the VRRP protocol to support this mode 345 of operation. 347 Backup_Down_Timer Timer that fires when BACKUP ADVERTISEMENT 348 has not been heard from a backup peer for 349 Backup_Down_Interval. 351 Backup_Adver_Timer Timer that fires to trigger sending of 352 BACKUP ADVERTISEMENT based on 353 Backup_Advertisement_Interval. 355 3.6.3. VRRP State Machine with Point to Point BFD 357 Following State Machine replaces the state Machine outlined in 358 section 6.4 of the VRRP protocol [RFC5798] to support this mode of 359 operation. Please refer to the section 6.4 of [RFC5798] for State 360 description. 362 3.6.3.1. Initialize 364 Following state machine replaces the state machine outlined in 365 section 6.4.1 of [RFC5798] 367 (100) If a Startup event is received, then: 369 (105) - If the Priority = 255 (i.e., the router owns the IPvX 370 address associated with the virtual router), then: 372 (110) + Send an ADVERTISEMENT 374 (115) + If the protected IPvX address is an IPv4 address, then: 376 (120) * Broadcast a gratuitous ARP request containing the 377 virtual router MAC address for each IP address associated 378 with the virtual router. 380 (125) + else // IPv6 382 (130) * For each IPv6 address associated with the virtual 383 router, send an unsolicited ND Neighbor Advertisement with 384 the Router Flag (R) set, the Solicited Flag (S) unset, the 385 Override flag (O) set, the target address set to the IPv6 386 address of the virtual router, and the target link-layer 387 address set to the virtual router MAC address. 389 (135) +endif // was protected addr IPv4? 391 (140) + Set the Adver_Timer to Advertisement_Interval 393 (145) + Transition to the {Master} state 395 (150) - else // rtr does not own virt addr 397 (155) + Set Master_Adver_Interval to Advertisement_Interval 399 (160) + Set the Master_Down_Timer to Master_Down_Interval 401 (165) + Set Backup_Adver_Timer to Backup_Advertisement_Interval 403 (170) + Transition to the {Backup} state 405 (175) -endif // priority was not 255 407 (180) endif // startup event was recv 409 3.6.3.2. Backup 411 Following state machine replaces the state machine outlined in 412 section 6.4.2 of [RFC5798] 414 (300) While in this state, a VRRP router MUST do the following: 416 (305) - If the protected IPvX address is an IPv4 address, then: 418 (310) + MUST NOT respond to ARP requests for the IPv4 419 address(es) associated with the virtual router. 421 (315) - else // protected addr is IPv6 423 (320) + MUST NOT respond to ND Neighbor Solicitation messages 424 for the IPv6 address(es) associated with the virtual router. 426 (325) + MUST NOT send ND Router Advertisement messages for the 427 virtual router. 429 (330) -endif // was protected addr IPv4? 431 (335) - MUST discard packets with a destination link-layer MAC 432 address equal to the virtual router MAC address. 434 (340) - MUST NOT accept packets addressed to the 435 IPvX address(es) associated with the virtual router. 437 (345) - If a Shutdown event is received, then: 439 (350) + Cancel the Master_Down_Timer. 441 (355) + Cancel the Backup_Adver_Timer. 443 (360) + Cancel Backup_Down_Timers. 445 (365) + Remove Peer table. 447 (370) + If Critical_BFD_Session Exists: 449 (375) * Tear down the Critical_BFD_Session. 451 (380) + endif // Critical_BFD_Session Exists? 453 (385) + Send a BACKUP ADVERTISEMENT with Priority = 0. 455 (390) + Transition to the {Initialize} state. 457 (395) -endif // shutdown recv 459 (400) - If the Master_Down_Timer fires or 460 If Critical_BFD_Session transitions from UP to DOWN, then: 462 (405) + Send an ADVERTISEMENT 464 (415) + If the protected IPvX address is an IPv4 address, then: 466 (420) * Broadcast a gratuitous ARP request on that interface 467 containing the virtual router MAC address for each IPv4 468 address associated with the virtual router. 470 (425) + else // ipv6 472 (430) * Compute and join the Solicited-Node multicast 473 address [RFC4291] for the IPv6 address(es) associated with 474 the virtual router. 476 (435) * For each IPv6 address associated with the virtual 477 router, send an unsolicited ND Neighbor Advertisement with 478 the Router Flag (R) set, the Solicited Flag (S) unset, the 479 Override flag (O) set, the target address set to the IPv6 480 address of the virtual router, and the target link-layer 481 address set to the virtual router MAC address. 483 (440) +endif // was protected addr ipv4? 485 (445) + Set the Adver_Timer to Advertisement_Interval. 487 (450) + If the Critical_BFD_Session exists: 489 (455) @ Tear Critical_BFD_Session. 491 (460) + endif // Critical_BFD_Session exists 493 (465) + Calculate the Critical_Backup. 495 (470) + If the Critical_Backup exists: 497 (475) * BootStrap Critical_BFD_Session with the 498 Critical_Backup. 500 (480) + endif //Critical_Backup exists? 502 (485) + Transition to the {Master} state. 504 (490) -endif // Master_Down_Timer fired 505 (485) - If an ADVERTISEMENT is received, then: 507 (490) + If the Priority in the ADVERTISEMENT is zero, then: 509 (495) * Set the Master_Down_Timer to Skew_Time. 511 (500) * If the Critical_BFD_Session exists: 513 (505) * Tear Critical_BFD_Session with the Master. 515 (510) * endIf // Critical_BFD_Session exists 517 (515) + else // priority non-zero 519 (520) * If Preempt_Mode is False, or if the Priority in the 520 ADVERTISEMENT is greater than or equal to the local 521 Priority, then: 523 (525) @ Set Master_Adver_Interval to Adver Interval 524 contained in the ADVERTISEMENT. 526 (530) @ Recompute the Master_Down_Interval. 528 (535) @ Reset the Master_Down_Timer to 529 Master_Down_Interval. 531 (540) @ Determine Critical_Backup. 533 (545) @ If Critical_BFD_Session does not exists and this 534 instance is the Critical_Backup: 536 (550) @+ BootStrap Critical_BFD_Session with Master. 538 (555) @ endif //Critical_BFD_Session exists check 540 (560) * else // preempt was true or priority was less 542 (565) @ Discard the ADVERTISEMENT. 544 (570) *endif // preempt test 546 (575) +endif // was priority zero? 548 (580) -endif // was advertisement recv? 550 (585) - If a BACKUP ADVERTISEMENT is received, then: 552 (590) + If the Priority in the BACKUP ADVERTISEMENT is zero, 553 then: 555 (595) * Cancel Backup_Down_Timer. 557 (600) * Remove the Peer from Peer table. 559 (605) + else // priority non-zero 561 (610) * Update the peer table with peer information. 563 (615) * Set Backup_Adver_Interval to Adver Interval 564 contained in the BACKUP ADVERTISEMENT. 566 (620) * Recompute the Backup_Down_Interval. 568 (625) * Reset the Backup_Down_Timer to Backup_Down_Interval. 570 (630) +endif // was priority zero? 572 (635) + Recalculate Critical_Backup. 574 (640) + If Critical_BFD_Session exists and this 575 instance is not the Critical_Backup: 577 (645) * Tear Down the Critical_BFD_Session. 579 (650) + else If Critical_BFD_Session does not exists and this 580 instance is the Critical_Backup: 582 (655) * BootStrap Critical_BFD_Session with Master. 584 (660) + endif // Critical_Backup change 586 (665) -endif // was backup advertisement recv? 588 (670) - If Backup_Down_Timer fires, then: 590 (675) + Remove the Peer from Peer table. 592 (680) + If Critical_BFD_Session does not exist: 594 (685) @ Recalculate Critical_Backup. 596 (690) @ If This instance is the Critical_Backup: 598 (695) +@ BootStrap Critical_BFD_Session with Master. 600 (700) @ endif // Critical_Backup change 602 (705) + endif // Critical_BFD_Session does not exist? 604 (710) -endif // Backup_Down_Timer fires? 606 (715) - If Backup_Adver_Timer fires, then: 608 (720) + Send a BACKUP ADVERTISEMENT. 610 (725) + Reset the Backup_Adver_Timer to 611 Backup_Advertisement_Interval. 613 (730) -endif // Backup_Down_Timer fires? 615 (735) endwhile // Backup state 617 3.6.3.3. Master 619 Following state machine replaces the state machine outlined in 620 section 6.4.3 of [RFC5798] 622 (800) While in this state, a VRRP router MUST do the following: 624 (805) - If the protected IPvX address is an IPv4 address, then: 626 (810) + MUST respond to ARP requests for the IPv4 address(es) 627 associated with the virtual router. 629 (815) - else // ipv6 631 (820) + MUST be a member of the Solicited-Node multicast 632 address for the IPv6 address(es) associated with the virtual 633 router. 635 (825) + MUST respond to ND Neighbor Solicitation message for 636 the IPv6 address(es) associated with the virtual router. 638 (830) + MUST send ND Router Advertisements for the virtual 639 router. 641 (835) + If Accept_Mode is False: MUST NOT drop IPv6 642 Neighbor Solicitations and Neighbor Advertisements. 644 (840) -endif // ipv4? 646 (845) - MUST forward packets with a destination link-layer MAC 647 address equal to the virtual router MAC address. 649 (850) - MUST accept packets addressed to the IPvX address(es) 650 associated with the virtual router if it is the IPvX address 651 owner or if Accept_Mode is True. Otherwise, MUST NOT accept 652 these packets. 654 (855) - If a Shutdown event is received, then: 656 (860) + Cancel the Adver_Timer. 658 (865) + Send an ADVERTISEMENT with Priority = 0, 660 (870) + Cancel Backup_Down_Timers. 662 (875) + Remove Peer table. 664 (880) + If Critical_BFD_Session Exists: 666 (885) * Tear down Critical_BFD_Session 668 (890) + endif // If Critical_BFD_Session Exists 670 (895) + Transition to the {Initialize} state. 672 (900) -endif // shutdown recv 674 (905) - If the Adver_Timer fires, then: 676 (910) + Send an ADVERTISEMENT. 678 (915) + Reset the Adver_Timer to Advertisement_Interval. 680 (920) -endif // advertisement timer fired 682 (925) - If an ADVERTISEMENT is received, then: 684 (930) -+ If the Priority in the ADVERTISEMENT is zero, then: 686 (935) -* Send an ADVERTISEMENT. 688 (940) -* Reset the Adver_Timer to Advertisement_Interval. 690 (945) -+ else // priority was non-zero 692 (950) -* If the Priority in the ADVERTISEMENT is greater 693 than the local Priority, 695 (955) -* or 696 (960) -* If the Priority in the ADVERTISEMENT is equal to 697 the local Priority and the primary IPvX Address of the 698 sender is greater than the local primary IPvX Address, then: 700 (965) -@ Cancel Adver_Timer 702 (970) -@ Set Master_Adver_Interval to Adver Interval 703 contained in the ADVERTISEMENT 705 (975) -@ Recompute the Skew_Time 707 (980) @ Recompute the Master_Down_Interval 709 (985) @ Set Master_Down_Timer to Master_Down_Interval 711 (990) If Critical_BFD_Session Exists: 713 (995) @+ Tear Critical_BFD_Session 715 (960) @ endif //Critical_BFD_Session Exists? 717 (965) @ Calculate Critical_Backup. 719 (970) @ If this instance is Critical_Backup: 721 (975) @+ BootStrap Critical_BFD_Session with new 722 Master. 724 (980) @ endif // am i Critical_Backup? 726 (985) @ Transition to the {Backup} state 728 (990) * else // new Master logic 730 (995) @ Discard ADVERTISEMENT 732 (1000) *endif // new Master detected 734 (1005) +endif // was priority zero? 736 (1010) -endif // advert recv 738 (1015) - If a BACKUP ADVERTISEMENT is received, then: 740 (1020) + If the Priority in the BACKUP ADVERTISEMENT is 741 zero, then: 743 (1025) * Remove the Peer from peer table. 745 (1030) + else: // priority non-zero 747 (1035) * Update the Peer info in peer table. 749 (1040) * Recompute the Backup_Down_Interval 751 (1045) * Reset the Backup_Down_Timer to 752 Backup_Down_Interval 754 (1050) + endif // priority in backup advert zero 756 (1055) + Calculate the Critical_Backup 758 (1060) + If Critical_BFD_Session doesnot exist: 760 (1065) * BootStrap Critical_BFD_Session 762 (1070) + else if Critical_BFD_Session exist and 763 Critical_Backup changes: 765 (1075) + Tear Critical_BFD_Session with old Backup 767 (1080) + BootStrap Critical_BFD_Session with Critical_Backup 769 (1085) + endif // Critical_BFD_Session check? 771 (1090) - endif // backup advert recv 773 (1095) - If Critical_BFD_Session transitions from UP to DOWN, 774 then: 775 (1100) + Cancel Backup_Down_Timer 777 (1105) + Delete the Peer info from peer table 779 (1200) + Calculate the Critical_Backup 781 (1205) + BootStrap Critical_BFD_Session with Critical_Backup 783 (1210) - endif // BFD session transition 785 (1215) endwhile // in Master 787 4. Scalability Considerations 789 To reduce the number of packets generated at a regular interval, 790 Backup Advert packets may be sent at a reduced rate as compared to 791 Advert packets sent by the VRRP Master. 793 5. Operational Considerations 795 A VRRP peer that forms a member of this Virtual Router, but does not 796 support this feature or extension must be configured with the lowest 797 priority, and will only operate as the Router of last resort on 798 failure of all other VRRP routers supporting this functionality. 800 It is recommended that mechanism defined by this draft, to interface 801 VRRP with BFD should be used when BFD can support more aggressive 802 monitoring timers than VRRP. Otherwise it is desirable not to 803 interface VRRP with BFD for determining the health of VRRP Master. 805 This Draft does not preclude the possibility of the peer table being 806 populated by means of manual configuration, instead of using the 807 BACKUP ADVERTISEMENT as defined by the Draft. 809 6. Applicability to VRRPv2 811 The workings of this Draft can be extended to VRRPv2 [RFC3768], with 812 the introduction of BACKUP ADVERTISEMENT and Peer Table as outlined 813 in the Draft. 815 7. IANA Considerations 817 This document requests IANA to create a new name space that is to be 818 managed by IANA. The document defines a new VRRP Packet Type. The 819 VRRP Packet Types are discussed below. 821 a) Type 1 (ADVERTISEMENT) defined in section 5.2.2 of [RFC5798] 822 b) Type 2 (BACKUP ADVERTISEMENT) defined in section 3.3 of this 823 document 825 7.1. A New Name Space for VRRP Packet Types 827 This document defines in Section 3.3 a "BACKUP ADVERTISEMENT" VRRP 828 Packet Type. The new name space has to be created by the IANA and 829 they will maintain this new name space. The field for this namespace 830 is 4-Bits, and IANA guidelines for assignments for this field are as 831 follows: 833 ADVERTISEMENT 1 834 BACKUP ADVERTISEMENT 2 836 Future allocations of values in this name space are to be assigned by 837 IANA using the "Specification Required" policy defined in [IANA-CONS] 839 8. Security Considerations 841 Security considerations discussed in [RFC5798], [RFC5880], apply to 842 this document. There are no additional security considerations 843 identified by this draft. 845 9. Acknowledgements 847 The authors gratefully acknowledge the contributions of Gerry Meyer, 848 and Mouli Chandramouli, for their contributions to the draft. The 849 authors will also like to thank Jeffrey Haas, Maik Pfeil, Chris 850 Bowers, Vengada Prasad Govindan and Alexander Vainshtein for their 851 comments and suggestions. 853 10. Normative References 855 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 856 (BFD)", RFC 5880, 2010. 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", RFC 2119, 1997. 861 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 862 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 2010. 864 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 865 Version 3 for IPv4 and IPv6", RFC 5798, 2010. 867 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 868 RFC 3768, 2004. 870 [IANA-CONS] 871 Narten, T. and H. Alvestrand, "Guidelines for Writing an 872 IANA Considerations Section in RFCs", RFC 2434, 1998. 874 Authors' Addresses 876 Nitish Gupta 877 Cisco Systems, Inc. 878 3265 CISCO Way 879 San Jose 95134 880 United States 882 Phone: +91 80 4429 2530 883 Email: nitisgup@cisco.com 884 URI: http://www.cisco.com/ 886 Aditya Dogra 887 Cisco Systems, Inc. 888 Sarjapur Outer Ring Road 889 Bangalore 560103 890 India 892 Phone: +91 80 4429 2166 893 Email: addogra@cisco.com 894 URI: http://www.cisco.com/ 896 Colin Docherty 897 AT&T 898 23 The Maltings 899 Haddington, Scotland EH414EF 900 United Kingdom 902 Email: colin.docherty@att.com 904 Greg Mirsky 905 Individual 907 Email: gregimirsky@gmail.com 909 Jeff Tantsura 910 Individual 912 Email: jefftant.ietf@gmail.com