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. High-end customers already use BGP in their networks, owing to the network size, its complexity or the resilience requirements of their Internet connectivity. For these customers, using BGP is not an issue, and they usually appreciate having a competent service provider peer to work with. Low-end customers are also a perfect fit, since they usually don't want to worry about the configuration of their routers (see the outsourcing option below).
- Help customers embrace BGP. The service provider deployment team can work with customers to deploy BGP as far into their networks as feasible (several early adopters of the MPLS VPN service successfully took this path). This strategy requires higher up-front investment but provides significantly higher value to the customer, resulting in a seamlessly integrated network and a more loyal customer.
- Offer a complete outsourcing service. Routing protocol issues occur only when the customer is maintaining the network edges and the service provider controls the network core. If you offer a LAN-to-LAN IP service, the issue is moot; it's now your responsibility to provide high-quality transport, and the customer is no longer concerned what routing protocol you use. This approach also increases your value, resulting in significantly higher (more profitable) revenue.
- Move away from Layer-3 networking. The focus some vendors and industry analysts place on Carrier Ethernet, Ethernet-over-MPLS and Virtual Private LAN Service (VPLS) clearly indicates that some service providers have decided to move back to the safer waters of the Layer-2 world (remember, X.25, Frame Relay and ATM were all Layer-2 services). That's a viable business decision that can work well, as long as you're honest about what you offer.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks. He is currently chief technology adviser at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. For more expert advice from Ivan, you can read his blog, Cisco IOS hints and tricks.