idnits 2.17.1 draft-mirsky-bfd-p2mp-vrrp-use-case-05.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 (November 1, 2020) is 1243 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 Apstra 6 Expires: May 5, 2021 G. Mishra 7 Verizon Inc. 8 November 1, 2020 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-05 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 May 5, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions used in this document . . . . . . . . . . . . 3 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 Master 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 Master router 83 within 100 msec or faster. 85 [RFC8562] extends [RFC5880] for multipoint and multicast networks, 86 which is precisely characterizes deployment scenarios for VRRP over 87 LAN segment. This document demonstrates how point-to-multipoint 88 (p2mp) BFD can enable faster detection of Master 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 p2mp BFD session. 93 1.1. Conventions used in this document 95 1.1.1. Terminology 97 BFD: Bidirectional Forwarding Detection 99 p2mp: Pont-to-Multipoint 101 VRRP: Virtual Router Redundancy Protocol 103 1.1.2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2. Problem Statement 113 A router may be part of several Virtual Router Redundancy groups, as 114 Master in some and as Backup in others. Supporting sub-second mode 115 for VRRPv3 [RFC5798] for all these roles without specialized support 116 in data plane may prove challenging. BFD already has many 117 implementations based on HW that are capable of supporting multiple 118 sub-second sessions concurrently. 120 3. Applicability of p2mp BFD 122 [RFC8562] may provide an efficient and scalable solution for fast- 123 converging environment that uses the default route rather than 124 dynamic routing. Each redundancy group presents itself as a p2mp BFD 125 session with its Master being the root and Backup routers being tails 126 of the p2mp BFD session. Figure 1 displays the extension of VRRP 127 [RFC5798] to bootstrap tail of the p2mp BFD session. Master 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 | Master Discriminator | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 151 where new fields are interpreted as: 153 B(FD) - a one-bit flag that indicates that the Master 154 Discriminator field is appended to VRRP packet defined in 155 [RFC5798]; 157 Master Discriminator - My Discriminator value allocated by the 158 root of the p2mp BFD session. 160 The Master router that is configured to use p2mp BFD to support 161 faster convergence of VRRP starts transmitting BFD control packets 162 with VRID as a source IP address and My Discriminator. The same 163 value of My Discriminator MUST be set as the value of the Master 164 Discriminator field. The BFD flag MUST be set in the VRRP packet. 165 Backup router demultiplexes p2mp BFD test sessions based on VRID that 166 it been configured with and the My Discriminator value it learns from 167 the received VRRP packet. When a Backup router detects the failure 168 of the Master router it re-evaluates its role in the VRID. As a 169 result, the Backup router may become the Master router of the given 170 VRID or continue as a Backup router. If the former is the case, then 171 the new Master router MUST select My Discriminator and start 172 transmitting p2mp BFD control packets using Master IP address as the 173 source IP address for p2mp BFD control packets. If the latter is the 174 case, then the Backup router MUST wait for the VRRP packet from the 175 new VRRP Master router that will bootstrap the new p2mp BFD session. 177 3.1. Multipoint BFD Encapsulation 179 The MultipointHead of p2mp BFD session when transmitting BFD control 180 packet: 182 MUST set TTL value to 1 (though note that VRRP packets have TTL 183 set to 255); 185 SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 186 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address 188 MAY use network broadcast address for IPv4 or link-local all nodes 189 multicast group for IPv6 as destination IP address; 191 MUST set destination UDP port value to 3784 when transmitting BFD 192 control packets, as defined in [RFC8562]; 194 MUST use the Master IP address as the source IP address. 196 4. IANA Considerations 198 This document makes no requests for IANA allocations. This section 199 may be deleted by RFC Editor. 201 5. Security Considerations 203 Security considerations discussed in [RFC5798], [RFC5880], and 204 [RFC8562], apply to this document. 206 6. Acknowledgements 208 7. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, 212 DOI 10.17487/RFC2119, March 1997, 213 . 215 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 216 Version 3 for IPv4 and IPv6", RFC 5798, 217 DOI 10.17487/RFC5798, March 2010, 218 . 220 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 221 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 222 . 224 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 225 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 226 DOI 10.17487/RFC5881, June 2010, 227 . 229 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 230 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 231 June 2010, . 233 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 234 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 235 May 2017, . 237 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 238 Ed., "Bidirectional Forwarding Detection (BFD) for 239 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 240 April 2019, . 242 Authors' Addresses 244 Greg Mirsky 245 ZTE Corp. 247 Email: gregimirsky@gmail.com 249 Jeff Tantsura 250 Apstra 252 Email: jefftant.ietf@gmail.com 254 Gyan Mishra 255 Verizon Inc. 257 Email: gyan.s.mishra@verizon.com