Himanshu Shah Internet Draft Tenor Networks draft-shah-mpls-l2vpn-reduce-00.txt Expires: September 2001 March 2001 Reducing over-provisioning for MPLS based L2VPN 1.0 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2.0 Abstract This document will describe how providerÆs edge router can reduce the over-provisioning of resources and in some cases do away with the range configuration so that new sites can be added to an existing VPN topologies without incurring configuration changes to other providerÆs edge routers in the VPN. 3.0 Overview The draft-kompella-mpls-l2vpn-02.txt [MPLS] describes methodologies by which layer 2 circuits can be mapped through MPLS tunnels to remote sites that belong to the same VPN. It greatly reduces the configuration and improves scalability through the use of LSP hierarchical model. The reduction in configuration is partly based on over-provisioning of the resources. This aspect of over-provisioning of resources on an a priori basis is problematic. This document proposes some models whereby resources are committed in limited fashion, as and when the newer sites join the existing VPN. These models require in some cases additional configuration and add to distribution of information amongst PE routers. However, the benefits compensate the drawbacks. Shah Informational - Expires September 2001 1 Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001 The service provider starts with some decisions on characteristics of the offered VPN topologies; for instance whether VPN is full-mesh or hub-and-spoke, how many sites would he consider reasonable to add without additional configuration, the type of clients (i.e. routers or switches), etc. The proposed models are more beneficial in some topologies and less in others. 4.0 Introduction With the advent of extensions proposed in draft-shah-mpls-l2vpn-ext- 00.txt [MPLS-shah] to the base draft-kompella-mpls-l2vpn-02.txt [MPLS], it is possible to articulate a model whereby the PE router does not have to over-provision all the resources required for the MPLS based layer 2 VPN. The extension draft [shah], proposes a mechanism whereby, VPN information can be distributed in fragments. Each fragment includes the range of CE-ID that the advertising PE router is willing to connect to. The total number of CE-ID the PE router would then connect to, stems from the cumulating ranges of the CE-ID present in each fragment. 5.0 Operations The following sections describe how a service provider could offer VPN services with varying configuration on the PE router and how that relates to varying level of over-provisioning and other benefits. First a basic unit of VPN information is defined, followed by actions performed on this unit. 5.1 VPN information set A set for a given VPN and CE-ID is defined as a subset of VPN information consisting of CE-Base, CE-Range and a set of PVCs and interface information. CE-Ids that is greater than or equal to CE- Base and less than CE-Range are considered to be the part of the set. Combination of all the sets would then represent the entire VPN information for a given CE-ID of a VPN on a PE router. Each set for a given VPN + CE-ID is disjoint from other sets present for the same VPN + CE-ID. They must never overlap. Also, CE-Range minus CE- Base must be greater than or equal to one but never zero. The VPN information set is either active or inactive. Active state means that label resources have been allocated and the VPN information set has been advertised. Inactive state indicates existence of the set without label allocation and unadvertised status. An active set becomes inactive when VPN information of the set is withdrawn. Shah Informational - Expires September 2001 2 Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001 5.2 Set Activation The VPN information set is considered activated when a range of labels are allocated for the set. These labels do not have to be contiguous for a whole set as shown in draft-shah-mpls-l2vpn-00.txt [MPLS-shah]. However, the total number of labels allocated for the set must match the CE-Range minus the CE-Base of the set. The set is then advertised to remote PE peers in one or more fragments as described in draft-shah-mpls-l2vpn-00.txt [MPLS-shah]. If the set consists of more than one fragment, all the fragments must be advertised before the set is considered active. Also, note that when a PE router receives an advertisement, it must send active set(s), which contain configured CE-ID and received CE- ID. The set is activated under following circumstances. 1. A set matching the local CE-ID 2. A received CE-ID matches one of the set (as allowed by the color match), i.e. falls within CE-Base and CE-Range of the local set for the VPN. It is quite possible that the received set information may not contain the local CE-ID. This is OK. It is expected that those remote PE peers whose sets contain the sent local CE-ID, would respond with active sets that contain the local CE-ID. An activated set may not become active if all the label resources could not be obtained or there were issues with advertisements. 5.3 Set Deactivation The VPN information set is considered deactivated when the advertisement of the set is withdrawn and the label resources are freed. The set must be deactivated in its entirety. This means all the fragments advertised for this set, must be withdrawn. The set is deactivated for the reasons described in draft-kompella- mpls-l2vpn-02.txt [MPLS]. The set can also be deactivated on a periodic garbage collection basis when upon inspection found to hold no received advertisements for the CE-ID present in the set from remote PE peer and no local CE-ID matches the set either. To protect against possible race conditions or excessive advertisements, one should use least recently used type of algorithm with periodic garbage collection. 5.4 Configuration options Following configuration options describe various operational models that offer varying benefits of reduction in over-provisioning coupled with flexibility of adding newer sites with minimal to none reconfiguration. Shah Informational - Expires September 2001 3 Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001 5.4.1 Option-1 In this model, service provider configures sets on each PE router for a given VPN and a CE-ID. The PE router then locates the set that contains the local CE-ID and allocates the resources for this set. Initially, only the set containing the local CE-ID is advertised to remote PE peers. When VPN information is received for a given VPN, the received CE-ID is matched against the configured sets for the VPN + CE-ID. If a set is found and is not active, the set is activated by allocating the resources and sending out the new advertisement. The advantage of this model is that service provider controls the range of CE-Ids that a particular PE router would admit. For example, a given VPN has 50 sites and the customer wishes sub-VPN cluster of CE-IDs 0 to 10 and 30 to 40. The service provider would then configure PE routers connected to those CE that fall in these ranges, with two sets of the VPN information. In this situation, over-provisioning is limited to either one set or two sets (i.e. 20) but not the full range (i.e. 50). 5.4.2 Option-2 In this model, service provider configures maximum range and an increment value along with PVC and interface information in a PE router for a given VPN and a CE-ID. The PE router then breaks the range using the increment value into distinct sets with CE-Base, CE- Range and the related PVC and interface information. Initially, the local CE-ID is matched against the sets and the matching set is activated. As and when VPN information from the remote PE peers is received, the CE-ID is matched against the local sets. The matching set is then activated, if not already, and a new advertisement is sent with active sets that contain both the local CE-ID and remote CE-ID. The remote PE reciprocates with same processing yielding a new advertisement, if necessary. This approach reduces the configuration significantly as compared to option 1 but relies on color matching mechanisms to form sub-VPN clusters or hub-and-spoke type of VPN topologies. 5.4.3 Option-3 In this model, only VPN, CE-ID and associated interface are configured. A reasonable increment as a default is ascertained and the maximum range is obtained based on the type of interface. For instance, if the interface is frame relay, maximum assumed for 2- byte DLCIs would be 992 (16 to 1008). Using the increment, sets are created. Initially, only the set that contains the local CE-ID is activated. Subsequently, as and when advertisement from remote PE is received, the matching sets are activated. Shah Informational - Expires September 2001 4 Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001 This model offers maximum flexibility and minimum configuration. However, it is applicable to limited number of customer topologies. For instance, it is more suitable to customer edge devices that are frame relay DTE devices and are capable of handling new DLCIs activating in real time. Its narrow applicability, however, does not necessarily diminish its advantages since topologies like frame relay might be the most used topologies for MPLS based L2VPN services. By doing away with range configuration, new sites can be added without having to worry about re-adjusting the ranges on existing PE routers. 5.4.4 Option-4 In this model, service provider assumes the VPN topology to be in a trusted environment. The PE router is configured for the role it plays in the VPN topology. For instance, if the VPN is hub-and-spoke and the PE router is a spoke, the range values configured in the router are treated stricter than the PE routers that are hub. The rest of the VPN information is configured as discussed earlier. When a new spoke site is added, the advertisement processed on the hub PE router differs from spoke PE router. If the received CE-ID does not match any of the local sets on the hub site, PE router would increase the range in chunks (as determined by configured increments) until the CE-ID falls under one of the set. This set is then activated. The PE routers at the spoke site on the other hand would discard the advertisement if the received CE-ID did not match any of the local set. In case of full-mesh VPN topologies, PE router processes the out-of- scope advertisements like a hub PE router. In this model, range is elastic (up to a point) for hub and full mesh PE routers while stricter for spoke PE routers. 6.0 Conclusion The various models described in this document allow PE routers to allocate resources on a pay as you go basis. As and when newer sites are added to the VPN, the existing PE routers may or may not have to allocate additional resources based on whether the newer site falls under the already allocated resources. When needed, resources are allocated in small chunks rather than one big chunk. However, there is a tradeoff between the over-provisioning and scalability. In worst-case scenario, when the increments are of size one, a greater number of VPN information sets are exchanged between the PE routers but then over-provisioning is null. There is a Shah Informational - Expires September 2001 5 Internet Draft draft-shah-mpls-l2vpn-reduce-00.txt March 2001 balance that a service provider can choose, having given all the options. 7.0 Acknowledgements Author would like to thank Xavier Briard and Bill Townsend for reviewing the draft. 8.0 References [MPLS] Kompella et al., "MPLS based Layer 2 VPNs", draft-kompella- mpls-l2vpn-02.txt, November 2000. [MPLS-shah] Shah et al., "Extensions to MPLS based Layer 2 VPNs", draft-shah-l2vpn-ext-00.txt, March 2001 Author's Address Himanshu Shah Tenor Networks 100 Nagog Park Acton, MA 01720 hshah@tenornetworks.com Shah Informational - Expires September 2001 6