idnits 2.17.1 draft-mirsky-mpls-p2mp-bfd-15.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 (19 September 2021) is 950 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 Ericsson 4 Intended status: Standards Track G. Mishra 5 Expires: 23 March 2022 Verizon Inc. 6 D. Eastlake 7 Futurewei Technologies 8 19 September 2021 10 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 11 draft-mirsky-mpls-p2mp-bfd-15 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) and Segment Routing (SR) point-to- 19 multipoint policies with SR-MPLS data plane. 21 It also describes the applicability of LSP Ping, as in-band, and the 22 control plane, as out-band, solutions to bootstrap a BFD session. 24 It also describes the behavior of the active tail for head 25 notification. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 23 March 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3 65 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4 66 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4 67 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 5 68 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS 71 LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 9.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 [RFC8562] defines a method of using Bidirectional Detection (BFD) 83 [RFC5880] to monitor and detect unicast failures between the sender 84 (head) and one or more receivers (tails) in multipoint or multicast 85 networks. 87 [RFC8562] added two BFD session types - MultipointHead and 88 MultipointTail. Throughout this document, MultipointHead and 89 MultipointTail refer to the value of the bfd.SessionType is set on a 90 BFD endpoint. 92 This document describes procedures for using such modes of BFD 93 protocol to detect data plane failures in Multiprotocol Label 94 Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths 95 (LSPs) and Segment Routing (SR) point-to-multipoint policies with SR- 96 MPLS data plane 97 The document also describes the applicability of out-band solutions 98 to bootstrap a BFD session in this environment. 100 It also describes the behavior of the active tail for head 101 notification. 103 2. Conventions used in this document 105 2.1. Terminology 107 MPLS: Multiprotocol Label Switching 109 LSP: Label Switched Path 111 BFD: Bidirectional Forwarding Detection 113 p2mp: Point-to-Multipoint 115 FEC: Forwarding Equivalence Class 117 G-ACh: Generic Associated Channel 119 ACH: Associated Channel Header 121 GAL: G-ACh Label 123 LSR: Label Switching Router 125 SR: Segment Routing 127 SR-MPLS: SR with MPLS data plane 129 2.2. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Multipoint BFD Encapsulation 139 [RFC8562] uses BFD in the Demand mode from the very start of a point- 140 to-multipoint (p2mp) BFD session. Because the head doesn't receive 141 any BFD Control packet from a tail, the head of the p2mp BFD session 142 transmits all BFD Control packets with the value of Your 143 Discriminator field set to zero. As a result, a tail cannot 144 demultiplex BFD sessions using Your Discriminator, as defined in 146 [RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the 147 tail uses the source IP address, My Discriminator, and the identity 148 of the multipoint tree from which the BFD Control packet was 149 received. If the BFD Control packet is encapsulated in IP/UDP, then 150 the source IP address MUST be used to demultiplex the received BFD 151 Control packet as described in Section 3.1. The non-IP encapsulation 152 case is described in Section 3.2. 154 3.1. IP Encapsulation of Multipoint BFD 156 [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp 157 MPLS LSP: 159 * UDP destination port MUST be set to 3784; 161 * destination IP address MUST be set to the loopback address 162 127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6 163 [RFC4291]. Note that that is different from how the destination 164 IP address selection is defined in Section 7 [RFC5884]. Firstly, 165 because only one loopback address ::1/128 is defined in IPv6. And 166 also, it is recommended to use the Entropy Label [RFC6790] to 167 discover multiple alternate paths in an MPLS network. Using a 168 single loopback address both for IPv4 and IPv6 encapsulation makes 169 it consistent and more straightforward for an implementation. 171 The Motivation section [RFC6790] lists several advantages of 172 generating the entropy value by an ingress Label Switching Router 173 (LSR) compared to when a transit LSR infers entropy using the 174 information in the MPLS label stack or payload. Thus this 175 specification further clarifies that: 177 if multiple alternative paths for the given p2mp LSP Forwarding 178 Equivalence Class (FEC) exist, the MultipointHead SHOULD use 179 Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise 180 those particular alternative paths; 182 or the MultipointHead MAY use the UDP port number as discovered by 183 LSP Ping traceroute [RFC8029] as the source UDP port number to 184 possibly exercise those particular alternate paths. 186 3.2. Non-IP Encapsulation of Multipoint BFD 188 In some environments, the overhead of extra IP/UDP encapsulations may 189 be considered burdensome, making the use of more compact G-ACh 190 encapsulation attractive. Also, the validation of the IP/UDP 191 encapsulation of a BFD Control packet in a p2mp BFD session may fail 192 because of a problem related to neither the MPLS label stack nor to 193 BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP 194 improves the accuracy of the correlation of the detected failure and 195 defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over 196 p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL) 197 (see [RFC5586]) at the bottom of the label stack followed by an 198 Associated Channel Header (ACH). If a BFD Control packet in PW-ACH 199 encapsulation (without IP/UDP Headers) is to be used in ACH, an 200 implementation would not be able to verify the identity of the 201 MultipointHead and, as a result, will not properly demultiplex BFD 202 packets. Hence, a new channel type value is needed. The Channel 203 Type field in ACH MUST be set to TBA1 value Section 7. To provide 204 the identity of the MultipointHead for the particular multipoint BFD 205 session, a Source Address TLV [RFC7212] MUST immediately follow a BFD 206 Control message. 208 4. Bootstrapping Multipoint BFD 210 4.1. LSP Ping 212 LSP Ping is the part of the on-demand OAM toolset used to detect and 213 localize defects in the data plane and verify the control plane 214 against the data plane by ensuring that the LSP is mapped to the same 215 FEC at both egress and ingress endpoints. 217 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 218 MultipointTail. If LSP Ping is used, it MUST include the Target FEC 219 TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case 220 of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in 221 Section 3.1 [RFC6425]. For the case of p2mp SR policy with SR-MPLS 222 data plane, an implementation of this specification MUST follow 223 procedures defined in [RFC8287]. Setting the value of Reply Mode 224 field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap 225 MultipointTail of the p2mp BFD session is RECOMMENDED. Indeed, 226 because BFD over a multipoint network uses BFD Demand mode, the LSP 227 echo reply from a tail has no useful information to convey to the 228 head, unlike in the case of the BFD over a p2p MPLS LSP [RFC5884]. A 229 MultipointTail that receives an LSP Ping that includes the BFD 230 Discriminator TLV: 232 * MUST validate the LSP Ping; 234 * MUST associate the received BFD Discriminator value with the p2mp 235 LSP; 237 * MUST create a p2mp BFD session and set bfd.SessionType = 238 MultipointTail as described in [RFC8562]; 240 * MUST use the source IP address of LSP Ping, the value of BFD 241 Discriminator from the BFD Discriminator TLV, and the identity of 242 the p2mp LSP to properly demultiplex BFD sessions. 244 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 245 be used to verify the control plane against the data plane 246 periodically by checking that the p2mp LSP is mapped to the same FEC 247 at the MultipointHead and all active MultipointTails. The rate of 248 generation of these LSP Ping Echo request messages SHOULD be 249 significantly less than the rate of generation of the BFD Control 250 packets because LSP Ping requires more processing to validate the 251 consistency between the data plane and the control plane. An 252 implementation MAY provide configuration options to control the rate 253 of generation of the periodic LSP Ping Echo request messages. 255 4.2. Control Plane 257 The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint 258 BFD session on a tail. 260 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP 262 [RFC8562] defined how the BFD Demand mode can be used in multipoint 263 networks. When applied in MPLS, procedures specified in [RFC8562] 264 allow an egress LSR to detect a failure of the part of the MPLS p2mp 265 LSP from the ingress LSR. The ingress LSR is not aware of the state 266 of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562], 267 defined an "active tail" behavior. An active tail might notify the 268 head of the detected failure and responds to a poll sequence 269 initiated by the head. The first method, referred to as Head 270 Notification without Polling, is mentioned in Section 5.2.1 271 [RFC8563], is the simplest of all described in [RFC8563]. The use of 272 this method in BFD over MPLS p2mp LSP is discussed in this document. 273 Analysis of other methods of a head learning of the state of an MPLS 274 p2mp LSP is outside the scope of this document. 276 As specified in [RFC8563] for the active tail mode, BFD variables 277 MUST be as follows: 279 On an ingress LSR: 281 * bfd.SessionType is MultipointHead; 283 * bfd.RequiredMinRxInterval is set to nonzero, allowing egress LSRs 284 to send BFD Control packets. 286 On an egress LSR: 288 * bfd.SessionType is MultipointTail; 290 * bfd.SilentTail is set to zero. 292 In Section 5.2.1 [RFC8563] is noted that "the tail sends unsolicited 293 BFD packets in response to the detection of a multipoint path 294 failure" but without the specifics on the information in the packet 295 and frequency of transmissions. This document defines below the 296 procedure of an active tail with unsolicited notifications for p2mp 297 MPLS LSP. 299 Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends 300 BFD Control packet with the following settings: 302 * the Poll (P) bit is set; 304 * the Status (Sta) field set to Down value; 306 * the Diagnostic (Diag) field set to Control Detection Time Expired 307 value; 309 * the value of the Your Discriminator field is set to the value the 310 egress LSR has been using to demultiplex that BFD multipoint 311 session; 313 * BFD Control packet MAY be encapsulated in IP/UDP with the 314 destination IP address of the ingress LSR and the UDP destination 315 port number set to 4784 per [RFC5883]. If non-IP encapsulation is 316 used, then a BFD Control packet is encapsulated using PW-ACH 317 encapsulation (without IP/UDP Headers) (0x0007) [RFC5885]; 319 * these BFD Control packets are transmitted at the rate of one per 320 second until either it receives a control packet valid for this 321 BFD session with the Final (F) bit set from the ingress LSR or the 322 defect condition clears; however to improve the likelihood of 323 notifying the ingress LSR of the failure of the p2mp MPLS LSP, the 324 egress LSR SHOULD initially transmit three BFD Control packets 325 defined above in short succession. 327 An ingress LSR that has received the BFD Control packet, as described 328 above, sends the unicast IP/UDP encapsulated BFD Control packet with 329 the Final (F) bit set to the egress LSR. 331 6. Security Considerations 333 This document does not introduce new security aspects but inherits 334 all security considerations from [RFC5880], [RFC5884], [RFC7726], 335 [RFC8562], [RFC8029], and [RFC6425]. 337 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 338 section 4.1 [RFC4687] to avoid congestion in the control plane or the 339 data plane caused by the rate of generating BFD Control packets. An 340 operator SHOULD consider the amount of extra traffic generated by 341 p2mp BFD when selecting the interval at which the MultipointHead will 342 transmit BFD Control packets. The operator MAY consider the size of 343 the packet the MultipointHead transmits periodically as using IP/UDP 344 encapsulation, which adds up to 28 octets, more than 50% of the BFD 345 Control packet length, comparing to G-ACh encapsulation. 347 7. IANA Considerations 349 IANA is requested to allocate value (TBA1) from its MPLS Generalized 350 Associated Channel (G-ACh) Types registry. 352 +=======+========================+===============+ 353 | Value | Description | Reference | 354 +=======+========================+===============+ 355 | TBA1 | Multipoint BFD Session | This document | 356 +-------+------------------------+---------------+ 358 Table 1: Multipoint BFD Session G-ACh Type 360 8. Acknowledgements 362 The authors sincerely appreciate the comments received from Andrew 363 Malis, Italo Busi, Shraddha Hegde, and thought stimulating questions 364 from Carlos Pignataro. 366 9. References 368 9.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 376 "MPLS Generic Associated Channel", RFC 5586, 377 DOI 10.17487/RFC5586, June 2009, 378 . 380 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 381 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 382 . 384 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 385 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 386 June 2010, . 388 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 389 "Bidirectional Forwarding Detection (BFD) for MPLS Label 390 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 391 June 2010, . 393 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 394 Forwarding Detection (BFD) for the Pseudowire Virtual 395 Circuit Connectivity Verification (VCCV)", RFC 5885, 396 DOI 10.17487/RFC5885, June 2010, 397 . 399 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 400 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 401 Failures in Point-to-Multipoint MPLS - Extensions to LSP 402 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 403 . 405 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 406 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 407 RFC 6790, DOI 10.17487/RFC6790, November 2012, 408 . 410 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 411 Associated Channel (G-ACh) Advertisement Protocol", 412 RFC 7212, DOI 10.17487/RFC7212, June 2014, 413 . 415 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 416 Aldrin, "Clarifying Procedures for Establishing BFD 417 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 418 DOI 10.17487/RFC7726, January 2016, 419 . 421 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 422 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 423 Switched (MPLS) Data-Plane Failures", RFC 8029, 424 DOI 10.17487/RFC8029, March 2017, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 432 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 433 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 434 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 435 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 436 . 438 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 439 Ed., "Bidirectional Forwarding Detection (BFD) for 440 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 441 April 2019, . 443 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 444 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 445 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 446 . 448 9.2. Informative References 450 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 451 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 452 2006, . 454 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 455 "Operations and Management (OAM) Requirements for Point- 456 to-Multipoint MPLS Networks", RFC 4687, 457 DOI 10.17487/RFC4687, September 2006, 458 . 460 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 461 "Multicast VPN Fast Upstream Failover", RFC 9026, 462 DOI 10.17487/RFC9026, April 2021, 463 . 465 Authors' Addresses 467 Greg Mirsky 468 Ericsson 470 Email: gregimirsky@gmail.com 472 Gyan Mishra 473 Verizon Inc. 475 Email: gyan.s.mishra@verizon.com 476 Donald Eastlake, 3rd 477 Futurewei Technologies 478 2386 Panoramic Circle 479 Apopka, FL 32703 480 United States of America 482 Email: d3e3e3@gmail.com