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]