Network Working Group                                                
   Internet Draft                                                G Bhat 
   Expires: January 2005                                         Cosine 
                                                         Communications 
                                                            August 2004 
    
    
                    Per VPN Routing for Layer 3 PPVPNs 
                 <draft-bhat-l3vpn-per-vpn-routing-00.txt> 
    
    
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 
    
 
 
<Bhat>                 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 
 
 
<Bhat>                 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].  
    

 
 
<Bhat>                 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 
 
 
<Bhat>                 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 
 
 
<Bhat>                 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  
    
    

 
 
<Bhat>                 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. 
    

 
 
<Bhat>                 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." 
    
    






































 
 
<Bhat>                 Expires - February 2005               [Page 8]