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