[vpn] Options for VPN routing.. (handling sclalability)

Options for VPN routing in the SP

   The following technologies can be used for exchanging VPN routing
   information 

   o Static routing

   o RIP [RFC2453]

   o OSPF [RFC2328]

   o BGP-4 [RFC1771]

VPN forwarding instances (VFIs)

   In layer 3 PE-based VPNs, the PE devices receive unencapsulated IP
   packets from the CE devices, and the PE devices use the IP
   destination addresses in these packets to help make their forwarding
   decisions.  In order to do this properly, the PE devices must obtain
   routing information from the customer networks.  This implies that
   the PE device participates in some manner in the customer network's
   routing.

   In layer 3 PE-based VPNs, a single PE device connected to several CE
   devices that are in the same VPN, and it may also be connected to CE
   devices of different VPNs.  The route which the PE chooses for a
   given IP destination address in a given packet will depend on the VPN
   from which the packet was received.  A PE device must therefore have
   a separate forwarding table for each VPN to which it is attached.  We
   refer to these forwarding tables as "VPN Forwarding Instances"
   (VFIs).A VFI contains routes to locally attached VPN sites, as well as
   routes to remote VPN sites.  

   Routes to local sites may be obtained in several ways.  One way is to
   explicitly configure static routes into the VFI.  This can be useful
   in simple deployments, but it requires that one or more devices in
   the customer's network be configured with static routes (perhaps just
   a default route), so that traffic will be directed from the site to
   the PE device. Another way is to have the PE device be a routing peer of the CE
   device, in a routing algorithm such as RIP, OSPF, or BGP.  Depending
   on the deployment scenario, the PE might need to advertise a large
   number of routes to each CE (e.g., all the routes which the PE
   obtained from remote sites in the CE's VPN), or it might just need to
   advertise a single default route to the CE.

   A PE device uses some resources in proportion to the number of VFIs
   that it has, particularly if a distinct dynamic routing protocol
   instance is associated with each VFI.  A PE device also uses some
   resources in proportion to the total number of routes it supports,
   where the total number of routes includes all the routes in all its
   VFIs, and all the public routes.  These scaling factors will limit
   the number of VPNs which a single PE device can support.

   When dynamic routing is used between a PE and a CE, it is not
   necessarily the case that each VFI is associated with a single
   routing protocol instance.  A single routing protocol instance may
   provide routing information for multiple VFIs, and/or multiple
   routing protocol instances might provide information for a single
   VFI.   

Per-VPN routing

   One option is to operate separate instances of routing protocols
   between the PEs, one instance for each VPN.  When this is done,
   routing protocol packets for each customer network need to be
   tunneled between PEs.  This uses the same tunneling method, and
   optionally the same tunnels, as is used for transporting VPN user
   data traffic between PEs.

   With per-VPN routing, a distinct routing instance corresponding to
   each VPN exists within the corresponding PE device.  VPN-specific
   tunnels are set up between PE devices.  Logically these tunnels
   are between the VFIs which are within the PE devices.  The tunnels
   then used as if they were normal links between normal routers.
   Routing protocols for each VPN operate between VFIs and the routers
   within the customer network.

   This approach establishes, for each VPN, a distinct "control plane"
   operating across the VPN backbone.  There is no sharing of control
   plane by any two VPNs, nor is there any sharing of control plane by
   the VPN routing and the public routing.  With this approach each PE
   device can logically be thought of as consisting of multiple
   independent routers.

   The multiple routing instances within the PE device may be separate
   processes, or may be in the same process with different data
   structures.  Similarly, there may be mechanisms internal to the PE
   devices to partition memory and other resources between routing
   instances.  

   This approach tends to minimize the explicit interactions between
   different VPNs, as well as between VPN routing public routing.
   However, as long as the independent logical routers share the same
   hardware, there is some sharing of resources, and interactions are
   still possible.  Also, each independent control plane has its
   associated overheads, and this can raise issues of scale.  For
   example, the PE device must run a potentially large number of
   independent routing "decision processes," and must also maintain a
   potentially very large number of routing adjacencies.

Aggregated routing model

   Another option is to use one single instance of a routing protocol
   for carrying VPN routing information between the PEs.  In this
   method, the routing information for multiple different VPNs is
   aggregated into a single routing protocol.

   This approach greatly reduces the number of routing adjacencies which
   the PEs must maintain, since there is no longer any need to maintain
   more than one such adjacency between a given pair of PEs.  If the
   single routing protocol supports a hierarchical route distribution
   mechanism (such as BGP's "route reflectors"), the PE-PE adjacencies
   can be completely eliminated, and the number of backbone adjacencies
   can be made into a small constant which is independent of the number
   of PE devices.  This improves the scaling properties.

   Additional routing instances may still be needed to support the
   exchange of routing information between the PE and its locally
   attached CEs.  These can be eliminated, with a consequent further
   improvement in scalability, by using static routing on the PE-CE
   interfaces, or possibly by having the PE-CE routing interaction use
   the same protocol instance that is used to distribute VPN routes
   across the VPN backbone.

   With this approach, the number of routing protocol instances in a PE
   device does not depend on the number of CEs supported by the PE
   device, if the routing between PE and CE devices is static or BGP-4.
   However, CE and PE devices in a VPN exchange route information inside
   a VPN using a routing protocol except for BGP-4, the number of
   routing protocol entities in a PE device depends on the number of CEs
   supported by the PE device.

   In principle it is possible for routing to be aggregated using either
   BGP or on an IGP.

4.4.4.1 Aggregated routing with OSPF or IS-IS

   When supporting VPNs, it is likely that there can be a large number
   of VPNs supported within any given SP network.  In general only a
   small number of PE devices will be interested in the operation of any
   one VPN.  Thus while the total amount of routing information related
   to the various customer networks will be very large, any one PE needs
   to know about only a small number of such networks.

   Generally SP networks use OSPF or IS-IS for interior routing within
   the SP network.  There are very good reasons for this choice, which
   are outside of the scope of this document.

   Both OSPF and IS-IS are link state routing protocols.  In link state
   routing, routing information is distributed via a flooding protocol.
   The set of routing peers is in general not fully meshed, but there is
   a path from any router in the set to any other.  Flooding ensures
   that routing information from any one router reaches all the others.
   This requires all routers in the set to maintain the same routing
   information.  One couldn't withhold any routing information from a
   particular peer unless it is known that none of the peers further
   downstream will need that information, and in general this cannot be
   known.

   As a result, if one tried to do aggregated routing by using OSPF,
   with all the PEs in the set of routing peers, all the PEs would end
   up with the exact same routing information; there is no way to
   constrain the distribution of routing information to a subset of the
   PEs.  Given the potential magnitude of the total routing information
   required for supporting a large number of VPNs, this would have
   unfortunate scaling implications.

   In some cases VPNs may span multiple areas within a provider, or span
   multiple providers.  If VPN routing information were aggregated into
   the IGP used within the provider, then some method would need to be
   used to extend the reach of IGP routing information between areas and
   between SPs.

4.4.4.2 Aggregated routing with BGP

   In order to use BGP for aggregated routing, the VPN routing
   information must be clearly distinguished from the public Internet
   routing information.  This is typically done by making use of BGP's
   capability of handling multiple address families, and treating the
   VPN routes as being in a different address family than the public
   Internet routes.  Typically a VPN route also carries attributes which
   depend on the particular VPN or VPNs to which that route belongs.

   When BGP is used for carrying VPN information, the total amount of
   information carried in BGP (including the Internet routes and VPN
   routes) may be quite large.  As noted above, there may be a large
   number of VPNs which are supported by any particular provider, and
   the total amount of routing information associated with all VPNs may
   be quite large.  However, any one PE will in general only need to be
   aware of a small number of VPNs.  This implies that where VPN routing
   information is aggregated into BGP, it is desirable to be able to
   limit which VPN information is distributed to which PEs.

   In "Interior BGP" (IBGP), routing information is not flooded; it is
   sent directly, over a TCP connection, to the peer routers (or to a
   route reflector).  These peer routers (unless they are route
   reflectors) are then not even allowed to redistribute the information
   to each other.  BGP also has a comprehensive set of mechanisms for
   constraining the routing information that any one peer sends to
   another, based on policies established by the network administration.
   Thus IBGP satisfies one of the requirements for aggregated routing
   within a single SP network - it makes it possible to ensure that
   routing information relevant to a particular VPN is processed only by
   the PE devices that attach to that VPN.  All that is necessary is
   that each VPN route be distributed with one or more attributes which
   identify the distribution policies.  Then distribution can be
   constrained by filtering against these attributes.

   In "Exterior BGP" (EBGP), routing peers do redistribute routing
   information to each other.  However, it is very common to constrain
   the distribution of particular items of routing information so that
   they only go to those exterior peers who have a "need to know,"
   although this does require apriori knowledge of which paths may
   validly lead to which addresses.  In the case of VPN routing, if a
   VPN is provided by a small set of cooperating SPs, such constraints
   can be applied to ensure that the routing information relevant to
   that VPN does not get distributed anywhere it doesn't need to be.  To
   the extent that a particular VPN is supported by a small number of
   cooperating SPs with private peering arrangements, this is
   particularly straightforward, as the set of EBGP neighbors which need
   to know the routing information from a particular VPN is easier to
   determine.

   BGP also has mechanisms (such as "Outbound Route Filtering," ORF)
   which enable the proper set of VPN routing distribution constraints
   to be dynamically distributed.  This reduces the management burden of
   setting up the constraints, and hence improves scalability.

   Within a single routing domain (in the layer 3 VPN context, this
   typically means within a single SP's network), it is common to have
   the IBGP routers peer directly with one or two route reflectors,
   rather than having them peer directly with each other.  This greatly
   reduces the number of IBGP adjacencies which any one router must
   support.  Further, a route reflector does not merely redistribute
   routing information, it "digests" the information first, by running
   its own decision processes.  Only routes which survive the decision
   process are redistributed.

   As a result, when route reflectors are used, the amount of routing
   information carried around the network, and in particular, the amount
   of routing information which any given router must receive and
   process, is greatly reduced.  This greatly increases the scalability
   of the routing distribution system.

   It has already been stated that a given PE has VPN routing
   information only for those PEs to which it is directly attached.  It
   is similarly important, for scalability, to ensure that no single
   route reflector should have to have all the routing information for
   all VPNs.  It is after all possible for the total number of VPN
   routes (across all VPNs supported by an SP) to exceed the number
   which can be supported by a single route reflector.  Therefore, the
   VPN routes may themselves be partitioned, with some route reflectors
   carrying one subset of the VPN routes and other route reflectors
   carrying a different subset.  The route reflectors which carry the
   public Internet routes can also be completely separate from the route
   reflectors that carry the VPN routes.

   The use of outbound route filters allows any one PE and any one route
   reflector to exchange information about only those VPNs which the PE
   and route reflector are both interested in.  This in turn ensures
   that each PE and each route reflector receives routing information
   only about the VPNs which it is directly supporting.  Large SPs which
   support a large number of VPNs therefore can partition the
   information which is required for support of those VPNs.

   Generally a PE device will be restricted in the total number of
   routes it can support, whether those are public Internet routes or
   VPN routes.  As a result, a PE device may be able to be attached to a
   larger number of VPNs if it does not also need to support Internet
   routes.

   The way in which VPN routes are partitioned among PEs and/or route
   reflectors is a deployment issue.  With suitable deployment
   procedures, the limited capacity of these devices will not limit the
   number of VPNs that can be supported.

   Similarly, whether a given PE and/or route reflector contains
   Internet routes as well as VPN routes is a deployment issue.  If the
   customer networks served by a particular PE do not need the Internet
   access, then that PE does not need to be aware of the Internet
   routes.  If some or all of the VPNs served by a particular PE do need
   the Internet access, but the PE does not contain Internet routes,
   then the PE can maintain a default route that routes all the Internet
   traffic from that PE to a different router within the SP network,
   where that other router holds the full the Internet routing table.
   (Note that this default route is an IGP default route,
    not a BGP default route, and hence may be present even in a
   "default-free zone").  With this approach the PE device needs only a
   single default route for all the Internet routes.

   For the reasons given above, the BGP protocol seems to be a
   reasonable protocol to use for distributing VPN routing information.
   Additional reasons for the use of BGP are:

   o BGP has been proven to be useful for distributing very large
     amounts of routing information; there isn't any routing
     distribution protocol which is known to scale any better.

   o The same BGP instance that is used for PE-PE distribution of VPN
     routes can be used for PE-CE route distribution, if CE-PE routing
     is static or BGP.  PEs and CEs are really parts of distinct
     Autonomous Systems, and BGP is particularly well-suited for
     carrying routing information between Autonomous Systems.

   On the other hand, BGP is also used for distributing public Internet
   routes, and it is crucially important that VPN route distributing not
   compromise the distribution of public Internet routes in any way.
   This issue is discussed in the following section.

Regards
Shashank
http://mia.ece.uic.edu/~papers