INTERNET DRAFT Pranjal Kumar Dutta L2VPN Working Group Marc Lasserre Expires: March 2007 Lucent Technologies September 2006 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.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- Wire) 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 March 2007 [Page 1] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.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......................................7 7. IANA Considerations..........................................7 8. Acknowledgements.............................................7 9. References...................................................7 10. Authors' Addresses...........................................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 March 2007 [Page 2] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.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 in 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 March 2007 [Page 3] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.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 may trigger LDP Address Withdraw Messages with empty MAC List to all other PE-rs devices in the VSI in the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit: Unknown bit. This bit MUST be set to 1. If the LSR-ID Format is not understood then the TLV MUST be ignored. F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded. Type : Type field. This field MUST be set to 0x405 (subject to IANA approval). This identifies the TLV type as LSR-ID TLV. Length : Length field. This field specifies the total length in octets of the LSR-ID Element in the TLV. The length varries depending on the type of LSR-ID Element. Dutta. Expires March 2007 [Page 4] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt There can be several types of LSR-ID Elements. 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 failover of spoke PW 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. Dutta. Expires March 2007 [Page 5] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt 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 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 device 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 may further trigger LDP Address Withdraw Message with empty MAC List and the LSR-ID option to all other PE-rs devices connected in full mesh in the VSI. PE2-rs SHOULD send the same LSR Identifier in the LSR-ID TLV as the one received in the message from MTU-s. 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. Dutta. Expires March 2007 [Page 6] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt 6. Security Considerations Security aspects of this draft will be discussed at a later point. 7. IANA Considerations The Type field in LSR-ID TLV is defined as 0x405 in section 5.1 and is subject to IANA approval. 8. Acknowledgments The authors wish to thank John Rigby, Prashanth Ishwar and Vipin Jain for valuable suggestions, both technical and editorial, for correcting and improving the document. 9. 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. 10. Author's Address Pranjal Kumar Dutta Lucent Technologies Email: pdutta@lucent.com Marc Lasserre Lucent Technologies E-mail: mlasserre@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 Dutta. Expires March 2007 [Page 7] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt 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. 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 March 2007 [Page 8] Internet Draft draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt