< draft-ietf-l2vpn-vpls-inter-domain-redundancy-06.txt		draft-ietf-l2vpn-vpls-inter-domain-redundancy-07.txt >
	Networking Working Group Z. Liu		Networking Working Group Z. Liu
	Internet-Draft China Telecom		Internet-Draft China Telecom
	Intended status: Standards Track L. Jin		Intended status: Standards Track L. Jin
	Expires: October 26, 2014		Expires: November 17, 2014
	R. Chen		R. Chen
	ZTE Corporation		ZTE Corporation
	D. Cai		D. Cai
	S. Salam		S. Salam
	Cisco		Cisco
	April 24, 2014		May 16, 2014
	Redundancy Mechanism for Inter-domain VPLS Service		Redundancy Mechanism for Inter-domain VPLS Service
	draft-ietf-l2vpn-vpls-inter-domain-redundancy-06		draft-ietf-l2vpn-vpls-inter-domain-redundancy-07
	Abstract		Abstract
	In many existing Virtual Private LAN Service (VPLS) inter-domain		In many existing Virtual Private LAN Service (VPLS) inter-domain
	deployments (based on RFC 4762), pseudowire (PW) connectivity offers		deployments (based on RFC 4762), pseudowire (PW) connectivity offers
	no node redundancy, or offers node redundancy only with a single		no Provider Edge (PE) node redundancy, or offers PE node redundancy
	domain. This deployment approach incurs a high risk of service		only with a single domain. This deployment approach incurs a high
	interruption, since at least one domain will not offer PW node		risk of service interruption, since at least one domain will not
	redundancy. This document describes an inter-domain VPLS solution		offer PE node redundancy. This document describes an inter-domain
	that provides PW node redundancy across domains.		VPLS solution that provides PE node redundancy across domains.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 26, 2014.		This Internet-Draft will expire on November 17, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . . 4		4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . . 4
	5. PW redundancy application procedure for inter-domain		5. PW redundancy application procedure for inter-domain
	redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 6		redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. ICCP switchover condition . . . . . . . . . . . . . . . . 6		5.1. ICCP switchover condition . . . . . . . . . . . . . . . . 6
	5.1.1. Inter-domain PW failure . . . . . . . . . . . . . . . 6		5.1.1. Inter-domain PW failure . . . . . . . . . . . . . . . 6
	5.1.2. PE node isolation . . . . . . . . . . . . . . . . . . 6		5.1.2. PE node isolation . . . . . . . . . . . . . . . . . . 6
	5.1.3. PE node failure . . . . . . . . . . . . . . . . . . . 6		5.1.3. PE node failure . . . . . . . . . . . . . . . . . . . 6
	5.2. Inter-domain redundancy with two-PWs . . . . . . . . . . . 6		5.2. Inter-domain redundancy with two-PWs . . . . . . . . . . . 7
	5.3. Inter-domain redundancy with four-PWs . . . . . . . . . . 7		5.3. Inter-domain redundancy with four-PWs . . . . . . . . . . 7
	6. Management Considerations . . . . . . . . . . . . . . . . . . 9		6. Management Considerations . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative references . . . . . . . . . . . . . . . . . . . 10		11.1. Normative references . . . . . . . . . . . . . . . . . . . 10
	11.2. Informative references . . . . . . . . . . . . . . . . . . 10		11.2. Informative references . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	In many existing Virtual Private LAN Service (VPLS) deployments based		In many existing Virtual Private LAN Service (VPLS) deployments based
	on [RFC4762], pseudowire (PW) connectivity offers no node redundancy,		on [RFC4762], pseudowire (PW) connectivity offers no Provider Edge
	or offers node redundancy only with a single domain. This deployment		(PE) node redundancy, or offers PE node redundancy only with a single
	approach incurs a high risk of service interruption, since at least		domain. This deployment approach incurs a high risk of service
	one domain will not offer PW node redundancy. This document		interruption, since at least one domain will not offer PE node
	describes an inter-domain VPLS solution that provides PW node		redundancy. This document describes an inter-domain VPLS solution
	redundancy across domains. The redundancy mechanism will provide		that provides PE node redundancy across domains. The redundancy
	node redundancy and link redundancy in both domains. The domain in		mechanism will provide PE node redundancy and link redundancy in both
			domains. The PE throughout the document refers to a routing and
			bridging capable PE defined in [RFC4762] section 10. The domain in
	this document refers to autonomous system (AS), or other		this document refers to autonomous system (AS), or other
	administrative domains.		administrative domains.
	The solution relies on the use of Inter-Chassis Communication		The solution relies on the use of Inter-Chassis Communication
	Protocol (ICCP) [I-D.ietf-pwe3-iccp] to coordinate between the two		Protocol (ICCP) [I-D.ietf-pwe3-iccp] to coordinate between the two
	redundant edge nodes, and use of PW Preferential Forwarding Status		redundant edge nodes, and use of PW Preferential Forwarding Status
	Bit [RFC6870] to negotiate the PW status. There is no change to any		Bit [RFC6870] to negotiate the PW status. There is no change to any
	protocol message formats and no new protocol options are introduced.		protocol message formats and no new protocol options are introduced.
	This solution is a description of reusing existing protocol building		This solution is a description of reusing existing protocol building
	blocks to achieve the desired function, but also defines		blocks to achieve the desired function, but also defines
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 40 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Motivation		3. Motivation
	Inter-AS VPLS offerings are widely deployed in service provider		Inter-AS VPLS offerings are widely deployed in service provider
	networks today. Typically, the Autonomous System Border Router		networks today. Typically, the Autonomous System Border Router
	(ASBR) and associated physical links that connect the domains carry a		(ASBR) and associated physical links that connect the domains carry a
	multitude of services. As such, it is important to provide link and		multitude of services. As such, it is important to provide PE node
	node redundancy, to ensure service high availability and meet the end		and link redundancy, to ensure service high availability and meet the
	customer service level agreements (SLAs).		end customer service level agreements (SLAs).
	Several current deployments of inter-AS VPLS are implemented like		Several current deployments of inter-AS VPLS are implemented like
	inter-AS option A in [RFC4364] section 10, where Virtual Local Area		inter-AS option A in [RFC4364] section 10, where Virtual Local Area
	Network (VLAN) is used to hand-off the services between two domains.		Network (VLAN) is used to hand-off the services between two domains.
	In these deployments, link/node redundancy is achieved using Multi-		In these deployments, PE node/link redundancy is achieved using
	Chassis Link Aggregation (MC-LAG) and ICCP [I-D.ietf-pwe3-iccp].		Multi-Chassis Link Aggregation (MC-LAG) and ICCP
	This, however, places two restrictions on the interconnection: the		[I-D.ietf-pwe3-iccp]. This, however, places two restrictions on the
	two domains must be interconnected using Ethernet links, and the		interconnection: the two domains must be interconnected using
	links must be homogeneous, i.e. of the same speed, in order to be		Ethernet links, and the links must be homogeneous, i.e. of the same
	aggregated. These two conditions can not always be guaranteed in		speed, in order to be aggregated. These two conditions can not
	live deployments. For instance, there are many scenarios where the		always be guaranteed in live deployments. For instance, there are
	interconnection between the domains uses Packet over Synchronous		many scenarios where the interconnection between the domains uses
	Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH),		Packet over Synchronous Optical Networking (SONET) / Synchronous
	thereby ruling out the applicability of MC-LAG as a redundancy		Digital Hierarchy (SDH), thereby ruling out the applicability of MC-
	mechanism. As such, from a technical point of view, it is desirable		LAG as a redundancy mechanism. As such, from a technical point of
	to use PWs to interconnect the VPLS domains, and to offer resiliency		view, it is desirable to use PWs to interconnect the VPLS domains,
	using PW redundancy mechanisms.		and to offer resiliency using PW redundancy mechanisms.
	Multiprotocol Border Gateway Protocol (MP-BGP) can be used for VPLS		Multiprotocol Border Gateway Protocol (MP-BGP) can be used for VPLS
	inter-domain protection, as described in [RFC6074], using either		inter-domain protection, as described in [RFC6074], using either
	option B or option C inter-AS models. However, with this solution,		option B or option C inter-AS models. However, with this solution,
	the protection time relies on BGP control plane convergence. In		the protection time relies on BGP control plane convergence. In
	certain deployments, with tight SLA requirements on availability,		certain deployments, with tight SLA requirements on availability,
	this mechanism may not provide the desired failover time		this mechanism may not provide the desired failover time
	characteristics. Furthermore, in certain situations MP-BGP is not		characteristics. Furthermore, in certain situations MP-BGP is not
	deployed for VPLS. The redundancy solution described in this		deployed for VPLS. The redundancy solution described in this
	document reuses ICCP [I-D.ietf-pwe3-iccp] and PW redundancy [RFC6718]		document reuses ICCP [I-D.ietf-pwe3-iccp] and PW redundancy [RFC6718]
	to provide fast convergence.		to provide fast convergence.
	Furthermore, in the case where Label Switched Multicast is not used		Furthermore, in the case where Label Switched Multicast is not used
	for VPLS multicast [RFC7117], the solution described here provides a		for VPLS multicast [RFC7117], the solution described here provides a
	better behavior compared to inter-AS option B: with option B, each		better behavior compared to inter-AS option B: with option B, each PE
	Provider Edge (PE) must perform ingress replication to all other PEs		must perform ingress replication to all other PEs in its local as
	in its local as well as the remote domain. Whereas, with the ICCP		well as the remote domain. Whereas, with the ICCP solution, the PE
	solution, the PE only replicates to local PEs and to the ASBR. The		only replicates to local PEs and to the ASBR. The ASBR then sends
	ASBR then sends traffic point-to-point to the remote ASBR, and the		traffic point-to-point to the remote ASBR, and the remote ASBR
	remote ASBR replicates to its local PEs. As a result, the load of		replicates to its local PEs. As a result, the load of replication is
	replication is distributed and is more efficient than option B.		distributed and is more efficient than option B.
	Two PW redundancy modes defined in [RFC6718], namely independent mode		Two PW redundancy modes defined in [RFC6718], namely independent mode
	and master/slave mode, are applicable in this solution. In order to		and master/slave mode, are applicable in this solution. In order to
	maintain control plane separation between two domains, the		maintain control plane separation between two domains, the
	independent mode is preferred by operators. The master/slave mode		independent mode is preferred by operators. The master/slave mode
	provides some enhanced capabilities and, hence, is included in this		provides some enhanced capabilities and, hence, is included in this
	document.		document.
	4. Network Use Case		4. Network Use Case
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 36 ¶
	remote peer. The PE with a higher IP address SHOULD ignore the		remote peer. The PE with a higher IP address SHOULD ignore the
	request and continue to wait for the acknowledgement from its peer		request and continue to wait for the acknowledgement from its peer
	in the remote domain. The PE with the lower IP address SHOULD		in the remote domain. The PE with the lower IP address SHOULD
	clear 'request switchover' bit and set 'Preferential Forwarding'		clear 'request switchover' bit and set 'Preferential Forwarding'
	local status bit, and update the PW status to ICCP peer.		local status bit, and update the PW status to ICCP peer.
	o The remote PE receiving 'request switchover' bit SHOULD		o The remote PE receiving 'request switchover' bit SHOULD
	acknowledge the request and activate the PW only when it is ready		acknowledge the request and activate the PW only when it is ready
	to take over as described in section 5.1, otherwise, it SHOULD		to take over as described in section 5.1, otherwise, it SHOULD
	ignore the request.		ignore the request.
	The node isolation failure and node failure is described in section		The PE node isolation failure and PE node failure is described in
	5.1.		section 5.1.
	For option B of 3:1 protection model, master/slave mode support is		For option B of 3:1 protection model, master/slave mode support is
	required, and should be as follows:		required, and should be as follows:
	o ICCP deployment option: ICCP is deployed on VPLS edge nodes in		o ICCP deployment option: ICCP is deployed on VPLS edge nodes in
	only one domain;		only one domain;
	o PW redundancy mode: master/slave only;		o PW redundancy mode: master/slave only;
	o Protection architectures: 3:1 (3 standby, 1 active).		o Protection architectures: 3:1 (3 standby, 1 active).
	When master/slave PW redundancy mode is employed, the network		When master/slave PW redundancy mode is employed, the network
	operators of two domains must agree on which domain PEs will be		operators of two domains must agree on which domain PEs will be
	skipping to change at page 8, line 48 ¶		skipping to change at page 9, line 4 ¶
	only one domain;		only one domain;
	o PW redundancy mode: master/slave only;		o PW redundancy mode: master/slave only;
	o Protection architectures: 3:1 (3 standby, 1 active).		o Protection architectures: 3:1 (3 standby, 1 active).
	When master/slave PW redundancy mode is employed, the network		When master/slave PW redundancy mode is employed, the network
	operators of two domains must agree on which domain PEs will be		operators of two domains must agree on which domain PEs will be
	master, and configure the devices accordingly. The inter-domain PWs		master, and configure the devices accordingly. The inter-domain PWs
	that connect to one PE should have higher PW priority than the PWs on		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		the other PE in the same RG. The procedure on the PE for PW failure
	is as follows:		is as follows:
	o The PE with higher PW priority should only enable one PW active,		o The PE with higher PW priority should only enable one PW active,
	and the other PWs standby.		and the other PWs standby.
	o When the PE detects active PW DOWN, it SHOULD enable the other		o When the PE detects active PW DOWN, it SHOULD enable the other
	local standby PW to be active with preference. Only when two		local standby PW to be active with preference. Only when two
	inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in		inter-domain PWs connect to the PE are DOWN, the ICCP peer PE in
	the same RG SHOULD switchover as described in section 5.1.		the same RG SHOULD switchover as described in section 5.1.
	The node isolation failure and node failure is described in section		The PE node isolation failure and PE node failure is described in
	5.1.		section 5.1.
	6. Management Considerations		6. Management Considerations
	When deploying the inter-domain redundancy mechanism described in		When deploying the inter-domain redundancy mechanism described in
	this document, consistent provisioning is required for proper		this document, consistent provisioning is required for proper
	operation. The two domains must both use the same use case (section		operation. The two domains must both use the same use case (section
	5.2 or section 5.3). Within each section, all of the described modes		5.2 or section 5.3). Within each section, all of the described modes
	and options must be provisioned identically both within each RG and		and options must be provisioned identically both within each RG and
	between the RGs. Additionally, for the two-PWs redundancy options		between the RGs. Additionally, for the two-PWs redundancy options
	defined in section 5.2, the two operators must also negotiate to		defined in section 5.2, the two operators must also negotiate to
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 36 ¶
	mechanism may not work properly.		mechanism may not work properly.
	7. Security Considerations		7. Security Considerations
	Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP		Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP
	control plane, [RFC4762] and [RFC6870] for PW control plane, this		control plane, [RFC4762] and [RFC6870] for PW control plane, this
	document has additional security consideration for ICCP control		document has additional security consideration for ICCP control
	plane.		plane.
	In this document, ICCP protocol is deployed between two PEs or ASBRs.		In this document, ICCP protocol is deployed between two PEs or ASBRs.
	The two PEs or ASBRs should only be connected by a well managed and		The two PEs or ASBRs should only be connected by a network that is
	highly monitored network. This should be ensured by the operator.		well managed and whose service levels and availability are highly
			monitored. This should be ensured by the operator.
	The state flapping on the inter-domain and intra-domain PW may cause		The state flapping on the inter-domain and intra-domain PW may cause
	security threats or be exploited to create denial of service attacks.		security threats or be exploited to create denial of service attacks.
	For example, excessive PW state flapping (e.g., by malicious peer		For example, excessive PW state flapping (e.g., by malicious peer
	PE's implementation) may lead to excessive ICCP exchanges.		PE's implementation) may lead to excessive ICCP exchanges.
	Implementations SHOULD provide mechanisms to perform control-plane		Implementations SHOULD provide mechanisms to perform control-plane
	policing and mitigate such types of attacks.		policing and mitigate such types of attacks.
	8. IANA Consideration		8. IANA Consideration
	No IANA allocation is required in this document.		No IANA allocation is required in this document.
	9. Acknowledgements		9. Acknowledgements
	The author would like to thank Sami Boutros, Giles Heron, Adrian		The authors would like to thank Sami Boutros, Giles Heron, Adrian
	Farrel, Andrew G. Malis and Stephen Kent for their valuable comments.		Farrel, Andrew G. Malis and Stephen Kent for their valuable comments.
	10. Contributors		10. Contributors
	Daniel Cohn		Daniel Cohn
	Email:daniel.cohn.ietf@gmail.com		Email:daniel.cohn.ietf@gmail.com
	Yubao Wang		Yubao Wang
	ZTE Corporation		ZTE Corporation
End of changes. 16 change blocks.
	48 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/