Internet DRAFT - draft-chen-route-oscillation-avoid
draft-chen-route-oscillation-avoid
Network Working Group Enke Chen
Internet Draft Redback Networks
Expiration Date: December 2002
BGP Route Oscillation Avoidance for Route Reflection and Confederation
draft-chen-route-oscillation-avoid-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 propose a mechanism and routing setup that would
avoid persistent route oscillations and yield consistent route
selection in a network using one-level Route Reflection, or using
Confederation where routers that participate in inter-member-AS
peering are fully meshed.
Chen [Page 1]
Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002
3. Introduction
As documented in [1], the routing information reduction by BGP Route
Reflection [2], or BGP Confederation [3] can result in persistent
route oscillations with certain network topologies and routing setup.
In this document we propose a mechanism and routing setup that would
avoid persistent route oscillations and yield consistent route
selection in a network using one-level Route Reflection, or using
Confederation where routers that participate in inter-member-AS
peering are fully meshed.
The proposed mechanism makes use of the mechanisms presented in [4,
5], and works within the current BGP protocol [6, 7] that limits
route advertisement to only one path per prefix.
4. Observations on IBGP Updates
Currently a BGP speaker follows the basic BGP principle that only the
best path is advertised to a BGP peer. Since the best path of a
prefix for a BGP speaker is impacted by routes received from internal
peers, the route advertised by the speaker is also impacted by routes
received from internal peers. This dependency can lead to circular
(and possibly excessive) IBGP routing updates, slow convergence, and
persistent route oscillation in the worst case.
The earlier version of BGP [6] specifies that a BGP speaker should
advertise to IBGP its best external route [6, Sect. 9.2.1]. With this
approach the route advertisement toward IBGP peers is independent of
route advertisement received from IBGP peers. In addition, this
approach has the benefit of faster routing convergence compared to
the current practice of advertising the best path.
If clients of a Route Reflector (RR) adopts this approach, and the RR
advertises to other clusters the best path from its clients and
external peers (as proposed in [4]), then the advertisement by the RR
to other clusters would become independent of routes received from
other clusters.
It is based on this observation that we formulate a mechanism and
routing setup that would avoid route oscillations for one-level route
reflection, and for a confederation where routers that participate in
inter-member-AS peering are fully meshed.
Chen [Page 2]
Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002
5. Mechanism for One-level Route Reflection
This mechanism consists of the following procedures and routing
setup:
a) One-level Route Reflection (all RRs are fully meshed).
b) BGP full mesh among clients of a RR.
c) Apply the mechanism in [4] for a RR.
d) A client advertises its best external route to IBGP peers.
Due to c) and d), we claim that with this mechanism and setup the
network is free of route oscillation.
It is noted that due to d) the best external path advertised by a BGP
speaker to an IBGP peer may be different from the overall best path
installed in RIB/FIB. Clearly the difference will not cause any
forwarding loop when the overall best path is also an external path.
When the overall best path for a BGP speaker is from an internal
peer, we claim that the best external path for the speaker will not
be selected as the best path by any other speakers. The proof for
this claim is included in the Appendix.
Therefore we conclude that the route selection consistency is
maintained with the proposed mechanism.
6. Mechanism for Confederation
The mechanism for Confederation consists of the following procedures
and routing setup:
a) BGP full mesh among routers that participate in inter-member-AS
peering.
b) BGP full mesh within a member-AS.
c) Apply the mechanism in [5] for a router that peers with a
neighobring AS in the confederation.
d) For a router that does not participate in inter-member-AS
peering, it should advertises its best external route to peers
within a confederation.
We claim that with the mechanism and routing setup a network would
Chen [Page 3]
Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002
avoid persistent route oscillations and yield consistent route
selection. This claim can be proved similarly.
7. Appendix: Proof of Route Selection Consistency
To simplify presentation, let us describe a general route reflection
setup as follows:
RR1 ---------- RR2 ---------- RR3 --- ... RRn
/ | | | |
/ | | | |
/ | | | |
/ | | | |
C11 C12 C2 C3 ...
| | | | |
| | | | |
(E11) (E12) (E2) (E3) ...
In this figure, there are multiple clusters with RR1, RR2, RR3 as the
route reflectors. C11 and C12 are clients of RR1. C2 is client of
RR2, and C3 is a client of RR3. E11, E12, E2, and E3 are the external
paths. Other than for the purpose of illustration, no restrictions
are imposed on the route reflection topology including the number of
clusters, number of clients, and where and how many external paths
are connected.
Assume that E2 is the best path among all paths received by RR1 from
other clusters, and assume that the EBGP path E11 is not the overall
best path for C11. we try to prove that E11 will not be selected as
the best path by any other routers.
Based on route selection procedures described in [7], E11 can only
lose (on C11) to an IBGP path (either E12 or E2) by either LOCAL-
PREF, or Origin, or AS-PATH Length, or MED. Due to the natural of
these parameters, as long as the overall best path (either E12 or E2)
is present on a router, E11 will continue to lose on the router
irrespective of any other paths.
Due to full IBGP mesh within a cluster, both E12 and E2 are present
on all routers within the cluster. So E11 will not be selected as the
best path by any router within the cluster.
To prove that E11 will not be selected as the best path by a router
in another cluster, we need to consider two cases:
Chen [Page 4]
Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002
(1) Assume E11 is lost to E12 on C11. Then E11 will not selected as
the best path from its clients on RR1, and will not be advertised by
RR1 to other clusters.
(2) Assume E11 is lost to E2 on C11. As RRs are fully meshed, E2 will
be present on all RRs. Thus E11 will not be selected as the best path
by any of the RRs.
Within the cluster served by RR2, E11 will not be selected by its
clients (even if E11 is better than E3 on RR2) as E2 is present.
As E2 is present on RR3, E11 will not be advertised to its clients,
thus will not be selected as the best path by its clients.
8. Security Considerations
This document introduces no new security concerns to BGP or other
specifications referenced in this document.
9. Acknowledgments
The author would like to thank Jenny Yuan for her review and
comments.
10. References
[1] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent
Route Oscillation Condition", Work in Progress (draft-ietf-idr-
route-oscillation-01), February 2002.
[2] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Traina, P., McPherson, D., Scudder, J.. "Autonomous System Con-
federations for BGP", RFC 3065, February 2001.
[4] Chen, E., "BGP Route Oscillation Reduction with Route
Reflection", Work in Progress
(draft-chen-rr-oscillation-reduce-01.txt), June 2002.
[5] Chen, E., "BGP Route Oscillation Reduction with Confederation",
Work in Progress (draft-chen-confed-oscillation-reduce-01.txt),
June 2002.
[6] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Chen [Page 5]
Internet Draft draft-chen-route-oscillation-avoid-00.txt June 2002
RFC 1771, March 1995.
[7] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Work in Progress (draft-ietf-idr-bgp4-17), January 2002
11. Author Information
Enke Chen
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
Email: enke@redback.com
Chen [Page 6]
