draft-ietf-idr-add-paths-guidelines-06.txt   draft-ietf-idr-add-paths-guidelines-07.txt 
Network Working Group J. Uttaro IDR Working Group J. Uttaro
Internet Draft AT&T Internet-Draft AT&T
Expires: July 27, 2014 P. Francois Intended status: Standards Track
Intended status: Standards Track IMDEA Networks Expires: Jun 3, 2015 P. Francois
January 27, 2014 R. Fragassi IMDEA Networks
A. Simpson
Alcatel-Lucent
K. Patel K. Patel
Cisco Systems Cisco Systems
P. Mohapatra P. Mohapatra
Cumulus Networks Cumulus Networks
J. Haas
Juniper Networks
A. Simpson
R. Fragassi
Alcatel-Lucent
Dec 3, 2014
Best Practices for Advertisement of Multiple Paths in IBGP Best Practices for Advertisement of Multiple Paths in IBGP
draft-ietf-idr-add-paths-guidelines-06.txt draft-ietf-idr-add-paths-guidelines-07.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 38 skipping to change at page 1, line 47
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 Jul 27, 2014. This Internet-Draft will expire on Jun 3, 2015.
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 36 skipping to change at page 2, line 45
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...7
4. Implementation Guidelines......................................8 4. Implementation Guidelines......................................8
4.1. Capability Negotiation....................................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................................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 N Paths..............................11
4.3.1.2. Advertise N Paths..............................12 4.3.1.2. Advertise All Paths............................12
4.3.1.3. Advertise All AS-Wide Best Paths...............12 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)........................................13
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......................................................14 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.....................................15
5.1. Introducing Add-Paths into an Existing Network...........15 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. Routing Churn............................................20 5.5. Interactions with Route Filtering........................20
6. Security Considerations.......................................20 5.6. Routing Churn............................................20
7. Acknowledgments...............................................20 6. Security Considerations.......................................21
8. Contributors..................................................20 7. Acknowledgments...............................................21
9. IANA Considerations...........................................20 8. Contributors..................................................21
10. References...................................................20 9. IANA Considerations...........................................21
10.1. Normative References....................................20 10. References...................................................21
10.1. Normative References....................................21
10.2. Informative References..................................21 10.2. Informative References..................................21
Appendix A. Other Path Selection Modes...........................22 Appendix A. Other Path Selection Modes...........................23
A.1. Advertise Neighbor-AS Group Best Path....................22 A.1. Advertise Neighbor-AS Group Best Path....................23
A.2. Best LocPref/Second LocPref..............................22 A.2. Best LocPref/Second LocPref..............................23
A.3. Advertise Paths at decisive step -1......................23 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 [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 8, line 24 skipping to change at page 8, line 24
. Considerations related to Add-Paths capability negotiation . Considerations related to Add-Paths capability negotiation
. Receiving BGP routes from Add-Paths peers . Receiving BGP routes from Add-Paths peers
. Advertising BGP routes to Add-Paths peers. This section . Advertising BGP routes to Add-Paths peers. This section
discusses various path selection algorithms, which are the discusses various path selection algorithms, which are the
procedures available to an Add-Paths speaker for deciding which procedures available to an Add-Paths speaker for deciding which
set of paths to advertise to an Add-Paths peer for particular set of paths to advertise to an Add-Paths peer for particular
prefixes. prefixes.
4.1. Capability Negotiation 4.1. Capability Advertisement
+---+ +---+ +---+ +---+
|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),
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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 shall be to both send and receive. operation is 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
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
typically send a single path chosen based on their own IGP tie-break typically send a single path chosen based on their own IGP tie-
(although modifications to this are proposed in [BGP-ORR]). breaking procedure (although modifications to this are proposed in
Increasing path visibility would also help routers to learn the path [BGP-ORR]). Increasing path visibility would also help routers to
that is best suited for them w.r.t. the IGP tie-break. learn the path that is best suited for them w.r.t. the IGP tie-
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
skipping to change at page 11, line 24 skipping to change at page 11, line 25
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 All Paths 4.3.1.1. Advertise N Paths
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
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
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
its decision process N times and consider at each iteration only the
paths that meet all of the following criteria:
(a) not selected during a previous iteration
(b)_diverse with respect to previously selected paths (see section
2 for the definition of a diverse path)
(c) not rejected by route filters or split horizon advertisement
rules
The memory cost of this path selection mode is bounded: a router
receives a 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 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.
Path optimality and backup path optimality are not guaranteed, i.e.
it is possible that the optimal path of a router (w.r.t. IGP tie-
breaking) is not contained in the set of paths advertised by its
Route 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
cases. Indeed, path visibility is still constrained by the maximum
number of paths, and configurations with routing oscillations still
exist.
This path selection mode is MANDATORY. The default value of N MUST be
2. The value of N MUST be configurable and MAY be upper bounded by
an implementation.
The default value of 2 ensures the availability of a backup path (if
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
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
configurable, to meet that objective.
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.
skipping to change at page 12, line 5 skipping to change at page 13, line 11
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.2. Advertise N Paths 4.3.1.3. Advertise All AS-Wide Best Paths
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
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
paths is to run N times its decision process. At each iteration of
the process only those paths not selected during a previous iteration
and those with a different NEXT_HOP and BGP Identifier (or Originator
ID) combination from previously-selected paths are eligible for
consideration. In this mode the paths actually advertised to a peer
are the eligible paths (up to N) minus those blocked by export
filters or applicable split horizon rules. The memory cost is
bounded: a router receives a 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 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.
Path optimality and backup path optimality are not guaranteed, i.e.
it is possible that the optimal path of a router (w.r.t. IGP tie-
break) is not contained in the set of paths advertised by its Route
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
cases. Indeed, path visibility is still constrained by the maximum
number of paths, and configurations with routing oscillations still
exist.
This path selection mode is MANDATORY. The default value of N MUST be
2. The value of N MUST be configurable and MAY be upper bounded by
an implementation.
The default value of 2 ensures the availability of a backup path (if
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
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
configurable, to meet that objective.
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.
skipping to change at page 13, line 31 skipping to change at page 13, line 42
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
requires to run the usual BGP Decision Process up to and including requires the router to run the usual BGP Decision Process up to and
the MED rule. The set of paths remaining after that step form the AS- including the MED rule. The set of paths remaining after that step
Wide best paths. Next, a best path selection algorithm is run up to form the AS-Wide best paths. Next, a best path selection algorithm
and including the MED rule, based on the paths that are not in the is run up to and including the MED rule, based on the paths that are
set of AS-Wide best paths. not in the 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.
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
skipping to change at page 20, line 5 skipping to change at page 19, line 49
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].
5.5. Routing Churn In general, if the network forwards on a hop-by-hop basis and does
not make use of encapsulation, it is necessary to advertise the best
path. The second path that is advertised should be the second best
path using one of the path selection modes described previously.
Additional paths are discretionary with the presumption that they can
be forwarded on a hop-by-hop basis.
Similarly, if the network uses encapsulation, the best path should be
advertised for consistency, the second best path should be advertised
for fast routing convergence. All further paths and their choice for
selection are completely discretionary; the destination is presumed
to be reachable via encapsulation.
5.5. Interactions with Route Filtering
As noted in the previous section, modification of advertised paths
may lead to inconsistent route selection. This is true even when the
Add-Paths feature is not in use. Similarly, the use of route
filtering, when used carelessly for iBGP, may result in inconsistent
route selection in an AS with the possibility of introducing
forwarding loops.
The Add-Paths feature has additional considerations for route
filtering since the receiver of multiple paths is unable to determine
by inspection of the received NLRI which path corresponds to the
sender's active path for the prefix. The sender SHOULD send the best
path when sending multiple paths for a destination. The receiver must
take care when rejecting destinations to not discard the best path
but permit alternate paths. A failure on either the part of the
sender or receiver to distribute/receive the best path may result in
inconsistent route selection.
An implementation MAY support the ability to suppress advertisement
of all alternate paths when the export policy would otherwise
suppress the best path.
5.6. Routing Churn
As noted in section 3.3 using Add-Paths between IBGP peers can help 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 to reduce routing churn with EBGP peers. This benefit does however
come at the cost of potentially increased churn between the IBGP Add- 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 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
skipping to change at page 24, line 14 skipping to change at page 25, line 14
Authors' Addresses Authors' Addresses
Jim Uttaro Jim Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 USA Middletown, NJ 07748 USA
Email: uttaro@att.com Email: uttaro@att.com
Pierre Francois Pierre Francois
IMDEA Networks Institute IMDEA Networks
Avenida del Mar Mediterraneo Avda. del Mar Mediterraneo, 22
Leganes 28919 Leganese 28918
Spain ES
Email: pierre.francois@imdea.org Email: pierre.francois@imdea.org
Pradosh Mohapatra Pradosh Mohapatra
Cumulus Networks Cumulus Networks
pmohapat@cumulusnetworks.com pmohapat@cumulusnetworks.com
Roberto Fragassi Roberto Fragassi
Alcatel-Lucent Alcatel-Lucent
600 Mountain Avenue 600 Mountain Avenue
Murray Hill, New Jersey Murray Hill, New Jersey
skipping to change at line 1001 skipping to change at page 25, line 42
600 March Road 600 March Road
Ottawa, Ontario K2K 2E6 Ottawa, Ontario K2K 2E6
Canada Canada
Email: adam.simpson@alcatel-lucent.com Email: adam.simpson@alcatel-lucent.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Jeffrey Haas
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: jhaas@juniper.net
 End of changes. 24 change blocks. 
92 lines changed or deleted 146 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/