idnits 2.17.1 draft-mirsky-bfd-p2mp-vrrp-use-case-06.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 (26 March 2021) is 1125 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 ZTE Corp. 4 Updates: 5798 (if approved) J. Tantsura 5 Intended status: Standards Track Juniper Networks 6 Expires: 27 September 2021 G. Mishra 7 Verizon Inc. 8 26 March 2021 10 Bidirectional Forwarding Detection (BFD) for Multi-point Networks and 11 Virtual Router Redundancy Protocol (VRRP) Use Case 12 draft-mirsky-bfd-p2mp-vrrp-use-case-06 14 Abstract 16 This document discusses the use of Bidirectional Forwarding Detection 17 (BFD) for multipoint networks to provide Virtual Router Redundancy 18 Protocol (VRRP) with sub-second Master convergence and defines the 19 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 27 September 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified 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 Master 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 Master router 82 within 100 msec or faster. 84 [RFC8562] extends [RFC5880] for multipoint and multicast networks, 85 which is precisely characterizes deployment scenarios for VRRP over 86 LAN segment. This document demonstrates how point-to-multipoint 87 (p2mp) BFD can enable faster detection of Master failure and thus 88 minimize service disruption in a VRRP domain. The document also 89 defines the extension to VRRP [RFC5798] to bootstrap a VRRP Backup 90 router to join in p2mp 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 Master in some and as Backup in others. Supporting sub-second mode 114 for VRRPv3 [RFC5798] for all these roles without specialized support 115 in 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 Master being the root and Backup routers being tails 125 of the p2mp BFD session. Figure 1 displays the extension of VRRP 126 [RFC5798] to bootstrap tail of the p2mp BFD session. Master 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 |Rsvd |B| Max Adver Int | Checksum | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 + + 136 | IPvX Address(es) | 137 + + 138 + + 139 + + 140 + + 141 | | 142 + + 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Master Discriminator | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 150 where new fields are interpreted as: 152 B(FD) - a one-bit flag that indicates that the Master 153 Discriminator field is appended to VRRP packet defined in 154 [RFC5798]; 156 Master Discriminator - My Discriminator value allocated by the 157 root of the p2mp BFD session. 159 The Master router that is configured to use p2mp BFD to support 160 faster convergence of VRRP starts transmitting BFD control packets 161 with VRID as a source IP address and My Discriminator. The same 162 value of My Discriminator MUST be set as the value of the Master 163 Discriminator field. The BFD flag MUST be set in the VRRP packet. 164 Backup router demultiplexes p2mp BFD test sessions based on VRID that 165 it been configured with and the My Discriminator value it learns from 166 the received VRRP packet. When a Backup router detects the failure 167 of the Master router it re-evaluates its role in the VRID. As a 168 result, the Backup router may become the Master router of the given 169 VRID or continue as a Backup router. If the former is the case, then 170 the new Master router MUST select My Discriminator and start 171 transmitting p2mp BFD control packets using Master IP address as the 172 source IP address for p2mp BFD control packets. If the latter is the 173 case, then the Backup router MUST wait for the VRRP packet from the 174 new VRRP Master router that will bootstrap the new p2mp BFD session. 176 3.1. Multipoint BFD Encapsulation 178 The MultipointHead of p2mp BFD session when transmitting BFD control 179 packet: 181 MUST set TTL value to 1 (though note that VRRP packets have TTL 182 set to 255); 184 SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 185 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address 187 MAY use network broadcast address for IPv4 or link-local all nodes 188 multicast group for IPv6 as destination IP address; 190 MUST set destination UDP port value to 3784 when transmitting BFD 191 control packets, as defined in [RFC8562]; 193 MUST use the Master IP address as the source IP address. 195 4. IANA Considerations 197 This document makes no requests for IANA allocations. This section 198 may be deleted by RFC Editor. 200 5. Security Considerations 202 Security considerations discussed in [RFC5798], [RFC5880], and 203 [RFC8562], apply to this document. 205 6. Acknowledgements 207 7. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, 211 DOI 10.17487/RFC2119, March 1997, 212 . 214 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 215 Version 3 for IPv4 and IPv6", RFC 5798, 216 DOI 10.17487/RFC5798, March 2010, 217 . 219 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 220 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 221 . 223 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 224 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 225 DOI 10.17487/RFC5881, June 2010, 226 . 228 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 229 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 230 June 2010, . 232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 234 May 2017, . 236 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 237 Ed., "Bidirectional Forwarding Detection (BFD) for 238 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 239 April 2019, . 241 Authors' Addresses 243 Greg Mirsky 244 ZTE Corp. 246 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 248 Jeff Tantsura 249 Juniper Networks 251 Email: jefftant.ietf@gmail.com 253 Gyan Mishra 254 Verizon Inc. 256 Email: gyan.s.mishra@verizon.com