idnits 2.17.1 draft-ietf-rtgwg-vrrp-p2mp-bfd-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 (Using the creation date from RFC5798, updated by this document, for RFC5378 checks: 2007-11-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 March 2022) is 750 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Updates: 5798 (if approved) J. Tantsura 5 Intended status: Standards Track Microsoft 6 Expires: 2 October 2022 G. Mishra 7 Verizon Inc. 8 31 March 2022 10 Applicability of Bidirectional Forwarding Detection (BFD) for Multi- 11 point Networks in Virtual Router Redundancy Protocol (VRRP) 12 draft-ietf-rtgwg-vrrp-p2mp-bfd-02 14 Abstract 16 This document discusses the applicability of Bidirectional Forwarding 17 Detection (BFD) for multipoint networks to provide Virtual Router 18 Redundancy Protocol (VRRP) with sub-second convergence of the Active 19 router and defines the extension to bootstrap point-to-multipoint BFD 20 session. 22 This draft updates RFC 5798. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 2 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions used in this document . . . . . . . . . . . . 2 59 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 60 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 3 63 3.1. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 The [RFC5798] is the current specification of the Virtual Router 73 Redundancy Protocol (VRRP) for IPv4 and IPv6 networks. VRRPv3 allows 74 for a faster switchover to a Backup router. Using such capability 75 with the software-based implementation of VRRP may prove challenging. 76 But it still may be possible to deploy VRRP and provide sub-second 77 detection of Active router failure by Backup routers. 79 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 80 originally defined detect failure of point-to-point (p2p) paths: 81 single-hop [RFC5881], multihop [RFC5883]. Single-hop BFD may be used 82 to enable Backup routers to detect a failure of the Active router 83 within 100 msec or faster. 85 [RFC8562] extends [RFC5880] for multipoint and multicast networks, 86 which matches the deployment scenarios for VRRP over the LAN segment. 87 This document demonstrates how point-to-multipoint (p2mp) BFD can 88 enable faster detection of the Active router failure and thus 89 minimize service disruption in a VRRP domain. The document also 90 defines the extension to VRRP [RFC5798] to bootstrap a VRRP Backup 91 router to join in a p2mp BFD session. 93 1.1. Conventions used in this document 94 1.1.1. Terminology 96 BFD: Bidirectional Forwarding Detection 98 p2mp: Pont-to-Multipoint 100 VRRP: Virtual Router Redundancy Protocol 102 1.1.2. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Problem Statement 112 A router may be part of several Virtual Router Redundancy groups, as 113 Active in some and as Backup in others. Supporting sub-second mode 114 for VRRPv3 [RFC5798] for all these roles without specialized support 115 in the data plane may prove challenging. BFD already has many 116 implementations based on HW that are capable of supporting multiple 117 sub-second sessions concurrently. 119 3. Applicability of p2mp BFD 121 [RFC8562] may provide an efficient and scalable solution for fast- 122 converging environment that uses the default route rather than 123 dynamic routing. Each redundancy group presents itself as a p2mp BFD 124 session, with its Active router being the root and Backup routers 125 being the tails of the p2mp BFD session. Figure 1 displays the 126 extension of VRRP [RFC5798] to bootstrap a tail of the p2mp BFD 127 session. 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |Rsvd |B| Max Adver Int | Checksum | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 + + 138 | IPvX Address(es) | 139 + + 140 + + 141 + + 142 + + 143 | | 144 + + 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Active Router Discriminator | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 152 The new fields are interpreted as follows: 154 B(FD) - a one-bit flag that indicates that the Active Router 155 Discriminator field is appended to VRRP packet defined in 156 [RFC5798]; 158 Active Router Discriminator - the four-octet field. The value 159 MUST NOT be zero, and it equals the My Discriminator value 160 allocated by the root of the p2mp BFD session. 162 The Active router, configured to use p2mp BFD to support faster 163 convergence of VRRP, starts transmitting BFD control packets with 164 VRID as a source IP address and the locally allocated value as the 165 value of the My Discriminator field ([RFC5880]). The same non-zero 166 value of My Discriminator MUST be set as the value of the Active 167 Router Discriminator field. The BFD flag MUST be set in the VRRP 168 packet. A Backup router demultiplexes p2mp BFD test sessions based 169 on VRID that it has been configured with and the non-zero My 170 Discriminator value it learns from the received VRRP packet. When a 171 Backup router detects the failure of the Active router, it re- 172 evaluates its role in the VRID. As a result, the Backup router may 173 become the Active router of the given VRID or continue as a Backup 174 router. If the former is the case, then the new Active router MUST 175 select My Discriminator and start transmitting p2mp BFD control 176 packets using Active router IP address as the source IP address for 177 p2mp BFD control packets. If the latter is the case, then the Backup 178 router MUST wait for the VRRP packet from the new VRRP Active router 179 that will bootstrap the new p2mp BFD session. 181 3.1. Multipoint BFD Encapsulation 183 The MultipointHead of p2mp BFD session when transmitting BFD control 184 packet: 186 MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]). 187 Similarly, all received BFD Control packets that are demultiplexed 188 to the session MUST be discarded if the received TTL or Hop Limit 189 is not equal to 255; 191 SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 192 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address 194 MAY use network broadcast address for IPv4 or link-local all nodes 195 multicast group for IPv6 as destination IP address; 197 MUST set destination UDP port value to 3784 when transmitting BFD 198 control packets, as defined in [RFC8562]; 200 MUST use the Active router IP address as the source IP address. 202 4. IANA Considerations 204 This document makes no requests for IANA allocations. This section 205 may be deleted by RFC Editor. 207 5. Security Considerations 209 This document defines an alternative way, to the one defined in 210 [RFC5798], to accelerate detecting a failure that affects VRRP 211 functionality using p2mp BFD. The operation of either protocol is 212 not changed. 214 Security considerations discussed in [RFC5798], [RFC5880], [RFC5881], 215 and [RFC8562], apply to this document. 217 6. Acknowledgements 219 7. Normative References 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 227 Version 3 for IPv4 and IPv6", RFC 5798, 228 DOI 10.17487/RFC5798, March 2010, 229 . 231 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 232 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 233 . 235 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 236 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 237 DOI 10.17487/RFC5881, June 2010, 238 . 240 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 241 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 242 June 2010, . 244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 246 May 2017, . 248 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 249 Ed., "Bidirectional Forwarding Detection (BFD) for 250 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 251 April 2019, . 253 Authors' Addresses 255 Greg Mirsky 256 Ericsson 257 Email: gregimirsky@gmail.com 259 Jeff Tantsura 260 Microsoft 261 Email: jefftant.ietf@gmail.com 263 Gyan Mishra 264 Verizon Inc. 265 Email: gyan.s.mishra@verizon.com