BGP-LS: What Is It Good For?

One of the questions I find myself answering a lot lately is what Packet Design’s BGP-LS story is. BGP-LS is an extension to Border Gateway Protocol (BGP) for distributing the network’s link-state (LS) topology model to external entities, such as the SDN controller. It has received a lot of attention because many SDN apps need this model.

The network’s link-state topology model consists of nodes (typically, but not limited to, routers) and links that connect these routers together. For each link, a set of attributes is also contained. These may include interface addresses, various metrics, and each link’s total and available bandwidth. This topology model is distributed among routers using one of the two prominent Interior Gateway Protocols (IGPs): ISIS (Intermediate System to Intermediate System) and OSPF (Open Shortest Path First) protocols.

The detailed link-state models of these two protocols are not identical. As a result, BGP-LS defines its own more abstract topology model and defines how to map these IGP models to its own model. As the network topology is discovered by the IGPs, the changes are reflected in the BGP-LS model as well and are also distributed using BGP-LS messages to any interested party, such as SDN controllers and apps. Note that the network devices themselves are not interested in learning the network topology this way, as they already participate in IGP and learn it firsthand.

Similarly, the Packet Design Route Explorer product learns the network topology firsthand by participating in IGPs. This has several advantages over learning it from BGP-LS:

• BGP-LS adds a layer of complexity: One of the main uses of Route Explorer is network diagnostics, including network design, protocol interaction, and vendor implementation issues, among others. BGP-LS introduces yet another element that can be broken, particularly as it relies on translating IGP’s native model into BGP-LS’ own model. As a result, getting to the root cause of network problems would be harder, because it would be difficult to know if an issue is present in the IGP or in BGP-LS itself.
• IGPs are not static: Many new features are introduced every year. It is not clear how fast these new features would be mapped to BGP-LS’s model. I personally doubt that they will be simultaneously introduced in specifications. Even if they were, some vendors may not implement the features in BGP-LS at the same time they implement it in their IGPs. This is because IGPs are essential to running the network, but BGP-LS is not.
• It is not clear how real time BGP-LS is: When a change happens in IGP, it needs to be injected into BGP. For many vendors, this cross-protocol injection happens on a timer. BGP itself has many timers that reduce its churn under heavy load. If a link was to flap very frequently, are the BGP messages really real time? Indeed, in one vendor’s demonstration during the MPLS World Congress in Paris earlier this month, the topology changes were reflected in the BGP-LS topology in about five seconds. Though this sounds fast, it needs to be compared to the time it takes to learn it from IGPs, which is typically in tens of milliseconds. That is three orders of magnitude difference. (At the conference, I heard one vendor say its implementation is real-time, but I have not seen it in action.)

What is BGP-LS good for then? Well, if a large number of SDN apps need the network topology model, it is unrealistic for a service provider to have all of them participate in IGPs. First of all, allowing apps to participate in IGPs requires much vetting. BGP-LS is safer because (1) it does not impact the network’s routing, as it is not used for that purpose; and (2) BGP has an extensive policy mechanism that can control and safeguard this information. BGP-LS is also more convenient for recording remote areas (this typically requires running IGP adjacencies over GRE tunnels or VLANs).

I would argue that even in the SDN apps use case, BGP-LS is not best suited for the job. Using YANG topology data models, a router can provide models for topologies it is part of to SDN controllers, which can then provide these models to applications using their northbound APIs. Or SDN controllers can participate in IGPs the way Route Explorer does and discover the network topology first-hand. Indeed, the ONOS controller has this capability. Packet Design’s SDN Management and Orchestration Platform also provides YANG topology models to applications. I will talk about these, as well as segment routing, in my next blog post.