< draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.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 12, 2014		Expires: November 17, 2014
	R. Chen		R. Chen
	ZTE Corporation		ZTE Corporation
	D. Cai		D. Cai
	S. Salam		S. Salam
	Cisco		Cisco
	April 10, 2014		May 16, 2014
	Redundancy provisioning for VPLS Inter-domain		Redundancy Mechanism for Inter-domain VPLS Service
	draft-ietf-l2vpn-vpls-inter-domain-redundancy-05		draft-ietf-l2vpn-vpls-inter-domain-redundancy-07
	Abstract		Abstract
	In many existing Virtual Private LAN Service (VPLS) deployments based		In many existing Virtual Private LAN Service (VPLS) inter-domain
	on RFC 4762, inter-domain connectivity has been deployed without node		deployments (based on RFC 4762), pseudowire (PW) connectivity offers
	redundancy, or with node redundancy in a single domain. This		no Provider Edge (PE) node redundancy, or offers PE node redundancy
	document describes a solution for inter-domain VPLS based on RFC 4762		only with a single domain. This deployment approach incurs a high
	with node and link redundancy in both domains.		risk of service interruption, since at least one domain will not
			offer PE node redundancy. This document describes an inter-domain
			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 12, 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 23 ¶		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 . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . . . . 9		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], inter-domain connectivity has been deployed without		on [RFC4762], pseudowire (PW) connectivity offers no Provider Edge
	node redundancy, or with node redundancy in a single domain. This		(PE) node redundancy, or offers PE node redundancy only with a single
	document is to provide a service protection mechanism for inter-		domain. This deployment approach incurs a high risk of service
	domain VPLS based on [RFC4762]. The protection mechanism will		interruption, since at least one domain will not offer PE node
	provide edge node redundancy and link redundancy in both domains.		redundancy. This document describes an inter-domain VPLS solution
	The domain in this document refers to autonomous system (AS), or		that provides PE node redundancy across domains. The redundancy
	other administrative domains.		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
			administrative domains.
	The solution relies on the use of ICCP [I-D.ietf-pwe3-iccp] to		The solution relies on the use of Inter-Chassis Communication
	coordinate between redundant edge nodes, and use of Pseudowire (PW)		Protocol (ICCP) [I-D.ietf-pwe3-iccp] to coordinate between the two
	Preferential Forwarding Status Bit [RFC6870] to negotiate the PW		redundant edge nodes, and use of PW Preferential Forwarding Status
	status. There is no change to any protocol message formats and no		Bit [RFC6870] to negotiate the PW status. There is no change to any
	new protocol options introduced. This solution is a description of		protocol message formats and no new protocol options are introduced.
	reusing existing protocol building blocks to achieve the desired		This solution is a description of reusing existing protocol building
	function, but also defines implementation behaviour necessary for the		blocks to achieve the desired function, but also defines
	function to work.		implementation behavior necessary for the function to work.
	2. Conventions used in this document		2. Conventions used in this document
	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 ASBRs and associated physical links		networks today. Typically, the Autonomous System Border Router
	that connect the domains carry a multitude of services. As such, it		(ASBR) and associated physical links that connect the domains carry a
	is important to provide link and node redundancy, to ensure service		multitude of services. As such, it is important to provide PE node
	high availability and meet end customer service level		and link redundancy, to ensure service high availability and meet the
	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 VLANs are used to		inter-AS option A in [RFC4364] section 10, where Virtual Local Area
	hand-off the services between two domains. In these deployments,		Network (VLAN) is used to hand-off the services between two domains.
	link/node redundancy is achieved using MC-LAG (Multi-Chassis Link		In these deployments, PE node/link redundancy is achieved using
	Aggregation) and [I-D.ietf-pwe3-iccp]. This, however, places two		Multi-Chassis Link Aggregation (MC-LAG) and ICCP
	restrictions on the interconnection: the two domains must be		[I-D.ietf-pwe3-iccp]. This, however, places two restrictions on the
	interconnected using Ethernet links, and the links must be		interconnection: the two domains must be interconnected using
	homogeneous, i.e. of the same speed, in order to be aggregated.		Ethernet links, and the links must be homogeneous, i.e. of the same
	These two conditions cannot always be guaranteed in live deployments.		speed, in order to be aggregated. These two conditions can not
	For instance, there are many scenarios where the interconnect between		always be guaranteed in live deployments. For instance, there are
	the domains uses Packet over Sonet/SDH (POS), thereby ruling out the		many scenarios where the interconnection between the domains uses
	applicability of MC-LAG as a redundancy mechanism. As such, from a		Packet over Synchronous Optical Networking (SONET) / Synchronous
	technical point of view, it is desirable to use PWs to interconnect		Digital Hierarchy (SDH), thereby ruling out the applicability of MC-
	the VPLS domains, and to offer resiliency using PW redundancy		LAG as a redundancy mechanism. As such, from a technical point of
	mechanisms.		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		Multiprotocol Border Gateway Protocol (MP-BGP) can be used for VPLS
	[RFC6074], using either option B or option C inter-AS models.		inter-domain protection, as described in [RFC6074], using either
	However, with this solution, the protection time relies on BGP		option B or option C inter-AS models. However, with this solution,
	control plane convergence. In certain deployments, with tight SLA		the protection time relies on BGP control plane convergence. In
	requirements on availability, this mechanism may not provide the		certain deployments, with tight SLA requirements on availability,
	desired failover time characteristics. Furthermore, in certain		this mechanism may not provide the desired failover time
	situations MP-BGP is not deployed for VPLS. The redundancy solution		characteristics. Furthermore, in certain situations MP-BGP is not
	described in this document reuses ICCP [I-D.ietf-pwe3-iccp] and PW		deployed for VPLS. The redundancy solution described in this
	redundancy [RFC6718] to provide fast convergence.		document reuses ICCP [I-D.ietf-pwe3-iccp] and PW redundancy [RFC6718]
			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 Autonomous		only replicates to local PEs and to the ASBR. The ASBR then sends
	System Border Router (ASBR). The ASBR then sends traffic P2P to the		traffic point-to-point to the remote ASBR, and the remote ASBR
	remote ASBR, and the remote ASBR replicates to its local PEs. As a		replicates to its local PEs. As a result, the load of replication is
	result, the load of replication is distributed and is more efficient		distributed and is more efficient than option B.
	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 5, line 23 ¶		skipping to change at page 5, line 26 ¶
	|PE2|---|-| PE4 |-|-----------------|--| PE6 ||----|PE8|		|PE2|---|-| PE4 |-|-----------------|--| PE6 ||----|PE8|
	+---+ | +-----+ | standby PW2 | +-----+| +---+		+---+ | +-----+ | standby PW2 | +-----+| +---+
	| | | |		| | | |
	| | | |		| | | |
	| RG1 | | RG2 |		| RG1 | | RG2 |
	+---------+ +---------+		+---------+ +---------+
	operator A network operator B network		operator A network operator B network
	Figure 1		Figure 1
	Figure 2 presents a four-PWs inter-domain VPLS redundancy use-case.		Figure 2 presents a four-PWs inter-domain VPLS redundancy use case.
	PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs		PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs
	within its own AS. A deployment example of this use case is where		within its own AS. A deployment example of this use case is where
	there are four physical links between two domains and four PEs are		there are four physical links between two domains and four PEs are
	physically connected with each other with four links.		physically connected with each other with four links.
	+---------+ +---------+		+---------+ +---------+
	+---+ | +-----+ | | +-----+| +---+		+---+ | +-----+ | | +-----+| +---+
	|PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7|		|PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7|
	| | | | |-|-PW3\ /------|--| || | |		| | | | |-|-PW3\ /------|--| || | |
	+---+\ |/+-----+ | \ / | +-----+\ /+---+		+---+\ |/+-----+ | \ / | +-----+\ /+---+
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 20 ¶
	PW redundancy application procedures are described in section 9.1 of		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		[I-D.ietf-pwe3-iccp]. When a PE node encounters a failure, the other
	PE takes over. This document reuses the PW redundancy mechanism		PE takes over. This document reuses the PW redundancy mechanism
	defined in[I-D.ietf-pwe3-iccp], with new ICCP switchover conditions		defined in[I-D.ietf-pwe3-iccp], with new ICCP switchover conditions
	as specified in following section.		as specified in following section.
	There are two PW redundancy modes defined in [RFC6870]: Independent		There are two PW redundancy modes defined in [RFC6870]: Independent
	mode and Master/Slave mode. For the inter-domain four-PW scenario,		mode and Master/Slave mode. For the inter-domain four-PW scenario,
	it is required for PEs to ensure that the same mode is supported on		it is required for PEs to ensure that the same mode is supported on
	the two ICCP peers in the same RG. One method to ensure mode		the two ICCP peers in the same RG. This can be achieved using manual
	consistency is by manual operation. Other methods are also possible		configuration at the ICCP peers. Other methods for ensuring
	and are out of the scope of this document.		consistency are out of the scope of this document.
	5.1. ICCP switchover condition		5.1. ICCP switchover condition
	5.1.1. Inter-domain PW failure		5.1.1. Inter-domain PW failure
	When a PE receives advertisements from the active PE, in the same RG,		When a PE receives advertisements from the active PE, in the same RG,
	indicating that all the inter-domain PW status has changed to DOWN/		indicating that all the inter-domain PW status has changed to DOWN/
	STANDBY, then if it has the highest priority (after the advertising		STANDBY, then if it has the highest priority (after the advertising
	PE), it SHOULD advertise active state for all of its associated		PE), it SHOULD advertise active state for all of its associated
	inter-domain PWs.		inter-domain PWs.
	5.1.2. PE node isolation		5.1.2. PE node isolation
	When a PE detects failure of all PWs to the local domain, it SHOULD		When a PE detects failure of all PWs to the local domain, it SHOULD
	advertise standby state for all its inter-domain PWs to trigger		advertise standby state for all its inter-domain PWs to trigger
	remote PE to switchover.		remote PE to switchover.
	5.1.3. PE node failure		5.1.3. PE node failure
	When a PE node detects that the active PE, that is member of the same		When a PE node detects that the active PE, that is a member of the
	RG, has gone down, if the local PE has redundant PWs for the affected		same RG, has gone down, if the local PE has redundant PWs for the
	services and has the highest priority (after the failed PE), it		affected services and has the highest priority (after the failed PE),
	advertises the active state for all associated inter-domain PWs.		it SHOULD advertise the active state for all associated inter-domain
			PWs.
	5.2. Inter-domain redundancy with two-PWs		5.2. Inter-domain redundancy with two-PWs
	In this use case, it is recommended that the operation be as follows:		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		o ICCP deployment option: ICCP is deployed on VPLS edge nodes in
	both domains;		both domains;
	o PW redundancy mode: independent mode only;		o PW redundancy mode: independent mode only;
	o Protection architectures: 1:1(1 standby, 1 active).		o Protection architectures: 1:1(1 standby, 1 active).
	The switchover rules described in section 5.1 apply. Before		The switchover rules described in section 5.1 apply. Before
	deploying this inter-domain VPLS, the operators should negotiate to		deploying this inter-domain VPLS, the operators should negotiate to
	configure the same PW high/low priority at two PW end-points. The		configure the same PW high/low priority at two PW end-points. The
	inter-domain VPLS relationship normally involves a contractual		inter-domain VPLS relationship normally involves a contractual
	process between operators, and the configuration of PW roles forms		process between operators, and the configuration of PW roles forms
	part of this process. E.g, in figure 1, PE3 and PE5 MUST both have		part of this process. E.g, in figure 1, PE3 and PE5 must both have
	higher/lower priority than PE4 and PE6, otherwise both PW1 and PW2		higher/lower priority than PE4 and PE6, otherwise both PW1 and PW2
	will be in standby state.		will be in standby state.
	5.3. Inter-domain redundancy with four-PWs		5.3. Inter-domain redundancy with four-PWs
	In this use case, there are two options to provide protection: 1:1		In this use case, there are two options to provide protection: 1:1
	and 3:1 protection. The inter-domain PWs that connect to the same PE		and 3:1 protection. The inter-domain PWs that connect to the same PE
	should have proper PW priority to advertise same active/standby		should have proper PW priority to advertise same active/standby
	state. E.g, in figure 2, both PW1 and PW3 connected to PE3 would		state. E.g, in figure 2, both PW1 and PW3 connected to PE3 should
	advertise active/standby state.		advertise active/standby state.
	For 1:1 protection model, the operation would be as follows:		For 1:1 protection model, the operation would 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
	both domains;		both domains;
	o PW redundancy mode: independent mode only;		o PW redundancy mode: independent mode only;
	o Protection architectures: 1:1(1 standby, 1 active).		o Protection architectures: 1:1(1 standby, 1 active).
	The switchover rules described in section 5.1 apply. In this case,		The switchover rules described in section 5.1 apply. In this case,
	the operators do not need to do any coordination of the inter-domain		the operators do not need to do any coordination of the inter-domain
	PW priority. The PE detecting one PW DOWN should set the other PW to		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		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		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.1.1.		or STANDBY, it SHOULD switchover as described in section 5.1.1.
	There are two variants of the 3:1 protection model. We will refer to		There are two variants of the 3:1 protection model. We will refer to
	them as option A and B. For option A of the 3:1 protection model, the		them as options A and B. The implementation MUST support option A,
	support of Request Switchover status bit [RFC6870] is required. The		and MAY support option B. Option B will be useful when the two legacy
	operation is as follows:		PEs in one domain does not support the function in this document.
			The two legacy PEs still need to support PW redundancy defined in
			[RFC6870], and be configured as slave node.
			For option A of the 3:1 protection model, the support of Request
			Switchover status bit [RFC6870] is required. The operation is 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
	both domains;		both domains;
	o PW redundancy mode: Independent mode with 'request switchover' bit		o PW redundancy mode: Independent mode with 'request switchover' bit
	support;		support;
	o Protection architectures: 3:1 (3 standby, 1 active).		o Protection architectures: 3:1 (3 standby, 1 active).
	In this case, the procedure on the PE for the PW failure is per		In this case, the procedure on the PE for the PW failure is per
	section 6.3 of [RFC6870], and with the following additions:		section 6.3 of [RFC6870], and with the following additions:
	o When the PE detects failure of the active inter-domain PW, it		o When the PE detects failure of the active inter-domain PW, it
	should switch to the other local standby inter-domain PW if		SHOULD switch to the other local standby inter-domain PW if
	available, and send an updated LDP pseudowire status message with		available, and send an updated LDP PW status message with the
	the 'request switchover' bit set on that local standby inter-		'request switchover' bit set on that local standby inter-domain PW
	domain PW to the remote PE;		to the remote PE;
	o Local and remote PE should also update the new PW status to their		o Local and remote PE SHOULD also update the new PW status to their
	ICCP peers, respectively, in Application Data Messages with PW-RED		ICCP peers, respectively, in Application Data Messages with PW-RED
	Synchronization Request TLV for corresponding service, so as to		Synchronization Request TLV for corresponding service, so as to
	synchronize the latest PW status on both PE sides;		synchronize the latest PW status on both PE sides.
	o While waiting for the acknowledgement, the PE that sent the		o While waiting for the acknowledgement, the PE that sends the
	'request switchover' bit may receive a switchover request from its		'request switchover' bit may receive a switchover request from its
	ICCP peer's PW remote endpoint by virtue of the ICCP		ICCP peer's PW remote endpoint by virtue of the ICCP
	synchronization. The PE MUST compare IP addresses with that PW		synchronization. The PE MUST compare IP addresses with that PW
	remote peer. The PE with a higher IP address will 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 MUST clear		in the remote domain. The PE with the lower IP address SHOULD
	'request switchover' bit and set 'Preferential Forwarding' local		clear 'request switchover' bit and set 'Preferential Forwarding'
	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 will acknowledge		o The remote PE receiving 'request switchover' bit SHOULD
	the request and activate the PW only when it is ready to take over		acknowledge the request and activate the PW only when it is ready
	as described in section 5.1, otherwise, it MUST ignore the		to take over as described in section 5.1, otherwise, it SHOULD
	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 35 ¶		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 would 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, some manual operation/negotiation is required to be		this document, consistent provisioning is required for proper
	done correctly and securely. E.g., each node within one RG should be		operation. The two domains must both use the same use case (section
	configured with same redundancy mode; the two operators should		5.2 or section 5.3). Within each section, all of the described modes
	negotiate to configure same PW priority at two nodes. If the		and options must be provisioned identically both within each RG and
	configuration consistency is broken, the inter-domain redundancy		between the RGs. Additionally, for the two-PWs redundancy options
			defined in section 5.2, the two operators must also negotiate to
			configure same high/low PW priority at the two PW end-points. If the
			provisioning is inconsistent, then the inter-domain redundancy
	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], [RFC4762]		Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP
	and [RFC6870], this document will have additional security		control plane, [RFC4762] and [RFC6870] for PW control plane, this
	consideration.		document has additional security consideration for ICCP control
			plane.
	ICCP is now deployed between two PEs or ASBRs, the two PEs or ASBRs
	should be connected by a well managed and highly monitored network.
	The LDP session could be secured with TCP Authentication Option
	[RFC5925]. This provides integrity and authentication for the ICCP
	messages. The LDP MD5 authentication key option, as described in
	section 2.9 of [RFC5036] MAY also be used.
	The attention of implementers and deployers is drawn to [RFC6941] and		In this document, ICCP protocol is deployed between two PEs or ASBRs.
	[RFC6952] with special attention to the recommendation to use TCP-AO		The two PEs or ASBRs should only be connected by a network that is
	[RFC5925] for enhanced security of LDP sessions.		well managed and whose service levels and availability are highly
			monitored. This should be ensured by the operator.
	The activitiy on the inter-domain and intra-domain pseudowire may		The state flapping on the inter-domain and intra-domain PW may cause
	cause security threats or be exploited to create denial of service		security threats or be exploited to create denial of service attacks.
	attackes. Excessive pseudowire state flapping (e.g., by malicious		For example, excessive PW state flapping (e.g., by malicious peer
	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 for their		The authors would like to thank Sami Boutros, Giles Heron, Adrian
	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
	Nanjing, China		Nanjing, China
	Email: wang.yubao@zte.com.cn		Email: wang.yubao@zte.com.cn
	11. References		11. References
	11.1. Normative references		11.1. Normative references
	[I-D.ietf-pwe3-iccp]		[I-D.ietf-pwe3-iccp]
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 46 ¶
	11.2. Informative references		11.2. Informative references
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service		[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
	(VPLS) Using Label Distribution Protocol (LDP) Signaling",		(VPLS) Using Label Distribution Protocol (LDP) Signaling",
	RFC 4762, January 2007.		RFC 4762, January 2007.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.
	[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,		[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
	"Provisioning, Auto-Discovery, and Signaling in Layer 2		"Provisioning, Auto-Discovery, and Signaling in Layer 2
	Virtual Private Networks (L2VPNs)", RFC 6074,		Virtual Private Networks (L2VPNs)", RFC 6074,
	January 2011.		January 2011.
	[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire		[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
	Redundancy", RFC 6718, August 2012.		Redundancy", RFC 6718, August 2012.
	[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
	Graveman, "MPLS Transport Profile (MPLS-TP) Security
	Framework", RFC 6941, April 2013.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, May 2013.
	[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.		[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
	Kodeboniya, "Multicast in Virtual Private LAN Service		Kodeboniya, "Multicast in Virtual Private LAN Service
	(VPLS)", RFC 7117, February 2014.		(VPLS)", RFC 7117, February 2014.
	Authors' Addresses		Authors' Addresses
	Zhihua Liu		Zhihua Liu
	China Telecom		China Telecom
	109 Zhongshan Ave.		109 Zhongshan Ave.
	Guangzhou 510630		Guangzhou 510630
End of changes. 39 change blocks.
	140 lines changed or deleted		140 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/