Link-State Distribution Using BGP Overview
Role of an Interior Gateway Protocol
An interior gateway protocol (IGP) is a type of protocol used for exchanging routing information between devices within an autonomous system (AS). Based on the method of computing the best path to a destination, the IGPs are divided into two categories:
Link-state protocols—Advertise information about the network topology (directly connected links and the state of those links) to all routers using multicast addresses and triggered routing updates until all the routers running the link-state protocol have identical information about the internetwork. The best path to a destination is calculated based on constraints such as maximum delay, minimum available bandwidth, and resource class affinity.
OSPF and IS-IS are examples of link-state protocols.
Distance vector protocols—Advertise complete routing table information to directly connected neighbors using a broadcast address. The best path is calculated based on the number of hops to the destination network.
RIP is an example of a distance vector protocol.
As the name implies, the role of an IGP is to provide routing connectivity within or internal to a given routing domain. A routing domain is a set of routers under common administrative control that share a common routing protocol. An AS can consist of multiple routing domains, where IGP functions to advertise and learn network prefixes (routes) from neighboring routers to build a route table that ultimately contains entries for all sources advertising reachability for a given prefix. IGP executes a route selection algorithm to select the best path between the local router and each destination, and provides full connectivity among the routers making up a routing domain.
In addition to advertising internal network reachability, IGPs are often used to advertise routing information that is external to that IGP's routing domain through a process known as route redistribution. Route redistribution is the process of exchanging routing information among distinct routing protocols to tie multiple routing domains together when intra-AS connectivity is desired.
Limitations of an Interior Gateway Protocol
While each individual IGP has its own advantages and limitations, the biggest limitations of IGP in general are performance and scalability.
IGPs are designed to handle the task of acquiring and distributing network topology information for traffic engineering purposes. While this model has served well, IGPs have inherent scaling limitations when it comes to distributing large databases. IGPs can autodetect neighbors, with which they acquire intra-area network topology information. However, the link-state database or a traffic engineering database has the scope of a single area or AS, thereby limiting applications, such as end-to-end traffic engineering, the benefit of having external visibility to make better decisions.
For label-switched networks, such as MPLS and Generalized MPLS (GMPLS), most existing traffic engineering solutions work in a single routing domain. These solutions do not work when a route from the ingress node to the egress node leaves the routing area or AS of the ingress node. In such cases, the path computation problem becomes complicated because of the unavailability of the complete routing information throughout the network. This is because service providers usually choose not to leak routing information beyond the routing area or AS for scalability constraints and confidentiality concerns.
Need for Spanning Link-State Distribution
One of the limitations of IGP is its inability to span link-state distribution outside a single area or AS. However, spanning link-state information acquired by an IGP across multiple areas or ASs has the following needs:
LSP path computation—This information is used to compute the path for MPLS LSPs across multiple routing domains, for example an inter-area TE LSP.
External path computing entities—External path computing entities, such as Application Layer Traffic Optimization (ALTO) and Path Computation Elements (PCE), perform path computations based on the network topology and current state of connections within the network, including traffic engineering information. This information is typically distributed by IGPs within the network.
However, because the external path computing entities cannot extract this information from the IGPs, they perform network monitoring to optimize network services.
Using BGP as a Solution
To meet the needs for spanning link-state distribution across multiple domains, an exterior gateway protocol (EGP) is required to collect link-state and traffic engineering information from an IGP area, share it with external component, and use it for computing paths for interdomain MPLS LSPs.
BGP is a standardized EGP designed to exchange routing and reachability information between autonomous systems (ASs). BGP is a proven protocol that has better scaling properties because it can distribute millions of entries (for example, VPN prefixes) in a scalable fashion. BGP is the only routing protocol in use today that is suited to carry all of the routes in the Internet. This is largely because BGP runs on top of TCP and can make use of TCP flow control. In contrast, the internal gateway protocols (IGPs) do not have flow control. When IGPs have too much route information, they begin to churn. When BGP has a neighboring speaker that is sending information too quickly, BGP can throttle down the neighbor by delaying TCP acknowledgments.
Another benefit of BGP is that it uses type, length, value (TLV) tuples and network layer reachability information (NLRI) that provide seemingly endless extensibility without the need for the underlying protocol to be altered.
The distribution of link-state information across domains is regulated using policies to protect the interests of the service provider. This requires a control over the topology distribution using policies. BGP with its implemented policy framework serves well in the interdomain route distribution. In Junos OS, BGP is completely policy driven. The operator must explicitly configure neighbors to peer with and explicitly accept routes into BGP. Furthermore, routing policy is used to filter and modify routing information. Thus, routing policies provide complete administrative control over the routing tables.
Although, within an AS, both IGP-TE and BGP-TE provide the same set of information, BGP-TE has better scaling characteristics that are inherited from the standard BGP protocol. This makes BGP-TE a more scalable choice for acquiring multi-area/multi-AS topology information.
By using BGP as a solution, the IGP-acquired information is used for distribution into BGP. The ISPs can selectively expose this information with other ISPs, service providers, and content distribution networks (CDNs) through normal BGP peering. This allows for aggregation of the IGP-acquired information across multiple areas and ASs, such that an external path computing entity can access the information by passively listening to a route reflector.
In Junos OS, the IGPs install topology information into a database called the traffic engineering database. The traffic engineering database contains the aggregated topology information. To install IGP topology information into traffic engineering database, use the set igp-topology configuration statement at the [edit protocols isis traffic-engineering] and [edit protocols ospf traffic-engineering] hierarchy levels. The mechanism to distribute link-state information using BGP includes the process of advertising the traffic engineering database into BGP-TE (import), and installing entries from BGP-TE into the traffic engineering database (export).
Traffic Engineering Database Import
To advertise the traffic engineering database into BGP-TE, the link and node entries in the traffic engineering database are converted in the form of routes. These converted routes are then installed by the traffic engineering database on behalf of the corresponding IGP, into a user-visible routing table called lsdist.0, on conditions subject to route policies. The procedure of leaking entries from the traffic engineering database into lsdist.0 is called traffic engineering database import as illustrated in Figure 1.
There are polices to govern the traffic engineering database import process. By default, no entries are leaked from the traffic engineering database into the lsdist.0 table.
Starting in Junos OS Release 17.4R1, the traffic engineering database installs interior gateway protocol (IGP) topology information in addition to RSVP-TE topology information in the lsdist.0 routing table as illustrated in Figure 1. Prior to Junos OS Release 17.4R1, the traffic engineering database only exported RSVP-TE topology information. Now you can monitor both IGP and traffic engineering topology information. The BGP-LS reads IGP entries from lsdist.0 and advertises these entries to the BGP peers. To import IGP topology information into BGP-LS from lsdist.0, use the set bgp-ls configuration statement at the [edit protocols mpls traffic-engineering database import igp-topology] hierarchy level.
Traffic Engineering Database Export
BGP can be configured to export or advertise routes from the lsdist.0 table, subject to policy. This is common for any kind of route origination in BGP. In order to advertise BGP-TE into the traffic engineering database, BGP needs to be configured with the BGP-TE address family, and an export policy that selects routes for redistribution into BGP.
BGP then propagates these routes like any other NLRI. BGP peers that have the BGP-TE family configured and negotiated receive BGP-TE NLRIs. BGP stores the received BGP-TE NLRIs in the form of routes in the lsdist.0 table, which is the same table that stores locally originated BGP-TE routes. The BGP-installed routes in lsdist.0 are then distributed to other peers like any other route. Thus, the standard route selection procedure applies to BGP-TE NLRIs received from multiple speakers.
To achieve interdomain TE, the routes in lsdist.0 are leaked into the traffic engineering database through a policy. This process is called traffic engineering database export as illustrated in Figure 1.
There are polices to govern the traffic engineering database export process. By default, no entries are leaked from the lsdist.0 table into the traffic engineering database.
For SDN applications, such as PCE and ALTO, the BGP-TE advertised information cannot leak into the traffic engineering database of a router. In such cases, an external server that peers with the routers using BGP-TE is used to move topology information up into the sky/orchestration system that spans the network. These external servers can be deemed as BGP-TE consumers, where they receive BGP-TE routes, but do not advertise them.
Assigning Credibility Values
Once the entries are installed in the traffic engineering database, the BGP-TE learned information is made available for CSPF path computation. The traffic engineering database uses a protocol preference scheme that is based on credibility values. A protocol with a higher credibility value is preferred over a protocol with a lower credibility value. BGP-TE has the capability to advertise information learned from multiple protocols at the same time, and so in addition to the IGP-installed entries in the traffic engineering database, there can be BGP-TE installed entries that correspond to more than one protocol. The traffic engineering database export component creates a traffic engineering database protocol and credibility level for each protocol that BGP-TE supports. These credibility values are configurable in the CLI.
The credibility order for the BGP-TE protocols is as follows:
ISIS Level 1—82
ISIS Level 2—83
Cross-Credibility Path Computation
After you assign credibility values, each credibility level is treated as an individual plane. The Constrained Shorted Path First algorithm starts with the highest assigned credibility to the lowest, finding a path within that credibility level.
With BGP-TE, it is essential to compute paths across credibility levels to compute inter-AS paths. For example, different credibility settings are seen on a device from area 0 that computes the path through area 1, because area 0 entries are installed by OSPF, and area 1 entries are installed by BGP-TE.
To enable path computation across credibility levels, include the cross-credibility-cspf statement at the edit protocols mpls, [edit protocols mpls label-switched-path lsp-name], and [edit protocols rsvp] hierarchy levels. At the [edit protocols rsvp] hierarchy level, enabling cross-credibility-cspf impacts bypass LSPs and loose hop expansion in transit.
Configuring cross-credibility-cspf enables path computation across credibility levels using the Constrained Shortest Path First algorithm, wherein the constraint is not performed on a credibility-by-credibility basis, but as a single constraint ignoring the assigned credibility values.
BGP-TE NLRIs and TLVs
Like other BGP routes, BGP-TE NLRIs can also be distributed through a route reflector that speaks BGP-TE NLRI. Junos OS implements the route reflection support for the BGP-TE family.
The following is a list of supported NLRIs:
IPv4 Prefix NLRI (receive and propagate)
IPv6 Prefix NLRI (receive and propagate)
Junos OS does not provide support for the route-distinguisher form of the above NRLIs.
The following is a list of supported fields in link and node NLRIs:
Protocol-ID—NLRI originates with the following protocol values:
Identifier—This value is configurable. By default, the identifier value is set to 0.
Local/Remote node descriptor—These include:
BGP-LS Identifier—This value is configurable. By default, the BGP-LS identifier value is set to 0
Link descriptors (Only for link NLRI)—This includes:
Link Local/Remote Identifiers
IPv4 interface address
IPv4 neighbor address
IPv6 neighbor/interface address—The IPv6 neighbor and interface addresses are not originated, but only stored and propagated when received.
Multi-topology ID—This value is not originated, but stored and propagated when received.
The following is a list of supported LINK_STATE attribute TLVs:
Max link bandwidth
Max reservable bandwidth
TE default metric
The following TLVs, which are not originated, but only stored and propagated when received:
Opaque link attributes
MPLS protocol mask
Link protection type
Link name attribute
Node flag bits—Only the overload bit is set.
The following TLVs, which are not originated, but only stored and propagated when received:
OSPF-specific node properties
Opaque node properties
IS-IS area identifier
Prefix attributes—These TLVs are stored and propagated like any other unknown TLVs.
Supported and Unsupported Features
Junos OS supports the following features with link-state distribution using BGP:
Advertisement of multiprotocol assured forwarding capability
Transmission and reception of node and link-state BGP and BGP-TE NLRIs
Nonstop active routing for BGP-TE NLRIs
Junos OS does not support the following functionality for link-state distribution using BGP:
Aggregated topologies, links, or nodes
Route distinguisher support for BGP-TE NLRIs
Multi-instance identifiers (excluding the default instance ID 0)
Advertisement of the link and node area TLV
Advertisement of MPLS signaling protocols
Importing node and link information with overlapping address
BGP Link-State Extensions for Source Packet Routing in Networking (SPRING)
Starting in Junos OS Release 17.2R1, the BGP link-state address family is extended to distribute the source packet routing in networking (SPRING) topology information to software-defined networking (SDN) controllers. BGP typically learns the link-state information from IGP and distributes it to BGP peers. Besides BGP, the SDN controller can get link-state information directly from IGP if the controller is a part of an IGP domain. However, BGP link-state distribution provides a scalable mechanism to export the topology information. BGP link-state extensions for SPRING is supported on interdomain networks.
Source Packet Routing in Networking (SPRING)
SPRING is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to decide the actual path it must take. SPRING engages IGPs, such as IS-IS and OSPF, for advertising network segments. Network segments can represent any instruction, topological or service-based. Within IGP topologies, IGP segments are advertised by the link-state routing protocols. There are two types of IGP segments:
When SPRING in enabled in a BGP network, BGP link-state address family learns the SPRING information from the IGP link-state routing protocols and advertises segments in the form of segment identifiers (SIDs). BGP link-state address family has been extended to carry SIDs and other SPRING-related information to BGP peers. The route reflector can steer a packet through a desired set of nodes and links by prepending the packet with an appropriate combination of tunnels. This feature allows BGP link-state address family to also advertise the SPRING information to BGP peers.
Flow of BGP Link-State SPRING Data
Figure 2 depicts the data flow of BGP link-state SPRING data that IS-IS pushes to the traffic engineering database.
IGP pushes the SPRING attributes to the traffic engineering database.
SPRING capabilities and algorithm information are carried forward as node attributes into the traffic engineering database.
Adjacent SID and LAN adjacent SID information are carried as link attributes.
Prefix SID or node-SID information is carried as prefix attributes.
A new set or a change to existing attributes triggers IGP updates to the traffic engineering database with new data.
RSVP is a prerequisite for link attributes.
If traffic engineering is disabled at the IGP level, none of the attributes are pushed to the traffic engineering database.
All parameters in the BGP traffic engineering NLRI, including the link, node, and prefix descriptors are derived from entries in the traffic engineering database.
The traffic engineering database imports route entries into the lsdist.0 routing table from IGP subject to policy.
The default policy of BGP is to export routes, which are known to BGP only. You configure an export policy for non-BGP routes in the lsdis.0 routing table. This policy advertises an entry learned from the traffic engineering database.
Currently, OSPF does not push SPRING information to the BGP link-state address family. IS-IS is the only IGP that pushes SPRING information to the BGP link-state address family.
Supported BGP Link-State Attributes and TLVs, and Unsupported Features for BGP Link-State with SPRING
BGP link-state with SPRING supports the following attributes and type, length, and values (TLVs) that are originated, received, and propagated in the network:
Segment routing Capabilities
Segment routing Algorithm
IP reachability information
The following list supports TLVs that are not originated, but only received and propagated in the network:
OSPF route type
Junos OS does not support the following features with BGP link-state with SPRING extensions:
IPv6 prefix origination
Traffic engineering database export for SPRING parameters
New TLVs with tcpdump (existing TLVs are also not supported).
SPRING over IPv6