idnits 2.17.00 (12 Aug 2021) /tmp/idnits40478/draft-ietf-pals-ms-pw-protection-02.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 (June 1, 2015) is 2546 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: December 3, 2015 Hai Gaoming BV 7 J. Shin 8 SK Telecom 9 L. Wang 10 China Mobile 11 A. D'Alessandro 12 Telecom Italia 13 June 1, 2015 15 S-PE Outage Protection for Static Multi-Segment Pseudowires 16 draft-ietf-pals-ms-pw-protection-02.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 December 3, 2015. 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 . . . . . . . . 6 78 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 79 A.2. Encapsulation of the PSC Protocol for Pseudowires . . . . 7 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 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and 124 MS-PWs 126 Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to 127 use redundant MS-PWs to protect an MS-PW against S-PE failure in the 128 case of a singly-homed CE, using the following network model from RFC 129 6718: 131 Native |<----------- Pseudowires ----------->| Native 132 Service | | Service 133 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 134 | V V V V V V | 135 | +-----+ +-----+ +-----+ | 136 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 137 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 138 | CE1| | |=========| |=========| | | CE2| 139 | | +-----+ +-----+ +-----+ | | 140 +----+ |.||.| |.||.| +----+ 141 |.||.| +-----+ |.||.| 142 |.||.|=========| |========== .||.| 143 |.||...PW2-Seg1......|.PW2-Seg2...||.| 144 |.| ===========|S-PE2|============ |.| 145 |.| +-----+ |.| 146 |.|============+-----+============= .| 147 |.....PW3-Seg1.| | PW3-Seg2......| 148 ==============|S-PE3|=============== 149 | | 150 +-----+ 152 Figure 1: Single-Homed CE with Redundant MS-PWs 154 In this figure, CE1 is connected to PE1 and CE2 is connected to PE2. 155 There are three MS PWs. PW1 is switched at S-PE1, PW2 is switched at 156 S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1 157 protection against S-PE failure for the subset of the path of the 158 emulated service from T-PE1 to T-PE2. 160 The procedures in RFCs 6718 and 6870 rely on LDP-based PW status 161 signaling to signal the state of the primary MS-PW that is being 162 protected, and the precedence in which redundant MS-PW(s) should be 163 used to protect the primary MS-PW should it fail. These procedures 164 make use of information carried by the PW Status TLV, which for 165 dynamically signaled PWs is carried by the LDP protocol. 167 However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the 168 LDP protocol for PW set and signaling, rather they are provisioned by 169 network management systems or other means at each T-PE and S-PE along 170 their path. They also do not use the LDP protocol for status 171 signaling. Rather, they use procedures defined in RFC 6478 [RFC6478] 172 for status signaling via the PW OAM message using the PW Associated 173 Channel Header (ACH). The PW Status TLV carried via this status 174 signaling is itself identical to the PW Status TLV carried via LDP- 175 based status signaling, including the identical PW Status Codes. 177 Sections 6 and 7 of RFC 6870 describes the management of a primary PW 178 and its secondary PW(s) to provide resiliency to the failure of the 179 primary PW. They use status codes transmitted between endpoint T-PEs 180 using the PW Status TLV transmitted by LDP. For this management to 181 apply to statically provisioned PWs, the PW status signaling defined 182 in RFC 6478 MUST be used for the primary and secondary PWs. In that 183 case, the endpoint T-PEs can then use the PW status signaling 184 provided by RFC 6478 in the place of LDP-based status signaling, but 185 otherwise operate identically as described in RFC 6870. Note that 186 the optional S-PE Bypass Mode defined in Section 5.5 of RFC 6478 187 cannot be used, as it requires LDP signaling. 189 3. Operational Considerations 191 Because LDP is not used between the T-PEs for statically provisioned 192 MS-PWs, the negotiation procedures described in RFC 6870 cannot be 193 used. Thus, operational care must be taken so that the endpoint 194 T-PEs are identically provisioned regarding the use of this document, 195 specifically whether or not MS-PW redundancy is being used, and for 196 each protected MS-PW, the identity of the primary MS-PW and the 197 precedence of the secondary MS-PWs. 199 4. Security Considerations 201 The security considerations defined for RFC 6478 apply to this 202 document as well. As the security considerations in RFCs 6718 and 203 6870 are related to their use of LDP, they are not required for this 204 document. 206 If the alternative approach in Appendix A is used, then the security 207 considerations defined for RFCs 6378, 7271, and 7324 also apply. 209 5. IANA Considerations 211 There are no requests for IANA actions in this document. 213 Note to the RFC Editor - this section can be removed before 214 publication. 216 6. Acknowledgements 218 The authors would like to thank Matthew Bocci, Yaakov Stein, David 219 Sinicrope, Sasha Vainshtein, and Italo Busi for their comments on 220 this document. 222 Figure 1 and the explanatory paragraph following the figure were 223 taken from RFC 6718. Figure 2 was adapted from RFC 6378. 225 7. References 227 7.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 233 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 234 Protection", RFC 6378, October 2011. 236 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 237 "Pseudowire Status for Static Pseudowires", RFC 6478, May 238 2012. 240 [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential 241 Forwarding Status Bit", RFC 6870, February 2013. 243 [RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., 244 Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS- 245 TP) Linear Protection to Match the Operational 246 Expectations of Synchronous Digital Hierarchy, Optical 247 Transport Network, and Ethernet Transport Network 248 Operators", RFC 7271, June 2014. 250 [RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear 251 Protection", RFC 7324, July 2014. 253 7.2. Informative References 255 [I-D.ietf-pals-redundancy-spe] 256 Dong, J. and H. Wang, "Pseudowire Redundancy on S-PE", 257 draft-ietf-pals-redundancy-spe-01 (work in progress), May 258 2015. 260 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 261 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 262 October 2009. 264 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 265 Redundancy", RFC 6718, August 2012. 267 Appendix A. Optional Linear Protection Approach 268 A.1. Introduction 270 In "MPLS Transport Profile (MPLS-TP) Linear Protection" [RFC6378], as 271 well as in the later updates of this RFC in "MPLS Transport Profile 272 (MPLS-TP) Linear Protection to Match the Operational Expectations of 273 SDH, OTN and Ethernet Transport Network Operators" [RFC7271] and in 274 "Updates to MPLS Transport Profile Linear Protection" [RFC7324], the 275 Protection State Coordination (PSC) protocol was defined for MPLS 276 LSPs only. 278 This Appendix extends these RFCs to be applicable for PWs (SS-PW and 279 MS-PW) as well. This is useful especially in the case of end-to-end 280 static provisioned MS-PWs running over MPLS-TP where tunnel 281 protection alone cannot be relied upon for end-to-end protection of 282 PWs against S-PE failure. It also enables a uniform operational 283 approach for protection at LSP and PW layers and an easier management 284 integration for networks that already use RFCs 6378, 7271, and 7324. 286 The protection architectures are those defined in [RFC6378]. For the 287 purposes of this Appendix, we define the protection domain of a 288 point-to-point PW as consisting of two terminating PEs (T-PEs) and 289 the transport paths that connect them (see Figure 2). 291 +-----+ //=======================\\ +-----+ 292 |T-PE1|// Working Path \\|T-PE2| 293 | /| |\ | 294 | ?< | | >? | 295 | \|\\ Protection Path //|/ | 296 +-----+ \\=======================// +-----+ 298 |<-------Protection Domain------->| 300 Figure 2: Protection Domain 302 This Appendix is an optional alternative approach to the one in 303 Section 2, therefore all implementations MUST include the approach in 304 Section 2 even if this alternative approach is used. The operational 305 considerations in Section 3 continue to apply when this approach is 306 used, and operational care must be taken so that the endpoint T-PEs 307 are identically provisioned regarding the use of this document. 309 A.2. Encapsulation of the PSC Protocol for Pseudowires 311 The PSC protocol can be used to protect against defects on any LSP 312 (segment, link or path). In the case of MS-PW, the PSC protocol can 313 also protect failed intermediate nodes (S-PE). Linear protection 314 protects an LSP or PW end-to-end and if a failure is detected, 315 switches traffic over to another (redundant) set of resources. 317 Obviously, the protected entity does not need to be of the same type 318 as the protecting. For example, it is possible to protect a link by 319 a path. Likewise it is possible to protect a SS-PW with a MS-PW and 320 vice versa. 322 From a PSC protocol point of view it is possible to view a SS-PW as a 323 single hop LSP, and a MS-PW as a multiple hop LSP. Thus, this 324 provides end-to-end protection for the SS-PW or MS-PW. The G-ACh 325 carrying the PSC protocol information is placed in the label stack 326 directly beneath the PW identifier. The PSC protocol will then work 327 as specified in RFCs 6378, 7271, and 7324. 329 Authors' Addresses 331 Andrew G. Malis (editor) 332 Huawei Technologies Co., Ltd 334 Email: agmalis@gmail.com 336 Loa Andersson 337 Huawei Technologies Co., Ltd 339 Email: loa@mail01.huawei.com 341 Huub van Helvoort 342 Hai Gaoming BV 344 Email: huubatwork@gmail.com 346 Jongyoon Shin 347 SK Telecom 349 Email: jongyoon.shin@sk.com 351 Lei Wang 352 China Mobile 354 Email: wangleiyj@chinamobile.com 356 Alessandro D'Alessandro 357 Telecom Italia 359 Email: alessandro.dalessandro@telecomitalia.it