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