Network Working Group D. Jamieson Internet Draft Nortel Networks Expiration Date: May 1999 R. Wang Nortel Networks Solicitation Extensions for BGP-4 Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes an extension to BGP-4 which may be used by a BGP-4 speaker to solicit Virtual Private Network (VPN) reachability information from other IBGP speakers. The motivation of the proposed technique is to provide a means of reducing the memory requirements of routers which use BGP-4 to distribute VPN reachability information as described in [1] and [4]. The extension is backward compatible in that a router which supports the extension can interoperate with a router which doesn't. 1. Introduction Recently, several drafts have described techniques to dynamically establish VPN tunnels across a provider network. Many of the drafts have proposed that BGP-4 be used to distribute either VPN Jamieson, et al [Page 1] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 reachability information or VPN route information. The methods described in [1] generally don't depend on outbound policy filters to control the distribution of VPN reachability information. When a new VPN member site joins a VPN the information regarding that site is distributed to all other Provider Edge (PE) routers in the network. This allows new VPN member sites to join a VPN with very little or no intervention on the part of the provider. On the other hand, the methods described in [4] do rely on outbound policy filtering to control the distribution of VPN route information. PE routers and route reflectors need to be provisioned with a list of peers which require specific VPN route information. When a new VPN member site joins a VPN, policy filtering may have to be changed on multiple devices. In a large provider network which supports a large number of VPN subscribers, the methods described in both [1] and [4] could have serious scaling problems. Using the methods described in [1], the amount of VPN reachability information that would be stored in the BGP-4 speakers' Adj-RIB-In could be very large. Whereas, the percentage of that information relevant to any particular BGP-4 speaker might be small. Using the methods described in [4], there would potentially be two problems. First, the amount of policy required to control VPN route information distribution would become onerous. Second, in a large network, route reflectors would be required. Depending on the distribution of VPN sites and the complexity of policy filtering, the route reflectors may be required to store huge amounts of information in their Adj-RIB-In. The following network scenario is based on the methods described in [1]. The scenario makes some assumptions on the size of a future network. One can debate the numbers to a certain extent but it is clear that there is a problem: Number of Provider Edge nodes in provider network: 2,000 Number of VPN interfaces per Provider Edge (PE): 1,000 Average number of sites belonging to a VPN: 10 Number of VPN entries distributed to each PE: 2,000,000 Memory consumption estimate: Conservative size of BGP Adj-RIB-In entry: 30 bytes Size of BGP Adj-RIB-In: 60,000,000 bytes Given the assumptions above, 10,000 VPN Adj-RIB-In entries on an Jamieson, et al [Page 2] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 average PE would be acted upon. In other words, those 10,000 entries would be passed to the PE's directly connected Customer Premises Equipments (CPEs) for the purpose of establishing VPN tunnels. Whereas, 1,990,000 or 99.5% of the entries would have no value and be ignored. Some BGP-4 implementations allow entries which should be in Adj-RIB- In to be discarded; however, the entries may be required at a later time when a new VPN member joins. Currently, if a BGP-4 implementation allows Adj-RIB-In entries to be discarded, the only way to retrieve them at a later time is to close the peer connection and re-establish it. In a large network, this would be very disruptive. This draft proposes a technique which would allow BGP-4 to discard Adj-RIB-In entries that are not relevant and solicit those that are. 2. Terms and Definitions VPN Reachability Information (VRI) - A BGP route associated with a VPN. It contains route information as defined in [2] and VPN specific information. Solicitation - A request for VRI from an IBGP speaker to other IBGP speakers. Solicitation Capable IBGP (SC-IBGP) speakers - A router which has an implementation of BGP-4 that supports the solicitation extensions and solicitation is enabled on that router. All IBGP speakers on that router are called SC-IBGP speakers. Non-Solicitation Capable IBGP (NSC-IBGP) speakers - A router which has an implementation of BGP-4 that either does not support the solicitation extensions or solicitation is disabled on that router. All IBGP speakers on that router are called NSC-IBGP speakers. 3. Design Criteria BGP Solicitation was designed to satisfy the following criteria: - Dynamic, non-disruptive distribution of VRI - Ability to discard non-relevant VRI Jamieson, et al [Page 3] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 - Compatibility It must be possible for NSC-IBGP speakers (including route reflectors) to continue supporting the general VPN architecture without any loss of VRI. 4. Solicitation Path Attributes This document introduces two new BGP-4 path attributes: Solicitation Request and Solicitation Withdraw. 4.1. Solicitation Request Path Attribute (Type Code 16): The Solicitation Request (SOL_REQ) path attribute is an optional transitive attribute of length 0. It is used by a SC-IBGP speaker to solicit VRI from other SC-IBGP speakers. 4.2. Solicitation Withdraw Path Attribute (Type Code 17): The Solicitation Withdraw (SOL_WD) path attribute is an optional transitive attribute of variable length. The SOL_WD path attribute consists of a list of four octet values, each of which indicates membership withdraw from a particular VPN. Each SOL_WD path attribute is represented by a list of tuples of form , where each tuple is encoded as shown below: +-----------------------------+ | Length (2 octets) | +-----------------------------+ | VPN identifiers (variable) | +-----------------------------+ Length - total length of the VPN identifiers in octets VPN identifiers - a list of withdrawing VPN identifiers An UPDATE message that contains the SOL_WD attribute is not required to carry any other path attributes. The solicitation extension path attributes must not be passed to EBGP peers. 5. Solicitation of VPN Reachability Information The first time a SC-IBGP speaker A advertises a VRI for VPN X, A must Jamieson, et al [Page 4] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 include a SOL_REQ path attribute along with the VRI. This VRI must be distributed to all IBGP peers. It should be noted that subsequent VRIs advertised by A for VPN X should not include the SOL_REQ path attribute. When a SC-IBGP speaker B which supports VPN X receives the VRI originated from A (may come from a route reflector), B must distribute all of its VRIs associated with VPN X back to the peer from which it received the solicitation. A SC-IBGP speaker not in VPN X may discard the reachability information from A (i.e. may not store it in its Adj-RIB-In). A NSC-IBGP speaker C receiving A's UPDATE message must ignore the SOL_REQ path attribute, store the reachability information in its Adj-RIB-In and continue to distribute its VRIs for VPN X to all of its peers. Meanwhile, A should store all reachability information from C in its adj-RIB-In regardless whether C participates in the same VPN(s) or not. 6. VPN Membership Withdraw When a member of VPN X unsubscribes, a SC-IBGP speaker A will notify all other IBGP peers known to support VPN X. Multiple members of VPN X may be supported by A. But if the last member of VPN X is withdrawn from A, all other SC-IBGP speakers that support X should stop sending VRIs related to VPN X to A. To withdraw membership from VPN X, a SC-IBGP speaker A may include a SOL_WD path attribute along with the unfeasible route(s) in its UPDATE message. Upon receiving this UPDATE message, a SC-IBGP speaker B must withdraw the unfeasible route(s). B must also stop sending reachability information related to VPN X to A if the last reachability information related to VPN X from A has been withdrawn. Means to withdraw VRIs on NSC-IBGP speakers need further investigation. 7. Operation of BGP Route Reflectors Operation of BGP route reflectors which do not support solicitation remains the same as defined in section 5 of [3]. Operation of BGP route reflector which supports solicitation is proposed to change to the following: Jamieson, et al [Page 5] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 Each route reflector must keep track of the VPN associated with each of its SC-Client peers. When a route is received by a route reflector, it selects the best path based on its path selection rule. After the best path is selected, it must do the following depending on the type of peer it is receiving the best path from: 1) A route from a Non-Client peer - reflect to all SC-Client peers in the same VPN; and - reflect to all NSC-Client peers. 2) A route from a Client peer - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN other than the originator; and - reflect to all NSC-Client peers other than the originator. 3) A route from an EBGP peer - reflect to all Non-Client peers; and - reflect to SC-Client peers in the same VPN; and - reflect to all NSC-Client peers. 8. Security Considerations Security issues are not discussed in this memo. 9. Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. 10. References [1] T. Li, "CPE Based VPNs Using MPLS", draft-li-mpls-vpn-00.txt, October 1998. [2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)" draft- ietf-idr-bgp4-08.txt, Augest 1998. Jamieson, et al [Page 6] Internet Draft draft-jamieson-bgp-solicit-00.txt November 1998 [3] T. Bates, R. Chandra, "BGP Route Reflection An Alternative to Full Mesh IBGP", RFC 1966, June 1996 [4] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-rosen-vpn-mpls- 00.txt, November 1998. 11. Author's Address Dwight Jamieson Nortel Networks, Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada Email: djamies@nortelnetworks.com Rong Wang Nortel Networks, Ltd. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada Email: rwang@nortelnetworks.com Jamieson, et al [Page 7]