Networking Working Group Z. Liu
Internet-Draft China Telecom
Intended status: Informational L. Jin
Expires: September 10, 2012 R. Chen
ZTE Corporation
March 9, 2012
Node redundancy provisioning for VPLS Inter-domain
draft-liu-l2vpn-vpls-inter-domain-redundancy-02
Abstract
In many VPLS deployment based on [RFC4762], inter-domain has been
deployed without node redundancy, or only with node redundancy in one
domain. This document describes how to deploy inter-domain VPLS
based on [RFC4762] with node redundancy in both domain. The draft
reuses the existing protocols without introducing any new protocols.
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 September 10, 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
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
Liu, et al. Expires September 10, 2012 [Page 1]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
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. Redundancy scenario with ICCP . . . . . . . . . . . . . . . . . 3
5. Node redundancy for VPLS Inter-domain . . . . . . . . . . . . . 4
6. MAC Withdraw procedure in VPLS Inter-domain . . . . . . . . . . 5
6.1. MAC withdraw notification TLV format . . . . . . . . . . . 6
6.2. Optimized MAC Withdraw processing . . . . . . . . . . . . . 7
7. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative references . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Liu, et al. Expires September 10, 2012 [Page 2]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
1. Introduction
In many VPLS deployment based on [RFC 4762], inter-domain has been
deployed without node redundancy, or only with node redundancy in one
domain. This document describes how to deploy inter-domain VPLS
based on [RFC 4762] with node redundancy in both domain. The draft
reuses the existing protocols without introducing any new protocols.
The domain in this document refers to AS, or other administrative
domain.
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 has now been wildly deployed between two providers.
Usually, the physical link and ASBR between the two providers would
carry many kinds of service, then it is important to provider link
and node redundancy for such kind of inter-AS service to ensure high
availability.
Some current high availability deployments of inter-AS VPLS are
provided by MC-LAG (Multi-Chassis Link Aggregation) and
[I-D.ietf-pwe3-iccp], but there is a pre-condition that the
interconnected link between the two providers are Ethernet link.
There are also many interconnection cases between two providers to
use POS (Packet over Sonet/SDH) link on which MC-LAG cannot be
enabled. Moreover, it is also required for the VPLS between two
providers to ensure bandwidth control, QoS, MAC address control and
Broadcast/Multicast traffic control. Then from the technical point
of view, it is necessary to use PW to interconnect the two VPLS in
its corresponding providers, and also to provide link/node redundancy
to ensure high availability.
4. Redundancy scenario with ICCP
The following figure presents a typical inter-AS VPLS deployment
topology. PE3 and PE4 are the VPLS edge nodes in network of operator
A, and PE5 and PE6 are the VPLS edge nodes in network of operator B.
The PE3/PE4/PE5/PE6 may be ASBR of the AS, or VPLS PE within its own
AS.
Liu, et al. Expires September 10, 2012 [Page 3]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
+---------+ +---------+
+---+ | +-----+ | active PW1 | +-----+| +---+
|PE1|---|-| PE3 |-|-----------------------|--| PE5 ||----|PE7|
+---+\ |/+-----+ | | +-----+\ /+---+
| \ / | * | | * | |\ / |
| \| | |ICCP| |ICCP| | | \ |
| / \ | * | | * | |/ \ |
+---+/ |\+-----+ | | +-----+/ \+---+
|PE2|---|-| PE4 |-|-----------------------|--| PE6 ||----|PE8|
+---+ | +-----+ | standby PW2 | +-----+| +---+
| | | |
| | | |
| RG1 | | RG2 |
+---------+ +---------+
operator A network operator B network
Figure 1
When inter-AS VPLS is deployed with node redundancy on both AS side,
node redundancy protocol ICCP[I-D.ietf-pwe3-iccp]SHOULD be
implemented on the VPLS edge nodes of the AS, e.g, ICCP should be
running between PE3 and PE4, PE5 and PE6.
There are several deployment scenarios for inter-domain VPLS:
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in one
domain, or in both domain;
o PW redundancy mode: independent or master/slave;
From the operator's point of view, it is important to keep the
technical balance and technical independence between the two
operators. One operator will not highly rely on the other operator's
technical choice for inter-domain VPLS node redundancy. Then it is
highly recommended to be the deployment scenario as follows:
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in
both domain;
o PW redundancy mode: independent only;
And this draft will only focus on the above deployment option, other
options are out of the scope.
5. Node redundancy for VPLS Inter-domain
The PEs in the RG are required to run an inter-chassis communication
protocol ([I-D.ietf-pwe3-iccp]) in order to select which
pseudowire(s) should be in active/standby state for a given VPLS
service instance.
Liu, et al. Expires September 10, 2012 [Page 4]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
The procedures to select active/standby pseudowire(s):
o The PEs in the RG enable ICCP[I-D.ietf-pwe3-iccp].
o The PEs should establish a PW-RED application connection using the
mechanism described in [I-D.ietf-pwe3-iccp], section 9.1.1.
o When the PW-RED application connection first comes up, Each PE
MUST advertise it local PW configuration to other PEs that are
members of the same RG. As part of the configuration information,
the PE should advertise a PW priority value that is used to
determine the precedence of a given pseudowire.
o Pseudowire Status Synchronization. In order to synchronize
pseudowire state, "PW-RED State TLV" is send whenever the
pseudowire state changes on a PE. The PE MAY re-advertise its PW-
RED state in an unsolicited/solicited manner, the detailed
mechanism is described in [I-D.ietf-pwe3-iccp], section 9.1.3.
The PEs SHOULD then use PW redundancy bit
[I-D.ietf-pwe3-redundancy-bit] or basic PW status bit [RFC4447] to
advertise the outcome of the arbitration to the peer PE(s).
Before deploying inter-domain VPLS, the operator MUST negotiate to
configure same PW priority at two end-points. If different PW
priority value is configured at the two PW end-points, e.g, PE3 and
PE5 for PW1, and PE4 and PE6 for PW2 in figure 1, it is possible to
select PE3 and PE6 as active for the two domain, then both PW1 and
PW2 will be standby according to the independent mode in
[I-D.ietf-pwe3-redundancy-bit].
6. 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 active PW failure is detected by the PE3, it
will trigger MAC Address Withdraw message into the full mesh. By
default, as per the processing rules defined in [RFC4762], upon PE4
activates the standby PW, it will also send a MAC Address Withdraw
message. There would be two copies of MAC Address Withdraw message
received by each PE, which would make the network convergence worse.
What's more, there are two MAC withdraw capabilities defined,
positive MAC withdraw (Flush-all-but-mine, defined in [RFC4762] and
[I-D.ietf-l2vpn-vpls-ldp-mac-opt]), and negative MAC withdraw (Flush-
Liu, et al. Expires September 10, 2012 [Page 5]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
all-from-me,defined in [I-D.ietf-l2vpn-vpls-ldp-mac-opt]). If the
two PE support only positive MAC withdraw, then PE4 is required to
send MAC withdraw message when PW switching. While if two PE support
both positive & negative MAC withdraw or support only negative MAC
withdraw capability, then PE3 is required to send MAC withdraw
message when PE switching.
In order to determine which PE to send MAC withdraw message is most
appropriate, we introduce an MAC withdraw notification TLV in ICCP
PW-RED application to negotiate the MAC withdraw capability.
6.1. MAC withdraw notification TLV format
The MAC withdraw notification TLV is describe 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 notification | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|N| Reserved |
+-+-+-+-+-+-+-+-+
Figure 2
U-bit: Unknown bit. This bit SHOULD be set to 1 (ignore if not
understood)
F-bit: Forward bit. This bit SHOULD be set to 0 (do not forward if
not understood)
MAC withdraw notification TLV: It is requested in the IANA
allocation.
P-bit: Used to indicate whether the node supports the positive (N=0,
Flush-all-but-mine) MAC withdraw capability. P=1 indicates that the
node has the capability to send the positive MAC withdraw message.
N-bit: Used to indicate whether the node supports the negative (N=1,
Flush-all-from-me) MAC withdraw capability. N=1 indicates that the
node has the capability to send the negative MAC withdraw message.
Reserved: Reserved for future use.
Liu, et al. Expires September 10, 2012 [Page 6]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
MAC withdraw notification TLV is advertised to a LDP ICCP peer if
there is at least one RG enabled on the local PE, and this TLV should
be carried in "RG Application Data" message.
6.2. Optimized MAC Withdraw processing
After receiving the MAC withdraw capability through MAC withdraw
notification TLV, the PE should process as below:
o If the former active PE & standby PE support only the positive MAC
withdraw capability, then former standby PE will trigger MAC
withdraw with positive MAC withdraw message
[I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other PEs that in the same AS
when active PW failures.
o If the former active PE & standby PE support only negative MAC
withdraw capability or support both positive & negative MAC
withdraw, then former active PE sends MAC Address withdraw message
with negative MAC withdraw message
[I-D.ietf-l2vpn-vpls-ldp-mac-opt] to other PEs that in the same AS
when active PW failures.
o The former standby PE may send MAC Address withdraw message with
positive MAC withdraw message [I-D.ietf-l2vpn-vpls-ldp-mac-opt] to
other PEs that in the same AS when the active PE failures.
7. 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
PE in one domain.
8. Security Considerations
This section will be added in a future version.
9. IANA Consideration
This document creates a new "ICC RG parameter type" (MAC withdraw
notification TLV) that is allocated by IANA, and a value of 0x0020 is
suggested for assignment with this TLV.
10. Normative references
[I-D.ietf-l2vpn-vpls-ldp-mac-opt]
Dutta, P., Balus, F., Stokes, O., and G. Calvignac, "LDP
Liu, et al. Expires September 10, 2012 [Page 7]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
Extensions for Optimized MAC Address Withdrawal in
H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-05 (work in
progress), October 2011.
[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]
Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", draft-ietf-pwe3-redundancy-06 (work in
progress), February 2012.
[I-D.ietf-pwe3-redundancy-bit]
Muley, P. and M. Aissaoui, "Pseudowire Preferential
Forwarding Status Bit", draft-ietf-pwe3-redundancy-bit-06
(work in progress), February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
Authors' Addresses
Zhihua Liu
China Telecom
109 Zhongshan Ave.
Guangzhou 510630
P.R.China
Email: zhliu@gsta.com
Liu, et al. Expires September 10, 2012 [Page 8]
Internet-Draft Node redundancy for VPLS Inter-domain March 2012
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
Liu, et al. Expires September 10, 2012 [Page 9]