INTERNET DRAFT Pranjal Kumar Dutta
L2VPN Working Group Lucent Technologies
Expires: January 2007 July 2006
LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS
draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
[VPLS-LDP] defines a mechanism to remove or unlearn MAC addresses
that have been dynamically learned in a Virtual Switch Instance(VSI)
for faster convergence on topology change. One of the ways to
accomplish this is by sending LDP Address Withdraw Message with
empty MAC List when topology change occurs due to spoke PW (Pseudo
Wires) switchover at dual-homed capable Multi-Tenant Unit Switch
(MTU-s) in a Hierarchical VPLS (H-VPLS) domain. On receiving this
message a PE-rs removes all MAC addresses associated with the VSI
except the ones learned in the session over which the message is
received. The MAC addresses removed in this procedure also include
the MAC addresses learned from LDP sessions in the same VSI that
are not actually affected due to such topology change. This document
proposes an extension to LDP Address Withdraw Message with empty MAC
List defined in [VPLS-LDP], which enables the PE-rs receiving the
message to remove only the MAC addresses that are affected and need
to be relearned.
Dutta. Expires January 2007 [Page 1]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
1. Conventions
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].
2. Terminology
This document uses terminology described in [RFC3036], [L2VPN-FRWK],
and [VPLS-LDP].
3. Table of Contents
1. Conventions..................................................2
2. Terminology..................................................2
3. Table of Contents............................................2
4. Introduction.................................................2
4.1 Flushing of MACs learned from unaffected PE-rs...........3
5. Mechanism to avoid flushing of MACs from unaffected PE-rs....4
5.1 LDP Extension on LSR-ID..................................4
5.2 Processing of LSR-ID.....................................5
5.3 MAC Address Withdrawal Procedure with LSR ID.............6
5.4 Applicability of LSR-ID..................................6
6. Security Considerations......................................6
7. Acknowledgements.............................................7
8. References...................................................7
9. Author's Address.............................................7
4. Introduction
MAC Address Withdrawal is a mechanism proposed for faster
convergence in [VPLS-LDP] to remove or unlearn MAC addresses within
a VSI that have been dynamically learned. One example where MAC
Address Withdrawal is required is as a result of topology change due
to failure of primary spoke PW or primary PE-rs in a dual-homed
H-VPLS scenerio. This is accomplished by sending a LDP Address
Withdraw Message with list of MAC addresses to be removed to all
other PE-rs (Provider Edge)devices over the corresponding LDP
sessions. In order to minimize the impact on LDP convergence time
when MAC List TLV contains a large number of MAC Addresses, it may
be preferable to send a LDP Address Withdraw Message with an empty
MAC address list. The rule for processing the LDP Address Withdraw
Message with empty MAC List is defined in [VPLS-LDP] as follows:
- Remove all the MAC addresses associated with the VPLS instance
(specified by FEC TLV) except the MAC addresses learned over the
PW associated with this signaling session over which the message
was received.
Dutta. Expires January 2007 [Page 2]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
This document identifies one problem related to the current proposal
of MAC Address Withdrawal Mechanism as defined in [VPLS-LDP] and
a solution is proposed. Following is a dual-homed H-VPLS scenerio
for single VSI where the problem in current MAC Address Withdrawal
Mechanism with empty MAC List as per [VPLS-LDP] is explained.
PE1-rs PE3-rs
+--------+ +--------+
| | | |
| -- | | -- |
Customer Site 1 | / \ |------------------| / \ |->
CE-1 /------| \ s/ | | \S / |
\ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+
\ MTU-s / | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full Mesh Core|
| \S / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ secondary spoke PW | / \ |
/ \ +--------+ \--------+--------+
CE-2 \ | | | |
Customer Site 2 \------| -- | | -- |
| / \ |------------------| / \ |->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE2-rs PE4-rs
Figure 1: Dual homed MTU-s in 2 tier hierarchy H-VPLS
4.1 Flushing of MACs learned from unaffected PE-rs
In the scenerio in figure.1, in normal condition only the primary
spoke PW is active at MTU-s and so PE1-rs is acting as the primary
device for the dual homed MTU-s. The MAC addresses located at
customer sites (beyond CE1 and CE2) are learned by PE1-rs over the
primary spoke PW. PE2-rs, PE3-rs and PE4-rs may learn those MAC
addresses in the H-VPLS core on the respective hub PWs over the
signaling session with PE1-rs.
When spoke PW switchover takes place at MTU-s to the secondary PW,
PE2-rs becomes the primary PE-rs device and traffic in the VSI from
CE1 and CE2 is diverted over the spoke PW to PE2-rs. MTU-s may
desire to unlearn or remove all the MAC addresses that are learned
across the VSI earlier through PE1-rs for faster convergence. MTU-s
may send LDP Address Withdraw Message with empty MAC List to PE2-rs.
As per the rules of processing for empty MAC list defined in
[VPLS-LDP] PE2-rs should flush all the MAC addresses learned for the
VSI over the signaling sessions with PE1-rs, PE3-rs and PE4-rs. But
the actual MAC addresses that require flushing and relearning at
Dutta. Expires January 2007 [Page 3]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
PE2-rs are the MAC addresses that have been learned on PW from
PE1-rs. MAC address flushing and relearning are resource intensive
processes at PE-rs devices when there is a large number of MAC
addresses associated in the VSI. After processing the LDP Address
Withdraw Message with empty MAC List at PE2-rs, it is propagated to
all other PE-rs devices in the VSI in full mesh core. Same
processing rules are applied at all other PE-rs devices. For
example, at PE3-rs all the MAC addresses learned from PWs connected
to PE1-rs and PE4-rs will be flushed and relearned subsequently. As
the number of PE-rs devices increases, the number of unaffected MAC
addresses flushed also increases. With large number of VSIs
provisioned in the H-VPLS domain the amount of unnecessary MAC
address flushing and learning intensifies. An extension to the
existing MAC Address Withdraw Mechanism with empty MAC List is
proposed that enables a PE-rs device to flush only MAC addresses
that need relearning due to topology change at MTU-s.
5. Mechanism to avoid flushing of MACs from unaffected PE-rs
A mechanism is proposed that enables a PE-rs to remove or unlearn
MAC addresses only from the PW over a signaling session that are
required to be removed or unlearned due to topology change at dual-
homed capable MTU-s in H-VPLS.
5.1 LDP Extension on LSR-ID
A new optional LSR-ID TLV is defined which MAY be propagated within
LDP Address Withdraw Message with empty MAC List to PE-rs device(s)
in the VSI. The LSR-ID TLV carries the unique LSR identification
info of a PE-rs device in the VSI. A new LSR-ID Element is defined
to encode the LSR identification info of a PE-rs device. The LSR-ID
TLV MUST contain a single LSR-ID Element.
The encoding of LSR-ID TLV follows standard LDP TLV encoding defined
in [RFC3036] and is as follows :
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| Type (LSR-ID ) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR-ID Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Both U bit and F bit in the TLV MUST be set to 1.
Type number for LSR-ID will be allocated from IANA later.
Length depends on the type of LSR-ID Element. There can be several
types of LSR-ID Elements.
Dutta. Expires January 2007 [Page 4]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
The LSR-ID Element encoding is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (LSR-ID Element Type)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Identifier (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Field of size 2 octets that contains the type
of LSR-ID Element.
Length Field of size 2 octets that contains the
length of the LSR Identifier in number of
octets.
LSR Identifier Variable length field that contains the
value of LSR Identifier based on specific
type.
In this version one LSR-ID Element value encoding is defined and is
as follows:
LSR-ID Element Type Length Value
type name
Generic 0x01 4 LSR Identifier = The first
four octets of LDP
Identifier[RFC3036] that
identify a LSR and is
globally unique value,
such as a 32-bit router Id
assigned to the LSR.
Definitions and usage of other types of LSR-ID Elements is a subject
for future study.
5.2 Processing of LSR-ID
This section defines the processing rules of LSR-ID TLV with Generic
LSR-ID Element (type 0x01). The LSR-ID TLV is applicable ONLY in LDP
Address Withdraw Message with empty MAC List as defined in
[VPLS-LDP] and MAY be sent as optional parameter. When a MTU-s
triggers MAC Address Withdrawal after spoke PW failover to a PE-rs
device, it MAY send the LSR-ID TLV option with LSR Identifier of
that PE-rs device. There may be some applications that may require a
PE-rs device to initiate MAC Address Withdrawal in a VSI. In such
case the PE-rs device that initiates MAC Address Withdrawal MAY use
its own LSR Identifier in the LSR-ID TLV option. Irrespective of
whether it is the MTU-s or PE-rs device that initiates the MAC
Address Withdrawal, a PE-rs devices receiving the option follows the
same processing rules as defined in this section.
When a PE-rs device receives a LDP Address Withdraw Message with
empty MAC List and the LSR-ID TLV option, the PE-rs SHOULD flush all
the MAC addresses learned from the PW over LDP signaling session
Dutta. Expires January 2007 [Page 5]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
with the PE-rs device identified by LSR-ID Element. Note that a
PE-rs device uses the same local router Id in LDP sessions with all
other PE-rs devices in the full mesh core.
When a PE-rs device receives LDP Address Withdraw Message with empty
MAC List and LSR-ID TLV option, and the PE-rs does not have LDP
session with the one specified by the LSR Identifier then it SHOULD
NOT flush or relearn any MAC address in the VSI.
If a PE-rs device receives a LDP Address Withdraw Message with the
LSR-ID option included when there is a valid MAC address list then
it SHOULD ignore the option and deal with MAC addresses explicitly
as per corresponding procedures defined in [VPLS-LDP].
When a PE-rs that doesn't support LSR-ID TLV receives LDP Address
Withdraw Message with this option then it SHOULD ignore the option
and SHOULD follow the processing rules as per [VPLS-LDP].
5.3 MAC Address Withdrawal Procedure with LSR-ID
This section explains the MAC Address Withdrawal Procedure in the
scenerio in figure.1 when LSR-ID TLV option is used with Generic
LSR-ID Element. In the scenerio, PE1-rs is the primary device for
the dual homed MTU-s in normal condition. The traffic received for
the VSI from CE1 and CE2 is forwarded by MTU-s to PE1-rs and the
corresponding MAC addresses are learned by PE1-rs over the primary
spoke PW. Accordingly other PE-rs devices in the VSI in full mesh
core may learn those MAC addresses on their respective PWs over the
LDP signaling session with PE1-rs. After a PW switchover takes place
at MTU-s to secondary spoke PW, PE2-rs is selected as primary device
and MTU-s diverts the traffic from CE1 and CE2 to PE2-rs. MTU-s may
send a MAC Address Withdraw Message for the VSI with empty MAC List
and the optional LSR-ID TLV. The corresponding Generic LSR-ID
Element within the option may contain the LSR Identifier from the
LDP session with PE1-rs that uniquely identifies PE1-rs in the
H-VPLS domain. When the message is received at PE2-rs the processing
engine SHOULD remove all MAC addresses learned on the PW over the
LDP session with the device identified by LSR-ID TLV, that is
PE1-rs. PE2-rs propagates the LDP Address Withdraw Message to all
other PE-rs devices connected in full mesh for the VSI. Same
processing rules SHOULD be applied at all other PE-rs devices. For
example, when the message is received at PE3-rs it identifies the
LSR-ID to be associated with the signaling session with PE1-rs, So
PE3-rs SHOULD remove all MAC addresses learned on the PW over the
signaling session with PE1-rs.
5.4 Applicability of LSR-ID
The use of the LSR-ID TLV is applicable with 2-tier HVPLS domains as
defined in [VPLS-LDP]. The use of the LSR-ID TLV in inter-domain
connectivity models or 3-tier hierarchy models is out of scope.
6. Security Considerations
Security aspects of this draft will be discussed at a later point.
Dutta. Expires January 2007 [Page 6]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
7. Acknowledgments
The author wish to thank Marc Lasserre, John Rigby, Prashanth Ishwar
and Vipin Jain for valuable suggestions, both technical and
editorial, for correcting and improving the document.
8. References
[L2VPN-FRWK] Andersson, L., et al. "Framework for Layer 2
Virtual Private Networks (L2VPNs)", work in
progress.
[VPLS-LDP] Lasserre, M., et al. "Virtual Private LAN Services
using LDP",work in progress.
[RFC3036] Andersson, L., et al. "LDP Specification",RFC 3036,
January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Author's Address
Pranjal Kumar Dutta
Lucent Technologies India Pvt. Ltd
#3/1 Millers Road, J P Techno Parks
Bangalore - 560052
India
Phone: +91.80.5113.1932
Fax : +91.80.5113.1936
Email: pdutta@lucent.com
IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Dutta. Expires January 2007 [Page 7]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt
Copyright Notice
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Dutta. Expires January 2007 [Page 8]
Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt