idnits 2.17.1 draft-jain-l2vpn-evpn-lsp-ping-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances 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 (June 17, 2014) is 3599 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) == Unused Reference: 'RFC5085' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-07 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-06 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Parag Jain, Ed. 3 Internet Draft Sami Boutros 4 Intended status: Standards Track Samer Salam 5 Expires: December 18, 2014 Cisco Systems 7 June 17, 2014 9 LSP-Ping Mechanisms for E-VPN and PBB-EVPN 10 draft-jain-l2vpn-evpn-lsp-ping-03.txt 12 Abstract 14 LSP-Ping is a widely deployed Operation, Administration, and 15 Maintenance (OAM) mechanism in MPLS networks. This document 16 describes mechanisms for detecting data-plane failures using LSP 17 Ping in MPLS based E-VPN and PBB-EVPN networks. 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), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction 2 58 2. Conventions used in this document 3 59 3. Terminology 3 60 4. Proposed Target FEC Stack Sub-TLVs 4 61 4.1. E-VPN MAC Sub-TLV 4 62 4.2. E-VPN Inclusive Multicast Sub-TLV 5 63 4.3. E-VPN Auto-Discovery Sub-TLV 6 64 5. Operations 6 65 5.1. Unicast Data-plane connectivity checks 6 66 5.2. Inclusive Multicast Data-plane Connectivity Checks 8 67 5.2.1. Ingress Replication 8 68 5.2.2. Using P2MP P-tree 9 69 5.2.3. Controlling Echo Responses when using P2MP P-tree 10 70 5.3. E-VPN Aliasing Data-plane connectivity check 10 71 6. Security Considerations 10 72 7. IANA Considerations 10 73 8. References 11 74 8.1. Normative References 11 75 8.2. Informative References 11 76 9. Acknowledgments 12 78 1. Introduction 80 [EVPN] describes MPLS based Ethernet VPN (E-VPN) technology. An E- 81 VPN comprises CE(s) connected to PE(s). The PEs provide layer 2 E- 82 VPN among the CE(s) over the MPLS core infrastructure. In E-VPN 83 networks, PEs advertise the MAC addresses learned from the locally 84 connected CE(s), along with MPLS Label, to remote PE(s) in the 85 control plane using multi-protocol BGP. E-VPN enables multi-homing 86 of CE(s) connected to multiple PEs and load balancing of traffic to 87 and from multi-homed CE(s). 89 [PBBEVPN] describes the use of Provider Backbone Bridging [802.1ah] 90 with E-VPN. PBB-EVPN maintains the C-MAC learning in data plane and 91 only advertises Provider Backbone MAC (B-MAC) addresses in control 92 plane using BGP. 94 Procedures for simple and efficient mechanisms to detect data-plane 95 failures using LSP Ping in MPLS network are well defined in 96 [RFC4379][RFC6425]. This document defines procedures to detect data- 97 plane failures using LSP Ping in MPLS networks deploying E-VPN and 98 PBB-EVPN. This draft defines 3 new Sub-TLVs for Target FEC Stack TLV 99 with the purpose of identifying the FEC on the Peer PE. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC-2119 [RFC2119]. 107 The term FEC-Type is used to refer to a tuple consisting of . 110 3. Terminology 112 B-MAC: Backbone MAC Address 114 CE: Customer Edge Device 116 C-MAC: Customer MAC Address 118 DF: Designated Forwarder 120 ESI: Ethernet Segment Identifier 122 EVI: E-VPN Instance 124 E-VPN: Ethernet Virtual Private Network 126 MPLS-OAM: MPLS Operations, Administration and Maintenance 128 P2MP: Point-to-Multipoint 130 PBB: Provider Backbone Bridge 132 PE: Provider Edge Device 134 4. Proposed Target FEC Stack Sub-TLVs 136 This document introduces three new Target FEC Stack sub-TLVs that 137 are included in the LSP-Ping Echo Request packet sent for detecting 138 faults in data-plane connectivity in E-VPN and PBB-EVPN networks. 139 These Target FEC Stack sub-TLVs are described next. 141 4.1. E-VPN MAC Sub-TLV 143 The E-VPN MAC sub-TLV is used to identify the MAC for an EVI under 144 test at a peer PE. 146 The E-VPN MAC sub-TLV fields are derived from the MAC advertisement 147 route defined in [EVPN] and has the format as shown in Figure 1. 148 This TLV is included in the Echo Request sent to the Peer PE by the 149 PE that is the originator of the request. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Route Distinguisher | 155 | (8 octets) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Ethernet Segment Identifier | 158 | (10 octets) | 159 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | must be zero | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Ethernet Tag ID | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | MAC Address | 165 + (6 Octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | MAC Addr Len | IP Addr Len | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | IP Address (4 or 16 Octets) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | EVI | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: E-VPN MAC sub-TLV format 175 The LSP Ping echo request is sent using the E-VPN MPLS label(s) 176 associated with the MAC route announced by a remote PE and the MPLS 177 transport label(s) to reach the remote PE. 179 4.2. E-VPN Inclusive Multicast Sub-TLV 181 The E-VPN Inclusive Multicast sub-TLV fields are based on the E-VPN 182 Inclusive Multicast route defined in [EVPN]. 184 The E-VPN Inclusive Multicast sub-TLV has the format as shown in 185 Figure 2. This TLV is included in the echo request sent to the E-VPN 186 peer PE by the originator of request to verify the multicast 187 connectivity state on the peer PE(s) in E-VPN and PBB-EVPN. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Route Distinguisher | 193 | (8 octets) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Ethernet Segment Identifier | 196 | (10 octets) | 197 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | must be zero | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Ethernet Tag ID | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | EVI | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: E-VPN Inclusive Multicast sub-TLV format 207 Broadcast, multicast and unknown unicast traffic can be sent using 208 ingress replication or P2MP P-tree in E-VPN and PBB-EVPN network. In 209 case of ingress replication, the Echo Request is sent using a label 210 stack of to each remote 211 PE participating in E-VPN or PBB-EVPN. The inclusive multicast label 212 is the downstream assigned label announced by the remote PE to which 213 the Echo Request is being sent. The Inclusive Multicast label is the 214 inner label in the MPLS label stack. 216 When using P2MP P-tree in E-VPN or PBB-EVPN, the Echo Request is 217 sent using P2MP P-tree transport label for inclusive P-tree 218 arrangement or using a label stack of for aggregate 220 inclusive P2MP P-tree arrangement as described in Section 5. 222 In case of E-VPN, an additional, E-VPN Auto-Discovery sub-TLV and 223 ESI MPLS label as the bottom label, may also be included in the Echo 224 Request as is described in Section 5. 226 4.3. E-VPN Auto-Discovery Sub-TLV 228 The E-VPN Auto-Discovery (AD) sub-TLV fields are based on the 229 Ethernet AD route advertisement defined in [EVPN]. E-VPN AD sub-TLV 230 applies to only E-VPN. 232 The E-VPN AD sub-TLV has the format shown in Figure 3. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Route Distinguisher | 238 | (8 octets) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Ethernet Segment Identifier | 241 | (10 octets) | 242 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | must be zero | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Ethernet Tag ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | EVI | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: E-VPN Auto-Discovery sub-TLV format 252 5. Operations 254 5.1. Unicast Data-plane connectivity checks 256 Figure 4 is an example of a PBB-EVPN network. CE1 is dual-homed to 257 PE1 and PE2. Assume, PE1 announced a MAC route with RD 1.1.1.1:00 and 258 B-MAC 00aa.00bb.00cc and with MPLS label 16001 for EVI 10. Similarly 259 PE2 announced a MAC route with RD 2.2.2.2:00 and B-MAC 00aa.00bb.00cc 260 and with MPLS label 16002. 262 On PE3, when a operator performs a connectivity check for the B-MAC 263 address 00aa.00bb.00cc on PE1, the operator initiates an LSP Ping 264 request with the target FEC stack TLV containing E-VPN MAC sub-TLV in 265 the Echo Request packet. The Echo Request packet is sent with the 266 {Transport Label(s) to reach PE1 + E-VPN Label = 16001} MPLS label 267 stack. Once the echo request packet reaches PE1, it will process the 268 packet and perform checks for the E-VPN MAC sub-TLV present in the 269 Target FEC Stack TLV as described in Section 4.4 in [RFC4379] and 270 respond according to [RFC4379] processing rules. 272 BEB +-----------------+ BEB 273 || | | || 274 \/ | | \/ 275 +----+ AC1 +-----+ +-----+ +----+ 276 | CE1|------| | | PE 3|-----| CE2| 277 +----+\ | PE1 | IP/MPLS | | +----+ 278 \ +-----+ Network +-----+ 279 \ | | 280 AC2\ +-----+ | 281 \ | | | 282 \| PE2 | | 283 +-----+ | 284 /\ | | 285 || +-----------------+ 286 BEB 288 <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> 290 Figure 4: PBB EVPN network 292 Similarly, on PE3, when an operator performs a connectivity check for 293 the B-MAC address 00aa.00bb.00cc on PE2, the operator initiates an 294 LSP Ping request with the target FEC stack TLV containing E-VPN MAC 295 sub-TLV in the echo request packet. The echo request packet is sent 296 with the {MPLS transport Label(s) to reach PE2 + E-VPN Label = 16002} 297 MPLS label stack. 299 LSP Ping operation for unicast data-plane connectivity checks in E- 300 VPN, are similar to as described above for PBB-EVPN except that the 301 checks are for C-MACs and not for B-MACs. 303 5.2. Inclusive Multicast Data-plane Connectivity Checks 305 5.2.1. Ingress Replication 307 Assume PE1 announced an Inclusive Multicast route for EVI 10, with 308 RD 1.1.1.1:00, Ethernet Tag (ISID 10), PMSI tunnel attribute Tunnel 309 type set to ingress replication and downstream assigned inclusive 310 multicast MPLS label 17001. Similarly PE2 announced an Inclusive 311 Multicast route for EVI 10, with RD 2.2.2.2:00, Ethernet Tag (ISID 312 10), PMSI tunnel attribute Tunnel type set to ingress replication 313 and downstream assigned inclusive multicast MPLS label 17002. 315 Given CE1 is dual homed to PE1 and PE2, assume that PE1 is the DF 316 for ISID 10 for the port corresponding to the ESI 11aa.22bb.33cc. 317 44dd.5500. 319 When an operator at PE3 initiates a connectivity check for the 320 inclusive multicast on PE1, the operator initiates an LSP Ping 321 request with the target FEC stack TLV containing E-VPN Inclusive 322 Multicast sub-TLV in the Echo Request packet. The Echo Request 323 packet is sent with the {Transport Label(s) to reach PE1 + E-VPN 324 Incl. Multicast Label = 17001} MPLS label stack. Once the packet 325 reaches PE1, the packet will have E-VPN Inclusive multicast label. 326 PE1 will process the packet and perform checks for the E-VPN 327 Inclusive Multicast sub-TLV present in the Target FEC Stack TLV as 328 described in Section 4.4 in [RFC4379] and respond according to 329 [RFC4379] processing rules. 331 Operator at PE3, may similarly also initiate an LSP Ping to PE2 with 332 the target FEC stack TLV containing E-VPN Inclusive Multicast sub- 333 TLV in the echo request packet. The echo request packet is sent with 334 the {transport Label(s) to reach PE2 + E-VPN Incl. Multicast Label = 335 17002} MPLS label stack. Since PE2 is not the DF for ISID 10 for the 336 port corresponding to the ESI value in the Inclusive Multicast sub- 337 TLV in the Echo Request, PE2 will reply with special code indicating 338 that FEC exists on the router and the behavior is to drop the packet 339 because of not DF as described in Section 7. 341 In case of E-VPN, in the Echo Request packet, an Ethernet AD sub-TLV 342 and the associated MPLS Split Horizon Label at the bottom of the 343 MPLS label stack, may be added to emulate traffic coming from a MH 344 site, this label is used by leaf PE(s) attached to the same MH site 345 not to forward packets back to the MH site. If the behavior on a 346 leaf PE is to drop the packet because of Split Horizon filtering, 347 the PE2 will reply with special code indicating that FEC exists on 348 the router and the behavior is to drop the packet because of Split 349 Horizon Filtering as described in Section 7. 351 5.2.2. Using P2MP P-tree 353 Both inclusive P-Tree and aggregate inclusive P-tree can be used in 354 E-VPN or PBB-EVPN networks. 356 When using an inclusive P-tree arrangement, p2mp p-tree transport 357 label itself is used to identify the L2 service associated with the 358 Inclusive Multicast Route, this L2 service could be a customer 359 Bridge, or a Provider Backbone Bridge. 361 For an Inclusive P-tree arrangement, when an operator performs a 362 connectivity check for the multicast L2 service, the operator 363 initiates an LSP Ping request with the target FEC stack TLV 364 containing E-VPN Inclusive Multicast sub-TLV in the echo request 365 packet. The echo request packet is sent with the {P2MP P-tree label} 366 MPLS label stack. 368 When using Aggregate Inclusive P-tree, a PE announces an upstream 369 assigned MPLS label along with the P-tree ID, in that case both the 370 p2mp p-tree MPLS transport label and the upstream MPLS label can be 371 used to identify the L2 service. 373 For an Aggregate Inclusive P-tree arrangement, when an operator 374 performs a connectivity check for the multicast L2 service, the 375 operator initiates an LSP Ping request with the target FEC stack TLV 376 containing E-VPN Inclusive Multicast sub-TLV in the echo request 377 packet. The echo request packet is sent with the {P2MP P-tree label + 378 E-VPN Upstream assigned Multicast Label} MPLS label stack. 380 The Leaf PE(s) of the p2mp tree will process the packet and perform 381 checks for the E-VPN Inclusive Multicast sub-TLV present in the 382 Target FEC Stack TLV as described in Section 4.4 in [RFC4379] and 383 respond according to [RFC4379] processing rules. A PE that is not 384 the DF for the EVI on the ESI in the Inclusive Multicast sub-TLV, 385 will reply with a special code indicating that FEC exists on the 386 router and the behavior is to drop the packet because of not DF as 387 described in Section 7. 389 In case of E-VPN, in the Echo Request packet, an Ethernet AD sub-TLV 390 and the associated MPLS Split Horizon Label at the bottom of the 391 MPLS label stack, may be added to emulate traffic coming from a MH 392 site, this label is used by leaf PE(s) attached to the same MH site 393 not to forward packets back to the MH site. If the behavior on a 394 leaf PE is to drop the packet because of Split Horizon filtering, 395 the PE2 will reply with special code indicating that FEC exists on 396 the router and the behavior is to drop the packet because of Split 397 Horizon Filtering as described in Section 7. 399 5.2.3. Controlling Echo Responses when using P2MP P-tree 401 The procedures described in [RFC6425] for preventing congestion of 402 Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 403 single egress node (Node Address P2MP Responder Identifier TLV) can 404 be applied to LSP Ping in PBB EVPN and E-VPN when using P2MP P- 405 trees for broadcast, multicast and unknown unicast traffic. 407 5.3. E-VPN Aliasing Data-plane connectivity check 409 Assume PE1 announced an Ethernet Auto discovery Route with the ESI 410 set to CE1 system ID and MPLS label 19001, and PE2 an Ethernet Auto 411 discovery Route with the ESI set to CE1 system ID and MPLS label 412 19002. 414 When an operator performs at PE3 a connectivity check for the 415 aliasing aspect of the Ethernet AD route to PE1, the operator 416 initiates an LSP Ping request with the target FEC stack TLV 417 containing E-VPN Ethernet AD sub-TLV in the echo request packet. The 418 echo request packet is sent with the {Transport label(s) to reach 419 PE1 + E-VPN Ethernet AD Label 19001} MPLS label stack. 421 When PE1 receives the packet it will process the packet and perform 422 checks for the E-VPN Ethernet AD sub-TLV present in the Target FEC 423 Stack TLV as described in Section 4.4 in [RFC4379] and respond 424 according to [RFC4379] processing rules. 426 6. Security Considerations 428 The proposal introduced in this document does not introduce any new 429 security considerations beyond that already apply to [EVPN], [PBBE 430 VPN] and [RFC6425]. 432 7. IANA Considerations 434 This document defines 3 new sub-TLV type to be included in Target 435 FEC Stack TLV (TLV Type 1) [RFC4379] in LSP Ping. 437 IANA is requested to assign a sub-TLV type value to the following 438 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label 439 Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- 440 TLVs" sub-registry: 442 o E-VPN MAC route sub-TLV. 444 o E-VPN Inclusive Multicast route sub-TLV 446 o E-VPN Auto-Discovery Route sub-TLV 448 Proposed new Return Codes 450 [RFC4379] defines values for the Return Code field of Echo Reply. 451 This document proposes two new Return Codes, which SHOULD be 452 included in the Echo Reply message by a PE in response to LSP Ping 453 Echo Request message: 455 1. The FEC exists on the PE and the behavior is to drop the packet 456 because of not DF. 458 2. The FEC exists on the PE and the behavior is to drop the packet 459 because of Split Horizon Filtering. 461 8. References 463 8.1. Normative References 465 [EVPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft- 466 ietf-l2vpn-evpn-07.txt, work in progress, May 7, 2014. 468 [PBBEVPN] Sajassi et al., "PBB E-VPN", draft-ietf-l2vpn-pbb-evpn- 469 06.txt, work in progress, October 2013. 471 [RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 472 Switched (MPLS) Data Plane Failures", RFC 4379, February 473 2006. 475 [RFC6425] Saxena, S et al, Detecting Data Plane Failures in Point- 476 to-Multipoint Multiprotocol Label Switching (MPLS) - 477 Extensions to LSP. RFC 6425, November 2011. 479 8.2. Informative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC2119, March 1997. 484 [RFC5085] T. Nadeau, et. al, "Pseudowire Virtual Circuit 485 Connectivity Verification (VCCV): A Control Channel for 486 Pseudowires ", RFC 5085, December 2007. 488 [RFC6388] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., 489 "LDP Extensions for Point-to-Multipoint and Multipoint-to- 490 Multipoint Label Switched Paths, RFC 6388, November 2011. 492 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 493 "Extensions to Resource Reservation Protocol - Traffic 494 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 495 Switched Paths (LSPs)", RFC 4875, May 2007. 497 9. Acknowledgments 499 The authors would like to thank Patrice Brissette for his valuable 500 input and comments. 502 This document was prepared using 2-Word-v2.0.template.dot. 504 Authors' Addresses 506 Parag Jain 507 Cisco Systems, Inc., 508 2000 Innovation Drive, 509 Kanata, ON K2K3E8, Canada. 510 E-mail: paragj@cisco.com 512 Sami Boutros 513 Cisco Systems, Inc. 514 3750 Cisco Way, 515 San Jose, CA 95134, USA. 516 E-mail: sboutros@cisco.com 518 Samer Salam 519 Cisco Systems, Inc. 520 595 Burrard Street, Suite 2123, 521 Vancouver, BC V7X 1J1, Canada. 522 E-mail: ssalam@cisco.com