idnits 2.17.1 draft-mirsky-mpls-p2mp-bfd-05.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 19, 2018) is 1979 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-04 == Outdated reference: A later version (-19) exists of draft-ietf-bfd-multipoint-18 Summary: 0 errors (**), 0 flaws (~~), 3 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 19, 2018 5 Expires: May 23, 2019 7 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP 8 draft-mirsky-mpls-p2mp-bfd-05 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 out-band solutions to bootstrap a BFD session in this environment. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 23, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 2 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3 57 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 3 58 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4 59 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 4 60 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Source MEP ID IP Address Type . . . . . . . . . . . . . . 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 [I-D.ietf-bfd-multipoint] defines a method of using Bidirectional 74 Detection (BFD) [RFC5880] to monitor and detect unicast failures 75 between the sender (head) and one or more receivers (tails) in 76 multipoint or multicast networks. This document describes procedures 77 for using such mode of BFD protocol to detect data plane failures in 78 Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label 79 Switched Paths (LSPs). The document also describes the applicability 80 of out-band 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 96 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 [I-D.ietf-bfd-multipoint] defines how the tail of multipoint BFD 112 session demultiplexes received BFD control packet when Your 113 Discriminator is not set, i.e., equals zero. Because 114 [I-D.ietf-bfd-multipoint] uses BFD in Demand mode from the very start 115 of the p2mp BFD session, the head of BFD multipoint session transmits 116 all BFD control packets with Your Discriminator set to zero. As a 117 result, a tail cannot demultiplex BFD sessions using Your 118 Discriminator, as defined in [RFC5880]. [I-D.ietf-bfd-multipoint] 119 requires that to demultiplex BFD sessions the tail uses the source IP 120 address, My Discriminator and the identity of the multipoint tree 121 from which the Multipoint BFD Control packet was received. The 122 identification of the multipoint tree MAY be provided by the p2mp 123 MPLS LSP label in case of inclusive p-tree or upstream assigned label 124 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 [I-D.ietf-bfd-multipoint] defines IP/UDP encapsulation for multipoint 133 BFD over p2mp 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 IP address discovered by LSP 148 Ping traceroute [RFC8029] as the destination IP address 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. Non-IP encapsulation for multipoint BFD 156 over p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label 157 (GAL) [RFC5586] at the bottom of the label stack followed by 158 Associated Channel Header (ACH). Channel Type field in ACH MUST be 159 set to MPLS-TP CV value (0x0023) [RFC6428]. To provide the identity 160 of the MultipointHead for the particular multipoint BFD session this 161 document defines new Source MEP ID IP Address type (TBA1) in 162 Section 6.1. If the Length value is 4, then the Value field contains 163 an IPv4 address. If the Length value is 16, then the Value field 164 contains an IPv6 address. Any other value of the Length field MUST 165 be considered as an error, and the BFD control packet MUST be 166 discarded. 168 4. Bootstrapping Multipoint BFD 170 4.1. LSP Ping 172 LSP Ping is the part of on-demand OAM toolset to detect and localize 173 defects in the data plane, and verify the control plane against the 174 data plane by ensuring that the LSP is mapped to the same FEC, at the 175 egress, as the ingress. 177 LSP Ping, as defined in [RFC6425], MAY be used to bootstrap 178 MultipointTail. If the LSP Ping used, it MUST include the Target FEC 179 TLV and the BFD Discriminator TLV defined in [RFC5884]. The Target 180 FEC TLV MUST use sub-TLVs defined in Section 3.1 [RFC6425]. It is 181 RECOMMENDED setting the value of Reply Mode field to "Do not reply" 182 [RFC8029] for the LSP Ping to bootstrap MultipointTail of the p2mp 183 BFD session. A MaultipointTail that receives the LSP Ping that 184 includes the BFD Discriminator TLV: 186 o MUST validate the LSP Ping; 188 o MUST associate the received BFD Discriminator value with the p2mp 189 LSP; 191 o MUST create p2mp BFD session and set bfd.SessionType = 192 MultipointTail as described in [I-D.ietf-bfd-multipoint]; 194 o MUST use the source IP address of LSP Ping, the value of BFD 195 Discriminator from the BFD Discriminator TLV, and the identity of 196 the p2mp LSP to properly demultiplex BFD sessions. 198 Besides bootstrapping a BFD session over a p2mp LSP, LSP Ping SHOULD 199 be used to verify the control plane against the data plane 200 periodically by checking that the p2mp LSP is mapped to the same FEC 201 at the MultipointHead and all active MultipointTails. The rate of 202 generation of these LSP Ping Echo request messages SHOULD be 203 significantly less than the rate of generation of the BFD Control 204 packets because LSP Ping requires more processing to validate the 205 consistency between the data plane and the control plane. An 206 implementation MAY provide configuration options to control the rate 207 of generation of the periodic LSP Ping Echo request messages. 209 4.2. Control Plane 211 BGP-BFD Attribute [I-D.ietf-bess-mvpn-fast-failover] MAY be used to 212 bootstrap multipoint BFD session on a tail. 214 5. Security Considerations 216 This document does not introduce new security aspects but inherits 217 all security considerations from [RFC5880], [RFC5884], [RFC7726], 218 [I-D.ietf-bfd-multipoint], [RFC8029], and [RFC6425]. 220 Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in 221 section 4.1 [RFC4687] to avoid congestion in the control plane or the 222 data plane caused by the rate of generating BFD control packets. An 223 operator SHOULD consider the amount of extra traffic generated by 224 p2mp BFD when selecting the interval at which the MultipointHead will 225 transmit BFD control packets. Also, the operator MAY consider the 226 size of the packet the MultipointHead transmits periodically as using 227 IP/UDP encapsulation adds up to 28 octets, which is more than 50% of 228 BFD control packet length, comparing to G-ACh encapsulation. 230 6. IANA Considerations 232 6.1. Source MEP ID IP Address Type 234 IANA is required to allocate value (TBD) for the Source MEP ID IP 235 Address type from the "CC/CV MEP-ID TLV" registry which is under the 236 "Pseudowire Associated Channel Types" registry. 238 +-------+-------------+---------------+ 239 | Value | Description | Reference | 240 +-------+-------------+---------------+ 241 | TBA1 | IP Address | This document | 242 +-------+-------------+---------------+ 244 Table 1: Source MEP ID IP Address TLV 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 [I-D.ietf-bess-mvpn-fast-failover] 256 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 257 upstream failover", draft-ietf-bess-mvpn-fast-failover-04 258 (work in progress), November 2018. 260 [I-D.ietf-bfd-multipoint] 261 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for 262 Multipoint Networks", draft-ietf-bfd-multipoint-18 (work 263 in progress), June 2018. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 271 "MPLS Generic Associated Channel", RFC 5586, 272 DOI 10.17487/RFC5586, June 2009, 273 . 275 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 276 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 277 . 279 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 280 "Bidirectional Forwarding Detection (BFD) for MPLS Label 281 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 282 June 2010, . 284 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 285 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 286 Failures in Point-to-Multipoint MPLS - Extensions to LSP 287 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 288 . 290 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 291 "Proactive Connectivity Verification, Continuity Check, 292 and Remote Defect Indication for the MPLS Transport 293 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 294 . 296 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 297 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 298 RFC 6790, DOI 10.17487/RFC6790, November 2012, 299 . 301 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 302 Aldrin, "Clarifying Procedures for Establishing BFD 303 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 304 DOI 10.17487/RFC7726, January 2016, 305 . 307 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 308 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 309 Switched (MPLS) Data-Plane Failures", RFC 8029, 310 DOI 10.17487/RFC8029, March 2017, 311 . 313 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 314 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 315 May 2017, . 317 8.2. Informative References 319 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 320 "Operations and Management (OAM) Requirements for Point- 321 to-Multipoint MPLS Networks", RFC 4687, 322 DOI 10.17487/RFC4687, September 2006, 323 . 325 Author's Address 327 Greg Mirsky 328 ZTE Corp. 330 Email: gregimirsky@gmail.com