idnits 2.17.1 draft-mirsky-mpls-p2mp-bfd-09.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 (April 14, 2020) is 1473 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 (-15) exists of draft-ietf-bess-mvpn-fast-failover-10 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 April 14, 2020 5 Expires: October 16, 2020 7 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 8 draft-mirsky-mpls-p2mp-bfd-09 10 Abstract 12 This document describes procedures for using Bidirectional Forwarding 13 Detection (BFD) for multipoint networks to detect data plane failures 14 in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) 15 Label Switched Paths (LSPs). It also describes the applicability of 16 LSP Ping, as in-band, and the control plane, as out-band, solutions 17 to bootstrap a BFD session in this environment. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 16, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 2 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3 58 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 3 59 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4 60 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 4 61 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC8562] defines a method of using Bidirectional Detection (BFD) 74 [RFC5880] to monitor and detect unicast failures between the sender 75 (head) and one or more receivers (tails) in multipoint or multicast 76 networks. This document describes procedures for using such mode of 77 BFD protocol to detect data plane failures in Multiprotocol Label 78 Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths 79 (LSPs). The document also describes the applicability of out-band 80 solutions to bootstrap a BFD session in this environment. 82 2. Conventions used in this document 84 2.1. Terminology 86 MPLS: Multiprotocol Label Switching 88 LSP: Label Switched Path 90 BFD: Bidirectional Forwarding Detection 92 p2mp: Point-to-Multipoint 94 FEC: Forwarding Equivalence Class 95 G-ACh: Generic Associated Channel 97 ACH: Associated Channel Header 99 GAL: G-ACh Label 101 2.2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Multipoint BFD Encapsulation 111 [RFC8562] uses BFD in the Demand mode from the very start of a point- 112 to-multipoint (p2mp) BFD session. Because the head doesn't receive 113 any BFD control packet from a tail, the head of the p2mp BFD session 114 transmits all BFD control packets with the value of Your 115 Discriminator field set to zero. As a result, a tail cannot 116 demultiplex BFD sessions using Your Discriminator, as defined in 117 [RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the 118 tail uses the source IP address, My Discriminator, and the identity 119 of the multipoint tree from which the BFD control packet was 120 received. The p2mp MPLS LSP label MAY provide the identification of 121 the multipoint tree in case of inclusive p-tree or upstream assigned 122 label in case of aggregate p-tree. If the BFD control packet is 123 encapsulated in IP/UDP, then the source IP address MUST be used to 124 demultiplex the received BFD control packet as described in 125 Section 3.1. The non-IP encapsulation case is described in 126 Section 3.2. 128 3.1. IP Encapsulation of Multipoint BFD 130 [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp 131 MPLS LSP: 133 UDP destination port MUST be set to 3784; 135 destination IP address MUST be set to one of the loopback 136 addresses from 127/8 range for IPv4 or to one of IPv4-mapped IPv4 137 loopback addresses from ::ffff:127.0.0.0/104 range for IPv6.; 139 This specification further clarifies that: 141 if multiple alternative paths for the given p2mp LSP Forwarding 142 Equivalence Class (FEC) exist, the MultipointHead SHOULD use 143 Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise 144 that particular alternative path; 146 or the MultipointHead MAY use the UDP port number as discovered by 147 LSP Ping traceroute [RFC8029] as the source UDP port number to 148 possibly exercise that particular alternate path. 150 3.2. Non-IP Encapsulation of Multipoint BFD 152 In some environments, the overhead of extra IP/UDP encapsulations may 153 be considered as overburden thus making the use of more compact G-ACh 154 encapsulation attractive. Also, the validation of the IP/UDP 155 encapsulation of BFD control packet of p2mp BFD session may fail 156 because of a problem not related to neither MPLS label stack nor to 157 BFD. Avoiding unnecessary encapsulation of p2mp BFD over MPLS LSP 158 improves the accuracy of the correlation of the detected failure and 159 defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over 160 p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL) 161 (see [RFC5586]) at the bottom of the label stack followed by 162 Associated Channel Header (ACH). If BFD Control, PW-ACH 163 encapsulation (without IP/UDP Headers) channel to be used in ACH, an 164 implementation would not be able to verify the identity of the 165 MultipointHead and, as a result, will not properly demultiplex BFD 166 packets. Hence, a new channel type value is needed. The Channel 167 Type field in ACH MUST be set to TBA1 value Section 6. To provide 168 the identity of the MultipointHead for the particular multipoint BFD 169 session a Source Address TLV [RFC7212] MUST immediately follow a BFD 170 control message. 172 4. Bootstrapping Multipoint BFD 174 4.1. LSP Ping 176 LSP Ping is the part of on-demand OAM toolset to detect and localize 177 defects in the data plane, and verify the control plane against the 178 data plane by ensuring that the LSP is mapped to the same FEC, at the 179 egress, as the ingress. 181 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 182 MultipointTail. If the LSP Ping used, it MUST include the Target FEC 183 TLV and the BFD Discriminator TLV defined in [RFC5884]. The Target 184 FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425]. It is 185 RECOMMENDED setting the value of Reply Mode field to "Do not reply" 186 [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp 187 BFD session. A MaultipointTail that receives the LSP Ping that 188 includes the BFD Discriminator TLV: 190 o MUST validate the LSP Ping; 191 o MUST associate the received BFD Discriminator value with the p2mp 192 LSP; 194 o MUST create p2mp BFD session and set bfd.SessionType = 195 MultipointTail as described in [RFC8562]; 197 o MUST use the source IP address of LSP Ping, the value of BFD 198 Discriminator from the BFD Discriminator TLV, and the identity of 199 the p2mp LSP to properly demultiplex BFD sessions. 201 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 202 be used to verify the control plane against the data plane 203 periodically by checking that the p2mp LSP is mapped to the same FEC 204 at the MultipointHead and all active MultipointTails. The rate of 205 generation of these LSP Ping Echo request messages SHOULD be 206 significantly less than the rate of generation of the BFD Control 207 packets because LSP Ping requires more processing to validate the 208 consistency between the data plane and the control plane. An 209 implementation MAY provide configuration options to control the rate 210 of generation of the periodic LSP Ping Echo request messages. 212 4.2. Control Plane 214 BGP-BFD Attribute [I-D.ietf-bess-mvpn-fast-failover] MAY be used to 215 bootstrap multipoint BFD session on a tail. 217 5. Security Considerations 219 This document does not introduce new security aspects but inherits 220 all security considerations from [RFC5880], [RFC5884], [RFC7726], 221 [RFC8562], [RFC8029], and [RFC6425]. 223 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 224 section 4.1 [RFC4687] to avoid congestion in the control plane or the 225 data plane caused by the rate of generating BFD control packets. An 226 operator SHOULD consider the amount of extra traffic generated by 227 p2mp BFD when selecting the interval at which the MultipointHead will 228 transmit BFD control packets. Also, the operator MAY consider the 229 size of the packet the MultipointHead transmits periodically as using 230 IP/UDP encapsulation adds up to 28 octets, which is more than 50% of 231 BFD control packet length, comparing to G-ACh encapsulation. 233 6. IANA Considerations 235 IANA is requested to allocate value (TBA1) from its MPLS Generalized 236 Associated Channel (G-ACh) Types registry. 238 +-------+------------------------+---------------+ 239 | Value | Description | Reference | 240 +-------+------------------------+---------------+ 241 | TBA1 | Multipoint BFD Session | This document | 242 +-------+------------------------+---------------+ 244 Table 1: Multipoint BFD Session G-ACh Type 246 7. Acknowledgements 248 The author sincerely appreciates the comments received from Andrew 249 Malis. 251 8. References 253 8.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 261 "MPLS Generic Associated Channel", RFC 5586, 262 DOI 10.17487/RFC5586, June 2009, 263 . 265 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 266 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 267 . 269 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 270 "Bidirectional Forwarding Detection (BFD) for MPLS Label 271 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 272 June 2010, . 274 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 275 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 276 Failures in Point-to-Multipoint MPLS - Extensions to LSP 277 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 278 . 280 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 281 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 282 RFC 6790, DOI 10.17487/RFC6790, November 2012, 283 . 285 [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 286 Associated Channel (G-ACh) Advertisement Protocol", 287 RFC 7212, DOI 10.17487/RFC7212, June 2014, 288 . 290 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 291 Aldrin, "Clarifying Procedures for Establishing BFD 292 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 293 DOI 10.17487/RFC7726, January 2016, 294 . 296 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 297 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 298 Switched (MPLS) Data-Plane Failures", RFC 8029, 299 DOI 10.17487/RFC8029, March 2017, 300 . 302 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 303 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 304 May 2017, . 306 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 307 Ed., "Bidirectional Forwarding Detection (BFD) for 308 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 309 April 2019, . 311 8.2. Informative References 313 [I-D.ietf-bess-mvpn-fast-failover] 314 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 315 upstream failover", draft-ietf-bess-mvpn-fast-failover-10 316 (work in progress), February 2020. 318 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 319 "Operations and Management (OAM) Requirements for Point- 320 to-Multipoint MPLS Networks", RFC 4687, 321 DOI 10.17487/RFC4687, September 2006, 322 . 324 Author's Address 326 Greg Mirsky 327 ZTE Corp. 329 Email: gregimirsky@gmail.com