Provider Provisioned VPN WG Ananth Nagarajan Internet Draft Consultant draft-ietf-l3vpn-as-vr-00.txt Category: Informational Expiration Date: January 2004 Junichi Sumimoto Muneyoshi Suzuki NTT Corporation Paul Knight Nortel Networks Benson Schliesser SAVVIS Communications July 2003 Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. 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. Abstract This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) [Page 1] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. Table of Contents 1. Introduction .................................... 3 2. SP Provisioning Model ........................... 4 2.1. Auto Discovery .................................. 4 3. Supported Topology and Traffic Types ............ 5 4. Isolated Exchange of Routing and Data Information ................................ 5 4.1. Isolation of Routing Information (constrained distribution of reachability information) ....... 6 4.2. Isolation of data ............................... 7 5. Access Control and Authentication ............... 7 6. Security ........................................ 8 6.1. Protection of User Data ......................... 8 6.2. SP Security Measures ............................ 8 7. Addressing ...................................... 9 8. Interoperability and Interworking ............... 10 9. Network Access .................................. 10 9.1. Physical and Link Layer Topology ................ 10 9.2. Temporary Access ................................ 10 9.3. Access Connectivity ............................. 10 10. Service Access .................................. 11 10.1. Internet Access ................................. 11 10.2. Hosting, ASP, other services .................... 11 11. SP Routing ...................................... 11 11.1. Core Router Awareness of Mechanisms Used ........ 12 12. Migration Impacts ............................... 13 13. Scalability ..................................... 14 14. QoS/SLA ......................................... 15 15. SLA Monitoring .................................. 16 16. Management ...................................... 16 16.1. SP Management of Customer Site .................. 16 16.2. Customer Management of VR ........................ 17 16.3. SP Network Management ............................ 17 17. Security Considerations ......................... 18 18. Acknowledgments ................................. 18 19. References ....................................... 18 19.1. Normative References ............................ 18 19.2. Informative References .......................... 18 20. Authors' Addresses .............................. 19 21. Full Copyright Statement ........................ 20 [Page 2] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 1. Introduction The virtual router concept for L3 PPVPNs was first introduced in [COREVPN]. This was generalized in [PPVPNVR]. A number of autodiscovery mechanisms can be used with this approach to L3 PPVPNs, and [COREVPN] represents one such approach using IP multicast. Based on the taxonomy of PPVPNs described in [FRAMEWORK], Virtual Router based approaches are classified as PE-based Layer 3 PPVPNs. VR-based PPVPNs are used in the following situations: - The customer wishes to outsource the maintenance and management of inter-site VPN connectivity to the Service Provider (SP). - The SP desires to provide VPN service without upgrading its core network to support any specific technology (e.g., MPLS), i.e., the SP wants to provide a Layer 3 VPN service over a range of core network technologies, including existing IP routed or Layer 2 switched core networks, MPLS, or a combination of these technologies. - The customer is not aware of the topology or mechanisms used in the SP core network and is responsible for routing between customer routers, which is independent of the routing used in the SP core. Only the customer-facing sides of the PE devices in the SP network are visible to the customer. - The customer wishes to exercise control of routing functions at the CE routers at each of its VPN sites, while depending on the SP to provide transport for data traffic and for the customers routing information across the SP core. From the viewpoint of any of the customers routers, there will usually appear to be a single router hop to any other VPN site. The only routes exchanged between the CE routers and the PE devices are the customers internal routes (with the possible addition of routes desired by the customer for Internet access via the SP, such as a default route). - The customer sends IP traffic across the VPN, possibly including non-IP traffic encapsulated in IP by the customer. - The VPN service provider does not own a backbone network but wishes to provide PPVPN services over a backbone obtained from some other provider. - Several cooperating SPs desire to offer PPVPN service at points that span multiple administrataive domains of the backbone, perhaps over the public Internet. [Page 3] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 This document describes how Virtual Router based approaches satisfy key requirements and metrics identified in the PPVPN Applicability Statements Guideline document [ASGUIDE]. These requirements are a subset of the requirements listed in the PPVPN Service Requirements document [REQTS]. This document is based on the guidelines specified in [ASGUIDE]. 2. SP Provisioning Model Virtual Routers (VRs) can interact with other routers so as to be indistinguishable from an individual physical router. However, multiple instances of VRs can be configured within a single physical device, providing a significant improvement in manageability and provisioning flexibility, compared with multiple physical routers. Each VR can maintain its own separate routing tables, so if two virtual routers are in the same physical router, an interaction of one VR with one of its peers does not have any effect on the interaction of another VR with any of its own peers. In some implementations, VRs may share physical interface bandwidth. VPNs are constructed via tunnels connecting VR pairs across the service provider backbone network. Per-VR routing protocol instantiations are run to distribute VPN reachability information. VPN membership information distribution is treated separately, and is achieved via sharing a VPN-ID, for example [RFC2685], between VRs that are members of a specific VPN. The detailed VR model is described in [PPVPNVR]. 2.1. Auto Discovery In the VR-based PPVPNS, various auto discovery mechanisms are supported. VPN discovery can be achieved through directory servers [RADIUS-DISC], explicit configuration via a management platform, using multicast [COREVPN] or by piggybacking VPN membership and topology information via routing protocols such as BGP [VPN-BGP]. A combination of these mechanisms may also be used on a PE. For example, for some VPNs topology discovery is done only through a management platform. For others, dynamic topology discovery is achieved using existing routing protocol. BGP-based auto-discovery is described in [VPN-BGP], and may be used for membership and topology discovery. It is important to note that, for the VR architecture, the auto- [Page 4] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 discovery mechanism is only used to automatically exchange control VPN information between VRs. It is not intended for interchange of the VPN routing information, which is accomplished by standard routing protocols running between the VRs, as discussed in [PPVPNVR]. 3. Supported Topology and Traffic Types VR-based PPVPNs can be constructed using either MPLS or IP tunnels (GRE, IP-in-IP, L2TP, IPSec) in the core network, or Layer 2 connections such as ATM or Frame Relay. The choice of the tunneling mechanism may impact other properties of the VPN itself, including scalability, manageability, QoS, security, etc. For example, the use of IPSec tunnels for encryption may impact forwarding performance on some devices, and therefore impact the number of sites or routes per VPN, the number of VPNs per PE, etc. The performance of IPSec tunnels may be improved through the use of dedicated hardware, which allows greater performance and scaling but potentially at increased cost. Tunnels are created on a per-VPN basis. For transport across the network, a number of these tunnels may be aggregated and carried within a PE-PE tunnel. The SP has a high degree of flexibility in configuring the topology of a VPN interconnecting customer sites. The topology can be full-mesh, partial-mesh, or any arbitrary topology that has been agreed to by the customer and the SP. 4. Isolated exchange of routing and data information By definition of a Virtual Private Network, the details of its addressing, topology, connectivity, and reachability as well as the data that it transports are implicitly considered to be private, and should therefore be isolated from other networks, including others that may be supported with the PPVPN infrastructure. [FRAMEWORK] [Page 5] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 4.1. Isolation of routing information (constrained distribution of reachability information) In any PPVPN, the SP is responsible for maintaining isolation between networks except as explicitly intended by the VPN owner. The VR model of PPVPNs provides for isolation by instantiating multiple Virtual Routers (VR) on a single physical platform to support multiple VPNs. [PPVPNVR] Each VR has its own logical interfaces, routing tables, forwarding tables, and routing protocol instances. Note that a VR may share physical interfaces with other VRs, depending on the implementation and specific topology. This provides for isolated topology, addressing, and reachability for the VPN. Addressing and Reachability includes the assignment, discovery, and distribution of source and/or destination information for the PPVPN. The isolation of this information implies that other networks, including other VPNs and the Internet, will have no visibility into the PPVPN except as explicitly configured. Routing information carried between VRs is carried in through the same tunnels as data itself, and is therefore segregated from the underlying backbone infrastructure by the same mechanisms that segregate data between VPNs. This model supports arbitrary routing architectures, including support for back-door links among customer VPN sites or other potentially unique routing architecture requirements. The support for arbitrary routing architectures, however, is accompanied by scalability and management issues. These issues are discussed later in this document. In the VR approach, virtual routers are connected to the CEs through local links, and to each other across the backbone through tunneling services provided by the service provider across the backbone. All data traffic within the VR-based VPN is isolated from non-VPN traffic by these mechanisms. Some VR implementations may provide the ability for customers to exercise limited management operations upon the VRs which are connected to the customer CEs. This may allow the customer to view routing tables, or traffic statistics, or to exercise some control over the customers routing. VRs MUST NOT allow any customer to circumvent the isolation of routing or data among VPNs. [Page 6] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 4.2. Isolation of data Data for different VPNs in the VR model is segregated through the use of different link-layer connections or tunnels over a common SP backbone. [PPVPNVR] Examples of such tunnels include GRE, L2TP, IPSec, MPLS or Layer 2 connections such as ATM or Frame Relay. It should be noted that this isolation can be impacted by misconfiguration. 5. Access Control and Authentication CE-PE authentication has not been specified for VR-based VPNs. PE/CE mutual authentication may be done via any mechanism supported by the routing protocol in which the CE and PE are peers (e.g., use of the TCP MD5 authentication when the CE/PE protocol is BGP), or by any other mechanism that may be desired by the customer. In order for VR-based PPVPNs to support confidentiality, integrity, authentication, and replay attack prevention, mechanisms such as IPsec may be used as tunneling mechanism or used over VPN tunnels. Even with the use of IPsec, the security level offered is dependent on the scope of the IPsec security associations: encrypting on a CE- to-CE basis (as in CE-based VPNs) will offer a wider scope of protection than only encrypting on a PE-to-PE basis (as in PE-based VPNs), since the CE-PE link remains unencrypted in the latter case. However, PE-PE IPsec offers substantial advantages in efficiency, outsourcing, and integration with the dynamic membership and dynamic routing nature of the PPVPN. CE-PE IPsec can also be used to protect traffic on the CE-PE section of the network. In this case the traffic is only unprotected by IPsec within the PE device. Policy- based security and access control mechanisms or firewalls may be used between sites in the same VPN. These can be implemented on the PE router, or on the CE. [Page 7] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 6. Security 6.1. Protection of user data As described above, end-to-end (CE-to-CE) IPSec may be used to protect user data. SPs may choose to provide CE-based IPSec as a value added service. If the SP core network is also part of the public Internet, the SP may choose to provide PE-to-PE IPSec as the tunneling mechanism between VRs. If inter-SP VPNs are to be provided, IPSec tunnels may be used. The impact on QoS and SLAs in this case will have to be studied. In general, user data is protected via the inherent isolation provided by the inter-VR tunnels. Varying levels of security of user data may be provided based on the type of tunnel that is used. 6.2. SP Security Measures In general, the SP should ensure that non-VPN traffic does not accidentally or maliciously enter a VPN. Since VRs can be configured very specifically for a customer, the SP can offer customers anti- spoofing or other traffic or route filtering services tailored for the customers network. The SP's PE and P devices should be protected against intrusion or denial of service attacks. This is especially important because the SP core network may be used to provide general Internet services apart from VPN services. Therefore any Denial of Service attack or misconfiguration that impacts other VPN services and Internet services should be prevented. Since most of the traffic from CE to PE, apart from control (routing and network management) traffic, gets encapsulated to be carried across the SP network, the possibility of users sending traffic to other (non-PE) systems in the core network is minimized or eliminated. The inherent isolation of VR mechanisms helps provide this protection against attacks from customer sites, but additional specific measures are available: - VR routing sessions can be authenticated between the PE and CE, and among PEs. - If BGP is used as an auto-discovery mechanism between VRs, it should be further authenticated using mechanisms such as TCP MD5. - Filtering of any management data entering the PE should be [Page 8] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 performed in order to prevent the acceptance of unauthorized packets from customers or other SPs into that PE. Denial of Service attacks may occur via routing traffic or network management traffic, either intentionally or accidentally via routing instabilities or misconfigurations in the VPN. With Virtual router VPNs, in many cases a dynamic routing protocol will be run between CE routers and VRs within PE routers. Either the same or a different dynamic routing protocol may be run between VR instances in each PE associated with a VPN. If routing is unstable in the private network, it is possible for this instability to propagated to the PE routers. For example, in some cases a large number of routing updates could be sent from the CE router to a VR within a PE router, or between VR instances in different PE routers. This could potentially place a major or excessive processing load on the PE routers. This issue can be mitigated via resource partitioning in the PE, in order to limit the amount of resources (e.g., CPU and memory) which any one VR is permitted to use in PE routers. Also, rate limits may be applied to the routing traffic sent from the CE to the PE. Alternately, when this problem is detected on the CE to PE link, the CE to PE interface may be shut down. In order to prevent DoS attacks due to network management traffic, the functions available to the customer need to be strictly controlled. It may also be useful to limit the resource use of this capability. Resource partitioning may be appropriate internal to PE routers, and network management traffic from the CE to the PE may be rate limited (for example,to prevent network management traffic from CE to PE to be used in a DOS attack). 7. Addressing Virtual routers may provide any or all of the services which are provided by a physical router, including Network Address Translation (NAT), packet filtering, etc. These VR capabilities can simplify the process of joining previously independent site networks, which may have overlapping address spaces. NAT can be used to satisfy intra- VPN non-unique addressing requirements. This facilitates the construction of short-term or ad-hoc VPNS. It should be noted, however, that NAT has accompanying scaling problems, and other mechanisms are needed to ensure proper routing updates, when two sites share the same routing domain. Non-unique and private customer addresses may be supported by using encapsulation within the tunneling mechanisms employed between VR pairs (e.g., GRE, IP-in-IP etc.). As such, support for private [Page 9] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 addressing as specified in [RFC1918] allows for non-unique addresses between different VPNs. 8. Interoperability and Interworking Interoperability and Interworking of VR-based VPNs with other L3 PPVPN mechanisms such as 2547bis is for further study. Since VRs provide all IP router functionalities, various VR-based solutions interwork and interoperate to the extent that IP networks interoperate and interwork. 9. Network Access 9.1. Physical and Link Layer Topology VR-based mechanisms do not affect the choice of physical and link layer technologies or topologies. 9.2. Temporary Access Temporary access for a dial-up user to a VR can be provided via PPP and AAA, using a Remote Access Server. Other access mechanisms such as IPSec can also be used. Thus, it is possible provide login and password based access to a VR-based VPN from an authorized user connected to the Internet. 9.3. Access Connectivity Multi-homing of CEs to multiple VRs (within the same or different PEs) is supported. The PEs (and consequently the VRs) may belong to different SPs. Load sharing based on IGP or other traffic engineering mechanisms used in the SP core are naturally supported by VR-based VPNs. [Page 10] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 10. Service Access 10.1. Internet Access Simultaneous VPN and Internet Access can be supported via various mechanisms. A specific VR may be assigned as a default VR that is connected to the Internet. If a single VR is to be used to carry a customer's VPN as well as Internet traffic, Internet traffic can be distinguished from VPN traffic by associating a default VPN-ID with Internet traffic and pointing it to a default route to the Internet. This default route to the Internet need not be direct, but may instead point to a firewall or other security device which may use different interfaces for VPN access and Internet access. 10.2. Hosting, ASP, other services All of the above "external" services can be supported by associating a separate address for every service that is not being used within the VPN. If a single server (for example, a web hosting server) is used to provide a particular service to all VPNs, NAT may be used to provide a unique address for clients to access that particular service. NAT can be performed either at the customer site or can be integrated into the PE. The scaling impacts of adding NAT to the PE will have to be considered. 11. SP Routing VR-based PPVPNs do not impose any additional requirements on the IGP used in the service provider core network. However, if the customer VPN runs an IGP, the VRs (and consequently the PEs) must support that IGP. This customer IGP need not be the same as the IGP running in the Service Provider's core network. >From the customers viewpoint of its VPN IGP routing topology (if it uses one), the SPs network topology appears much simpler than it may actually be. Depending on the VR implementation, the SPs service offering, and the SPs physical topology, it may appear as either a single large router with interfaces for each VPN site, as a full mesh, with two routers between any two sites, as a hub-and spoke topology (when the customer wants all inter-site traffic to pass through one or more specific sites, for application of services such as security filtering), or other arbitrary topology. In general, the SP's actual core routing topology is invisible to the customer. [Page 11] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 Fault handling is a specific problem when the timers used for the VR- to-VR routing peering are shorter than the timers used for the routing peering within the service provider(s) network. In this case a single failure within a service provider network may look like a collection of un-correlated failures in the VPN. Moreover, since a VR doesn't really "know" what causes the failure, the VR may react to such a failure by re-routing along some other tunnel, while this other tunnel may be also affected by the same failure. As a result, this would slow down routing convergence within the VPN. To avoid the problems mentioned above one may consider making the timers used for the VR-to-VR peering longer than the timers used for the routing peering within the service provider network (so that failures within the service provider network would be "invisible" to the VR-VR tunnels). But that has its own set of problems. While this may be possible to accomplish within a single routing domain (one needs to appropriately set the IGP timers within the domain), doing this in a network that includes more than one routing domain may be difficult (as timers include both IGP and BGP timers, and moreover, timers include IGP timers in several routing domains). Another consequence of making the timers used for the VR-to-VR peering over the tunnels longer than the timers used for the routing peering within the service provider network is that it would increase the amount of traffic that will be "black holed" in the case of VR failures. A key aspect of the issue here is that layer 3 problems in the SP network may appear as layer 2 problems in the VPN. Thus stability of the SP network, with an emphasis on quick recovery, is a key element in delivering satisfactory service. Prevention of Denial of Service attacks caused by routing instabilities has been discussed in Section 6.2. 11.1. Core router awareness of mechanisms used Since tunnels are established between VR pairs, the core router (P router) does not have any information of the mechanisms used to construct the VPN. If MPLS is the tunneling mechanism that is used between the VRs, the core routers may have to be MPLS enabled in order to leverage the benefits of MPLS tunnels (e.g., traffic engineering). As such, while the core routers are not aware of VPN- specific information, they should support requirements to meet [Page 12] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 relevant SLAs. (e.g., for guaranteed QoS, the core routers may need to support appropriate QoS mechanisms). 12. Migration impacts Similar to other Layer 3 PPVPN architectures, any CE using services provided using the VR approach can access a PE similar to the way it would access another CE router in a private network using leased lines. As the VR approach makes use of standard routing protocols without any extensions, there is no requirement for additional capabilities on the part of CEs in order to interoperate with a VR- based PPVPN. Key design considerations include: - The PEs will introduce extra router hops - If the VR-VR backbone routing protocol differs from the sites, then IGP metric implications should be carefully evaluated. This would be particularly true for multihomed VPN sites. In general, a VR-based PPVPN offers the customer a greatly simplified network topology compared to a customer-managed private network, since each CE router sees a single link as the next-hop route to all other VPN sites. There is no need to configure multiple physical or logical interfaces on the CE routers. Multi-homed VPN sites or sites with back-door connections will involve design decisions as to whether each of the multiple links should operate as a backup link or as a load-sharing link. Also, since the VR approach does not depend on the backbone architecture in terms of routing protocols, a VR-based L3 PPVPN can be offered on a service provider core network without the need for specific core technologies. For example, the core network does not need specific mechanisms like MPLS to be implemented on the P routers. Similarly, if the core network is a Layer 2 network based on ATM or Frame Relay, VR-based VPNs can still be constructed. It should be noted, however, that core network mechanisms would determine the overall properties and services that may be provided over the VPN. For example, in order to support customer QoS SLAs, the core network should be robustly engineered or should support QoS mechanisms, in addition to SLA marking at the PE. [Page 13] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 Thus, while migration impacts in the case of basic VPN functionality using VR are minimal from the customers' or providers' point of view, appropriate core mechanisms may be necessary for certain services. 13. Scalability PE-based PPVPNs have better scalability than CE-based PPVPNs, because the total number of VPN tunnels that need to be managed are far fewer in the service provider backbone, than between CEs. Addition of a new CE in a CE-based PPVPN would require O(N^2) tunnels to be set up where N represents the total number of CEs. In comparison, addition of a new CE for a specific customer, in the case of a PE-based PPVPN, would simply require an additional connection between the new CE and the PE, because inter-PE tunnels already exist per VPN. VR is a technology for implementing logical routing instances in a PE device. A PE device may contain more than one VR and a VR supports one VPN. Therefore, scalability of a VR and conventional physical router are basically the same, e.g., if different routing protocols are used for customer and network sides of a VR or physical router, the load is increased compared with the case when the same protocols are used. The major factor contributing to scalability constraint in the VR approach is the number of VRs which can be supported by a PE. This is because, the number of VRs in a PE device is equal to the number of VPNs which are supported by the PE. Resources used by a VR instance include memory and processor resources, used to support VPN tunnel mechanisms, routing protocol instances, route tables, interface management, etc. The extent to which these resources are utilized impact scalability. Much of the resource utilization for a given VPN will be affected by the topology of the VPN. For instance, a VPN with a full-mesh topology will require that VRs have more peers for the VPN tunneling mechanism, for routing protocol adjacencies, for security protocols, etc., while a hub-and-spoke model will constrain the resources required for 'spoke' PE routers. >From a VR perspective, scalability also depends on whether the same routing protocols are used between VRs as in the backbone network. If the inter-VR routing protocols are different from the backbone IGP, the scaling and management impacts for configuring routing protocols on a per-VR basis may be significant. For example, it may be necessary to maintain OSPF databases for the entire customer VPN topology, as opposed to maintaining information for only directly [Page 14] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 connected customer sites. Additionally, the customer IGP may need to maintain information about the entire VR topology, for the VRs which are connected to the customer's CEs. Other concerns include routing loop avoidance, route redistribution, etc. Thus, while the VR model allows the routing protocols between customers and VRs to be different than the backbone IGP, this flexibility can be accompanied by scalability concerns. Mechanisms such as OSPF areas may be used to circumvent such scaling issues. It is normal in many cases for a VR located in a PE router to run a routing instance with each other VR which is part of the same VPN. In some cases this could result in a large number of routing adjacencies. The number of routing adjacencies could aggravate the impact of instability in routing in the private network, or aggravate the impact of routing protocol DOS attack described in Section 6.2. As mentioned in Section 6.2, this can be mitigated by appropriate resource partitioning in the PE, and by rate limiting of routing packets,including packets from CE to PE and well as packets from PE to PE. Also, while this consideration may limit the number of VRs which may potentially be supported from a single PE device, it does not have any significant effect on the overall scaling of a network implementing the VR approach. 14. QoS/SLA VR-based PPVPNs support any kind of QoS that the core network and the tunneling mechanism used support. VR-based VPNs can utilize different quality of service mechanisms. QoS mechanisms developed for physical routers can be used with VRs, on a per-VR basis. e.g. classification, policing, drop policies, traffic shaping and scheduling/bandwidth reservation. The architecture allows separate quality of service engineering of the VPNs and the backbone. However, the tunneling mechanisms themselves should support relevant QoS mechanisms. [Page 15] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 15. SLA Monitoring VR-based VPNs can implement a variety of methods to monitor compliance with Service Level Agreements. Since the links between VRs make use of tunnels across the underlying backbone network, the SLA monitoring capabilities of the backbone network can be used to monitor the performance of the inter-VR links. Because the inter-VR links are tunnels, and the SLA monitoring capabilities of the backbone network may not include "per tunnel" monitoring capabilities, some VR implementations support additional SLA monitoring mechanisms. Performance to SLA requirements within the PEs hosting the VRs is typically monitored via internal processes to ensure compliance from end to end. In addition, either the service provider or the VPN customer can use all existing SLA tracking tools (round trip time measurement, traceroute mapping, etc.) within the VR-based VPN. 16. Management 16.1. SP Management of customer site The SP may choose to manage the customer site (i.e., the CE devices) for added revenue. If the SP uses a centralized customer management system, care should be taken to uniquely identify various CEs belonging to different VPNs, so that CE devices from different VPNs do not reach each other. The customer may desire to have access to the PE device for monitoring purposes (e.g., ping, traceroute). Providing such access is at the discretion of the SP. Traffic statistics in order to prove SLAs to customers may be provided on a periodic basis. Other statistics that can show enhanced SP capabilities, including protection against Denial of Service attacks, failure etc., can be provided to the customer. [Page 16] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 16.2. Customer Management of VR Some VR implementations may provide the ability for customers to exercise limited management operations upon the VRs which are connected to the customer CEs. This may allow the customer to view routing tables, or traffic statistics, or to exercise some control over the customers routing. Customer network management and troubleshooting systems will generally have less ability to gather information from the VRs than from the customers own routers, and will also have little or no ability to directly change VR configurations. The customers systems should be planned so as to accommodate the restricted capabilities of the VRs to respond to customer network management processes. Prevention of Denial of Service attacks due to network management traffic originating from customer management of the VR has been discussed in Section 6.2. 16.3. SP Network Management When an SP provides VR-based VPN services, it is highly likely that the PE devices used are complex because of the number of VRs supported, the number of routing adjacencies between VR pairs, maintenance of tunnel and VPN-specific information and possibly other information such as QoS. Thus the management of the PE is extremely critical for the SP. If the SP core is also used to provide Internet services, adequate mechanisms should be in place in order to not allow misconfigurations or instabilities in the PE control plane to affect the general Internet operations or impact other VPN customers. In addition to normal SP network management, prevention of Denial of Service attacks must be in place in the PEs. Resource partitioning and rate limiting, as described in Section 6.2 are examples of such mechanisms. [Page 17] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 17. Security considerations There are no additional security considerations besides those already addressed in the document in Section 6. 18. Acknowledgments The authors of this draft would like to acknowledge the suggestions and comments received from the entire Layer 3 Applicability Statement Design Team formed in the PPVPN working group. Besides the authors, the members of the design team include Marco Carugi, Eric Rosen, Jeremy De Clercq, Luyuan Fang, Dave McDysan, Cliff Wang, Olivier Paridaens, Tom Nadeau, Yakov Rekhter and Rick Wilder. Thanks are also due to the authors of [PPVPNVR], especially Hamid Ould-Brahim. Many thanks are due to the constructive comments made by Ross Callon and Mark Duffy. 19. REFERENCES 19.1. Normative References [PPVPNVR] Ould-Brahim, H., et al., "Network based IP VPN Architecture using Virtual Routers", work in progress. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 19.2. Informative References [ASGUIDE] Sumimoto, J., et al., "Guidelines of Applicability Statements for PPVPNs," work in progress. [FRAMEWORK] R. Callon, et al., "A Framework for Layer 3 Provider Provisioned Virtual Private Networks," work in progress. [REQTS] McDysan, D., et al., "Service requirements for Layer 3 Provider Provisioned Virtual Private Networks", work in progress. [Page 18] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 [RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [RFC1918] Rekhter, Y. et al., "Address Allocation for Private Internets," RFC 1918, February 1996. [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [COREVPN] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN Architecture", work in progress. [RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. [VPN-BGP] Ould-Brahim, H., et al, "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", work in progress. [RADIUS-DISC] Heinanen J., "Using Radius for PE-Based VPN Discovery", work in progress. 20. Authors' Addresses Ananth Nagarajan Consultant E-mail: ananth@maoz.com Muneyoshi Suzuki Junichi Sumimoto NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Email: sumimoto.junichi@lab.ntt.co.jp Paul Knight Nortel Networks 600 Technology Park Drive Billerica, MA 01821 E-mail: paknight@nortelnetworks.com Benson Schliesser SAVVIS Communications 717 Office Parkway St. Louis, MO 63141 Phone: +1-314-468-7036 Email: bensons@savvis.net [Page 19] Internet Draft draft-ietf-l3vpn-as-vr-00.txt Jul 2003 21. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. [Page 20]