idnits 2.17.1 draft-ietf-mpls-p2mp-bfd-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 : ---------------------------------------------------------------------------- == 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 (10 February 2022) is 803 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: 14 August 2022 Verizon Inc. 6 D. Eastlake 7 Futurewei Technologies 8 10 February 2022 10 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 11 draft-ietf-mpls-p2mp-bfd-01 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 14 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 (shown in Figure 1) MUST use Generic Associated Channel 197 (G-ACh) Label (GAL) (see [RFC5586]) at the bottom of the label stack 198 followed by an Associated Channel Header (ACH). If a BFD Control 199 packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used 200 in ACH, an implementation would not be able to verify the identity of 201 the MultipointHead and, as a result, will not properly demultiplex 202 BFD 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, as defined in Section 4.1 [RFC7212], 206 MUST immediately follow a BFD Control message. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | LSP Label | TC |S| TTL | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | GAL | TC |1| TTL | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |0 0 0 1|Version| Reserved | Channel Type = TBA1 | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ BFD Control Message ~ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type=0 | Reserved | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Reserved (16 bits) | Address Family (16 bits) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 ~ Address ~ 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1: VRRP Extension to Bootstrap P2MP BFD session 228 4. Bootstrapping Multipoint BFD 230 4.1. LSP Ping 232 LSP Ping is the part of the on-demand OAM toolset used to detect and 233 localize defects in the data plane and verify the control plane 234 against the data plane by ensuring that the LSP is mapped to the same 235 FEC at both egress and ingress endpoints. 237 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 238 MultipointTail. If LSP Ping is used, it MUST include the Target FEC 239 TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case 240 of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in 241 Section 3.1 [RFC6425]. For the case of p2mp SR policy with SR-MPLS 242 data plane, an implementation of this specification MUST follow 243 procedures defined in [RFC8287]. Setting the value of Reply Mode 244 field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap 245 MultipointTail of the p2mp BFD session is RECOMMENDED. Indeed, 246 because BFD over a multipoint network uses BFD Demand mode, the LSP 247 echo reply from a tail has no useful information to convey to the 248 head, unlike in the case of the BFD over a p2p MPLS LSP [RFC5884]. A 249 MultipointTail that receives an LSP Ping that includes the BFD 250 Discriminator TLV: 252 * MUST validate the LSP Ping; 254 * MUST associate the received BFD Discriminator value with the p2mp 255 LSP; 257 * MUST create a p2mp BFD session and set bfd.SessionType = 258 MultipointTail as described in [RFC8562]; 260 * MUST use the source IP address of LSP Ping, the value of BFD 261 Discriminator from the BFD Discriminator TLV, and the identity of 262 the p2mp LSP to properly demultiplex BFD sessions. 264 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 265 be used to verify the control plane against the data plane 266 periodically by checking that the p2mp LSP is mapped to the same FEC 267 at the MultipointHead and all active MultipointTails. The rate of 268 generation of these LSP Ping Echo request messages SHOULD be 269 significantly less than the rate of generation of the BFD Control 270 packets because LSP Ping requires more processing to validate the 271 consistency between the data plane and the control plane. An 272 implementation MAY provide configuration options to control the rate 273 of generation of the periodic LSP Ping Echo request messages. 275 4.2. Control Plane 277 The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint 278 BFD session on a tail. 280 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP 282 [RFC8562] defined how the BFD Demand mode can be used in multipoint 283 networks. When applied in MPLS, procedures specified in [RFC8562] 284 allow an egress LSR to detect a failure of the part of the MPLS p2mp 285 LSP from the ingress LSR. The ingress LSR is not aware of the state 286 of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562], 287 defined an "active tail" behavior. An active tail might notify the 288 head of the detected failure and responds to a poll sequence 289 initiated by the head. The first method, referred to as Head 290 Notification without Polling, is mentioned in Section 5.2.1 291 [RFC8563], is the simplest of all described in [RFC8563]. The use of 292 this method in BFD over MPLS p2mp LSP is discussed in this document. 293 Analysis of other methods of a head learning of the state of an MPLS 294 p2mp LSP is outside the scope of this document. 296 As specified in [RFC8563] for the active tail mode, BFD variables 297 MUST be as follows: 299 On an ingress LSR: 301 * bfd.SessionType is MultipointHead; 303 * bfd.RequiredMinRxInterval is set to nonzero, allowing egress LSRs 304 to send BFD Control packets. 306 On an egress LSR: 308 * bfd.SessionType is MultipointTail; 310 * bfd.SilentTail is set to zero. 312 In Section 5.2.1 [RFC8563] is noted that "the tail sends unsolicited 313 BFD packets in response to the detection of a multipoint path 314 failure" but without the specifics on the information in the packet 315 and frequency of transmissions. This document defines below the 316 procedure of an active tail with unsolicited notifications for p2mp 317 MPLS LSP. 319 Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends 320 BFD Control packet with the following settings: 322 * the Poll (P) bit is set; 324 * the Status (Sta) field set to Down value; 326 * the Diagnostic (Diag) field set to Control Detection Time Expired 327 value; 329 * the value of the Your Discriminator field is set to the value the 330 egress LSR has been using to demultiplex that BFD multipoint 331 session; 333 * BFD Control packet MAY be encapsulated in IP/UDP with the 334 destination IP address of the ingress LSR and the UDP destination 335 port number set to 4784 per [RFC5883]. If non-IP encapsulation is 336 used, then a BFD Control packet is encapsulated using PW-ACH 337 encapsulation (without IP/UDP Headers) (0x0007) [RFC5885]; 339 * these BFD Control packets are transmitted at the rate of one per 340 second until either it receives a control packet valid for this 341 BFD session with the Final (F) bit set from the ingress LSR or the 342 defect condition clears; however to improve the likelihood of 343 notifying the ingress LSR of the failure of the p2mp MPLS LSP, the 344 egress LSR SHOULD initially transmit three BFD Control packets 345 defined above in short succession. 347 An ingress LSR that has received the BFD Control packet, as described 348 above, sends the unicast IP/UDP encapsulated BFD Control packet with 349 the Final (F) bit set to the egress LSR. 351 6. Security Considerations 353 This document does not introduce new security aspects but inherits 354 all security considerations from [RFC5880], [RFC5884], [RFC7726], 355 [RFC8562], [RFC8029], and [RFC6425]. 357 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 358 section 4.1 [RFC4687] to avoid congestion in the control plane or the 359 data plane caused by the rate of generating BFD Control packets. An 360 operator SHOULD consider the amount of extra traffic generated by 361 p2mp BFD when selecting the interval at which the MultipointHead will 362 transmit BFD Control packets. The operator MAY consider the size of 363 the packet the MultipointHead transmits periodically as using IP/UDP 364 encapsulation, which adds up to 28 octets, more than 50% of the BFD 365 Control packet length, comparing to G-ACh encapsulation. 367 7. IANA Considerations 369 IANA is requested to allocate value (TBA1) from its MPLS Generalized 370 Associated Channel (G-ACh) Types registry. 372 +=======+========================+===============+ 373 | Value | Description | Reference | 374 +=======+========================+===============+ 375 | TBA1 | Multipoint BFD Session | This document | 376 +-------+------------------------+---------------+ 378 Table 1: Multipoint BFD Session G-ACh Type 380 8. Acknowledgements 382 The authors sincerely appreciate the comments received from Andrew 383 Malis, Italo Busi, Shraddha Hegde, and thought stimulating questions 384 from Carlos Pignataro. 386 9. References 388 9.1. Normative References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 396 "MPLS Generic Associated Channel", RFC 5586, 397 DOI 10.17487/RFC5586, June 2009, 398 . 400 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 401 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 402 . 404 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 405 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 406 June 2010, . 408 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 409 "Bidirectional Forwarding Detection (BFD) for MPLS Label 410 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 411 June 2010, . 413 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 414 Forwarding Detection (BFD) for the Pseudowire Virtual 415 Circuit Connectivity Verification (VCCV)", RFC 5885, 416 DOI 10.17487/RFC5885, June 2010, 417 . 419 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 420 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 421 Failures in Point-to-Multipoint MPLS - Extensions to LSP 422 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 423 . 425 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 426 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 427 RFC 6790, DOI 10.17487/RFC6790, November 2012, 428 . 430 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 431 Associated Channel (G-ACh) Advertisement Protocol", 432 RFC 7212, DOI 10.17487/RFC7212, June 2014, 433 . 435 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 436 Aldrin, "Clarifying Procedures for Establishing BFD 437 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 438 DOI 10.17487/RFC7726, January 2016, 439 . 441 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 442 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 443 Switched (MPLS) Data-Plane Failures", RFC 8029, 444 DOI 10.17487/RFC8029, March 2017, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 452 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 453 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 454 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 455 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 456 . 458 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 459 Ed., "Bidirectional Forwarding Detection (BFD) for 460 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 461 April 2019, . 463 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 464 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 465 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 466 . 468 9.2. Informative References 470 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 471 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 472 2006, . 474 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 475 "Operations and Management (OAM) Requirements for Point- 476 to-Multipoint MPLS Networks", RFC 4687, 477 DOI 10.17487/RFC4687, September 2006, 478 . 480 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 481 "Multicast VPN Fast Upstream Failover", RFC 9026, 482 DOI 10.17487/RFC9026, April 2021, 483 . 485 Authors' Addresses 487 Greg Mirsky 488 Ericsson 490 Email: gregimirsky@gmail.com 492 Gyan Mishra 493 Verizon Inc. 495 Email: gyan.s.mishra@verizon.com 497 Donald Eastlake, 3rd 498 Futurewei Technologies 499 2386 Panoramic Circle 500 Apopka, FL 32703 501 United States of America 503 Email: d3e3e3@gmail.com