idnits 2.17.1 draft-liu-l2vpn-vpls-inter-domain-redundancy-04.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 lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2012) is 4316 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC5561' is defined on line 386, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-05 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-07 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-10 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 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: BCP L. Jin 5 Expires: January 3, 2013 R. Chen 6 ZTE 7 D. Cai 8 S. Salam 9 Cisco 10 July 2, 2012 12 Redundancy provisioning for VPLS Inter-domain 13 draft-liu-l2vpn-vpls-inter-domain-redundancy-04 15 Abstract 17 In many VPLS deployments based on RFC4762, inter-domain connectivity 18 has been deployed without node redundancy, or with node redundancy in 19 a single domain. This document describes a solution for inter-domain 20 VPLS based on RFC4762 with node and link redundancy in both domains. 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. PW redundancy application procedure for inter-domain . . . . . 5 61 5.1. ICCP switchover condition . . . . . . . . . . . . . . . . . 6 62 5.1.1. Inter-domain PW failure . . . . . . . . . . . . . . . . 6 63 5.1.2. PE node isolation . . . . . . . . . . . . . . . . . . . 6 64 5.1.3. PE node failure . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Inter-domain redundancy with two-PWs . . . . . . . . . . . 6 66 5.3. Inter-domain redundancy with four-PWs . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative references . . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 In many VPLS deployment based on [RFC4762], inter-domain connectivity 78 has been deployed without node redundancy, or with node redundancy in 79 a single domain. This document describes a solution for inter-domain 80 VPLS based on [RFC4762] with node and link redundancy in both domain. 81 The domain in this document refers to AS, or other administrative 82 domains. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC2119. 90 3. Motivation 92 Inter-AS VPLS offerings are widely deployed in service provider 93 networks today. Typically, the ASBRs and associated physical links 94 that connect the domains carry a multitude of services. As such, it 95 is important to provide link and node redundancy, to ensure service 96 high availability and meet end customer service level agreements 97 (SLAs). 99 Several current deployments of inter-AS VPLS are implemented using 100 Inter-AS Option A, where VLANs are used to hand-off the services 101 between the two domains. In these deployments, link/node redundancy 102 is achieved using MC-LAG (Multi-Chassis Link Aggregation) and 103 [I-D.ietf-pwe3-iccp]. This, however, places two restrictions on the 104 interconnect: the two domains must be interconnected using Ethernet 105 links, and the links must be homogeneous, i.e. of the same speed, in 106 order to be aggregate-able. These two conditions cannot always be 107 guaranteed in live deployments. For instance, there are many 108 scenarios where the interconnect between the domains uses POS (Packet 109 over Sonet/SDH), thereby ruling out the applicability of MC-LAG as a 110 redundancy mechanism. As such, from a technical point of view, it is 111 desirable to use PWs to interconnect the VPLS domains, and to offer 112 resiliency using PW redundancy mechanisms. 114 MP-BGP can be used for VPLS inter-domain protection, as described in 115 [RFC6074], using either Option B or Option C inter-AS models. 116 However, with this solution, the protection time relies on BGP 117 control plane convergence. In certain deployments, with tight SLA 118 requirements on availability, this mechanism may not provide the 119 desired failover time characteristics. Furthermore, in certain 120 situations MP-BGP is not deployed for VPLS. The redundancy solution 121 described in this draft reuses ICCP [I-D.ietf-pwe3-iccp] and PW 122 redundancy [I-D.ietf-pwe3-redundancy] to provide fast convergence. 124 Furthermore, in the case where Label Switched Multicast is not used 125 for VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], the solution 126 described here provides a better behavior compared to inter-AS option 127 B: with option B, each PE must perform ingress replication to all 128 other PEs in its local as well as the remote domain. Whereas, with 129 the ICCP solution, the PE only replicates to local PEs and to the 130 ASBR. The ASBR then sends traffic P2P to the remote ASBR, and the 131 remote ASBR replicates to its local PEs. As a result, the load of 132 replication is distributed and is more efficient than option B. 134 The two PW redundancy modes defined in 135 [I-D.ietf-pwe3-redundancy-bit], namely independent mode and master/ 136 slave mode, are applicable in this solution. In order to maintain 137 control plane separation between the two domains, the independent 138 mode is preferred by operators. While the master/slave mode provides 139 some enhanced capabilities and, hence, is included in this draft. 141 4. Network Use Case 143 There are two network use cases for VPLS inter-domain redundancy: 144 two-PWs redundancy case, and four-PWs redundancy case. 146 Figure 1 presents an example use case with two inter-domain PWs. 147 PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs 148 within its own AS. A deployment example of this use case is where 149 there are only two physical links between the two domains and PE3 is 150 physically connected with PE5, and PE4 is physically connected with 151 PE6. 153 +---------+ +---------+ 154 +---+ | +-----+ | active PW1 | +-----+| +---+ 155 |PE1|---|-| PE3 |-|-----------------------|--| PE5 ||----|PE7| 156 +---+\ |/+-----+ | | +-----+\ /+---+ 157 | \ / | * | | * | |\ / | 158 | \| | |ICCP| |ICCP| | | \ | 159 | / \ | * | | * | |/ \ | 160 +---+/ |\+-----+ | | +-----+/ \+---+ 161 |PE2|---|-| PE4 |-|-----------------------|--| PE6 ||----|PE8| 162 +---+ | +-----+ | standby PW2 | +-----+| +---+ 163 | | | | 164 | | | | 165 | RG1 | | RG2 | 166 +---------+ +---------+ 167 operator A network operator B network 169 Figure 1 171 Figure 2 presents a four-PWs inter-domain VPLS redundancy use-case. 172 PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs 173 within its own AS. A deployment example of this use case is where 174 there are four physical links between the two domains and the four 175 PEs are physically connected with each other with four links. 177 +---------+ +---------+ 178 +---+ | +-----+ | | +-----+| +---+ 179 |PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7| 180 +---+\ |/+-----+ |-PW3-\ /-------| +-----+\ /+---+ 181 | \ / | * | \ / | * | |\ / | 182 | \| | |ICCP| X |ICCP| | | \ | 183 | / \ | * | / \ | * | |/ \ | 184 +---+/ |\+-----+ |-PW4-/ \-------| +-----+/ \+---+ 185 |PE2|---|-| PE4 |-|----PW2----------|--| PE6 ||----|PE8| 186 +---+ | +-----+ | | +-----+| +---+ 187 | | | | 188 | | | | 189 | RG1 | | RG2 | 190 +---------+ +---------+ 191 operator A network operator B network 193 Figure 2 195 5. PW redundancy application procedure for inter-domain 197 PW redundancy application procedures are described in section 9.1 of 198 [I-D.ietf-pwe3-iccp]. When a PE node encounters a failure, the other 199 PE takes over. This document reuses the PW redundancy mechanism 200 defined in [I-D.ietf-pwe3-iccp], with new ICCP switchover conditions 201 as specified in the following section. 203 There are two PW redundancy modes defined in 204 [I-D.ietf-pwe3-redundancy-bit]: Independent mode and Master/Slave 205 mode. For the inter-domain four-PW scenario, it is required for the 206 PEs to ensure that the same mode is supported on the two ICCP peers 207 in the same RG. 209 5.1. ICCP switchover condition 211 5.1.1. Inter-domain PW failure 213 When a PE receives advertisements from the active PE, in the same RG, 214 indicating that all the inter-domain PW status has changed to DOWN/ 215 STANDBY, then if it has the highest priority (after the advertising 216 PE), it SHOULD advertise active state for all of its associated 217 inter-domain PWs. 219 5.1.2. PE node isolation 221 When a PE detects failure of all PWs to the local domain, it SHOULD 222 advertise standby state for all its inter-domain PWs to trigger 223 remote PEs to switchover. 225 5.1.3. PE node failure 227 When a PE node detects that the active PE, that is member of the same 228 RG, has gone down, if the local PE has redundant PWs for the affected 229 services and has the highest priority (after the failed PE), it 230 advertises the active state for all associated inter-domain PWs. 232 5.2. Inter-domain redundancy with two-PWs 234 In this use case, it is recommended that the operation be as follows: 235 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 236 both domain; 237 o PW redundancy mode: independent mode only; 238 o Protection architectures: 1:1 (1 standby, 1 active). 240 The switchover rules described in section 5.2 apply. Before 241 deploying this inter-domain VPLS, the operators MUST negotiate to 242 configure same PW high/low priority at the two PW end-points. E.g, 243 in figure 1, PE3 and PE5 MUST both have higher/lower priority than 244 PE4 and PE6, otherwise both PW1 and PW2 will be in standby state. 246 5.3. Inter-domain redundancy with four-PWs 248 In this use case, there are generally three options to provide 1:1 249 protection or 3:1 protection. The inter-domain PWs that connect to 250 the same PE should have proper PW priority to advertise same active/ 251 standby state. E.g, in figure 2, both PW1 and PW3 connected to PE3 252 would advertise active/standby state. 254 For 1:1 protection model, the operation would be as follows: 256 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 257 both domains; 258 o PW redundancy mode: independent mode only; 259 o Protection architectures: 1:1(1 standby, 1 active). 261 The switchover rules described in section 5.2 apply. In this case, 262 the operator does not need to do any coordination of the inter-domain 263 PW priority. The PE detecting one PW DOWN should set the other PW to 264 STANDBY if available, and then synchronize the updated state to its 265 ICCP peer. When a PE detects that the PWs from ICCP peer PE are DOWN 266 or STANDBY, it should switchover as described in section 5.2.1. 268 There are two variants of the 3:1 protection model. We will refer to 269 them as option A and B. For option A of the 3:1 protection model, the 270 support of 'request switchover' bit is required. The operation is as 271 follows: 272 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 273 both domain; 274 o PW redundancy mode: Independent mode with 'request switchover' bit 275 support; 276 o Protection architectures: 3:1 (3 standby, 1 active). 278 In this case, the procedure on the PE for the PW failure is per 279 section 6.3 of [I-D.ietf-pwe3-redundancy-bit], and with the following 280 additions: 281 o When the PE detects failure of the active inter-domain PW, it 282 should switch to the other local standby inter-domain PW if 283 available, and send an updated LDP pseudowire status message with 284 the 'request switchover' bit set on that local standby inter- 285 domain PW to remote the PE; 286 o Local and remote PE should also update the new PW status to their 287 ICCP peers, respectively, in Application Data Messages with PW-RED 288 Synchronization Request TLV for corresponding service, so as to 289 synchronize the latest PW status on both PE sides. 290 o While waiting for the acknowledgment, the PE that sent the 291 'request switchover' bit may receive a switchover request from its 292 ICCP peer's PW remote endpoint by virtue of the ICCP 293 synchronization. The PE MUST compare IP addresses with that PW 294 remote peer. The PE with a higher IP address will ignore the 295 request and continue to wait for the acknowledgement from its peer 296 in the remote domain. The PE with the lower IP address MUST clear 297 'request switchover' bit and set 'Preferential Forwarding' local 298 status bit, and update the PW status to ICCP peer. 299 o The remote PE receiving 'request switchover' bit will acknowledge 300 the request and activate the PW only when it is ready to take over 301 as described in section 5.2, otherwise, it MUST ignore the 302 request. 304 The node isolation failure and node failure is described in section 305 5.2. 307 For option B of 3:1 protection model, master/slave mode support is 308 required, and should be as follows: 309 o ICCP deployment option: ICCP is deployed on VPLS edge nodes in 310 only one domain; 311 o PW redundancy mode: master/slave only; 312 o Protection architectures: 3:1 (3 standby, 1 active). 314 When master/slave PW redundancy mode is employed, the network 315 operators of the two domains must agree on which domain PEs will be 316 master, and configure the devices accordingly. The inter-domain PWs 317 that connect to one PE should have higher PW priority than the PWs on 318 the other PE in the same RG. The procedure on the PE for PW failure 319 is as follows: 320 o The PE with higher PW priority should only enable one PW active, 321 and the other PWs standby. 322 o When the PE detects active PW DOWN, it should enable the other 323 local standby PW to be active with preference. Only when the two 324 inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in 325 the same RG would switchover as described in section 5.2.. 327 The node isolation failure and node failure is described in section 328 5.2. 330 6. Security Considerations 332 This draft will have the same security properties of 333 [I-D.ietf-pwe3-iccp] and [RFC4762]. 335 7. IANA Consideration 337 No IANA allocation is required in this draft. 339 8. Acknowledgements 341 The authors wish to acknowledge the contributions of Daniel Cohn and 342 Yubao Wang. 344 Daniel Cohn 345 Orckit-Corrigent 346 Email: danielc@orckit.com 348 Yubao Wang 349 ZTE Corporation 350 Email: wang.yubao@zte.com.cn 352 9. References 354 9.1. Normative references 356 [I-D.ietf-pwe3-iccp] 357 Martini, L., Salam, S., Sajassi, A., Bocci, M., 358 Matsushima, S., and T. Nadeau, "Inter-Chassis 359 Communication Protocol for L2VPN PE Redundancy", 360 draft-ietf-pwe3-iccp-05 (work in progress), April 2011. 362 [I-D.ietf-pwe3-redundancy-bit] 363 Muley, P. and M. Aissaoui, "Pseudowire Preferential 364 Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-07 365 (work in progress), May 2012. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 9.2. Informative References 372 [I-D.ietf-l2vpn-vpls-mcast] 373 Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang, 374 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-10 (work 375 in progress), February 2012. 377 [I-D.ietf-pwe3-redundancy] 378 Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 379 Redundancy", draft-ietf-pwe3-redundancy-09 (work in 380 progress), June 2012. 382 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 383 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 384 RFC 4762, January 2007. 386 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 387 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 389 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and Luo, W., 390 "Provisioning, Auto-Discovery, and Signaling in Layer 2 391 Virtual Private Networks (L2VPNs)", RFC 6074, January 392 2011. 394 Authors' Addresses 396 Zhihua Liu 397 China Telecom 398 109 Zhongshan Ave. 399 Guangzhou 510630 400 P.R.China 402 Email: zhliu@gsta.com 404 Lizhong Jin 405 ZTE Corporation 406 889 Bibo Road 407 Shanghai 201203 408 P.R.China 410 Email: lizhong.jin@zte.com.cn 412 Ran Chen 413 ZTE Corporation 414 68 Zijinghua Road 415 Nanjing 210012 416 P.R.China 418 Email: chen.ran@zte.com.cn 420 Dennis Cai 421 Cisco 422 3750 Cisco Way, 423 San Jose, California 95134 424 USA 426 Email: dcai@cisco.com 428 Samer Salam 429 Cisco 430 595 Burrard Street, Suite 2123 431 Vancouver, BC V7X 1J1 432 Canada 434 Email: ssalam@cisco.com