idnits 2.17.1 draft-mirsky-bfd-p2mp-vrrp-use-case-03.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 30, 2018) is 1973 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) == Outdated reference: A later version (-19) exists of draft-ietf-bfd-multipoint-18 Summary: 0 errors (**), 0 flaws (~~), 2 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 ZTE Corp. 4 Updates: 5798 (if approved) J. Tantsura 5 Intended status: Standards Track November 30, 2018 6 Expires: June 3, 2019 8 Bidirectional Forwarding Detection (BFD) for Multi-point Networks and 9 Virtual Router Redundancy Protocol (VRRP) Use Case 10 draft-mirsky-bfd-p2mp-vrrp-use-case-03 12 Abstract 14 This document discusses use of Bidirectional Forwarding Detection 15 (BFD) for multi-point networks to provide Virtual Router Redundancy 16 Protocol (VRRP) with sub-second Master convergence and defines the 17 extension to bootstrap point-to-multipoint BFD session. 19 This draft updates RFC 5798. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions used in this document . . . . . . . . . . . . 2 57 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 3 61 3.1. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The [RFC5798] is the current specification of the Virtual Router 71 Redundancy Protocol (VRRP) for IPv4 and IPv6 networks. VRRPv3 allows 72 for faster switchover to a Backup router. Using such capability with 73 software-based implementation of VRRP is may prove challenging. But 74 it still may be possible to deploy VRRP and provide sub-second 75 detection of Master router failure by Backup routers. 77 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 78 originally defined detect failure of point-to-point (p2p) paths: 79 single-hop [RFC5881], multihop [RFC5883]. Single-hop BFD may be used 80 to enable Backup routers to detect failure of the Master router 81 within 100 msec or faster. [I-D.nitish-vrrp-bfd] demonstrates how, 82 with some extensions to [RFC5798], that can be achieved. 84 [I-D.ietf-bfd-multipoint] extends [RFC5880] for multipoint and 85 multicast networks, which is precisely characterizes deployment 86 scenarios for VRRP over LAN segment. This document demonstrates how 87 point-to-multipoint (p2mp) BFD can enable faster detection of Master 88 failure and thus minimize service disruption in a VRRP domain. The 89 document also defines the extension to VRRP [RFC5798] to bootstrap a 90 VRRP Backup router to join in p2mp BFD session. 92 1.1. Conventions used in this document 93 1.1.1. Terminology 95 BFD: Bidirectional Forwarding Detection 97 p2mp: Pont-to-Multipoint 99 VRRP: Virtual Router Redundancy Protocol 101 1.1.2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Problem Statement 111 A router may be part of several Virtual Router Redundancy groups, as 112 Master in some and as Backup in others. Supporting sub-second mode 113 for VRRPv3 [RFC5798] for all these roles without specialized support 114 in data plane may prove to be very challenging. BFD already has many 115 implementations based on HW that are capable to support multiple sub- 116 second session concurrently. 118 3. Applicability of p2mp BFD 120 [I-D.ietf-bfd-multipoint] may provide the efficient and scaleable 121 solution for fast-converging environment that uses default route 122 rather than dynamic routing. Each redundancy group presents itself 123 as p2mp BFD session with its Master being the root and Backup routers 124 being tails of the p2mp BFD session. Figure 1 displays the extension 125 of VRRP [RFC5798] to bootstrap tail of the p2mp BFD session. Master 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |Rsvd |B| Max Adver Int | Checksum | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 + + 135 | IPvX Address(es) | 136 + + 137 + + 138 + + 139 + + 140 | | 141 + + 142 | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Master Discriminator | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 149 where new fields are interpreted as: 151 B(FD) - one bit flag that indicates that the Master Discriminator 152 field is appended to VRRP packet defined in [RFC5798]; 154 Master Discriminator - My Discriminator value allocated by the 155 root of the p2mp BFD session. 157 The Master router that is configured to use p2mp BFD to support 158 faster convergence of VRRP starts transmitting BFD control packets 159 with VRID as source IP address and My Discriminator. The same value 160 of My Discriminator MUST be set as value of Master Discriminator 161 field and BFD flag MUST be set in the VRRP packet. Backup router 162 demultiplexes p2mp BFD test sessions based on VRID that it been 163 configured with and the My Discriminator value it learns from the 164 received VRRP packet. When a Backup router detects failure of the 165 Master router it re-evaluates its role in the VRID. As result, the 166 Backup router may become the Master router of the given VRID or 167 continue as a Backup router. If the former is the case, then the new 168 Master router MUST select My Discriminator and start transmitting 169 p2mp BFD control packets using Master IP address as source IP address 170 for p2mp BFD control packets. If the latter is the case, then the 171 Backup router MUST wait for VRRP packet from the new VRRP Master 172 router that will bootstrap new p2mp BFD session. 174 3.1. Multipoint BFD Encapsulation 176 The MultipointHead of p2mp BFD session when transmitting BFD control 177 packet: 179 MUST set TTL value to 1 (though note that VRRP packets have TTL 180 set to 255); 182 SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 183 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address 185 MAY use network broadcast address for IPv4 or link-local all nodes 186 multicast group for IPv6 as destination IP address; 188 MUST set destination UDP port value to 3784 when transmitting BFD 189 control packets, as defined in [I-D.ietf-bfd-multipoint]; 191 MUST use Master IP address as source IP address. 193 4. IANA Considerations 195 This document makes no requests for IANA allocations. This section 196 may be deleted by RFC Editor. 198 5. Security Considerations 200 Security considerations discussed in [RFC5798], [RFC5880], and 201 [I-D.ietf-bfd-multipoint], apply to this document. 203 6. Acknowledgements 205 7. Normative References 207 [I-D.ietf-bfd-multipoint] 208 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for 209 Multipoint Networks", draft-ietf-bfd-multipoint-18 (work 210 in progress), June 2018. 212 [I-D.nitish-vrrp-bfd] 213 Gupta, N., Dogra, A., Docherty, C., Mirsky, G., and J. 214 Tantsura, "Fast failure detection in VRRP with BFD", 215 draft-nitish-vrrp-bfd-04 (work in progress), August 2016. 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, 220 . 222 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 223 Version 3 for IPv4 and IPv6", RFC 5798, 224 DOI 10.17487/RFC5798, March 2010, 225 . 227 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 228 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 229 . 231 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 232 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 233 DOI 10.17487/RFC5881, June 2010, 234 . 236 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 237 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 238 June 2010, . 240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 242 May 2017, . 244 Authors' Addresses 246 Greg Mirsky 247 ZTE Corp. 249 Email: gregimirsky@gmail.com 251 Jeff Tantsura 253 Email: jefftant.ietf@gmail.com