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