A Pseudo-Protocol for BGP Next Hop Cost Manipulation
draft-mitchell-rtgwg-pseudo-bgp-nh-cost-00

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 21, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Implementation Overview
• 3. Implementation Details
• 3.1. Key-Value Store
• 3.2. Cost Replacement Mechanism
• 3.2.1. Simple Implementation Option
• 3.2.2. Alternative Implementation Option (for use with ORR)
• 3.2.3. IGP Shortcuts Like Implementation Option
• 3.2.4. Handling Router Maintenance
• 4. Relationship to Other Work
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

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 [RFC4271], 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.

2. Implementation Overview

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.

3. Implementation Details

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

3.1. Key-Value Store

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 [RFC2328] or IS-IS [RFC1195] when utilizing wide metrics [RFC3784]. 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.

3.2. Cost Replacement Mechanism

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.

3.2.1. Simple Implementation Option

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.

3.2.2. Alternative Implementation Option (for use with ORR)

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 [I-D.ietf-idr-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.

3.2.3. IGP Shortcuts Like Implementation Option

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 [RFC3906], 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 [RFC3906] 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 [RFC5305] for IS-IS or for OSPF, Section 3.4.1 of [RFC3630] or Section 3 of [RFC5329] 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 [RFC3906] with the same end result in respect to the costs used by the BGP path selection process.

3.2.4. Handling Router Maintenance

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 [RFC6987], 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.

4. Relationship to Other Work

The mechanism in this draft solves similar problems as those described in BGP optimal route reflection [I-D.ietf-idr-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 [I-D.ietf-idr-bgp-nh-cost] 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.

5. Security Considerations

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

6. IANA Considerations

This document includes no request to IANA.

7. Acknowledgements

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

8. References

8.1. Normative References

8.2. Informative References

Author's Address