Network Working Group Internet Draft G Bhat Expires: January 2005 Cosine Communications August 2004 Per VPN Routing for Layer 3 PPVPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 describes a method to do Per VPN routing for L3 PPVPNs. The solution uses BGP for auto-discovery of VPN membership, but uses Per VPN RIP instances and dynamic MPLS tunnel interfaces to exchange customer routes. The document proposes modifications to the RIP protocol to the make the solution scalable. The framework presented also supports deployment of multicast routing and forwarding for L3 PPVPNs without enabling multicast in the core. Conventions used in this document 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 RFC-2119 [2]. Table of Contents Expires - February 2005 [Page 1] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 1. Introduction...................................................2 2. Per VPN Routing Solution.......................................3 2.1 MPLS Tunnel Interface......................................3 2.2 Routing over Tunnel Interfaces.............................4 2.3 Data Forwarding............................................4 2.4 Multicast over Tunnel Interfaces...........................4 3. Addressing Scalability.........................................5 Security Considerations...........................................6 Normative References..............................................6 Author's Addresses................................................7 Intellectual Property Notice......................................7 Full Copyright Statement..........................................7 1. Introduction [VPN-2547bis] provides a framework to implement network-based layer 3 VPNs using BGP as the aggregated routing protocol. The framework however has several drawbacks that are listed below. - Typical BGP deployments use route-reflectors. Aggregated routing using BGP means that the route-reflectors need to store all customer routes. This leads to scalability issues when there are a large number of VPNs. - Route-reflectors and PE routers also need to carry Internet routes. With the Internet routing tables still growing, storing both Internet and VPN routes on one router again leads to scalability issues. An additional concern is that disturbances in VPN routing may affect Internet routing and vice-versa. One could potentially get around these problems by using a network design that separates Internet routing from VPN routing, but that will likely result in a significant increase in complexity as well as cost of deployment. - BGP is designed for scalability and stability, but not for fast convergence. Changes are not propagated by BGP routers immediately, but are batched and sent together. Some BGP implementations use the BGP scanner processes for next-hop validation and for importing routes to VRFs. All these features have an adverse impact on the convergence of VPN routing. BGP scan interval can be reduced to improve convergence, but that increases the load on the CPU. - Multicast routing does not fit easily into this framework. The method proposed in [MCAST-VPN] restricts the protocol used in the customer network to PIM and requires significant changes to PIM implementation on the PE. In addition, it requires deployment of multicast and storing Per VPN state in the core routers. There is also an extra-overhead in the forwarding Expires - February 2005 [Page 2] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 plane because of the GRE encapsulation of data packets in the core. MPLS-based L2 VPN solutions can be used to address some of the issues listed above. But the benefits of using a network-based L3 VPN solution, namely deployment of network-based services like firewalls, stateful packet filters and NAT, are lost using the L2 VPN approach. This document presents a PPVPN solution that addresses all the above issues. The solution presented builds on the framework provided in [VPN-2547bis]. It uses the mechanisms provided in [VPN-2547bis] for auto-discovery of all the VRFs belong a VPN and to setup LSPs connecting VRFs. But instead of aggregate routing based on BGP to exchange customer routes, this solution employs Per VPN routing. In a Per VPN routing approach, routing protocols are run over the MPLS LSPs to exchange customer routes. To facilitate running of routing protocols over LSPs, the solution relies on creating MPLS tunnel interfaces at the PE routers. To make the solution scalable, a modified version of RIP is recommended as the routing protocol. Details of the approach are presented below. 2. Per VPN Routing Solution It is assumed that the provider network is configured to exchange routes and data using [VPN-2547bis]. Per VPN routing (PVR) is enabled on a VRF through configuration. Each PVR enabled VRF must be configured with an MPLS tunnel endpoint address. It is preferable to use the address of a loopback interface associated with the VRF for this purpose. Each PVR enabled VRF must announce only the MPLS tunnel endpoint address using [VPN-2547bis] (no customer routes must be announced). Note that for this solution to work, all VRFs belonging to the VPN must have Per VPN routing enabled. 2.1 MPLS Tunnel Interface Assume VRF x and VRF y are two PVR enabled VRFs that belong to the same VPN in PE routers A and B respectively. Let X and Y be the respective MPLS tunnel endpoint addresses on the two VRFs. When PE router A receives VPN route Y from PE router B, it creates a dynamic unnumbered MPLS tunnel interface Ty with destination Y and associates it with VRF x. Similarly, router B creates a dynamic tunnel interface Tx associated with VRF y when it receives VPN route X. The tunnel interface uses the label-stack associated with tunnel destination route to send packets. So any packet sent out of tunnel interface Ty on PE router A is sent to VRF y exactly the same way as any data packet would be sent to VRF y using [VPN-2547bis]. Expires - February 2005 [Page 3] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 PE router A treats any labeled packet destined to VRF x with a source IP address that matches the tunnel destination (Y in this case) as having arrived on the tunnel interface Ty. To ensure that routing control packets sent over the tunnel interface at a PE router are received on the corresponding tunnel interface at the remote PE router, the sender must set the source IP address on the routing protocol control packets to the MPLS tunnel endpoint address configured on the VRF. In the earlier example, whenever VRF y sends routing control packets to VRF x over tunnel Tx, it sets the source of the packets to Y. 2.2 Routing over Tunnel Interfaces After the MPLS tunnel interface is setup, routing information can be exchanged over the tunnel using the method described in the previous section. As far as the routing protocol is concerned the tunnel interface appears as any other unnumbered point-to-point link. Adjacencies can thus be formed and routes exchanged over the tunnel interface. Scalability issues arising from having a large number of protocol instances on the PE-router dictate the choice of routing protocol used. The RIP protocol with some simple modifications happens to be ideally suited for this purpose. Section 3 discusses this in more detail. 2.3 Data Forwarding The routes learnt through the routing protocols over the tunnel interface have the outgoing interface set to the tunnel interface. Packets sent to these destinations are sent out with a 2-label stack exactly as in [VPN-2547bis]. However, when VPN data traffic is received on the PE router, the router needs to do two lookups for each packet to determine how to forward the packet. The first lookup is on the MPLS label, the second is on the destination IP address. It is required that the receiving router support two-stage lookup in hardware for this solution to be practical. Several vendor implementations of [VPN-2547bis] already use two-stage lookups to support distribution of one label per VRF (instead of one label per route). 2.4 Multicast over Tunnel Interfaces Just like unicast routing protocols, any multicast protocol (PIM-SM, PIM-DM, DVMRP or MOSPF) can be enabled on the MPLS tunnel interfaces. Multicast routing information can thus be exchanged across the core without multicast being enabled on any of the P-routers. When compared with the solution in [MCAST-VPN] there may some extra overhead in the forwarding plane due to the overlay approach. But Expires - February 2005 [Page 4] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 this lack of optimality is offset by the simplicity of the model and by the use of MPLS encapsulation instead of GRE encapsulation for multicast data traffic. 3. Addressing Scalability As mentioned earlier, the biggest concern with using a Per VPN routing solution is the large number of instances of the routing protocol on the PE-router. With a link-state protocol like OSPF, the large number of decision processes on the PE router along with the large number of different link-state databases makes the solution impractical. Compared to OSPF, RIP is much simpler and consumes very little resources on the router. But RIP has a few problems of its own which are listed below. 1. RIP requires that the entire routing table be sent to all neighbors every 30 seconds. This is a big overhead on the core network when compared with aggregate routing using BGP where updates are sent only when there are changes in the routing table. 2. Routing updates received on one tunnel are propagated across all the other tunnel interfaces. When compared with aggregate routing using BGP, this again is extra control traffic going across the core (By design BGP routers do not propagate routes learnt over one IBGP session to another IBGP session). This also can lead to count-to-infinity problems and slow convergence when PE-routers crash. However, both problems can be solved with some modifications to RIP. Problem 2 can be solved by simply making RIP emulate BGP. In other words, RIP can be modified so that routing updates received over a MPLS tunnel interface are propagated to non-tunnel interfaces only. Problem 1 however requires a more careful consideration. In normal RIP processing, periodic updates are used to detect whether the neighbor or the link to the neighbor is down. Since RIP runs over UDP and does not use acknowledgements, periodic updates are the only mechanism to handle lost updates. In the PPVPN scenario, neighbor liveness can be detected from the status of the route to the tunnel destination. If the remote PE router crashes for any reason, the route to the MPLS tunnel destination will be deleted and tunnel will be brought down. Periodic updates are therefore not required to detect neighbor liveness. They can be eliminated altogether if some mechanism can be devised to deliver routing updates reliably. [RFC1582] describes exactly such a mechanism. This RFC, originally proposed for running RIP over demand circuits, actually describes all the extensions to RIP required to make it work without periodic Expires - February 2005 [Page 5] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 updates. Implementing this RFC should therefore directly address problem 1 (some vendor implementations of RIP already support this RFC). Some routing implementations may have RIP as a separate process. For these implementations, there is no way to know that the neighbor is down if the remote RIP process crashes. In these cases, the MPLS tunnel endpoints from a VRF must be announced using [VPN-2547bis] only if the corresponding RIP instance is alive. If the RIP instance crashes, the tunnel endpoint route must be withdrawn. It is clear that with the above modifications, the amount of processing at the PE router using Per VPN RIP routing will be comparable to that with BGP aggregate routing. RIP by design uses minimal data structures, so impact on the PE router in terms of memory usage should be minimal. Routing convergence also should be significantly faster with this approach. Security Considerations De-multiplexing packets based on the source address could be a security concern. In our earlier example, a customer attached to VRX y could spoof RIP packets to VRF x by sending RIP packets with destination set to X and source set to Y. One way to get around this is to enable authentication for the RIP instances on the two VRFs. Another approach would be to do unicast RPF (Reverse Path Forwarding) check on all packets coming from the CE routers. Normative References [VPN-2547bis] "BGP/MPLS VPNs", draft-ietf-l3vpn-VPN-2547bis-01.txt, Rosen, Rekhter, et. al. September 2003 [RFC1582] Meyer, G.,ôRIP over Demand Circuitsö, RFC 1582, 1994. [MCAST-VPN] ôMulticast in MPLS/BGP IP VPNsö, draft-rosen-vpn-mcast- 07.txt, Rosen, Cai, et. al. May 2004 Informative References [L3VPN-framework] ôA Framework for Layer 3 Provider Provisioned Virtual Private Networksö, draft-ietf-l3vpn-framework-00.txt, Callon R., Suzuki M., March 2003 Expires - February 2005 [Page 6] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 Author's Addresses Girish S. Bhat Cosine Communications 1200 Bridge Parkway Redwood City, CA 94065 Email: gbhat@cosinecom.com Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement "Copyright (C) The Internet Society (2004). 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. Expires - February 2005 [Page 7] draft-bhat-l3vpn-per-vpn-routing-00.txt August 2004 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." Expires - February 2005 [Page 8]