idnits 2.17.00 (12 Aug 2021) /tmp/idnits41950/draft-ietf-pals-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2015) is 2482 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: February 5, 2016 August 4, 2015 7 Pseudowire Redundancy on S-PE 8 draft-ietf-pals-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 RFC 6870 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 February 5, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . 6 66 4. VCCV Considerations . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 8 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 enabling faster protection switching compared to the end-to-end MS-PW 87 protection mechanisms. This document describes some scenarios in 88 which PW redundancy is provided on S-PEs, and specifies the 89 operations of the S-PEs. Signaling of the preferential forwarding 90 status as defined in [RFC6870] is reused. This document does not 91 require any change to the T-PEs of MS-PW. 93 2. Typical Scenarios of PW Redundancy on S-PE 95 In some MS-PW deployment scenarios, there are benefits to provide PW 96 redundancy on S-PEs. This section describes typical scenarios of PW 97 redundancy on S-PE. 99 2.1. MS-PW Redundancy on S-PE 101 +-----+ 102 +---+ +-----+ | | +---+ 103 | | | |------|T-PE2|----| | 104 | | +-----+ | ..PW-Seg2.......| | | 105 | | |....PW-Seg1..... | +-----+ | | 106 |CE1|----|T-PE1|------|S-PE1| |CE2| 107 | | | | | . | +-----+ | | 108 | | +-----+ | ..PW-Seg3.......| | | 109 | | | |------|T-PE3|----| | 110 +---+ +-----+ | | +---+ 111 +-----+ 112 Figure 1.MS-PW Redundancy on S-PE 114 As illustrated in Figure 1, CE1 is connected to T-PE1 while CE2 is 115 dual-homed to T-PE2 and T-PE3. T-PE1 is connected to S-PE1 only, and 116 S-PE1 is connected to both T-PE2 and T-PE3. The MS-PW is switched on 117 S-PE1, and PW-Seg2 and PW-Seg3 provides resiliency on S-PE1 for 118 failure of T-PE2 or T-PE3 or the connected ACs. PW-Seg2 is selected 119 as the primary PW segment, and PW-Seg3 is the secondary PW segment. 121 MS-PW redundancy on S-PE is beneficial for the scenario in Figure 1 122 since T-PE1 as an access node may not support PW redundancy. 123 Besides, with PW redundancy on S-PE, the number of PW segments 124 required between T-PE1 and S-PE1 is only half of the number of PW 125 segments needed when end-to-end MS-PW redundancy is used. In 126 addition, in this scenario PW redundancy on S-PE could provide faster 127 protection switching, compared with end-to-end protection switching 128 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. Note that when PW redundancy for MS-PW 175 is provided on S-PE, the optional S-PE Bypass Mode as defined in 176 [RFC6478] MUST NOT be used. This section specifies the operations of 177 S-PEs on which PW redundancy is provisioned. This section does not 178 make any change to the T-PEs of MS-PW. 180 The S-PEs connect to the neighboring T-PEs or other S-PEs on two 181 sides with PW segments. For the S-PE which provides PW redundancy 182 for an MS-PW, on one side there is a single PW segment, which is 183 called the single-homed side, and on the other side there are 184 multiple PW segments, which is called the multi-homed side. The 185 scenario in which the S-PE has two multi-homed sides is out of scope. 187 In general, the S-PE MUST work as a Slave node for the single-homed 188 side, and MUST work in Independent mode for the multi-homed side. 189 Consequently, The T-PE on the single-homed side MUST work in the 190 Master mode, and the T-PEs on the multi-homed side MUST work in the 191 Independent mode. The S-PE MUST pass the preferential forwarding 192 status received from the single-homed side unchanged to the PW 193 segments on the multi-homed side. The S-PE MUST advertise Standby 194 status to the single-homed side if it receives Standby status from 195 all the PW segments on the multi-homed side, and it MUST advertise 196 Active status to the single-homed side if it receives Active status 197 from any of the PW segments on the multi-homed side. For the single- 198 homed side, the active PW segment is determined by the T-PE on this 199 side, which works as the Master node. On the multi-homed side, since 200 both the S-PE and T-PEs work in the Independent mode, the PW segment 201 which has both local and remote Up/Down status and Preferential 202 Forwarding status as Up and Active MUST be selected for traffic 203 forwarding. 205 The Signaling of Preferential Forwarding bit as defined in [RFC6870] 206 and [RFC6478] is reused in these scenarios. 208 3.1. Operations of Scenario 1 210 For the scenario in Figure 1, assume the AC from CE2 to T-PE2 is 211 active. In normal operation, S-PE1 would receive Active Preferential 212 Forwarding status bit on the single-homed side from T-PE1, then it 213 would advertise Active Preferential Forwarding status bit on both PW- 214 Seg2 and PW-Seg3. T-PE2 and T-PE3 would advertise Active and Standby 215 preferential status bit to S-PE1 respectively, reflecting the 216 forwarding state of the two ACs connected to CE2. By matching the 217 local and remote Up/Down status and Preferential Forwarding status, 218 PW-Seg2 would be used for traffic forwarding. 220 On failure of the AC between CE2 and T-PE2, the forwarding state of 221 AC on T-PE3 is changed to Active. T-PE3 then advertises Active 222 Preferential Status to S-PE1, and T-PE2 would advertise a PW status 223 Notification message to S-PE1, indicating that the AC between CE2 and 224 T-PE2 is down. S-PE1 would perform the switchover according to the 225 updated local and remote Preferential Forwarding status and the 226 status of "Pseudowire forwarding", and select PW-Seg3 as the new PW 227 Segment for traffic forwarding. Since S-PE1 still connects to an 228 Active PW segment on the multi-homed side, it will not advertise any 229 change of the PW status to T-PE1. If S-PE1 supports the SP-PE TLV 230 processing as defined in [RFC6073], it SHOULD advertise the updated 231 SP-PE TLVs by sending a Label Mapping message to T-PE1. 233 3.2. Operations of Scenario 2 235 For the scenario of Figure 2, assume the AC from CE2 to T-PE2 is 236 active. T-PE1 works in Master mode and it would advertise Active and 237 Standby Preferential Forwarding status bit respectively to S-PE1 and 238 S-PE2 according to configuration. According to the received 239 Preferential Forwarding status bit, S-PE1 would advertise Active 240 Preferential Forwarding status bit to both T-PE2 and T-PE3, and S-PE2 241 would advertise Standby Preferential Forwarding status bit to both 242 T-PE2 and T-PE3. T-PE2 would advertise Active Preferential 243 Forwarding status bit to both S-PE1 and S-PE2, and T-PE3 would 244 advertise Standby Preferential Forwarding status bit to both S-PE1 245 and S-PE2, reflecting the forwarding state of the two ACs connected 246 to CE2. By matching the local and remote Up/Down Status and 247 Preferential Forwarding status, PW1-Seg2 from S-PE1 to T-PE2 would be 248 used for traffic forwarding. Since S-PE1 connects to the Active PW 249 segment on the multi-homed side, it would advertise Active 250 Preferential Forwarding status bit to T-PE1, and S-PE2 would 251 advertise Standby Preferential Forwarding status bit to T-PE1 since 252 it does not have any Active PW segment on the multi-homed side. 254 On failure of the AC between CE2 and T-PE2, the forwarding state of 255 AC on T-PE3 is changed to Active. T-PE3 would then advertise Active 256 Preferential Forwarding status bit to both S-PE1 and S-PE2, and T-PE2 257 would advertise a PW status Notification message to both S-PE1 and 258 S-PE2, indicating that the AC between CE2 and T-PE2 is down. S-PE1 259 would perform the switchover according to the updated local and 260 remote Preferential Forwarding status and the status of "Pseudowire 261 forwarding", and select PW1-Seg3 for traffic forwarding. Since S-PE1 262 still has an Active PW segment on the multi-homed side, it would not 263 advertise any change of the PW status to T-PE1. If S-PE1 supports 264 the SP-PE TLV processing as defined in [RFC6073], it SHOULD advertise 265 the updated SP-PE TLVs by sending a Label Mapping message to T-PE1. 267 If S-PE1 fails, T-PE1 would notice this through some detection 268 mechanism and then advertise the Active Preferential Forwarding 269 status bit to S-PE2, and PW2-Seg1 would be selected by T-PE1 for 270 traffic forwarding. On receipt of the newly changed Preferential 271 Forwarding status, S-PE2 would advertise the Active Preferential 272 Forwarding status to both T-PE2 and T-PE3. T-PE2 and T-PE3 would 273 also notice the failure of S-PE1 by some detection mechanism. Then 274 by matching the local and remote Up/Down and Preferential Forwarding 275 status, PW2-Seg2 would be selected for traffic forwarding. 277 4. VCCV Considerations 279 PW VCCV [RFC5085] CC type 1 "PW ACH" can be used with S-PE redundancy 280 mechanism. VCCV CC type 2 "Router Alert Label" is not supported for 281 MS-PW as specified in [RFC6073]. If VCCV CC type 3 "TTL Expiry" is 282 to be used, the PW label TTL MUST be set to the appropriate value to 283 reach the target PE. The hop count from one T-PE to the target PE 284 can be obtained either via SP-PE TLVs, through MS-PW path trace or 285 based on management plane information. 287 5. IANA Considerations 289 This document makes no request of IANA. 291 6. Security Considerations 293 This document specifies the mechanisms of providing PW redundancy on 294 the S-PEs of MS-PWs. The security considerations specified in 295 [RFC4447], [RFC6073], [RFC6870] and [RFC6478] apply to this document. 297 7. Acknowledgements 299 The authors would like to thank Mach Chen, Lizhong Jin, Mustapha 300 Aissaoui, Luca Martini, Matthew Bocci and Stewart Bryant for their 301 valuable comments and discussions. 303 8. References 305 8.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 313 G. Heron, "Pseudowire Setup and Maintenance Using the 314 Label Distribution Protocol (LDP)", RFC 4447, 315 DOI 10.17487/RFC4447, April 2006, 316 . 318 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 319 Aissaoui, "Segmented Pseudowire", RFC 6073, 320 DOI 10.17487/RFC6073, January 2011, 321 . 323 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 324 "Pseudowire Status for Static Pseudowires", RFC 6478, 325 DOI 10.17487/RFC6478, May 2012, 326 . 328 [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire 329 Preferential Forwarding Status Bit", RFC 6870, 330 DOI 10.17487/RFC6870, February 2013, 331 . 333 8.2. Informative References 335 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 336 Edge-to-Edge (PWE3) Architecture", RFC 3985, 337 DOI 10.17487/RFC3985, March 2005, 338 . 340 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 341 Circuit Connectivity Verification (VCCV): A Control 342 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 343 December 2007, . 345 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 346 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 347 DOI 10.17487/RFC5659, October 2009, 348 . 350 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 351 Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, 352 . 354 Authors' Addresses 356 Jie Dong 357 Huawei Technologies 358 Huawei Building, No.156 Beiqing Rd. 359 Beijing 100095 360 China 362 Email: jie.dong@huawei.com 363 Haibo Wang 364 Huawei Technologies 365 Huawei Building, No.156 Beiqing Rd. 366 Beijing 100095 367 China 369 Email: rainsword.wang@huawei.com