Blog1 “BGP-LS:The Bridge from IGP to SDN and Intent-Based Routing”

We are now in the era of Software-Defined Networking (SDN), where Service Provider networks are no longer satisfied with simple shortest-path routing. Customers and applications are demanding application-aware traffic engineering — paths selected not just on IGP metrics, but on business intent: latency, bandwidth, SLA, cost, even environmental impact.

BGP Link-State (BGP-LS) was designed to overcome the limits of IGP flooding and deliver complete topology visibility to SDN controllers. Today, it has become the critical enabler of application-aware traffic engineering and intent-based routing, where customers can choose paths based on cost, latency, sustainability, or business policy.

The Shift Towards Application-Aware Networking

We are now in the era of Software-Defined Networking (SDN), where Service Provider networks are no longer satisfied with forwarding traffic on the shortest IGP path. Customers and applications are demanding more:

• Paths optimized for low latency (e.g., financial trading or 5G slicing).
• Paths with assured bandwidth for large data flows.
• Green routing options that minimize power consumption and carbon footprint.
• Policies that prefer or avoid specific cable systems based on risk or commercial agreements.

This is intent-based routing in practice: the customer specifies the intent, and the network programs itself to deliver that outcome.

But for this to be possible, a controller must have complete visibility of the network topology — every node, link, prefix, and attribute. Without that visibility, intent-based routing is blind.

Why Not Just Use IGP?

At first glance, it seems obvious: why not let the controller run IS-IS or OSPF and learn the topology directly from the routers?

In practice, this approach quickly runs into problems in large Service Provider networks:

• IGPs are built for convergence, not export. They use aggressive flooding and SPF recalculations to ensure fast recovery. That’s great for routers, but inefficient for a remote controller that only wants a copy of the topology.
• Networks are split into multiple domains. OSPF areas or IS-IS levels are used to keep flooding and SPF computation under control.
• Controllers would need to join every domain. That means running multiple IGP instances, establishing adjacencies everywhere, and handling constant flooding.
• Operational complexity skyrockets. Especially when the controller is hosted remotely, or when multiple IGPs must be supported across acquisitions and mergers.

The result? Controllers cannot easily get an end-to-end view of the network from IGPs alone.

In short: IGPs remain excellent for intra-domain routing, but they are not ideal for exporting topology to external systems.

This is where BGP Link-State (BGP-LS) comes in. Defined in RFC 7752, BGP-LS extends the familiar BGP protocol to carry link-state information outside the IGP domain.

Instead of forcing controllers to participate in every IGP, routers can:

• Export their IGP link-state database into BGP-LS.
• Advertise topology as BGP NLRIs (Nodes, Links, Prefixes).
• Attach attributes (metrics, bandwidth, SR SIDs, etc.) as BGP path attributes.
• Send it all to the controller via a standard BGP session.

This design makes BGP-LS:

• Scalable → works across multiple domains.
• Policy-driven → operators can filter or control exactly what to export.
• Flexible → future IGP/TE/SR extensions only require new TLVs in BGP-LS, no redesign.

From Topology Export to Intent-Based Routing

The real strength of BGP-LS is not just in exporting topology. It’s about enabling application-aware and intent-based networking.

Here’s how it works in practice:

1. Visualization → The controller builds a complete, multi-domain topology from BGP-LS updates.
2. Options → Customers or applications are presented with multiple valid path options (shortest, lowest-latency, green, cable-specific, etc.).
3. Selection → The customer selects the path that aligns with their intent.
4. Programming → The controller installs the path into the network, often as an SR-TE policy.
5. Execution → The network forwards traffic along the chosen path.

Examples of customer intents that BGP-LS enables:

• “Give me the least-cost path for my backup traffic.”
• “Ensure my trading application runs on the lowest-latency route.”
• “Steer this service via the lowest power consumption path to meet sustainability goals.”
• “Force traffic through my preferred submarine cable system.”
• “Avoid this provider or this geography for compliance reasons.”

Without BGP-LS, the controller cannot present these options because it doesn’t see the full topology. With BGP-LS, intent becomes actionable.

The Big Picture

Think of BGP-LS as the translator between distributed IGPs and centralized intelligence:

IGP (OSPF / IS-IS) → BGP-LS → Controller (PCE / SDN app)

• IGP stays inside the domain, doing fast convergence.
• BGP-LS extracts the LSDB and exports it.
• The controller builds a global, SR-aware topology.
• Customers and applications define intent → the controller programs the network accordingly.

It Matters

• For customers → Choice and visibility. They get to pick the path that matches their business requirements.
• For operators → Control and scalability. BGP-LS provides a standards-based, policy-driven way to export topology.
• For engineers → Future readiness. BGP-LS is the foundation for SR-TE, PCE, network slicing, and intent-based networking.

BGP LS Deployments:

There are few use cases mentioned below where BGP-LS deployments are very popular. There may be many more use cases where BGL LS would be part of topology and that would be  strictly design requirements.

Coming Next

In this post, we answered “Why BGP-LS?” and introduced its role as the bridge between IGP and SDN.

• In the next blog, we’ll dive into BGP-LS Fundamentals — exploring the building blocks (NLRIs and Path Attributes) that allow controllers to reconstruct the network graph and make intent-based routing a reality.