draft-ietf-idr-add-paths-guidelines-04.txt   draft-ietf-idr-add-paths-guidelines-05.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 Expires: Dec 21, 2013 P. Francois
Nov 26, 2012 Individual Contributor Intended status: Standards Track IMDEA Networks
Expires: May 26, 2013 P. Francois June 21, 2013 R. Fragassi
IMDEA Networks
R. Fragassi
A. Simpson A. Simpson
Alcatel-Lucent Alcatel-Lucent
P. Mohapatra K. Patel
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-04.txt draft-ietf-idr-add-paths-guidelines-05.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 36
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 26, 2013. This Internet-Draft will expire on Dec 21, 2013.
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 44 skipping to change at page 2, line 43
4. Implementation Guidelines......................................8 4. Implementation Guidelines......................................8
4.1. Capability Negotiation....................................8 4.1. Capability Negotiation....................................8
4.2. Receiving Multiple Paths..................................9 4.2. Receiving Multiple Paths..................................9
4.3. Advertising Multiple Paths................................9 4.3. Advertising Multiple Paths................................9
4.3.1. Path Selection Modes................................11 4.3.1. Path Selection Modes................................11
4.3.1.1. Advertise All Paths............................11 4.3.1.1. Advertise All Paths............................11
4.3.1.2. Advertise N Paths..............................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.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......................................................14
5. Deployment Considerations.....................................14 4.3.3. Derived Modes from Adding N More Paths..............15
5.1. Introducing Add-Paths into an Existing Network...........14 5. Deployment Considerations.....................................15
5.2. Scalability Considerations...............................17 5.1. Introducing Add-Paths into an Existing Network...........15
5.3. Routing Consistency Considerations.......................17 5.2. Scalability Considerations...............................18
5.4. Consistency between Advertised Paths and Forwarding Paths18 5.3. Routing Consistency Considerations.......................18
5.5. Routing Churn............................................19 5.4. Consistency between Advertised Paths and Forwarding Paths19
6. Security Considerations.......................................19 5.5. Routing Churn............................................20
7. IANA Considerations...........................................19 6. Security Considerations.......................................20
8. Conclusions...................................................19 7. Acknowledgments...............................................20
9. References....................................................19 8. Contributors..................................................20
9.1. Normative References.....................................19 9. IANA Considerations...........................................20
9.2. Informative References...................................19 10. References...................................................21
10. Acknowledgments..............................................20 10.1. Normative References....................................21
Appendix A. Other Path Selection Modes...........................21 10.2. Informative References..................................21
A.1. Advertise Neighbor-AS Group Best Path....................21 Appendix A. Other Path Selection Modes...........................22
A.2. Best LocPref/Second LocPref..............................21 A.1. Advertise Neighbor-AS Group Best Path....................22
A.3. Advertise Paths at decisive step -1......................22 A.2. Best LocPref/Second LocPref..............................22
A.3. Advertise Paths at decisive step -1......................23
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 14, line 21 skipping to change at page 14, line 21
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
Many BGP implementations support BGP Multipath, allowing a BGP router
to use multiple BGP next-hops for forwarding towards a prefix/NLRI
when the corresponding paths are considered equally preferred. In
cases where the deployment of Add-Paths is mostly aimed at providing
multiple paths for load balancing with BGP Multipath, a natural
approach for a BGP speaker supporting Add-paths is to advertise the
paths that are selected by its BGP multipath selection algorithm.
BGP Multipath selection algorithms can vary depending on the
implementation and configuration options. An Add-Paths mode based on
BGP multipath is considered practical because it lets the BGP path
propagation be aligned with the load balancing objectives expressed
by the operator configuring BGP multipath.
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
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
bound on the number of advertised paths the ones that should be
advertised are those with the highest degree of preference by the BGP
decision process. This can be achieved if the advertising router has
strictly ordered all of its paths.
This path selection mode is OPTIONAL.
4.3.2. Derived Modes from Bounding the Number of Advertised Paths 4.3.2. Derived Modes from Bounding the Number of Advertised Paths
For some of the modes discussed in section 4.3.1 the number of paths For some of the modes discussed in section 4.3.1 the number of paths
selected by the algorithm (M) is not predictable in advance, and selected by the algorithm (M) is not predictable in advance, and
depends on factors such as network topology. For such modes, depends on factors such as network topology. For such modes,
implementations MAY support the ability to limit the number of implementations MAY support the ability to limit the number of
advertised paths to some value N that is less than M. advertised paths to some value N that is less than M.
It must be noted that the resulting derivative mode may no longer It must be noted that the resulting derivative mode may no longer
meet the properties stated in section 4.3.1 (which assumes N=M). This meet the properties stated in section 4.3.1 (which assumes N=M). This
is particularly true for the MED oscillation avoidance property. The is particularly true for the MED oscillation avoidance property. The
use of such bounds thus needs to be considered carefully in use of such bounds thus needs to be considered carefully in
deployments where MED oscillation avoidance is a key goal of deployments where MED oscillation avoidance is a key goal of
deploying Add-path. If fast recovery is the main objective then it is deploying Add-path. If fast recovery is the main objective then it is
reasonable and sufficient to set N to 2. If the main goal is reasonable and sufficient to set N to 2. If the main goal is
improved load-balancing then limiting N to number of ECMP paths improved load-balancing then limiting N to number of ECMP paths
supported by the forwarding planes of the receiving routers is also a supported by the forwarding planes of the receiving routers is also a
reasonable practice. reasonable practice.
4.3.3. Derived Modes from Adding N More Paths
Some modes discussed in section 4.3.1 may result in only one or a few
selected paths, depending on network topology and/or router
configuration, and this small number of paths may not meet minimum
requirements for backup path or load balancing purposes. When using
such modes implementations MAY support the ability to add N more
paths to the set returned by the basic selection algorithm as
described in section 4.3.1. The N more paths should be the N next-
best paths, as determined by the BGP decision process.
It must be noted that the resulting derivative mode may no longer
meet the properties stated in section 4.3.1 (which assumes N=0).
5. Deployment Considerations 5. Deployment Considerations
This section proposes a potential strategy for introducing Add-Paths This section proposes a potential strategy for introducing Add-Paths
into an existing network and discusses considerations related to into an existing network and discusses considerations related to
scalability, routing consistency and routing churn. scalability, routing consistency and routing churn.
5.1. Introducing Add-Paths into an Existing Network 5.1. Introducing Add-Paths into an Existing Network
There are many possible ways that Add-Paths can be introduced into an There are many possible ways that Add-Paths can be introduced into an
existing deployed network. It is not a practical goal for this existing deployed network. It is not a practical goal for this
skipping to change at page 19, line 22 skipping to change at page 20, line 22
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 TBD
7. IANA Considerations 7. Acknowledgments
TBD This document was prepared using 2-Word-v2.0.template.dot.
8. Conclusions 8. Contributors
Virginie Van den Schrieck
Email: v.vandenschrieck@gmail.com
Pradosh Mohapatra
Cumulus Networks
Email: pmohapat@cumulusnetworks.com
Rohit Gupta
Apple Inc
Email: rxgupta@apple.com
9. IANA Considerations
TBD TBD
9. References 10. References
9.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, March 1997.
9.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-07, June 17, 2012.
[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.
skipping to change at page 20, line 16 skipping to change at page 22, line 5
Wilfong, "Route oscillations in iBGP with Route Wilfong, "Route oscillations in iBGP with Route
Reflection", Sigcomm 2002. Reflection", Sigcomm 2002.
[BGP-ORR] Raszuk, R., Cassar, C., Aman, E., Decraene, B., "BGP [BGP-ORR] Raszuk, R., Cassar, C., Aman, E., Decraene, B., "BGP
Optimal Route Reflection", draft-raszuk-bgp-optimal- Optimal Route Reflection", draft-raszuk-bgp-optimal-
route-reflection-01, March 11, 2011. route-reflection-01, March 11, 2011.
[RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway
Protocol 4 (BGP-4), January 2006. Protocol 4 (BGP-4), January 2006.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Appendix A. Other Path Selection Modes Appendix A. Other Path Selection Modes
A.1. Advertise Neighbor-AS Group Best Path A.1. Advertise Neighbor-AS Group Best Path
[walton-osc] proposes that a router groups its paths based on the [walton-osc] proposes that a router groups its paths based on the
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
skipping to change at page 23, line 13 skipping to change at page 24, line 13
in the set of paths advertised. in the set of paths advertised.
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
Email: v.vandenschrieck@gmail.com
Pierre Francois Pierre Francois
IMDEA Networks IMDEA Networks
Avenida del Mar Mediterraneo Avenida del Mar Mediterraneo
Leganes 28919 Leganes 28919
Spain Spain
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
Adam Simpson Adam Simpson
Alcatel-Lucent Alcatel-Lucent
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
Pradosh Mohapatra 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: pmohapat@cisco.com Email: keyupate@cisco.com
 End of changes. 18 change blocks. 
39 lines changed or deleted 86 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/