idnits 2.17.1 draft-ietf-pals-p2mp-pw-lsp-ping-04.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 (July 3, 2017) is 2488 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 (-04) exists of draft-ietf-pals-p2mp-pw-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS Workgroup P. Jain, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Boutros 5 Expires: January 4, 2018 VMWare, Inc. 6 S. Aldrin 7 Google Inc. 8 July 3, 2017 10 Definition of P2MP PW TLV for LSP-Ping Mechanisms 11 draft-ietf-pals-p2mp-pw-lsp-ping-04 13 Abstract 15 LSP-Ping is a widely deployed Operation, Administration, and 16 Maintenance (OAM) mechanism in MPLS networks. This document 17 describes a mechanism to verify connectivity of Point-to-Multipoint 18 (P2MP) Pseudowires (PW) using LSP Ping. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Identifying a P2MP PW . . . . . . . . . . . . . . . . . . . . 4 58 4.1. P2MP Pseudowire Sub-TLV . . . . . . . . . . . . . . . . . 4 59 5. Encapsulation of OAM Ping Packets . . . . . . . . . . . . . . 5 60 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Controlling Echo Responses . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 11.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 73 attributes of a unidirectional P2MP Telecommunications service such 74 as P2MP ATM over Public Switched Network (PSN). Requirements for 75 P2MP PW are described in [RFC7338]. P2MP PWs are carried over P2MP 76 MPLS LSP. The Procedures for P2MP PW signaling using BGP are 77 described in [RFC7117] and LDP for single segment P2MP PWs are 78 described in [I-D.ietf-pals-p2mp-pw]. Many P2MP PWs can share the 79 same P2MP MPLS LSP and this arrangement is called Aggregate P2MP 80 Tree. An aggregate P2MP tree requires an upstream assigned label so 81 that on the tail of the P2MP LSP, the traffic can be associated with 82 a Virtual Private Network (VPN) or a Virtual Private LAN Service 83 (VPLS) instance. When a P2MP MPLS LSP carries only one VPN or VPLS 84 service instance, the arrangement is called Inclusive P2MP Tree. For 85 Inclusive P2MP Tree, P2MP MPLS LSP label itself can uniquely identify 86 the VPN or VPLS service being carried over P2MP MPLS LSP. The P2MP 87 MPLS LSP can also be used in Selective P2MP Tree arrangement for 88 carrying multicast traffic. In a Selective P2MP Tree arrangement, 89 traffic to each multicast group in a VPN or VPLS instance is carried 90 by a separate unique P2MP LSP. In Aggregate Selective P2MP Tree 91 arrangement, traffic to a set of multicast groups from different VPN 92 or VPLS instances is carried over the same shared P2MP LSP. 94 The P2MP MPLS LSP are setup either using P2MP RSVP-TE [RFC4875] or 95 Multipoint LDP (mDLP) [RFC6388]. Mechanisms for fault detection and 96 isolation for data plane failures for P2MP MPLS LSPs are specified in 98 [RFC6425]. This document describes a mechanism to detect data plane 99 failures for P2MP PW carried over P2MP MPLS LSPs. 101 This document defines a new P2MP Pseudowire sub-TLV for Target FEC 102 Stack for P2MP PW. The P2MP Pseudowire sub-TLV is added in Target 103 FEC Stack TLV by the originator of the Echo Request to inform the 104 receiver at P2MP MPLS LSP tail of the P2MP PW being tested. 106 Multi-segment Pseudowires support is out of scope of this document. 108 2. Specification of Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Terminology 116 ACH: Associated Channel Header 118 ATM: Asynchronous Transfer Mode 120 CE: Customer Edge 122 FEC: Forwarding Equivalence Class 124 GAL: Generic Associated Channel Label 126 LDP: Label Distribution Protocol 128 LSP: Label Switched Path 130 LSR: Label Switching Router 132 mLDP: Multipoint LDP 134 MPLS-OAM: MPLS Operations, Administration and Maintenance 136 P2MP: Point-to-Multipoint 138 P2MP-PW: Point-to-Multipoint PseudoWire 140 PE: Provider Edge 142 PSN: Public Switched Network 144 PW: PseudoWire 145 RSVP: Resource Reservation Protocol 147 TE: Traffic Engineering 149 TLV: Type Length Value 151 VPLS: Virtual Private LAN Service 153 4. Identifying a P2MP PW 155 This document introduces a new LSP Ping Target FEC Stack sub-TLV, 156 P2MP Pseudowire sub-TLV, to identify the P2MP PW under test at the 157 P2MP LSP Tail/Bud node. 159 4.1. P2MP Pseudowire Sub-TLV 161 The P2MP Pseudowire sub-TLV has the format shown in Figure 1. This 162 TLV is included in the echo request sent over P2MP PW by the 163 originator of request. 165 The Attachment Group Identifier (AGI) in P2MP Pseudowire Sub-TLV as 166 described in Section 3.4.2 in [RFC4446], identifies the VPLS 167 instance. The Originating Router's IP address is the IPv4 or IPv6 168 address of the P2MP PW root. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | AGI Type | AGI Length | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 175 ~ AGI Value ~ 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | IP Addr Len | | 179 +-+-+-+-+-+-+-+ | 180 ~ Originating Routers IP Addr ~ 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: P2MP Pseudowire sub-TLV format 186 For Inclusive and Selective P2MP Trees, the echo request is sent 187 using the P2MP MPLS LSP label. 189 For Aggregate Inclusive and Aggregate Selective P2MP Trees, the echo 190 request is sent using a label stack of [P2MP MPLS LSP label, upstream 191 assigned P2MP PW label]. The P2MP MPLS LSP label is the outer label 192 and upstream assigned P2MP PW label is inner label. 194 5. Encapsulation of OAM Ping Packets 196 The LSP Ping Echo request packet is encapsulated with the MPLS label 197 stack as described in previous sections, followed by one of the two 198 encapsulation options: 200 o GAL Label [RFC6426] followed by IPv4(0x0021) or IPv6(0x0057) type 201 Associated Channel Header (ACH) [RFC4385] 203 o PW ACH [RFC4385] 205 To ensure interoperability, implementations of this document MUST 206 support both encapsulations. 208 6. Operations 210 In this section, we explain the operation of the LSP Ping over P2MP 211 PW. Figure 2 shows a P2MP PW PW1 setup from T-PE1 to remote PEs (T- 212 PE2, T-PE3 and T-PE4). The transport LSP associated with the P2MP 213 PW1 can be mLDP P2MP MPLS LSP or P2MP TE tunnel. 215 |<--------------P2MP PW---------------->| 216 Native | | Native 217 Service | |<--PSN1->| |<--PSN2->| | Service 218 (AC) V V V V V V (AC) 219 | +-----+ +------+ +------+ | 220 | | | | P1 |=========|T-PE2 |AC3 | +---+ 221 | | | | .......PW1.........>|-------->|CE3| 222 | |T-PE1|=========| . |=========| | | +---+ 223 | | .......PW1........ | +------+ | 224 | | . |=========| . | +------+ | 225 | | . | | . |=========|T-PE3 |AC4 | +---+ 226 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 227 |CE1|------->|... | | |=========| | | +---+ 228 +---+ | | . | +------+ +------+ | 229 | | . | +------+ +------+ | 230 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 231 | | .......PW1..............PW1.........>|-------->|CE5| 232 | | |=========| |=========| | | +---+ 233 | +-----+ +------+ +------+ | 235 Figure 2: P2MP PW 237 When an operator wants to perform a connectivity check for the P2MP 238 PW1, the operator initiate a LSP-Ping request with the Target FEC 239 Stack TLV containing P2MP Pseudowire sub-TLV in the echo request 240 packet. For an Inclusive P2MP Tree arrangement, the echo request 241 packet is sent over the P2MP MPLS LSP with one of the following two 242 encapsulation options: 244 o {P2MP LSP label, GAL} MPLS label stack and IPv4 or IPv6 ACH. 246 o {P2MP LSP label} MPLS label stack and PW ACH. 248 For an Aggregate Inclusive Tree arrangement, the echo request packet 249 is sent over the P2MP MPLS LSP with one of the following two 250 encapsulation options: 252 o {P2MP LSP label, P2MP PW upstream assigned label, GAL} MPLS label 253 stack and IPv4 or IPv6 ACH. 255 o {P2MP LSP label, P2MP PW upstream assigned label} MPLS label stack 256 and PW ACH. 258 The intermediate P routers do swap and replication based on the MPLS 259 LSP label. Once the echo request packet reaches remote terminating 260 PEs, T-PEs use GAL label and the IPv4/IPv6 ACH Channel header or PW 261 ACH as the case may be, to determine that the packet is an OAM 262 Packet. The T-PEs process the packet and perform checks for the P2MP 263 Pseudowire sub-TLV present in the Target FEC Stack TLV as described 264 in Section 4.4 in [RFC8029] and respond according to [RFC8029] 265 processing rules. 267 7. Controlling Echo Responses 269 The procedures described in [RFC6425] for preventing congestion of 270 Echo Responses (Echo Jitter TLV in Section 3.3 of [RFC6425]) and 271 limiting the echo reply to a single egress node (Node Address P2MP 272 Responder Identifier TLV in Section 3.2 [RFC6425]) should be applied 273 to P2MP PW LSP Ping. 275 8. Security Considerations 277 The proposal introduced in this document does not introduce any new 278 security considerations beyond those that already apply to [RFC6425]. 280 9. IANA Considerations 282 This document defines a new sub-TLV type to be included in Target FEC 283 Stack TLV (TLV Type 1) [RFC8029] in LSP Ping. 285 IANA is requested to assign a sub-TLV type value to the following 286 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label Switched 287 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- TLVs" sub- 288 registry: 290 o P2MP Pseudowire sub-TLV 292 10. Acknowledgments 294 The authors would like to thank Shaleen Saxena, Greg Mirsky, Andrew 295 G. Malis, and Danny Prairie for their valuable input and comments. 297 11. References 299 11.1. Normative References 301 [I-D.ietf-pals-p2mp-pw] 302 Boutros, S. and S. Sivabalan, "Signaling Root-Initiated 303 Point-to-Multipoint Pseudowire using LDP", draft-ietf- 304 pals-p2mp-pw-03 (work in progress), June 2017. 306 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 307 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 308 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 309 February 2006, . 311 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 312 Emulation (PWE3)", BCP 116, RFC 4446, 313 DOI 10.17487/RFC4446, April 2006, 314 . 316 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 317 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 318 Failures in Point-to-Multipoint MPLS - Extensions to LSP 319 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 320 . 322 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 323 On-Demand Connectivity Verification and Route Tracing", 324 RFC 6426, DOI 10.17487/RFC6426, November 2011, 325 . 327 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 328 C. Kodeboniya, "Multicast in Virtual Private LAN Service 329 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 330 . 332 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 333 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 334 Switched (MPLS) Data-Plane Failures", RFC 8029, 335 DOI 10.17487/RFC8029, March 2017, 336 . 338 11.2. Informative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 346 Yasukawa, Ed., "Extensions to Resource Reservation 347 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 348 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 349 DOI 10.17487/RFC4875, May 2007, 350 . 352 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 353 Thomas, "Label Distribution Protocol Extensions for Point- 354 to-Multipoint and Multipoint-to-Multipoint Label Switched 355 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 356 . 358 [RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, 359 "Requirements and Framework for Point-to-Multipoint 360 Pseudowires over MPLS Packet Switched Networks", RFC 7338, 361 DOI 10.17487/RFC7338, September 2014, 362 . 364 Authors' Addresses 366 Parag Jain (editor) 367 Cisco Systems, Inc. 368 2000 Innovation Drive 369 Kanata, ON K2K-3E8 370 Canada 372 Email: paragj@cisco.com 374 Sami Boutros 375 VMWare, Inc. 376 USA 378 Email: sboutros@vmware.com 379 Sam Aldrin 380 Google Inc. 381 USA 383 Email: aldrin.ietf@gmail.com