idnits 2.17.00 (12 Aug 2021) /tmp/idnits30435/draft-ietf-pals-p2mp-pw-lsp-ping-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 (August 21, 2017) is 1727 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: draft-ietf-pals-p2mp-pw has been published as RFC 8338 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: February 22, 2018 VMWare, Inc. 6 S. Aldrin 7 Google Inc. 8 August 21, 2017 10 Definition of P2MP PW TLV for LSP-Ping Mechanisms 11 draft-ietf-pals-p2mp-pw-lsp-ping-05 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 February 22, 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 . . . . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 11.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 Leaf PE (L-PE), the traffic can be associated with a 82 Virtual Private Network (VPN) or a Virtual Private LAN Service (VPLS) 83 instance. When a P2MP MPLS LSP carries only one VPN or VPLS service 84 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 at Root PE(R-PE) 104 to inform the receiver at Leaf PE(L-PE) 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 AGI: Attachment Group Identifier 120 ATM: Asynchronous Transfer Mode 122 CE: Customer Edge 124 FEC: Forwarding Equivalence Class 126 GAL: Generic Associated Channel Label 128 LDP: Label Distribution Protocol 130 L-PE: Leaf-PE, one of many destinations of the P2MP MPLS LSP i.e. 131 egress PE 133 LSP: Label Switched Path 135 LSR: Label Switching Router 137 mLDP: Multipoint LDP 139 MPLS-OAM: MPLS Operations, Administration and Maintenance 141 P2MP: Point-to-Multipoint 143 P2MP-PW: Point-to-Multipoint PseudoWire 145 PE: Provider Edge 146 PSN: Public Switched Network 148 PW: PseudoWire 150 R-PE: Root PE - ingress PE, PE initiating P2MP PW setup 152 RSVP: Resource Reservation Protocol 154 TE: Traffic Engineering 156 TLV: Type Length Value 158 VPLS: Virtual Private LAN Service 160 4. Identifying a P2MP PW 162 This document introduces a new LSP Ping Target FEC Stack sub-TLV, 163 P2MP Pseudowire sub-TLV, to identify the P2MP PW under test at the 164 P2MP Leaf PE (L-PE). 166 4.1. P2MP Pseudowire Sub-TLV 168 The P2MP Pseudowire sub-TLV has the format shown in Figure 1. This 169 TLV is included in the echo request sent over P2MP PW by the 170 originator of request. 172 The Attachment Group Identifier (AGI) in P2MP Pseudowire Sub-TLV as 173 described in Section 3.4.2 in [RFC4446], identifies the VPLS 174 instance. The Originating Router's IP address is the IPv4 or IPv6 175 address of the P2MP PW root. The address family of the IP address is 176 determined by the IP Addr Len field. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | AGI Type | AGI Length | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 183 ~ AGI Value ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | IP Addr Len | | 187 +-+-+-+-+-+-+-+ | 188 ~ Originating Routers IP Addr ~ 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: P2MP Pseudowire sub-TLV format 194 For Inclusive and Selective P2MP Trees, the echo request is sent 195 using the P2MP MPLS LSP label. 197 For Aggregate Inclusive and Aggregate Selective P2MP Trees, the echo 198 request is sent using a label stack of [P2MP MPLS LSP label, upstream 199 assigned P2MP PW label]. The P2MP MPLS LSP label is the outer label 200 and upstream assigned P2MP PW label is inner label. 202 5. Encapsulation of OAM Ping Packets 204 The LSP Ping Echo request packet is encapsulated with the MPLS label 205 stack as described in previous sections, followed by one of the two 206 encapsulation options: 208 o GAL Label [RFC6426] followed by IPv4(0x0021) or IPv6(0x0057) type 209 Associated Channel Header (ACH) [RFC4385] 211 o PW ACH [RFC4385] 213 To ensure interoperability, implementations of this document MUST 214 support both encapsulations. 216 6. Operations 218 In this section, we explain the operation of the LSP Ping over P2MP 219 PW. Figure 2 shows a P2MP PW PW1 setup from Root PE R-PE1, to Leaf 220 PEs (L-PE2, L-PE3 and L-PE4). The transport LSP associated with the 221 P2MP PW1 can be mLDP P2MP MPLS LSP or P2MP TE tunnel. 223 |<--------------P2MP PW---------------->| 224 Native | | Native 225 Service | |<--PSN1->| |<--PSN2->| | Service 226 (AC) V V V V V V (AC) 227 | +-----+ +------+ +------+ | 228 | | | | P1 |=========|L-PE2 |AC3 | +---+ 229 | | | | .......PW1.........>|-------->|CE3| 230 | |R-PE1|=========| . |=========| | | +---+ 231 | | .......PW1........ | +------+ | 232 | | . |=========| . | +------+ | 233 | | . | | . |=========|L-PE3 |AC4 | +---+ 234 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 235 |CE1|------->|... | | |=========| | | +---+ 236 +---+ | | . | +------+ +------+ | 237 | | . | +------+ +------+ | 238 | | . |=========| P2 |=========|L-PE4 |AC5 | +---+ 239 | | .......PW1..............PW1.........>|-------->|CE5| 240 | | |=========| |=========| | | +---+ 241 | +-----+ +------+ +------+ | 243 Figure 2: P2MP PW 245 When an operator wants to perform a connectivity check for the P2MP 246 PW1, the operator initiate a LSP-Ping request from Root PE R-PE1, 247 with the Target FEC Stack TLV containing P2MP Pseudowire sub-TLV in 248 the echo request packet. For an Inclusive P2MP Tree arrangement, the 249 echo request packet is sent over the P2MP MPLS LSP with one of the 250 following two encapsulation options: 252 o {P2MP LSP label, GAL} MPLS label stack and IPv4 or IPv6 ACH. 254 o {P2MP LSP label} MPLS label stack and PW ACH. 256 For an Aggregate Inclusive Tree arrangement, the echo request packet 257 is sent over the P2MP MPLS LSP with one of the following two 258 encapsulation options: 260 o {P2MP LSP label, P2MP PW upstream assigned label, GAL} MPLS label 261 stack and IPv4 or IPv6 ACH. 263 o {P2MP LSP label, P2MP PW upstream assigned label} MPLS label stack 264 and PW ACH. 266 The intermediate P routers do mpls label swap and replication based 267 on the incoming MPLS LSP label. Once the echo request packet reaches 268 L-PEs, L-PEs use GAL label and the IPv4/IPv6 ACH Channel header or PW 269 ACH as the case may be, to determine that the packet is an OAM 270 Packet. The L-PEs process the packet and perform checks for the P2MP 271 Pseudowire sub-TLV present in the Target FEC Stack TLV as described 272 in Section 4.4 in [RFC8029] and respond according to [RFC8029] 273 processing rules. 275 7. Controlling Echo Responses 277 The procedures described in [RFC6425] for preventing congestion of 278 Echo Responses (Echo Jitter TLV in Section 3.3 of [RFC6425]) and 279 limiting the echo reply to a single L-PE (Node Address P2MP Responder 280 Identifier TLV in Section 3.2 [RFC6425]) should be applied to P2MP PW 281 LSP Ping. 283 8. Security Considerations 285 The proposal introduced in this document does not introduce any new 286 security considerations beyond those that already apply to [RFC6425]. 288 9. IANA Considerations 290 This document defines a new sub-TLV type to be included in Target FEC 291 Stack TLV (TLV Type 1) [RFC8029] in LSP Ping. 293 IANA is requested to assign a sub-TLV type value to the following 294 sub-TLV from the "Multiprotocol Label Switching (MPLS) Label Switched 295 Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub- TLVs" sub- 296 registry: 298 o P2MP Pseudowire sub-TLV 300 10. Acknowledgments 302 The authors would like to thank Shaleen Saxena, Greg Mirsky, Andrew 303 G. Malis, and Danny Prairie for their valuable input and comments. 305 11. References 307 11.1. Normative References 309 [I-D.ietf-pals-p2mp-pw] 310 Boutros, S. and S. Sivabalan, "Signaling Root-Initiated 311 Point-to-Multipoint Pseudowire using LDP", draft-ietf- 312 pals-p2mp-pw-03 (work in progress), June 2017. 314 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 315 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 316 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 317 February 2006, . 319 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 320 Emulation (PWE3)", BCP 116, RFC 4446, 321 DOI 10.17487/RFC4446, April 2006, . 324 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 325 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 326 Failures in Point-to-Multipoint MPLS - Extensions to LSP 327 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 328 . 330 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 331 On-Demand Connectivity Verification and Route Tracing", 332 RFC 6426, DOI 10.17487/RFC6426, November 2011, 333 . 335 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 336 C. Kodeboniya, "Multicast in Virtual Private LAN Service 337 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 338 . 340 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 341 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 342 Switched (MPLS) Data-Plane Failures", RFC 8029, 343 DOI 10.17487/RFC8029, March 2017, . 346 11.2. Informative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, . 353 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 354 Yasukawa, Ed., "Extensions to Resource Reservation 355 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 356 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 357 DOI 10.17487/RFC4875, May 2007, . 360 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 361 Thomas, "Label Distribution Protocol Extensions for Point- 362 to-Multipoint and Multipoint-to-Multipoint Label Switched 363 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 364 . 366 [RFC7338] Jounay, F., Ed., Kamite, Y., Ed., Heron, G., and M. Bocci, 367 "Requirements and Framework for Point-to-Multipoint 368 Pseudowires over MPLS Packet Switched Networks", RFC 7338, 369 DOI 10.17487/RFC7338, September 2014, . 372 Authors' Addresses 374 Parag Jain (editor) 375 Cisco Systems, Inc. 376 2000 Innovation Drive 377 Kanata, ON K2K-3E8 378 Canada 380 Email: paragj@cisco.com 382 Sami Boutros 383 VMWare, Inc. 384 USA 386 Email: sboutros@vmware.com 388 Sam Aldrin 389 Google Inc. 390 USA 392 Email: aldrin.ietf@gmail.com