idnits 2.17.1 draft-ietf-pim-bfd-p2mp-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 RFC7761, but the abstract doesn't seem to directly say this. It does mention RFC7761 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2019) is 1747 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 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 Updates: 7761 (if approved) J. Xiaoli 5 Intended status: Standards Track ZTE Corporation 6 Expires: December 19, 2019 June 17, 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-01 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 December 19, 2019. 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 . . . . . . . . . . . . . . . . . . . 5 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], then it MUST include BFD TLV in its 165 PIM-Hello message. If the head uses extensions defined in 166 [I-D.ietf-pim-dr-improvement], then DR MUST include BFD TLV in its 167 Hello message after the DR Address TLV. For a BDR it is RECOMMENDED 168 to include BFD TLV in its Hello message. If BDR includes BFD TLV, 169 then it MUST be after the BDR Address TLV. Then the head MUST begin 170 periodic transmission of BFD control packets. Source IP address of 171 the BFD control packet MUST be the same as the source IP address of 172 the PIM-Hello with BFD TLV messages being transmitted by the head. 173 The values of My Discriminator in the BFD control packet and My 174 Discriminator field of the BFD TLV in PIM-Hello, transmitted by the 175 head MUST be the same. When a PIM-SM router is configured to monitor 176 the head by using p2p BFD, referred to through this document as 177 'tail', receives PIM-Hello packet with BFD TLV it MAY create p2mp BFD 178 session of type MultipointTail, as defined in [RFC8562]. 180 Because p2mp BFD doesn't use the three-way handshake and the head 181 transmits BFD control packets with the value of Your Discriminator 182 field set to zero, [RFC8562] modified how a BFD system demultiplexes 183 received BFD control packet. The tail demultiplexes p2mp BFD test 184 session based on head's source IP address, the My Discriminator value 185 it learned from BFD Discriminator TLV and the identity of the 186 multipoint path that the BFD control packet was received from. The 187 Detection Time for p2mp BFD sessions is defined differently from the 188 definition provided in [RFC5880]. The Detection Time for each 189 MultipointTail session is calculated as the product of the last 190 received values of Desired Min TX Interval and Detect Mult. A tail 191 declares the BFD session down after the Detection Timer expires. If 192 the tail has detected MultipointHead failure, it MUST remove the 193 neighbor. If the failed head node was PIM-SM DR or BDR, the tail MAY 194 start DR Election process as specified in Section 4.3.2 [RFC7761] or 195 Section 4.1 [I-D.ietf-pim-dr-improvement] respectively. 197 If the head ceased to include BFD TLV in its PIM-Hello message, tails 198 MUST close the corresponding MultipointTail BFD session. Thus the 199 tail stops using BFD to monitor the head and reverts to the 200 procedures defined in [RFC7761] and [I-D.ietf-pim-dr-improvement]. 202 3.1. Multipoint BFD Encapsulation 204 The MultipointHead of p2mp BFD session when transmitting BFD control 205 packet: 207 MUST set TTL value to 1; 209 SHOULD use group address ALL-PIM-ROUTERS ('224.0.0.13' for IPv4 210 and 'ff02::d' for IPv6) as destination IP address 212 MAY use network broadcast address for IPv4 or link-local all nodes 213 multicast group for IPv6 as the destination IP address; 215 MUST set destination UDP port value to 3784 when transmitting BFD 216 control packets, as defined in [RFC8562]. 218 4. IANA Considerations 220 IANA is requested to allocate a new OptionType value from PIM Hello 221 Options registry according to: 223 +-------------+----------------+-------------------+---------------+ 224 | Value Name | Length Number | Name Protocol | Reference | 225 +-------------+----------------+-------------------+---------------+ 226 | TBA | 4 | BFD Discriminator | This document | 227 +-------------+----------------+-------------------+---------------+ 229 Table 1: BFD Discriminator option type 231 5. Security Considerations 233 Security considerations discussed in [RFC7761], [RFC5880], and 234 [RFC8562], and [I-D.ietf-pim-dr-improvement] apply to this document. 236 An implementation that supports this specification SHOULD use a 237 mechanism to control the maximum number of BFD sessions that can be 238 active at the same time. 240 6. Acknowledgments 242 Authors cannot say enough to express their appreciation of comments 243 and suggestions we received from Stig Venaas. 245 7. Normative References 247 [I-D.ietf-pim-dr-improvement] 248 Zhang, Z., hu, f., Xu, B., and m. mishra, "PIM DR 249 Improvement", draft-ietf-pim-dr-improvement-07 (work in 250 progress), January 2019. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 258 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 259 . 261 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 262 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 263 DOI 10.17487/RFC5881, June 2010, 264 . 266 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 267 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 268 June 2010, . 270 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 271 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 272 Multicast - Sparse Mode (PIM-SM): Protocol Specification 273 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 274 2016, . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 281 Ed., "Bidirectional Forwarding Detection (BFD) for 282 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 283 April 2019, . 285 Authors' Addresses 287 Greg Mirsky 288 ZTE Corp. 290 Email: gregimirsky@gmail.com 292 Ji Xiaoli 293 ZTE Corporation 294 No.50 Software Avenue, Yuhuatai District 295 Nanjing 296 China 298 Email: ji.xiaoli@zte.com.cn