idnits 2.17.1 draft-ietf-pim-bfd-p2mp-use-case-02.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, 2019) is 1736 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-07 == Outdated reference: A later version (-05) exists of draft-mankamana-pim-bdr-02 ** Downref: Normative reference to an Informational draft: draft-mankamana-pim-bdr (ref. 'I-D.mankamana-pim-bdr') Summary: 1 error (**), 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, 2020 ZTE Corporation 6 July 25, 2019 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-02 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, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 3 61 3.1. Multipoint BFD Encapsulation . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 Faster convergence in the control plane, in general, is beneficial 71 and allows minimizing periods of traffic blackholing, transient 72 routing loops, and other scenarios that may negatively affect service 73 data flow. That equally applies to unicast and multicast routing 74 protocols. 76 [RFC7761] is the current specification of the Protocol Independent 77 Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. 78 Confirming implementation of PIM-SM elects a Designated Router (DR) 79 on each PIM-SM interface. When a group of PIM-SM nodes is connected 80 to shared-media segment, e.g., Ethernet, the one elected as DR is to 81 act on behalf of directly connected hosts in the context of the PIM- 82 SM protocol. Failure of the DR impacts the quality of the multicast 83 services it provides to directly connected hosts because the default 84 failure detection interval for PIM-SM routers is 105 seconds. 85 Introduction of Backup DR (BDR), proposed in 86 [I-D.ietf-pim-dr-improvement], improves convergence time in the PIM- 87 SM over shared-media segment but still depends on long failure 88 detection interval. 90 Bidirectional Forwarding Detection (BFD) [RFC5880] had been 91 originally defined to detect failure of point-to-point (p2p) paths - 92 single-hop [RFC5881], multihop [RFC5883]. [RFC8562] extends the BFD 93 base specification [RFC5880] for multipoint and multicast networks, 94 which precisely characterizes deployment scenarios for PIM-SM over 95 LAN segment. This document demonstrates how point-to-multipoint 96 (p2mp) BFD can enable faster detection of PIM-SM router failure and 97 thus minimize multicast service disruption. The document also 98 defines the extension to PIM-SM [RFC7761] and 99 [I-D.ietf-pim-dr-improvement] to bootstrap a PIM-SM router to join in 100 p2mp BFD session over shared-media link. 102 1.1. Conventions used in this document 104 1.1.1. Terminology 106 BFD: Bidirectional Forwarding Detection 108 BDR: Backup Designated Router 110 DR: Designated Router 112 p2mp: Pont-to-Multipoint 114 PIM-SM: Protocol Independent Multicast - Sparse Mode 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. Problem Statement 126 [RFC7761] does not provide a method for fast, e.g., sub-second, 127 failure detection of a neighbor PIM-SM router. BFD already has many 128 implementations based on HW that are capable of supporting multiple 129 sub-second sessions concurrently. 131 3. Applicability of p2mp BFD 133 [RFC8562] may provide an efficient and scalable solution for the 134 fast-converging environment that demonstrates the head-tails 135 relationship. Each such group presents itself as p2mp BFD session 136 with its head being the root and other routers being tails of the 137 p2mp BFD session. Figure 1 displays the new optional BFD 138 Discriminator TLV to bootstrap tail of the p2mp BFD session. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | OptionType | OptionLength | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | My Discriminator | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: BFD Discriminator TLV to Bootstrap P2MP BFD session 150 where new fields are interpreted as: 152 OptionType is a value (TBA1) assigned by IANA Section 4 that 153 identifies the TLV as BFD Discriminator TLV; 155 OptionLength value is always 4 157 My Discriminator - My Discriminator value allocated by the root of 158 the p2mp BFD session. 160 If PIM-SM routers that support this specification are configured to 161 use p2mp BFD for faster convergence, then the router to be monitored, 162 referred to as 'head', MUST create BFD session of type 163 MultipointHead, as defined in [RFC8562]. If the head doesn't support 164 [I-D.ietf-pim-dr-improvement], but, for example, uses procedures 165 defined in [I-D.mankamana-pim-bdr], then it MUST include BFD TLV in 166 its PIM-Hello message. If the head uses extensions defined in 167 [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its 168 Hello message. The DR Address TLV also MUST be included in the Hello 169 message. For a BDR it is RECOMMENDED to include BFD TLV in its Hello 170 message. If BDR includes BFD TLV, then the BDR Address TLV also MUST 171 be present in the Hello message. Then the head MUST begin periodic 172 transmission of BFD control packets. Source IP address of the BFD 173 control packet MUST be the same as the source IP address of the PIM- 174 Hello with BFD TLV messages being transmitted by the head. The 175 values of My Discriminator in the BFD control packet and My 176 Discriminator field of the BFD TLV in PIM-Hello, transmitted by the 177 head MUST be the same. When a PIM-SM router is configured to monitor 178 the head by using p2p BFD, referred to through this document as 179 'tail', receives PIM-Hello packet with BFD TLV it MAY create p2mp BFD 180 session of type MultipointTail, as defined in [RFC8562]. 182 Because p2mp BFD doesn't use the three-way handshake and the head 183 transmits BFD control packets with the value of Your Discriminator 184 field set to zero, [RFC8562] modified how a BFD system demultiplexes 185 received BFD control packet. The tail demultiplexes p2mp BFD test 186 session based on head's source IP address, the My Discriminator value 187 it learned from BFD Discriminator TLV and the identity of the 188 multipoint path that the BFD control packet was received from. The 189 Detection Time for p2mp BFD sessions is defined differently from the 190 definition provided in [RFC5880]. The Detection Time for each 191 MultipointTail session is calculated as the product of the last 192 received values of Desired Min TX Interval and Detect Mult. A tail 193 declares the BFD session down after the Detection Timer expires. If 194 the tail has detected MultipointHead failure, it MUST remove the 195 neighbor. If the failed head node was PIM-SM DR or BDR, the tail MAY 196 start DR Election process as specified in Section 4.3.2 [RFC7761] or 197 Section 4.1 [I-D.ietf-pim-dr-improvement] respectively. 199 If the head ceased to include BFD TLV in its PIM-Hello message, tails 200 MUST close the corresponding MultipointTail BFD session. Thus the 201 tail stops using BFD to monitor the head and reverts to the 202 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. 204 3.1. Multipoint BFD Encapsulation 206 The MultipointHead of p2mp BFD session when transmitting BFD control 207 packet: 209 MUST set TTL value to 1; 211 SHOULD use group address ALL-PIM-ROUTERS ('224.0.0.13' for IPv4 212 and 'ff02::d' for IPv6) as destination IP address 214 MAY use network broadcast address for IPv4 or link-local all nodes 215 multicast group for IPv6 as the destination IP address; 217 MUST set destination UDP port value to 3784 when transmitting BFD 218 control packets, as defined in [RFC8562]. 220 4. IANA Considerations 222 IANA is requested to allocate a new OptionType value from PIM Hello 223 Options registry according to: 225 +-------------+----------------+-------------------+---------------+ 226 | Value Name | Length Number | Name Protocol | Reference | 227 +-------------+----------------+-------------------+---------------+ 228 | TBA | 4 | BFD Discriminator | This document | 229 +-------------+----------------+-------------------+---------------+ 231 Table 1: BFD Discriminator option type 233 5. Security Considerations 235 Security considerations discussed in [RFC7761], [RFC5880], and 236 [RFC8562], and [I-D.ietf-pim-dr-improvement] apply to this document. 238 An implementation that supports this specification SHOULD use a 239 mechanism to control the maximum number of BFD sessions that can be 240 active at the same time. 242 6. Acknowledgments 244 Authors cannot say enough to express their appreciation of comments 245 and suggestions we received from Stig Venaas. 247 7. Normative References 249 [I-D.ietf-pim-dr-improvement] 250 Zhang, Z., hu, f., Xu, B., and m. mishra, "PIM DR 251 Improvement", draft-ietf-pim-dr-improvement-07 (work in 252 progress), January 2019. 254 [I-D.mankamana-pim-bdr] 255 mishra, m., "PIM Backup Designated Router Procedure", 256 draft-mankamana-pim-bdr-02 (work in progress), April 2019. 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 264 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 265 . 267 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 268 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 269 DOI 10.17487/RFC5881, June 2010, 270 . 272 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 273 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 274 June 2010, . 276 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 277 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 278 Multicast - Sparse Mode (PIM-SM): Protocol Specification 279 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 280 2016, . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 287 Ed., "Bidirectional Forwarding Detection (BFD) for 288 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 289 April 2019, . 291 Authors' Addresses 293 Greg Mirsky 294 ZTE Corp. 296 Email: gregimirsky@gmail.com 298 Ji Xiaoli 299 ZTE Corporation 300 No.50 Software Avenue, Yuhuatai District 301 Nanjing 302 China 304 Email: ji.xiaoli@zte.com.cn