idnits 2.17.1 draft-mirsky-mpls-p2mp-bfd-14.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 March 2021) is 1122 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track G. Mishra 5 Expires: 1 October 2021 Verizon Inc. 6 D. Eastlake 7 Futurewei Technologies 8 30 March 2021 10 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 11 draft-mirsky-mpls-p2mp-bfd-14 13 Abstract 15 This document describes procedures for using Bidirectional Forwarding 16 Detection (BFD) for multipoint networks to detect data plane failures 17 in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) 18 Label Switched Paths (LSPs) using active tails with unsolicited 19 notifications mode. It also describes the applicability of LSP Ping, 20 as in-band, and the control plane, as out-band, solutions to 21 bootstrap a BFD session in this environment. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 1 October 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 2 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3 61 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 3 62 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4 63 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 4 64 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.2. Operation of Multipoint BFD with Active Tail over P2MP MPLS 66 LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 [RFC8562] defines a method of using Bidirectional Detection (BFD) 79 [RFC5880] to monitor and detect unicast failures between the sender 80 (head) and one or more receivers (tails) in multipoint or multicast 81 networks. [RFC8562] added two BFD session types - MultipointHead and 82 MultipointTail. Throughout this document, MultipointHead and 83 MultipointTail refer to the value of the bfd.SessionType is set on a 84 BFD endpoint. This document describes procedures for using such 85 modes of BFD protocol to detect data plane failures in Multiprotocol 86 Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched 87 Paths (LSPs). The document also describes the applicability of out- 88 band solutions to bootstrap a BFD session in this environment. 90 2. Conventions used in this document 92 2.1. Terminology 94 MPLS: Multiprotocol Label Switching 96 LSP: Label Switched Path 97 BFD: Bidirectional Forwarding Detection 99 p2mp: Point-to-Multipoint 101 FEC: Forwarding Equivalence Class 103 G-ACh: Generic Associated Channel 105 ACH: Associated Channel Header 107 GAL: G-ACh Label 109 2.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Multipoint BFD Encapsulation 119 [RFC8562] uses BFD in the Demand mode from the very start of a point- 120 to-multipoint (p2mp) BFD session. Because the head doesn't receive 121 any BFD Control packet from a tail, the head of the p2mp BFD session 122 transmits all BFD Control packets with the value of Your 123 Discriminator field set to zero. As a result, a tail cannot 124 demultiplex BFD sessions using Your Discriminator, as defined in 125 [RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the 126 tail uses the source IP address, My Discriminator, and the identity 127 of the multipoint tree from which the BFD Control packet was 128 received. The p2mp MPLS LSP label MAY provide the identification of 129 the multipoint tree in case of an inclusive p-tree or upstream- 130 assigned label in case of aggregate p-tree. If the BFD Control 131 packet is encapsulated in IP/UDP, then the source IP address MUST be 132 used to demultiplex the received BFD Control packet as described in 133 Section 3.1. The non-IP encapsulation case is described in 134 Section 3.2. 136 3.1. IP Encapsulation of Multipoint BFD 138 [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp 139 MPLS LSP: 141 * UDP destination port MUST be set to 3784; 142 * destination IP address MUST be set to the loopback address 143 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 144 [RFC4291]. 146 This specification further clarifies that: 148 if multiple alternative paths for the given p2mp LSP Forwarding 149 Equivalence Class (FEC) exist, the MultipointHead SHOULD use 150 Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise 151 those particular alternative paths; 153 or the MultipointHead MAY use the UDP port number as discovered by 154 LSP Ping traceroute [RFC8029] as the source UDP port number to 155 possibly exercise those particular alternate paths. 157 3.2. Non-IP Encapsulation of Multipoint BFD 159 In some environments, the overhead of extra IP/UDP encapsulations may 160 be considered burdensome, making the use of more compact G-ACh 161 encapsulation attractive. Also, the validation of the IP/UDP 162 encapsulation of a BFD Control packet in a p2mp BFD session may fail 163 because of a problem related to neither the MPLS label stack nor to 164 BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP 165 improves the accuracy of the correlation of the detected failure and 166 defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over 167 p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL) 168 (see [RFC5586]) at the bottom of the label stack followed by an 169 Associated Channel Header (ACH). If a BFD Control packet in PW-ACH 170 encapsulation (without IP/UDP Headers) is to be used in ACH, an 171 implementation would not be able to verify the identity of the 172 MultipointHead and, as a result, will not properly demultiplex BFD 173 packets. Hence, a new channel type value is needed. The Channel 174 Type field in ACH MUST be set to TBA1 value Section 6. To provide 175 the identity of the MultipointHead for the particular multipoint BFD 176 session, a Source Address TLV [RFC7212] MUST immediately follow a BFD 177 Control message. 179 4. Bootstrapping Multipoint BFD 181 4.1. LSP Ping 183 LSP Ping is the part of the on-demand OAM toolset used to detect and 184 localize defects in the data plane and verify the control plane 185 against the data plane by ensuring that the LSP is mapped to the same 186 FEC at both egress and ingress endpoints. 188 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 189 MultipointTail. If LSP Ping used, it MUST include the Target FEC TLV 190 and the BFD Discriminator TLV defined in [RFC5884]. The Target FEC 191 TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425]. Setting the 192 value of Reply Mode field to "Do not reply" [RFC8029] for the LSP 193 Ping to bootstrap MultipointTail of the p2mp BFD session is 194 RECOMMENDED. Indeed, because BFD over a multipoint network uses BFD 195 Demand mode, the LSP echo reply from a tail has no useful information 196 to convey to the head, unlike in the case of the BFD over a p2p MPLS 197 LSP [RFC5884]. A MultipointTail that receives an LSP Ping that 198 includes the BFD Discriminator TLV: 200 * MUST validate the LSP Ping; 202 * MUST associate the received BFD Discriminator value with the p2mp 203 LSP; 205 * MUST create a p2mp BFD session and set bfd.SessionType = 206 MultipointTail as described in [RFC8562]; 208 * MUST use the source IP address of LSP Ping, the value of BFD 209 Discriminator from the BFD Discriminator TLV, and the identity of 210 the p2mp LSP to properly demultiplex BFD sessions. 212 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 213 be used to verify the control plane against the data plane 214 periodically by checking that the p2mp LSP is mapped to the same FEC 215 at the MultipointHead and all active MultipointTails. The rate of 216 generation of these LSP Ping Echo request messages SHOULD be 217 significantly less than the rate of generation of the BFD Control 218 packets because LSP Ping requires more processing to validate the 219 consistency between the data plane and the control plane. An 220 implementation MAY provide configuration options to control the rate 221 of generation of the periodic LSP Ping Echo request messages. 223 4.2. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP 225 [RFC8562] defined how the BFD Demand mode can be used in multipoint 226 networks. When applied in MPLS, procedures specified in [RFC8562] 227 allow an egress LSR to detect a failure of the part of the MPLS p2mp 228 LSP from the ingress LSR. The ingress LSR is not aware of the state 229 of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562], 230 defined an "active tail" behavior. An active tail might notify the 231 head of the detected failure and responds to a poll sequence 232 initiated by the head. The first method, referred to as Head 233 Notification without Polling, is mentioned in Section 5.2.1 234 [RFC8563], is the simplest of all described in [RFC8563]. The use of 235 this method in BFD over MPLS p2mp LSP is discussed in this document. 237 Analysis of other methods of a head learning of the state of an MPLS 238 p2mp LSP is outside the scope of this document. 240 As specified in [RFC8563] for the active tail mode, BFD variables 241 MUST be as follows: 243 On an ingress LSR: 245 * bfd.SessionType is MultipointHead; 247 * bfd.RequiredMinRxInterval is set to nonzero, allowing egress LSRs 248 to send BFD Control packets. 250 On an egress LSR: 252 * bfd.SessionType is MultipointTail; 254 * bfd.SilentTail is set to zero. 256 In Section 5.2.1 [RFC8563] is noted that "the tail sends unsolicited 257 BFD packets in response to the detection of a multipoint path 258 failure" but without the specifics on the information in the packet 259 and frequency of transmissions. This document defines below the 260 procedure of an active tail with unsolicited notifications for p2mp 261 MPLS LSP. 263 Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends 264 BFD Control packet with the following settings: 266 * the Poll (P) bit is set; 268 * the Status (Sta) field set to Down value; 270 * the Diagnostic (Diag) field set to Control Detection Time Expired 271 value; 273 * the value of the Your Discriminator field is set to the value the 274 egress LSR has been using to demultiplex that BFD multipoint 275 session; 277 * BFD Control packet is encapsulated in IP/UDP with the destination 278 IP address of the ingress LSR and the UDP destination port number 279 set to 4784 per [RFC5883] 281 * these BFD Control packets are transmitted at the rate of one per 282 second until either it receives a control packet valid for this 283 BFD session with the Final (F) bit set from the ingress LSR or the 284 defect condition clears; however to improve the likelihood of 285 notifying the ingress LSR of the failure of the p2mp MPLS LSP, the 286 egress LSR SHOULD initially transmit three BFD Control packets 287 defined above in short succession. 289 An ingress LSR that has received the BFD Control packet, as described 290 above, sends the unicast IP/UDP encapsulated BFD Control packet with 291 the Final (F) bit set to the egress LSR. 293 4.3. Control Plane 295 The BGP-BFD Attribute [I-D.ietf-bess-mvpn-fast-failover] MAY be used 296 to bootstrap multipoint BFD session on a tail. 298 5. Security Considerations 300 This document does not introduce new security aspects but inherits 301 all security considerations from [RFC5880], [RFC5884], [RFC7726], 302 [RFC8562], [RFC8029], and [RFC6425]. 304 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 305 section 4.1 [RFC4687] to avoid congestion in the control plane or the 306 data plane caused by the rate of generating BFD Control packets. An 307 operator SHOULD consider the amount of extra traffic generated by 308 p2mp BFD when selecting the interval at which the MultipointHead will 309 transmit BFD Control packets. The operator MAY consider the size of 310 the packet the MultipointHead transmits periodically as using IP/UDP 311 encapsulation, which adds up to 28 octets, more than 50% of the BFD 312 Control packet length, comparing to G-ACh encapsulation. 314 6. IANA Considerations 316 IANA is requested to allocate value (TBA1) from its MPLS Generalized 317 Associated Channel (G-ACh) Types registry. 319 +=======+========================+===============+ 320 | Value | Description | Reference | 321 +=======+========================+===============+ 322 | TBA1 | Multipoint BFD Session | This document | 323 +-------+------------------------+---------------+ 325 Table 1: Multipoint BFD Session G-ACh Type 327 7. Acknowledgements 329 The author sincerely appreciates the comments received from Andrew 330 Malis and thought stimulating questions from Carlos Pignataro. 332 8. References 333 8.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 341 "MPLS Generic Associated Channel", RFC 5586, 342 DOI 10.17487/RFC5586, June 2009, 343 . 345 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 346 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 347 . 349 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 350 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 351 June 2010, . 353 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 354 "Bidirectional Forwarding Detection (BFD) for MPLS Label 355 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 356 June 2010, . 358 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 359 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 360 Failures in Point-to-Multipoint MPLS - Extensions to LSP 361 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 362 . 364 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 365 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 366 RFC 6790, DOI 10.17487/RFC6790, November 2012, 367 . 369 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 370 Associated Channel (G-ACh) Advertisement Protocol", 371 RFC 7212, DOI 10.17487/RFC7212, June 2014, 372 . 374 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 375 Aldrin, "Clarifying Procedures for Establishing BFD 376 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 377 DOI 10.17487/RFC7726, January 2016, 378 . 380 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 381 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 382 Switched (MPLS) Data-Plane Failures", RFC 8029, 383 DOI 10.17487/RFC8029, March 2017, 384 . 386 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 387 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 388 May 2017, . 390 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 391 Ed., "Bidirectional Forwarding Detection (BFD) for 392 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 393 April 2019, . 395 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 396 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 397 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 398 . 400 8.2. Informative References 402 [I-D.ietf-bess-mvpn-fast-failover] 403 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast 404 Upstream Failover", Work in Progress, Internet-Draft, 405 draft-ietf-bess-mvpn-fast-failover-15, 21 January 2021, 406 . 409 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 410 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 411 2006, . 413 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 414 "Operations and Management (OAM) Requirements for Point- 415 to-Multipoint MPLS Networks", RFC 4687, 416 DOI 10.17487/RFC4687, September 2006, 417 . 419 Authors' Addresses 421 Greg Mirsky 422 ZTE Corp. 424 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 425 Gyan Mishra 426 Verizon Inc. 428 Email: gyan.s.mishra@verizon.com 430 Donald Eastlake, 3rd 431 Futurewei Technologies 432 2386 Panoramic Circle 433 Apopka, FL 32703 434 United States of America 436 Email: d3e3e3@gmail.com