--- 1/draft-ietf-grow-diverse-bgp-path-dist-03.txt 2011-06-23 23:15:59.000000000 +0200 +++ 2/draft-ietf-grow-diverse-bgp-path-dist-04.txt 2011-06-23 23:15:59.000000000 +0200 @@ -1,23 +1,23 @@ GROW Working Group R. Raszuk, Ed. Internet-Draft R. Fernando Intended status: Informational K. Patel -Expires: July 8, 2011 Cisco Systems +Expires: December 3, 2011 Cisco Systems D. McPherson Verisign K. Kumaki KDDI Corporation - January 4, 2011 + Jun 2011 Distribution of diverse BGP paths. - draft-ietf-grow-diverse-bgp-path-dist-03 + draft-ietf-grow-diverse-bgp-path-dist-04 Abstract The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined today BGP has no mechanisms to distribute paths other then best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the @@ -39,21 +39,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,37 +64,37 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BGP Add-Paths Proposal . . . . . . . . . . . . . . . . . . 4 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Multi plane route reflection . . . . . . . . . . . . . . . . . 6 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 - 5. Discussion on current models of IBGP route distribution . . . 13 - 5.1. Full Mesh . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Discussion on current models of IBGP route distribution . . . 14 + 5.1. Full Mesh . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Confederations . . . . . . . . . . . . . . . . . . . . . . 15 - 5.3. Route reflectors . . . . . . . . . . . . . . . . . . . . . 15 - 6. Deployment considerations . . . . . . . . . . . . . . . . . . 15 - 7. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. Route reflectors . . . . . . . . . . . . . . . . . . . . . 16 + 6. Deployment considerations . . . . . . . . . . . . . . . . . . 16 + 7. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 18 8. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. Security considerations . . . . . . . . . . . . . . . . . . . 18 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 9. Security considerations . . . . . . . . . . . . . . . . . . . 19 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Current BGP4 [RFC4271] protocol specification allows for the selection and propagation of only one best path for each prefix. The BGP protocol as defined today has no mechanism to distribute other then best path between its speakers. This behaviour results in a number of problems in the deployment of new applications and services. @@ -131,22 +131,22 @@ number of services carried over BGP the add-paths proposal was 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 four octet value called the Path Identifier. The implication of this change on a BGP implementation is that it must now maintain per path, instead of per prefix, peer advertisement state to track which of the peers each path was advertised to. This new requirement has its own memory and processing cost. Suffice to 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, - in part because of this resource overhead. + could claimed to support the new add-path behaviour in production + code, in major part due to this resource overhead. An important observation is that distribution of more than one best path by Autonomous System Border Routers (ASBRs) with multiple EBGP peers attached to it where no "next hop self" is set may result in bestpath selection inconsistency within the autonomous system. Therefore it is also required to attach in the form of a new attribute the possible tie breakers and propagate those within the domain. The example of such attribute for the purpose of fast connectivity restoration to address that very case of ASBR injecting multiple external paths into the IBGP mesh has been presented and @@ -275,31 +275,38 @@ The proposed solution is based on the use of additional route reflectors or new functionality enabled on the existing route reflectors that instead of distributing the best path for each route will distribute an alternative path other then best. The best path (main) reflector plane distributes the best path for each route as it 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 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 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 logical router partition, new BGP process or just a new configuration knob on an existing route reflector and configuring an additional IBGP session from the current clients if required. There are no code changes required on the route reflector clients for this mechanism to work. It is easy to observe that the installation of one or more additional route reflector control planes is much cheaper and an 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 propagate the Nth best path instead of the overall best path. An implementation is encouraged to enable this new functionality on a per neighbor basis. While this is an implementation detail, the code to calculate Nth best path is also required by other BGP solutions. For example in the application of fast connectivity restoration BGP must calculate a backup path for installation into the RIB and FIB ahead of the actual @@ -841,35 +849,35 @@ draft-decraene-bgp-graceful-shutdown-requirements-01 (work in progress), March 2009. [I-D.ietf-idr-add-paths] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", draft-ietf-idr-add-paths-04 (work in progress), August 2010. [I-D.ietf-idr-best-external] - Marques, P., Fernando, R., Chen, E., and P. Mohapatra, - "Advertisement of the best external route in BGP", - draft-ietf-idr-best-external-02 (work in progress), - August 2010. + Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. + Gredler, "Advertisement of the best external route in + BGP", draft-ietf-idr-best-external-04 (work in progress), + April 2011. [I-D.ietf-idr-route-oscillation] McPherson, D., "BGP Persistent Route Oscillation Condition", draft-ietf-idr-route-oscillation-01 (work in progress), February 2002. [I-D.pmohapat-idr-fast-conn-restore] Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, "Fast Connectivity Restoration Using BGP Add-path", - draft-pmohapat-idr-fast-conn-restore-00 (work in - progress), September 2008. + draft-pmohapat-idr-fast-conn-restore-01 (work in + progress), March 2011. [I-D.raszuk-idr-ibgp-auto-mesh] Raszuk, R., "IBGP Auto Mesh", draft-raszuk-idr-ibgp-auto-mesh-00 (work in progress), June 2003. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.