idnits 2.17.1 draft-ietf-pwe3-redundancy-03.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 is 1 instance of too long lines in the document, the longest one being 11 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 (May 14, 2010) is 5096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 580, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-14 Summary: 2 errors (**), 0 flaws (~~), 3 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 Alcatel-Lucent 4 Expires: November 2010 5 May 14, 2010 7 Pseudowire (PW) Redundancy 8 draft-ietf-pwe3-redundancy-03.txt 10 Abstract 12 This document describes a framework comprised of few scenarios and 13 associated requirements where PW redundancy is needed. A set of 14 redundant PWs is configured between PE nodes in SS-PW applications, 15 or between T-PE nodes in MS-PW applications. In order for the PE/T-PE 16 nodes to indicate the preferred PW to forward to one another, a new 17 status is needed to indicate the preferential forwarding status of 18 active or standby for each PW in the redundancy set. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 14, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [1]. 58 Table of Contents 60 1. Terminology .............................................. 2 61 2. Introduction.............................................. 3 62 3. Reference Model........................................... 4 63 3.1. PE Architecture...................................... 4 64 3.2. Multiple Multi-homed................................. 5 65 3.3. Single Homed CE with MS-PW redundancy................ 7 66 3.4. PW redundancy between MTU-s.......................... 8 67 3.5. PW redundancy between n-PEs.......................... 9 68 3.6. PW redundancy in Bridge Module Model................. 10 69 4. Generic PW redundancy requirements........................ 11 70 4.1. Protection switching requirements.................... 11 71 4.2. Operational requirements............................. 11 72 5. Security Considerations................................... 12 73 6. IANA considerations....................................... 12 74 7. Major Contributing Authors................................ 12 75 8. Acknowledgments........................................... 13 76 9. References................................................ 14 77 9.1. Normative References................................. 14 78 9.2. Informative References............................... 14 79 Author's Addresses........................................... 14 81 1. Terminology 83 o Active PW. A PW whose preferential status is set to Active and 84 Operational status is UP and is used for forwarding user and OAM 85 traffic. 87 o Standby PW. A PW whose preferential status is set to Standby and 88 Operational status is UP and is not used for forwarding user 89 traffic but may forward OAM traffic. 91 o PW Endpoint: A PE where a PW terminates on a point where Native 92 Service Processing is performed, e.g., A SS-PW PE, an MS-PW T-PE, 93 or an H-VPLS MTU-s or PE-rs. 95 o Primary PW: the PW which a PW endpoint activates in preference to 96 any other PW when more than one PW qualify for active state. When 97 the primary PW comes back up after a failure and qualifies for 98 active state, the PW endpoint always reverts to it. The 99 designation of Primary is performed by local configuration for 100 the PW at the PE. 102 o Secondary PW: when it qualifies for active state, a Secondary PW 103 is only selected if no Primary PW is configured or if the 104 configured primary PW does not qualify for active state (e.g., is 105 DOWN). By default, a PW in a redundancy PW set is considered 106 secondary. There is no Revertive mechanism among secondary PWs. 108 o Revertive protection switching. Traffic will be carried by 109 primary PW if it is Operationally UP and the wait-to-restore 110 timer expires and primary PW is made the Active PW. 112 o Non-revertive protection switching. Traffic will be carried by 113 the last PW selected as a result of previous active PW entering 114 Operationally DOWN state. 116 o Manual selection of PW . Ability for the operator to manually 117 select the primary/secondary PWs. 119 This document uses the term 'PE' to be synonymous with both PEs as 120 per RFC3985 and T-PEs as per RFC5659. 122 This document uses the term 'PW' to be synonymous with both PWs as 123 per RFC3985 and SS-PWs, MS-PWs, S-PEs, PW-segment and PW 124 switching point as per RFC5659. 126 2. Introduction 128 In single-segment PW (SS-PW) applications, protection for the PW is 129 provided by the PSN layer. This may be an Resource Reservation 130 Protocol traffic engineered (RSVP-TE) labeled switch (LSP) with a 131 fast-Reroute (FRR) backup and/or an end-to-end backup LSP. There are 132 applications however where the backup PW terminates on a different 133 target PE node. PSN protection mechanisms cannot protect against 134 failure of the target PE node or the failure of the remote AC. 136 In multi-segment PW (MS-PW) applications, a primary and one or more 137 secondary PWs in standby mode are configured in the network. The 138 paths of these PWs are diverse in the sense that they are switched at 139 different S-PE nodes. In these applications, PW redundancy is 140 important for the service resilience. 142 In some deployments, it is important for operators that particular PW 143 is preferred if it is available. For example, PW path with least 144 latency may be preferred. 146 This document describes framework for these applications and its 147 associated operational requirements. The framework comprises of new 148 required status called preferential status to PW apart from the 149 operational status already defined in the PWE3 control protocol [2]. 151 3. Reference Model 153 Following figures shows the reference architecture of PE for the PW 154 redundancy and its usage in different topologies and applications. 156 3.1. PE Architecture 158 Figure 1 shows the PE architecture for PW redundancy, when more than 159 one PW in a redundant set is associated with a single AC. This is 160 based on the architecture in Figure 4b of RFC3985 [3]. The forwarder 161 selects which of the redundant PWs to using the criteria described in 162 this document. 164 +----------------------------------------+ 165 | PE Device | 166 +----------------------------------------+ 167 Single | | Single | PW Instance 168 AC | + PW Instance X<===========> 169 | | | 170 | |----------------------| 171 <------>o | Single | PW Instance 172 | Forwarder + PW Instance X<===========> 173 | | | 174 | |----------------------| 175 | | Single | PW Instance 176 | + PW Instance X<===========> 177 | | | 178 +----------------------------------------+ 179 Figure 1 PE architecture for PW redundancy 181 3.2. Multiple Multi-homed 183 |<-------------- Emulated Service ---------------->| 184 | | 185 | |<------- Pseudo Wire ------>| | 186 | | | | 187 | | |<-- PSN Tunnels-->| | | 188 | V V V V | 189 V AC +----+ +----+ AC V 190 +-----+ | |....|.......PW1........|....| | +-----+ 191 | |----------| PE1|...... .........| PE3|----------| | 192 | CE1 | +----+ \ / PW3 +----+ | CE2 | 193 | | +----+ X +----+ | | 194 | | | |....../ \..PW4....| | | | 195 | |----------| PE2| | PE4|--------- | | 196 +-----+ | |....|.....PW2..........|....| | +-----+ 197 AC +----+ +----+ AC 199 Figure 2 Multiple Multi-homed CEs with single SS-PW redundancy 201 In the Figure 2 illustrated above both CEs, CE1 and CE2 are dual- 202 homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for 203 dual-homing and the used protocols are outside the scope of this 204 document. Note that the PSN tunnels are not shown in this figure for 205 clarity. However, it can be assumed that each of the PWs shown is 206 encapsulated in a separate PSN tunnel. 208 PE1 has PW1 and PW4 service connecting PE3 and PE4 respectively. 209 Similarly PE2 has PW2 and Pw3 pseudo wire service connecting PE4 and 210 PE3 respectively. PW1, PW2, PW3 and PW4 are all operationally UP. In 211 order to support N:1 or 1:1 only one PW is required to be selected to 212 forward the traffic. Thus the PW needs to reflect its new status 213 apart from the operational status. We call this as preferential 214 forwarding status with state representing 'active' the one carrying 215 traffic while the other 'standby' which is operationally UP but not 216 forwarding traffic. The method of deriving Active/Standby status of 217 the AC is outside the scope of this document. 219 A new algorithm needs to be developed using the preferential 220 forwarding state of PW and select only one PW to forward. 222 On failure of AC between the dual homed CE1 in this case lets say PE1 223 the preferential status on PE2 needs to be changed. Different 224 mechanisms/protocols can be used to achieve this and these are beyond 225 the scope of this document. After the change in status the algorithm 226 for selection of PW needs to revaluate and select PW to forward the 227 traffic. In this application, because each dual-homing algorithm 228 running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, 229 PE4}, selects the active AC independently, there is a need to signal 230 the active status of the AC such that the PE nodes can select a 231 common active PW path for end-to-end forwarding between CE1 and CE2. 232 This helps in restricting the changes occurring on one side of 233 network due to failure to the other side of the network. 235 Also the failures in the carrier core network MUST NOT be propagated 236 to customer network. Hence network operator should take this 237 consideration while designing the network. For ex. if there is 238 failure of LSP tunnel, operator should have rely on FRR or an 239 alternate LSP path/tunnel which will be seamless to the PW service. 240 Note this method also protects against any single PE failure or some 241 dual PE failures. 243 One Multi-homed CE with single SS-PW redundancy application is a 244 subset of above. Only PW1 and PW3 exist in this case. This helps 245 against AC failure and PE failure of dual homed AC. Similar 246 requirements applies in usage MS-PW redundancy as well. An additional 247 requirement applicable to MS-PW is forwarding of status notification 248 through S-PE. In general from customer view, SS-PW and MS-PW has 249 similar resiliency requirement. 251 There is also a 1:1 protection switching case that is a subset of the 252 above where PW3 and PW4 are not present. 254 o If the CEs do not perform native service protection switching, but 255 instead may use load balancing. This protects against AC failures 256 and can use the native service to indicate active/failed state. 258 o If each CE homes to different PEs, then the CEs can implement 259 native service protection switching, without any PW redundancy 260 functions. All that the PW needs to do is detect AC, PE, or PSN 261 tunnel failures and convey that information to both PEs at the end 262 of the PW. This is applicable to MS-PW as well. 264 3.3. Single Homed CE with MS-PW redundancy 266 This is the main application of interest and the network setup is 267 shown in Figure 3 269 Native |<------------Pseudo Wire------------>| Native 270 Service | | Service 271 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 272 | V V V V V V | 273 | +-----+ +-----+ +-----+ | 274 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 275 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 276 | CE1| | |=========| |=========| | | CE2| 277 | | +-----+ +-----+ +-----+ | | 278 +----+ |.||.| |.||.| +----+ 279 |.||.| +-----+ |.||.| 280 |.||.|=========| |========== .||.| 281 |.||...PW2-Seg1......|.PW2-Seg2...||.| 282 |.| ===========|S-PE2|============ |.| 283 |.| +-----+ |.| 284 |.|============+-----+============= .| 285 |.....PW3-Seg1.| | PW3-Seg2......| 286 ==============|S-PE3|=============== 287 | | 288 +-----+ 290 Figure 3 Single homed CE with multi-segment pseudo-wire redundancy 292 In Figure 3, CE1 is connected to PE1 in provider Edge 1 and CE2 to 293 PE2 in provider edge 2 respectively. There are three segmented PWs. A 294 PW1, is switched at S-PE1, PW2, which is switched at S-PE2 and PW3, 295 is switched at S-PE3. 297 Since there is no multi-homing running on the AC, the T-PE nodes 298 would advertise 'Active' for the forwarding status based on the 299 priority. Priorities associate meaning of 'primary PW' and 'secondary 300 PW'. These priorities MUST be used in revertive mode as well and 301 paths must be switched accordingly. The priority can be configuration 302 or derivation from the PWid. Lower the PWid higher the priority. 303 However, this does not guarantee selection of same PW by the T-PEs 304 because, for example, mismatch of the configuration of the PW 305 priority in each T-PE. The intent of this application is to have T- 306 PE1 and T-PE2 synchronize the transmit and receive path of the PW 307 over the network. In other words, both T-PE nodes are required to 308 transmit over the PW segment which is switched by the same S-PE. This 309 is desirable for ease of operation and troubleshooting. 311 3.4. PW redundancy between MTU-s 313 Following figure illustrates the application of use of PW redundancy 314 in spoke PW by dual homed MTU-s to PEs. 316 |<-PSN1-->| |<-PSN2-->| 317 V V V V 318 +-----+ +-----+ 319 |MTU-s|=========|PE1 |======== 320 |..Active PW group....| H-VPLS-core 321 | |=========| |========= 322 +-----+ +-----+ 323 |.| 324 |.| +-----+ 325 |.|===========| |========== 326 |...Standby PW group|.H-VPLS-core 327 =============| PE2|========== 328 +-----+ 330 Figure 4 Multi-homed MTU-s in H-VPLS core 332 In Figure 4, MTU-s is dual homed to PE1 and PE2 and has spoke PWs to 333 each of them. MTU-s needs to choose only one of the spoke PW (active 334 PW) to one of the PE to forward the traffic and the other to standby 335 status. MTU-s can derive the status of the PWs based on local policy 336 configuration. PE1 and PE2 are connected to H-VPLS core on the other 337 side of network. MTU-s communicates the status of its member PWs for 338 a set of VSIs having common status Active/Standby. Here MTU-s 339 controls the selection of PWs to forward the traffic. Signaling 340 using PW grouping with common group-id in PWid FEC Element or 341 Grouping TLV in Generalized PWid FEC Element as defined in [2] to PE1 342 and PE2 respectively, is encouraged to scale better. 344 Whenever MTU-s performs a switchover, it needs to communicate to PE2 345 for the Standby PW group the changed status of active. 347 In this scenario, PE devices are aware of switchovers at MTU-s and 348 could generate MAC Withdraw Messages to trigger MAC flushing within 349 the H-VPLS full mesh. By default, MTU-s devices should still trigger 350 MAC Withdraw messages as currently defined in [5] to prevent two 351 copies of MAC withdraws to be sent (one by MTU-s and another one by 352 PEs). Mechanisms to disable MAC Withdraw trigger in certain devices 353 is out of the scope of this document. 355 3.5. PW redundancy between n-PEs 357 Following figure illustrates the application of use of PW redundancy 358 for dual homed connectivity between PE devices in a ring topology. 360 +-------+ +-------+ 362 | PE1 |=====================| PE2 |====... 364 +-------+ PW Group 1 +-------+ 366 || || 368 VPLS Domain A || || VPLS Domain B 370 || || 372 +-------+ +-------+ 374 | PE3 |=====================| PE4 |==... 376 +-------+ PW Group 2 +-------+ 378 Figure 5 Redundancy in Ring topology 380 In Figure 5, PE1 and PE3 from VPLS domain A are connected to PE2 and 381 PE4 in VPLS domain B via PW group 1 and group 2. Each of the PE in 382 respective domain is connected to each other as well to form the ring 383 topology. Such scenarios may arise in inter-domain H-VPLS deployments 384 where RSTP or other mechanisms may be used to maintain loop free 385 connectivity of PW groups. 387 Ref.[5] outlines about multi-domain VPLS service without specifying 388 how redundant border PEs per domain per VPLS instance can be 389 supported. In the example above, PW group1 may be blocked at PE1 by 390 RSTP and it is desirable to block the group at PE2 by virtue of 391 exchanging the PW preferential status as Standby. How the PW grouping 392 should be done here is again deployment specific and is out of scope 393 of the solution. 395 3.6. PW redundancy in Bridge Module Model 397 ----------------------------+ Provider +------------------------ 399 . Core . 401 +------+ . . +------+ 403 | n-PE |======================| n-PE | 405 Provider | (P) |---------\ /-------| (P) | Provider 407 Access +------+ ._ \ / . +------+ Access 409 Network . \/ . Network 411 (1) +------+ . /\ . +------+ (2) 413 | n-PE |----------/ \--------| n-PE | 415 | (B) |----------------------| (B) |_ 417 +------+ . . +------+ 419 . . 421 ----------------------------+ +------------------------ 423 Figure 6 Bridge Module Model 425 In Figure 6, two provider access networks, each having two n-PEs, 426 where the n-PEs are connected via a full mesh of PWs for a given VPLS 427 instance. As shown in the figure, only one n-PE in each access 428 network is serving as a Primary PE (P) for that VPLS instance and the 429 other n-PE is serving as the backup PE (B).In this figure, each 430 primary PE has two active PWs originating from it. Therefore, when a 431 multicast, broadcast, and unknown unicast frame arrives at the 432 primary n-PE from the access network side, the n-PE replicates the 433 frame over both PWs in the core even though it only needs to send the 434 frames over a single PW (shown with == in the figure) to the primary 435 n-PE on the other side. This is an unnecessary replication of the 436 customer frames that consumes core-network bandwidth (half of the 437 frames get discarded at the receiving n-PE). This issue gets 438 aggravated when there is three or more n-PEs per provider, access 439 network. For example if there are three n-PEs or four n-PEs per 440 access network, then 67% or 75% of core-BW for multicast, broadcast 441 and unknown unicast are respectively wasted. 443 In this scenario, n-PEs can disseminate the status of PWs 444 active/standby among themselves and furthermore to have it tied up 445 with the redundancy mechanism such that per VPLS instance the status 446 of active/backup n-PE gets reflected on the corresponding PWs 447 emanating from that n-PE. 449 4. Generic PW redundancy requirements 451 4.1. Protection switching requirements 453 o Protection architecture such as N:1,1:1 or 1+1 can be used. N:1 454 protection case is somewhat inefficient in terms of capacity 455 consumption hence implementations SHOULD support this method 456 while 1:1 being subset and efficient MUST be supported. 1+1 457 protection architecture can be supported but is left for further 458 study. 460 o Non-revertive mode MUST be supported, while revertive mode is an 461 optional one. 463 o Protection switchover can be operator driven like Manual 464 lockout/force switchover or due to signal failure. Both methods 465 MUST be supported and signal failure MUST be given higher 466 priority than any local or far end request. 468 4.2. Operational requirements 470 o (T-)PEs involved in protecting a PW SHOULD automatically discover 471 and attempt to resolve inconsistencies in the configuration of 472 primary/secondary PW. 474 o (T-)PEs involved in protecting a PW SHOULD automatically discover 475 and attempt to resolve inconsistencies in the configuration of 476 revertive/non-revertive protection switching mode. 478 o (T-)PEs that do not automatically discover or resolve 479 inconsistencies in the configuration of primary/secondary, 480 revertive/non-revertive, or other parameters MUST generate an 481 alarm upon detection of an inconsistent configuration. 483 o (T-)PEs involved with protection switching MUST support the 484 configuration of revertive or non-revertive protection switching 485 mode. 487 o (T-)PEs involved with protection switching SHOULD support the 488 local invocation of protection switching. 490 o (T-)PEs involved with protection switching SHOULD support the 491 local invocation of a lockout of protection switching. 493 o In standby status PW can still receive packets in order to avoid 494 black holing of in-flight packets during switchover. However in 495 case of use of VPLS application packets are dropped in standby 496 status except for the OAM packets. 498 5. Security Considerations 500 This document expects extensions to LDP that are needed for 501 protecting pseudo-wires. It will have the same security properties as 502 in LDP [4] and the PW control protocol [2]. 504 6. IANA considerations 506 This document has no actions for IANA. 508 7. Major Contributing Authors 510 The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta, 511 Marc Lasserre, Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave 512 Mcdysan, Giles Heron and Thomas Nadeau who made a major contribution 513 to the development of this document. 515 Matthew Bocci 516 Alcatel 517 Voyager Place, Shoppenhangers Rd 518 Maidenhead, Berks, UK SL6 2PJ 519 Email: matthew.bocci@alcatel.com 521 Pranjal Kumar Dutta 522 Alcatel-Lucent 523 Email: pdutta@alcatel-lucent.com 525 Marc Lasserre 526 Alcatel-Lucent 527 Email: mlasserre@alcatel-lucent.com 529 Jonathan Newton 530 Cable & Wireless 531 Email: Jonathan.Newton@cwmsg.cwplc.com 533 Olen Stokes 534 Extreme Networks 535 Email: ostokes@extremenetworks.com 537 Hamid Ould-Brahim 538 Nortel 539 Email: hbrahim@nortel.com 541 Dave McDysan 542 Verizon 543 Email: dave.mcdysan@verizon.com 545 Giles Heron 546 BT 547 Email: giles.heron@gmail.com 549 Thomas Nadeau 550 BT 551 Email: tnadeau@lucidvision.com 553 8. Acknowledgments 555 The authors would like to thank Vach Kompella, Kendall Harvey, 556 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 557 Niger for their valuable comments and suggestions. 559 9. References 561 9.1. Normative References 563 [1] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 567 LDP", RFC 4447, April 2006. 569 [3] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge 570 (PWE3) Architecture", RFC 3985 March 2005 572 [4] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", 573 RFC 5036, January 2001 575 [5] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 576 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007 578 9.2. Informative References 580 [6] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 581 segmented-pw-14.txt, October 2010. 583 Author's Addresses 585 Praveen Muley 586 Alcatel 587 701 E. Middlefiled Road 588 Mountain View, CA, USA 589 Email: Praveen.muley@alcatel.com 591 Mustapha Aissaoui 592 Alcatel 593 600 March Rd 594 Kanata, ON, Canada K2K 2E6 595 Email: mustapha.aissaoui@alcatel.com