idnits 2.17.1 draft-shawam-pwe3-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 (October 10, 2014) is 3485 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: April 13, 2015 Hai Gaoming BV 7 J. Shin 8 SK Telecom 9 L. Wang 10 China Mobile 11 A. D'Alessandro 12 Telecom Italia 13 October 10, 2014 15 S-PE Outage Protection for Static Multi-Segment Pseudowires 16 draft-shawam-pwe3-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 by updating the existing procedures in RFC 29 6870. It also contains an optional approach based on MPLS-TP Linear 30 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 13, 2015. 49 Copyright Notice 51 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 As described in RFC 5659 [RFC5659], Multi-Segment Pseudowires (MS- 85 PWs) consist of terminating PEs (T-PEs), switching PEs (S-PEs), and 86 PW segments between the T-PEs at each of the MS-PW and the interior 87 S-PEs. In MPLS and MPLS-TP environments, statically provisioned 88 Single-Segment Pseudowires (SS-PWs) are protected against tunnel 89 failure via MPLS-level and MPLS-TP-level tunnel protection. With 90 statically provisioned Multi-Segment Pseudowires (MS-PWs), each PW 91 segment of the MS-PW is likewise protected from tunnel failure via 92 MPLS-level and MPLS-TP-level tunnel protection. However, PSN tunnel 93 protection does not protect static MS-PWs from failures of S-PEs 94 along the path of the MS-PW. 96 RFC 6718 [RFC6718] provides a general framework for PW protection, 97 and RFC 6870 [RFC6870], which is based upon that framework, describes 98 protection procedures for MS-PWs that are dynamically signaled using 99 LDP. This document describes how to achieve protection against S-PE 100 failure in a static MS-PW by extending RFC 6870 to be applicable for 101 statically provisioned MS-PWs pseudowires (PWs) as well. 103 This document also contains an optional alternative approach based on 104 MPLS-TP Linear Protection. This approach, described in Appendix A, 105 MUST be identically provisioned in the PE endpoints for the protected 106 MS-PW in order to be used. See Appendix A for further details on 107 this alternative approach. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Extension to RFC 6870 to Protect Statically Provisioned SS-PWs and 116 MS-PWs 118 Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870 document how to 119 use redundant MS-PWs to protect an MS-PW against S-PE failure in the 120 case of a singly-homed CE, using the following network model from RFC 121 6718: 123 Native |<----------- Pseudowires ----------->| Native 124 Service | | Service 125 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 126 | V V V V V V | 127 | +-----+ +-----+ +-----+ | 128 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 129 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 130 | CE1| | |=========| |=========| | | CE2| 131 | | +-----+ +-----+ +-----+ | | 132 +----+ |.||.| |.||.| +----+ 133 |.||.| +-----+ |.||.| 134 |.||.|=========| |========== .||.| 135 |.||...PW2-Seg1......|.PW2-Seg2...||.| 136 |.| ===========|S-PE2|============ |.| 137 |.| +-----+ |.| 138 |.|============+-----+============= .| 139 |.....PW3-Seg1.| | PW3-Seg2......| 140 ==============|S-PE3|=============== 141 | | 142 +-----+ 144 Figure 1: Single-Homed CE with Redundant MS-PWs 146 In this figure, CE1 is connected to PE1 and CE2 is connected to PE2. 147 There are three MS PWs. PW1 is switched at S-PE1, PW2 is switched at 148 S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1 149 protection against S-PE failure for the subset of the path of the 150 emulated service from T-PE1 to T-PE2. 152 The procedures in RFCs 6718 and 6870 rely on LDP-based PW status 153 signaling to signal the state of the primary MS-PW that is being 154 protected, and the precedence in which redundant MS-PW(s) should be 155 used to protect the primary MS-PW should it fail. These procedures 156 make use of information carried by the PW Status TLV, which for 157 dynamically signaled PWs is carried by the LDP protocol. 159 However, statically provisioned PWs (SS-PWs or MS-PWs) do not use the 160 LDP protocol for PW set and signaling, rather they are provisioned by 161 network management systems or other means at each T-PE and S-PE along 162 their path. They also do not use the LDP protocol for status 163 signaling. Rather, they use procedures defined in RFC 6478 [RFC6478] 164 for status signaling via the PW OAM message using the PW Associated 165 Channel Header (ACH). The PW Status TLV carried via this status 166 signaling is itself identical to the PW Status TLV carried via LDP- 167 based status signaling, including the identical PW Status Codes. 169 Sections 6 and 7 of RFC 6870 describes the management of a primary PW 170 and its secondary PW(s) to provide resiliency to the failure of the 171 primary PW. They use status codes transmitted between endpoint T-PEs 172 using the PW Status TLV transmitted by LDP. For this management to 173 apply to statically provisioned PWs, the PW status signaling defined 174 in RFC 6478 MUST be used for the primary and secondary PWs. In that 175 case, the endpoint T-PEs can then use the PW status signaling 176 provided by RFC 6478 in the place of LDP-based status signaling, but 177 otherwise operate identically as described in RFC 6870. 179 3. Operational Considerations 181 Because LDP is not used between the T-PEs for statically provisioned 182 MS-PWs, the negotiation procedures described in RFC 6870 cannot be 183 used. Thus, operational care must be taken so that the endpoint 184 T-PEs are identically provisioned regarding the use of this document, 185 specifically whether or not MS-PW redundancy is being used, and for 186 each protected MS-PW, the identity of the primary MS-PW and the 187 precedence of the secondary MS-PWs. 189 4. Security Considerations 191 The security considerations defined for RFC 6478 apply to this 192 document as well. As the security considerations in RFCs 6718 and 193 6870 are related to their use of LDP, they are not required for this 194 document. 196 If the alternative approach in Appendix A is used, then the security 197 considerations defined for RFCs 6378, 7271, and 7324 also apply. 199 5. IANA Considerations 201 There are no requests for IANA actions in this document. 203 Note to the RFC Editor - this section can be removed before 204 publication. 206 6. Acknowledgements 208 The authors would like to thank Matthew Bocci, Yaakov Stein, and 209 David Sinicrope for their comments on this document. 211 Figure 1 and the explanatory paragraph following the figure were 212 taken from RFC 6718. 214 7. References 215 7.1. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 221 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 222 Protection", RFC 6378, October 2011. 224 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 225 "Pseudowire Status for Static Pseudowires", RFC 6478, May 226 2012. 228 [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential 229 Forwarding Status Bit", RFC 6870, February 2013. 231 [RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., 232 Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS- 233 TP) Linear Protection to Match the Operational 234 Expectations of Synchronous Digital Hierarchy, Optical 235 Transport Network, and Ethernet Transport Network 236 Operators", RFC 7271, June 2014. 238 [RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear 239 Protection", RFC 7324, July 2014. 241 7.2. Informative References 243 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 244 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 245 October 2009. 247 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 248 Redundancy", RFC 6718, August 2012. 250 Appendix A. Optional Linear Protection Approach 252 A.1. Introduction 254 In "MPLS Transport Profile (MPLS-TP) Linear Protection" [RFC6378], as 255 well as in the later updates of this RFC in "MPLS Transport Profile 256 (MPLS-TP) Linear Protection to Match the Operational Expectations of 257 SDH, OTN and Ethernet Transport Network Operators" [RFC7271] and in 258 "Updates to MPLS Transport Profile Linear Protection" [RFC7324], the 259 Protection State Coordination (PSC) protocol was defined for MPLS 260 LSPs only. 262 This Appendix extends these RFCs to be applicable for PWs (SS-PW and 263 MS-PW) as well. This is useful especially in the case of end-to-end 264 static provisioned MS-PWs running over MPLS-TP where tunnel 265 protection alone cannot be relied upon for end-to-end protection of 266 PWs against S-PE failure. It also enables a uniform operational 267 approach for protection at LSP and PW layers and an easier management 268 integration for networks that already use RFCs 6378, 7271, and 7324. 270 This Appendix is optional alternative approach to the one in 271 Section 2, therefore all implementations MUST include the approach in 272 Section 2 even if this alternative approach is used. The operational 273 considerations in Section 3 continue to apply when this approach is 274 used, and operational care must be taken so that the endpoint T-PEs 275 are identically provisioned regarding the use of this document. 277 A.2. Encapsulation of the PSC Protocol for Pseudowires 279 The PSC protocol can be used to protect against defects on any LSP 280 (segment, link or path). In the case of MS-PW, the PSC protocol can 281 also protect failed intermediate nodes (S-PE). Linear protection 282 protects an LSP or PW end-to-end and if a failure is detected, 283 switches traffic over to another (redundant) set of resources. 285 Obviously, the protected entity does not need to be of the same type 286 as the protecting. For example, it is possible to protect a link by 287 a path. Likewise it is possible to protect a SS-PW with a MS-PW and 288 vice versa. 290 From a PSC protocol point of view it is possible to view a SS-PW as a 291 single hop LSP, and a MS-PW as a multiple hop LSP. Thus, this 292 provides end-to-end protection for the SS-PW or MS-PW. The G-ACh 293 carrying the PSC protocol information is placed in the label stack 294 directly beneath the PW identifier. The PSC protocol will then work 295 as specified in RFCs 6378, 7271, and 7324. 297 Authors' Addresses 299 Andrew G. Malis 300 Huawei Technologies Co., Ltd 302 Email: agmalis@gmail.com 304 Loa Andersson 305 Huawei Technologies Co., Ltd 307 Email: loa@mail01.huawei.com 308 Huub van Helvoort 309 Hai Gaoming BV 311 Email: huubatwork@gmail.com 313 Jongyoon Shin 314 SK Telecom 316 Email: jongyoon.shin@sk.com 318 Lei Wang 319 China Mobile 321 Email: wangleiyj@chinamobile.com 323 Alessandro D'Alessandro 324 Telecom Italia 326 Email: alessandro.dalessandro@telecomitalia.it