idnits 2.17.1 draft-ietf-pwe3-redundancy-spe-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 abstract seems to contain references ([RFC6870]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2014) is 3624 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) == Unused Reference: 'RFC3985' is defined on line 309, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft H. Wang 4 Intended status: Standards Track Huawei Technologies 5 Expires: November 24, 2014 May 23, 2014 7 Pseudowire Redundancy on S-PE 8 draft-ietf-pwe3-redundancy-spe-02 10 Abstract 12 This document describes Multi-Segment Pseudowire (MS-PW) protection 13 scenarios in which the pseudowire redundancy is provided on the 14 Switching-PE (S-PE). Operations of the S-PEs which provide PW 15 redundancy are specified in this document. Signaling of the 16 preferential forwarding status as defined in [RFC6870] is reused. 17 This document does not require any change to the T-PEs of MS-PW. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 24, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Typical Scenarios of PW Redundancy on S-PE . . . . . . . . . 2 61 2.1. MS-PW Redundancy on S-PE . . . . . . . . . . . . . . . . 3 62 2.2. MS-PW Redundancy on S-PE with S-PE Protection . . . . . . 3 63 3. S-PE Operations . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Operations of Scenario 1 . . . . . . . . . . . . . . . . 5 65 3.2. Operations of Scenario 2 . . . . . . . . . . . . . . . . 5 66 4. VCCV Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 [RFC6718] describes the framework and requirements for pseudowire 78 (PW) redundancy, and [RFC6870] specifies Pseudowire (PW) redundancy 79 mechanism for scenarios where a set of redundant PWs is configured 80 between provider edge (PE) nodes in single-segment pseudowire (SS-PW) 81 [RFC3985]applications, or between terminating provider edge (T-PE) 82 nodes in multi-segment pseudowire (MS-PW) [RFC5659] applications. 84 In some MS-PW scenarios, there are benefits to provide PW redundancy 85 on S-PEs, such as reducing the burden on the access T-PE nodes, and 86 faster protection switching. This document describes some scenarios 87 in which PW redundancy is provided on S-PEs, and specifies the 88 operations of the S-PEs. Signaling of the preferential forwarding 89 status as defined in [RFC6870] is reused. This document does not 90 require any change to the T-PEs of MS-PW. 92 2. Typical Scenarios of PW Redundancy on S-PE 94 In some MS-PW deployment scenarios, there are benefits to provide PW 95 redundancy on S-PEs. This section describes typical scenarios of PW 96 redundancy on S-PE. 98 2.1. MS-PW Redundancy on S-PE 100 +-----+ 101 +---+ +-----+ | | +---+ 102 | | | |------|T-PE2|----| | 103 | | +-----+ | ..PW-Seg2.......| | | 104 | | |....PW-Seg1..... | +-----+ | | 105 |CE1|----|T-PE1|------|S-PE1| |CE2| 106 | | | | | . | +-----+ | | 107 | | +-----+ | ..PW-Seg3.......| | | 108 | | | |------|T-PE3|----| | 109 +---+ +-----+ | | +---+ 110 +-----+ 111 Figure 1.MS-PW Redundancy on S-PE 113 As illustrated in Figure 1, CE1 is connected to T-PE1 while CE2 is 114 dual-homed to T-PE2 and T-PE3. T-PE1 is connected to S-PE1 only, and 115 S-PE1 is connected to both T-PE2 and T-PE3. The MS-PW is switched on 116 S-PE1, and PW-Seg2 and PW-Seg3 provides resiliency on S-PE1 for 117 failure of T-PE2 or T-PE3 or the connected ACs. PW-Seg2 is selected 118 as primary PW segment, and PW-Seg3 is secondary PW segment. 120 MS-PW redundancy on S-PE is beneficial for the scenario in Figure 1 121 since T-PE1 as an access node may not be able to provide PW 122 redundancy, especially when the PW-Seg1 between T-PE1 and S-PE1 is 123 statically configured. And with PW redundancy on S-PE, the number of 124 PW segments required between T-PE1 and S-PE1 is only half of the 125 number of PW segments needed when using end-to-end MS-PW redundancy. 126 In addition, in this scenario PW redundancy on S-PE could provide 127 faster protection switching, compared with end-to-end protection 128 switching of MS-PW. 130 2.2. MS-PW Redundancy on S-PE with S-PE Protection 131 +---+ +-----+ +-----+ +-----+ 132 | | | | | | | | 133 | | |......PW1-Seg1......PW1-Seg2........| 134 | | | . | | | 135 |CE1|----|T-PE1|------|S-PE1|-----------|T-PE2| 136 | | | . | | . | PW1-Seg3 | | +---+ 137 | | +---.-+ | ......... ......|----| | 138 | | |. | | . .| | | | 139 +---+ |. +-----+ . . +-----+ | | 140 |. . . |CE2| 141 |. .. | | 142 |. +-----+ . . +-----+ | | 143 |. | | . .| |----| | 144 |...PW2-Seg1.......... ......| +---+ 145 | | . | PW2-Seg2 | | 146 ----------|S-PE2|-----------|T-PE3| 147 | . | | | 148 | .....PW2-Seg3........| 149 | | | | 150 +-----+ +-----+ 151 Figure 2. MS-PW Redundancy on S-PE with S-PE protection 153 As illustrated in Figure 2, CE1 is connected to T-PE1 while CE2 is 154 dual-homed to T-PE2 and T-PE3. T-PE1 is connected to S-PE1 and 155 S-PE2, and both S-PE1 and S-PE2 are connected to both T-PE2 and 156 T-PE3. There are two MS-PWs which are switched at S-PE1 and S-PE2 157 respectively to provide S-PE node protection. For MS-PW1, S-PE1 158 provides resiliency using PW1-Seg2 and PW1-Seg3. For MS-PW2, S-PE2 159 provides resiliency using PW2-Seg2 and PW2-Seg3. MS-PW1 is the 160 primary PW and PW1-Seg2 between S-PE1 and T-PE2 is the primary PW 161 segment. MS-PW2 is the secondary PW. 163 MS-PW redundancy on S-PE is beneficial for this scenario since it 164 reduces the number of end-to-end MS-PWs required for both T-PE and 165 S-PE protection. In addition, PW redundancy on S-PE could provide 166 faster protection switching, compared with end-to-end protection 167 switching of MS-PW. 169 3. S-PE Operations 171 For an S-PE which provides PW redundancy for MS-PW, it is important 172 to advertise proper preferential forwarding status to the PW segments 173 on both sides and perform protection switching according to the 174 received status information. This section specifies the operations 175 of S-PEs on which PW redundancy is provisioned. This document does 176 not make any change to the T-PEs of MS-PW. 178 In general, the S-PE SHOULD work as a Slave node for the single- 179 connected side, and SHOULD work in Independent mode for the multi- 180 connected side. The S-PE SHOULD pass the preferential forwarding 181 status received from the single-connected side unchanged to the PW 182 segments on the multi-connected side. The S-PE SHOULD advertise 183 Standby status to the single-connected side if it receives Standby 184 status from all the PW segments on the multi-connected side, and it 185 SHOULD advertise Active status to the single-connected side if it 186 receives Active status from any of the PW segments on the multi- 187 connected side. For the single-connected side, the active PW segment 188 is determined by the T-PE on this side, which works as the Master 189 node. On the multi-connected side, the PW segment which has both 190 local and remote Up/Down status and Preferential Forwarding status as 191 Up and Active SHOULD be selected for traffic forwarding. 193 The Signaling of Preferential Forwarding bit defined in [RFC6870] is 194 reused in these scenarios. 196 3.1. Operations of Scenario 1 198 For the scenario in Figure 1, assume the AC from CE2 to T-PE2 is 199 active. In normal operation, S-PE1 would receive Active Preferential 200 Forwarding status bit on the single-connected side from T-PE1, then 201 it would advertise Active Preferential Forwarding status bit on both 202 PW-Seg2 and PW-Seg3. T-PE2 and T-PE3 would advertise Active and 203 Standby preferential status bit respectively to S-PE1, reflecting the 204 forwarding state of the two ACs to CE2. By matching the local and 205 remote Up/Down status and Preferential Forwarding status, PW-Seg2 206 would be used for traffic forwarding. 208 On failure of the AC between CE2 and T-PE2, the forwarding state of 209 AC on T-PE3 is changed to Active. T-PE3 then advertises Active 210 Preferential Status to S-PE1, and T-PE2 would advertise a PW status 211 Notification message to S-PE1, indicating that the AC between CE2 and 212 T-PE2 is down. S-PE1 would perform the switchover according to the 213 updated local and remote Preferential Forwarding status and status of 214 "Pseudowire forwarding", and select PW-Seg3 as the new PW Segment for 215 traffic forwarding. Since S-PE1 still connects to an Active PW 216 segment on the multi-connected side, it will not advertise any change 217 of the PW status to T-PE1. S-PE1 may advertise the updated Switching 218 Point PE TLVs (SP-PE TLVs) [RFC6073] using Label Mapping message to 219 T-PE1. 221 3.2. Operations of Scenario 2 223 For the scenario of Figure 2, assume the AC from CE2 to T-PE2 is 224 active. T-PE1 works in Master mode and it would advertise Active and 225 Standby Preferential Forwarding status bit respectively to S-PE1 and 226 S-PE2 according to configuration. According to the received 227 Preferential Forwarding status bit, S-PE1 would advertise Active 228 Preferential Forwarding status bit to both T-PE2 and T-PE3, and S-PE2 229 would advertise Standby Preferential Forwarding status bit to both 230 T-PE2 and T-PE3. T-PE2 would advertise Active Preferential 231 Forwarding status bit to both S-PE1 and S-PE2, and T-PE3 would 232 advertise Standby Preferential Forwarding status bit to both S-PE1 233 and S-PE2, reflecting the forwarding state of the two ACs to CE2. By 234 matching the local and remote Up/Down Status and Preferential 235 Forwarding status, PW1-Seg2 from S-PE1 to T-PE2 would be used for 236 traffic forwarding. Since S-PE1 connects to the Active PW segment on 237 the multi-connected side, it would advertise Active Preferential 238 Forwarding status bit to T-PE1, and S-PE2 would advertise Standby 239 Preferential Forwarding status bit to T-PE1 since it does not have 240 any Active PW segment on the multi-connected side. 242 On failure of the AC between CE2 and T-PE2, the forwarding state of 243 AC on T-PE3 is changed to Active. T-PE3 would then advertise Active 244 Preferential Forwarding status bit to both S-PE1 and S-PE2, and T-PE2 245 would advertise a PW status Notification message to both S-PE1 and 246 S-PE2, indicating that the AC between CE2 and T-PE2 is down. S-PE1 247 would perform the switchover according to the updated local and 248 remote Preferential Forwarding status and status of "Pseudowire 249 forwarding", and select PW1-Seg3 for traffic forwarding. Since S-PE1 250 still has an Active PW segment on the multi-connected side, it would 251 not advertise any change of the PW status to T-PE1. S-PE1 may 252 advertise the updated SP-PE TLVs [RFC6073] using Label Mapping 253 message to T-PE1. 255 If S-PE1 fails, T-PE1 would notice this through some kind of 256 detection mechanism and then advertise the Active Preferential 257 Forwarding status bit to S-PE2, and PW2-Seg1 would be selected by 258 T-PE1 for traffic forwarding. On receipt of the newly changed 259 Preferential Forwarding status, S-PE2 would advertise the Active 260 Preferential Forwarding status to both T-PE2 and T-PE3. T-PE2 and 261 T-PE3 would also notice the failure of S-PE1 by some kind of 262 detection mechanism. Then by matching the local and remote Up/Down 263 and Preferential Forwarding status, PW2-Seg2 would be selected for 264 traffic forwarding. 266 4. VCCV Considerations 268 PW VCCV [RFC5085] CC type 1 "PW ACH" can be used with S-PE redundancy 269 mechanism. VCCV CC type 2 "Router Alert Label" is not supported for 270 MS-PW as specified in [RFC6073]. If VCCV CC type 3 "TTL Expiry" is 271 to be used, the hop count from one T-PE to the remote T-PE needs to 272 be obtained in advance. This can be achieved either by control plane 273 SP-PE TLVs or through data plane tracing of the MS-PW. 275 5. IANA Considerations 277 This document makes no request of IANA. 279 6. Security Considerations 281 This document has the same security properties as in the PWE3 control 282 protocol [RFC4447] and [RFC6870]. 284 7. Acknowledgements 286 The authors would like to thank Mach Chen, Lizhong Jin, Mustapha 287 Aissaoui, Luca Martini, Matthew Bocci and Stewart Bryant for their 288 valuable comments and discussions. 290 8. References 292 8.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 298 Heron, "Pseudowire Setup and Maintenance Using the Label 299 Distribution Protocol (LDP)", RFC 4447, April 2006. 301 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 302 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 304 [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential 305 Forwarding Status Bit", RFC 6870, February 2013. 307 8.2. Informative References 309 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 310 Edge (PWE3) Architecture", RFC 3985, March 2005. 312 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 313 Connectivity Verification (VCCV): A Control Channel for 314 Pseudowires", RFC 5085, December 2007. 316 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 317 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 318 October 2009. 320 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 321 Redundancy", RFC 6718, August 2012. 323 Authors' Addresses 325 Jie Dong 326 Huawei Technologies 327 Huawei Building, No.156 Beiqing Rd. 328 Beijing 100095 329 China 331 Email: jie.dong@huawei.com 333 Haibo Wang 334 Huawei Technologies 335 Huawei Building, No.156 Beiqing Rd. 336 Beijing 100095 337 China 339 Email: rainsword.wang@huawei.com