idnits 2.17.00 (12 Aug 2021) /tmp/idnits36787/draft-ietf-rtgwg-vrrp-p2mp-bfd-01.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: ---------------------------------------------------------------------------- (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 (21 March 2022) is 61 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 (~~), 0 warnings (==), 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: 22 September 2022 G. Mishra 7 Verizon Inc. 8 21 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-01 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 Active convergence and 19 defines the extension to bootstrap point-to-multipoint BFD session. 21 This draft updates RFC 5798. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 22 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions used in this document . . . . . . . . . . . . 3 58 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 59 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 3 62 3.1. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The [RFC5798] is the current specification of the Virtual Router 72 Redundancy Protocol (VRRP) for IPv4 and IPv6 networks. VRRPv3 allows 73 for a faster switchover to a Backup router. Using such capability 74 with the software-based implementation of VRRP may prove challenging. 75 But it still may be possible to deploy VRRP and provide sub-second 76 detection of Active router failure by Backup routers. 78 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 79 originally defined detect failure of point-to-point (p2p) paths: 80 single-hop [RFC5881], multihop [RFC5883]. Single-hop BFD may be used 81 to enable Backup routers to detect a failure of the Active router 82 within 100 msec or faster. 84 [RFC8562] extends [RFC5880] for multipoint and multicast networks, 85 which matches the deployment scenarios for VRRP over the LAN segment. 86 This document demonstrates how point-to-multipoint (p2mp) BFD can 87 enable faster detection of Active failure and thus minimize service 88 disruption in a VRRP domain. The document also defines the extension 89 to VRRP [RFC5798] to bootstrap a VRRP Backup router to join in p2mp 90 BFD session. 92 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 being the root and Backup routers being the 125 tails of the p2mp BFD session. Figure 1 displays the extension of 126 VRRP [RFC5798] to bootstrap a tail of the p2mp BFD session. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |Rsvd |B| Max Adver Int | Checksum | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 + + 137 | IPvX Address(es) | 138 + + 139 + + 140 + + 141 + + 142 | | 143 + + 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Active Router Discriminator | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 151 The new fields are interpreted as follows: 153 B(FD) - a one-bit flag that indicates that the Active Router 154 Discriminator field is appended to VRRP packet defined in 155 [RFC5798]; 157 Active Router Discriminator - the four-octet field. The value 158 MUST NOT be zero, and it equals the My Discriminator value 159 allocated by the root of the p2mp BFD session. 161 The Active router, configured to use p2mp BFD to support faster 162 convergence of VRRP, starts transmitting BFD control packets with 163 VRID as a source IP address and the locally allocated value as the 164 value of the My Discriminator field ([RFC5880]). The same non-zero 165 value of My Discriminator MUST be set as the value of the Active 166 Router Discriminator field. The BFD flag MUST be set in the VRRP 167 packet. A Backup router demultiplexes p2mp BFD test sessions based 168 on VRID that it has been configured with and the non-zero My 169 Discriminator value it learns from the received VRRP packet. When a 170 Backup router detects the failure of the Active router, it re- 171 evaluates its role in the VRID. As a result, the Backup router may 172 become the Active router of the given VRID or continue as a Backup 173 router. If the former is the case, then the new Active router MUST 174 select My Discriminator and start transmitting p2mp BFD control 175 packets using Active IP address as the source IP address for p2mp BFD 176 control packets. If the latter is the case, then the Backup router 177 MUST wait for the VRRP packet from the new VRRP Active router that 178 will bootstrap the new p2mp BFD session. 180 3.1. Multipoint BFD Encapsulation 182 The MultipointHead of p2mp BFD session when transmitting BFD control 183 packet: 185 MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]). 186 Similarly, all received BFD Control packets that are demultiplexed 187 to the session MUST be discarded if the received TTL or Hop Limit 188 is not equal to 255; 190 SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 191 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address 193 MAY use network broadcast address for IPv4 or link-local all nodes 194 multicast group for IPv6 as destination IP address; 196 MUST set destination UDP port value to 3784 when transmitting BFD 197 control packets, as defined in [RFC8562]; 199 MUST use the Active IP address as the source IP address. 201 4. IANA Considerations 203 This document makes no requests for IANA allocations. This section 204 may be deleted by RFC Editor. 206 5. Security Considerations 208 This document defines an alternative way, to the one defined in 209 [RFC5798], to accelerate detecting a failure that affects VRRP 210 functionality using p2mp BFD. The operation of either protocol is 211 not changed. 213 Security considerations discussed in [RFC5798], [RFC5880], [RFC5881], 214 and [RFC8562], apply to this document. 216 6. Acknowledgements 218 7. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 226 Version 3 for IPv4 and IPv6", RFC 5798, 227 DOI 10.17487/RFC5798, March 2010, 228 . 230 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 231 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 232 . 234 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 235 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 236 DOI 10.17487/RFC5881, June 2010, 237 . 239 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 240 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 241 June 2010, . 243 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 244 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 245 May 2017, . 247 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 248 Ed., "Bidirectional Forwarding Detection (BFD) for 249 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 250 April 2019, . 252 Authors' Addresses 254 Greg Mirsky 255 Ericsson 256 Email: gregimirsky@gmail.com 258 Jeff Tantsura 259 Microsoft 260 Email: jefftant.ietf@gmail.com 262 Gyan Mishra 263 Verizon Inc. 264 Email: gyan.s.mishra@verizon.com