idnits 2.17.1 draft-mirsky-mpls-p2mp-bfd-08.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 (November 26, 2019) is 1610 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-08 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 November 26, 2019 5 Expires: May 29, 2020 7 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 8 draft-mirsky-mpls-p2mp-bfd-08 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 May 29, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Multipoint BFD over MPLS LSP Associated Channel Type . . 6 66 6.2. Source MEP ID IP Address Type . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [RFC8562] defines a method of using Bidirectional Detection (BFD) 76 [RFC5880] to monitor and detect unicast failures between the sender 77 (head) and one or more receivers (tails) in multipoint or multicast 78 networks. This document describes procedures for using such mode of 79 BFD protocol to detect data plane failures in Multiprotocol Label 80 Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths 81 (LSPs). The document also describes the applicability of out-band 82 solutions to bootstrap a BFD session in this environment. 84 2. Conventions used in this document 86 2.1. Terminology 88 MPLS: Multiprotocol Label Switching 90 LSP: Label Switched Path 92 BFD: Bidirectional Forwarding Detection 94 p2mp: Point-to-Multipoint 95 FEC: Forwarding Equivalence Class 97 G-ACh: Generic Associated Channel 99 ACH: Associated Channel Header 101 GAL: G-ACh Label 103 2.2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. Multipoint BFD Encapsulation 113 [RFC8562] uses BFD in the Demand mode from the very start of a point- 114 to-multipoint (p2mp) BFD session. Because the head doesn't receive 115 any BFD control packet from a tail, the head of the p2mp BFD session 116 transmits all BFD control packets with the value of Your 117 Discriminator field set to zero. As a result, a tail cannot 118 demultiplex BFD sessions using Your Discriminator, as defined in 119 [RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the 120 tail uses the source IP address, My Discriminator, and the identity 121 of the multipoint tree from which the BFD control packet was 122 received. The p2mp MPLS LSP label MAY provide the identification of 123 the multipoint tree in case of inclusive p-tree or upstream assigned 124 label in case of aggregate p-tree. If the BFD control packet is 125 encapsulated in IP/UDP, then the source IP address MUST be used to 126 demultiplex the received BFD control packet as described in 127 Section 3.1. The non-IP encapsulation case is described in 128 Section 3.2. 130 3.1. IP Encapsulation of Multipoint BFD 132 [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp 133 MPLS LSP: 135 UDP destination port MUST be set to 3784; 137 destination IP address MUST be from the 127/8 range for IPv4 and 138 from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6; 140 This specification further clarifies that: 142 if multiple alternative paths for the given p2mp LSP Forwarding 143 Equivalence Class (FEC) exist, the MultipointHead SHOULD use 144 Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise 145 that particular alternative path; 147 or the MultipointHead MAY use the UDP port number as discovered by 148 LSP Ping traceroute [RFC8029] as the source UDP port number to 149 possibly exercise that particular alternate path. 151 3.2. Non-IP Encapsulation of Multipoint BFD 153 In some environments, the overhead of extra IP/UDP encapsulations may 154 be considered as overburden and make using more compact G-ACh 155 encapsulation attractive. Also, the validation of the IP/UDP 156 encapsulation of BFD control packet of p2mp BFD session may fail 157 because of a problem not related to neither MPLS label stack nor to 158 BFD. Avoiding unnecessary encapsulation of p2mp BFD over MPLS LSP 159 improves the accuracy of correlation of the detected failure and 160 defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over 161 p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL) 162 (see [RFC5586]) at the bottom of the label stack followed by 163 Associated Channel Header (ACH). The Channel Type field in ACH MUST 164 be set to TBA1 value Section 6.1. To provide the identity of the 165 MultipointHead for the particular multipoint BFD session this 166 document defines the new Source MEP ID IP Address type (TBA2) in 167 Section 6.2. If the Length value is 4, then the Value field contains 168 an IPv4 address. If the Length value is 16, then the Value field 169 contains an IPv6 address. Any other value of the Length field MUST 170 be considered as an error, and the BFD control packet MUST be 171 discarded. 173 4. Bootstrapping Multipoint BFD 175 4.1. LSP Ping 177 LSP Ping is the part of on-demand OAM toolset to detect and localize 178 defects in the data plane, and verify the control plane against the 179 data plane by ensuring that the LSP is mapped to the same FEC, at the 180 egress, as the ingress. 182 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 183 MultipointTail. If the LSP Ping used, it MUST include the Target FEC 184 TLV and the BFD Discriminator TLV defined in [RFC5884]. The Target 185 FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425]. It is 186 RECOMMENDED setting the value of Reply Mode field to "Do not reply" 187 [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp 188 BFD session. A MaultipointTail that receives the LSP Ping that 189 includes the BFD Discriminator TLV: 191 o MUST validate the LSP Ping; 193 o MUST associate the received BFD Discriminator value with the p2mp 194 LSP; 196 o MUST create p2mp BFD session and set bfd.SessionType = 197 MultipointTail as described in [RFC8562]; 199 o MUST use the source IP address of LSP Ping, the value of BFD 200 Discriminator from the BFD Discriminator TLV, and the identity of 201 the p2mp LSP to properly demultiplex BFD sessions. 203 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 204 be used to verify the control plane against the data plane 205 periodically by checking that the p2mp LSP is mapped to the same FEC 206 at the MultipointHead and all active MultipointTails. The rate of 207 generation of these LSP Ping Echo request messages SHOULD be 208 significantly less than the rate of generation of the BFD Control 209 packets because LSP Ping requires more processing to validate the 210 consistency between the data plane and the control plane. An 211 implementation MAY provide configuration options to control the rate 212 of generation of the periodic LSP Ping Echo request messages. 214 4.2. Control Plane 216 BGP-BFD Attribute [I-D.ietf-bess-mvpn-fast-failover] MAY be used to 217 bootstrap multipoint BFD session on a tail. 219 5. Security Considerations 221 This document does not introduce new security aspects but inherits 222 all security considerations from [RFC5880], [RFC5884], [RFC7726], 223 [RFC8562], [RFC8029], and [RFC6425]. 225 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 226 section 4.1 [RFC4687] to avoid congestion in the control plane or the 227 data plane caused by the rate of generating BFD control packets. An 228 operator SHOULD consider the amount of extra traffic generated by 229 p2mp BFD when selecting the interval at which the MultipointHead will 230 transmit BFD control packets. Also, the operator MAY consider the 231 size of the packet the MultipointHead transmits periodically as using 232 IP/UDP encapsulation adds up to 28 octets, which is more than 50% of 233 BFD control packet length, comparing to G-ACh encapsulation. 235 6. IANA Considerations 237 6.1. Multipoint BFD over MPLS LSP Associated Channel Type 239 IANA is requested to allocate value (TBA1) from its MPLS Generalized 240 Associated Channel (G-ACh) Types registry. 242 +-------+------------------------+---------------+ 243 | Value | Description | Reference | 244 +-------+------------------------+---------------+ 245 | TBA1 | Multipoint BFD Session | This document | 246 +-------+------------------------+---------------+ 248 Table 1: Multipoint BFD Session G-ACh Type 250 6.2. Source MEP ID IP Address Type 252 IANA is required to allocate value (TBA2) for the Source MEP ID IP 253 Address type from the "CC/CV MEP-ID TLV" registry which is under the 254 "MPLS Generalized Associated Channel (G-ACh) Types" registry. 256 +-------+-------------+---------------+ 257 | Value | Description | Reference | 258 +-------+-------------+---------------+ 259 | TBA2 | IP Address | This document | 260 +-------+-------------+---------------+ 262 Table 2: Source MEP ID IP Address TLV Type 264 7. Acknowledgements 266 The author sincerely appreciates the comments received from Andrew 267 Malis. 269 8. References 271 8.1. Normative References 273 [I-D.ietf-bess-mvpn-fast-failover] 274 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 275 upstream failover", draft-ietf-bess-mvpn-fast-failover-08 276 (work in progress), August 2019. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 284 "MPLS Generic Associated Channel", RFC 5586, 285 DOI 10.17487/RFC5586, June 2009, 286 . 288 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 289 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 290 . 292 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 293 "Bidirectional Forwarding Detection (BFD) for MPLS Label 294 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 295 June 2010, . 297 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 298 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 299 Failures in Point-to-Multipoint MPLS - Extensions to LSP 300 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 301 . 303 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 304 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 305 RFC 6790, DOI 10.17487/RFC6790, November 2012, 306 . 308 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 309 Aldrin, "Clarifying Procedures for Establishing BFD 310 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 311 DOI 10.17487/RFC7726, January 2016, 312 . 314 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 315 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 316 Switched (MPLS) Data-Plane Failures", RFC 8029, 317 DOI 10.17487/RFC8029, March 2017, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 325 Ed., "Bidirectional Forwarding Detection (BFD) for 326 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 327 April 2019, . 329 8.2. Informative References 331 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 332 "Operations and Management (OAM) Requirements for Point- 333 to-Multipoint MPLS Networks", RFC 4687, 334 DOI 10.17487/RFC4687, September 2006, 335 . 337 Author's Address 339 Greg Mirsky 340 ZTE Corp. 342 Email: gregimirsky@gmail.com