idnits 2.17.1 draft-ietf-pwe3-redundancy-09.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 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 27, 2012) is 4320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6073' is defined on line 766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Muley 3 Internet-Draft M. Aissaoui 4 Intended status: Informational M. Bocci 5 Expires: December 29, 2012 Alcatel-Lucent 6 June 27, 2012 8 Pseudowire Redundancy 9 draft-ietf-pwe3-redundancy-09 11 Abstract 13 This document describes a framework comprised of a number of 14 scenarios and associated requirements for pseudowire (PW) redundancy. 15 A set of redundant PWs is configured between provider edge (PE) nodes 16 in single -segment PW applications, or between terminating PE (T-PE) 17 nodes in multi-segment PW applications. In order for the PE/T-PE 18 nodes to indicate the preferred PW to use for forwarding PW packets 19 to one another, a new PW status is required to indicate the 20 preferential forwarding status of active or standby for each PW in 21 the redundant set. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 29, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. PW Redundancy Network Reference Scenarios . . . . . . . . 6 68 3.2.1. PW Redundancy for AC and PE Protection: One 69 Dual-Homed CE with Redundant SS-PWs . . . . . . . . . 6 70 3.2.2. PW Redundancy for AC and PE Protection: Two 71 Dual-Homed CEs with Redundant SS-PWs . . . . . . . . . 8 72 3.2.3. PW Redundancy for S-PE Protection: Single-Homed 73 CEs with Redundant MS-PWs . . . . . . . . . . . . . . 9 74 3.2.4. PW Redundancy for PE-rs Protection in H-VPLS using 75 SS-PWs . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2.5. PW Redundancy for PE Protection in a VPLS Ring 77 using SS-PWs . . . . . . . . . . . . . . . . . . . . . 12 78 3.2.6. PW Redundancy for VPLS n-PE Protection using SS-PWs . 13 79 4. Generic PW Redundancy Requirements . . . . . . . . . . . . . . 15 80 4.1. Protection Switching Requirements . . . . . . . . . . . . 15 81 4.2. Operational Requirements . . . . . . . . . . . . . . . . . 15 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 16 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The objective of pseudowire (PW) redundancy is to maintain 94 connectivity across the packet switched network (PSN) used by the 95 emulated service if a component in the path of the emulated service 96 fails or a backup component is activated. For example, PW redundancy 97 will enable the correct PW to be used for forwarding emulated service 98 packets when the connectivity of an attachment circuit (AC) changes 99 due to the failure of an AC, or when a pseudowire (PW) or packet 100 switched network (PSN) tunnel fails due to the failure of a provider 101 edge (PE) node. 103 PW redundancy uses redundant ACs, PEs, and PWs to eliminate single 104 points of failure in the path of an emulated service. This is 105 achieved while ensuring that only one path between a pair of customer 106 edge nodes (CEs) is active at any given time. Mechanisms that rely 107 on more than one active path between the CEs e.g. 1+1 protection 108 switching, are out of scope of this document because they may require 109 a permanent bridge to provide traffic replication as well as support 110 for a 1+1 protection switching protocol in the CEs. 112 Protection for a PW segment can be provided by the PSN layer. This 113 may be a resource reservation protocol with traffic engineering 114 (RSVP-TE) labeled switched path (LSP) with a fast-reroute (FRR) 115 backup or an end-to-end backup LSP. These mechanisms can restore PSN 116 connectivity rapidly enough to avoid triggering protection by PW 117 redundancy. PSN protection mechanisms cannot protect against the 118 failure of a PE node or the failure of the remote AC. Typically, 119 this is supported by dual-homing a customer edge (CE) node to 120 different PE nodes which provide a pseudowire emulated service across 121 the PSN. A set of PW mechanisms is therefore required that enables a 122 primary and one or more backup PWs to terminate on different PE 123 nodes. An important requirement is that changes occurring on the 124 dual-homed side of the network due to the failure of an AC or PE are 125 not propagated to the ACs on the other side of the network. 126 Furthermore, failures in the PSN are not propagated to the attached 127 CEs. 129 In cases where PSN protection mechanisms are not able to recover from 130 a PSN failure, or where a failure of a switching PE (S-PE) may occur, 131 a set of mechanisms that support the operation of a primary and one 132 or more backup PWs via a different set of S-PEs or diverse PSN 133 tunnels is therefore required. For multi-segment PWs (MS-PWs), the 134 paths of these PWs are diverse in that they are switched at different 135 S-PE nodes. 137 In both of these cases, PW redundancy is important to maximise the 138 resiliency of the emulated service. It supplements PSN protection 139 techniques and can operate in addition to, or instead of those 140 techniques when they are not available. 142 This document describes a framework for these applications and its 143 associated operational requirements. The framework utilizes a new PW 144 status, called the Preferential Forwarding Status of the PW. This is 145 separate from the operational states defined in RFC4446 [RFC4446]. 146 The mechanisms for PW redundancy are modeled on general protection 147 switching principles. 149 2. Terminology 151 o Up PW: A PW which has been configured (label mapping exchanged 152 between PEs) and is not in any of the PW or AC defect states 153 specified in [RFC4446]. Such a PW is available for forwarding 154 traffic. 156 o Down PW: A PW that has either not been fully configured, or has 157 been configured and is in any one of the PW or AC defect states 158 specified in [RFC4446]. Such a PW is not available for forwarding 159 traffic. 161 o Active PW: An up PW used for forwarding Operations, Administration 162 and Maintenance (OAM), user plane and control plane traffic. 164 o Standby PW: An up PW that is not used for forwarding user traffic 165 but may forward OAM and specific control plane traffic. 167 o PW Endpoint: A PE where a PW terminates on a point where native 168 service processing is performed, e.g., A single-segment PW (SS-PW) 169 PE, a multi-segment pseudowire (MS-PW) terminating PE (T-PE), or a 170 hierarchical VPLS MTU-s or PE-rs. 172 o Primary PW: The PW which a PW endpoint activates (i.e. uses for 173 forwarding) in preference to any other PW when more than one PW 174 qualifies for the active state. When the primary PW comes back up 175 after a failure and qualifies for the active state, the PW 176 endpoint always reverts to it. The designation of primary is 177 performed by local configuration for the PW at the PE and is only 178 required when revertive behaviour is used and is not applicable 179 when non-revertive protection switching is used. 181 o Secondary PW: When it qualifies for the active state, a secondary 182 PW is only selected if no primary PW is configured or if the 183 configured primary PW does not qualify for active state (e.g., is 184 down). By default, a PW in a redundancy PW set is considered 185 secondary. There is no revertive mechanism among secondary PWs. 187 o Revertive protection switching: Traffic will be carried by the 188 primary PW if all of the following is true: It is up, a wait-to- 189 restore timer expires, and the primary PW is made the active PW. 191 o Non-revertive protection switching: Traffic will be carried by the 192 last PW selected as a result of previous active PW entering the 193 operationally down state. 195 o Manual selection of a PW: The ability to manually select the 196 primary/secondary PWs. 198 o MTU-s: A hierarchical virtual private LAN service multi-tenant 199 unit switch, as defined in RFC4762 [RFC4762]. 201 o PE-rs: A hierarchical virtual private LAN service switch, as 202 defined in RFC4762. 204 o n-PE: A network facing provider edge node, as defined in RFC4026 205 [RFC4026]. 207 o 1:1 protection: One specific subset of a path for an emulated 208 service, consisting of a standby PW and/or AC, protects another 209 specific subset of a path for the emulated service. User traffic 210 is transmitted over only one specific subset of the path at a 211 time. 213 o N:1 protection: N specific subsets of paths for an emulated 214 service, consisting of standby PWs and/or ACs, protect another 215 specific subset of the path for the emulated service. User 216 traffic is transmitted over only one specific subset of the path 217 at a time. 219 o 1+1 protection: One specific subset of a path for an emulated 220 service, consisting of a standby PW and/or AC, protects another 221 specific subset of a path for the emulated service. Traffic is 222 permanently duplicated at the ingress node on both the currently 223 active and standby subsets of the paths. 225 This document uses the term 'PE' to be synonymous with both PEs as 226 per RFC3985[RFC3985] and T-PEs as per RFC5659 [RFC5659]. 228 This document uses the term 'PW' to be synonymous with both PWs as 229 per RFC3985 and SS-PWs, MS-PWs, and PW segments as per RFC5659. 231 3. Reference Models 233 The following sections show the reference architecture of the PE for 234 PW redundancy and the usage of the architecture in different 235 topologies and applications. 237 3.1. PE Architecture 239 Figure 1 shows the PE architecture for PW redundancy when more than 240 one PW in a redundant set is associated with a single AC. This is 241 based on the architecture in Figure 4b of RFC3985 [RFC3985]. The 242 forwarder selects which of the redundant PWs to use based on the 243 criteria described in this document. 245 +----------------------------------------+ 246 | PE Device | 247 +----------------------------------------+ 248 Single | | Single | PW Instance 249 AC | + PW Instance X<===========> 250 | | | 251 | |----------------------| 252 <------>o | Single | PW Instance 253 | Forwarder + PW Instance X<===========> 254 | | | 255 | |----------------------| 256 | | Single | PW Instance 257 | + PW Instance X<===========> 258 | | | 259 +----------------------------------------+ 261 Figure 1: PE Architecture for PW redundancy 263 3.2. PW Redundancy Network Reference Scenarios 265 This section presents a set of reference scenarios for PW redundancy. 266 These reference scenarios represent example network topologies that 267 illustrate the use of PW redundancy. They can be combined together 268 to create more complex or comprehensive topologies, as required by a 269 particular application or deployment. 271 3.2.1. PW Redundancy for AC and PE Protection: One Dual-Homed CE with 272 Redundant SS-PWs 274 Figure 2 illustrates an application of single segment pseudowire 275 redundancy where one of the CEs is dual-homed. This scenario is 276 designed to protect the emulated service against a failure of one of 277 the PEs or ACs attached to the multi-homed CE. Protection against 278 failures of the PSN tunnels is provided using PSN mechanisms such as 279 MPLS fast reroute, so that these failures do not impact the PW. 281 CE1 is dual-homed to PE1 and PE3. A dual homing control protocol, 282 the details of which are outside the scope of this document, enables 283 the PEs and CEs to determine which PE (PE1 or PE3) should forward 284 towards CE1, and therefore which AC CE1 should use to forward towards 285 the PSN. 287 |<-------------- Emulated Service ---------------->| 288 | | 289 | |<------- Pseudo Wire ------>| | 290 | | | | 291 | | |<-- PSN Tunnels-->| | | 292 | V V V V | 293 V AC +----+ +----+ AC V 294 +-----+ | | PE1|==================| | | +-----+ 295 | |----------|....|...PW1.(active)...|....|----------| | 296 | | | |==================| | | CE2 | 297 | CE1 | +----+ |PE2 | | | 298 | | +----+ | | +-----+ 299 | | | |==================| | 300 | |----------|....|...PW2.(standby)..| | 301 +-----+ | | PE3|==================| | 302 AC +----+ +----+ 304 Figure 2: One Dual-Homed CE and Redundant SS-PWs 306 In this scenario, only one of the PWs should be used for forwarding 307 between PE1 / PE3, and PE2. PW redundancy determines which PW to 308 make active based on the forwarding state of the ACs so that only one 309 path is available from CE1 to CE2. This requires an additional PW 310 state that reflects this forwarding state, which is separate from the 311 operational status of the PW. This is the 'Preferential Forwarding 312 Status'. 314 Consider the example where the AC from CE1 to PE1 is initially active 315 and the AC from CE1 to PE3 is initially standby. PW1 is made active 316 and PW2 is made standby in order to complete the path to CE2. 318 On failure of the AC between CE1 and PE1, the forwarding state of the 319 AC on PE3 transitions to active. The preferential forwarding state 320 of PW2 therefore needs to become active, and PW1 standby, in order to 321 reestablish connectivity between CE1 and CE2. PE3 therefore uses PW2 322 to forward towards CE2, and PE2 uses PW2 instead of PW1 to forward 323 towards CE1. PW redundancy in this scenario requires that the 324 forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so 325 that PE2 can choose which PW to make active. 327 Changes occurring on the dual-homed side of the network due to a 328 failure of the AC or PE are not propagated to the ACs on the other 329 side of the network. Furthermore, failures in the PSN are not 330 propagated to the attached CEs. 332 3.2.2. PW Redundancy for AC and PE Protection: Two Dual-Homed CEs with 333 Redundant SS-PWs 335 Figure 3 illustrates an application of single segment pseudowire 336 redundancy where both of the CEs are dual-homed. This scenario is 337 also designed to protect the emulated service against failures of the 338 ACs and failures of the PEs. Both CE1 and CE2, are dual-homed to 339 their respective PEs, PE1 and PE2, and PE3 and PE4. A dual homing 340 control protocol, the details of which are outside the scope of this 341 document, enables the PEs and CEs to determine which PEs should 342 forward towards the CEs, and therefore which ACs the CEs should use 343 to forward towards the PSN. 345 Note that the PSN tunnels are not shown in this figure for clarity. 346 However, it can be assumed that each of the PWs shown is encapsulated 347 in a separate PSN tunnel. Protection against failures of the PSN 348 tunnels is provided using PSN mechanisms such as MPLS fast reroute, 349 so that these failures do not impact the PW. 350 |<-------------- Emulated Service ---------------->| 351 | | 352 | |<------- Pseudowire ------->| | 353 | | | | 354 | | |<-- PSN Tunnels-->| | | 355 | V V V V | 356 V AC +----+ +----+ AC V 357 +-----+ | |....|.......PW1........|....| | +-----+ 358 | |----------| PE1|...... .........| PE3|----------| | 359 | CE1 | +----+ \ / PW3 +----+ | CE2 | 360 | | +----+ X +----+ | | 361 | | | |....../ \..PW4....| | | | 362 | |----------| PE2| | PE4|--------- | | 363 +-----+ | |....|.....PW2..........|....| | +-----+ 364 AC +----+ +----+ AC 366 Figure 3: Two Dual-Homed CEs and Redundant SS-PWs 368 PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PW2 369 and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3 and PW4 are all 370 up. In order to support protection for the emulated service, only 371 one PW MUST be selected to forward traffic. 373 If a PW has a preferential forwarding status of 'active', it can be 374 used for forwarding traffic. The actual up PW chosen by the combined 375 set of PEs connected to the CEs is determined by considering the 376 preferential forwarding status of each PW at each PE. The mechanisms 377 for communicating the preferential forwarding status are outside the 378 scope of this document. Only one PW is used for forwarding. 380 The following failure scenario illustrates the operation of PW 381 redundancy in Figure 3. In the initial steady state, when there are 382 no failures of the ACs, one of the PWs is chosen as the active PW, 383 and all others are chosen as standby. The dual-homing protocol 384 between CE1 and PE1/PE2 chooses to use the AC to PE2, while the 385 protocol between CE2 and PE3/PE4 chooses to use the AC to PE4. 386 Therefore the PW between PE2 and PE4 is chosen as the active PW to 387 complete the path between CE1 and CE2. 389 On failure of the AC between the dual-homed CE1 and PE2, the 390 preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4 391 needs to change so as to re-establish a path from CE1 to CE2. 392 Different mechanisms can be used to achieve this and these are beyond 393 the scope of this document. After the change in status, the 394 algorithm needs to evaluate and select which PW to forward traffic 395 on. In this application, each dual-homing algorithm, i.e., {CE1, 396 PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently. 397 There is therefore a need to signal the active status of each AC such 398 that the PEs can select a common active PW for forwarding between CE1 399 and CE2. 401 Changes occurring on one side of network due to a failure of the AC 402 or PE are not propagated to the ACs on the other side of the network. 403 Furthermore, failures in the PSN are not propagated to the attached 404 CEs. Note that end-to-end native service protection switching can 405 also be used to protect the emulated service in this scenario. In 406 this case, PW3 and PW4 are not necessary. 408 If the CEs do not perform native service protection switching, they 409 may instead use load balancing across the paths between the CEs. 411 3.2.3. PW Redundancy for S-PE Protection: Single-Homed CEs with 412 Redundant MS-PWs 414 Figure 4 shows a scenario where both CEs are single homed, and MS-PW 415 redundancy is used. The main objective is to protect the emulated 416 service against failures of the S-PEs. 418 Native |<----------- Pseudowires ----------->| Native 419 Service | | Service 420 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 421 | V V V V V V | 422 | +-----+ +-----+ +-----+ | 423 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 424 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 425 | CE1| | |=========| |=========| | | CE2| 426 | | +-----+ +-----+ +-----+ | | 427 +----+ |.||.| |.||.| +----+ 428 |.||.| +-----+ |.||.| 429 |.||.|=========| |========== .||.| 430 |.||...PW2-Seg1......|.PW2-Seg2...||.| 431 |.| ===========|S-PE2|============ |.| 432 |.| +-----+ |.| 433 |.|============+-----+============= .| 434 |.....PW3-Seg1.| | PW3-Seg2......| 435 ==============|S-PE3|=============== 436 | | 437 +-----+ 439 Figure 4: Single-Homed CE with Redundant MS-PWs 441 CE1 is connected to PE1 and CE2 is connected to PE2. There are three 442 multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched at 443 S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1 444 protection for the subset of the path of the emulated service from 445 T-PE1 to T-PE2. 447 Since there is no multi-homing running on the ACs, the T-PE nodes 448 advertise 'active' for the preferential forwarding status based on a 449 priority for the PW. The priority associates a meaning of 'primary 450 PW' and 'secondary PW' to a PW. These priorities MUST be used if 451 revertive mode is used and the active PW to use for forwarding 452 determined accordingly. The priority can be derived via 453 configuration or based on the value of the PW forwarding equivalence 454 class (FEC). For example, a lower value of PWid FEC can be taken as 455 a higher priority. However, this does not guarantee selection of 456 same PW by the T-PEs because of, for example, a mismatch in the 457 configuration of the PW priority at each T-PE. The intent of this 458 application is for T-PE1 and T-PE2 to synchronize the transmit and 459 receive paths of the PW over the network. In other words, both T-PE 460 nodes are required to transmit over the PW segment which is switched 461 by the same S-PE. This is desirable for ease of operation and 462 troubleshooting. 464 3.2.4. PW Redundancy for PE-rs Protection in H-VPLS using SS-PWs 466 The following figure (based on the architecture shown in Figure 3 of 467 [RFC4762]) illustrates the application of PW redundancy to 468 hierarchical VPLS (H-VPLS). Note that the PSN tunnels are not shown 469 for clarity, and only one PW of a PW group is shown. A multi-tenant 470 unit switch (MTU-s) is dual-homed to two PE router switches (PE-rs). 471 The example here uses SS-PWs and the objective is to protect the 472 emulated service against failures of a PE-rs. 474 PE1-rs 475 +--------+ 476 | VSI | 477 Active PW | -- | 478 Group..........|../ \..|. 479 CE-1 . | \ / | . 480 \ . | -- | . 481 \ . +--------+ . 482 \ MTU-s . . . PE3-rs 483 +--------+ . . . +--------+ 484 | VSI | . . H-VPlS .| VSI | 485 | -- ..|.. . Core |.. -- | 486 | / \ | . PWs | / \ | 487 | \ /..|.. . | \ / | 488 | -- | . . .|.. -- | 489 +--------+ . . . +--------+ 490 / . . . 491 / . +--------+ . 492 / . | VSI | . 493 CE-2 . | -- | . 494 ..........|../ \..|. 495 Standby PW | \ / | 496 Group | -- | 497 +--------+ 498 PE2-rs 500 Figure 5: MTU-s Dual Homing in H-VPLS Core 502 In Figure 5, the MTU-s is dual homed to PE1-rs and PE2-rs and has 503 spoke PWs to each of them. The MTU-s needs to choose only one of the 504 spoke PWs (the active PW) to forward traffic to one of the PEs, and 505 sets the other PW to standby. The MTU-s can derive the status of the 506 PWs based on local policy configuration. PE1-rs and PE2-rs are 507 connected to the H-VPLS core on the other side of network. The MTU-s 508 communicates the status of its member PWs for a set of virtual 509 switching instances (VSIs) that share a common status of active or 510 standby. Here, the MTU-s controls the selection of PWs used to 511 forward traffic. Signaling using PW grouping with a common group-id 512 in the PWid FEC Element, or a Grouping TLV in Generalized PWid FEC 513 Element as defined in [RFC4447], to PE1-rs and PE2-rs, is recommended 514 for improved scaling. 516 Whenever an MTU-s performs a switchover of the active PW group, it 517 needs to communicate this status change the PE2-rs. That is, it 518 informs PE2-rs that the status of the standby PW group has changed to 519 active. 521 In this scenario, PE devices are aware of switch overs at the MTU-s 522 and could generate MAC Withdraw messages to trigger MAC flushing 523 within the H-VPLS full-mesh. By default, MTU-s devices should still 524 trigger MAC withdraw messages as defined in [RFC4762] to prevent two 525 copies of MAC withdraws to be sent (one by the MTU-s and another one 526 by the PE-rs'). Mechanisms to disable the MAC withdraw trigger in 527 certain devices are out of the scope of this document. 529 3.2.5. PW Redundancy for PE Protection in a VPLS Ring using SS-PWs 531 The following figure illustrates the use of PW redundancy for dual- 532 homed connectivity between PEs in a VPLS ring topology. As above, 533 PSN tunnels are not shown and only one PW of a PW group is shown for 534 clarity. The example here uses SS-PWs and the objective is to 535 protect the emulated service against failures of a PE on the ring. 537 PE1 PE2 538 +--------+ +--------+ 539 | VSI | | VSI | 540 | -- | | -- | 541 ......|../ \..|.....................|../ \..|....... 542 | \ / | PW Group 1 | \ / | 543 | -- | | -- | 544 +--------+ +--------+ 545 . . 546 . . 547 VPLS Domain A . . VPLS Domain B 548 . . 549 . . 550 . . 551 +--------+ +--------+ 552 | VSI | | VSI | 553 | -- | | -- | 554 ......|../ \..|.....................|../ \..|........ 555 | \ / | PW Group 2 | \ / | 556 | -- | | -- | 557 +--------+ +--------+ 558 PE3 PE4 560 Figure 6: Redundancy in a VPLS Ring Topology 562 In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and 563 PE4 in VPLS domain B via PW group 1 and PW group 2. The PEs are 564 connected to each other in such a way as to form a ring topology. 565 Such scenarios may arise in inter-domain H-VPLS deployments where 566 rapid spanning tree (RSTP) or other mechanisms may be used to 567 maintain loop free connectivity of the PW groups. 569 [RFC4762] outlines multi-domain VPLS services without specifying how 570 multiple redundant border PEs per domain and per VPLS instance can be 571 supported. In the example above, PW group 1 may be blocked at PE1 by 572 RSTP and it is desirable to block the group at PE2 by exchanging the 573 PW preferential forwarding status of standby. The details of how PW 574 grouping is achieved and used is deployment specific and is outside 575 the scope of this document. 577 3.2.6. PW Redundancy for VPLS n-PE Protection using SS-PWs 578 |<----- Provider ----->| 579 Core 580 +------+ +------+ 581 | n-PE |::::::::::::::::::::::| n-PE | 582 Provider | (P) |.......... .........| (P) | Provider 583 Access +------+ . . +------+ Access 584 Network X Network 585 (1) +------+ . . +------+ (2) 586 | n-PE |.......... .........| n-PE | 587 | (B) |......................| (B) | 588 +------+ +------+ 590 Figure 7: Bridge Module Model 592 Bridge Module Model 594 Figure 7 shows a scenario with two provider access networks. The 595 example here uses SS-PWs and the objective is to protect the emulated 596 service against failures of a network-facing PE (n-PE). 598 Each network has two n-Pes. These n-PEs are connected via a full 599 mesh of PWs for a given VPLS instance. As shown in the figure, only 600 one n-PE in each access network serves as the primary PE (P) for that 601 VPLS instance and the other n-PE serves as the backup PE (B). In 602 this figure, each primary PE has two active PWs originating from it. 603 Therefore, when a multicast, broadcast, or unknown unicast frame 604 arrives at the primary n-PE from the access network side, the n-PE 605 replicates the frame over both PWs in the core even though it only 606 needs to send the frames over a single PW (shown with :::: in the 607 figure) to the primary n-PE on the other side. This is an 608 unnecessary replication of the customer frames that consumes core- 609 network bandwidth (half of the frames get discarded at the receiving 610 n-PE). This issue gets aggravated when there is three or more n-PEs 611 per provider, access network. For example if there are three n-PEs 612 or four n-PEs per access network, then 67% or 75% of core bandwidth 613 for multicast, broadcast and unknown unicast are wasted, 614 respectively. 616 In this scenario, the n-PEs can communicate the active or standby 617 status of the PWs among them. This status can be derived from the 618 active or backup state of an n-PE for a given VPLS. 620 4. Generic PW Redundancy Requirements 622 4.1. Protection Switching Requirements 624 o Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1 625 protection MUST be supported. The N:1 protection case is less 626 efficient in terms of the resources that must be allocated and 627 hence this SHOULD be supported. 1+1 protection MAY be used in the 628 scenarios described in the document. However, the details of its 629 usage are outside the scope of this document, as it MAY require a 630 1+1 protection switching protocol between the CEs. 632 o Non-revertive behavior MUST be supported, while revertive behavior 633 is OPTIONAL. This avoids the need to designate one PW as primary 634 unless revertive behavior is explicitly required. 636 o Protection switchover can be initiated from a PE e.g. using a 637 manual switchover, or a forced switchover, or it may be triggered 638 by a signal failure i.e. a defect in the PW or PSN. Manual 639 switchover may be necessary if it is required to disable one PW in 640 a redundant set. Both methods MUST be supported and signal 641 failure triggers MUST be treated with a lower priority than any 642 local or far-end forced switch or manual trigger. 644 o A PE MAY be able to forward packets received from a PW with a 645 standby status in order to avoid black holing of in-flight packets 646 during switchover. However, in the case of use of VPLS, all VPLS 647 application packets received from standby PWs MUST be dropped, 648 except for OAM and control plane packets. 650 4.2. Operational Requirements 652 o (T-)PEs involved in protecting a PW SHOULD automatically discover 653 and attempt to resolve inconsistencies in the configuration of 654 primary/secondary PW. 656 o (T-)PEs involved in protecting a PW SHOULD automatically discover 657 and attempt to resolve inconsistencies in the configuration of 658 revertive/non-revertive protection switching mode. 660 o (T-)PEs that do not automatically discover or resolve 661 inconsistencies in the configuration of primary/secondary, 662 revertive/non-revertive, or other parameters MUST generate an 663 alarm upon detection of an inconsistent configuration. 665 o (T-)PEs participating in PW redundancy MUST support the 666 configuration of revertive or non-revertive protection switching 667 modes if both modes are supported. 669 o The MIB(s) MUST support inter-PSN monitoring of the PW redundancy 670 configuration, including the protection switching mode. 672 o (T-)PEs participating in PW redundancy SHOULD support the local 673 invocation of protection switching. 675 o (T-)PEs participating in PW redundancy SHOULD support the local 676 invocation of a lockout of protection switching. 678 5. Security Considerations 680 This document requires extensions to the Label Distribution Protocol 681 (LDP) that are needed for protecting pseudowires. These will inherit 682 at least the same security properties as LDP [RFC5036] and the PW 683 control protocol [RFC4447]. 685 6. IANA Considerations 687 This document has no actions for IANA. 689 7. Major Contributing Authors 691 The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre, 692 Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles 693 Heron and Thomas Nadeau who made a major contribution to the 694 development of this document. 696 Pranjal Dutta 697 Alcatel-Lucent 698 Email: pranjal.dutta@alcatel-lucent.com 700 Marc Lasserre 701 Alcatel-Lucent 702 Email: marc.lasserre@alcatel-lucent.com 704 Jonathan Newton 705 Cable & Wireless 706 Email: Jonathan.Newton@cw.com 708 Olen Stokes 709 Extreme Networks 710 Email: ostokes@extremenetworks.com 712 Hamid Ould-Brahim 713 Email: ouldh@yahoo.com 715 Dave McDysan 716 Verizon 717 Email: dave.mcdysan@verizon.com 719 Giles Heron 720 Cisco Systems 721 Email: giles.heron@gmail.com 723 Thomas Nadeau 724 Juniper Networks 725 Email: tnadeau@lucidvision.com 727 8. Acknowledgements 729 The authors would like to thank Vach Kompella, Kendall Harvey, 730 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 731 Niger for their valuable comments and suggestions. 733 9. References 735 9.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997. 740 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 741 Edge (PWE3) Architecture", RFC 3985, March 2005. 743 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 744 Private Network (VPN) Terminology", RFC 4026, March 2005. 746 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 747 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 749 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 750 Heron, "Pseudowire Setup and Maintenance Using the Label 751 Distribution Protocol (LDP)", RFC 4447, April 2006. 753 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 754 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 755 RFC 4762, January 2007. 757 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 758 Specification", RFC 5036, October 2007. 760 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 761 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 762 October 2009. 764 9.2. Informative References 766 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 767 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 769 Authors' Addresses 771 Praveen Muley 772 Alcatel-Lucent 774 Email: praveen.muley@alcatel-lucent.com 776 Mustapha Aissaoui 777 Alcatel-Lucent 779 Email: mustapha.aissaoui@alcatel-lucent.com 780 Matthew Bocci 781 Alcatel-Lucent 783 Email: matthew.bocci@alcatel-lucent.com