idnits 2.17.1 draft-ietf-pwe3-redundancy-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 276 characters in excess of 72. 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 (September 22, 2011) is 4599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 565, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley, Ed. 2 Internet Draft Mustapha Aissaoui, Ed. 3 Intended Status: Informational Matthew Bocci, Ed. 4 Expires: March 2012 Alcatel-Lucent 6 September 22, 2011 8 Pseudowire Redundancy 9 draft-ietf-pwe3-redundancy-05.txt 11 Abstract 12 This document describes a framework comprised of a number of 13 scenarios and associated requirements for pseudowire (PW) 14 redundancy. A set of redundant PWs is configured between provider 15 edge (PE) nodes in single segment PW applications, or between 16 Terminating PE nodes in Multi-Segment PW applications. In order for 17 the PE/T-PE nodes to indicate the preferred PW to use for forwarding 18 PW packets to one another, a new PW status is required to indicate 19 the preferential forwarding status of active or standby for each PW 20 in the redundancy set. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on December 30, 2011 46 Copyright Notice 48 Copyright (c) 2011 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 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [1]. 66 Table of Contents 67 Copyright Notice.....................................2 68 1. Introduction.........................................3 69 2. Terminology.........................................3 70 3. Reference Models.....................................5 71 3.1. PE Architecture..................................5 72 3.2. PW Redundancy Network Reference Scenarios.............5 73 3.2.1. Single Multi-Homed CE.........................5 74 3.2.2. Multiple Multi-homed CEs.......................7 75 3.3. Single Homed CE with MS-PW redundancy................9 76 3.4. PW redundancy between MTU-s in H-VPLS...............10 77 3.5. PW redundancy between VPLS n-PEs...................11 78 3.6. PW redundancy in VPLS Bridge Module Model............11 79 4. Generic PW redundancy requirements......................13 80 4.1. Protection switching requirements..................13 81 4.2. Operational requirements..........................13 82 5. Security Considerations...............................14 83 6. IANA considerations..................................14 84 7. Major Contributing Authors............................15 85 8. Acknowledgments.....................................15 86 9. References.........................................16 87 9.1. Normative References.............................16 88 9.2. Informative References...........................16 89 Author's Addresses.....................................17 91 1. Introduction 92 The objective of PW redundancy is to provide sparing of attachment 93 circuits (ACs), Provider Edge nodes (PEs), and Pseudowires (PWs) to 94 eliminate single points of failure, while ensuring that only one 95 active path between a pair of Customer Edge nodes (CEs). 96 In single-segment PW (SS-PW) applications, protection for the PW is 97 provided by the PSN layer. This may be a Resource Reservation 98 Protocol with Traffic Engineering (RSVP-TE) labeled switched path 99 (LSP) with a fast-Reroute (FRR) backup or an end-to-end backup LSP. 100 PSN protection mechanisms cannot protect against failure of the a PE 101 node or the failure of the remote AC. Typically, this is supported 102 by dual-homing a Cutomer Edge (CE) node to different PE nodes which 103 provide a pseudowire emulated service across the PSN. A set of PW 104 mechanisms is theerfore required that enables a primary and one or 105 more backup backup PWs to terminate on different PE nodes. 106 In multi-segment PW (MS-PW) applications, PSN protection mechanisms 107 cannot protect against the failure of a switching PE (S-PE). A set 108 of mechanisms that support the operation of a primary and one or 109 more backup PWs via a diferent set of S-PEs is therefore required. 110 The paths of these PWs are diverse in the sense that they are 111 switched at different S-PE nodes. 112 In both of these applications, PW redundancy is important to 113 maximise the resiliency of the emulated service. 114 This document describes framework for these applications and its 115 associated operational requirements. The framework utilizes a new PW 116 status, called the Preferential Forwarding Status of the PW. This is 117 separate from the operational states defined in RFC4447 [2]. The 118 mechanisms for PW redundancy are modeled on general protection 119 switching principles. 121 2. Terminology 122 o UP PW: A PW which has been configured (label mapping exchanged 123 between PEs) and s not in any of the PW defect states specified 124 in [2]. Such a PW is available for forwarding traffic. 126 o DOWN PW: A PW that has either not been fully configured, or has 127 been configured and is in any one of the PW defect states 128 specified in [2]. Such a PW is not available for forwarding 129 traffic. 130 o Active PW. An UP PW used for forwarding user, OAM and control 131 plane traffic. 132 o Standby PW. An UP PW that is not used for forwarding user traffic 133 but may forward OAM and specific control plane traffic. 134 o PW Endpoint: A PE where a PW terminates on a point where Native 135 Service Processing is performed, e.g., A Single Segment PW (SS- 136 PW) PE, a Multi-Segment Pseudowire (MS-PW) Terminating PE (T-PE), 137 or a Hierarchical VPLS MTU-s or PE-rs. 138 o Primary PW: the PW which a PW endpoint activates (i.e. uses for 139 forwarding) in preference to any other PW when more than one PW 140 qualifies for active state. When the primary PW comes back up 141 after a failure and qualifies for the active state, the PW 142 endpoint always reverts to it. The designation of Primary is 143 performed by local configuration for the PW at the PE. 144 o Secondary PW: when it qualifies for the active state, a Secondary 145 PW is only selected if no Primary PW is configured or if the 146 configured primary PW does not qualify for active state (e.g., is 147 DOWN). By default, a PW in a redundancy PW set is considered 148 secondary. There is no Revertive mechanism among secondary PWs. 149 o Revertive protection switching. Traffic will be carried by 150 primary PW if it is UP and a wait-to-restore timer expires and 151 primary PW is made the Active PW. 152 o Non-revertive protection switching. Traffic will be carried by 153 the last PW selected as a result of previous active PW entering 154 Operationally DOWN state. 155 o Manual selection of PW. The ability for the operator to manually 156 select the primary/secondary PWs. 157 This document uses the term 'PE' to be synonymous with both PEs as 158 per RFC3985 and T-PEs as per RFC5659. 159 This document uses the term 'PW' to be synonymous with both PWs as 160 per RFC3985 and SS-PWs, MS-PWs, S-PEs, PW-segment and PW 161 switching point as per RFC5659. 163 3. Reference Models 164 Following sections describe show the reference architecture of the 165 PE for PW redundancy and its usage in different topologies and 166 applications. 168 3.1. PE Architecture 169 Figure 1 shows the PE architecture for PW redundancy, when more than 170 one PW in a redundant set is associated with a single AC. This is 171 based on the architecture in Figure 4b of RFC3985 [3]. The forwarder 172 selects which of the redundant PWs to use based on the criteria 173 described in this document. 174 +----------------------------------------+ 175 | PE Device | 176 +----------------------------------------+ 177 Single | | Single | PW Instance 178 AC | + PW Instance X<===========> 179 | | | 180 | |----------------------| 181 <------>o | Single | PW Instance 182 | Forwarder + PW Instance X<===========> 183 | | | 184 | |----------------------| 185 | | Single | PW Instance 186 | + PW Instance X<===========> 187 | | | 188 +----------------------------------------+ 190 Figure 1 PE architecture for PW redundancy 191 3.2. PW Redundancy Network Reference Scenarios 192 This section presents a set of reference scenarios for PW 193 redundancy. 194 3.2.1. Single Multi-Homed CE 195 The following figure illustrates an application of single segment 196 pseudowire redundancy. This scenario is designed to protect the 197 emulated service against a failure of one of the PEs or ACs attached 198 to the multi-homed CE. Protection against failures of the PSN 199 tunnels is provided using PSN mechanisms such as MPLS Fast Reroute, 200 so that these failures do not impact the PW. 202 CE1 is dual-homed to PE1 and PE3. A dual homing control protocol, 203 the details of which are outside the scope of this document, selects 204 which AC CE1 should use to forward towards the PSN, and which PE 205 (PE1 or PE3) should forward towards CE1. 207 |<-------------- Emulated Service ---------------->| 208 | | 209 | |<------- Pseudo Wire ------>| | 210 | | | | 211 | | |<-- PSN Tunnels-->| | | 212 | V V V V | 213 V AC +----+ +----+ AC V 214 +-----+ | | PE1|==================| | | +-----+ 215 | |----------|....|...PW1.(active)...|....|----------| | 216 | | | |==================| | | CE2 | 217 | CE1 | +----+ |PE2 | | | 218 | | +----+ | | +-----+ 219 | | | |==================| | 220 | |----------|....|...PW2.(standby)..| | 221 +-----+ | | PE3|==================| | 222 AC +----+ +----+ 224 Figure 2 PW Redundancy with one Multi-Homed CE 225 In this scenario, only one of the PWs should be used for forwarding 226 between PE1 / PE3, and PE2. PW redundancy determines which PW to 227 make active based on the forwarding state of the ACs so that only 228 one path is available from CE1 to CE2. 229 Consider the example where the AC from CE1 to PE1 is initially 230 active and the AC from CE1 to PE3 is initially standby. PW1 is made 231 active and PW2 is made standby in order to complete the path to CE2. 232 On failure of the AC between CE1 and PE1, the forwarding state of 233 the AC on PE3 transitions to Active. The preferential forwarding 234 state of PW2 therefore needs to become active, and PW1 standby, in 235 order to reestablish connectivity between CE1 and CE2. PE3 therefore 236 uses PW2 to forward towards CE2, and PE2 uses PW2 instead of PW1 to 237 forward towards CE1. PW redundancy in this scenario requires that 238 the forwarding status of the ACs at PE1 and PE3 be signaled to PE2 239 so that PE2 can choose which PW to make active. 240 Changes occurring on the dual homed side of network due to a failure 241 of the AC or PE are not propagated to the ACs on the other side of 242 the network. Furthermore, failures in the PSN are not be propagated 243 to the attached CEs. 245 3.2.2. Multiple Multi-homed CEs 246 This scenario, illustrated in Figure 3, is also designed to protect 247 the emulated service against failures of the ACs and failures of the 248 PEs. Here, both CEs, CE1 and CE2, are dual-homed to their respective 249 PEs, PE1 and PE2, and PE3 and PE4. The method used by the CEs to 250 choose which AC to use to forward traffic towards the PSN is 251 determined by a dual-homing control protocol. The details of this 252 protocol are outside the scope of this document. 253 Note that the PSN tunnels are not shown in this figure for clarity. 254 However, it can be assumed that each of the PWs shown is 255 encapsulated in a separate PSN tunnel. Protection against failures 256 of the PSN tunnels is provided using PSN mechanisms such as MPLS 257 Fast Reroute, so that these failures do not impact the PW. 259 |<-------------- Emulated Service ---------------->| 260 | | 261 | |<------- Pseudowire ------->| | 262 | | | | 263 | | |<-- PSN Tunnels-->| | | 264 | V V V V | 265 V AC +----+ +----+ AC V 266 +-----+ | |....|.......PW1........|....| | +-----+ 267 | |----------| PE1|...... .........| PE3|----------| | 268 | CE1 | +----+ \ / PW3 +----+ | CE2 | 269 | | +----+ X +----+ | | 270 | | | |....../ \..PW4....| | | | 271 | |----------| PE2| | PE4|--------- | | 272 +-----+ | |....|.....PW2..........|....| | +-----+ 273 AC +----+ +----+ AC 275 Figure 3 Multiple Multi-homed CEs with SS-PW redundancy 277 PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PE2 278 has PW2 and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3 and PW4 279 are all UP. In order to support N:1 or 1:1 protection, only one PW 280 MUST be selected to forward traffic. This document defines an 281 additional PW that reflects this forwarding state, which is separate 282 from the operational status of the PW. This is the 'Preferential 283 Forwarding Status'. 284 If a PW has a preferential forwarding status of 'active', it can be 285 used for forwarding traffic. The actual UP PW chosen by the combined 286 set of PEs that interconnect the CEs is determined by considering 287 the preferential forwarding status of each PW at each PE. The 288 mechanisms for achieving this selection are outside the scope of 289 this document. Only one PW is used for forwarding. 290 The following failure scenario illustrates the operation of PW 291 redundancy in Figure 2. In the initial steady state, when there are 292 no failures of the ACs, one of the PWs is chosen as the active PW, 293 and all others are chosen as standby. The dual-homing protocol 294 between CE1 and PE1/PE2 chooses to use the AC to PE2, while the 295 protocol between CE2 and PE3/PE4 chooses to use the AC to PE4. 296 Therefore the PW between PE2 and PE4 is chosen as the active PW to 297 complete the path between CE1 and CE2. 298 On failure of the AC between the dual-homed CE1 and PE2, the 299 preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4 300 needs to change so as to re-establish a path from CE1 to CE2. 301 Different mechanisms can beused to achieve this and these are beyond 302 the scope of this document. After the change in status the algorithm 303 for selection of PW needs to revaluate and select PW to forward 304 traffic. In this application each dual-homing algorithm, i.e., {CE1, 305 PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently. 306 There is therefore a need to signal the active status of each AC 307 such that the PEs can select a common active PW for forwarding 308 between CE1 and CE2. 309 Changes occurring on one side of network due to a failure of the AC 310 or PE are not propagated to the ACs on the other side of the 311 network. Furthermore, failures in the PSN are not be propagated to 312 the attached CEs. 313 Note that End-to-end native service protection switching can also be 314 used to protect the emulated service in this scenario. In this case, 315 PW3 and PW4 are not necessary. 317 If the CEs do not perform native service protection switching, they 318 may instead may use load balancing across the paths between the CEs. 320 3.3. Single Homed CE with MS-PW redundancy 321 This application is shown in Figure 4. The main objective is to 322 protect the emulated service against failures of the S-PEs. 323 Native |<----------- Pseudowires ----------->| Native 324 Service | | Service 325 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 326 | V V V V V V | 327 | +-----+ +-----+ +-----+ | 328 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 329 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 330 | CE1| | |=========| |=========| | | CE2| 331 | | +-----+ +-----+ +-----+ | | 332 +----+ |.||.| |.||.| +----+ 333 |.||.| +-----+ |.||.| 334 |.||.|=========| |========== .||.| 335 |.||...PW2-Seg1......|.PW2-Seg2...||.| 336 |.| ===========|S-PE2|============ |.| 337 |.| +-----+ |.| 338 |.|============+-----+============= .| 339 |.....PW3-Seg1.| | PW3-Seg2......| 340 ==============|S-PE3|=============== 341 | | 342 +-----+ 344 Figure 4 Single homed CE with multi-segment pseudowire redundancy 345 CE1 is connected to PE1 and CE2 to PE2, respectively. There are 346 three multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched 347 at S-PE2, and PW3 is switched at S-PE3. 348 Since there is no multi-homing running on the ACs, the T-PE nodes 349 would advertise 'Active' for the forwarding status based on a 350 priority for the PW. Priorities associate meaning of 'primary PW' 351 and 'secondary PW'. These priorities MUST be used in revertive mode 352 as well and paths must be switched accordingly. The priority can be 353 configuration or derivation from the PWid. Lower the PWid higher the 354 priority. However, this does not guarantee selection of same PW by 355 the T-PEs because, for example, mismatch of the configuration of the 356 PW priority in each T-PE. The intent of this application is to have 357 T-PE1 and T-PE2 synchronize the transmit and receive paths of the PW 358 over the network. In other words, both T-PE nodes are required to 359 transmit over the PW segment which is switched by the same S-PE. 360 This is desirable for ease of operation and troubleshooting. 362 3.4. PW redundancy between MTU-s in H-VPLS 363 Following figure illustrates the application of use of PW redundancy 364 to Hierarchical VPLS (H-VPLS). Here, and MTU-s is dual-homed to two 365 PE-rs. 367 |<-PSN1-->| |<-PSN2-->| 368 V V V V 369 +-----+ +-----+ 370 |MTU-s|=========|PE1 |======== 371 |..Active PW group....| H-VPLS-core 372 | |=========| |========= 373 +-----+ +-----+ 374 |.| 375 |.| +-----+ 376 |.|===========| |========== 377 |...Standby PW group|.H-VPLS-core 378 =============| PE2|========== 379 +-----+ 381 Figure 5 Multi-homed MTU-s in H-VPLS core 382 In Figure 5, the MTU-s is dual homed to PE1 and PE2 and has spoke 383 PWs to each of them. The MTU-s needs to choose only one of the spoke 384 PWs ( the active PW) to one of the PE to forward the traffic and the 385 other to standby status. The MTU-s can derive the status of the PWs 386 based on local policy configuration. PE1 and PE2 are connected to 387 the H-VPLS core on the other side of network. The MTU-s communicates 388 the status of its member PWs for a set of VSIs having common status 389 of Active or Standby. Here the MTU-s controls the selection of PWs 390 to forward the traffic. Signaling using PW grouping with a common 391 group-id in PWid FEC Element or Grouping TLV in Generalized PWid FEC 392 Element as defined in [2] to PE1 and PE2 respectively, is 393 recommended to scale better. 394 Whenever MTU-s performs a switchover, it needs to communicate to PE2 395 for the Standby PW group the changed status of active. 396 In this scenario, PE devices are aware of switchovers at MTU-s and 397 could generate MAC Withdraw Messages to trigger MAC flushing within 398 the H-VPLS full mesh. By default, MTU-s devices should still trigger 399 MAC Withdraw messages as currently defined in [5] to prevent two 400 copies of MAC withdraws to be sent (one by MTU-s and another one by 401 PEs). Mechanisms to disable MAC Withdraw trigger in certain devices 402 is out of the scope of this document. 404 3.5. PW redundancy between VPLS n-PEs 405 Following figure illustrates the application of use of PW redundancy 406 for dual homed connectivity between PE devices in a ring topology. 407 +-------+ +-------+ 408 | PE1 |=====================| PE2 |====... 409 +-------+ PW Group 1 +-------+ 410 || || 411 VPLS Domain A || || VPLS Domain B 412 || || 413 +-------+ +-------+ 414 | PE3 |=====================| PE4 |==... 415 +-------+ PW Group 2 +-------+ 416 Figure 6 Redundancy in Ring topology 417 In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and 418 PE4 in VPLS domain B via PW group 1 and group 2. Each of the PEs in 419 the respective domains is connected to each other as well as forming 420 the ring topology. Such scenarios may arise in inter-domain H-VPLS 421 deployments where rapid spanning tree (RSTP) or other mechanisms may 422 be used to maintain loop free connectivity of PW groups. 423 [5] outlines multi-domain VPLS services without specifying how 424 multiple redundant border PEs per domain per VPLS instance can be 425 supported. In the example above, PW group 1 may be blocked at PE1 by 426 RSTP and it is desirable to block the group at PE2 by virtue of 427 exchanging the PW preferential forwarding status of Standby. How the 428 PW grouping should be done here is again deployment specific and is 429 out of scope of the solution. 430 3.6. PW redundancy in VPLS Bridge Module Model 431 ----------------------------+ Provider +------------------------ 432 . Core . 433 +------+ . . +------+ 434 | n-PE |======================| n-PE | 435 Provider | (P) |---------\ /-------| (P) | Provider 436 Access +------+ ._ \ / . +------+ Access 437 Network . \/ . Network 438 (1) +------+ . /\ . +------+ (2) 439 | n-PE |----------/ \--------| n-PE | 440 | (B) |----------------------| (B) |_ 441 +------+ . . +------+ 442 . . 443 ----------------------------+ +------------------------ 444 Figure 7 Bridge Module Model 445 In Figure 7, two provider access networks, each having two n-PEs, 446 where the n-PEs are connected via a full mesh of PWs for a given 447 VPLS instance. As shown in the figure, only one n-PE in each access 448 network is serving as a Primary PE (P) for that VPLS instance and 449 the other n-PE is serving as the backup PE (B). In this figure, each 450 primary PE has two active PWs originating from it. Therefore, when a 451 multicast, broadcast, and unknown unicast frame arrives at the 452 primary n-PE from the access network side, the n-PE replicates the 453 frame over both PWs in the core even though it only needs to send 454 the frames over a single PW (shown with == in the figure) to the 455 primary n-PE on the other side. This is an unnecessary replication 456 of the customer frames that consumes core-network bandwidth (half of 457 the frames get discarded at the receiving n-PE). This issue gets 458 aggravated when there is three or more n-PEs per provider, access 459 network. For example if there are three n-PEs or four n-PEs per 460 access network, then 67% or 75% of core-BW for multicast, broadcast 461 and unknown unicast are respectively wasted. 463 In this scenario, n-PEs can disseminate the status of PWs 464 active/standby among them and furthermore to have it tied up with 465 the redundancy mechanism such that per VPLS instance the status of 466 active/backup n-PE gets reflected on the corresponding PWs emanating 467 from that n-PE. 468 4. Generic PW redundancy requirements 469 4.1. Protection switching requirements 470 o Protection architecture such as N:1,1:1 or 1+1 can be used. N:1 471 protection case is somewhat inefficient in terms of capacity 472 consumption hence implementations SHOULD support this method 473 while 1:1 being subset and efficient MUST be supported. 1+1 474 protection architecture can be supported but is left for further 475 study. 476 o Non-revertive mode MUST be supported, while revertive mode is an 477 optional one. 478 o Protection switchover can be operator driven like Manual 479 lockout/force switchover or due to signal failure. Both methods 480 MUST be supported and signal failure MUST be given higher 481 priority than any local or far end request. 482 4.2. Operational requirements 483 o (T-)PEs involved in protecting a PW SHOULD automatically discover 484 and attempt to resolve inconsistencies in the configuration of 485 primary/secondary PW. 486 o (T-)PEs involved in protecting a PW SHOULD automatically discover 487 and attempt to resolve inconsistencies in the configuration of 488 revertive/non-revertive protection switching mode. 489 o (T-)PEs that do not automatically discover or resolve 490 inconsistencies in the configuration of primary/secondary, 491 revertive/non-revertive, or other parameters MUST generate an 492 alarm upon detection of an inconsistent configuration. 493 o (T-)PEs involved with protection switching MUST support the 494 configuration of revertive or non-revertive protection switching 495 mode. 496 o (T-)PEs involved with protection switching SHOULD support the 497 local invocation of protection switching. 499 o (T-)PEs involved with protection switching SHOULD support the 500 local invocation of a lockout of protection switching. 501 o In standby status PW can still receive packets in order to avoid 502 black holing of in-flight packets during switchover. However in 503 case of use of VPLS application packets are dropped in standby 504 status except for the OAM packets. 506 5. Security Considerations 507 This document expects extensions to LDP that are needed for 508 protecting pseudo-wires. It will have the same security properties 509 as in LDP [4] and the PW control protocol [2]. 510 6. IANA considerations 511 This document has no actions for IANA. 513 7. Major Contributing Authors 514 The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre, 515 Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles 516 Heron and Thomas Nadeau who made a major contribution to the 517 development of this document. 519 Pranjal Dutta 520 Alcatel-Lucent 521 Email: pranjal.dutta@alcatel-lucent.com 523 Marc Lasserre 524 Alcatel-Lucent 525 Email: marc.lasserre@alcatel-lucent.com 527 Jonathan Newton 528 Cable & Wireless 529 Email: Jonathan.Newton@cw.com 531 Olen Stokes 532 Extreme Networks 533 Email: ostokes@extremenetworks.com 535 Hamid Ould-Brahim 536 Nortel 537 Email: hbrahim@nortel.com 539 Dave McDysan 540 Verizon 541 Email: dave.mcdysan@verizon.com 543 Giles Heron 544 Cisco Systems 545 Email: giles.heron@gmail.com Formatted: Field Code Thomas Nadeau Formatted: Computer Associates Formatted: Email: tnadeau@lucidvision.com 547 8. Acknowledgments 548 The authors would like to thank Vach Kompella, Kendall Harvey, 549 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 550 Niger for their valuable comments and suggestions. 552 9. References 553 9.1. Normative References 554 [1] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 557 LDP", RFC 4447, April 2006. 558 [3] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge 559 (PWE3) Architecture", RFC 3985 March 2005 560 [4] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", 561 RFC 5036, January 2001 562 [5] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 563 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007 564 9.2. Informative References 565 [6] Martini, L., et al., "Segmented Pseudo Wire", RFC6073, January 566 2011. 568 Author's Addresses 569 Praveen Muley 570 Alcatel-Lucent 571 701 E. Middlefiled Road 572 Mountain View, CA, USA 573 Email: Praveen.muley@alcatel-lucent.com 575 Mustapha Aissaoui 576 Alcatel-Lucent 577 600 March Rd 578 Kanata, ON, Canada K2K 2E6 579 Email: mustapha.aissaoui@alcatel-lucent.com 581 Matthew Bocci 582 Alcatel-Lucent 583 Voyager Place 584 Shoppenhangers Rd, 585 Maidenhead, Berks, UK 586 Email: matthew.bocci@alcatel-lucent.com