draft-ietf-idr-add-paths-guidelines-00.txt   draft-ietf-idr-add-paths-guidelines-01.txt 
Network Working Group J. Uttaro Network Working Group J. Uttaro
Internet Draft AT&T Internet Draft AT&T
Intended status: Standards Track V. Van den Schrieck Intended status: Standards Track V. Van den Schrieck
November 24, 2010 P. Francois May 25, 2011 P. Francois
Expires: May 24, 2011 UCLouvain Expires: Nov 25, 2011 UCLouvain
R. Fragassi R. Fragassi
A. Simpson A. Simpson
Alcatel-Lucent Alcatel-Lucent
P. Mohapatra P. Mohapatra
Cisco Systems Cisco Systems
Best Practices for Advertisement of Multiple Paths in BGP Best Practices for Advertisement of Multiple Paths in IBGP
draft-ietf-idr-add-paths-guidelines-00.txt draft-ietf-idr-add-paths-guidelines-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 24, 2011. This Internet-Draft will expire on Nov 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.1. Fast Connectivity Restoration.............................5 3.1. Fast Connectivity Restoration.............................5
3.2. Load Balancing............................................7 3.2. Load Balancing............................................7
3.3. Churn Reduction...........................................7 3.3. Churn Reduction...........................................7
3.4. Suppression of MED-Related Persistent Route Oscillation...7 3.4. Suppression of MED-Related Persistent Route Oscillation...7
4. Implementation Guidelines......................................8 4. Implementation Guidelines......................................8
4.1. Capability Negotiation....................................8 4.1. Capability Negotiation....................................8
4.2. Receiving Multiple Paths..................................9 4.2. Receiving Multiple Paths..................................9
4.3. Advertising Multiple Paths................................9 4.3. Advertising Multiple Paths................................9
4.3.1. Path Selection Modes................................11 4.3.1. Path Selection Modes................................11
4.3.1.1. Advertise All Paths............................11 4.3.1.1. Advertise All Paths............................11
4.3.1.2. Advertise N Paths..............................11 4.3.1.2. Advertise N Paths..............................12
4.3.1.3. Advertise All AS-Wide Best Paths...............12 4.3.1.3. Advertise All AS-Wide Best Paths...............12
4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths 4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths
(Double AS Wide)........................................13 (Double AS Wide)........................................13
4.3.2. Derived Modes from Bounding the Number of Advertised 4.3.2. Derived Modes from Bounding the Number of Advertised
Paths......................................................14 Paths......................................................14
5. Scalability and Routing Consistency Considerations............14 5. Deployment Considerations.....................................14
5.1. Scalability Considerations...............................14 5.1. Introducing Add-Paths into an Existing Network...........14
5.2. Routing Consistency Considerations.......................14 5.2. Scalability Considerations...............................16
5.3. Consistency between Advertised Paths and Forwarding Paths15 5.3. Routing Consistency Considerations.......................17
6. Security Considerations.......................................16 5.4. Consistency between Advertised Paths and Forwarding Paths17
7. IANA Considerations...........................................16 5.5. Routing Churn............................................18
8. Conclusions...................................................16 6. Security Considerations.......................................18
9. References....................................................16 7. IANA Considerations...........................................18
9.1. Normative References.....................................16 8. Conclusions...................................................18
9.2. Informative References...................................16 9. References....................................................19
10. Acknowledgments..............................................17 9.1. Normative References.....................................19
Appendix A. Other Path Selection Modes...........................18 9.2. Informative References...................................19
A.1. Advertise Neighbor-AS Group Best Path....................18 10. Acknowledgments..............................................19
A.2. Best LocPref/Second LocPref..............................18 Appendix A. Other Path Selection Modes...........................20
A.3. Advertise Paths at decisive step -1......................19 A.1. Advertise Neighbor-AS Group Best Path....................20
A.2. Best LocPref/Second LocPref..............................20
A.3. Advertise Paths at decisive step -1......................21
1. Introduction 1. Introduction
The BGP Add-Paths capability enhances current BGP implementations by The BGP Add-Paths capability enhances current BGP implementations by
allowing a BGP router to exchange with its BGP peers more than one allowing a BGP router to exchange with its BGP peers more than one
path for the same destination/NLRI. The base BGP standard [RFC 4271] path for the same destination/NLRI. The base BGP standard [RFC 4271]
does not provide for such a capability. If a BGP router learns does not provide for such a capability. If a BGP router learns
multiple paths for the same NLRI (from multiple peers), it selects multiple paths for the same NLRI (from multiple peers), it selects
only one as its best path and advertises the best path to its peers. only one as its best path and advertises the best path to its peers.
The primary goal of Add-Paths is to increase the visibility of paths The primary goal of Add-Paths is to increase the visibility of paths
skipping to change at page 4, line 42 skipping to change at page 4, line 42
In this document the following terms are used: In this document the following terms are used:
Add-Paths peer: refers a peer with which the local system has agreed Add-Paths peer: refers a peer with which the local system has agreed
to receive and/or send NLRI with path identifiers to receive and/or send NLRI with path identifiers
Primary path: A path toward a prefix that is considered a best path Primary path: A path toward a prefix that is considered a best path
by the BGP decision process [RFC 4271] and actively used for by the BGP decision process [RFC 4271] and actively used for
forwarding traffic to that prefix. A router may have multiple primary forwarding traffic to that prefix. A router may have multiple primary
paths for a prefix if it implements multipath. paths for a prefix if it implements multipath.
Backup path: One of the non-best paths toward a prefix. Diverse path: A BGP path associated with a different BGP next-hop and
BGP router than some other set of paths. The BGP router associated
with a path is inferred from the ORIGINATOR_ID attribute or, if there
is none, the BGP Identifier of the peer that advertised the path.
Optimal backup path: the backup path that will be selected as the new Backup path: A diverse path with respect to the primary paths toward
a prefix. The backup path can be used to forward traffic to the
destination if the primary paths fail.
Optimal backup path: The backup path that will be selected as the new
best path for a prefix when all primary paths are removed/withdrawn. best path for a prefix when all primary paths are removed/withdrawn.
AS-Wide preferred paths: All paths that are considered as best when AS-Wide preferred paths: All paths that are considered as best when
applying rules of the BGP decision process up to the IGP tie-break. applying rules of the BGP decision process up to the IGP tie-break.
Path diversity: The property that a router has several paths for a
given prefix and each one is associated with a unique BGP next-hop
(and BGP router).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
3. Add-Paths Applications 3. Add-Paths Applications
[draft-pmohapat] presents the applications that would benefit from [draft-pmohapat] presents the applications that would benefit from
multiple paths advertisement in iBGP. They are summarized in the multiple paths advertisement in iBGP. They are summarized in the
following subsections. following subsections.
skipping to change at page 5, line 30 skipping to change at page 5, line 32
With the dissemination of backup paths, fast connectivity restoration With the dissemination of backup paths, fast connectivity restoration
and convergence can be achieved. If a router has a backup path, it and convergence can be achieved. If a router has a backup path, it
can directly select that path as best upon failure of the primary can directly select that path as best upon failure of the primary
path. This minimizes packet loss in the dataplane. Sending multiple path. This minimizes packet loss in the dataplane. Sending multiple
paths in iBGP allows routers to receive backup paths when path paths in iBGP allows routers to receive backup paths when path
visibility is not sufficient with classical BGP. This is especially visibility is not sufficient with classical BGP. This is especially
useful when Route Reflection is used. useful when Route Reflection is used.
Consider a network such as the one depicted in Figure 1 and suppose Consider a network such as the one depicted in Figure 1 and suppose
that none of the routers support Add-Paths. From AS1 there are 3 that none of the routers support Add-Paths. AS1 receives from AS3 2
paths (A, B and C) to a particular destination XYZ: two of the paths paths (A and B) to a particular destination XYZ. Suppose path A is
are via AS3 and one of the paths is via AS2. In this example, Path A preferred over path B due to path A having a lower MED (multi-exit
is preferred over Path B due to Path A having a lower MED (multi-exit discriminator).
discriminator) (MED for Path A is lower than MED for path B).
AS1 uses a route reflector RR1 to reduce the scale of its IBGP mesh. AS1 uses a route reflector RR1 to reduce the scale of its IBGP mesh.
During steady state, RR1 knows about (has in its RIB-IN) only 2 of If the routers in AS1 are not configured for best-external then RR1
the 3 paths. Router B suppresses the advertisement of its best knows about only path A during steady state because router B
external path (B) to RR, an IBGP peer, because its best overall path suppresses/withdraws its advertisement of path (B) to RR1. If the
is A, learnt from router A (via the RR). RR1 chooses path A as the routers in AS1 do support best-external then RR1 may have both paths
overall best since its IGP cost to router A is the lowest among path in its Adj-RIB-IN, but regardless of the best-external configuration
A and C. During normal conditions, router D has even less knowledge RR1 can only advertise its best path A to its peers, including router
of the available paths to destination XYZ; it knows only about path D.
(A), the best path from RR1's perspective.
======== ===================== ======== =====================
= +---+ +---+ +---+ = +---+ +---+ +---+
= |RTR|________|RTR| |RTR| = |RTR|________|RTR| |RTR|
= | E | | A | | C |\ <-Path C = | E | | A | | C |
= +---+Path A->+---+ AS1 +---+ \ = +---+Path A->+---+ AS1 +---+
= = = \ / = \ ======= = = = \ / =
= = = \ / = +---+ = = = = \ / =
= = = \ / = |RTR| = = = = \ / =
= = = \ / = | G | = = = = \ / =
= AS3 = = +---+ = +---+ = = AS3 = = +---+ =
= = = |RR | = = = = = = |RR | =
= = = | 1 | = = AS2 = = = = | 1 | =
= = = +---+ = ======= = = = +---+ =
= = = / \ = = = = / \ =
= = = / \ = = = = / \ =
= = = / \ = = = = / \ =
= = = / \ = = = = / \ =
= +---+Path B->+---+ +---+ = +---+Path B->+---+ +---+
= |RTR| ______|RTR| |RTR| = |RTR| ______|RTR| |RTR|
= | F | | B | | D | = | F | | B | | D |
= +---+ +---+ +---+ = +---+ +---+ +---+
======== ===================== ======== =====================
Figure 1: Example Topology Figure 1: Example Topology
Consider now the steps required to restore traffic from router D to Under these circumstances consider the steps required to restore
destination XYZ when the link between Router A and Router E fails. traffic from router D to destination XYZ when the link between Router
A and Router E fails. (Assume that router A set next-hop to self when
advertising path A and that router B is not configured for best-
external).
1. Router A sends a BGP UPDATE message withdrawing its advertisement 1. Router A sends a BGP UPDATE message withdrawing its advertisement
of path (A). of path (A).
2. RR receives the withdrawal, and propagates it to its other client 2. RR1 receives the withdrawal, and propagates it to its other client
peers, routers B, C and D. peers, routers B, C and D.
3. When router B receives the withdrawal of path (A) it reruns its 3. When router B receives the withdrawal of path (A) it reruns its
decision process and selects path (B) as its new best path. Router decision process and selects path (B) as its new best path. Router
B advertises path (B) to RR. B advertises path (B) to RR1.
4. RR reruns its decision process and selects path (B) as its new 4. RR1 reruns its decision process and selects path (B) as its new
best path. RR advertises path (B) to client peers A, C and D. best path. RR1 advertises path (B) to client peers A, C and D.
5. Router D reruns its decisions process, determines path (B) to be 5. Router D reruns its decisions process, determines path (B) to be
the best path, and updates its forwarding table. After this step the best path, and updates its forwarding table. After this step
traffic from router D to destination XYZ is restored (the traffic traffic from router D to destination XYZ is restored (the traffic
path has changed from A to B). path has changed from A to B).
With the use of Add-Paths, the convergence time for the above path With the use of Add-Paths, the convergence time for the above path
failure example can be reduced considerably. The main reason for the failure example can be reduced considerably. The main reason for the
improvement is that Add-Paths allows router D to be aware of more improvement is that Add-Paths allows router D to be aware of more
than one path to destination XYZ prior to the failure of the best than one path to destination XYZ prior to the failure of the best
path (A). In steady-state (with no failures) router B decides, as path (A). In steady-state (with no failures) router B decides, as
before, that path (A) is its best path but it also advertises path before, that path (A) is its best path but because of its Add-Paths
(B) - which happens to be its next-best overall path and its best (or best-external) configuration it also advertises path (B) to RR1.
"external" path - to RR. With Add-Paths RR1 now has knowledge of all Using Add-Paths RR1 can advertise both learned paths to its IBGP
3 paths to destination XYZ and it can advertise more than just the peers, including router D. Now consider again the scenario where the
best path (A) to its peers. Suppose RR1 is allowed to advertise up to link between Router A and Router E fails. In this case, with Add-
3 paths for destination XYZ. In this case, with the appropriate path Paths, fewer steps are required to achieve re-convergence:
selection algorithm, it will advertise paths (A), (B) and (C) to
router D. Now consider again the scenario where the link between
Router A and Router E fails. In this case, with Add-Paths, fewer
steps are required to achieve re-convergence:
1. Router A sends a BGP UPDATE message withdrawing its advertisement 1. Router A sends a BGP UPDATE message withdrawing its advertisement
of path (A). of path (A).
2. RR1 receives the withdrawal, and propagates it to its other client 2. RR1 receives the withdrawal, and propagates it to its other client
peers, routers B, C and D. peers, routers B, C and D.
3. Router D receives the withdrawal, reruns the decision process and 3. Router D receives the withdrawal, reruns the decision process and
updates the forwarding entry for destination XYZ. updates the forwarding entry for destination XYZ.
3.2. Load Balancing 3.2. Load Balancing
Increased path diversity allows routers to install several paths in Increased path diversity allows routers to install several paths in
their forwarding tables in order to load balance traffic across those their forwarding tables in order to load balance traffic across those
paths. paths.
3.3. Churn Reduction 3.3. Churn Reduction
When Add-Paths is used in an AS, the availability of additional When Add-Paths is used in an AS, the availability of additional
backup paths means failures can be recovered locally with much less backup paths means failures can be recovered locally with much less
path exploration in iBGP and therefore less Updates disseminated in path exploration in iBGP and therefore less updates disseminated in
eBGP. When the preferred backup path is the post-convergence path, eBGP. When the preferred backup path is the post-convergence path,
churn is minimized. churn is minimized.
3.4. Suppression of MED-Related Persistent Route Oscillation 3.4. Suppression of MED-Related Persistent Route Oscillation
As described in [oscillation], Add-Paths is a valuable tool in As described in [oscillation], Add-Paths is a valuable tool in
helping to stop persistent route oscillations caused by comparison of helping to stop persistent route oscillations caused by comparison of
paths based on MED in topologies where route reflectors or the paths based on MED in topologies where route reflectors or the
confederation structure hide some paths. With the appropriate path confederation structure hide some paths. With the appropriate path
selection algorithm Add-Paths stops these route oscillations because selection algorithm Add-Paths stops these route oscillations because
the same set of paths are consistently advertised by the route the same set of paths are consistently advertised by the route
reflector or the confederation border router and the routers reflector or the confederation border router and the routers
receiving this set of paths make stable routing decisions about the receiving this set of paths make stable routing decisions about the
best path. best path.
4. Implementation Guidelines 4. Implementation Guidelines
In this section, we discuss recommendations for the implementation of This section discusses recommendations for the implementation of Add-
add-paths. We first discuss the BGP capability negotiations related Paths. The following topics are addressed:
to the use of Add-paths among iBGP peers, as well as their
configuration aspects. Next, we provide an overview of RIB-IN . Considerations related to Add-Paths capability negotiation
management issues for the support of Add-paths. Finally, we discuss
the properties of various algorithms for the selection of the paths . Receiving BGP routes from Add-Paths peers
to be advertised by a BGP speaker supporting Add-paths. The goal of
this last section is to recommend, in future revisions of the draft, . Advertising BGP routes to Add-Paths peers. This section
a default paths selection mode, as well as the minimal set of modes discusses various path selection algorithms, which are the
to be supported by a BGP speaker supporting Add-paths. procedures available to an Add-Paths speaker for deciding which
set of paths to advertise to an Add-Paths peer for particular
prefixes.
4.1. Capability Negotiation 4.1. Capability Negotiation
+---+ +---+ +---+ +---+
|RTR|___________|RTR| |RTR|___________|RTR|
| A | <-BGP-> | B | | A | <-BGP-> | B |
+---+ +---+ +---+ +---+
Figure 2: BGP Peering Example Figure 2: BGP Peering Example
skipping to change at page 8, line 42 skipping to change at page 8, line 45
the BGP capabilities advertisements during session setup must the BGP capabilities advertisements during session setup must
indicate that peer B wants to send multiple paths for AFI=x, SAFI=y indicate that peer B wants to send multiple paths for AFI=x, SAFI=y
and that router A is willing to receive multiple paths for AFI=x, and that router A is willing to receive multiple paths for AFI=x,
SAFI=y. Similarly, in order for router A to send multiple paths per SAFI=y. Similarly, in order for router A to send multiple paths per
NLRI to peer B, for a particular address family (AFI=x, SAFI=y), the NLRI to peer B, for a particular address family (AFI=x, SAFI=y), the
BGP capabilities advertisements must indicate that router A wants to BGP capabilities advertisements must indicate that router A wants to
send multiple paths for AFI=x, SAFI=y and peer B is willing to send multiple paths for AFI=x, SAFI=y and peer B is willing to
receive multiple paths for AFI=x, SAFI=y. Refer to [Add-Paths] for receive multiple paths for AFI=x, SAFI=y. Refer to [Add-Paths] for
details of the Add-Paths capabilities advertisement. details of the Add-Paths capabilities advertisement.
The capabilities of the local router shall be configurable per peer The capabilities of the local router MUST be configurable per peer
and per address family, with the ability to configure send-only and per address family, and SHOULD support the ability to configure
operation or receive-only operation. The default mode of operation send-only operation or receive-only operation. The default mode of
shall be to both send and receive. operation shall be to both send and receive.
4.2. Receiving Multiple Paths 4.2. Receiving Multiple Paths
Currently, per standard BGP behavior, if a BGP router receives an Currently, per standard BGP behavior, if a BGP router receives an
advertisement of an NLRI and path from a specific peer and that peer advertisement of an NLRI and path from a specific peer and that peer
subsequently advertises the same NLRI with different path information subsequently advertises the same NLRI with different path information
(e.g. a different NEXT_HOP and/or different path attributes) the new (e.g. a different NEXT_HOP and/or different path attributes) the new
path effectively overwrites the existing path. path effectively overwrites the existing path.
When Add-Paths has been negotiated with the peer, the newly When Add-Paths has been negotiated with the peer, the newly
advertised path should be stored in the RIB-IN along with all of the advertised path should be stored in the RIB-IN along with all of the
paths previously advertised (and not withdrawn) by the peer. paths previously advertised (and not withdrawn) by the peer.
When the Add-Paths receive capability for (AFIx, SAFIy) has been When an Add-Paths speaker has negotiated to receive multiple paths
negotiated with a peer all advertisements and withdrawals of NLRI for (AFIx, SAFIy) from a peer all advertisements and withdrawals of
within that address family by that peer shall include a path NLRI within that address family from that peer MUST include a path
identifier, as described in [Add-Paths]. The path identifiers have no identifier, as described in [Add-Paths]. The path identifiers have no
significance to the receiving peer. If the combination of NLRI and significance to the receiving peer. If the combination of NLRI and
path identifier in an advertisement from a peer is unique (does not path identifier in an advertisement from a peer is unique (does not
match an existing route in the RIB-IN from that peer) then the route match an existing route in the RIB-IN from that peer) then the route
is added to the RIB-IN. If the combination of NLRI and path is added to the RIB-IN. If the combination of NLRI and path
identifier in a received advertisement is the same as an existing identifier in a received advertisement is the same as an existing
route in the RIB-IN from the peer then the new route replaces the route in the RIB-IN from the peer then the new route replaces the
existing one. If the combination of NLRI and path identifier in a existing one. If the combination of NLRI and path identifier in a
received withdrawal matches an existing route in the RIB-IN from the received withdrawal matches an existing route in the RIB-IN from the
peer then that route shall be removed from the RIB-IN. peer then that route shall be removed from the RIB-IN.
A BGP UPDATE message from a peer sending NLRI with the path A BGP UPDATE message from an Add-Paths peer may advertise and
identifier may advertise and withdraw more than one NLRI belonging to withdraw more than one NLRI belonging to one or more address
one or more address families. In this case Add-Paths may be supported families. In this case Add-Paths may be supported for some of the
for some of the address families and not others. In this situation address families and not others. In this situation the receiving BGP
the receiving BGP router should not expect that all of the path router should not expect that all of the path identifiers in the
identifiers in the UPDATE message will be the same. UPDATE message will be the same.
4.3. Advertising Multiple Paths 4.3. Advertising Multiple Paths
[Add-Paths] specifies how to encode the advertisement of multiple [Add-Paths] specifies how to encode the advertisement of multiple
paths towards the same NLRI over an iBGP session, but provides no paths towards the same NLRI over an iBGP session, but provides no
details about which set of multiple paths should be advertised. In details about which set of multiple paths should be advertised. In
this section, four path selection algorithms are described and this section, four path selection algorithms are described and
compared with each other. These 4 algorithms are considered to be the compared with each other. These 4 algorithms are considered to be the
most useful across the widest range of deployment scenarios. Of most useful across the widest range of deployment scenarios. The list
course the list of possible path selection algorithms is much larger of possible path selection algorithms is much larger and for the
and for the interested reader Appendix A provides information about interested reader Appendix A provides information about other path
other path selection modes that were considered in historical selection modes that were considered in historical versions of this
versions of this document. document.
In comparing any two path selection algorithms the following factors In comparing any two path selection algorithms the following factors
should be taken into account: should be taken into account:
Control Plane Load: When a router receives multiples paths for a Control Plane Load: When a router receives multiples paths for a
prefix from an iBGP client it has to store more paths in its Adj-Rib- prefix from an iBGP client it has to store more paths in its Adj-Rib-
Ins. Ins.
Control Plane Stress: Coping with multiple iBGP paths has two Control Plane Stress: Coping with multiple iBGP paths has two
implications on the computation that a router has to handle. First, implications on the computation that a router has to handle. First,
skipping to change at page 10, line 27 skipping to change at page 10, line 27
MED/IGP oscillations: BGP sometimes suffers from routing oscillations MED/IGP oscillations: BGP sometimes suffers from routing oscillations
when the physical topology differs from the logical topology, or when when the physical topology differs from the logical topology, or when
the MED attribute is used. This is due to the limited path the MED attribute is used. This is due to the limited path
visibility when a single path is advertised and Route Reflection is visibility when a single path is advertised and Route Reflection is
used. Increasing the path visibility by advertising multiple paths used. Increasing the path visibility by advertising multiple paths
can help solve this issue. can help solve this issue.
Path optimality: When a single path is advertised, border routers do Path optimality: When a single path is advertised, border routers do
not always receive the optimal path. As an example, Route Reflectors not always receive the optimal path. As an example, Route Reflectors
send a single path chosen based on their own IGP tie-break. typically send a single path chosen based on their own IGP tie-break
(although modifications to this are proposed in [BGP-ORR]).
Increasing path visibility would also help routers to learn the path Increasing path visibility would also help routers to learn the path
that is best suited for them w.r.t. the IGP tie-break. that is best suited for them w.r.t. the IGP tie-break.
Backup path optimality: Multiple paths advertisement gives routers Backup path optimality: Multiple paths advertisement gives routers
the opportunity to have a backup path. However, some backup paths the opportunity to have a backup path. However, some backup paths
are better than others. Indeed, when a link failure occurs, if a are better than others. Indeed, when a link failure occurs, if a
router already knows its post-convergence path, the BGP re- router already knows its post-convergence path, the BGP re-
convergence is straightforward and traffic is less impacted by the convergence is straightforward and traffic is less impacted by the
transient use of non-best forwarding paths. transient use of non-best forwarding paths.
skipping to change at page 11, line 11 skipping to change at page 11, line 11
paths to a peer so that it will have the best path and the optimal paths to a peer so that it will have the best path and the optimal
backup path. For load balancing purposes, it may be desirable to backup path. For load balancing purposes, it may be desirable to
advertise more paths, but inclusion of the optimal backup path in the advertise more paths, but inclusion of the optimal backup path in the
set may be less critical. For route oscillation elimination, it is set may be less critical. For route oscillation elimination, it is
required to advertise all group-best paths for a prefix. required to advertise all group-best paths for a prefix.
4.3.1. Path Selection Modes 4.3.1. Path Selection Modes
The following subsections describe the 4 main path selection modes The following subsections describe the 4 main path selection modes
considered in this draft. Each mode is considered either MANDATORY or considered in this draft. Each mode is considered either MANDATORY or
OPTIONAL. A MANDATORY mode should be present in any implementation OPTIONAL. A MANDATORY mode MUST be supported by any implementation
that claims compliance with [Add-Paths]. An OPTIONAL made may be that claims compliance with this document. An OPTIONAL made may be
supported by some but not all implementations. supported by some but not all implementations.
The path selection mode and any parameters applicable to the mode The path selection mode and any parameters applicable to the mode
MUST be configurable per AFI/SAFI and per peer and SHOULD be MUST be configurable per AFI/SAFI and per peer and SHOULD be
configurable per prefix. configurable per prefix. To illustrate the value of this flexibility,
consider a prefix P that belongs to an address family F requiring
path IDs to be included with every NLRI (e.g. due to the Add-Paths
capability negotiation with the peer). If P is one of a number of
prefixes that would not benefit from the advertisement of multiple
paths then it is perfectly valid to send only the best path.
4.3.1.1. Advertise All Paths 4.3.1.1. Advertise All Paths
A simple rule for advertising multiple paths in iBGP is to simply A simple rule for advertising multiple paths in iBGP is to simply
advertise to iBGP peers all received paths, provided they pass export advertise to iBGP peers all received paths, provided they pass export
filters. This solution is easy to implement, but the counterpart is filters. This solution is easy to implement, but the counterpart is
that all those paths need to be stored by all routers that receive that all those paths need to be stored by all routers that receive
them, which can be quite expensive. If a path to a prefix P is them, which can be quite expensive. If a path to a prefix P is
advertised to N border routers, with a Full Mesh of iBGP sessions, advertised to N border routers, with a Full Mesh of iBGP sessions,
all routers have N paths in their Adj-RIB-Ins. If Route Reflection all routers have N paths in their Adj-RIB-Ins. If Route Reflection
is used and each client is connected to 2 Route Reflectors, it may is used and each client is connected to 2 Route Reflectors, it may
learn up to 2*N paths. learn up to 2*N paths.
skipping to change at page 11, line 44 skipping to change at page 11, line 49
switch on their optimal backup path in case of failure. switch on their optimal backup path in case of failure.
However, as more paths are exchanged, the number of BGP messages However, as more paths are exchanged, the number of BGP messages
disseminated during the initial iBGP convergence can be high, and disseminated during the initial iBGP convergence can be high, and
convergence may be slower. convergence may be slower.
Routing oscillations are prevented with this rule, because a router Routing oscillations are prevented with this rule, because a router
won't need to withdraw a previously advertised path when its best won't need to withdraw a previously advertised path when its best
path changes. path changes.
Routers that support Add-Path MAY support this path selection mode. This path selection mode is OPTIONAL.
It is an OPTIONAL mode.
4.3.1.2. Advertise N Paths 4.3.1.2. Advertise N Paths
Another solution is for a router to advertise a maximum of N paths to Another solution is for a router to advertise a maximum of N paths to
iBGP peers. Here, the computational cost is the selection of the N iBGP peers. Here, the computational cost is the selection of the N
paths. Indeed, there must be a ranking of the paths in order to paths. Indeed, there must be a ranking of the paths in order to
advertise the most interesting ones. A way for a router to select N advertise the most interesting ones. A way for a router to select N
paths is to run N times its decision process. At each iteration of paths is to run N times its decision process. At each iteration of
the process only those paths not selected during a previous iteration the process only those paths not selected during a previous iteration
and not having a NEXT_HOP or BGP Identifier (or Originator ID) in and those with a different NEXT_HOP and BGP Identifier (or Originator
common with the previously-selected paths are eligible for ID) combination from previously-selected paths are eligible for
consideration. The memory cost is bounded: a router receives a consideration. The memory cost is bounded: a router receives a
maximum of N paths for each prefix from each peer. With N equal to 2, maximum of N paths for each prefix from each peer. With N equal to 2,
all routers know at least two paths and can provide local recovery in all routers know at least two paths and can provide local recovery in
case of failure. If multipath routing is to be deployed in the AS, N case of failure. If multipath routing is to be deployed in the AS, N
can be increased to provide more alternate paths to the routers. can be increased to provide more alternate paths to the routers.
Path optimality and backup path optimality are not guaranteed, but as Path optimality and backup path optimality are not guaranteed, i.e.
path diversity is better, the nexthops of the chosen primary and it is possible that the optimal path of a router (w.r.t. IGP tie-
backup path are more likely to be closer to the router than with break) is not contained in the set of paths advertised by its Route
classical BGP. Reflector. However, as the number of paths that it receives is higher
than without Add-Paths, it is possible that the chosen nexthop is
closer to the router in terms of IGP cost than the nexthop that would
have been chosen without Add-Paths.
This solution helps to reduce routing oscillations, but not in all This solution helps to reduce routing oscillations, but not in all
cases. Indeed, path visibility is still constrained by the maximum cases. Indeed, path visibility is still constrained by the maximum
number of paths, and configurations with routing oscillations still number of paths, and configurations with routing oscillations still
exist. exist.
Routers that support Add-Path MUST support this path selection mode. This path selection mode is MANDATORY. The default value of N MUST be
The default value of N must be 2. The value of N MUST be 2. The value of N MUST be configurable and MAY be upper bounded by
configurable and MAY be upper bounded by an implementation. an implementation.
The default value of 2 ensures the availability of a backup path (if The default value of 2 ensures the availability of a backup path (if
2 or more paths have been received) while maintaining minimum impact 2 or more paths have been received) while maintaining minimum impact
to memory and churn. If Add-N with N equal to 2 is insufficient to to memory and churn. If Add-N with N equal to 2 is insufficient to
meet another objective (e.g. loadsharing or MED/IGP oscillation) meet another objective (e.g. loadsharing or MED/IGP oscillation)
there is always a large enough value of N that can selected, if N is there is always a large enough value of N that can selected, if N is
configurable, to meet that objective. configurable, to meet that objective.
4.3.1.3. Advertise All AS-Wide Best Paths 4.3.1.3. Advertise All AS-Wide Best Paths
Another choice is to advertise all paths with the same AS-wide Another choice is to advertise all paths with the same AS-wide
preference [Basu-ibgp-osc], i.e. the paths that all routers would preference [Basu-ibgp-osc], i.e. the paths that all routers would
select based on the rules of the decision process that are not select based on the rules of the decision process that are not
router-dependent (i.e. Local-preference, ASPath length and MED router-dependent (i.e. Local-preference, ASPath length and MED
rules). Thus, for a given router, those paths only differ by the IGP rules). Thus, for a given router, those paths only differ by the IGP
cost to the nexthop or by the tie-breaking rules. cost to the nexthop or by the tie-breaking rules.
The computational cost is reduced, as a router only has to send the The computational cost is reduced, as a router only has to send the
paths remaining before applying the IGP tie-breaking rule. However, paths remaining before applying the IGP tie-breaking rule. However,
skipping to change at page 13, line 17 skipping to change at page 13, line 25
router-specific preferences, i.e. the IGP cost to the nexthop. Hot router-specific preferences, i.e. the IGP cost to the nexthop. Hot
potato routing is respected. Also, MED oscillations are prevented, potato routing is respected. Also, MED oscillations are prevented,
because the path visibility among the AS-wide preferred paths is because the path visibility among the AS-wide preferred paths is
total. total.
The existence of a backup path is not guaranteed. If only one path The existence of a backup path is not guaranteed. If only one path
with the AS-wide best attributes exists, there is no backup path with the AS-wide best attributes exists, there is no backup path
disseminated. However, if such a path exists, it is optimal as it disseminated. However, if such a path exists, it is optimal as it
has the same AS-wide preference as the primary has the same AS-wide preference as the primary
Routers that support Add-Path MAY support this path selection mode. This path selection mode is OPTIONAL.
It is an OPTIONAL mode.
4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths (Double AS Wide) 4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths (Double
AS Wide)
This variant of "Advertise All AS Wide Best Paths" trades-off the This variant of "Advertise All AS Wide Best Paths" trades-off the
number of paths being propagated within the iBGP system for post- number of paths being propagated within the iBGP system for post-
convergence alternate paths availability and routing stability. A BGP convergence alternate paths availability and routing stability. A BGP
speaker running this mode will select for advertisement its AS Wide speaker running this mode will select for advertisement its AS Wide
Best paths, plus all the AS Wide Best paths obtained when removing Best paths, plus all the AS Wide Best paths obtained when removing
the first ones from consideration. the first ones from consideration.
Under this mode, a BGP speaker knows multiple AS-Wide best paths or Under this mode, a BGP speaker knows multiple AS-Wide best paths or
the AS-Wide best path and all the second AS-Wide best paths, so that the AS-Wide best path and all the second AS-Wide best paths, so that
skipping to change at page 13, line 49 skipping to change at page 14, line 12
and including the MED rule, based on the paths that are not in the and including the MED rule, based on the paths that are not in the
set of AS-Wide best paths. set of AS-Wide best paths.
The number of paths for a prefix p, known by a given router of the The number of paths for a prefix p, known by a given router of the
AS, is the number of AS-Wide best and second AS-Wide best paths found AS, is the number of AS-Wide best and second AS-Wide best paths found
at the Borders of the AS. at the Borders of the AS.
MED Oscillations are avoided by this mode, both for the primary and MED Oscillations are avoided by this mode, both for the primary and
alternate paths being picked under this mode. alternate paths being picked under this mode.
Routers that support Add-Path MAY support this path selection mode. This path selection mode is OPTIONAL.
It is an OPTIONAL mode.
4.3.2. Derived Modes from Bounding the Number of Advertised Paths 4.3.2. Derived Modes from Bounding the Number of Advertised Paths
For some of the modes discussed in section 4.3.1 the number of paths For some of the modes discussed in section 4.3.1 the number of paths
selected by the algorithm (M) is not predictable in advance, and selected by the algorithm (M) is not predictable in advance, and
depends on factors such as network topology. For such modes, depends on factors such as network topology. For such modes,
implementations MAY support the ability to limit the number of implementations MAY support the ability to limit the number of
advertised paths to some value N that is less than M. advertised paths to some value N that is less than M.
It must be noted that the resulting derivative mode may no longer It must be noted that the resulting derivative mode may no longer
meet the properties stated in section 4.3.1 (which assumes N=M). This meet the properties stated in section 4.3.1 (which assumes N=M). This
is particularly true for the MED oscillation avoidance property. The is particularly true for the MED oscillation avoidance property. The
use of such bounds thus needs to be considered carefully in use of such bounds thus needs to be considered carefully in
deployments where MED oscillation avoidance is a key goal of deployments where MED oscillation avoidance is a key goal of
deploying Add-path. If fast recovery is the main objective then it is deploying Add-path. If fast recovery is the main objective then it is
reasonable and sufficient to set N to 2. If the main goal is reasonable and sufficient to set N to 2. If the main goal is
improved load-balancing then limiting N to number of ECMP paths improved load-balancing then limiting N to number of ECMP paths
supported by the forwarding planes of the receiving routers is also a supported by the forwarding planes of the receiving routers is also a
reasonable practice. reasonable practice.
5. Scalability and Routing Consistency Considerations 5. Deployment Considerations
When Add-Paths is introduced into a network it can have important This section proposes a potential strategy for introducing Add-Paths
implications on nodal and network scalability and routing consistency into an existing network and discusses considerations related to
and correctness. scalability, routing consistency and routing churn.
5.1. Scalability Considerations 5.1. Introducing Add-Paths into an Existing Network
There are many possible ways that Add-Paths can be introduced into an
existing deployed network. It is not a practical goal for this
document to list all of these options and discuss the pros and cons
for each one. It is however valuable to consider an example migration
strategy that may be relatively common among layer 3 service
providers that currently use route reflectors for scaling. This
example migration strategy is attractive for several reasons:
1. It involves incremental steps that allow the impact of Add-
Paths to be carefully evaluated before proceeding to the next
step.
2. It recognizes the fact that many routers will require at least
a software upgrade to support Add-Paths, and it will not be
practical to upgrade all of these routers all at once.
3. It reduces convergence time (in stages) with a relatively
moderate increase in router memory and CPU demands.
The example migration strategy assumes a starting point of a deployed
network with one or more RR clusters. None of the routers in the
network support Add-Paths without an upgrade, but some do support
best-external. Two of the clusters in this network are shown in
Figure 3. In cluster 2, PE1, PE2, RRy and RRz are configured for
best-external. This makes RRy and RRz aware of all external paths
received by PEs in cluster 2 and ensures that RRy and RRz can
advertise a path to the RRs in cluster 1 if it happens that the best
overall route is learned from cluster 1. It doesn't however allow
other clusters to be aware of more than one path per prefix learned
by cluster 2.
========== ==================
= = = =
= +---+ +---+ +---+ =
= |RR |---------------|RR | <-BE| | =
= |a | |y |------|PE1| =
= | | | | | | =
= +---+ +---+ +---+ =
= | = = | \ / =
= | = = | \ / =
= | = = | \/ =
= | = = | /\ =
= | = = | / \ =
= | = = | / \ =
= +---+ +---+ +---+ =
= |RR |---------------|RR |------| | =
= |b | |z | <-BE|PE2| =
= | | | | | | =
= +---+ +---+ +---+ =
= = = =
========== ==================
RR Cluster 1 RR Cluster 2
Figure 3: RR Cluster Before Add-Paths
The following sequence of steps occurs in the example migration
strategy:
1. The route reflectors are upgraded in each cluster, one by one, to
support Add-Paths. This allows the intra- and (eventually) inter-
cluster RR-to-RR sessions to start using Add-Paths. All RRs are
configured to use the Add-N, N=2 path selection algorithm. The
effect of this step is to slightly reduce convergence time when
the best and second-best paths for a prefix are learned by a
single cluster (such as cluster 2 in Figure 3).
2. The clients are upgraded in each cluster, one by one, to support
Add-Paths. On the RRs Add-Paths is configured to use the Add-N,
N=2 path selection algorithm towards upgraded client peers. At
this step clients are configured in the receive-only Add-Paths
mode. This means that best-external continues to operate as
before in the client-to-RR direction. The effect of this step is
to ensure that all clients have two paths per prefix for ECMP or
fast failover, assuming at least 2 paths are available.
3. The clients are re-configured to use Add-Paths in the transmit
direction towards their RR peers. This causes Add-Paths to replace
the best-external behavior. The effect of this step is to free up
CPU and memory resources related to the storage of paths that are
third best or worse. If a cluster such as the one in Figure 3 had
50 clients, and 10 of these learned an external route for the same
prefix, then the RRs in that cluster would need to store up to 12
paths for that prefix. This would be true even if the 2 best
overall paths came from another cluster. Contrast this with the
use of Add-Paths in the client-to-RR direction. For the same case
the route reflectors need only store the 2 paths learned from non-
client peers.
5.2. Scalability Considerations
In terms of scalability, we note that advertising multiple paths per In terms of scalability, we note that advertising multiple paths per
prefix requires more memory and state than the current behavior of prefix requires more memory and state than the current behavior of
advertising the best path only. A BGP speaker that does not implement advertising the best path only. A BGP speaker that does not implement
Add-Paths maintains send state information in its prefix data Add-Paths maintains send state information in its prefix data
structure per neighbor as a way to determine that the prefix has been structure per neighbor as a way to determine that the prefix has been
advertised to the neighbor. With Add-Paths, this information has to advertised to the neighbor. With Add-Paths, this information has to
be replicated on a per path basis that needs to be advertised. be replicated on a per path basis that needs to be advertised.
Mathematically, if "send state" size per prefix is 's' bytes, number Mathematically, if "send state" size per prefix is 's' bytes, number
of neighbors is 'n', and number of paths being advertised is 'p', of neighbors is 'n', and number of paths being advertised is 'p',
then the current memory requirement for BGP "send state" = n * s then the current memory requirement for BGP "send state" = n * s
bytes; with Add-Paths, it becomes n * s * p bytes. In practice, this bytes; with Add-Paths, it becomes n * s * p bytes. In practice, this
value may be reduced with implementation optimizations similar to value may be reduced with implementation optimizations similar to
attribute sharing. Receiving multiple paths per prefix also requires attribute sharing. Receiving multiple paths per prefix also requires
more memory and state since each path is a separate entry in the Adj- more memory and state since each path is a separate entry in the Adj-
RIB-Ins. RIB-Ins.
5.2. Routing Consistency Considerations 5.3. Routing Consistency Considerations
As discussed in previous sections Add-Paths can help routers select As discussed in previous sections Add-Paths can help routers select
more optimal paths and it can help deal with certain route more optimal paths and it can help deal with certain route
oscillation conditions arising from incomplete knowledge of the oscillation conditions arising from incomplete knowledge of the
available paths. But depending on the path selection algorithm and available paths. But depending on the path selection algorithm and
how it is used Add-Paths is not immune to its own cases of routing how it is used Add-Paths is not immune to its own cases of routing
inconsistencies. If the BGP routers within an AS do not make inconsistencies. If the BGP routers within an AS do not make
consistent routing decisions about how to reach a particular consistent routing decisions about how to reach a particular
destination, route oscillations may occur and these route destination, route oscillations may occur and these route
oscillations may result in traffic loss. oscillations may result in traffic loss.
skipping to change at page 15, line 26 skipping to change at page 17, line 34
far from ideal from a scalability perspective but it does guarantee far from ideal from a scalability perspective but it does guarantee
routing consistency and correctness. A path selection mode that routing consistency and correctness. A path selection mode that
allows better control over scalability is the Advertise N paths mode, allows better control over scalability is the Advertise N paths mode,
but this is susceptible to routing inconsistency. First, if the N but this is susceptible to routing inconsistency. First, if the N
paths do not include the best path from each neighbor AS group then paths do not include the best path from each neighbor AS group then
route oscillation cannot be precluded. Second, if the advertising route oscillation cannot be precluded. Second, if the advertising
router (e.g. an RR) advertises N paths to peer_n and M paths to router (e.g. an RR) advertises N paths to peer_n and M paths to
peer_m, and N < M, care must be exercised to ensure that all paths peer_m, and N < M, care must be exercised to ensure that all paths
advertised to peer_n are included in the paths advertised to peer_m. advertised to peer_n are included in the paths advertised to peer_m.
This can be assured as long as the advertising router has strictly This can be assured as long as the advertising router has strictly
ordered all of its paths ordered all of its paths.
5.3. Consistency between Advertised Paths and Forwarding Paths 5.4. Consistency between Advertised Paths and Forwarding Paths
When using Add-Paths, routers may advertise paths that they have not When using Add-Paths, routers may advertise paths that they have not
selected as best, and that they are thus not using for traffic selected as best, and that they are thus not using for traffic
forwarding. If two levels of encapsulation are used in the network forwarding. This is generally not an issue if encapsulation is used
as described in [RFC4364], this is not an issue, as only the ingress in the AS as described in [RFC4364] and all forwarding decisions,
router performs a lookup in its BGP-fed FIB. The traffic is including by the tunnel egress router, are based on label information
encapsulated to the egress link, and no other router on the - i.e. if only the ingress router performs an IP FIB lookup. In this
forwarding path needs to perform a BGP lookup. The dataplane path situation the dataplane path followed by the packets is the one
followed by the packets is the one intended by the ingress router, intended by the ingress router, and corresponds to the control plane
and corresponds to the control plane path it advertises. path it selected.
However, in some networks using Add-Paths without double On the other hand, if Add-Paths is used in a network without
encapsulation, some scenarios can result in forwarding deflection or encapsulation, some scenarios can result in forwarding deflection or
loops. Such forwarding anomalies already occur without Add-Paths, loops. Such forwarding anomalies already occur without Add-Paths,
when the routers on the forwarding path do not use the same nexthop when the routers on the forwarding path do not have a synchronized
as the ingress router. They will deflect the traffic to their own view of the best path. They will deflect the traffic to their own
nexthop, and, when multiple deflections occur, forwarding loops can local view of the best path, and, when multiple deflections occur,
appear. With Add-Paths, the issue can be exacerbated due to routers forwarding loops can occur. With Add-Paths, the issue can be
advertising non-best paths, even when one level of encapsulation is exacerbated due to routers advertising non-best paths. As discussed
used. Indeed, both the ingress and the egress routers perform a BGP above, encapsulation can help with this issue, but only to the extent
lookup, and traffic can be deflected by the egress router. that it allows downstream routers to forward without an IP FIB
lookup.
A first example of such issue is when the Local-Pref of paths A first example of such issue is when the Local-Pref of non-primary
received over iBGP sessions is modified. The ingress router may thus paths received over iBGP sessions is modified. The ingress router
select as best a path non-preferred by the egress, and the egress may thus select as best a path non-preferred by the egress, and the
router will thus deflect the traffic. egress router will thus deflect the traffic.
Another example is when the best path is selected based on tie- Another example is when the best path is selected based on tie-
breaking rule. When the ingress and the egress base their path breaking rule. When the ingress and the egress base their path
selection on the router-id of the neighbor that advertised the path selection on the router-id of the neighbor that advertised the path
to them, the result may be different for each of them. This specific to them, the result may be different for each of them. This specific
issue is described and solved in [draft-pmohapat]. issue is described and solved in [draft-pmohapat].
5.5. Routing Churn
As noted in section 3.3 using Add-Paths between IBGP peers can help
to reduce routing churn with EBGP peers. This benefit does however
come at the cost of potentially increased churn between the IBGP Add-
Paths peers. In a non Add-Paths deployment a change in the preference
order of non-best paths requires no updates to be sent to peers. But
when a router has Add-Paths peers changes in non-best path preference
may no longer be invisible and increased route churn may be
observable. Choosing the right path selection mode and parameters -
for example not setting N unnecessarily large in the Add-N mode, is
important to minimizing this additional churn.
6. Security Considerations 6. Security Considerations
TBD TBD
7. IANA Considerations 7. IANA Considerations
TBD TBD
8. Conclusions 8. Conclusions
TBD TBD
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[Add-Paths] Walton, D., Retana, A., Chen E., Scudder J., [Add-Paths] Walton, D., Retana, A., Chen E., Scudder J.,
"Advertisement of Multiple Paths in BGP", February 6, "Advertisement of Multiple Paths in BGP", February
2010. 6, 2010.
[draft-pmohapat] Mohapatra, P., Fernando, R., Filsfils, C., and R. [draft-pmohapat] Mohapatra, P., Fernando, R., Filsfils, C., and R.
Raszuk, "Fast Connectivity Restoration Using BGP Add- Raszuk, "Fast Connectivity Restoration Using BGP
path", draft-pmohapat-idr-fast-conn-restore-00.txt (work Add-path", draft-pmohapat-idr-fast-conn-restore-
in progress), September 2008. 00.txt (work in progress), September 2008.
[oscillation] Walton, D., Retana, A., Chen, E., Scudder, J., "BGP [oscillation] Walton, D., Retana, A., Chen, E., Scudder, J., "BGP
Persistent Route Oscillation Solutions", draft-walton- Persistent Route Oscillation Solutions", draft-
bgp-route-oscillation-stop-03.txt, May 10, 2010. walton-bgp-route-oscillation-stop-03.txt, May 10,
2010.
[Basu-ibgp-osc] Basu, A., Ong, C., Rasala, A., Sheperd, B., and G. [Basu-ibgp-osc] Basu, A., Ong, C., Rasala, A., Sheperd, B., and G.
Wilfong, "Route oscillations in iBGP with Route
Reflection", Sigcomm 2002.
Wilfong, "Route oscillations in iBGP with Route [BGP-ORR] Raszuk, R., Cassar, C., Aman, E., Decraene, B., "BGP
Reflection", Sigcomm 2002. Optimal Route Reflection", draft-raszuk-bgp-optimal-
route-reflection-01, March 11, 2011.
[RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway
Protocol 4 (BGP-4), January 2006. Protocol 4 (BGP-4), January 2006.
10. Acknowledgments 10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Appendix A. Other Path Selection Modes Appendix A. Other Path Selection Modes
A.1. Advertise Neighbor-AS Group Best Path A.1. Advertise Neighbor-AS Group Best Path
[walton-osc] proposes that a router groups its paths based on the [walton-osc] proposes that a router groups its paths based on the
 End of changes. 53 change blocks. 
173 lines changed or deleted 292 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/