draft-ietf-idr-add-paths-guidelines-02.txt   draft-ietf-idr-add-paths-guidelines-03.txt 
Network Working Group J. Uttaro Network Working Group J. Uttaro
Internet Draft AT&T Internet Draft AT&T
Intended status: Standards Track V. Van den Schrieck Intended status: Standards Track V. Van den Schrieck
Nov 25, 2011 UCLouvain May 25, 2012 Individual Contributor
Expires: May 25, 2012 P. Francois Expires: Nov 25, 2012 P. Francois
IMDEA Networks IMDEA Networks
R. Fragassi R. Fragassi
A. Simpson A. Simpson
Alcatel-Lucent Alcatel-Lucent
P. Mohapatra P. Mohapatra
Cisco Systems Cisco Systems
Best Practices for Advertisement of Multiple Paths in IBGP Best Practices for Advertisement of Multiple Paths in IBGP
draft-ietf-idr-add-paths-guidelines-02.txt draft-ietf-idr-add-paths-guidelines-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 25, 2012. This Internet-Draft will expire on Nov 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Abstract Abstract
Add-Paths is a BGP enhancement that allows a BGP router to advertise Add-Paths is a BGP enhancement that allows a BGP router to advertise
multiple distinct paths for the same prefix/NLRI. This provides a multiple distinct paths for the same prefix/NLRI. This provides a
number of potential benefits, including reduced routing churn, faster number of potential benefits, including reduced routing churn, faster
convergence and better loadsharing. convergence and better loadsharing.
This document provides recommendations to implementers of Add-Paths This document provides recommendations to implementers of Add-Paths
so that network operators have the tools needed to address their so that network operators have the tools needed to address their
skipping to change at page 2, line 48 skipping to change at page 2, line 48
4.3.1. Path Selection Modes................................11 4.3.1. Path Selection Modes................................11
4.3.1.1. Advertise All Paths............................11 4.3.1.1. Advertise All Paths............................11
4.3.1.2. Advertise N Paths..............................12 4.3.1.2. Advertise N Paths..............................12
4.3.1.3. Advertise All AS-Wide Best Paths...............12 4.3.1.3. Advertise All AS-Wide Best Paths...............12
4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths 4.3.1.4. Advertise ALL AS-Wide Best and Next-Best Paths
(Double AS Wide)........................................13 (Double AS Wide)........................................13
4.3.2. Derived Modes from Bounding the Number of Advertised 4.3.2. Derived Modes from Bounding the Number of Advertised
Paths......................................................14 Paths......................................................14
5. Deployment Considerations.....................................14 5. Deployment Considerations.....................................14
5.1. Introducing Add-Paths into an Existing Network...........14 5.1. Introducing Add-Paths into an Existing Network...........14
5.2. Scalability Considerations...............................16 5.2. Scalability Considerations...............................17
5.3. Routing Consistency Considerations.......................17 5.3. Routing Consistency Considerations.......................17
5.4. Consistency between Advertised Paths and Forwarding Paths17 5.4. Consistency between Advertised Paths and Forwarding Paths18
5.5. Routing Churn............................................18 5.5. Routing Churn............................................19
6. Security Considerations.......................................18 6. Security Considerations.......................................19
7. IANA Considerations...........................................18 7. IANA Considerations...........................................19
8. Conclusions...................................................18 8. Conclusions...................................................19
9. References....................................................19 9. References....................................................19
9.1. Normative References.....................................19 9.1. Normative References.....................................19
9.2. Informative References...................................19 9.2. Informative References...................................19
10. Acknowledgments..............................................19 10. Acknowledgments..............................................20
Appendix A. Other Path Selection Modes...........................20 Appendix A. Other Path Selection Modes...........................21
A.1. Advertise Neighbor-AS Group Best Path....................20 A.1. Advertise Neighbor-AS Group Best Path....................21
A.2. Best LocPref/Second LocPref..............................20 A.2. Best LocPref/Second LocPref..............................21
A.3. Advertise Paths at decisive step -1......................21 A.3. Advertise Paths at decisive step -1......................22
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 11, line 26 skipping to change at page 11, line 26
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 All Paths
A simple rule for advertising multiple paths in iBGP is to simply A simple rule for advertising multiple paths in iBGP is to advertise
advertise to iBGP peers all received paths, provided they pass export to iBGP peers all received paths minus those blocked by export
filters. This solution is easy to implement, but the counterpart is filters or applicable split horizon rules. This solution is easy to
that all those paths need to be stored by all routers that receive implement, but the counterpart is that all those paths need to be
them, which can be quite expensive. If a path to a prefix P is stored by all routers that receive them, which can be quite
advertised to N border routers, with a Full Mesh of iBGP sessions, expensive. If a path to a prefix P is advertised to N border
all routers have N paths in their Adj-RIB-Ins. If Route Reflection routers, with a Full Mesh of iBGP sessions, all routers have N paths
is used and each client is connected to 2 Route Reflectors, it may in their Adj-RIB-Ins. If Route Reflection is used and each client is
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.
skipping to change at page 12, line 15 skipping to change at page 12, line 15
4.3.1.2. Advertise N Paths 4.3.1.2. Advertise N Paths
Another solution is for a router to advertise a maximum of N paths to Another solution is for a router to advertise a maximum of N paths to
iBGP peers. Here, the computational cost is the selection of the N iBGP peers. Here, the computational cost is the selection of the N
paths. Indeed, there must be a ranking of the paths in order to paths. Indeed, there must be a ranking of the paths in order to
advertise the most interesting ones. A way for a router to select N advertise the most interesting ones. A way for a router to select N
paths is to run N times its decision process. At each iteration of paths is to run N times its decision process. At each iteration of
the process only those paths not selected during a previous iteration the process only those paths not selected during a previous iteration
and those with a different NEXT_HOP and BGP Identifier (or Originator and those with a different NEXT_HOP and BGP Identifier (or Originator
ID) combination from previously-selected paths are eligible for ID) combination from previously-selected paths are eligible for
consideration. The memory cost is bounded: a router receives a consideration. In this mode the paths actually advertised to a peer
maximum of N paths for each prefix from each peer. With N equal to 2, are the eligible paths (up to N) minus those blocked by export
all routers know at least two paths and can provide local recovery in filters or applicable split horizon rules. The memory cost is
case of failure. If multipath routing is to be deployed in the AS, N bounded: a router receives a maximum of N paths for each prefix from
can be increased to provide more alternate paths to the routers. 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. 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- 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 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 Reflector. However, as the number of paths that it receives is higher
than without Add-Paths, it is possible that the chosen nexthop is 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 closer to the router in terms of IGP cost than the nexthop that would
have been chosen without Add-Paths. have been chosen without Add-Paths.
This solution helps to reduce routing oscillations, but not in all This solution helps to reduce routing oscillations, but not in all
skipping to change at page 12, line 47 skipping to change at page 12, line 50
The default value of 2 ensures the availability of a backup path (if The default value of 2 ensures the availability of a backup path (if
2 or more paths have been received) while maintaining minimum impact 2 or more paths have been received) while maintaining minimum impact
to memory and churn. If Add-N with N equal to 2 is insufficient to to memory and churn. If Add-N with N equal to 2 is insufficient to
meet another objective (e.g. loadsharing or MED/IGP oscillation) meet another objective (e.g. loadsharing or MED/IGP oscillation)
there is always a large enough value of N that can selected, if N is there is always a large enough value of N that can selected, if N is
configurable, to meet that objective. configurable, to meet that objective.
4.3.1.3. Advertise All AS-Wide Best Paths 4.3.1.3. Advertise All AS-Wide Best Paths
Another choice is to advertise all paths with the same AS-wide Another choice is to 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. 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
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
skipping to change at page 13, line 33 skipping to change at page 13, line 37
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 for advertisement its AS Wide speaker running this mode will select, as candidates for
Best paths, plus all the AS Wide Best paths obtained when removing advertisement, its AS Wide Best paths, plus all the AS Wide Best
the first ones from consideration. paths obtained when removing the first ones from consideration. The
paths actually advertised to a peer are the double-AS_wide candidate
paths minus those blocked by export filters or applicable split
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 to run the usual BGP Decision Process up to and including
the MED rule. The set of paths remaining after that step form the AS- the MED rule. The set of paths remaining after that step form the AS-
skipping to change at page 22, line 14 skipping to change at page 23, 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
Virginie Van den Schrieck Virginie Van den Schrieck
UCLouvain Email: v.vandenschrieck@gmail.com
Place Ste Barbe, 2
Louvain-la-Neuve 1348 BE
Email: virginie.vandenschrieck@uclouvain.be
URI: http://inl.info.ucl.ac.be/vvandens
Pierre Francois Pierre Francois
IMDEA Networks IMDEA Networks
Email: pierre.francois@imdea.org Email: pierre.francois@imdea.org
Roberto Fragassi Roberto Fragassi
Alcatel-Lucent Alcatel-Lucent
600 Mountain Avenue 600 Mountain Avenue
Murray Hill, New Jersey Murray Hill, New Jersey
Email: roberto.fragassi@alcatel-lucent.com Email: roberto.fragassi@alcatel-lucent.com
 End of changes. 15 change blocks. 
42 lines changed or deleted 46 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/