draft-ietf-grow-diverse-bgp-path-dist-03.txt   draft-ietf-grow-diverse-bgp-path-dist-04.txt 
GROW Working Group R. Raszuk, Ed. GROW Working Group R. Raszuk, Ed.
Internet-Draft R. Fernando Internet-Draft R. Fernando
Intended status: Informational K. Patel Intended status: Informational K. Patel
Expires: July 8, 2011 Cisco Systems Expires: December 3, 2011 Cisco Systems
D. McPherson D. McPherson
Verisign Verisign
K. Kumaki K. Kumaki
KDDI Corporation KDDI Corporation
January 4, 2011 Jun 2011
Distribution of diverse BGP paths. Distribution of diverse BGP paths.
draft-ietf-grow-diverse-bgp-path-dist-03 draft-ietf-grow-diverse-bgp-path-dist-04
Abstract Abstract
The BGP4 protocol specifies the selection and propagation of a single The BGP4 protocol specifies the selection and propagation of a single
best path for each prefix. As defined today BGP has no mechanisms to best path for each prefix. As defined today BGP has no mechanisms to
distribute paths other then best path between its speakers. This distribute paths other then best path between its speakers. This
behaviour results in number of disadvantages for new applications and behaviour results in number of disadvantages for new applications and
services. services.
This document presents an alternative mechanism for solving the This document presents an alternative mechanism for solving the
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 5, 2011. This Internet-Draft will expire on December 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BGP Add-Paths Proposal . . . . . . . . . . . . . . . . . . 4 2.1. BGP Add-Paths Proposal . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Multi plane route reflection . . . . . . . . . . . . . . . . . 6 4. Multi plane route reflection . . . . . . . . . . . . . . . . . 6
4.1. Co-located best and backup path RRs . . . . . . . . . . . 9 4.1. Co-located best and backup path RRs . . . . . . . . . . . 9
4.2. Randomly located best and backup path RRs . . . . . . . . 10 4.2. Randomly located best and backup path RRs . . . . . . . . 11
4.3. Multi plane route servers for Internet Exchanges . . . . . 13 4.3. Multi plane route servers for Internet Exchanges . . . . . 13
5. Discussion on current models of IBGP route distribution . . . 13 5. Discussion on current models of IBGP route distribution . . . 14
5.1. Full Mesh . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Full Mesh . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Confederations . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Confederations . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Route reflectors . . . . . . . . . . . . . . . . . . . . . 15 5.3. Route reflectors . . . . . . . . . . . . . . . . . . . . . 16
6. Deployment considerations . . . . . . . . . . . . . . . . . . 15 6. Deployment considerations . . . . . . . . . . . . . . . . . . 16
7. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 17 7. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 18
8. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security considerations . . . . . . . . . . . . . . . . . . . 18 9. Security considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Current BGP4 [RFC4271] protocol specification allows for the Current BGP4 [RFC4271] protocol specification allows for the
selection and propagation of only one best path for each prefix. The selection and propagation of only one best path for each prefix. The
BGP protocol as defined today has no mechanism to distribute other BGP protocol as defined today has no mechanism to distribute other
then best path between its speakers. This behaviour results in a then best path between its speakers. This behaviour results in a
number of problems in the deployment of new applications and number of problems in the deployment of new applications and
services. services.
skipping to change at page 5, line 6 skipping to change at page 5, line 6
number of services carried over BGP the add-paths proposal was number of services carried over BGP the add-paths proposal was
submitted in 2002 to enable BGP to distribute more then one path. submitted in 2002 to enable BGP to distribute more then one path.
This is achieved by including as a part of the NLRI an additional This is achieved by including as a part of the NLRI an additional
four octet value called the Path Identifier. four octet value called the Path Identifier.
The implication of this change on a BGP implementation is that it The implication of this change on a BGP implementation is that it
must now maintain per path, instead of per prefix, peer advertisement must now maintain per path, instead of per prefix, peer advertisement
state to track which of the peers each path was advertised to. This state to track which of the peers each path was advertised to. This
new requirement has its own memory and processing cost. Suffice to new requirement has its own memory and processing cost. Suffice to
say that by the end of 2009 none of the commercial BGP implementation say that by the end of 2009 none of the commercial BGP implementation
could claim to support the new add-path behaviour in production code, could claimed to support the new add-path behaviour in production
in part because of this resource overhead. code, in major part due to this resource overhead.
An important observation is that distribution of more than one best An important observation is that distribution of more than one best
path by Autonomous System Border Routers (ASBRs) with multiple EBGP path by Autonomous System Border Routers (ASBRs) with multiple EBGP
peers attached to it where no "next hop self" is set may result in peers attached to it where no "next hop self" is set may result in
bestpath selection inconsistency within the autonomous system. bestpath selection inconsistency within the autonomous system.
Therefore it is also required to attach in the form of a new Therefore it is also required to attach in the form of a new
attribute the possible tie breakers and propagate those within the attribute the possible tie breakers and propagate those within the
domain. The example of such attribute for the purpose of fast domain. The example of such attribute for the purpose of fast
connectivity restoration to address that very case of ASBR injecting connectivity restoration to address that very case of ASBR injecting
multiple external paths into the IBGP mesh has been presented and multiple external paths into the IBGP mesh has been presented and
skipping to change at page 8, line 27 skipping to change at page 8, line 27
The proposed solution is based on the use of additional route The proposed solution is based on the use of additional route
reflectors or new functionality enabled on the existing route reflectors or new functionality enabled on the existing route
reflectors that instead of distributing the best path for each route reflectors that instead of distributing the best path for each route
will distribute an alternative path other then best. The best path will distribute an alternative path other then best. The best path
(main) reflector plane distributes the best path for each route as it (main) reflector plane distributes the best path for each route as it
does today. The second plane distributes the second best path for does today. The second plane distributes the second best path for
each route and so on. Distribution of N paths for each route can be each route and so on. Distribution of N paths for each route can be
achieved by using N reflector planes. achieved by using N reflector planes.
As diverse-path functionality may be enabled on a per peer basis one
of the deployment model can be realized to continue advertisement of
overall best path from both route reflectors while in addition new
session can be provisioned to get additional path. That will allow
the non interupted use of best path even if one of the RRs goes down
provided that the overall best path is still a valid one.
Each plane of route reflectors is a logical entity and may or may not Each plane of route reflectors is a logical entity and may or may not
be co-located with the existing best path route reflectors. Adding a be co-located with the existing best path route reflectors. Adding a
route reflector plane to a network may be as easy as enabling a route reflector plane to a network may be as easy as enabling a
logical router partition, new BGP process or just a new configuration logical router partition, new BGP process or just a new configuration
knob on an existing route reflector and configuring an additional knob on an existing route reflector and configuring an additional
IBGP session from the current clients if required. There are no code IBGP session from the current clients if required. There are no code
changes required on the route reflector clients for this mechanism to changes required on the route reflector clients for this mechanism to
work. It is easy to observe that the installation of one or more work. It is easy to observe that the installation of one or more
additional route reflector control planes is much cheaper and an additional route reflector control planes is much cheaper and an
easier than the need of upgrading 100s of route reflector clients in easier than the need of upgrading 100s of route reflector clients in
the entire network to support different protocol encoding. the entire network to support different bgp protocol encoding.
Diverse path route reflectors need the new ability to calculate and Diverse path route reflectors need the new ability to calculate and
propagate the Nth best path instead of the overall best path. An propagate the Nth best path instead of the overall best path. An
implementation is encouraged to enable this new functionality on a implementation is encouraged to enable this new functionality on a
per neighbor basis. per neighbor basis.
While this is an implementation detail, the code to calculate Nth While this is an implementation detail, the code to calculate Nth
best path is also required by other BGP solutions. For example in best path is also required by other BGP solutions. For example in
the application of fast connectivity restoration BGP must calculate a the application of fast connectivity restoration BGP must calculate a
backup path for installation into the RIB and FIB ahead of the actual backup path for installation into the RIB and FIB ahead of the actual
skipping to change at page 20, line 32 skipping to change at page 21, line 26
draft-decraene-bgp-graceful-shutdown-requirements-01 (work draft-decraene-bgp-graceful-shutdown-requirements-01 (work
in progress), March 2009. in progress), March 2009.
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", "Advertisement of Multiple Paths in BGP",
draft-ietf-idr-add-paths-04 (work in progress), draft-ietf-idr-add-paths-04 (work in progress),
August 2010. August 2010.
[I-D.ietf-idr-best-external] [I-D.ietf-idr-best-external]
Marques, P., Fernando, R., Chen, E., and P. Mohapatra, Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
"Advertisement of the best external route in BGP", Gredler, "Advertisement of the best external route in
draft-ietf-idr-best-external-02 (work in progress), BGP", draft-ietf-idr-best-external-04 (work in progress),
August 2010. April 2011.
[I-D.ietf-idr-route-oscillation] [I-D.ietf-idr-route-oscillation]
McPherson, D., "BGP Persistent Route Oscillation McPherson, D., "BGP Persistent Route Oscillation
Condition", draft-ietf-idr-route-oscillation-01 (work in Condition", draft-ietf-idr-route-oscillation-01 (work in
progress), February 2002. progress), February 2002.
[I-D.pmohapat-idr-fast-conn-restore] [I-D.pmohapat-idr-fast-conn-restore]
Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk,
"Fast Connectivity Restoration Using BGP Add-path", "Fast Connectivity Restoration Using BGP Add-path",
draft-pmohapat-idr-fast-conn-restore-00 (work in draft-pmohapat-idr-fast-conn-restore-01 (work in
progress), September 2008. progress), March 2011.
[I-D.raszuk-idr-ibgp-auto-mesh] [I-D.raszuk-idr-ibgp-auto-mesh]
Raszuk, R., "IBGP Auto Mesh", Raszuk, R., "IBGP Auto Mesh",
draft-raszuk-idr-ibgp-auto-mesh-00 (work in progress), draft-raszuk-idr-ibgp-auto-mesh-00 (work in progress),
June 2003. June 2003.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006. (IBGP)", RFC 4456, April 2006.
 End of changes. 14 change blocks. 
26 lines changed or deleted 33 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/