draft-ietf-idr-add-paths-guidelines-07.txt   draft-ietf-idr-add-paths-guidelines-08.txt 
IDR Working Group J. Uttaro IDR Working Group J. Uttaro
Internet-Draft AT&T Internet-Draft AT&T
Intended status: Standards Track Intended status: Informational
Expires: Jun 3, 2015 P. Francois Expires: Oct 25, 2016 P. Francois
IMDEA Networks IMDEA Networks
K. Patel K. Patel
Cisco Systems Cisco Systems
P. Mohapatra J. Haas
Cumulus Networks Juniper Networks
J. Haas
Juniper Networks
A. Simpson A. Simpson
R. Fragassi R. Fragassi
Alcatel-Lucent Nokia
Dec 3, 2014 Apr 25, 2016
Best Practices for Advertisement of Multiple Paths in IBGP Best Practices for Advertisement of Multiple Paths in IBGP
draft-ietf-idr-add-paths-guidelines-07.txt draft-ietf-idr-add-paths-guidelines-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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 47 skipping to change at page 1, line 44
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 Jun 3, 2015. This Internet-Draft will expire on October 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 43 skipping to change at page 2, line 43
provides recommendations based on the target application. provides recommendations based on the target application.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
2. Terminology....................................................4 2. Terminology....................................................4
3. Add-Paths Applications.........................................5 3. Add-Paths Applications.........................................5
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...8
4. Implementation Guidelines......................................8 4. Implementation Guidelines......................................8
4.1. Capability Advertisement..................................8 4.1. Capability Advertisement..................................8
4.2. Receiving Multiple Paths..................................9 4.2. Receiving Multiple Paths..................................9
4.3. Advertising Multiple Paths................................9 4.3. Advertising Multiple Paths...............................10
4.3.1. Path Selection Modes................................11 4.3.1. Path Selection Modes................................11
4.3.1.1. Advertise N Paths..............................11 4.3.1.1. Advertise N Paths..............................11
4.3.1.2. Advertise All Paths............................12 4.3.1.2. Advertise All Paths............................12
4.3.1.3. Advertise All AS-Wide Best Paths...............13 4.3.1.3. Advertise All AS-Wide Best Paths...............13
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)........................................14
4.3.1.5. Advertise Used Multipaths......................14 4.3.1.5. Advertise Used Multipaths......................14
4.3.2. Derived Modes from Bounding the Number of Advertised 4.3.2. Derived Modes from Bounding the Number of Advertised
Paths......................................................15 Paths......................................................15
4.3.3. Derived Modes from Adding N More Paths..............15 4.3.3. Derived Modes from Adding N More Paths..............15
5. Deployment Considerations.....................................15 5. Deployment Considerations.....................................16
5.1. Introducing Add-Paths into an Existing Network...........16 5.1. Introducing Add-Paths into an Existing Network...........16
5.2. Scalability Considerations...............................18 5.2. Scalability Considerations...............................18
5.3. Routing Consistency Considerations.......................18 5.3. Routing Consistency Considerations.......................18
5.4. Consistency between Advertised Paths and Forwarding Paths19 5.4. Consistency between Advertised Paths and Forwarding Paths19
5.5. Interactions with Route Filtering........................20 5.5. Interactions with Route Filtering........................20
5.6. Routing Churn............................................20 5.6. Routing Churn............................................20
6. Security Considerations.......................................21 6. Security Considerations.......................................21
7. Acknowledgments...............................................21 7. Acknowledgments...............................................21
8. Contributors..................................................21 8. Contributors..................................................21
9. IANA Considerations...........................................21 9. IANA Considerations...........................................21
10. References...................................................21 10. References...................................................21
10.1. Normative References....................................21 10.1. Normative References....................................21
10.2. Informative References..................................21 10.2. Informative References..................................22
Appendix A. Other Path Selection Modes...........................23 Appendix A. Other Path Selection Modes...........................23
A.1. Advertise Neighbor-AS Group Best Path....................23 A.1. Advertise Neighbor-AS Group Best Path....................23
A.2. Best LocPref/Second LocPref..............................23 A.2. Best LocPref/Second LocPref..............................23
A.3. Advertise Paths at decisive step -1......................24 A.3. Advertise Paths at decisive step -1......................24
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 [RFC4271]
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
within an iBGP system. This has the effect of improving robustness within an IBGP system. This has the effect of improving robustness
in case of failure, reducing the number of BGP messages exchanged in case of failure, reducing the number of BGP messages exchanged
during such an event, and offering the potential for faster re- during such an event, and offering the potential for faster re-
convergence. Through careful selection of the paths to be advertised, convergence. Through careful selection of the paths to be advertised,
Add-Paths can also prevent routing oscillations. Add-Paths can also prevent routing oscillations.
The purpose of this document is to provide the necessary The purpose of this document is to provide the necessary
recommendations to the implementers of Add-Paths so that network recommendations to the implementers of Add-Paths so that network
operators have the tools needed to address their specific operators have the tools needed to address their specific
applications and to manage the scalability impact of Add-Paths while applications and to manage the scalability impact of Add-Paths while
maintaining routing consistency. A router implementing Add-Paths may maintaining routing consistency. A router implementing Add-Paths may
skipping to change at page 4, line 38 skipping to change at page 4, line 38
target application. target application.
2. Terminology 2. Terminology
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 [RFC4271] 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.
Diverse path: A BGP path associated with a different BGP next-hop and 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 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 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. is none, the BGP Identifier of the peer that advertised the path.
Backup path: A diverse path with respect to the primary paths toward 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 a prefix. The backup path can be used to forward traffic to the
destination if the primary paths fail. destination if the primary paths fail.
Optimal backup path: The backup path that will be selected as the new 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.
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 [RFC2119].
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.
3.1. Fast Connectivity Restoration 3.1. Fast Connectivity Restoration
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. AS1 receives from AS3 2 that none of the routers support Add-Paths. AS1 receives from AS3 two
paths (A and B) to a particular destination XYZ. Suppose path A is paths (A and B) to a particular destination in AS3. Suppose path A is
preferred over path B due to path A having a lower MED (multi-exit preferred over path B due to path A having a lower MED (multi-exit
discriminator). discriminator).
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.
If the routers in AS1 are not configured for best-external then RR1 If the routers in AS1 are not configured to advertise the best
knows about only path A during steady state because router B external path [BEST-EXT] then RR1 knows about only path A during
suppresses/withdraws its advertisement of path (B) to RR1. If the steady state because router B suppresses/withdraws its advertisement
routers in AS1 do support best-external then RR1 may have both paths of path (B) to RR1. If the routers in AS1 do support best-external
in its Adj-RIB-IN, but regardless of the best-external configuration [BEST-EXT] then RR1 may have both paths in its Adj-RIB-IN, but
RR1 can only advertise its best path A to its peers, including router regardless, RR1 can only advertise its best path A to its peers,
D. including router D.
======== ===================== ======== =====================
= +---+ +---+ +---+ = +---+ +---+ +---+
= |RTR|________|RTR| |RTR| = |RTR|________|RTR| |RTR|
= | E | | A | | C | = | E | | A | | C |
= +---+Path A->+---+ AS1 +---+ = +---+Path A->+---+ AS1 +---+
= = = \ / = = = = \ / =
= = = \ / = = = = \ / =
= = = \ / = = = = \ / =
= = = \ / = = = = \ / =
skipping to change at page 6, line 31 skipping to change at page 6, line 31
= = = / \ = = = = / \ =
= +---+Path B->+---+ +---+ = +---+Path B->+---+ +---+
= |RTR| ______|RTR| |RTR| = |RTR| ______|RTR| |RTR|
= | F | | B | | D | = | F | | B | | D |
= +---+ +---+ +---+ = +---+ +---+ +---+
======== ===================== ======== =====================
Figure 1: Example Topology Figure 1: Example Topology
Under these circumstances consider the steps required to restore Under these circumstances consider the steps required to restore
traffic from router D to destination XYZ when the link between Router traffic from router D to the destination in AS3 when the link between
A and Router E fails. (Assume that router A set next-hop to self when Router A and Router E fails. (Assume that router A set next-hop to
advertising path A and that router B is not configured for best- self when advertising path A and that router B is not configured for
external). best-external [BEST-EXT]).
1. Router A sends a BGP UPDATE message withdrawing its advertisement 1. Router A sends a BGP UPDATE message to RR1 withdrawing its
of path (A). advertisement 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. 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 RR1. B advertises path (B) to RR1.
4. RR1 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. RR1 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 the destination in AS3 is restored (the
path has changed from A to B). traffic path has changed to go through router B and then router
F).
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 the destination in AS3 prior to the failure of the
path (A). In steady-state (with no failures) router B decides, as best path (A). In steady-state (with no failures) router B decides,
before, that path (A) is its best path but because of its Add-Paths as before, that path (A) is its best path but because of its Add-
(or best-external) configuration it also advertises path (B) to RR1. Paths (or best-external [BEST-EXT]) configuration it also advertises
Using Add-Paths RR1 can advertise both learned paths to its IBGP path (B) to RR1. Using Add-Paths RR1 can advertise both learned paths
peers, including router D. Now consider again the scenario where the to its IBGP peers, including router D. Now consider again the
link between Router A and Router E fails. In this case, with Add- scenario where the link between Router A and Router E fails. In this
Paths, fewer steps are required to achieve re-convergence: 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 to RR1 withdrawing its
of path (A). advertisement 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 the destination in AS3.
4. Traffic from router D to the destination in AS3 follows the
alternate path through router B-router F provided that the other
routers on this forwarding path have the same synchronized IP FIB
view or else encapsulation is used to avoid IP FIB lookups until
traffic reaches router F; refer to section 5.4 for more discussion
of this topic.
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. The forwarding consistency considerations mentioned in section
5.4 also apply to this use case.
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 less intermediate updates sent to EBGP
eBGP. When the preferred backup path is the post-convergence path, peers. 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
skipping to change at page 8, line 35 skipping to change at page 8, line 45
+---+ +---+ +---+ +---+
|RTR|___________|RTR| |RTR|___________|RTR|
| A | <-BGP-> | B | | A | <-BGP-> | B |
+---+ +---+ +---+ +---+
Figure 2: BGP Peering Example Figure 2: BGP Peering Example
In Figure 2, in order for a router A to receive multiple paths per In Figure 2, in order for a router A to receive multiple paths per
NLRI from peer B, for a particular address family (AFI=x, SAFI=y), NLRI from peer B, for a particular address family (AFI=x, SAFI=y),
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 MUST be configurable per peer The capabilities of the local router MUST be configurable per peer
and per address family, and SHOULD support the ability to configure and per address family, and SHOULD support the ability to configure
send-only operation or receive-only operation. The default mode of send-only operation or receive-only operation. The default mode of
operation is to both send and receive. operation is to both send and receive.
4.2. Receiving Multiple Paths 4.2. Receiving Multiple Paths
skipping to change at page 9, line 31 skipping to change at page 9, line 40
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 an Add-Paths peer may advertise and A BGP UPDATE message from an Add-Paths peer could advertise and
withdraw more than one NLRI belonging to one or more address withdraw more than one NLRI belonging to one or more address
families. In this case Add-Paths may be supported for some of the families. The receiving BGP router MUST NOT expect or require its
address families and not others. In this situation the receiving BGP peer to send path identifiers with all routes belonging to all
router should not expect that all of the path identifiers in the address families. It also MUST NOT expect that all of the received
UPDATE message will be the same. path identifiers in the UPDATE message are 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. The list most useful across the widest range of deployment scenarios. The list
of possible path selection algorithms is much larger and for the of possible path selection algorithms is much larger and for the
interested reader Appendix A provides information about other path interested reader Appendix A provides information about other path
selection modes that were considered in historical versions of this selection modes that were considered in historical 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,
it has to compute the paths to send to its peers, i.e. more than the it has to compute the paths to send to its peers, i.e. more than the
best path. Second, it also has to handle the potential churn related best path. Second, it also has to handle the potential churn related
to the exchange of those multiple paths. to the exchange of those multiple paths.
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
skipping to change at page 10, line 40 skipping to change at page 11, line 5
learn the path that is best suited for them w.r.t. the IGP tie- learn the path that is best suited for them w.r.t. the IGP tie-
breaking. breaking.
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.
Convergence time: Advertising multiple paths in iBGP has an impact on Convergence time: Advertising multiple paths in IBGP has an impact on
the convergence time of the BGP system. More paths need to be the convergence time of the BGP system. More paths need to be
exchanged, but on the other hand, the routing information is exchanged, but on the other hand, the routing information is
propagated faster. With an increased path visibility, there is less propagated faster. With an increased path visibility, there is less
path exploration during the convergence. Also, with the availability path exploration during the convergence. Also, with the availability
of backup paths, convergence time in case of failure is also reduced. of backup paths, convergence time in case of failure is also reduced.
Target application: Depending on the application type, the number of Target application: Depending on the application type, the number of
paths to advertise for a prefix will vary. For example, for fast paths to advertise for a prefix will vary. For example, for fast
connectivity restoration, it may be sufficient to advertise only 2 connectivity restoration, it may be sufficient to advertise only 2
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
skipping to change at page 11, line 25 skipping to change at page 11, line 38
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. To illustrate the value of this flexibility, configurable per prefix. To illustrate the value of this flexibility,
consider a prefix P that belongs to an address family F requiring 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 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 capability negotiation with the peer). If P is one of a number of
prefixes that would not benefit from the advertisement of multiple prefixes that would not benefit from the advertisement of multiple
paths then it is perfectly valid to send only the best path. paths then it is perfectly valid to send only the best path.
4.3.1.1. Advertise N Paths 4.3.1.1. Advertise N Paths
With the 'Advertise N Paths' mode (Add-N for short) a router With the 'Advertise N Paths' mode (Add-N for short) a router
advertises up to N paths per prefix towards an Add-Paths peer. The advertises up to N paths per prefix towards an Add-Paths peer. The
computational cost of this mode is the selection of the N paths. computational cost of this mode is the selection of the N paths.
There must be a ranking of the paths in order to ensure consistency There must be a ranking of the paths in order to ensure consistency
in the set of paths advertised to different Add-Paths peers. The in the set of paths advertised to different Add-Paths peers. The
recommended way for a router to consistently select N paths is to run recommended way for a router to consistently select N paths is to run
its decision process N times and consider at each iteration only the its decision process N times and consider at each iteration only the
paths that meet all of the following criteria: paths that meet all of the following criteria:
skipping to change at page 12, line 29 skipping to change at page 12, line 41
2. The value of N MUST be configurable and MAY be upper bounded by 2. The value of N MUST be 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.2. Advertise All Paths 4.3.1.2. Advertise All Paths
A simple rule for advertising multiple paths in iBGP is to advertise A simple rule for advertising multiple paths in IBGP is to advertise
to iBGP peers all received paths minus those blocked by export to IBGP peers all received paths minus those blocked by export
filters or applicable split horizon rules. This solution is easy to filters or applicable split horizon rules. This solution is easy to
implement, but the counterpart is that all those paths need to be implement, but the counterpart is that all those paths need to be
stored by all routers that receive them, which can be quite stored by all routers that receive them, which can be quite
expensive. If a path to a prefix P is advertised to N border expensive. If a path to a prefix P is advertised to N border
routers, with a Full Mesh of iBGP sessions, all routers have N paths routers, with a Full Mesh of IBGP sessions, all routers have N paths
in their Adj-RIB-Ins. If Route Reflection is used and each client is in their Adj-RIB-Ins. If Route Reflection is used and each client is
connected to 2 Route Reflectors, it may learn up to 2*N paths. connected to 2 Route Reflectors, it may learn up to 2*N paths.
This solution gives a perfect path visibility to all routers, thus This solution gives a perfect path visibility to all routers, thus
limiting churn and losses of connectivity in case of failure. Indeed, limiting churn and losses of connectivity in case of failure. Indeed,
this allows routers to select their optimal primary path, and to this allows routers to select their optimal primary path, and to
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.
This path selection mode is OPTIONAL. This path selection mode is OPTIONAL.
4.3.1.3. Advertise All AS-Wide Best Paths 4.3.1.3. Advertise All AS-Wide Best Paths
Another choice is to consider the set of paths with the same AS-wide Another choice is to consider the set of 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. The paths actually cost to the nexthop or by the tie-breaking rules. The paths actually
advertised to a peer are the set of AS-wide best paths minus those advertised to a peer are the set of AS-wide best paths minus those
blocked by export filters or applicable split horizon rules. blocked by export filters or applicable split horizon 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,
it is difficult to predict how many paths will be stored, as it it is difficult to predict how many paths will be stored, as it
depends on the number of eBGP sessions on which this prefix is depends on the number of EBGP sessions on which this prefix is
advertised with the best AS-wide preference. advertised with the best AS-wide preference.
With this rule, the routing system is optimal: all routers can choose With this rule, the routing system is optimal: all routers can choose
their best path (or best paths if multipath is used) based on their their best path (or best paths if multipath is used) based on their
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
skipping to change at page 13, line 39 skipping to change at page 14, line 4
their best path (or best paths if multipath is used) based on their their best path (or best paths if multipath is used) based on their
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
This path selection mode is OPTIONAL. This path selection mode is OPTIONAL.
4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths (Double 4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths (Double
AS Wide) 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, as candidates for speaker running this mode will select, as candidates for
advertisement, its AS Wide Best paths, plus all the AS Wide Best advertisement, its AS Wide Best paths, plus all the AS Wide Best
paths obtained when removing the first ones from consideration. The paths obtained when removing the first ones from consideration. The
paths actually advertised to a peer are the double-AS wide candidate paths actually advertised to a peer are the double-AS_wide candidate
paths minus those blocked by export filters or applicable split paths minus those blocked by export filters or applicable split
horizon rules. horizon rules.
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
routing optimality and backup path availability are ensured. Note routing optimality and backup path availability are ensured. Note
that the post-convergence paths will be known by each BGP node in an that the post-convergence paths will be known by each BGP node in an
AS supporting this mode. AS supporting this mode.
The computation complexity of this mode is relatively low as it The computation complexity of this mode is relatively low as it
skipping to change at page 14, line 29 skipping to change at page 14, line 41
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.
This path selection mode is OPTIONAL. This path selection mode is OPTIONAL.
4.3.1.5. Advertise Used Multipaths 4.3.1.5. Advertise Used Multipaths
Many BGP implementations support BGP Multipath, allowing a BGP router Many BGP implementations support BGP Multipath, allowing a BGP router
to use multiple BGP next-hops for forwarding towards a prefix/NLRI to use multiple BGP next-hops for forwarding towards a prefix/NLRI
when the corresponding paths are considered equally preferred. In when the corresponding paths are considered equally preferred. In
cases where the deployment of Add-Paths is mostly aimed at providing cases where the deployment of Add-Paths is mostly aimed at providing
multiple paths for load balancing with BGP Multipath, a natural multiple paths for load balancing with BGP Multipath, a natural
approach for a BGP speaker supporting Add-paths is to advertise the approach for a BGP speaker supporting Add-paths is to advertise the
paths that are selected by its BGP multipath selection algorithm. paths that are selected by its BGP multipath selection algorithm.
BGP Multipath selection algorithms can vary depending on the BGP Multipath selection algorithms can vary depending on the
implementation and configuration options. An Add-Paths mode based on implementation and configuration options. An Add-Paths mode based on
BGP multipath is considered practical because it lets the BGP path BGP multipath is considered practical because it lets the BGP path
propagation be aligned with the load balancing objectives expressed propagation be aligned with the load balancing objectives expressed
by the operator configuring BGP multipath. by the operator configuring BGP multipath.
In some deployment scenarios, it is likely that such a mode leads to In some deployment scenarios, it is likely that such a mode leads to
the selection and advertisement of a large number of paths for some the selection and advertisement of a large number of paths for some
NLRI, and hence should be controlled as per the mechanism described NLRI, and hence should be controlled as per the mechanism described
in section 4.3.2. In case the number of multipaths exceeds the upper in section 4.3.2. In case the number of multipaths exceeds the upper
bound on the number of advertised paths the ones that should be bound on the number of advertised paths the ones that should be
skipping to change at page 18, line 24 skipping to change at page 18, line 24
5.2. Scalability Considerations 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 K is the number of neighbors, s is the "send
of neighbors is 'n', and number of paths being advertised is 'p', state" size per prefix in bytes, and N is the number of advertised
then the current memory requirement for BGP "send state" = n * s paths per prefix, then the current memory requirement for BGP "send
bytes; with Add-Paths, it becomes n * s * p bytes. In practice, this state" = K * s bytes; with Add-Paths, it becomes K * s * N bytes. In
value may be reduced with implementation optimizations similar to practice, this value may be reduced with implementation optimizations
attribute sharing. Receiving multiple paths per prefix also requires similar to attribute sharing. Receiving multiple paths per prefix
more memory and state since each path is a separate entry in the Adj- also requires more memory and state since each path is a separate
RIB-Ins. entry in the Adj-RIB-Ins.
5.3. 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
skipping to change at page 19, line 39 skipping to change at page 19, line 39
when the routers on the forwarding path do not have a synchronized when the routers on the forwarding path do not have a synchronized
view of the best path. They will deflect the traffic to their own view of the best path. They will deflect the traffic to their own
local view of the best path, and, when multiple deflections occur, local view of the best path, and, when multiple deflections occur,
forwarding loops can occur. With Add-Paths, the issue can be forwarding loops can occur. With Add-Paths, the issue can be
exacerbated due to routers advertising non-best paths. As discussed exacerbated due to routers advertising non-best paths. As discussed
above, encapsulation can help with this issue, but only to the extent above, encapsulation can help with this issue, but only to the extent
that it allows downstream routers to forward without an IP FIB that it allows downstream routers to forward without an IP FIB
lookup. lookup.
A first example of such issue is when the Local-Pref of non-primary A first example of such issue is when the Local-Pref of non-primary
paths received over iBGP sessions is modified. The ingress router paths received over IBGP sessions is modified. The ingress router
may thus select as best a path non-preferred by the egress, and the may thus select as best a path non-preferred by the egress, and the
egress 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].
In general, if the network forwards on a hop-by-hop basis and does In general, if the network forwards on a hop-by-hop basis and does
skipping to change at page 20, line 20 skipping to change at page 20, line 20
advertised for consistency, the second best path should be advertised advertised for consistency, the second best path should be advertised
for fast routing convergence. All further paths and their choice for for fast routing convergence. All further paths and their choice for
selection are completely discretionary; the destination is presumed selection are completely discretionary; the destination is presumed
to be reachable via encapsulation. to be reachable via encapsulation.
5.5. Interactions with Route Filtering 5.5. Interactions with Route Filtering
As noted in the previous section, modification of advertised paths As noted in the previous section, modification of advertised paths
may lead to inconsistent route selection. This is true even when the may lead to inconsistent route selection. This is true even when the
Add-Paths feature is not in use. Similarly, the use of route Add-Paths feature is not in use. Similarly, the use of route
filtering, when used carelessly for iBGP, may result in inconsistent filtering, when used carelessly for IBGP, may result in inconsistent
route selection in an AS with the possibility of introducing route selection in an AS with the possibility of introducing
forwarding loops. forwarding loops.
The Add-Paths feature has additional considerations for route The Add-Paths feature has additional considerations for route
filtering since the receiver of multiple paths is unable to determine filtering since the receiver of multiple paths is unable to determine
by inspection of the received NLRI which path corresponds to the by inspection of the received NLRI which path corresponds to the
sender's active path for the prefix. The sender SHOULD send the best sender's active path for the prefix. The sender SHOULD send the best
path when sending multiple paths for a destination. The receiver must path when sending multiple paths for a destination. The receiver must
take care when rejecting destinations to not discard the best path take care when rejecting destinations to not discard the best path
but permit alternate paths. A failure on either the part of the but permit alternate paths. A failure on either the part of the
skipping to change at page 21, line 7 skipping to change at page 21, line 7
Paths peers. In a non Add-Paths deployment a change in the preference 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 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 when a router has Add-Paths peers changes in non-best path preference
may no longer be invisible and increased route churn may be may no longer be invisible and increased route churn may be
observable. Choosing the right path selection mode and parameters - observable. Choosing the right path selection mode and parameters -
for example not setting N unnecessarily large in the Add-N mode, is for example not setting N unnecessarily large in the Add-N mode, is
important to minimizing this additional churn. important to minimizing this additional churn.
6. Security Considerations 6. Security Considerations
TBD This document introduces no new security concerns in the base
operation of BGP [RFC4271].
7. Acknowledgments 7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
8. Contributors 8. Contributors
Virginie Van den Schrieck The following individuals are acknowledged for their contributions to
Email: v.vandenschrieck@gmail.com earlier versions of this draft: Pradosh Mohapatra, Virginie Van den
Schrieck and Rohit Gupta.
Rohit Gupta
Apple Inc
Email: rxgupta@apple.com
9. IANA Considerations 9. IANA Considerations
TBD IANA has assigned capability number 69 for the ADD-PATH Capability
described in this document. This registration is in the BGP
Capability Codes registry.
10. References 10. References
10.1. Normative References 10.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, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
10.17487/RFC4271, January 2006, <http://www.rfc-
editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, DOI
10.17487/RFC4364, February 2006, <http://www.rfc-
editor.org/info/rfc4364>.
10.2. Informative References 10.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", draft- "Advertisement of Multiple Paths in BGP", draft-
ietf-idr-add-paths-07, June 17, 2012. ietf-idr-add-paths-13, Dec 11, 2015.
[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 Raszuk, "Fast Connectivity Restoration Using BGP
Add-path", draft-pmohapat-idr-fast-conn-restore- Add-path", draft-pmohapat-idr-fast-conn-restore-
02.txt, Oct 3, 2011. 02.txt, Oct 3, 2011.
[BEST-EXT] Marques, P., Fernando, R., Chen, E., Mohapatra, P.,
Gredler, H., "Advertisement of the best external
route in BGP", draft-ietf-idr-best-external-05.txt,
Jan 3, 2012.
[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- Persistent Route Oscillation Solutions", draft-
walton-bgp-route-oscillation-stop-06.txt, June 14, walton-bgp-route-oscillation-stop-06.txt, June 14,
2012. 2012.
[Basu-ibgp-osc] Basu, A., Ong, C., Rasala, A., Sheperd, B., and G. [BGP-ORR] Raszuk, R., Cassar, C., Aman, E., Decraene, B.,
Wilfong, "Route oscillations in iBGP with Route Litkowski, S., Wang, K., "BGP Optimal Route
Reflection", Sigcomm 2002. Reflection (BGP-ORR)", draft-ietf-idr-bgp-optimal-
route-reflection-11, Jan 8, 2016.
[BGP-ORR] Raszuk, R., Cassar, C., Aman, E., Decraene, B., "BGP
Optimal Route Reflection", draft-raszuk-bgp-optimal-
route-reflection-01, March 11, 2011.
[RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway
Protocol 4 (BGP-4), January 2006.
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
neighbor AS from which it was learned, and to advertise the best path neighbor AS from which it was learned, and to advertise the best path
in each of those groups. in each of those groups.
The control plane stress induced by this solution is the computation The control plane stress induced by this solution is the computation
of the per-neighbor path group, and the application of the decision of the per-neighbor path group, and the application of the decision
process to each of them. The Control-Plane load is bounded by the process to each of them. The Control-Plane load is bounded by the
number of neighboring ASes advertising a prefix, which cannot be number of neighboring ASes advertising a prefix, which cannot be
known a-priori. known a-priori.
Path optimality and backup path optimality are not guaranteed, as the Path optimality and backup path optimality are not guaranteed, as the
paths advertised are not all the AS-wide preferred paths. Backup path paths advertised are not all the AS-wide preferred paths. Backup path
availability is not guaranteed. Indeed, if only one AS advertises availability is not guaranteed. Indeed, if only one AS advertises
this prefix, even on multiple eBGP sessions, only one of the paths this prefix, even on multiple EBGP sessions, only one of the paths
may be selected and advertised. may be selected and advertised.
A.2. Best LocPref/Second LocPref A.2. Best LocPref/Second LocPref
This selection method consists in grouping the paths by Local This selection method consists in grouping the paths by Local
Preference. A router sends to its peers all paths with the highest Preference. A router sends to its peers all paths with the highest
Local Preference. If there is only a single path with the highest Local Preference. If there is only a single path with the highest
Local Preference, it also sends all paths with the second best Local Local Preference, it also sends all paths with the second best Local
Preference. Preference.
This method ensures that all routers know all paths with the best This method ensures that all routers know all paths with the best
local preference. As local preference are often related to the type local preference. As local preference are often related to the type
of peering of the peer the path comes from, this ensures that in case of peering of the peer the path comes from, this ensures that in case
of failure, routers have a backup path of equivalent quality. This of failure, routers have a backup path of equivalent quality. This
prevents for example that a router switches temporarily on a peer prevents for example that a router switches temporarily on a peer
path while an alternate path from a customer is available but hidden path while an alternate path from a customer is available but hidden
at the border of the AS. Such a situation could result in a at the border of the AS. Such a situation could result in a
temporary withdrawal of the prefix on some eBGP sessions when the temporary withdrawal of the prefix on some EBGP sessions when the
router selects the path via the peer. router selects the path via the peer.
The advertisement of the Second Local Preference occurs when there is The advertisement of the Second Local Preference occurs when there is
no alternate path with the same quality as the best path. This way, no alternate path with the same quality as the best path. This way,
fast convergence is still ensured. Backup path is optimal, as it has fast convergence is still ensured. Backup path is optimal, as it has
the second AS-Wide preference, which becomes the AS-wide best the second AS-Wide preference, which becomes the AS-wide best
preference upon failure of the primary one. preference upon failure of the primary one.
Sending all the paths with a given Local Preference also has a Sending all the paths with a given Local Preference also has a
positive impact on routing optimality. Indeed, this allows border positive impact on routing optimality. Indeed, this allows border
 End of changes. 60 change blocks. 
113 lines changed or deleted 130 lines changed or added

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