idnits 2.17.1 draft-ietf-pim-bfd-p2mp-use-case-09.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 -- The document date (7 October 2021) is 931 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Xiaoli 5 Expires: 10 April 2022 ZTE Corporation 6 7 October 2021 8 Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) 9 Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks 10 draft-ietf-pim-bfd-p2mp-use-case-09 12 Abstract 14 This document specifies how Bidirectional Forwarding Detection for 15 multipoint networks can provide sub-second failover for routers that 16 participate in Protocol Independent Multicast - Sparse Mode (PIM-SM). 17 An extension to the PIM Hello message used to bootstrap a point-to- 18 multipoint BFD session is also defined in this document. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 10 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. BFD Discriminator PIM Hello Option . . . . . . . . . . . . . 3 58 2.1. Using P2MP BFD in PIM Router Monitoring . . . . . . . . . 4 59 2.2. P2MP BFD in PIM DR Load Balancing . . . . . . . . . . . . 5 60 2.3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 5 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 6.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Faster convergence in the control plane minimizes the periods of 72 traffic blackholing, transient routing loops, and other situations 73 that may negatively affect service data flow. Faster convergence in 74 the control plane is beneficial to unicast and multicast routing 75 protocols. 77 [RFC7761] is the current specification of the Protocol Independent 78 Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. A 79 conforming implementation of PIM-SM elects a Designated Router (DR) 80 on each PIM-SM interface. When a group of PIM-SM nodes is connected 81 to a shared media segment, e.g., Ethernet, the node elected as DR 82 acts on behalf of directly connected hosts in the context of the PIM- 83 SM protocol. Failure of the DR impacts the quality of the multicast 84 services it provides to directly connected hosts because the default 85 failure detection interval for PIM-SM routers is 105 seconds. 87 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 88 originally defined to detect a failure of a point-to-point (p2p) 89 path, single-hop [RFC5881] or multihop [RFC5883]. In some PIM-SM 90 deployments, a p2p BFD can be used to detect a failure and enable 91 faster failover. [RFC8562] extends the BFD base specification 92 [RFC5880] for multipoint and multicast networks, and it precisely 93 characterizes deployment scenarios for PIM-SM over a LAN segment. 94 Among specific characteristics of p2mp BFD that particularly benefit 95 PIM-SM over a LAN segment is a faster transition to the Up state of 96 the p2mp BFD session due to avoidance of the three-way handshake 97 required in p2p BFD [RFC5880]. Also, because the router that 98 transmits BFD Control messages uses the BFD Demand mode [RFC5880], it 99 maintains less BFD state than the Asynchronous mode. Point-to- 100 multipoint (p2mp) BFD can enable faster detection of PIM-SM router 101 failure and thus minimize multicast service disruption. The 102 monitored PIM-SM router acts as the head and other routers as tails 103 of a p2mp BFD session. This document defines the monitoring of a 104 PIM-SM router using p2mp BFD. The document also defines the 105 extension to PIM-SM [RFC7761] to bootstrap a PIM-SM router to join in 106 p2mp BFD session over shared media segment. 108 1.1. Conventions used in this document 110 1.1.1. Terminology 112 This document uses terminology defined in [RFC5880], [RFC8562], and 113 [RFC7761]. Familiarity with these specifications and the terminology 114 used is expected. 116 1.1.2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. BFD Discriminator PIM Hello Option 126 Figure 1 displays the new optional BFD Discriminator PIM Hello option 127 to bootstrap a tail of the p2mp BFD session. 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | OptionType | OptionLength | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | HeadDiscriminator | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: BFD Discriminator PIM Hello Option 138 where new fields are interpreted as: 140 OptionType: TBA. 142 OptionLength: MUST be set to 4. 144 HeadDiscriminator: equals the value of My Discriminator 145 ([RFC5880]) allocated by the head. 147 If the value of the OptionLength field is not equal to 4, the BFD 148 Discriminator PIM Hello option is considered malformed, and the 149 receiver MUST stop processing PIM Hello options. If the value of the 150 HeadDiscriminator field equals zero, then the BFD Discriminator PIM 151 Hello option MUST be considered invalid, and the receiver MUST ignore 152 it. The receiver SHOULD log a notification regarding the malformed 153 or invalid BFD Discriminator Hello option under the control of a 154 throttling logging mechanism. 156 2.1. Using P2MP BFD in PIM Router Monitoring 158 If the head is no longer serving the function that prompted it to be 159 monitored, then it MUST cease including the BFD Discriminator PIM 160 Hello option in its PIM-Hello message, and it SHOULD shut down the 161 BFD session following the procedures described in Section 5.9 162 [RFC8562]. 164 The head MUST create a BFD session of type MultipointHead [RFC8562]. 165 Note that any PIM-SM router, regardless of its role, MAY become a 166 head of a p2mp BFD session. To control the volume of BFD control 167 traffic on a shared media segment, an operator should carefully 168 select PIM-SM routers configured as a head of a p2mp BFD session. 169 The head MUST include the BFD Discriminator option in its Hello 170 messages, and it MUST include a 4-byte HeadDiscriminator with a value 171 other than zero. 173 If a PIM-SM router is configured to monitor the head by using p2mp 174 BFD, referred to through this document as 'tail', receives a PIM- 175 Hello packet with the BFD Discriminator PIM Hello option, the tail 176 MAY create a p2mp BFD session of type MultipointTail, as defined in 177 [RFC8562]. 179 The node that includes the BFD Discriminator PIM Hello option 180 transmits BFD Control packets periodically. For the tail to 181 correctly demultiplex BFD [RFC8562], the source address, and My 182 Discriminator values of the BFD packets MUST be the same as those of 183 the HeadDiscriminator in the PIM Hello message. If that is not the 184 case, the tail BFD node would not be able to monitor the state of the 185 PIM-SM node, that is, the head of the p2mp BFD session, though the 186 regular PIM-SM mechanisms remain fully operational. 188 If the tail detects a MultipointHead failure [RFC8562], it MUST 189 delete the corresponding neighbor state and follow procedures defined 190 in [RFC7761]. 192 If the head ceases to include the BFD Discriminator PIM Hello option 193 in its PIM-Hello message, tails SHOULD close the corresponding 194 MultipointTail BFD session without affecting the PIM state in any 195 way. Thus the tail stops using BFD to monitor the head and reverts 196 to the procedures defined in [RFC7761]. 198 2.2. P2MP BFD in PIM DR Load Balancing 200 [RFC8775] specifies the PIM Designated Router Load Balancing (DRLB) 201 functionality. Any PIM router that advertises the DRLB-Cap Hello 202 Option can become the head of a p2mp BFD session, as specified in 203 Section 2.1. The head router administratively sets the 204 bfd.SessionState to Up in the MultipointHead session [RFC8562] only 205 if it is a Group Designated Router (GDR) Candidate, as specified in 206 Sections 5.5 and 5.6 of [RFC8775]. If the router is no longer the 207 GDR, then it MUST shut down following the procedures described in 208 Section 5.9 [RFC8562]. For each GDR Candidate that includes BFD 209 Discriminator option in its PIM Hello, the PIM DR creates a 210 MultipointTail session [RFC8562]. PIM DR demultiplexes BFD sessions 211 based on the value of the My Discriminator field and the source IP 212 address. If PIM DR detects a failure of one of the sessions, it MUST 213 remove that router from the GDR Candidate list and immediately 214 transmit a new DRLB-List option. 216 2.3. Multipoint BFD Encapsulation 218 The MultipointHead of a p2mp BFD session when transmitting BFD 219 Control packets: 221 MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]); 223 MUST use the group address ALL-PIM-ROUTERS ('224.0.0.13' for IPv4 224 and 'ff02::d' for IPv6) as destination IP address 226 3. IANA Considerations 228 IANA is requested to allocate a new OptionType value from PIM-Hello 229 Options registry according to: 231 +=======+========+==========================+===============+ 232 | Value | Length | Name | Reference | 233 +=======+========+==========================+===============+ 234 | TBA | 4 | BFD Discriminator Option | This document | 235 +-------+--------+--------------------------+---------------+ 237 Table 1: BFD Discriminator option type 239 4. Security Considerations 241 This document defines a way to accelerate detecting a failure that 242 affects PIM functionality by using BFD. The operation of either 243 protocol is not changed. 245 The security considerations discussed in [RFC7761], [RFC5880], 246 [RFC8562], and [RFC8775] apply to this document. 248 5. Acknowledgments 250 The authors cannot say enough to express their appreciation of the 251 comments and suggestions we received from Stig Venaas. The authors 252 greatly appreciate the comments and suggestions by Alvaro Retana that 253 improved the clarity of the document. 255 6. References 257 6.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 265 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 266 . 268 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 269 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 270 DOI 10.17487/RFC5881, June 2010, 271 . 273 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 274 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 275 Multicast - Sparse Mode (PIM-SM): Protocol Specification 276 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 277 2016, . 279 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 280 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 281 May 2017, . 283 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 284 Ed., "Bidirectional Forwarding Detection (BFD) for 285 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 286 April 2019, . 288 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., 289 and A. Green, "PIM Designated Router Load Balancing", 290 RFC 8775, DOI 10.17487/RFC8775, April 2020, 291 . 293 6.2. Informative References 295 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 296 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 297 June 2010, . 299 Authors' Addresses 301 Greg Mirsky 302 Ericsson 304 Email: gregimirsky@gmail.com 306 Ji Xiaoli 307 ZTE Corporation 308 No.50 Software Avenue, Yuhuatai District 309 Nanjing, 310 China 312 Email: ji.xiaoli@zte.com.cn