Routing Area Working Group J. Mitchell
Internet-Draft October 19, 2015
Intended status: Informational
Expires: April 21, 2016
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
Mitchell Expires April 21, 2016 [Page 1]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Implementation Overview . . . . . . . . . . . . . . . . . . . 3
3. Implementation Details . . . . . . . . . . . . . . . . . . . 3
3.1. Key-Value Store . . . . . . . . . . . . . . . . . . . . . 3
3.2. Cost Replacement Mechanism . . . . . . . . . . . . . . . 4
3.2.1. Simple Implementation Option . . . . . . . . . . . . 4
3.2.2. Alternative Implementation Option (for use with ORR) 4
3.2.3. IGP Shortcuts Like Implementation Option . . . . . . 5
3.2.4. Handling Router Maintenance . . . . . . . . . . . . . 5
4. Relationship to Other Work . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Mitchell Expires April 21, 2016 [Page 2]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
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:
o A key-value store (e.g. an associative array) for associating
nexthop prefixes to costs
o 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.
Mitchell Expires April 21, 2016 [Page 3]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
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.
Mitchell Expires April 21, 2016 [Page 4]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
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
Mitchell Expires April 21, 2016 [Page 5]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
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.
Mitchell Expires April 21, 2016 [Page 6]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
7. Acknowledgements
Thanks to Ina Minei for initial review of this document and helpful
suggestions.
8. References
8.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
8.2. Informative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/
RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, DOI
10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, DOI 10.17487/RFC3784, June 2004,
<http://www.rfc-editor.org/info/rfc3784>.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, DOI 10.17487/RFC3906, October 2004,
<http://www.rfc-editor.org/info/rfc3906>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
Mitchell Expires April 21, 2016 [Page 7]
Internet-Draft draft-mitchell-rtgwg-pseudo-bgp-nh-cost October 2015
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", RFC
5329, DOI 10.17487/RFC5329, September 2008,
<http://www.rfc-editor.org/info/rfc5329>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI
10.17487/RFC6987, September 2013,
<http://www.rfc-editor.org/info/rfc6987>.
[I-D.ietf-idr-bgp-optimal-route-reflection]
Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S.
Litkowski, "BGP Optimal Route Reflection (BGP-ORR)",
draft-ietf-idr-bgp-optimal-route-reflection-10 (work in
progress), July 2015.
[I-D.ietf-idr-bgp-nh-cost]
Varlashkin, I., Raszuk, R., Patel, K., Bhardwaj, M., and
S. Bayraktar, "Carrying next-hop cost information in BGP",
draft-ietf-idr-bgp-nh-cost-02 (work in progress), May
2015.
Author's Address
Jon Mitchell
Email: jrmitche@puck.nether.net
Mitchell Expires April 21, 2016 [Page 8]