Network Working Group B. Kothari Internet-Draft R. Fernando Updates: 4761 (if approved) Juniper Networks Intended status: Standards Track October 27, 2008 Expires: April 30, 2009 VPLS Flush in BGP-based Virtual Private LAN Service draft-kothari-l2vpn-vpls-flush-00.txt Status of this Memo 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. 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. This Internet-Draft will expire on April 30, 2009. Kothari & Fernando Expires April 30, 2009 [Page 1]
Internet-Draft BGP VPLS Flush October 2008 Abstract This document defines procedures that allow BGP based Virtual Private LAN Service (VPLS) provider edge (PE) devices to send explicit flush notifications to remote VPLS PEs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General Terminology . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2. VPLS Flush Capability . . . . . . . . . . . . . . . . . . . . 5 3. VPLS-FLUSH Message . . . . . . . . . . . . . . . . . . . . . . 6 3.1. MAC List TLV . . . . . . . . . . . . . . . . . . . . . . . 8 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Kothari & Fernando Expires April 30, 2009 [Page 2]
Internet-Draft BGP VPLS Flush October 2008 1. Introduction [RFC4761] describes mechanisms that allow VPLS PEs to use BGP to automatically discover PE membership in VPLS domains and to signal pseudowires required to carry VPLS traffic. Each VPLS PE maintains state for MAC addresses that it learns from locally attached customer sites. In addition, each VPLS PE also maintains state for MAC addresses that belong to remote customer sites that are attached to remote PEs. MAC addresses of remote customer sites are learned over the pseudowires that are established among all the VPLS PEs. In case of a topology change that teardown pseudowires, VPLS PEs delete MAC addresses that were learned on those pseudowires. However, there are cases when a topology change, such as a failure between a customer site and a PE, does not teardown a pseudowire. In such cases where only local VPLS PE is aware of the topology change, an explicit notification for flushing MAC addresses on remote VPLS PEs is required. In absence of explicit MAC flush notification, stale MAC state might be deleted when MAC age out timer expires, which is typically in the order of minutes. Flushing of MAC addresses increases connectivity restoration time after a failure, and thus, a mechanism to expedite flushing of MAC addresses is highly desirable. This document describes a new BGP Capability for flush mechanisms in BGP based VPLS. A new BGP message, VPLS-FLUSH, is introduced to carry a list of TLVs that will be used to flush the MAC addresses associated with those TLVs. BGP is used as the control plane protocol to carry the VPLS-FLUSH message for following reasons: 1. Reuse: Since BGP is already used as the control plane protocol for VPLS service, use of BGP to carry VPLS-FLUSH message eliminates need for service providers to deploy a new protocol for MAC flush notification. 2. Efficient flooding: Since a VPLS PE that triggers the MAC flush operations needs to notify all other VPLS PEs participating in the same VPLS, it needs to efficiently flood the message to only the PEs that are intended recipient of VPLS-FLUSH message. The VPLS-FLUSH message will be propagated to only those routers that would have received the VPLS NLRIs for the same RT that is carried in the VPLS-FLUSH message as well, both in intra-AS and inter-AS deployments. BGP signalled VPLS networks restrict the flow of routing messages to only the interested routers and ASes today by use of Route Target extended communities [RFC4360] and RT constrains [RFC4684]. Kothari & Fernando Expires April 30, 2009 [Page 3]
Internet-Draft BGP VPLS Flush October 2008 1.1. General Terminology VPLS domain: A VPLS domain represents a bridging domain per customer. A Route Target community as described in [RFC4360] is used to identify all the PE routers participating in a particular VPLS domain. Source PE: A VPLS PE that originates either the VPLS NLRI or VPLS- FLUSH message. The source PE address is carried in Route Origin Extended Community [RFC4360] and use of this community for VPLS advertisements is described in [I-D.kompella-l2vpn-vpls-multihoming]. 1.2. 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]. Kothari & Fernando Expires April 30, 2009 [Page 4]
Internet-Draft BGP VPLS Flush October 2008 2. VPLS Flush Capability To advertise the VPLS Flush Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [RFC3392]. The Capability code is to be assigned by IANA with a Capability length 0. By advertising the VPLS Flush Capability to a peer, a BGP speaker conveys to the peer that the speaker is capable of receiving and properly handling the VPLS-FLUSH message, described in Section 4, from the peer. A BGP speaker should only send a VPLS Flush Capability to a peer if and only if BGP VPLS address family (Section 3.2.2 [RFC4761]) is also enabled and negotiated with the peer. Kothari & Fernando Expires April 30, 2009 [Page 5]
Internet-Draft BGP VPLS Flush October 2008 3. VPLS-FLUSH Message The VPLS-FLUSH is a new BGP message that always includes the fixed size BGP header and MUST include the fields shown below. The type is to be assigned by IANA. Message Format: +-----------------------------------------------------+ | Sequence Number (4 octets) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | VPLS Flush TLVs Length (2 octets) | +-----------------------------------------------------+ | VPLS Flush TLVs (variable) | +-----------------------------------------------------+ Sequence Number: This 4-octets unsigned integer indicates the current sequence number of the flush message being sent to the remote VPLS PEs. Total Attribute Length: This 2-octets unsigned integer indicates the total length of the Path Attributes field in octets. Its value MUST be greater than 0, which implies that at least one attribute must be present. Attributes: A variable length sequence of path attributes is present in every VPLS-FLUSH message. The following attributes MUST be present: o Route Target Community o AS-PATH Attribute o ORIGINATOR_ID Attribute Kothari & Fernando Expires April 30, 2009 [Page 6]
Internet-Draft BGP VPLS Flush October 2008 o CLUSTER_LIST Attribute o Route Origin Extended Community AS-PATH, ORIGINATOR_ID and CLUSTER_LIST attributes are processed and updated exactly like they are in routing messages and are present to make sure VPLS-FLUSH messages never end up in a loop. Note that use of Route Origin Extended Community for VPLS advertisements is described in [I-D.kompella-l2vpn-vpls-multihoming]. VPLS Flush TLVs Length: This 2-octets unsigned integer indicates the total length of the VPLS Flush TLVs field in octets. Its value MUST be greater than 0. VPLS Flush TLVs: This is a variable length field that contains a list of TLVs that indicates what MAC addresses are to be flushed based on the value contained in each TLV. Each TLV is a triple <type, length, value> of variable length. The type is a 2-octet field that identifies one of the possible TLVs defined. Length is a 2-octet field that indicates the TLV value length. Value is of variable length and is encoded according to the TLV type. If a VPLS PE receives a VPLS-FLUSH message that contains a TLV type that it does not understand, it SHOULD ignore that TLV alone. The Type is a 2-octet field, with possible values as follows: Value Meaning 0 MAC list TLV Kothari & Fernando Expires April 30, 2009 [Page 7]
Internet-Draft BGP VPLS Flush October 2008 3.1. MAC List TLV VPLS FLush TLV type 0 indicates that the TLV contains a list of 48 bits MAC addresses that should be flushed by the PE processing the VPLS-FLUSH message. The length field specifies the total length in octets of the MAC addresses present in the TLV. If the length is 0, which indicates that no MAC addresses are present, then all MAC addresses learned from the source PE (indicated by Route Origin Extended Community) should be flushed. The length MUST be a multiple of 6. The encoding for MAC list 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 | Length | +------------------------------+-------------------------------+ | MAC address #1 | +------------------------------+-------------------------------+ | MAC address #1 | MAC address #2 | +------------------------------+-------------------------------+ | MAC address #2 | +------------------------------+-------------------------------+ . ... . +------------------------------+-------------------------------+ | MAC address #n | +------------------------------+-------------------------------+ | MAC address #n | +------------------------------+ A VPLS PE that receives a VPLS-FLUSH message with a MAC list TLV should delete each MAC address listed in the TLV that it learned from the source VPLS PE for the VPLS domain specified by the Route Target. Kothari & Fernando Expires April 30, 2009 [Page 8]
Internet-Draft BGP VPLS Flush October 2008 4. Operation A speaker that is willing to receive the VPLS-FLUSH message from its peer should advertise the VPLS-FLUSH capability to its peer. A speaker may send the VPLS-FLUSH message to its peer only if it has received the VPLS-FLUSH capability from its peer. A VPLS-FLUSH message originated for a particular VPLS domain should carry the same Route Target (RT) that is used to identify that VPLS domain. The Route Target Extended Communities serve the dual purpose of identifying the member PEs of a VPLS domain as well as limiting the flooding of the VPLS-FLUSH message to be bounded by the member PEs. A router that receives a VPLS-FLUSH message without any RTs MUST neither process it nor propagate it. A RR or ASBR should not do BGP path selection for VPLS-FLUSH messages. A RR or ASBR MUST process the attributes contained in the VPLS-FLUSH message for loop detection and for RT constrains before propagating the message to other BGP peers, but it should hold no permanent state for a VPLS-FLUSH message. A PE should not do BGP or VPLS path selection for VPLS-FLUSH messages. A PE should only process VPLS Flush TLVs for the messages that have Route Target that matches one of the VPLS instance configured on the PE router. A PE might receive the same VPLS-FLUSH message from a source PE more than once due to presence of RRs or ASBRs. A PE can use the sequence number field to detect duplicate VPLS-FLUSH messages. It is RECOMMENDED that a PE ignore duplicate VPLS-FLUSH messages. How a PE ignore duplicate VPLS-FLUSH messages is outside the scope of this document. Other than state to detect duplicate flush messages, a PE should hold no other permanent state. A VPLS-FLUSH message might be lost if there are multiple failures. In such cases, the remote PEs for which the flush message was targeted for will continue to hold stale information unless they age it out or relearn the MAC addresses from a different source PE. If a VPLS-FLUSH message is lost due to a topology change that also teardown the PWs, then the affected PEs SHOULD flush MAC addresses learned over those PWs. Kothari & Fernando Expires April 30, 2009 [Page 9]
Internet-Draft BGP VPLS Flush October 2008 5. Security Considerations TBD Kothari & Fernando Expires April 30, 2009 [Page 10]
Internet-Draft BGP VPLS Flush October 2008 6. IANA Considerations TBD Kothari & Fernando Expires April 30, 2009 [Page 11]
Internet-Draft BGP VPLS Flush October 2008 7. Acknowledgments The authors would like to thank Yakov Rekhter, Nischal Sheth and John Scudder for their comments and suggestions. Kothari & Fernando Expires April 30, 2009 [Page 12]
Internet-Draft BGP VPLS Flush October 2008 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [I-D.kompella-l2vpn-vpls-multihoming] Kompella, K., Kothari, B., and T. IV, "Multi-homing in BGP-based Virtual Private LAN Service", draft-kompella-l2vpn-vpls-multihoming-01 (work in progress), July 2008. 8.2. Informative References [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006. [802.1ah] "IEEE Draft P802.1ah/D4.2 Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges,", March 2008. Kothari & Fernando Expires April 30, 2009 [Page 13]
Internet-Draft BGP VPLS Flush October 2008 Authors' Addresses Bhupesh Kothari Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: bhupesh@juniper.net Rex Fernando Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: rex@juniper.net Kothari & Fernando Expires April 30, 2009 [Page 14]
Internet-Draft BGP VPLS Flush October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Kothari & Fernando Expires April 30, 2009 [Page 15]