idnits 2.17.1 draft-ietf-pim-bfd-p2mp-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 -- The document date (November 30, 2020) is 1237 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 (-14) exists of draft-ietf-pim-dr-improvement-10 == Outdated reference: A later version (-05) exists of draft-mankamana-pim-bdr-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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 ZTE Corp. 4 Intended status: Standards Track J. Xiaoli 5 Expires: June 3, 2021 ZTE Corporation 6 November 30, 2020 8 Bidirectional Forwarding Detection (BFD) for Multi-point Networks and 9 Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case 10 draft-ietf-pim-bfd-p2mp-use-case-05 12 Abstract 14 This document discusses the use of Bidirectional Forwarding Detection 15 (BFD) for multi-point networks to provide nodes that participate in 16 Protocol Independent Multicast - Sparse Mode (PIM-SM) with the sub- 17 second convergence. Optional extension to PIM-SM Hello, as specified 18 in RFC 7761, to bootstrap point-to-multipoint BFD session. also 19 defined in this document. 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, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 . . . . . . . . . . . . 3 57 1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 4 61 3.1. Using P2MP BFD in PIM DR/BDR Monitoring . . . . . . . . . 4 62 3.2. P2MP BFD in PIM DR Load Balancing . . . . . . . . . . . . 5 63 3.3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Faster convergence in the control plane, in general, is beneficial 75 and allows minimizing periods of traffic blackholing, transient 76 routing loops, and other scenarios that may negatively affect service 77 data flow. That equally applies to unicast and multicast routing 78 protocols. 80 [RFC7761] is the current specification of the Protocol Independent 81 Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. 82 Confirming implementation of PIM-SM elects a Designated Router (DR) 83 on each PIM-SM interface. When a group of PIM-SM nodes is connected 84 to shared-media segment, e.g., Ethernet, the one elected as DR is to 85 act on behalf of directly connected hosts in the context of the PIM- 86 SM protocol. Failure of the DR impacts the quality of the multicast 87 services it provides to directly connected hosts because the default 88 failure detection interval for PIM-SM routers is 105 seconds. 89 Introduction of Backup DR (BDR), proposed in 90 [I-D.ietf-pim-dr-improvement], improves convergence time in the PIM- 91 SM over shared-media segment but still depends on long failure 92 detection interval. 94 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 95 originally defined to detect failure of point-to-point (p2p) paths - 96 single-hop [RFC5881], multihop [RFC5883]. In some PIM-SM 97 deployments, a p2p BFD can be used to detect a failure and enable 98 faster conversion. [RFC8562] extends the BFD base specification 99 [RFC5880] for multipoint and multicast networks, which precisely 100 characterizes deployment scenarios for PIM-SM over a LAN segment. 101 Among specific characteristics of p2mp BFD that are particularly 102 benefit PIM-SM over a LAN segment is a faster transition to the Up 103 state of the p2mp BFD session due to avoidance of the three-way 104 handshake required in p2p BFD [RFC5880]. Also, because the router 105 that transmits BFD Control messages uses the BFD Demand mode 106 [RFC5880] it maintains less BFD state comparing to the Asynchronous 107 mode. This document demonstrates how point-to-multipoint (p2mp) BFD 108 can enable faster detection of PIM-SM router failure and thus 109 minimize multicast service disruption. The document also defines the 110 extension to PIM-SM [RFC7761] and [I-D.ietf-pim-dr-improvement] to 111 bootstrap a PIM-SM router to join in p2mp BFD session over shared- 112 media link. 114 1.1. Conventions used in this document 116 1.1.1. Acronyms 118 BFD: Bidirectional Forwarding Detection 120 BDR: Backup Designated Router 122 DR: Designated Router 124 DRLB: Designated Router Load Balancing 126 DRLB-Cap: DRLB Capability Hello Option 128 DRLB-List: DRLB List Hello Option 130 GDR: Group Designated Router 132 p2mp: Point-to-Multipoint 134 p2p: Point-to-Point 136 PIM-SM: Protocol Independent Multicast - Sparse Mode 138 1.1.2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2. Problem Statement 148 [RFC7761] does not provide a method for fast, e.g., sub-second, 149 failure detection of a neighbor PIM-SM router. BFD already has many 150 implementations based on HW that are capable of supporting multiple 151 sub-second sessions concurrently. 153 3. Applicability of p2mp BFD 155 [RFC8562] may provide an efficient and scalable solution for the 156 fast-converging environment that demonstrates the head-tails 157 relationship. Each such group presents itself as p2mp BFD session 158 with its head being the root and other routers being tails of the 159 p2mp BFD session. Figure 1 displays the new optional BFD 160 Discriminator PIM Hello Option to bootstrap tail of the p2mp BFD 161 session. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | OptionType | OptionLength | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | My Discriminator | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: BFD Discriminator PIM Hello Option 173 where new fields are interpreted as: 175 OptionType is a value (TBA1) assigned by IANA Section 4 that 176 identifies the TLV as BFD Discriminator TLV; 178 OptionLength value is always 4 180 My Discriminator - My Discriminator value allocated by the root of 181 the p2mp BFD session. 183 3.1. Using P2MP BFD in PIM DR/BDR Monitoring 185 If PIM-SM routers that support this specification are configured to 186 use p2mp BFD for faster convergence, then the router to be monitored, 187 referred to as 'head', MUST create a BFD session of type 188 MultipointHead, as defined in [RFC8562]. Note that any PIM-SM router 189 that supports this specification, regardless of its role in PIM-SM, 190 MAY become a head of a p2mp BFD session. If the head doesn't support 191 [I-D.ietf-pim-dr-improvement], but, for example, uses procedures 192 defined in [I-D.mankamana-pim-bdr], then it MUST include BFD TLV in 193 its PIM-Hello message. If the head uses extensions defined in 195 [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its 196 Hello message. The DR Address TLV also MUST be included in the Hello 197 message. For a BDR, it is RECOMMENDED to include BFD TLV in its 198 Hello message. If BDR includes BFD TLV, then the BDR Address TLV 199 also MUST be present in the Hello message. As mentioned earlier, any 200 non-DR and non-BDR MAY include BFD TLV in its Hello message. Then 201 the head MUST begin periodic transmission of BFD Control packets. 202 The Source IP address of the BFD Control packet MUST be the same as 203 the source IP address of the PIM-Hello with BFD TLV messages being 204 transmitted by the head. My Discriminator's field value in the BFD 205 Control packet and My Discriminator field of the BFD TLV in PIM- 206 Hello, transmitted by the head, MUST be the same. When a PIM-SM 207 router is configured to monitor the head by using p2mp BFD, referred 208 to through this document as 'tail', receives PIM-Hello packet with 209 BFD TLV, the tail MAY create a p2mp BFD session of type 210 MultipointTail, as defined in [RFC8562]. 212 Because p2mp BFD doesn't use the three-way handshake and the head 213 transmits BFD Control packets with the value of Your Discriminator 214 field set to zero, [RFC8562] modified how a BFD system demultiplexes 215 received BFD Control packet. The tail demultiplexes p2mp BFD test 216 session based on head's source IP address, the My Discriminator value 217 it learned from BFD Discriminator TLV and the identity of the 218 multipoint path that the BFD Control packet was received from. The 219 Detection Time for p2mp BFD sessions is defined differently from the 220 definition provided in [RFC5880]. The Detection Time for each 221 MultipointTail session is calculated as the product of the last 222 received values of Desired Min TX Interval and Detect Mult. A tail 223 declares the BFD session down after the Detection Timer expires. If 224 the tail has detected MultipointHead failure, it MUST remove the 225 neighbor. If the failed head node was PIM-SM DR or BDR, the tail MAY 226 start DR Election process as specified in Section 4.3.2 [RFC7761] or 227 Section 4.1 [I-D.ietf-pim-dr-improvement] respectively. 229 If the head ceased to include BFD TLV in its PIM-Hello message, tails 230 MUST close the corresponding MultipointTail BFD session. Thus the 231 tail stops using BFD to monitor the head and reverts to the 232 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. 234 3.2. P2MP BFD in PIM DR Load Balancing 236 [RFC8775] defined the modification, Designated Router Load Balancing 237 (DRLB), to the PIM-SM protocol that allows for distribution of PIM-SM 238 DR responsibilities on a multi-access network segment. [RFC8775] 239 introduced the new PIM Hello options - Load Balancing Capability 240 (DRLB-Cap) and DR Load Balancing List (DRLB-List). PIM router that 241 includes DRLB-Cap Hello Option MAY include BFD Discriminator PIM 242 Hello Option (Figure 1). That router MUST create a BFD session and 243 set itself as MultipointHead [RFC8562]. The router MUST set 244 bfd.SessionState in the MultipointHead session to Down. If a PIM 245 router that includes BFD Discriminator Option in its Hello finds its 246 address in DRLB-List PIM Hello Option as Group Designated Router 247 (GDR) Candidate for the first time, the router MUST set 248 bfd.SessionState to Up and start periodically transmit BFD Control 249 messages. If the PIM router that was GDR Candidate doesn't find its 250 address in the most recent DRLB-List Option, the router MUST set 251 bfd.SessionState to Down and cease transmitting BFD Control messages. 252 For each GDR Candidate that includes BFD Discriminator Option in its 253 PIM Hello, PIM DR creates a MultipointTail session [RFC8562]. PIM DR 254 demultiplexes BFD sessions based on the value in My Discriminator 255 field and the source IP address. If PIM DR detects a failure of one 256 of the sessions, it MUST remove that router from the GDR Candidate 257 list and immediately transmit a new DRLB-List Option. 259 3.3. Multipoint BFD Encapsulation 261 The MultipointHead of p2mp BFD session when transmitting BFD Control 262 packet: 264 MUST set TTL value to 1; 266 SHOULD use group address ALL-PIM-ROUTERS ('224.0.0.13' for IPv4 267 and 'ff02::d' for IPv6) as destination IP address 269 MAY use network broadcast address for IPv4 or link-local all nodes 270 multicast group for IPv6 as the destination IP address; 272 MUST set destination UDP port value to 3784 when transmitting BFD 273 Control packets, as defined in [RFC8562]. 275 4. IANA Considerations 277 IANA is requested to allocate a new OptionType value from PIM Hello 278 Options registry according to: 280 +-------------+----------------+-------------------+---------------+ 281 | Value Name | Length Number | Name Protocol | Reference | 282 +-------------+----------------+-------------------+---------------+ 283 | TBA | 4 | BFD Discriminator | This document | 284 +-------------+----------------+-------------------+---------------+ 286 Table 1: BFD Discriminator option type 288 5. Security Considerations 290 Security considerations discussed in [RFC7761], [RFC5880], and 291 [RFC8562], and [I-D.ietf-pim-dr-improvement] apply to this document. 293 PIM-SM link-local messages can be authenticated using various 294 mechanisms, as described in Section 6.3 [RFC7761]. Authentication of 295 BFD Control messages defined in Section 6.7 [RFC5880]. Each protocol 296 MAY use authentication of its messages independently of the mode used 297 by the other protocol. 299 An implementation that supports this specification SHOULD use a 300 mechanism to control the maximum number of BFD sessions that can be 301 active at the same time. 303 6. Acknowledgments 305 Authors cannot say enough to express their appreciation of comments 306 and suggestions we received from Stig Venaas. 308 7. References 310 7.1. Normative References 312 [I-D.ietf-pim-dr-improvement] 313 Zhang, Z., hu, f., Xu, B., and M. Mishra, "Protocol 314 Independent Multicast - Sparse Mode (PIM-SM) Designated 315 Router (DR) Improvement", draft-ietf-pim-dr-improvement-10 316 (work in progress), September 2020. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, 320 DOI 10.17487/RFC2119, March 1997, 321 . 323 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 324 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 325 . 327 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 328 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 329 DOI 10.17487/RFC5881, June 2010, 330 . 332 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 333 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 334 June 2010, . 336 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 337 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 338 Multicast - Sparse Mode (PIM-SM): Protocol Specification 339 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 340 2016, . 342 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 343 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 344 May 2017, . 346 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 347 Ed., "Bidirectional Forwarding Detection (BFD) for 348 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 349 April 2019, . 351 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., 352 and A. Green, "PIM Designated Router Load Balancing", 353 RFC 8775, DOI 10.17487/RFC8775, April 2020, 354 . 356 7.2. Informative References 358 [I-D.mankamana-pim-bdr] 359 Mishra, M., Goh, J., and G. Mishra, "PIM Backup Designated 360 Router Procedure", draft-mankamana-pim-bdr-04 (work in 361 progress), April 2020. 363 Authors' Addresses 365 Greg Mirsky 366 ZTE Corp. 368 Email: gregimirsky@gmail.com 370 Ji Xiaoli 371 ZTE Corporation 372 No.50 Software Avenue, Yuhuatai District 373 Nanjing 374 China 376 Email: ji.xiaoli@zte.com.cn