doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3345.txt b/doc/rfc/rfc3345.txt
new file mode 100644
index 0000000..d79df47
--- /dev/null
+++ b/doc/rfc/rfc3345.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                       D. McPherson
+Request for Comments: 3345                                           TCB
+Category: Informational                                          V. Gill
+                                                   AOL Time Warner, Inc.
+                                                               D. Walton
+                                                               A. Retana
+                                                     Cisco Systems, Inc.
+                                                             August 2002
+
+
+  Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   In particular configurations, the BGP scaling mechanisms defined in
+   "BGP Route Reflection - An Alternative to Full Mesh IBGP" and
+   "Autonomous System Confederations for BGP" will introduce persistent
+   BGP route oscillation.  This document discusses the two types of
+   persistent route oscillation that have been identified, describes
+   when these conditions will occur, and provides some network design
+   guidelines to avoid introducing such occurrences.
+
+1. Introduction
+
+   The Border Gateway Protocol (BGP) is an inter-Autonomous System
+   routing protocol.  The primary function of a BGP speaking system is
+   to exchange network reachability information with other BGP systems.
+
+   In particular configurations, the BGP [1] scaling mechanisms defined
+   in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [2] and
+   "Autonomous System Confederations for BGP" [3] will introduce
+   persistent BGP route oscillation.
+
+   The problem is inherent in the way BGP works: locally defined routing
+   policies may conflict globally, and certain types of conflicts can
+   cause persistent oscillation of the protocol.  Given current
+   practices, we happen to see the problem manifest itself in the
+   context of MED + route reflectors or confederations.
+
+
+
+McPherson, et al.            Informational                      [Page 1]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+   The current specification of BGP-4 [4] states that the
+   MULTI_EXIT_DISC is only comparable between routes learned from the
+   same neighboring AS.  This limitation is consistent with the
+   description of the attribute: "The MULTI_EXIT_DISC attribute may be
+   used on external (inter-AS) links to discriminate among multiple exit
+   or entry points to the same neighboring AS." [1,4]
+
+   In a full mesh iBGP network, all the internal routers have complete
+   visibility of the available exit points into a neighboring AS.  The
+   comparison of the MULTI_EXIT_DISC for only some paths is not a
+   problem.
+
+   Because of the scalability implications of a full mesh iBGP network,
+   two alternatives have been standardized: route reflectors [2] and AS
+   confederations [3].  Both alternatives describe methods by which
+   route distribution may be achieved without a full iBGP mesh in an AS.
+
+   The route reflector alternative defines the ability to re-advertise
+   (reflect) iBGP-learned routes to other iBGP peers once the best path
+   is selected [2].  AS Confederations specify the operation of a
+   collection of autonomous systems under a common administration as a
+   single entity (i.e. from the outside, the internal topology and the
+   existence of separate autonomous systems are not visible).  In both
+   cases, the reduction of the iBGP full mesh results in the fact that
+   not all the BGP speakers in the AS have complete visibility of the
+   available exit points into a neighboring AS.  In fact, the visibility
+   may be partial and inconsistent depending on the location (and
+   function) of the router in the AS.
+
+   In certain topologies involving either route reflectors or
+   confederations (detailed description later in this document), the
+   partial visibility of the available exit points into a neighboring AS
+   may result in an inconsistent best path selection decision as the
+   routers don't have all the relevant information.  If the
+   inconsistencies span more than one peering router, they may result in
+   a persistent route oscillation.  The best path selection rules
+   applied in this document are consistent with the current
+   specification [4].
+
+   The persistent route oscillation behavior is deterministic and can be
+   avoided by employing some rudimentary BGP network design principles
+   until protocol enhancements resolve the problem.
+
+   In the following sections a taxonomy of the types of oscillations is
+   presented and a description of the set of conditions that will
+   trigger route oscillations is given.  We continue by providing
+   several network design alternatives that remove the potential of this
+   occurrence.
+
+
+
+McPherson, et al.            Informational                      [Page 2]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+   It is the intent of the authors that this document serve to increase
+   operator awareness of the problem, as well as to trigger discussion
+   and subsequent proposals for potential protocol enhancements that
+   remove the possibility of this to occur.
+
+   The oscillations are classified into Type I and Type II depending
+   upon the criteria documented below.
+
+2. Discussion of Type I Churn
+
+   In the following two subsections we provide configurations under
+   which Type I Churn will occur.  We begin with a discussion of the
+   problem when using Route Reflection, and then discuss the problem as
+   it relates to AS Confederations.
+
+   In general, Type I Churn occurs only when BOTH of the following
+   conditions are met:
+
+      1) a single-level Route Reflection or AS Confederations design is
+         used in the network AND
+
+      2) the network accepts the BGP MULTI_EXIT_DISC (MED) attribute
+         from two or more ASs for a single prefix and the MED values are
+         unique.
+
+   It is also possible for the non-deterministic ordering of paths to
+   cause the route oscillation problem.  [1] does not specify that paths
+   should be ordered based on MEDs but it has been proven that non-
+   deterministic ordering can lead to loops and inconsistent routing
+   decisions.  Most vendors have either implemented deterministic
+   ordering as default behavior, or provide a knob that permits the
+   operator to configure the router to order paths in a deterministic
+   manner based on MEDs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                      [Page 3]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+2.1. Route Reflection and Type I Churn
+
+   We now discuss Type I oscillation as it relates to Route Reflection.
+   To begin, consider the topology depicted in Figure 1:
+
+      ---------------------------------------------------------------
+    /     --------------------               --------------------     \
+   |    /                      \           /                      \    |
+   |   |       Cluster 1        |         |      Cluster 2         |   |
+   |   |                        |         |                        |   |
+   |   |                        |   *1    |                        |   |
+   |   |         Ra(RR) . . . . . . . . . . . . . . Rd(RR)         |   |
+   |   |         .  .           |         |           .            |   |
+   |   |       .*5    .*4       |         |           .*12         |   |
+   |   |     .          .       |         |           .            |   |
+   |   |   Rb(C)        Rc(C)   |         |         Re(C)          |   |
+   |   |     .            .     |         |           .            |   |
+   |    \    .            .    /           \          .           /    |
+   |      ---.------------.---               ---------.----------      |
+    \        .(10)        .(1)     AS1                .(0)            /
+      -------.------------.---------------------------.--------------
+             .            .                           .
+          ------            .     ------------      .
+        /        \            . /              \   .
+       |   AS10   |            |      AS6       |
+        \        /              \              /
+          ------                  ------------
+                .                      .
+                   .                   .
+                      .       --------------
+                         .  /                \
+                           |      AS100       |- 10.0.0.0/8
+                            \                /
+                              --------------
+
+             Figure 1: Example Route Reflection Topology
+
+   In Figure 1 AS1 contains two Route Reflector Clusters, Clusters 1 and
+   2.  Each Cluster contains one Route Reflector (RR) (i.e., Ra and Rd,
+   respectively).  An associated 'RR' in parentheses represents each RR.
+   Cluster 1 contains two RR Clients (Rb and Rc), and Cluster 2 contains
+   one RR Client (Re).  An associated 'C' in parentheses indicates RR
+   Client status.  The dotted lines are used to represent BGP peering
+   sessions.
+
+   The number contained in parentheses on the AS1 EBGP peering sessions
+   represents the MED value advertised by the peer to be associated with
+   the 10.0.0.0/8 network reachability advertisement.
+
+
+
+McPherson, et al.            Informational                      [Page 4]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+   The number following each '*' on the IBGP peering sessions represents
+   the additive IGP metrics that are to be associated with the BGP
+   NEXT_HOP attribute for the concerned route.  For example, the Ra IGP
+   metric value associated with a NEXT_HOP learned via Rb would be 5;
+   while the metric value associated with the NEXT_HOP learned via Re
+   would be 13.
+
+   Table 1 depicts the 10.0.0.0/8 route attributes as seen by routers
+   Rb, Rc and Re, respectively.  Note that the IGP metrics in Figure 1
+   are only of concern when advertising the route to an IBGP peer.
+
+            Router  MED  AS_PATH
+            --------------------
+            Rb       10   10 100
+            Rc        1    6 100
+            Re        0    6 100
+
+            Table 1: Route Attribute Table
+
+   For the following steps 1 through 5, the best path will be marked
+   with a '*'.
+
+      1) Ra has the following installed in its BGP table, with the path
+         learned via AS2 marked best:
+
+                            NEXT_HOP
+             AS_PATH  MED   IGP Cost
+             -----------------------
+               6 100    1          4
+            * 10 100   10          5
+
+         The '10 100' route should not be marked as best, though this is
+         not the cause of the persistent route oscillation.  Ra realizes
+         it has the wrong route marked as best since the '6 100' path
+         has a lower IGP metric.  As such, Ra makes this change and
+         advertises an UPDATE message to its neighbors to let them know
+         that it now considers the '6 100, 1, 4' route as best.
+
+      2) Rd receives the UPDATE from Ra, which leaves Rd with the
+         following installed in its BGP table:
+
+                            NEXT_HOP
+             AS_PATH  MED   IGP Cost
+             -----------------------
+            *  6 100    0         12
+               6 100    1          5
+
+
+
+
+
+McPherson, et al.            Informational                      [Page 5]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+         Rd then marks the '6 100, 0, 12' route as best because it has a
+         lower MED.  Rd sends an UPDATE message to its neighbors to let
+         them know that this is the best route.
+
+      3) Ra receives the UPDATE message from Rd and now has the
+         following in its BGP table:
+
+                            NEXT_HOP
+             AS_PATH  MED   IGP Cost
+             -----------------------
+               6 100    0         13
+               6 100    1          4
+            * 10 100   10          5
+
+         The first route (6 100, 0, 13) beats the second route (6 100,
+         1, 4) because of a lower MED.  Then the third route (10 100,
+         10, 5) beats the first route because of lower IGP metric to
+         NEXT_HOP.  Ra sends an UPDATE message to its peers informing
+         them of the new best route.
+
+      4) Rd receives the UPDATE message from Ra, which leaves Rd with
+         the following BGP table:
+
+                            NEXT_HOP
+             AS_PATH  MED   IGP Cost
+             -----------------------
+               6 100    0         12
+            * 10 100   10          6
+
+         Rd selects the '10 100, 10, 6' path as best because of the IGP
+         metric.  Rd sends an UPDATE/withdraw to its peers letting them
+         know this is the best route.
+
+      5) Ra receives the UPDATE message from Rd, which leaves Ra with
+         the following BGP table:
+
+                            NEXT_HOP
+             AS_PATH  MED   IGP Cost
+             -----------------------
+               6 100    1          4
+            * 10 100   10          5
+
+         Ra received an UPDATE/withdraw for '6 100, 0, 13', which
+         changes what is considered the best route for Ra.  This is why
+         Ra has the '10 100, 10, 5' route selected as best in Step 1,
+         even though '6 100, 1, 4' is actually better.
+
+
+
+
+
+McPherson, et al.            Informational                      [Page 6]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+      At this point, we've made a full loop and are back at Step 1.  The
+      router realizes it is using the incorrect best path, and repeats
+      the cycle.  This is an example of Type I Churn when using Route
+      Reflection.
+
+2.2. AS Confederations and Type I Churn
+
+   Now we provide an example of Type I Churn occurring with AS
+   Confederations.  To begin, consider the topology depicted in Figure
+   2:
+
+     ---------------------------------------------------------------
+   /     --------------------               --------------------     \
+  |    /                      \           /                      \    |
+  |   |       Sub-AS 65000     |         |      Sub-AS 65001      |   |
+  |   |                        |         |                        |   |
+  |   |                        |   *1    |                        |   |
+  |   |         Ra . . . . . . . . . . . . . . . . . Rd           |   |
+  |   |         .  .           |         |           .            |   |
+  |   |       .*3    .*2       |         |           .*6          |   |
+  |   |     .          .       |         |           .            |   |
+  |   |    Rb . . . . . Rc     |         |          Re            |   |
+  |   |     .    *5      .     |         |           .            |   |
+  |    \    .            .    /           \          .           /    |
+  |      ---.------------.---               ---------.----------      |
+   \        .(10)        .(1)     AS1                .(0)            /
+     -------.------------.---------------------------.--------------
+            .            .                           .
+         ------            .     ------------      .
+       /        \            . /              \  .
+      |   AS10   |            |      AS6       |
+       \        /              \              /
+         ------                  ------------
+               .                      .
+                  .                   .
+                     .       --------------
+                        .  /                \
+                          |      AS100       |- 10.0.0.0/8
+                           \                /
+                             --------------
+
+            Figure 2: Example AS Confederations Topology
+
+   The number contained in parentheses on each AS1 EBGP peering session
+   represents the MED value advertised by the peer to be associated with
+   the 10.0.0.0/8 network reachability advertisement.
+
+
+
+
+
+McPherson, et al.            Informational                      [Page 7]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+   The number following each '*' on the IBGP peering sessions represents
+   the additive IGP metrics that are to be associated with the BGP
+   NEXT_HOP attribute for the concerned route.
+
+   For example, the Ra IGP metric value associated with a NEXT_HOP
+   learned via Rb would be 3; while the metric value associated with the
+   NEXT_HOP learned via Re would be 6.
+
+   Table 2 depicts the 10.0.0.0/8 route attributes as seen by routers
+   Rb, Rc and Re, respectively.  Note that the IGP metrics in Figure 2
+   are only of concern when advertising the route to an IBGP peer.
+
+         Router  MED  AS_PATH
+         --------------------
+         Rb       10   10 100
+         Rc        1    6 100
+         Re        0    6 100
+
+         Table 2: Route Attribute Table
+
+   For the following steps 1 through 6 the best route will be marked
+   with an '*'.
+
+      1) Ra has the following BGP table:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+            *         10 100   10          3
+               (65001) 6 100    0          7
+                       6 100    1          2
+
+         The '10 100' route is selected as best and is advertised to Rd,
+         though this is not the cause of the persistent route
+         oscillation.
+
+      2) Rd has the following in its BGP table:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+                       6 100    0          6
+            * (65000) 10 100   10          4
+
+         The '(65000) 10 100' route is selected as best because it has
+         the lowest IGP metric.  As a result, Rd sends an
+         UPDATE/withdraw to Ra for the '6 100' route that it had
+         previously advertised.
+
+
+
+McPherson, et al.            Informational                      [Page 8]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+      3) Ra receives the withdraw from Rd.  Ra now has the following in
+         its BGP table:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+            *         10 100   10          3
+                       6 100    1          2
+
+         Ra received a withdraw for '(65001) 6 100', which changes what
+         is considered the best route for Ra.  Ra does not compute the
+         best path for a prefix unless its best route was withdrawn.
+         This is why Ra has the '10 100, 10, 3' route selected as best,
+         even though the '6 100, 1, 2' route is better.
+
+      4) Ra's periodic BGP scanner runs and realizes that the '6 100'
+         route is better because of the lower IGP metric.  Ra sends an
+         UPDATE/withdraw to Rd for the '10 100' route since Ra is now
+         using the '6 100' path as its best route.
+
+         Ra's BGP table looks like this:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+                      10 100   10          3
+            *          6 100    1          2
+
+      5) Rd receives the UPDATE from Ra and now has the following in its
+         BGP table:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+               (65000) 6 100    1          3
+            *          6 100    0          6
+
+         Rd selects the '6 100, 0, 6' route as best because of the lower
+         MED value.  Rd sends an UPDATE message to Ra, reporting that '6
+         100, 0, 6' is now the best route.
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                      [Page 9]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+      6) Ra receives the UPDATE from Rd.  Ra now has the following in
+         its BGP table:
+
+                                    NEXT_HOP
+                     AS_PATH  MED   IGP Cost
+             -------------------------------
+            *         10 100   10          3
+               (65001) 6 100    0          7
+                       6 100    1          2
+
+         At this point we have made a full cycle and are back to step 1.
+         This is an example of Type I Churn with AS Confederations.
+
+2.3. Potential Workarounds for Type I Churn
+
+   There are a number of alternatives that can be employed to avoid this
+   problem:
+
+      1) When using Route Reflection make sure that the inter-Cluster
+         links have a higher IGP metric than the intra-Cluster links.
+         This is the preferred choice when using Route Reflection.  Had
+         the inter-Cluster IGP metrics been much larger than the intra-
+         Cluster IGP metrics, the above would not have occurred.
+
+      2) When using AS Confederations ensure that the inter-Sub-AS links
+         have a higher IGP metric than the intra-Sub-AS links.  This is
+         the preferred option when using AS Confederations.  Had the
+         inter-Sub-AS IGP metrics been much larger than the intra-Sub-AS
+         IGP metrics, the above would not have occurred.
+
+      3) Do not accept MEDs from peers (this may not be a feasible
+         alternative).
+
+      4) Utilize other BGP attributes higher in the decision process so
+         that the BGP decision algorithm never reaches the MED step.  As
+         using this completely overrides MEDs, Option 3 may make more
+         sense.
+
+      5) Always compare BGP MEDs, regardless of whether or not they were
+         obtained from a single AS.  This is probably a bad idea since
+         MEDs may be derived in a number of ways, and are typically done
+         so as a matter of operator-specific policy.  As such, comparing
+         MED values for a single prefix learned from multiple ASs is
+         ill-advised.  Of course, this mostly defeats the purpose of
+         MEDs, and as such, Option 3 may be a more viable alternative.
+
+      6) Use a full IBGP mesh.  This is not a feasible solution for ASs
+         with a large number of BGP speakers.
+
+
+
+McPherson, et al.            Informational                     [Page 10]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+3. Discussion of Type II Churn
+
+   In the following subsection we provide configurations under which
+   Type II Churn will occur when using AS Confederations.  For the sake
+   of brevity, we avoid similar discussion of the occurrence when using
+   Route Reflection.
+
+   In general, Type II churn occurs only when BOTH of the following
+   conditions are met:
+
+      1) More than one tier of Route Reflection or Sub-ASs is used in
+         the network AND
+
+      2) the network accepts the BGP MULTI_EXIT_DISC (MED) attribute
+         from two or more ASs for a single prefix and the MED values are
+         unique.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 11]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+3.1. AS Confederations and Type II Churn
+
+   Let's now examine the occurrence of Type II Churn as it relates to AS
+   Confederations.  Figure 3 provides our sample topology:
+
+     ---------------------------------------------------------------
+   /                     -------------------                          \
+  |      AS 1          /      Sub-AS 65500   \                         |
+  |                   |                       |                        |
+  |                   |    Rc . . . . Rd      |                        |
+  |                   |    .   *2      .      |                        |
+  |                    \  .              .   /                         |
+  |                      .-----------------.                           |
+  |                     .*40                 .*40                      |
+  |      --------------.-----                --.-----------------      |
+  |    /              .        \           /     .                \    |
+  |   |   Sub-AS     .          |         |        .      Sub-AS   |   |
+  |   |    65501    .           |         |          .     65502   |   |
+  |   |          Rb             |         |         Re             |   |
+  |   |          .              |         |        . .             |   |
+  |   |          .*10           |         |     *2.   .*3          |   |
+  |   |          .              |         |      .     .           |   |
+  |   |          Ra             |         |  . Rg . . . Rf         |   |
+  |    \          .            /           .             .        /    |
+  |      ----------.----------           .  -------------.-------      |
+   \                .(0)               .(1)              .()          /
+     ----------------.---------------.-------------------.----------
+
+                     .            .                     .
+                      ---------  .                  ---------
+                      |AS 200 |                     |AS 300 |
+                      ---------                     ---------
+                              .                     .
+                                .                 .
+                                -------------------
+                                |      AS 400     | - 10.0.0.0/8
+                                -------------------
+
+            Figure 3: Example AS Confederations Topology
+
+   In Figure 3 AS 1 contains three Sub-ASs, 65500, 65501 and 65502.  No
+   RR is used within the Sub-AS, and as such, all routers within each
+   Sub-AS are fully meshed.  Ra and Rb are members of Sub-AS 65501.  Rc
+   and Rd are members of Sub-AS 65500.  Ra and Rg are EBGP peering with
+   AS 200, router Rf has an EBGP peering with AS 300.  AS 200 and AS 300
+   provide transit for AS 400, and in particular, the 10/8 network.  The
+   dotted lines are used to represent BGP peering sessions.
+
+
+
+
+McPherson, et al.            Informational                     [Page 12]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+   The number following each '*' on the BGP peering sessions represents
+   the additive IGP metrics that are to be associated with the BGP
+   NEXT_HOP.  The number contained in parentheses on each AS 1 EBGP
+   peering session represents the MED value advertised by the peer to be
+   associated with the network reachability advertisement (10.0.0.0/8).
+
+   Rc, Rd and Re are the primary routers involved in the churn, and as
+   such, will be the only BGP tables that we will monitor step by step.
+
+   For the following steps 1 through 8 each router's best route will be
+   marked with a '*'.
+
+      1) Re receives the AS 400 10.0.0.0/8 route advertisement via AS
+         200 from Rg and AS 300 from Rf.  Re selects the path via Rg and
+         AS 200 because of IGP metric (Re didn't consider MED because
+         the advertisements were received from different ASs).
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Re   * 200 400    1          2
+                   300 400               3
+
+         Re sends an UPDATE message to Rd advertising its new best path
+         '200 400, 1'.
+
+      2) The '200 400, 0' path was advertised from Ra to Rb, and then
+         from Rb to Rc.  Rd learns the '200 400, 1' path from Re.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            -------------------------------
+            Rc   * 200 400   0         50
+            Rd   * 200 400   1         42
+            Re     300 400              3
+                 * 200 400   1          2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 13]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+      3) Rc and Rd advertise their best paths to each other; Rd selects
+         '200 400, 0' because of the MED.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc   * 200 400   0         50
+                   200 400   1         44
+            Rd   * 200 400   0         52
+                   200 400   1         42
+            Re     300 400              3
+                 * 200 400   1          2
+
+         Rd has a new best path so it sends an UPDATE to to Re,
+         announcing the new path and an UPDATE/withdraw for '200 400, 1'
+         to Rc.
+
+      4) Re now selects '300 400' (with no MED) because '200 400, 0'
+         beats '200 400, 1' based on MED and '300 400' beats '200 400,
+         0' because of IGP metric.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc   * 200 400    0         50
+            Rd   * 200 400    0         52
+                   200 400    1         42
+            Re   * 300 400               3
+                   200 400    0         92
+
+         Re has a new best path and sends an UPDATE to Rd for '300 400'.
+
+   5) Rd selects the '300 400' path because of IGP metric.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc   * 200 400    0         50
+            Rd     200 400    0         52
+                 * 300 400              43
+            Re   * 300 400               3
+                   200 400    0         92
+                   200 400    1          2
+
+         Rd has a new best path so it sends an UPDATE to Rc and a
+         UPDATE/withdraw to Re for '200 400, 0'.
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 14]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+      6) Rc selects '300 400' because of the IGP metric.  Re selects
+         '200 400, 1' because of the IGP metric.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc     200 400    0         50
+                 * 300 400              45
+            Rd     200 400    0         52
+                 * 300 400              43
+            Re     300 400               3
+                 * 200 400    1          2
+
+         Rc sends an UPDATE/withdraw for '200 400, 0' to Rd.  Re sends
+         an UPDATE for '200 400, 1' to Rd.
+
+      7) Rd selects '200 400, 1' as its new best path based on the IGP
+         metric.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc     200 400    0         50
+                 * 300 400              45
+            Rd   * 200 400    1         42
+            Re     300 400               3
+                 * 200 400    1          2
+
+         Rd sends an UPDATE to Rc, announcing '200 400, 1' and
+         implicitly withdraws '300 400'.
+
+      8) Rc selects '200 400, 0'.
+
+                                  NEXT_HOP
+            Router AS_PATH  MED   IGP Cost
+            ------------------------------
+            Rc   * 200 400    0         50
+                   200 400    1         44
+            Rd   * 200 400    1         42
+            Re     300 400               3
+                 * 200 400    1          2
+
+         At this point we are back to Step 2 and are in a loop.
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 15]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+3.2. Potential Workarounds for Type II Churn
+
+   1) Do not accept MEDs from peers (this may not be a feasible
+      alternative).
+
+   2) Utilize other BGP attributes higher in the decision process so
+      that the BGP decision algorithm selects a single AS before it
+      reaches the MED step.  For example, if local-pref were set based
+      on the advertising AS, then you first eliminate all routes except
+      those in a single AS.  In the example, router Re would pick either
+      X or Y based on your local-pref and never change selections.
+
+      This leaves two simple workarounds for the two types of problems.
+
+      Type I:  Make inter-cluster or inter-sub-AS link metrics higher
+      than intra-cluster or intra-sub-AS metrics.
+
+      Type II: Make route selections based on local-pref assigned to the
+      advertising AS first and then use IGP cost and MED to make
+      selection among routes from the same AS.
+
+      Note that this requires per-prefix policies, as well as near
+      intimate knowledge of other networks by the network operator.  The
+      authors are not aware of ANY [large] provider today that performs
+      per-prefix policies on routes learned from peers.  Implicitly
+      removing this dynamic portion of route selection does not appear
+      to be a viable option in today's networks.  The main point is that
+      an available workaround using local-pref so that no two AS's
+      advertise a given prefix at the same local-pref solves type II
+      churn.
+
+   3) Always compare BGP MEDs, regardless of whether or not they were
+      obtained from a single AS.  This is probably a bad idea since MEDs
+      may be derived in a number of ways, and are typically done so as a
+      matter of operator-specific policy and largely a function of
+      available metric space provided by the employed IGP.  As such,
+      comparing MED values for a single prefix learned from multiple ASs
+      is ill-advised.  This mostly defeats the purpose of MEDs; Option 1
+      may be a more viable alternative.
+
+   4) Do not use more than one tier of Route Reflection or Sub-ASs in
+      the network.   The risk of route oscillation should be considered
+      when designing networks that might use a multi-tiered routing
+      isolation architecture.
+
+   5) In a RR topology, mesh the clients.  For confederations, mesh the
+      border routers at each level in the hierarchy.  In Figure 3, for
+      example, if Rb and Re are peers, then there's no churn.
+
+
+
+McPherson, et al.            Informational                     [Page 16]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+4. Future Work
+
+   It should be stated that protocol enhancements regarding this problem
+   must be pursued.  Imposing network design requirements, such as those
+   outlined above, are clearly an unreasonable long-term solution.
+   Problems such as this should not occur under 'default' protocol
+   configurations.
+
+5. Security Considerations
+
+   This discussion introduces no new security concerns to BGP or other
+   specifications referenced in this document.
+
+6. Acknowledgments
+
+   The authors would like to thank Curtis Villamizar, Tim Griffin, John
+   Scudder, Ron Da Silva, Jeffrey Haas and Bill Fenner.
+
+7. References
+
+   [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
+       1771, March 1995.
+
+   [2] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An
+       Alternative to Full Mesh IBGP", RFC 2796, April 2000.
+
+   [3] Traina, P., McPherson, D. and J. Scudder, J., "Autonomous System
+       Confederations for BGP", RFC 3065, February 2001.
+
+   [4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
+       Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 17]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+8. Authors' Addresses
+
+   Danny McPherson
+   TCB
+   EMail: danny@tcb.net
+
+
+   Vijay Gill
+   AOL Time Warner, Inc.
+   12100 Sunrise Valley Drive
+   Reston, VA 20191
+   EMail: vijay@umbc.edu
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 18]
+
+RFC 3345       BGP Persistent Route Oscillation Condition    August 2002
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.            Informational                     [Page 19]
+