Wondering About VPLS and Routing Protocols

Customer interest in carrier Ethernet services is growing. With its simplicity, established knowledge base among engineers, and low cost per megabit, Ethernet WAN services are the next logical step for WAN access. Carriers are rushing to upgrade their networks to provide Ethernet access globally.

My network uses a lot of WAN Ethernet. All of our sites in the US use it for access to the L3VPN MPLS cloud from our service provider. This has proven to be a great technology for us. However, in our case, WAN Ethernet is just the access circuit to the MPLS cloud. We peer eBGP over these WAN Ethernet circuits to the provider's PER. I have discussed my affection for BGP previously and how it's allowed us to scale our network and utilize enhanced routing features.

But many of the carriers are positioning WAN Ethernet not as an access option to their L3VPN MPLS clouds, but as a VPLS solution. VPLS provides Layer-2 connectivity between customer sites, not Layer-3 access. While the connectivity is still any-to-any (multipoint) as L3VPN MPLS is, it is one layer lower in the OSI model. Many carriers are providing VPLS via their existing MPLS backbone. But, I also had an interesting discussion with a carrier recently that is considering an all Ethernet backbone for their future generation network. This would be Ethernet supporting Ethernet without a L3VPN MPLS option.

In a VPLS service, customers don't peer routing protocols with the carrier, but directly between their own routers over the Layer-2 multi-access VPLS network. This is just like any Ethernet LAN you have today. While it may be over thousands of miles, as far as the routers are concerned, it's just a LAN. This makes BGP a much more difficult routing protocol to use since it relies on static neighbors generally in a point-to-point environment. Furthermore, since there is no routing protocol peering to external organizations (in MPLS' case a service provider) customers can continue to run an IGP - most likely OSPF or EIGRP. OSPF and EIGRP form neighbors automatically and are suited for multi-access LANs.

But this introduces an interesting routing protocol scalability problem. In reading books and best practice guides, I've learned to keep the number of OSPF or EIGRP neighbors on a single LAN segment to 20 or less (preferably toward less). But how do you do this in a VPLS environment when you have hundreds of remote field sites (like banks and restaurants do)? All of those sites cannot be on the same Layer-2 domain since the routing protocols could not handle all the neighbors. Yes, you could segment the network into islands of 10-20 sites, but then you lose the any-to-any capabilities that VPLS provides. Traffic must route through hub sites that have the bandwidth size to handle not only traffic destined to the hub, but also site-to-site traffic. Plus, how do you configure OSPF areas or EIGRP summarization correctly in this case? The last thing you want is to configure your routing protocol to turn VPLS into a frame-relay style network with all traffic routing through a hub site.

VPLS looks like a great technology for a small number of sites, but I'm concerned about how routing protocols would scale to handle it. To make VPLS a viable revenue service, carriers must be able to sell it to large enterprises as a viable option to L3VPN MPLS. However, customers are getting very used to the routing control and capabilities L3VPNs and MPLS provide. I just have a feeling they won't realize how much they like these features until they're gone.

I'm interested to see how this will work out and thoughts and solution you may have.