Carrier's Carrier Solution Overview

The carrier's carrier MPLS/VPN solution is targeted at ISPs (or MPLS/VPN service providers) that are VPN customers of another service provider that provides connectivity or pure bandwidth services across an MPLS/VPN backbone. These VPN customers usually require inter-POP connectivity (including the capability to carry full Internet routing information) across the MPLS/VPN backbone and also adopt their own peering and routing policies

No restrictions within the MPLS/VPN architecture prevent this type of connectivity from being possible, using the functionality that we have already described in previous chapters. However, it is important to understand the implications of providing this service and to determine whether the mechanisms already described within the MPLS/VPN architecture are adequate to supply inter-POP connectivity.

Before reviewing how this type of connectivity can be provided, it is essential to make some distinctions between route types so that the following explanations become clear. We know that the carrier's carrier solutions are targeted at VPN customers that are ISPs, so we can assume that these customers will also be providing connectivity for their own external customers. This means that the ISP will have routes that belong to its own internal network and routes that will belong to external customers, or peering points. Figure 14-2 illustrates these types of routes.

Within the figure, we can see that all the ISP internal links, internal services, and loopback interfaces can be classed as internal routes. We will see later in this chapter that not all of these routes need to be advertised between ISP sites. All routes learned via Internet peering points or from customers of the ISP can be classed as external routes. For the rest of this chapter, we will refer to each of these route types as either ISP-customer internal or ISP-customer external routes to help provide the distinction of whether the route will be advertised across the MPLS/VPN backbone (ISP-customer internal) or directly between ISP VPN customer sites (ISP-customer external).

To fully appreciate the implications of this type of connectivity, we should review what will happen if the exchange of routing information between ISP sites is achieved by advertising all possible routes (both internal and external) across the PE-to-CE links. Figure 14-3 provides an example of this type of deployment.

As seen in Figure 14-3, the amount of routing information that the ISP may hold?and, therefore, exchange between POP sites?may be substantial. The most likely scenario is that the ISP will hold full Internet routes, as is the case in our sample topology, although partial routing may be an option. This will almost certainly still present a substantial number of routes that must be exchanged between POP sites.

In Figure 14-3, the EuroISP1 and EuroISP2 VPN customers each want to advertise full Internet routes to other POP sites across the MPLS/VPN backbone. To achieve this, these routes are advertised toward the San Jose PE-router, which must install them into the relevant VRFs?in this case, full routes into the EuroISP1 VRF and full routes into the EuroISP2 VRF.

If only one ISP customer attaches to the MPLS/VPN backbone, then the worst-case scenario is that full Internet routes will be advertised toward the PE-router from every ISP site. However, as illustrated in Figure 14-3, it is apparent that as more ISP customers require connectivity across the MPLS/VPN backbone, the exchange of routing information presents some major scaling issues that must be addressed.

This exchange of ISP-customer external routing information between sites via the MPLS/VPN backbone is not very optimal. If you consider the amount of routing information that each PE-router will need to hold, potentially multiple copies of full Internet routes, and also the amount of label space that will be required per VRF (one label per route), you can see that the basic architecture is not going to provide a scalable method for this type of connectivity. You can also see that if each ISP advertises all routes toward the backbone, this presents a major increase in the amount of routing protocol traffic traversing the MPLS/VPN backbone, even though much of this information is not actually required by the service provider that provides the VPN service. Therefore, an alternative method of route exchange is needed in this type of environment to overcome these limitations?this is provided through use of the carrier's carrier architecture.