MPLS VPNs are a complex mix of technologies, but the basics can be described with a few simple facts. The most important is: When an enterprise network is migrated to an
MPLS
VPN
service, the service provider's routers replace the enterprise network's core routers.
If the service provider's edge routers become part of the customer's IP network, they obviously have to engage in the customer's routing protocol, which is a challenge facing all MPLS VPN service providers: which routing protocol to run with the customer‾ Should the provider adapt to every customer's whim and support any routing protocol known to mankind or try to enforce its own choice‾
Life was easy when MPLS VPN technology was introduced almost 10 years ago. Cisco was the only vendor supporting the technology and offered only two routing protocols: BGP (the routing protocol commonly used on the Internet) or Routing Information Protocol (RIP, a 20-year-old relic). Early adopters were more than willing to use whatever service providers offered because of the significant cost savings. But as other vendors leveled the playing field, customers increasingly exercised their leverage and demanded support for the routing protocol of their choice.
Cisco and other MPLS VPN equipment vendors responded by offering more and more routing protocols, leaving the service providers in a quagmire. Their support teams were familiar with BGP -- assuming that the service provider was already offering world-class Internet service, which meant that some incumbent players did not fare as well -- but they were not conversant with a plethora of enterprise routing protocols. (Anyone who has ever configured multiple routing protocols in a single network realizes that the only people who thrive on their complex interactions are the writers of CCIE-level preparation courses.)
Keep the network simple
To keep the network simple, you should minimize the number of routing protocols it uses. In the case of MPLS VPNs, that means pushing BGP (which must be used in the service provider's core network to transport the VPN prefixes between network edges) as far out as possible. So migrating the whole customer network to BGP is the ideal solution from the service provider's perspective.
Customers have a completely different view, however. Re-engineering the whole network and introducing a new (unfamiliar and supposedly highly complex and slowly converging) routing protocol in their network to reduce the cost of the WAN operation does not look like a good deal. They would prefer to retain their existing network structure, minimize the changes to their routing protocols and push the burden of interoperability toward the service provider (while still trying to bargain for the lowest-price deal).
Service providers can choose among several directions to move away from this lose-lose situation:
- Support numerous customer routing protocols. This approach would require significant investment in the service provider's support team training to maintain a decent level of support quality, as the provider's TAC network technicians have to be able to troubleshoot multiple interacting IP routing protocols. Regardless of the investment required, the perceived value of this approach is low, as you tend to compete on features (for example, 'Do you support OSPF sham link‾' or 'How about running multiple EIGRP autonomous systems‾'), not on the value you're providing to the customer. Needless to say, many service providers choose to go this route without beefing up the support team, resulting in dissatisfied customers.
Choose the right customers.