idnits 2.17.00 (12 Aug 2021) /tmp/idnits41712/draft-ietf-pals-ms-pw-protection-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6870, but the abstract doesn't seem to directly say this. It does mention RFC6870 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6870, updated by this document, for RFC5378 checks: 2008-02-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2015) is 2424 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-redundancy-spe has been published as RFC 7795 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Malis, Ed. 3 Internet-Draft L. Andersson 4 Updates: 6870 (if approved) Huawei Technologies Co., Ltd 5 Intended status: Standards Track H. van Helvoort 6 Expires: April 3, 2016 Hai Gaoming BV 7 J. Shin 8 SK Telecom 9 L. Wang 10 China Mobile 11 A. D'Alessandro 12 Telecom Italia 13 October 1, 2015 15 S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires 16 draft-ietf-pals-ms-pw-protection-03.txt 18 Abstract 20 In MPLS and MPLS-TP environments, statically provisioned Single- 21 Segment Pseudowires (SS-PWs) are protected against tunnel failure via 22 MPLS-level and MPLS-TP-level tunnel protection. With statically 23 provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the 24 MS-PW is likewise protected from tunnel failures via MPLS-level and 25 MPLS-TP-level tunnel protection. However, static MS-PWs are not 26 protected end-to-end against failure of one of the switching PEs 27 (S-PEs) along the path of the MS-PW. This document describes how to 28 achieve this protection via redundant MS-PWs by updating the existing 29 procedures in RFC 6870. It also contains an optional approach based 30 on MPLS-TP Linear Protection. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 3, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Extension to RFC 6870 to Protect Statically Provisioned SS- 69 PWs and MS-PWs . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Operational Considerations . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Optional Linear Protection Approach . . . . . . . . 7 78 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 79 A.2. Encapsulation of the PSC Protocol for Pseudowires . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 As described in RFC 5659 [RFC5659], Multi-Segment Pseudowires (MS- 85 PWs) consist of terminating PEs (T-PEs), one or more switching PEs 86 (S-PEs), and a sequence of PW segments that connects one of the T-PEs 87 with its "adjacent" S-PE, connects this S-PE with the next S-PE in 88 the sequence and so on until the last S-PE is connected by the last 89 PW segment to the remaining T-PE. In MPLS and MPLS-TP environments, 90 statically provisioned Single-Segment Pseudowires (SS-PWs) are 91 protected against tunnel failure via MPLS-level and MPLS-TP-level 92 tunnel protection. With statically provisioned Multi-Segment 93 Pseudowires (MS-PWs), each PW segment of the MS-PW is likewise 94 protected from tunnel failure via MPLS-level and MPLS-TP-level tunnel 95 protection. However, PSN tunnel protection does not protect static 96 MS-PWs from failures of S-PEs along the path of the MS-PW. 98 RFC 6718 [RFC6718] provides a general framework for PW protection, 99 and RFC 6870 [RFC6870], which is based upon that framework, describes 100 protection procedures for MS-PWs that are dynamically signaled using 101 LDP. This document describes how to achieve protection against S-PE 102 failure in a static MS-PW by extending RFC 6870 to be applicable for 103 statically provisioned MS-PWs pseudowires (PWs) as well. 105 This document also contains an OPTIONAL alternative approach based on 106 MPLS-TP Linear Protection. This approach, described in Appendix A, 107 MUST be identically provisioned in the PE endpoints for the protected 108 MS-PW in order to be used. See Appendix A for further details on 109 this alternative approach. 111 This document differs from [I-D.ietf-pals-redundancy-spe] in that 112 this draft provides end-to-end resiliency for static MS-PWs, while 113 [I-D.ietf-pals-redundancy-spe] provides resiliency at intermediate 114 S-PEs, rather than end-to-end resiliency, and for both dynamically 115 signaled and static MS-PWs. 117 L2TPv3-based PWs are outside the scope of this document. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and 126 MS-PWs 128 Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to 129 use redundant MS-PWs to protect an MS-PW against S-PE failure in the 130 case of a singly-homed CE, using the following network model from RFC 131 6718: 133 Native |<----------- Pseudowires ----------->| Native 134 Service | | Service 135 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 136 | V V V V V V | 137 | +-----+ +-----+ +-----+ | 138 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 139 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 140 | CE1| | |=========| |=========| | | CE2| 141 | | +-----+ +-----+ +-----+ | | 142 +----+ |.||.| |.||.| +----+ 143 |.||.| +-----+ |.||.| 144 |.||.|=========| |========== .||.| 145 |.||...PW2-Seg1......|.PW2-Seg2...||.| 146 |.| ===========|S-PE2|============ |.| 147 |.| +-----+ |.| 148 |.|============+-----+============= .| 149 |.....PW3-Seg1.| | PW3-Seg2......| 150 ==============|S-PE3|=============== 151 | | 152 +-----+ 154 Figure 1: Single-Homed CE with Redundant MS-PWs 156 In this figure, CE1 is connected to PE1 and CE2 is connected to PE2. 157 There are three MS PWs. PW1 is switched at S-PE1, PW2 is switched at 158 S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1 159 protection against S-PE failure for the subset of the path of the 160 emulated service from T-PE1 to T-PE2. 162 The procedures in RFCs 6718 and 6870 rely on LDP-based PW status 163 signaling to signal the state of the primary MS-PW that is being 164 protected, and the precedence in which redundant MS-PW(s) should be 165 used to protect the primary MS-PW should it fail. These procedures 166 make use of information carried by the PW Status TLV, which for 167 dynamically signaled PWs is carried by the LDP protocol. 169 However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the 170 LDP protocol for PW set and signaling, rather they are provisioned by 171 network management systems or other means at each T-PE and S-PE along 172 their path. They also do not use the LDP protocol for status 173 signaling. Rather, they use procedures defined in RFC 6478 [RFC6478] 174 for status signaling via the PW OAM message using the PW Associated 175 Channel Header (ACH). The PW Status TLV carried via this status 176 signaling is itself identical to the PW Status TLV carried via LDP- 177 based status signaling, including the identical PW Status Codes. 179 Sections 6 and 7 of RFC 6870 describes the management of a primary PW 180 and its secondary PW(s) to provide resiliency to the failure of the 181 primary PW. They use status codes transmitted between endpoint T-PEs 182 using the PW Status TLV transmitted by LDP. For this management to 183 apply to statically provisioned PWs, the PW status signaling defined 184 in RFC 6478 MUST be used for the primary and secondary PWs. In that 185 case, the endpoint T-PEs can then use the PW status signaling 186 provided by RFC 6478 in the place of LDP-based status signaling, but 187 otherwise operate identically as described in RFC 6870. Note that 188 the optional S-PE Bypass Mode defined in Section 5.5 of RFC 6478 189 cannot be used, as it requires LDP signaling. 191 3. Operational Considerations 193 Because LDP is not used between the T-PEs for statically provisioned 194 MS-PWs, the negotiation procedures described in RFC 6870 cannot be 195 used. Thus, operational care must be taken so that the endpoint 196 T-PEs are identically provisioned regarding the use of this document, 197 specifically whether or not MS-PW redundancy is being used, and for 198 each protected MS-PW, the identity of the primary MS-PW and the 199 precedence of the secondary MS-PWs. 201 4. Security Considerations 203 The security considerations defined for RFC 6478 apply to this 204 document as well. As the security considerations in RFCs 6718 and 205 6870 are related to their use of LDP, they are not required for this 206 document. 208 If the alternative approach in Appendix A is used, then the security 209 considerations defined for RFCs 6378, 7271, and 7324 also apply. 211 5. IANA Considerations 213 There are no requests for IANA actions in this document. 215 Note to the RFC Editor - this section can be removed before 216 publication. 218 6. Acknowledgements 220 The authors would like to thank Matthew Bocci, Yaakov Stein, David 221 Sinicrope, Sasha Vainshtein, and Italo Busi for their comments on 222 this document. 224 Figure 1 and the explanatory paragraph following the figure were 225 taken from RFC 6718. Figure 2 was adapted from RFC 6378. 227 7. References 229 7.1. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, 233 DOI 10.17487/RFC2119, March 1997, 234 . 236 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 237 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 238 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 239 October 2011, . 241 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 242 "Pseudowire Status for Static Pseudowires", RFC 6478, 243 DOI 10.17487/RFC6478, May 2012, 244 . 246 [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire 247 Preferential Forwarding Status Bit", RFC 6870, 248 DOI 10.17487/RFC6870, February 2013, 249 . 251 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 252 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 253 Transport Profile (MPLS-TP) Linear Protection to Match the 254 Operational Expectations of Synchronous Digital Hierarchy, 255 Optical Transport Network, and Ethernet Transport Network 256 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 257 . 259 [RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear 260 Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014, 261 . 263 7.2. Informative References 265 [I-D.ietf-pals-redundancy-spe] 266 Dong, J. and H. Wang, "Pseudowire Redundancy on S-PE", 267 draft-ietf-pals-redundancy-spe-02 (work in progress), 268 August 2015. 270 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 271 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 272 DOI 10.17487/RFC5659, October 2009, 273 . 275 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 276 Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, 277 . 279 Appendix A. Optional Linear Protection Approach 281 A.1. Introduction 283 In "MPLS Transport Profile (MPLS-TP) Linear Protection" [RFC6378], as 284 well as in the later updates of this RFC in "MPLS Transport Profile 285 (MPLS-TP) Linear Protection to Match the Operational Expectations of 286 SDH, OTN and Ethernet Transport Network Operators" [RFC7271] and in 287 "Updates to MPLS Transport Profile Linear Protection" [RFC7324], the 288 Protection State Coordination (PSC) protocol was defined for MPLS 289 LSPs only. 291 This Appendix extends these RFCs to be applicable for PWs (SS-PW and 292 MS-PW) as well. This is useful especially in the case of end-to-end 293 static provisioned MS-PWs running over MPLS-TP where tunnel 294 protection alone cannot be relied upon for end-to-end protection of 295 PWs against S-PE failure. It also enables a uniform operational 296 approach for protection at LSP and PW layers and an easier management 297 integration for networks that already use RFCs 6378, 7271, and 7324. 299 The protection architectures are those defined in [RFC6378]. For the 300 purposes of this Appendix, we define the protection domain of a 301 point-to-point PW as consisting of two terminating PEs (T-PEs) and 302 the transport paths that connect them (see Figure 2). 304 +-----+ //=======================\\ +-----+ 305 |T-PE1|// Working Path \\|T-PE2| 306 | /| |\ | 307 | ?< | | >? | 308 | \|\\ Protection Path //|/ | 309 +-----+ \\=======================// +-----+ 311 |<-------Protection Domain------->| 313 Figure 2: Protection Domain 315 This Appendix is an OPTIONAL alternative approach to the one in 316 Section 2. For interoperability, all implementations MUST include 317 the approach in Section 2 even if this alternative approach is used. 318 The operational considerations in Section 3 continue to apply when 319 this approach is used, and operational care must be taken so that the 320 endpoint T-PEs are identically provisioned regarding the use of this 321 document. 323 A.2. Encapsulation of the PSC Protocol for Pseudowires 325 The PSC protocol can be used to protect against defects on any LSP 326 (segment, link or path). In the case of MS-PW, the PSC protocol can 327 also protect failed intermediate nodes (S-PE). Linear protection 328 protects an LSP or PW end-to-end and if a failure is detected, 329 switches traffic over to another (redundant) set of resources. 331 Obviously, the protected entity does not need to be of the same type 332 as the protecting. For example, it is possible to protect a link by 333 a path. Likewise it is possible to protect a SS-PW with a MS-PW and 334 vice versa. 336 From a PSC protocol point of view it is possible to view a SS-PW as a 337 single hop LSP, and a MS-PW as a multiple hop LSP. Thus, this 338 provides end-to-end protection for the SS-PW or MS-PW. The G-ACh 339 carrying the PSC protocol information is placed in the label stack 340 directly beneath the PW identifier. The PSC protocol will then work 341 as specified in RFCs 6378, 7271, and 7324. 343 Authors' Addresses 345 Andrew G. Malis (editor) 346 Huawei Technologies Co., Ltd 348 Email: agmalis@gmail.com 350 Loa Andersson 351 Huawei Technologies Co., Ltd 353 Email: loa@mail01.huawei.com 355 Huub van Helvoort 356 Hai Gaoming BV 358 Email: huubatwork@gmail.com 360 Jongyoon Shin 361 SK Telecom 363 Email: jongyoon.shin@sk.com 364 Lei Wang 365 China Mobile 367 Email: wangleiyj@chinamobile.com 369 Alessandro D'Alessandro 370 Telecom Italia 372 Email: alessandro.dalessandro@telecomitalia.it