idnits 2.17.1 draft-ietf-pwe3-redundancy-06.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 (February 16, 2012) is 4445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6073' is defined on line 660, 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: August 19, 2012 Alcatel-Lucent 6 February 16, 2012 8 Pseudowire Redundancy 9 draft-ietf-pwe3-redundancy-06 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 nodes in 17 Multi-Segment PW applications. In order for the PE/T-PE nodes to 18 indicate the preferred PW to use for forwarding PW packets to one 19 another, a new PW status is required to indicate the preferential 20 forwarding status of active or standby for each PW in the redundancy 21 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 August 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. PW Redundancy Network Reference Scenarios . . . . . . . . 5 68 3.2.1. Single Multi-Homed CE . . . . . . . . . . . . . . . . 5 69 3.2.2. Multiple Multi-Homed CEs . . . . . . . . . . . . . . . 7 70 3.2.3. Single-Homed CE With MS-PW Redundancy . . . . . . . . 8 71 3.2.4. PW Redundancy Between MTU-s in H-VPLS . . . . . . . . 9 72 3.2.5. PW Redundancy Between VPLS Network Facing PEs 73 (n-PEs) . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.2.6. Redundancy in a VPLS Bridge Module Model . . . . . . . 11 75 4. Generic PW Redundancy Requirements . . . . . . . . . . . . . . 12 76 4.1. Protection Switching Requirements . . . . . . . . . . . . 12 77 4.2. Operational Requirements . . . . . . . . . . . . . . . . . 13 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 13 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 The objective of PW redundancy is to provide sparing of attachment 90 circuits (ACs), Provider Edge nodes (PEs), and Pseudowires (PWs) to 91 eliminate single points of failure, while ensuring that only one 92 active path between a pair of Customer Edge nodes (CEs). 94 In single-segment PW (SS-PW) applications, protection for the PW is 95 provided by the PSN layer. This may be a Resource Reservation 96 Protocol with Traffic Engineering (RSVP-TE) labeled switched path 97 (LSP) with a fast-Reroute (FRR) backup or an end-to-end backup LSP. 98 PSN protection mechanisms cannot protect against failure of the a PE 99 node or the failure of the remote AC. Typically, this is supported 100 by dual-homing a Customer Edge (CE) node to different PE nodes which 101 provide a pseudowire emulated service across the PSN. A set of PW 102 mechanisms is therefore required that enables a primary and one or 103 more backup PWs to terminate on different PE nodes. 105 In multi-segment PW (MS-PW) applications, PSN protection mechanisms 106 cannot protect against the failure of a switching PE (S-PE). A set 107 of mechanisms that support the operation of a primary and one or more 108 backup PWs via a different set of S-PEs is therefore required. The 109 paths of these PWs are diverse in the sense that they are switched at 110 different S-PE nodes. 112 In both of these applications, PW redundancy is important to maximise 113 the resiliency of the emulated service. 115 This document describes framework for these applications and its 116 associated operational requirements. The framework utilizes a new PW 117 status, called the Preferential Forwarding Status of the PW. This is 118 separate from the operational states defined in RFC4447 [RFC4447]. 119 The mechanisms for PW redundancy are modeled on general protection 120 switching principles. 122 2. Terminology 124 o Up PW: A PW which has been configured (label mapping exchanged 125 between PEs) and is not in any of the PW defect states specified 126 in [RFC4447]. Such a PW is is available for forwarding traffic. 128 o Down PW: A PW that has either not been fully configured, or has 129 been configured and is in any one of the PW defect states 130 specified in [RFC4447]. Such a PW is not available for forwarding 131 traffic. 133 o Active PW. An UP PW used for forwarding user, OAM and control 134 plane traffic. 136 o Standby PW. An UP PW that is not used for forwarding user traffic 137 but may forward OAM and specific control plane traffic. 139 o PW Endpoint: A PE where a PW terminates on a point where Native 140 Service Processing is performed, e.g., A Single Segment PW (SS-PW) 141 PE, a Multi-Segment Pseudowire (MS-PW) Terminating PE (T-PE), or a 142 Hierarchical VPLS MTU-s or PE-rs. 144 o Primary PW: the PW which a PW endpoint activates (i.e. uses for 145 forwarding) in preference to any other PW when more than one PW 146 qualifies for active state. When the primary PW comes back up 147 after a failure and qualifies for the active state, the PW 148 endpoint always reverts to it. The designation of Primary is 149 performed by local configuration for the PW at the PE. 151 o Secondary PW: when it qualifies for the active state, a Secondary 152 PW is only selected if no Primary PW is configured or if the 153 configured primary PW does not qualify for active state (e.g., is 154 DOWN). By default, a PW in a redundancy PW set is considered 155 secondary. There is no Revertive mechanism among secondary PWs. 157 o Revertive protection switching. Traffic will be carried by the 158 primary PW if it is UP and a wait-to-restore timer expires and the 159 primary PW is made the Active PW. 161 o Non-revertive protection switching. Traffic will be carried by 162 the last PW selected as a result of previous active PW entering 163 Operationally DOWN state. 165 o Manual selection of PW. The ability for the operator to manually 166 select the primary/secondary PWs. 168 o MTU-s: A hierarchical virtual private LAN service Multi-Tenant 169 Unit switch, as defined in RFC4762 [RFC4762]. 171 o PE-rs: A hierarchical virtual private LAN service switch, as 172 defined in RFC4762. 174 o n-PE: A network facing provider edge node, as defined in RFC4026 175 [RFC4026]. 177 This document uses the term 'PE' to be synonymous with both PEs as 178 per RFC3985[RFC3985] and T-PEs as per RFC5659 [RFC5659]. 180 This document uses the term 'PW' to be synonymous with both PWs as 181 per RFC3985 and SS-PWs, MS-PWs, and PW segments as per RFC5659. 183 3. Reference Models 185 The following sections describe show the reference architecture of 186 the PE for PW redundancy and its usage in different topologies and 187 applications. 189 3.1. PE Architecture 191 Figure 1 shows the PE architecture for PW redundancy, when more than 192 one PW in a redundant set is associated with a single AC. This is 193 based on the architecture in Figure 4b of RFC3985 [RFC3985]. The 194 forwarder selects which of the redundant PWs to use based on the 195 criteria described in this document. 197 +----------------------------------------+ 198 | PE Device | 199 +----------------------------------------+ 200 Single | | Single | PW Instance 201 AC | + PW Instance X<===========> 202 | | | 203 | |----------------------| 204 <------>o | Single | PW Instance 205 | Forwarder + PW Instance X<===========> 206 | | | 207 | |----------------------| 208 | | Single | PW Instance 209 | + PW Instance X<===========> 210 | | | 211 +----------------------------------------+ 213 Figure 1: PE Architecture for PW redundancy 215 3.2. PW Redundancy Network Reference Scenarios 217 This section presents a set of reference scenarios for PW redundancy. 219 3.2.1. Single Multi-Homed CE 221 The following figure illustrates an application of single segment 222 pseudowire redundancy. This scenario is designed to protect the 223 emulated service against a failure of one of the PEs or ACs attached 224 to the multi-homed CE. Protection against failures of the PSN 225 tunnels is provided using PSN mechanisms such as MPLS Fast Reroute, 226 so that these failures do not impact the PW. 228 CE1 is dual-homed to PE1 and PE3. A dual homing control protocol, 229 the details of which are outside the scope of this document, selects 230 which AC CE1 should use to forward towards the PSN, and which PE (PE1 231 or PE3) should forward towards CE1. 233 |<-------------- Emulated Service ---------------->| 234 | | 235 | |<------- Pseudo Wire ------>| | 236 | | | | 237 | | |<-- PSN Tunnels-->| | | 238 | V V V V | 239 V AC +----+ +----+ AC V 240 +-----+ | | PE1|==================| | | +-----+ 241 | |----------|....|...PW1.(active)...|....|----------| | 242 | | | |==================| | | CE2 | 243 | CE1 | +----+ |PE2 | | | 244 | | +----+ | | +-----+ 245 | | | |==================| | 246 | |----------|....|...PW2.(standby)..| | 247 +-----+ | | PE3|==================| | 248 AC +----+ +----+ 250 Figure 2: PW Redundancy with One Multi-Homed CE 252 In this scenario, only one of the PWs should be used for forwarding 253 between PE1 / PE3, and PE2. PW redundancy determines which PW to 254 make active based on the forwarding state of the ACs so that only one 255 path is available from CE1 to CE2. 257 Consider the example where the AC from CE1 to PE1 is initially active 258 and the AC from CE1 to PE3 is initially standby. PW1 is made active 259 and PW2 is made standby in order to complete the path to CE2. 261 On failure of the AC between CE1 and PE1, the forwarding state of the 262 AC on PE3 transitions to Active. The preferential forwarding state 263 of PW2 therefore needs to become active, and PW1 standby, in order to 264 reestablish connectivity between CE1 and CE2. PE3 therefore uses PW2 265 to forward towards CE2, and PE2 uses PW2 instead of PW1 to forward 266 towards CE1. PW redundancy in this scenario requires that the 267 forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so 268 that PE2 can choose which PW to make active. 270 Changes occurring on the dual homed side of network due to a failure 271 of the AC or PE are not propagated to the ACs on the other side of 272 the network. Furthermore, failures in the PSN are not be propagated 273 to the attached CEs. 275 3.2.2. Multiple Multi-Homed CEs 277 This scenario, illustrated in Figure 3, is also designed to protect 278 the emulated service against failures of the ACs and failures of the 279 PEs. Here, both CEs, CE1 and CE2, are dual-homed to their respective 280 PEs, PE1 and PE2, and PE3 and PE4. The method used by the CEs to 281 choose which AC to use to forward traffic towards the PSN is 282 determined by a dual-homing control protocol. The details of this 283 protocol are outside the scope of this document. 285 Note that the PSN tunnels are not shown in this figure for clarity. 286 However, it can be assumed that each of the PWs shown is encapsulated 287 in a separate PSN tunnel. Protection against failures of the PSN 288 tunnels is provided using PSN mechanisms such as MPLS Fast Reroute, 289 so that these failures do not impact the PW. 291 |<-------------- Emulated Service ---------------->| 292 | | 293 | |<------- Pseudowire ------->| | 294 | | | | 295 | | |<-- PSN Tunnels-->| | | 296 | V V V V | 297 V AC +----+ +----+ AC V 298 +-----+ | |....|.......PW1........|....| | +-----+ 299 | |----------| PE1|...... .........| PE3|----------| | 300 | CE1 | +----+ \ / PW3 +----+ | CE2 | 301 | | +----+ X +----+ | | 302 | | | |....../ \..PW4....| | | | 303 | |----------| PE2| | PE4|--------- | | 304 +-----+ | |....|.....PW2..........|....| | +-----+ 305 AC +----+ +----+ AC 307 Figure 3: Multiple Multi-Homed CEs with PW Redundancy 309 PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PE2 310 has PW2 and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3 and PW4 311 are all UP. In order to support N:1 or 1:1 protection, only one PW 312 MUST be selected to forward traffic. This document defines an 313 additional PW state that reflects this forwarding state, which is 314 separate from the operational status of the PW. This is the 315 'Preferential Forwarding Status'. 317 If a PW has a preferential forwarding status of 'active', it can be 318 used for forwarding traffic. The actual UP PW chosen by the combined 319 set of PEs that interconnect the CEs is determined by considering the 320 preferential forwarding status of each PW at each PE. The mechanisms 321 for achieving this selection are outside the scope of this document. 322 Only one PW is used for forwarding. 324 The following failure scenario illustrates the operation of PW 325 redundancy in Figure 2. In the initial steady state, when there are 326 no failures of the ACs, one of the PWs is chosen as the active PW, 327 and all others are chosen as standby. The dual-homing protocol 328 between CE1 and PE1/PE2 chooses to use the AC to PE2, while the 329 protocol between CE2 and PE3/PE4 chooses to use the AC to PE4. 330 Therefore the PW between PE2 and PE4 is chosen as the active PW to 331 complete the path between CE1 and CE2. 333 On failure of the AC between the dual-homed CE1 and PE2, the 334 preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4 335 needs to change so as to re-establish a path from CE1 to CE2. 336 Different mechanisms can be used to achieve this and these are beyond 337 the scope of this document. After the change in status the algorithm 338 for selection of PW needs to revaluate and select PW to forward 339 traffic. In this application each dual-homing algorithm, i.e., {CE1, 340 PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently. 341 There is therefore a need to signal the active status of each AC such 342 that the PEs can select a common active PW for forwarding between CE1 343 and CE2. 345 Changes occurring on one side of network due to a failure of the AC 346 or PE are not propagated to the ACs on the other side of the network. 347 Furthermore, failures in the PSN are not be propagated to the 348 attached CEs. Note that End-to-end native service protection 349 switching can also be used to protect the emulated service in this 350 scenario. In this case, PW3 and PW4 are not necessary. 352 If the CEs do not perform native service protection switching, they 353 may instead may use load balancing across the paths between the CEs. 355 3.2.3. Single-Homed CE With MS-PW Redundancy 357 This application is shown in Figure 4. The main objective is to 358 protect the emulated service against failures of the S-PEs. 360 Native |<----------- Pseudowires ----------->| Native 361 Service | | Service 362 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 363 | V V V V V V | 364 | +-----+ +-----+ +-----+ | 365 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 366 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 367 | CE1| | |=========| |=========| | | CE2| 368 | | +-----+ +-----+ +-----+ | | 369 +----+ |.||.| |.||.| +----+ 370 |.||.| +-----+ |.||.| 371 |.||.|=========| |========== .||.| 372 |.||...PW2-Seg1......|.PW2-Seg2...||.| 373 |.| ===========|S-PE2|============ |.| 374 |.| +-----+ |.| 375 |.|============+-----+============= .| 376 |.....PW3-Seg1.| | PW3-Seg2......| 377 ==============|S-PE3|=============== 378 | | 379 +-----+ 381 Figure 4: Single-Homed CE with MS-PW Redundancy 383 CE1 is connected to PE1 and CE2 to PE2, respectively. There are 384 three multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched 385 at S-PE2, and PW3 is switched at S-PE3. 387 Since there is no multi-homing running on the ACs, the T-PE nodes 388 would advertise 'Active' for the forwarding status based on a 389 priority for the PW. Priorities associate meaning of 'primary PW' 390 and 'secondary PW'. These priorities MUST be used in revertive mode 391 as well and paths must be switched accordingly. The priority can be 392 configuration or derivation from the PWid. Lower the PWid higher the 393 priority. However, this does not guarantee selection of same PW by 394 the T-PEs because, for example, mismatch of the configuration of the 395 PW priority in each T-PE. The intent of this application is to have 396 T-PE1 and T-PE2 synchronize the transmit and receive paths of the PW 397 over the network. In other words, both T-PE nodes are required to 398 transmit over the PW segment which is switched by the same S-PE. 399 This is desirable for ease of operation and troubleshooting. 401 3.2.4. PW Redundancy Between MTU-s in H-VPLS 403 The following figure illustrates the application of use of PW 404 redundancy to Hierarchical VPLS (H-VPLS). Here, a Multi-Tenant Unit 405 switch (MTU-s) is dual-homed to two PE router switches (PE-rs). 407 |<-PSN1-->| |<-PSN2-->| 408 V V V V 409 +-----+ +-----+ 410 |MTU-s|=========|PE1 |======== 411 |..Active PW group....| H-VPLS-core 412 | |=========| |========= 413 +-----+ +-----+ 414 |.| 415 |.| +-----+ 416 |.|===========| |========== 417 |...Standby PW group|.H-VPLS-core 418 =============| PE2|========== 419 +-----+ 421 Figure 5: MTU-s Dual Homing in H-VPLS Core 423 In Figure 5, the MTU-s is dual homed to PE1 and PE2 and has spoke PWs 424 to each of them. The MTU-s needs to choose only one of the spoke PWs 425 ( the active PW) to one of the PE to forward the traffic and the 426 other to standby status. The MTU-s can derive the status of the PWs 427 based on local policy configuration. PE1 and PE2 are connected to 428 the H-VPLS core on the other side of network. The MTU-s communicates 429 the status of its member PWs for a set of VSIs having common status 430 of Active or Standby. Here the MTU-s controls the selection of PWs 431 to forward the traffic. Signaling using PW grouping with a common 432 group-id in PWid FEC Element or Grouping TLV in Generalized PWid FEC 433 Element as defined in [RFC4447] to PE1 and PE2 respectively, is 434 recommended to scale better. 436 Whenever MTU-s performs a switchover, it needs to communicate to PE2 437 for the Standby PW group the changed status of active. 439 In this scenario, PE devices are aware of switchovers at MTU-s and 440 could generate MAC Withdraw Messages to trigger MAC flushing within 441 the H-VPLS full mesh. By default, MTU-s devices should still trigger 442 MAC Withdraw messages as currently defined in [RFC4762] to prevent 443 two copies of MAC withdraws to be sent (one by MTU-s and another one 444 by PEs). Mechanisms to disable MAC Withdraw trigger in certain 445 devices is out of the scope of this document. 447 3.2.5. PW Redundancy Between VPLS Network Facing PEs (n-PEs) 449 Following figure illustrates the application of use of PW redundancy 450 for dual homed connectivity between PE devices in a ring topology. 452 +-------+ +-------+ 453 | PE1 |=====================| PE2 |====... 454 +-------+ PW Group 1 +-------+ 455 || || 456 VPLS Domain A || || VPLS Domain B 457 || || 458 +-------+ +-------+ 459 | PE3 |=====================| PE4 |==... 460 +-------+ PW Group 2 +-------+ 462 Figure 6: Redundancy in a Ring Topology 464 In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and 465 PE4 in VPLS domain B via PW group 1 and group 2. Each of the PEs in 466 the respective domains is connected to each other as well as forming 467 the ring topology. Such scenarios may arise in inter-domain H-VPLS 468 deployments where rapid spanning tree (RSTP) or other mechanisms may 469 be used to maintain loop free connectivity of PW groups. 471 [RFC4762] outlines multi-domain VPLS services without specifying how 472 multiple redundant border PEs per domain per VPLS instance can be 473 supported. In the example above, PW group 1 may be blocked at PE1 by 474 RSTP and it is desirable to block the group at PE2 by virtue of 475 exchanging the PW preferential forwarding status of Standby. How the 476 PW grouping should be done here is again deployment specific and is 477 out of scope of the solution. 479 3.2.6. Redundancy in a VPLS Bridge Module Model 481 ----------------------------+ Provider +------------------------ 482 . Core . 483 +------+ . . +------+ 484 | n-PE |======================| n-PE | 485 Provider | (P) |---------\ /-------| (P) | Provider 486 Access +------+ ._ \ / . +------+ Access 487 Network . \/ . Network 488 (1) +------+ . /\ . +------+ (2) 489 | n-PE |----------/ \--------| n-PE | 490 | (B) |----------------------| (B) |_ 491 +------+ . . +------+ 492 . . 493 ----------------------------+ +------------------------ 495 Figure 7: Bridge Module Model 497 In Figure 7, two provider access networks, each having two n-PEs, 498 where the n-PEs are connected via a full mesh of PWs for a given VPLS 499 instance. As shown in the figure, only one n-PE in each access 500 network is serving as a Primary PE (P) for that VPLS instance and the 501 other n-PE is serving as the backup PE (B). In this figure, each 502 primary PE has two active PWs originating from it. Therefore, when a 503 multicast, broadcast, and unknown unicast frame arrives at the 504 primary n-PE from the access network side, the n-PE replicates the 505 frame over both PWs in the core even though it only needs to send the 506 frames over a single PW (shown with == in the figure) to the primary 507 n-PE on the other side. This is an unnecessary replication of the 508 customer frames that consumes core-network bandwidth (half of the 509 frames get discarded at the receiving n-PE). This issue gets 510 aggravated when there is three or more n-PEs per provider, access 511 network. For example if there are three n-PEs or four n-PEs per 512 access network, then 67% or 75% of core-BW for multicast, broadcast 513 and unknown unicast are wasted, respectively. 515 In this scenario, n-PEs can disseminate the status of PWs active/ 516 standby among them and furthermore to have it tied up with the 517 redundancy mechanism such that per VPLS instance the status of 518 active/backup n-PE gets reflected on the corresponding PWs emanating 519 from that n-PE. 521 4. Generic PW Redundancy Requirements 523 4.1. Protection Switching Requirements 525 o Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1 526 protection MUST besupported. The N:1 protection case is less 527 efficient in terms of the resources that must be allocated and 528 hence this SHOULD be supported. 1+1 protection architecture MAY be 529 suported, but its definition is for further study. 531 o Non-revertive behavior MUST be supported, while revertive behavior 532 is OPTIONAL. 534 o Protection switchover can be triggered by the operator e.g. using 535 a Manual lockout/force switchover, or it may be triggered by a 536 signal failure i.e. a defect in the PW or PSN. Both methods MUST 537 be supported and signal failure triggers MUST be treated with a 538 higher priority than any local or far-end operator-initiated 539 trigger. 541 o Note that a PE MAY be able to forward packets received from a 542 standby status PW in order to avoid black holing of in-flight 543 packets during switchover. However, in the case of use of VPLS, 544 all VPLS application packets received from standby PWs MUST be 545 dropped, except for OAM packets. 547 4.2. Operational Requirements 549 o (T-)PEs involved in protecting a PW SHOULD automatically discover 550 and attempt to resolve inconsistencies in the configuration of 551 primary/secondary PW. 553 o (T-)PEs involved in protecting a PW SHOULD automatically discover 554 and attempt to resolve inconsistencies in the configuration of 555 revertive/non-revertive protection switching mode. 557 o (T-)PEs that do not automatically discover or resolve 558 inconsistencies in the configuration of primary/secondary, 559 revertive/non-revertive, or other parameters MUST generate an 560 alarm upon detection of an inconsistent configuration. 562 o (T-)PEs participating in PW redundancy MUST support the 563 configuration of revertive or non-revertive protection switching 564 modes. 566 o (T-)PEs participating in PW redundancy SHOULD support the local 567 invocation of protection switching. 569 o (T-)PEs participating in PW redundancy SHOULD support the local 570 invocation of a lockout of protection switching. 572 o 574 5. Security Considerations 576 This document requires extensions to LDP that are needed for 577 protecting pseudowires. These will inherit at least the same 578 security properties as LDP [RFC5036] and the PW control protocol 579 [RFC4447]. 581 6. IANA Considerations 583 This document has no actions for IANA. 585 7. Major Contributing Authors 587 The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre, 588 Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles 589 Heron and Thomas Nadeau who made a major contribution to the 590 development of this document. 592 Pranjal Dutta 593 Alcatel-Lucent 594 Email: pranjal.dutta@alcatel-lucent.com 596 Marc Lasserre 597 Alcatel-Lucent 598 Email: marc.lasserre@alcatel-lucent.com 600 Jonathan Newton 601 Cable & Wireless 602 Email: Jonathan.Newton@cw.com 604 Olen Stokes 605 Extreme Networks 606 Email: ostokes@extremenetworks.com 608 Hamid Ould-Brahim 609 Nortel 610 Email: hbrahim@nortel.com 612 Dave McDysan 613 Verizon 614 Email: dave.mcdysan@verizon.com 616 Giles Heron 617 Cisco Systems 618 Email: giles.heron@gmail.com 620 Thomas Nadeau 621 Computer Associates 622 Email: tnadeau@lucidvision.com 624 8. Acknowledgements 626 The authors would like to thank Vach Kompella, Kendall Harvey, 627 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 628 Niger for their valuable comments and suggestions. 630 9. References 632 9.1. Normative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 638 Edge (PWE3) Architecture", RFC 3985, March 2005. 640 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 641 Private Network (VPN) Terminology", RFC 4026, March 2005. 643 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 644 Heron, "Pseudowire Setup and Maintenance Using the Label 645 Distribution Protocol (LDP)", RFC 4447, April 2006. 647 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 648 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 649 RFC 4762, January 2007. 651 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 652 Specification", RFC 5036, October 2007. 654 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 655 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 656 October 2009. 658 9.2. Informative References 660 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 661 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 663 Authors' Addresses 665 Praveen Muley 666 Alcatel-Lucent 668 Email: praveen.muley@alcatel-lucent.com 670 Mustapha Aissaoui 671 Alcatel-Lucent 673 Email: mustapha.aissaoui@alcatel-lucent.com 675 Matthew Bocci 676 Alcatel-Lucent 678 Email: matthew.bocci@alcatel-lucent.com