Network Working Group Daniel Walton
Internet Draft Alvaro Retana
Expiration Date: January 2006 Enke Chen
Cisco Systems
BGP Persistent Route Oscillation Solution
draft-walton-bgp-route-oscillation-stop-01.txt
1. Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
In this document we present two sets of paths for an address prefix
that can be advertised by a BGP route reflector or confederation ASBR
to eliminate the MED-type route oscillations in a network. The first
set involves all the available paths, and would achieve the same
routing consistency as the full IBGP mesh. The second set, which is
a subset of the first set, involves the neighbor-AS based Group Best
Paths, and would be sufficient to eliminate the MED-type route
oscillations (subject to certain commonly adopted topological
constrains).
Walton, et al Expiration Date January 2006 [Page 1]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
3. Introduction
As documented in [4], the routing information reduction by BGP Route
Reflection [2] or BGP Confederation [3] can result in persistent IBGP
route oscillations with certain routing setup and network topologies.
Except for a couple artificially engineered network topologies, the
MED attribute [1] has played a pivotal role in virtually all of the
known persistent IBGP route oscillations. For the sake of brevity,
we use the term "MED-type route oscillation" hereafter to refer to a
persistent IBGP route oscillation in which the MED plays a role.
In order to eliminate the MED-type route oscillations and to achieve
consistent routing in a network, clearly a route reflector or a
confederation ASBR needs to advertise more than just the best path
for an address prefix. Our goal is to identify the "right" set of
paths for an address prefix that needs to be advertised by a route
reflector or a confederation ASBR.
In this document we present two sets of paths for an address prefix
that can be advertised by a BGP route reflector or confederation ASBR
to eliminate the MED-type route oscillations in a network. The first
set involves all the available paths, and would achieve the same
routing consistency as the full IBGP mesh. The second set, which is
a set of the first set, involves the neighbor-AS based Group Best
Paths, and would be sufficient to eliminate the MED-type route
oscillations (subject to certain commonly adopted topological
constrains).
These paths can be advertised using the mechanism described in [5]
for advertising multiple paths. The deployment of the mechanisms
requires only minor software changes for the vast majority of the BGP
speakers in a network.
4. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7].
Walton, et al Expiration Date January 2006 [Page 2]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
5. Advertise the Available Paths
Observe that in a network that maintains a full IBGP mesh all the BGP
speakers have consistent and equivalent routing information. Such a
network is thus free of the MED-type route oscillations and other
routing inconsistencies such as forwarding loops.
Therefore one approach is to allow a route reflector or a
confederation ASBR to advertise all the available paths for an
address prefix. Clearly this approach would yield the same amount of
routing information and achieve the same routing consistency as the
full IBGP mesh in a network.
This approach can be implemented using the mechanism described in [5]
for advertising multiple paths, and in this case the path identifier
of a path would be the BGP Identifier of the BGP speaker that
originates the route in the AS (or the Confederation).
6. Advertise the Group Best Paths
The term neighbor-AS for a route refers to the neighboring AS from
which the route was received. The calculation of the neighbor-AS is
specified in Sect. 9.1.2.2 of [1], and Section 7.2 of [3]. By
definition the MED is comparable only among routes with the same
neighbor-AS. As a result, the route selection procedures specified
in [1] would conceptually involve two steps: first organize the paths
for an address prefix into groups according to their respective
neighbor-ASÇÖs, and calculate the most preferred one (termed "Group
Best Path") for each of the groups; Then calculate the overall best
path among all the Group Best Paths.
As a generally recommended [2, 3] and widely adopted practice, a
route reflection cluster or a confederation sub-AS should be designed
such that the IGP metrics for links within a cluster (or
confederation sub-AS) are smaller than the IGP metrics for the links
between the clusters (or confederation sub-AS). This practice helps
achieve consistent routing within a route reflection cluster or a
confederation sub-AS.
Observe also that in a network that maintains full IBGP mesh only the
paths that survive the (Local_Pref, AS-PATH Length, Origin, MED)
comparisons [1] would contribute to the route selection in the
network.
When the aforementioned practice for devising a route reflection
cluster or confederation sub-AS is followed in a network, we claim
that the advertisement of all the Group Best Paths by a route
Walton, et al Expiration Date January 2006 [Page 3]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
reflector or a confederation ASBR is sufficient to eliminate the MED-
type route oscillations in the network. This claim can be validated
as the following.
Consider a route reflection cluster that sources one or more
paths that would survive the (Local_Pref, AS-PATH Length, Origin,
MED) comparisons among all the paths in the network. One of
these surviving paths would be selected as the Group Best Path by
the route reflector in the cluster. Due to the constrain on the
IGP metrics as described previously, this path would remain as
the Group Best Path and would be advertised to all other clusters
even after a path is received from another cluster.
On the other hand, when no path in a route reflection cluster
would survive the (Local_Pref, AS-PATH Length, Origin, MED)
comparisons among all the paths in the network, the Group Best
Path (when exists) for a route reflector would be from another
cluster. Clearly the advertise of the Group Best Path by the
route reflector to the clients only depends on the paths received
from other clusters.
Therefore there is no MED-type route oscillation in the network
as the advertisement of a Group Best Path to a peer does not
depend on the paths received from that peer.
The claim for the confederation can be validated similarly.
Note that a Group Best Path for an address prefix can be identified
by the combination of the address prefix and the neighbor-AS. Thus
this approach can be implemented using the mechanism described in [5]
for advertising multiple paths, and in this case the path identifier
of a path would be the neighbor-AS of the path.
It should be noted that the approach of advertising the Group Best
Paths requires certain topological constrains to be satisfied in
order to eliminate the MED-type route oscillation. In addition, the
BGP speakers still depend on the route selection by the route
reflector or the confederation ASBR. As the route selection involves
the comparison of the nexthopÇÖs IGP metrics which are specific to a
particular BGP speaker, the routing information advertised by a route
reflector or a confederation ASBR may still be inadequate to avoid
other routing inconsistencies such as forwarding loops in certain
networks.
Walton, et al Expiration Date January 2006 [Page 4]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
7. Route Reflection and Confederation
To allow a a route reflector or a confederation ASBR to advertise
either the Available Paths or Group Best Paths using the mechanism
described in [5], the following revisions are proposed for BGP route
reflection and BGP Confederation.
7.1. Route Reflection
Depending on the configuration a route reflector SHOULD include the
<AFI, SAFI, Path Identifier Type> for a particular <AFI, SAFI> in the
ADD-PATH Capability [5] advertised to an IBGP peer. The Path
Identifier Type could either be "AS Number Based", or "BGP Identifier
Based".
A route reflector SHOULD advertise to its clients the Group Best
Paths (or the Available Paths) received from its non-client IBGP
peers.
A route reflector SHOULD advertise to its non-client IBGP peers the
Group Best Paths (or the Available Paths) received from its clients.
A route reflector MAY also advertise to its clients the Group Best
Paths (or the Available Paths) received from its clients.
7.2. Confederation
Depending on the configuration a confederation ASBR SHOULD include
the <AFI, SAFI, Path Identifier Type> for a particular <AFI, SAFI> in
the ADD-PATH Capability [5] advertised to an IBGP peer. The Path
Identifier Type could either be "AS Number Based", or "BGP Identifier
Based".
A confederation ASBR SHOULD advertise to its IBGP peers the Group
Best Paths (or the Available Paths) received from its confederation
external peers.
A confederation ASBR SHOULD advertise to confederation external peers
the Group Best Paths (or the Available Paths) received from its IBGP
peers.
Walton, et al Expiration Date January 2006 [Page 5]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
8. Deployment Considerations
Some route oscillations, once detected, can be eliminated by simple
configuration workarounds. As carrying additional paths impacts the
memory usage and routing convergence in a network, it is recommended
that the impact be evaluated and the approach of using a
configuration workaround be considered in deciding whether to deploy
the proposed mechanism in a network.
While the route reflectors or confederation ASBRs in a network need
to advertise the Group Best Paths or Available Paths, the vast
majority of the BGP speakers in the network only need to receive the
Group Best Paths or Available Paths, which would involve just minor
software changes:
- Advertise the ADD-PATH Capability [5] without any <AFI, SAFI>.
- Process received UPDATE messages based on the address prefix
and the path identifier.
To deploy the mechanism of advertising multiple paths in a network,
it is recommended that the BGP speakers (one at a time) be first
upgraded to a software version that supports the new capability, and
be configured to advertise the new capability without any <AFI,
SAFI>. Then on a per route reflection cluster or confederation sub-
AS basis, the route reflectors or the confederation ASBRs are re-
configured to include the appropriate <AFI, SAFI> in the capability
advertised.
It should be emphasized that in order to eliminate the MED-type route
oscillations in a network using the approach of advertising the Group
Best Paths, the recommended practice for devising a route reflection
cluster or confederation sub-AS with respect to the IGP metrics [2,
3] should be followed.
It is expected that the approach of advertising the Group Best Paths
would be adequate to achieve consistent routing for the vast majority
of the networks. For a network that has large number of alternate
paths, the approach should be a good choice as the number of paths
advertised by a reflector or a confederation ASBR is bounded by the
number of the neighbor-ASÇÖs for a particular address prefix. The
additional states for an address prefix would also be per neighbor-AS
based rather than per path based. The number of the neighbor-ASÇÖs for
a particular address prefix is typically small because of the limited
number of upstream providers for a customer and the nature of
advertising only customer routes at the inter-exchange points.
The approach of advertising the Group Best Paths, however, may still
Walton, et al Expiration Date January 2006 [Page 6]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
be inadequate for certain networks to avoid other routing
inconsistencies such as forwarding loops. The required topological
constrains could also be operationally challenging. In these cases
the approach of advertising the Available Paths may be used. In
general this approach would result in larger number of paths to be
advertised, and may require per-path states to be maintained. Note
that the number of paths that need to be maintained and advertised
can be greatly reduced by accepting the IGP metric based MEDs from
other peering networks.
9. Security Considerations
This extension to BGP does not change the underlying security issues
inherent in the existing BGP [6].
10. Acknowledgments
This document combines prior work on "BGP Persistent Route
Oscillation Solution" by Daniel Walton, David Cook, Alvaro Retana,
and John Scudder, with prior work on "Advertisement of the Group Best
Paths" by Enke Chen, and Naiming Shen. The current authors wish to
thank all these authors for their contribution.
11. References
[1] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
[2] Bates, T., R. Chandra, and E. Chen "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Traina, P., D. McPherson, and J. Scudder, "Autonomous System
Confederations for BGP", RFC 3065, February 2001.
[4] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border Gateway
Protocol (BGP) Persistent Route Oscillation Condition",
RFC 3345, August 2002.
[5] D. Walton, A. Retana, and E. Chen, "Advertisement of Multiple
Paths in BGP", draft-walton-bgp-add-path-03.txt, July 2005.
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Walton, et al Expiration Date January 2006 [Page 7]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
Levels", BCP 14, RFC 2119, March 1997.
12. AuthorsÇÖ Addresses
Daniel Walton
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
Email: dwalton@cisco.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
Email: aretana@cisco.com
Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: enkechen@cisco.com
13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Walton, et al Expiration Date January 2006 [Page 8]
draft-walton-bgp-route-oscillation-stop-01.txt July 2005
14. Full Copyright Notice
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Walton, et al Expiration Date January 2006 [Page 9]
