idnits 2.17.1 draft-ietf-pim-bfd-p2mp-use-case-04.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 (July 25, 2020) is 1364 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-09 == 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: January 26, 2021 ZTE Corporation 6 July 25, 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-04 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 January 26, 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. Terminology . . . . . . . . . . . . . . . . . . . . . 3 58 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 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]. [RFC8562] extends the BFD 97 base specification [RFC5880] for multipoint and multicast networks, 98 which precisely characterizes deployment scenarios for PIM-SM over 99 LAN segment. This document demonstrates how point-to-multipoint 100 (p2mp) BFD can enable faster detection of PIM-SM router failure and 101 thus minimize multicast service disruption. The document also 102 defines the extension to PIM-SM [RFC7761] and 103 [I-D.ietf-pim-dr-improvement] to bootstrap a PIM-SM router to join in 104 p2mp BFD session over shared-media link. 106 1.1. Conventions used in this document 108 1.1.1. Terminology 110 BFD: Bidirectional Forwarding Detection 112 BDR: Backup Designated Router 114 DR: Designated Router 116 DRLB: Designated Router Load Balancing 118 DRLB-Cap: DRLB Capability Hello Option 120 DRLB-List: DRLB List Hello Option 122 GDR: Group Designated Router 124 p2mp: Pont-to-Multipoint 126 PIM-SM: Protocol Independent Multicast - Sparse Mode 128 1.1.2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Problem Statement 138 [RFC7761] does not provide a method for fast, e.g., sub-second, 139 failure detection of a neighbor PIM-SM router. BFD already has many 140 implementations based on HW that are capable of supporting multiple 141 sub-second sessions concurrently. 143 3. Applicability of p2mp BFD 145 [RFC8562] may provide an efficient and scalable solution for the 146 fast-converging environment that demonstrates the head-tails 147 relationship. Each such group presents itself as p2mp BFD session 148 with its head being the root and other routers being tails of the 149 p2mp BFD session. Figure 1 displays the new optional BFD 150 Discriminator PIM Hello Option to bootstrap tail of the p2mp BFD 151 session. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | OptionType | OptionLength | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | My Discriminator | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: BFD Discriminator PIM Hello Option 163 where new fields are interpreted as: 165 OptionType is a value (TBA1) assigned by IANA Section 4 that 166 identifies the TLV as BFD Discriminator TLV; 168 OptionLength value is always 4 170 My Discriminator - My Discriminator value allocated by the root of 171 the p2mp BFD session. 173 3.1. Using P2MP BFD in PIM DR/BDR Monitoring 175 If PIM-SM routers that support this specification are configured to 176 use p2mp BFD for faster convergence, then the router to be monitored, 177 referred to as 'head', MUST create BFD session of type 178 MultipointHead, as defined in [RFC8562]. If the head doesn't support 179 [I-D.ietf-pim-dr-improvement], but, for example, uses procedures 180 defined in [I-D.mankamana-pim-bdr], then it MUST include BFD TLV in 181 its PIM-Hello message. If the head uses extensions defined in 182 [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its 183 Hello message. The DR Address TLV also MUST be included in the Hello 184 message. For a BDR it is RECOMMENDED to include BFD TLV in its Hello 185 message. If BDR includes BFD TLV, then the BDR Address TLV also MUST 186 be present in the Hello message. Then the head MUST begin periodic 187 transmission of BFD control packets. Source IP address of the BFD 188 control packet MUST be the same as the source IP address of the PIM- 189 Hello with BFD TLV messages being transmitted by the head. The 190 values of My Discriminator in the BFD control packet and My 191 Discriminator field of the BFD TLV in PIM-Hello, transmitted by the 192 head MUST be the same. When a PIM-SM router is configured to monitor 193 the head by using p2p BFD, referred to through this document as 194 'tail', receives PIM-Hello packet with BFD TLV it MAY create p2mp BFD 195 session of type MultipointTail, as defined in [RFC8562]. 197 Because p2mp BFD doesn't use the three-way handshake and the head 198 transmits BFD control packets with the value of Your Discriminator 199 field set to zero, [RFC8562] modified how a BFD system demultiplexes 200 received BFD control packet. The tail demultiplexes p2mp BFD test 201 session based on head's source IP address, the My Discriminator value 202 it learned from BFD Discriminator TLV and the identity of the 203 multipoint path that the BFD control packet was received from. The 204 Detection Time for p2mp BFD sessions is defined differently from the 205 definition provided in [RFC5880]. The Detection Time for each 206 MultipointTail session is calculated as the product of the last 207 received values of Desired Min TX Interval and Detect Mult. A tail 208 declares the BFD session down after the Detection Timer expires. If 209 the tail has detected MultipointHead failure, it MUST remove the 210 neighbor. If the failed head node was PIM-SM DR or BDR, the tail MAY 211 start DR Election process as specified in Section 4.3.2 [RFC7761] or 212 Section 4.1 [I-D.ietf-pim-dr-improvement] respectively. 214 If the head ceased to include BFD TLV in its PIM-Hello message, tails 215 MUST close the corresponding MultipointTail BFD session. Thus the 216 tail stops using BFD to monitor the head and reverts to the 217 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. 219 3.2. P2MP BFD in PIM DR Load Balancing 221 [RFC8775] defined the modification, Designated Router Load Balancing 222 (DRLB), to the PIM-SM protocol that allows for distribution of PIM-SM 223 DR responsibilities on a multi-access network segment. [RFC8775] 224 introduced the new PIM Hello options - Load Balancing Capability 225 (DRLB-Cap) and DR Load Balancing List (DRLB-List). PIM router that 226 includes DRLB-Cap Hello Option MAY include BFD Discriminator PIM 227 Hello Option (Figure 1). That router MUST create a BFD session and 228 set itself as MultipointHead [RFC8562]. The router MUST set 229 bfd.SessionState in the MultipointHead session to Down. If a PIM 230 router that includes BFD Discriminator Option in its Hello finds its 231 address in DRLB-List PIM Hello Option as Group Designated Router 232 (GDR) Candidate for the first time, the router MUST set 233 bfd.SessionState to Up and start periodically transmit BFD control 234 messages. If the PIM router that was GDR Candidate doesn't find its 235 address in the most recent DRLB-List Option, the router MUST set 236 bfd.SessionState to Down and cease transmitting BFD control messages. 237 For each GDR Candidate that includes BFD Discriminator Option in its 238 PIM Hello, PIM DR creates a MultipointTail session [RFC8562]. PIM DR 239 demultiplexes BFD sessions based on the value in My Discriminator 240 field and the source IP address. If PIM DR detects a failure of one 241 of the sessions, it MUST remove that router from the GDR Candidate 242 list and immediately transmit a new DRLB-List Option. 244 3.3. Multipoint BFD Encapsulation 246 The MultipointHead of p2mp BFD session when transmitting BFD control 247 packet: 249 MUST set TTL value to 1; 251 SHOULD use group address ALL-PIM-ROUTERS ('224.0.0.13' for IPv4 252 and 'ff02::d' for IPv6) as destination IP address 254 MAY use network broadcast address for IPv4 or link-local all nodes 255 multicast group for IPv6 as the destination IP address; 257 MUST set destination UDP port value to 3784 when transmitting BFD 258 control packets, as defined in [RFC8562]. 260 4. IANA Considerations 262 IANA is requested to allocate a new OptionType value from PIM Hello 263 Options registry according to: 265 +-------------+----------------+-------------------+---------------+ 266 | Value Name | Length Number | Name Protocol | Reference | 267 +-------------+----------------+-------------------+---------------+ 268 | TBA | 4 | BFD Discriminator | This document | 269 +-------------+----------------+-------------------+---------------+ 271 Table 1: BFD Discriminator option type 273 5. Security Considerations 275 Security considerations discussed in [RFC7761], [RFC5880], and 276 [RFC8562], and [I-D.ietf-pim-dr-improvement] apply to this document. 278 An implementation that supports this specification SHOULD use a 279 mechanism to control the maximum number of BFD sessions that can be 280 active at the same time. 282 6. Acknowledgments 284 Authors cannot say enough to express their appreciation of comments 285 and suggestions we received from Stig Venaas. 287 7. References 289 7.1. Normative References 291 [I-D.ietf-pim-dr-improvement] 292 Zhang, Z., hu, f., Xu, B., and m. mishra, "PIM DR 293 Improvement", draft-ietf-pim-dr-improvement-09 (work in 294 progress), October 2019. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 302 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 303 . 305 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 306 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 307 DOI 10.17487/RFC5881, June 2010, 308 . 310 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 311 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 312 June 2010, . 314 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 315 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 316 Multicast - Sparse Mode (PIM-SM): Protocol Specification 317 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 318 2016, . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 325 Ed., "Bidirectional Forwarding Detection (BFD) for 326 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 327 April 2019, . 329 [RFC8775] Cai, Y., Ou, H., Vallepalli, S., Mishra, M., Venaas, S., 330 and A. Green, "PIM Designated Router Load Balancing", 331 RFC 8775, DOI 10.17487/RFC8775, April 2020, 332 . 334 7.2. Informative References 336 [I-D.mankamana-pim-bdr] 337 mishra, m., Goh, J., and G. Mishra, "PIM Backup Designated 338 Router Procedure", draft-mankamana-pim-bdr-04 (work in 339 progress), April 2020. 341 Authors' Addresses 343 Greg Mirsky 344 ZTE Corp. 346 Email: gregimirsky@gmail.com 348 Ji Xiaoli 349 ZTE Corporation 350 No.50 Software Avenue, Yuhuatai District 351 Nanjing 352 China 354 Email: ji.xiaoli@zte.com.cn