Networking Working Group Z. Liu Internet-Draft China Telecom Intended status: Standards Track L. Jin Expires: December 15, 2012 R. Chen ZTE D. Cai S. Salam Cisco June 13, 2012 Redundancy provisioning for VPLS Inter-domain draft-liu-l2vpn-vpls-inter-domain-redundancy-03 Abstract In many VPLS deployments based on [RFC4762], inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on [RFC4762] with node and link redundancy in both domains. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 15, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Liu, et al. Expires December 15, 2012 [Page 1] Internet-Draft Redundancy for VPLS Inter-domain June 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 5. PW redundancy application procedure for inter-domain redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. PW redundancy mode negotiation . . . . . . . . . . . . . . 5 5.2. ICCP switchover condition . . . . . . . . . . . . . . . . 6 5.2.1. PW failure . . . . . . . . . . . . . . . . . . . . . . 6 5.2.2. PE node isolation . . . . . . . . . . . . . . . . . . 6 5.2.3. PE node failure . . . . . . . . . . . . . . . . . . . 6 5.3. Inter-domain redundancy with two Inter-domain PWs . . . . 6 5.4. Inter-domain redundancy with Inter-domain four-PWs . . . . 7 5.5. MAC Withdraw procedure in VPLS Inter-domain . . . . . . . 8 5.5.1. MAC Withdraw Capability TLV format . . . . . . . . . . 9 5.5.2. Optimized MAC Withdraw processing . . . . . . . . . . 10 6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative references . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Liu, et al. Expires December 15, 2012 [Page 2] Internet-Draft Redundancy for VPLS Inter-domain June 2012 1. Introduction In many VPLS deployment based on [RFC 4762], inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on [RFC 4762] with node and link redundancy in both domain. The domain in this document refers to AS, or other administrative domains. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. Motivation Inter-AS VPLS offerings are widely deployed in service provider networks today. Typically, the ASBRs and associated physical links that connect the domains carry a multitude of services. As such, it is important to provide link and node redundancy, to ensure service high availability and meet end customer service level agreements (SLAs). Several current deployments of inter-AS VPLS are implemented using Inter-AS Option A, where VLANs are used to hand-off the services between the two domains. In these deployments, link/node redundancy is achieved using MC-LAG (Multi-Chassis Link Aggregation) and [I-D.ietf-pwe3-iccp]. This, however, places two restrictions on the interconnect: the two domains must be interconnected using Ethernet links, and the links must be homogeneous, i.e. of the same speed, in order to be aggregate-able. These two conditions cannot always be guaranteed in live deployments. For instance, there are many scenarios where the interconnect between the domains uses POS (Packet over Sonet/SDH), thereby ruling out the applicability of MC-LAG as a redundancy mechanism. As such, from a technical point of view, it is desirable to use PWs to interconnect the VPLS domains, and to offer resiliency using PW redundancy mechanisms. MP-BGP can be used for VPLS inter-domain protection, as described in [RFC6074], using either Option B or Option C inter-AS models. However, with this solution, the protection time relies on BGP control plane convergence. In certain deployments, with tight SLA requirements on availability, this mechanism may not provide the desired failover time characteristics. Furthermore, in certain situations MP-BGP is not deployed for VPLS. The redundancy solution Liu, et al. Expires December 15, 2012 [Page 3] Internet-Draft Redundancy for VPLS Inter-domain June 2012 described in this draft reuses ICCP [I-D.ietf-pwe3-iccp] and PW redundancy [I-D.ietf-pwe3-redundancy] to provide fast convergence. Furthermore, in the case where Label Switched Multicast is not used for VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], the solution described here provides a better behavior compared to inter-AS option B: with option B, each PE must perform ingress replication to all other PEs in its local as well as the remote domain. Whereas, with the ICCP solution, the PE only replicates to local PEs and to the ASBR. The ASBR then sends traffic P2P to the remote ASBR, and the remote ASBR replicates to its local PEs. As a result, the load of replication is distributed and is more efficient than option B. The two PW redundancy modes defined in [I-D.ietf-pwe3-redundancy-bit], namely independent mode and master/ slave mode, are applicable in this solution. In order to maintain control plane separation between the two domains, the independent mode is preferred by operators. While the master/slave mode provides some enhanced capabilities and, hence, is included in this draft. 4. Network Use Case There are two network use cases for VPLS inter-domain redundancy: two-PWs redundancy case, and four-PWs redundancy case. Figure 1 presents an example use case with two inter-domain PWs, where there are only two physical links between the two domains. PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs within its own AS, and PE3 is physically connected with PE5, and PE4 is physically connected with PE6. +---------+ +---------+ +---+ | +-----+ | active PW1 | +-----+| +---+ |PE1|---|-| PE3 |-|-----------------------|--| PE5 ||----|PE7| +---+\ |/+-----+ | | +-----+\ /+---+ | \ / | * | | * | |\ / | | \| | |ICCP| |ICCP| | | \ | | / \ | * | | * | |/ \ | +---+/ |\+-----+ | | +-----+/ \+---+ |PE2|---|-| PE4 |-|-----------------------|--| PE6 ||----|PE8| +---+ | +-----+ | standby PW2 | +-----+| +---+ | | | | | | | | | RG1 | | RG2 | +---------+ +---------+ operator A network operator B network Liu, et al. Expires December 15, 2012 [Page 4] Internet-Draft Redundancy for VPLS Inter-domain June 2012 Figure 1 Figure 2 presents a four-PWs inter-domain VPLS redundancy use-case, where there are four physical links between the two domains. PE3/ PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs within its own AS, and the four PEs are physically connected with each other with four links. +---------+ +---------+ +---+ | +-----+ | | +-----+| +---+ |PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7| +---+\ |/+-----+ |-PW3-\ /-------| +-----+\ /+---+ | \ / | * | \ / | * | |\ / | | \| | |ICCP| X |ICCP| | | \ | | / \ | * | / \ | * | |/ \ | +---+/ |\+-----+ |-PW4-/ \-------| +-----+/ \+---+ |PE2|---|-| PE4 |-|----PW2----------|--| PE6 ||----|PE8| +---+ | +-----+ | | +-----+| +---+ | | | | | | | | | RG1 | | RG2 | +---------+ +---------+ operator A network operator B network Figure 2 5. PW redundancy application procedure for inter-domain redundancy PW redundancy application procedures are described in section 9.1 of [I-D.ietf-pwe3-iccp]. When a PE node encounters a failure, the other PE takes over. This draft reuses the PW redundancy mechanism defined in [I-D.ietf-pwe3-iccp], with new ICCP switchover conditions as specified in the following section, and also the corresponding MAC withdrawal mechanism. 5.1. PW redundancy mode negotiation There are two PW redundancy modes defined in [I-D.ietf-pwe3-redundancy-bit]: Independent mode and Master/Slave mode. For the inter-domain four-PW scenario, it is required for the PEs to advertise their redundancy mode configuration in order to ensure that the same mode is supported on the two ICCP peers in the same RG. [I-D.ietf-pwe3-iccp] section 7.1.3 defines PW-RED Config TLV. This Liu, et al. Expires December 15, 2012 [Page 5] Internet-Draft Redundancy for VPLS Inter-domain June 2012 draft proposes that the Flags field of the Config TLV be extended with two new values to indicated the PW redundancy mode configured on the PE for the associated PW: o "0x04" to indicate independent PW redundancy mode configured. o "0x08" to indicate Master/Slave PW redundancy mode configured. If the advertised values do not match among the PEs in the RG for a given ROID, then the implementation MUST alert the operator of mis- configuration. 5.2. ICCP switchover condition 5.2.1. PW failure When a PE receives advertisements from the active PE, in the same RG, indicating that all the PW status has changed to DOWN/STANDBY, then if it has the highest priority (after the advertising PE), it SHOULD advertise active state for all of its associated inter-domain PWs. 5.2.2. PE node isolation When a PE detects failure of all PWs to the local domain, it SHOULD advertise standby state for all its inter-domain PWs, and send ICCP Application Data message to trigger remote PEs to switchover. 5.2.3. PE node failure When a PE node detects that the active PE, that is member of the same RG, has gone down, if the local PE has redundant PWs for the affected services and has the highest priority (after the failed PE), it advertises the active state for all associated inter-domain PWs. 5.3. Inter-domain redundancy with two Inter-domain PWs In this use case, it is recommended that the operation be as follows: o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domain; o PW redundancy mode: independent mode only; o Protection architectures: 1:1 (1 standby, 1 active). The switchover rules described in section 5.2 apply. Before deploying this inter-domain VPLS, the operators MUST negotiate to configure same PW high/low priority at the two PW end-points. E.g, in figure 1, PE3 and PE5 MUST both have higher/lower priority than PE4 and PE6, otherwise both PW1 and PW2 will be in standby state. Liu, et al. Expires December 15, 2012 [Page 6] Internet-Draft Redundancy for VPLS Inter-domain June 2012 5.4. Inter-domain redundancy with Inter-domain four-PWs In this use case, there are generally three options to provide 1:1 protection or 3:1 protection. The inter-domain PWs that connect to the same PE should have proper PW priority to advertise same active/ standby state. E.g, in figure 2, both PW1 and PW3 connected to PE3 would advertise active/standby state. For 1:1 protection model, the operation would be as follows: o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domain; o PW redundancy mode: independent mode only; o Protection architectures: 1:1(1 standby, 1 active). The switchover rules described in section 5.2 apply. In this case, the operator does not need to do any coordination of the inter-domain PW priority. The PE detecting one PW DOWN should set the other PW to STANDBY if available, and then synchronize the updated state to its ICCP peer. When a PE detects that the PWs from ICCP peer PE are DOWN or STANDBY, it should switchover as described in section 5.2.1. There are two variants of the 3:1 protection model. We will refer to them as options A and B. For option A of the 3:1 protection model, the support for 'request switchover' bit is required. The operation is as follows: o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domain; o PW redundancy mode: Independent mode with 'request switchover' bit support; o Protection architectures: 3:1 (3 standby, 1 active). In this case, the procedure on the PE for the PW failure is per section 6.3 of draft-ietf-pwe3-redundancy-bit-07, and with the following additions: o When the PE detects failure of the active inter-domain PW, it should switch to the other local standby inter-domain PW if available, and send an updated LDP pseudowire status message with the 'request switchover' bit set on that local standby inter- domain PW to remote the PE; o Local and remote PE should also update the new PW status to their ICCP peers, respectively, in Application Data Messages with PW-RED Synchronization Request TLV for corresponding service, so as to synchronize the latest PW status on both PE sides. o While waiting for the acknowledgment, the PE that sent the 'request switchover' bit may receive a switchover request from its ICCP peer's PW remote endpoint by virtue of the ICCP synchronization. The PE MUST compare IP addresses with that PW remote peer. The PE with a higher IP address will ignore the Liu, et al. Expires December 15, 2012 [Page 7] Internet-Draft Redundancy for VPLS Inter-domain June 2012 request and continue to wait for the acknowledgement from its peer in the remote domain. The PE with the lower IP address MUST clear 'request switchover' bit and set 'Preferential Forwarding' local status bit, and update the PW status to ICCP peer. o The remote PE receiving !(R)request switchover!_ bit will acknowledge the request and activate the PW only when it is ready to take over as described in section 5.2, otherwise, it MUST ignore the request. The node isolation failure and node failure is described in section 5.2. For option B of 3:1 protection model, master/slave mode support is required, and should be as follows: o ICCP deployment option: ICCP is deployed on VPLS edge nodes in only one domain; o PW redundancy mode: master/slave only; o Protection architectures: 3:1 (3 standby, 1 active). When master/slave PW redundancy mode is employed, the network operators of the two domains must agree on which domain PEs will be master, and configure the devices accordingly. The inter-domain PWs that connect to one PE should have higher PW priority than the PWs on the other PE in the same RG. The procedure on the PE for PW failure is as follows: o The PE with higher PW priority should only enable one PW active, and the other PWs standby. o When the PE detects active PW DOWN, it should enable the other local standby PW to be active with preference. Only when the two inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in the same RG would switchover as described in section 5.2.. The node isolation failure and node failure is described in section 5.2. 5.5. MAC Withdraw procedure in VPLS Inter-domain It MAY be desirable to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. This is accomplished by sending an LDP Address Withdraw Message. PE SHOULD not advertise MAC Address Withdraw message from one domain to the other. Correspondingly, VPLS PE that connects another domain SHOULD also reject any MAC Address Withdraw message received from that domain. In figure 1, when the failure of the active PW is detected by PE3, it will trigger negative MAC Address Withdraw message [I-D.ietf-l2vpn-vpls-ldp-mac-opt]. By default, as per the processing rules defined in [RFC4762], upon PE4 activates the standby PW, it Liu, et al. Expires December 15, 2012 [Page 8] Internet-Draft Redundancy for VPLS Inter-domain June 2012 will also send a MAC Address Withdraw message. There would be two copies of MAC Address Withdraw messages received by each PE, which would make the network convergence worse. In order to determine which PE to send MAC Withdraw message, this draft introduce an MAC Withdraw Capability for LDP [RFC5561], a MAC Withdraw Capability TLV is used for negotiating the MAC withdraw capability. 5.5.1. MAC Withdraw Capability TLV format The MAC Withdraw Capability TLV is described as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| MAC withdraw Capability | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Reserved |P|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 U-bit: set to "1". F-bit: set to "0". Once advertised, this capability cannot be withdrawn and hence the S-bit must always be set to 1 both in Initialization message and Capability message. MAC withdraw capability TLV: It is requested to be assigned by the IANA. P-bit:set "1" to indicate whether the node supports the positive MAC withdraw capability. N-bit:set "1" to indicate whether the node supports the negative MAC withdraw capability. Reserved: Reserved for future use. MAC Withdraw Capability TLV is advertised to a LDP ICCP peer PE that Liu, et al. Expires December 15, 2012 [Page 9] Internet-Draft Redundancy for VPLS Inter-domain June 2012 in the same domain, and this TLV may be carried in an LDP Initialization message or LDP Capability message. 5.5.2. Optimized MAC Withdraw processing After receiving the MAC withdraw capability through MAC Withdraw capability TLV, the PE should process as below: o If the former active PE does not support negative MAC withdraw capability, and former standby PE support positive MAC withdraw capability, former standby PE will send positive to all other PEs with positive MAC capability. o If the former active PE support negative MAC withdraw capability, the former active PE sends negative to other PEs that have negative MAC withdraw capability. And if the former standby PE also support positive MAC withdraw capability, it will send positive to other PEs with positive and without negative MAC withdraw capability. 6. Load Balancing It is recommended to configure different PW priority values for different VPLS instance, then the active PW of different VPLS will be running on different PEs, to provide load balancing between the two PEs in one domain. 7. Security Considerations This draft will have the same security properties of [I-D.ietf-pwe3-iccp] and [RFC4762]. 8. IANA Consideration This document creates a new "MAC Withdraw Capability" that is requested to be allocated by IANA. 9. Acknowledgements The authors wish to acknowledge the contributions of Daniel Cohn and Yubao Wang. Daniel Cohn Orckit-Corrigent Email: danielc@orckit.com Liu, et al. Expires December 15, 2012 [Page 10] Internet-Draft Redundancy for VPLS Inter-domain June 2012 Yubao Wang ZTE Corporation Email: wang.yubao@zte.com.cn 10. References 10.1. Normative references [I-D.ietf-pwe3-iccp] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-05 (work in progress), April 2011. [I-D.ietf-pwe3-redundancy-bit] Muley, P. and M. Aissaoui, "Pseudowire Preferential Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-07 (work in progress), May 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-l2vpn-vpls-ldp-mac-opt] Dutta, P., Balus, F., Stokes, O., and G. Calvignac, "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-06 (work in progress), May 2012. [I-D.ietf-l2vpn-vpls-mcast] Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-10 (work in progress), February 2012. [I-D.ietf-pwe3-redundancy] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", draft-ietf-pwe3-redundancy-08 (work in progress), May 2012. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. Liu, et al. Expires December 15, 2012 [Page 11] Internet-Draft Redundancy for VPLS Inter-domain June 2012 Authors' Addresses Zhihua Liu China Telecom 109 Zhongshan Ave. Guangzhou 510630 P.R.China Email: zhliu@gsta.com Lizhong Jin ZTE Corporation 889 Bibo Road Shanghai 201203 P.R.China Email: lizhong.jin@zte.com.cn Ran Chen ZTE Corporation 68 Zijinghua Road Nanjing 210012 P.R.China Email: chen.ran@zte.com.cn Dennis Cai Cisco 3750 Cisco Way, San Jose, California 95134 USA Email: dcai@cisco.com Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada Email: ssalam@cisco.com Liu, et al. Expires December 15, 2012 [Page 12]