idnits 2.17.1 draft-ietf-l2vpn-vpls-inter-domain-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 date (May 16, 2014) is 3634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Z. Liu 3 Internet-Draft China Telecom 4 Intended status: Standards Track L. Jin 5 Expires: November 17, 2014 6 R. Chen 7 ZTE Corporation 8 D. Cai 9 S. Salam 10 Cisco 11 May 16, 2014 13 Redundancy Mechanism for Inter-domain VPLS Service 14 draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 16 Abstract 18 In many existing Virtual Private LAN Service (VPLS) inter-domain 19 deployments (based on RFC 4762), pseudowire (PW) connectivity offers 20 no Provider Edge (PE) node redundancy, or offers PE node redundancy 21 only with a single domain. This deployment approach incurs a high 22 risk of service interruption, since at least one domain will not 23 offer PE node redundancy. This document describes an inter-domain 24 VPLS solution that provides PE node redundancy across domains. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 17, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. PW redundancy application procedure for inter-domain 65 redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. ICCP switchover condition . . . . . . . . . . . . . . . . 6 67 5.1.1. Inter-domain PW failure . . . . . . . . . . . . . . . 6 68 5.1.2. PE node isolation . . . . . . . . . . . . . . . . . . 6 69 5.1.3. PE node failure . . . . . . . . . . . . . . . . . . . 6 70 5.2. Inter-domain redundancy with two-PWs . . . . . . . . . . . 7 71 5.3. Inter-domain redundancy with four-PWs . . . . . . . . . . 7 72 6. Management Considerations . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative references . . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative references . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 In many existing Virtual Private LAN Service (VPLS) deployments based 85 on [RFC4762], pseudowire (PW) connectivity offers no Provider Edge 86 (PE) node redundancy, or offers PE node redundancy only with a single 87 domain. This deployment approach incurs a high risk of service 88 interruption, since at least one domain will not offer PE node 89 redundancy. This document describes an inter-domain VPLS solution 90 that provides PE node redundancy across domains. The redundancy 91 mechanism will provide PE node redundancy and link redundancy in both 92 domains. The PE throughout the document refers to a routing and 93 bridging capable PE defined in [RFC4762] section 10. The domain in 94 this document refers to autonomous system (AS), or other 95 administrative domains. 97 The solution relies on the use of Inter-Chassis Communication 98 Protocol (ICCP) [I-D.ietf-pwe3-iccp] to coordinate between the two 99 redundant edge nodes, and use of PW Preferential Forwarding Status 100 Bit [RFC6870] to negotiate the PW status. There is no change to any 101 protocol message formats and no new protocol options are introduced. 102 This solution is a description of reusing existing protocol building 103 blocks to achieve the desired function, but also defines 104 implementation behavior necessary for the function to work. 106 2. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Motivation 114 Inter-AS VPLS offerings are widely deployed in service provider 115 networks today. Typically, the Autonomous System Border Router 116 (ASBR) and associated physical links that connect the domains carry a 117 multitude of services. As such, it is important to provide PE node 118 and link redundancy, to ensure service high availability and meet the 119 end customer service level agreements (SLAs). 121 Several current deployments of inter-AS VPLS are implemented like 122 inter-AS option A in [RFC4364] section 10, where Virtual Local Area 123 Network (VLAN) is used to hand-off the services between two domains. 124 In these deployments, PE node/link redundancy is achieved using 125 Multi-Chassis Link Aggregation (MC-LAG) and ICCP 126 [I-D.ietf-pwe3-iccp]. This, however, places two restrictions on the 127 interconnection: the two domains must be interconnected using 128 Ethernet links, and the links must be homogeneous, i.e. of the same 129 speed, in order to be aggregated. These two conditions can not 130 always be guaranteed in live deployments. For instance, there are 131 many scenarios where the interconnection between the domains uses 132 Packet over Synchronous Optical Networking (SONET) / Synchronous 133 Digital Hierarchy (SDH), thereby ruling out the applicability of MC- 134 LAG as a redundancy mechanism. As such, from a technical point of 135 view, it is desirable to use PWs to interconnect the VPLS domains, 136 and to offer resiliency using PW redundancy mechanisms. 138 Multiprotocol Border Gateway Protocol (MP-BGP) can be used for VPLS 139 inter-domain protection, as described in [RFC6074], using either 140 option B or option C inter-AS models. However, with this solution, 141 the protection time relies on BGP control plane convergence. In 142 certain deployments, with tight SLA requirements on availability, 143 this mechanism may not provide the desired failover time 144 characteristics. Furthermore, in certain situations MP-BGP is not 145 deployed for VPLS. The redundancy solution described in this 146 document reuses ICCP [I-D.ietf-pwe3-iccp] and PW redundancy [RFC6718] 147 to provide fast convergence. 149 Furthermore, in the case where Label Switched Multicast is not used 150 for VPLS multicast [RFC7117], the solution described here provides a 151 better behavior compared to inter-AS option B: with option B, each PE 152 must perform ingress replication to all other PEs in its local as 153 well as the remote domain. Whereas, with the ICCP solution, the PE 154 only replicates to local PEs and to the ASBR. The ASBR then sends 155 traffic point-to-point to the remote ASBR, and the remote ASBR 156 replicates to its local PEs. As a result, the load of replication is 157 distributed and is more efficient than option B. 159 Two PW redundancy modes defined in [RFC6718], namely independent mode 160 and master/slave mode, are applicable in this solution. In order to 161 maintain control plane separation between two domains, the 162 independent mode is preferred by operators. The master/slave mode 163 provides some enhanced capabilities and, hence, is included in this 164 document. 166 4. Network Use Case 168 There are two network use cases for VPLS inter-domain redundancy: 169 two-PWs redundancy case, and four-PWs redundancy case. 171 Figure 1 presents an example use case with two inter-domain PWs. 172 PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs 173 within its own AS. PE3 and PE4 belong to one redundancy group (RG), 174 and PE5 and PE6 belong to another RG. A deployment example of this 175 use case is where there are only two physical links between two 176 domains and PE3 is physically connected with PE5, and PE4 is 177 physically connected with PE6. 179 +---------+ +---------+ 180 +---+ | +-----+ | active PW1 | +-----+| +---+ 181 |PE1|---|-| PE3 |-|-----------------|--| PE5 ||----|PE7| 182 +---+\ |/+-----+ | | +-----+\ /+---+ 183 | \ / | * | | * | |\ / | 184 | \| | |ICCP| |ICCP| | | \ | 185 | / \ | * | | * | |/ \ | 186 +---+/ |\+-----+ | | +-----+/ \+---+ 187 |PE2|---|-| PE4 |-|-----------------|--| PE6 ||----|PE8| 188 +---+ | +-----+ | standby PW2 | +-----+| +---+ 189 | | | | 190 | | | | 191 | RG1 | | RG2 | 192 +---------+ +---------+ 193 operator A network operator B network 195 Figure 1 197 Figure 2 presents a four-PWs inter-domain VPLS redundancy use case. 198 PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs 199 within its own AS. A deployment example of this use case is where 200 there are four physical links between two domains and four PEs are 201 physically connected with each other with four links. 203 +---------+ +---------+ 204 +---+ | +-----+ | | +-----+| +---+ 205 |PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7| 206 | | | | |-|-PW3\ /------|--| || | | 207 +---+\ |/+-----+ | \ / | +-----+\ /+---+ 208 | \ / | * | \ / | * | |\ / | 209 | \| | |ICCP| X |ICCP| | | \ | 210 | / \ | * | / \ | * | |/ \ | 211 +---+/ |\+-----+ | / \ | +-----+/ \+---+ 212 | | | | |-|-PW4/ \------|--| || | | 213 |PE2|---|-| PE4 |-|----PW2----------|--| PE6 ||----|PE8| 214 +---+ | +-----+ | | +-----+| +---+ 215 | | | | 216 | | | | 217 | RG1 | | RG2 | 218 +---------+ +---------+ 219 operator A network operator B network 221 Figure 2 223 5. PW redundancy application procedure for inter-domain redundancy 225 PW redundancy application procedures are described in section 9.1 of 226 [I-D.ietf-pwe3-iccp]. When a PE node encounters a failure, the other 227 PE takes over. This document reuses the PW redundancy mechanism 228 defined in[I-D.ietf-pwe3-iccp], with new ICCP switchover conditions 229 as specified in following section. 231 There are two PW redundancy modes defined in [RFC6870]: Independent 232 mode and Master/Slave mode. For the inter-domain four-PW scenario, 233 it is required for PEs to ensure that the same mode is supported on 234 the two ICCP peers in the same RG. This can be achieved using manual 235 configuration at the ICCP peers. Other methods for ensuring 236 consistency are out of the scope of this document. 238 5.1. ICCP switchover condition 240 5.1.1. Inter-domain PW failure 242 When a PE receives advertisements from the active PE, in the same RG, 243 indicating that all the inter-domain PW status has changed to DOWN/ 244 STANDBY, then if it has the highest priority (after the advertising 245 PE), it SHOULD advertise active state for all of its associated 246 inter-domain PWs. 248 5.1.2. PE node isolation 250 When a PE detects failure of all PWs to the local domain, it SHOULD 251 advertise standby state for all its inter-domain PWs to trigger 252 remote PE to switchover. 254 5.1.3. PE node failure 256 When a PE node detects that the active PE, that is a member of the 257 same RG, has gone down, if the local PE has redundant PWs for the 258 affected services and has the highest priority (after the failed PE), 259 it SHOULD advertise the active state for all associated inter-domain 260 PWs. 262 5.2. Inter-domain redundancy with two-PWs 264 In this use case, it is recommended that the operation be as follows: 265 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 266 both domains; 267 o PW redundancy mode: independent mode only; 268 o Protection architectures: 1:1(1 standby, 1 active). 270 The switchover rules described in section 5.1 apply. Before 271 deploying this inter-domain VPLS, the operators should negotiate to 272 configure the same PW high/low priority at two PW end-points. The 273 inter-domain VPLS relationship normally involves a contractual 274 process between operators, and the configuration of PW roles forms 275 part of this process. E.g, in figure 1, PE3 and PE5 must both have 276 higher/lower priority than PE4 and PE6, otherwise both PW1 and PW2 277 will be in standby state. 279 5.3. Inter-domain redundancy with four-PWs 281 In this use case, there are two options to provide protection: 1:1 282 and 3:1 protection. The inter-domain PWs that connect to the same PE 283 should have proper PW priority to advertise same active/standby 284 state. E.g, in figure 2, both PW1 and PW3 connected to PE3 should 285 advertise active/standby state. 287 For 1:1 protection model, the operation would be as follows: 288 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 289 both domains; 290 o PW redundancy mode: independent mode only; 291 o Protection architectures: 1:1(1 standby, 1 active). 293 The switchover rules described in section 5.1 apply. In this case, 294 the operators do not need to do any coordination of the inter-domain 295 PW priority. The PE detecting one PW DOWN SHOULD set the other PW to 296 STANDBY if available, and then synchronize the updated state to its 297 ICCP peer. When a PE detects that the PWs from ICCP peer PE are DOWN 298 or STANDBY, it SHOULD switchover as described in section 5.1.1. 300 There are two variants of the 3:1 protection model. We will refer to 301 them as options A and B. The implementation MUST support option A, 302 and MAY support option B. Option B will be useful when the two legacy 303 PEs in one domain does not support the function in this document. 304 The two legacy PEs still need to support PW redundancy defined in 305 [RFC6870], and be configured as slave node. 307 For option A of the 3:1 protection model, the support of Request 308 Switchover status bit [RFC6870] is required. The operation is as 309 follows: 311 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 312 both domains; 313 o PW redundancy mode: Independent mode with 'request switchover' bit 314 support; 315 o Protection architectures: 3:1 (3 standby, 1 active). 317 In this case, the procedure on the PE for the PW failure is per 318 section 6.3 of [RFC6870], and with the following additions: 319 o When the PE detects failure of the active inter-domain PW, it 320 SHOULD switch to the other local standby inter-domain PW if 321 available, and send an updated LDP PW status message with the 322 'request switchover' bit set on that local standby inter-domain PW 323 to the remote PE; 324 o Local and remote PE SHOULD also update the new PW status to their 325 ICCP peers, respectively, in Application Data Messages with PW-RED 326 Synchronization Request TLV for corresponding service, so as to 327 synchronize the latest PW status on both PE sides. 328 o While waiting for the acknowledgement, the PE that sends the 329 'request switchover' bit may receive a switchover request from its 330 ICCP peer's PW remote endpoint by virtue of the ICCP 331 synchronization. The PE MUST compare IP addresses with that PW 332 remote peer. The PE with a higher IP address SHOULD ignore the 333 request and continue to wait for the acknowledgement from its peer 334 in the remote domain. The PE with the lower IP address SHOULD 335 clear 'request switchover' bit and set 'Preferential Forwarding' 336 local status bit, and update the PW status to ICCP peer. 337 o The remote PE receiving 'request switchover' bit SHOULD 338 acknowledge the request and activate the PW only when it is ready 339 to take over as described in section 5.1, otherwise, it SHOULD 340 ignore the request. 342 The PE node isolation failure and PE node failure is described in 343 section 5.1. 345 For option B of 3:1 protection model, master/slave mode support is 346 required, and should be as follows: 347 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 348 only one domain; 349 o PW redundancy mode: master/slave only; 350 o Protection architectures: 3:1 (3 standby, 1 active). 352 When master/slave PW redundancy mode is employed, the network 353 operators of two domains must agree on which domain PEs will be 354 master, and configure the devices accordingly. The inter-domain PWs 355 that connect to one PE should have higher PW priority than the PWs on 356 the other PE in the same RG. The procedure on the PE for PW failure 357 is as follows: 359 o The PE with higher PW priority should only enable one PW active, 360 and the other PWs standby. 361 o When the PE detects active PW DOWN, it SHOULD enable the other 362 local standby PW to be active with preference. Only when two 363 inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in 364 the same RG SHOULD switchover as described in section 5.1. 366 The PE node isolation failure and PE node failure is described in 367 section 5.1. 369 6. Management Considerations 371 When deploying the inter-domain redundancy mechanism described in 372 this document, consistent provisioning is required for proper 373 operation. The two domains must both use the same use case (section 374 5.2 or section 5.3). Within each section, all of the described modes 375 and options must be provisioned identically both within each RG and 376 between the RGs. Additionally, for the two-PWs redundancy options 377 defined in section 5.2, the two operators must also negotiate to 378 configure same high/low PW priority at the two PW end-points. If the 379 provisioning is inconsistent, then the inter-domain redundancy 380 mechanism may not work properly. 382 7. Security Considerations 384 Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP 385 control plane, [RFC4762] and [RFC6870] for PW control plane, this 386 document has additional security consideration for ICCP control 387 plane. 389 In this document, ICCP protocol is deployed between two PEs or ASBRs. 390 The two PEs or ASBRs should only be connected by a network that is 391 well managed and whose service levels and availability are highly 392 monitored. This should be ensured by the operator. 394 The state flapping on the inter-domain and intra-domain PW may cause 395 security threats or be exploited to create denial of service attacks. 396 For example, excessive PW state flapping (e.g., by malicious peer 397 PE's implementation) may lead to excessive ICCP exchanges. 398 Implementations SHOULD provide mechanisms to perform control-plane 399 policing and mitigate such types of attacks. 401 8. IANA Consideration 403 No IANA allocation is required in this document. 405 9. Acknowledgements 407 The authors would like to thank Sami Boutros, Giles Heron, Adrian 408 Farrel, Andrew G. Malis and Stephen Kent for their valuable comments. 410 10. Contributors 412 Daniel Cohn 414 Email:daniel.cohn.ietf@gmail.com 416 Yubao Wang 417 ZTE Corporation 418 Nanjing, China 419 Email: wang.yubao@zte.com.cn 421 11. References 423 11.1. Normative references 425 [I-D.ietf-pwe3-iccp] 426 Martini, L., Salam, S., Sajassi, A., and S. Matsushima, 427 "Inter-Chassis Communication Protocol for L2VPN PE 428 Redundancy", draft-ietf-pwe3-iccp-16 (work in progress), 429 March 2014. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential 435 Forwarding Status Bit", RFC 6870, February 2013. 437 11.2. Informative references 439 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 440 Networks (VPNs)", RFC 4364, February 2006. 442 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 443 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 444 RFC 4762, January 2007. 446 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 447 "Provisioning, Auto-Discovery, and Signaling in Layer 2 448 Virtual Private Networks (L2VPNs)", RFC 6074, 449 January 2011. 451 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 452 Redundancy", RFC 6718, August 2012. 454 [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. 455 Kodeboniya, "Multicast in Virtual Private LAN Service 456 (VPLS)", RFC 7117, February 2014. 458 Authors' Addresses 460 Zhihua Liu 461 China Telecom 462 109 Zhongshan Ave. 463 Guangzhou 510630 464 P.R.China 466 Email: zhliu@gsta.com 468 Lizhong Jin 469 Shanghai 470 P.R.China 472 Email: lizho.jin@gmail.com 474 Ran Chen 475 ZTE Corporation 476 NO.19 East Huayuan Road 477 Haidian District Beijing 100191 478 P.R.China 480 Email: chen.ran@zte.com.cn 482 Dennis Cai 483 Cisco 484 3750 Cisco Way, 485 San Jose, California 95134 486 USA 488 Email: dcai@cisco.com 489 Samer Salam 490 Cisco 491 595 Burrard Street, Suite:2123 492 Vancouver, BC V7X 1J1 493 Canada 495 Email: ssalam@cisco.com