No Accident BGP is used for VPNs

Border Gateway Protocol (BGP) is used in many roles. So many, that some worry about the impact on Internet stability. The distribution of flowspec rules by BGP that was implicated in the recent Centurylink outage was a reminder to some of that potential, notwithstanding a hopefully fuller understanding of the outage in the future. Most agree on BGP’s traditional role in interconnecting Internet autonomous systems (AS). There are interesting arguments for and against eBGP’s (exterior BGP) use in dense datacenter fabrics. BGP’s use as an approach to Virtual Private Networks (VPNs) has been successful, and I argue in this article that BGP’s natural focus and strengths make it an obvious choice for VPNs. As the industry regularly approaches the question “Are we using BGP for too many things”, clarity on where it is a natural fit, and where it is a forced fit, maybe helpful, in addition to other arguments such as too many eggs in one basket.

The bottom line of my argument is BGP is a purpose built control plane for connecting ASs, and for describing what is happening outside of a network, both of which are needed in the VPN use case; certainly layer 3, and to some extent layer 2.

EGPs (BGP4) & Interior Gateway Protocols (IGPs) - OSPF/IS-IS - really have two VERY different roles, with access to different information, which defines their differences in many ways. I limit the conversation of IGPs here to OSPF/IS-IS as they are the IGPs most prominent in ISPs, certainly large ones, and because they are more different from BGP than RIP and (E)IGRP. Net: a link-state protocol is a very different beast than a path/distance vector protocol.

Figure 1. Role of EGPs and IGPs

Figure 1, the scope of an IGP as being the routers internal to a network, and an EGP as being the other networks connected to the network, show the fundamental focus and concerns of each protocol. BGP, in this role, does not care too much what is going on inside the network, as long as it can get to other BGP speakers and learn about what is going on outside the network / what other networks are reachable. IGPs OTOH are totally concerned with what is going on inside the network and where to direct traffic that is destined for outside the network. This is networking 101, and most network professionals understand this.

To complete the networking 101 refresh, as eBGP does not have significant information about the internals of any network, it focuses on the problems it can address, for example policy between networks. Even if eBGP was designed to distribute (all) link and link metric information, whether that information could be trusted, from another administrative domain, would be an ongoing question. Link state IGPs on the other hand, have significant information about their networks / areas: all routers and links, routing costs, and traffic engineering metrics. Not surprisingly, what IGPs do better than BGP is understand the complete topology, regardless of whether all routers are being used, and understand the characteristics of different links. This information enables link state IGPs to specialize in topology, traffic engineering, and derived multiple path reachability optionality (from the topology information).

OSPF version 2, the most widely deployed version of OSPF, is highly optimized for its originally envisioned role, and not very extensible to multiple address families, not even to IPv6 (hence OSPF version 3 - which in addition to supporting IPv6 may address other OSPF extensibility issues). IS-IS did require modifications to support IPv6, but because of its use of TLVs (type-length-value), the changes were more minor than what was required for OSPFv2—>v3; TLV work for OSPF has been going on as well.

Figure 2. BGP VPNs.

Regardless, Figure 2, BGP VPNs, is very like Figure 1, because the VPN use case is in someways similar to the Internet gateway case: Either the provider or the customer may want to enforce / accept policy at the gateway to an AS, the VPN routes are not really internal routes, they are more like external routes to the AS and iBGP can be used for distribution, including route reflectors. I believe there is a strong case for L3 VPNs using BGP.

On a purely protocol level, it could be argued the case for L2 VPNs using BGP is not as strong, however, in addition to leveraging some of L3 VPN’s protocol infrastructure and picking up BGP functionality like multi-homing, there are some other reasons to consider it, as I wrote in: BGP for Service Layer Migration and Perhaps More

Putting aside all the BGP capabilities VPNs pick up, and a fundamental role in the network and basic protocol architecture, L3 VPNs do seem to be a good fit for BGP. Layer 2 VPNs arguably less so, but there is also the benefits to be explored of one approach to all VPNs and the features of BGP.

One of the main levers for reducing complexity is layering and separating different protocols for different roles, and the industry may yet explore that, even if BGP is a better fit for supporting VPNs than other existing routing protocols. However, that is a different issue, that may be resolved in any number of ways; it is a different issue to whether BGP is a good fit for VPNs or not.

What are your thoughts? Let me know.