jrmitche@puck.nether.net

Routing Routing Area Working Group Internet Draft BGP This describes a local router implementation option that provides a facility for the manipulation of the costs of IGP learned routes that are utilized as BGP NextHops rather than using the SPF calculated cost to the same route when running the BGP path selection algorithm. The result is something that works like a pseudo-routing protocol but only impacting the BGP decision making process.

In networks where out of band route reflectors are in use that also deploy tunneling technologies such as RSVP-TE LSPs and where the operator has selected to use non-IGP SPF derived metrics on those tunnels which influence the BGP path selection process at the point when it reaches step (e) of section 9.1.2.2 of , an operator wishing to make the same decision for BGP prefixes that reach this point in the process on a router which does not deploy the tunneling technology has little capability to do so given existing functionality available in vendor implementations. This limits the ability for the out of band BGP route reflector from being deployed in these networks without implementing the tunnel technologies in use similiar to a router in the forwarding path (in band) or choosing to live with the IGP SPF derived decision for this step, neither of which are an ideal deployment scenario. Presumably, the metrics configured on the tunnels deployed have value from a traffic engineering standpoint versus the IGP derived metrics, and issues may occur meeting the network requirements if the route reflector in question were to make a different decision than that made by a similarly located client. This draft proposes a way for an implementation to provide a simple capability to manipulate the cost to the typically IGP learned prefixes that are utilized as BGP next hops.

A pseudo-protocol can be used to manipulate the cost to a BGP nexthop in cases where the normal IGP SPF cost is not desirable. To accomplish this, the pseudo-protocol would need the desired cost and a way to inject this cost in the BGP bestpath calculation. This can be accomplished via two components: A key-value store (e.g. an associative array) for associating nexthop prefixes to costs A cost replacement mechanism for utilizing the looked up information in place of the normally utilized IGP cost to the nexthop available in the routing table when doing the BGP bestpath calculation.

As discussed above the implementation must provide two distinct components, a key-value store and a cost replacement mechanism.

An implementation must provide a basic key-value store such as an associative array to store the replacement cost information configured by the operator. The key in this mechanism MUST be represented by an actual prefix, typically a host route such a /32 in IPv4 or a /128 for IPv6. The value stored to represent the nexthop cost MUST be an unsigned integer with possible values of 0 to a minimum of 2^32 to cover the maximum path metrics utilized by the most widely deployed IGPs, such as OSPF or IS-IS when utilizing wide metrics . Implementations MAY support maximum values up to 2^64 for a wider range of applications. The implementation MAY choose to represent the operator input data into the store directly in the router configuration or utilize a separate storage mechanism to store the configured information, however the implementation MUST persist this information through router reload or other events regardless of local representation of the data. An implementation MAY also provide a separate ephemeral mechanism for this information that replaces information from the persistent option, however no use case requiring this is discussed further in the draft. Specifying the method for configuring these values (for instance through CLI or NetConf/Yang) is out of the scope of this draft.

There are several implementation options for using the data in key-value store described above to replace the BGP nexthop costs. These are described in the sections below.

Upon finishing the computation of the SPF, or for non link-state protocols, at any point upon which a route is due to be added or updated in the routing information base (RIB), a lookup MUST be done on the route in the key value store and the cost to the nexthop for that prefix MUST be replaced by the value returned if one is available. The implementation SHOULD provide a mechanism that allows the operator to utilize either the nexthop replacement information or the SPF or normal routing protocol derived cost. For instance an implementation MAY do this by associating a different, operator configurable, route preference with the routes created by the pseudo-protocol versus the IGP protocol route preference. If the replacement routes are installed into the RIB and Forwarding Information Base (FIB) of the router, the associated Layer3 and Layer2 information and any other adjacency information required to forward on the route should be copied from the original route so that traffic from the router itself is still forwarding correctly.

In the case that the router performing the implementation described in this document does not actually need to forward along the BGP prefixes received (is out of band from a network traffic forwarding standpoint) and has an implementation of BGP optimal route reflection in place, the BGP nexthop costs can be associated only with the decision made for the BGP optimal route reflection group. The information in the local key-value store could be used to replace directly the IGP costs from the topology standpoint of the out of band router or the costs that would have been computed from the virtual IGP placement configured by ORR. In either of these cases, there is no need to actually place the information in the RIB or FIB of the local router, if nexthop information is stored only for the purpose of BGP bestpath calculations, as it is not necessary for local decisions as long as the appropriately configured BGP clients receive the appropriate paths as a result from the BGP bestpath decision.

In some cases, operators may not find it sufficient to only replace configured nexthop costs directly using the mechanism described above. If the desire of the operator is to utilize the BGP pseudo-protocol to mirror the operational BGP bestpath behavior of traffic forwarding routers in the network that utilize RSVP-TE LSPs in conjunction with a deployment of IGP Shortcuts , a more complicated implementation approach can resolve such a use case. It should be noted this implementation option is only required if in the use case the operator utilizes an absolute or relative configured metric for the on the RSVP-TE LSPs in question, and does not dynamically derive the metrics to points beyond the tail-end of the tunnel strictly from the IGP SPF cost to that prefix. In this situation the implementation MAY attempt to come to same cost system as this design requires by implementing a similar approach as sections 4 through 6 of describe but with the important difference that the router running this implementation does not actually have RSVP-TE LSPs configured. The way that they can implement the approach is by considering at every node processed in the SPF algorithm whether the key-value store contains an entry representing the traffic engineering router id for that node (for instance as described in Section 4.3 of for IS-IS or for OSPF, Section 3.4.1 of or Section 3 of for OSPFv2 and OSPFv3 respectively. If the key-value store does have such an entry, the cost up to that step in the SPF algorithm should be replaced with the value for that entry so the end result is that all downstream derived costs are influenced by the replacement cost looked up in the key-value store. This is similar in operation to Section 5 of with the same end result in respect to the costs used by the BGP path selection process.

Having a hard coded value that represents the cost to a prefix negates the normal reaction of costs to network events and for the most part this is the operator desired behavior when utilizing this feature. However in the case where the prefix in question was sent by a router that has been taken out of service from an IGP standpoint, for instance by utilizing the IS-IS overload bit or by configuring unusually high IGP costs, for instance as described in , the operator's intentions are likely to be different in respect to direct traffic to that prefix. To simplify the language, this draft refers to any of these mechanisms as “overloading” the router. To avoid utilizing the pseudo-protocol’s costs in the case of overloaded routers, an implementation MAY choose not to replace the costs normally derived via the IGP (effectively ignoring the existence of the entry in the key-value store) in the cases where that entry represents a router or prefix which appears to be overloaded. In the case of implementations that have the “IGP Shortcuts Like Implementation” functionality, no cost replacements should happen for any nodes beyond the node that appears to be overloaded either.

The mechanism in this draft solves similar problems as those described in BGP optimal route reflection with the primary differences being the source of the authoritative information for the nexthop replacement cost information as well as the optional implementation approach outlined for IGP Shortcut Like impact on downstream routers. Another draft aimed at similar use cases is which currently proposes utilizing BGP-LS to distribute next hop cost information from a controller or router in the network to the router upon which cost manipulation may happen. The primary difference between this draft and that is the reduced protocol complexity. In networks that use absolute metrics on tunnel infrastructure that influence BGP bestpath decisions, this information is already typically centrally stored, so adding protocol complexity necessary to send this information between routers and then utilize that information received is not necessary for the solution to be implemented. This draft does not require or propose any BGP protocol extensions. Another advantage of this approach than receiving the information from the client is the lack of delay as the router doing the calculation is receiving SPF updates on a similar timeframe as the client and is not waiting for it to finish the calculation and then repackage the information after change into a BGP-LS message to send to the out of band route reflector.

The design does not introduce any additional security concerns. General BGP security considerations are discussed in and .

This document includes no request to IANA.

Thanks to Ina Minei for initial review of this document and helpful suggestions.