--- 1/draft-ietf-idr-bgp-optimal-route-reflection-06.txt 2014-07-31 17:14:28.953259536 -0700 +++ 2/draft-ietf-idr-bgp-optimal-route-reflection-07.txt 2014-07-31 17:14:28.997260597 -0700 @@ -1,24 +1,24 @@ IDR Working Group R. Raszuk -Internet-Draft NTT I3 +Internet-Draft Individual Intended status: Standards Track C. Cassar -Expires: July 6, 2014 Cisco Systems +Expires: February 1, 2015 Cisco Systems E. Aman TeliaSonera B. Decraene S. Litkowski Orange - January 2, 2014 + July 31, 2014 BGP Optimal Route Reflection (BGP-ORR) - draft-ietf-idr-bgp-optimal-route-reflection-06 + draft-ietf-idr-bgp-optimal-route-reflection-07 Abstract [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress @@ -53,21 +53,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 6, 2014. + This Internet-Draft will expire on February 1, 2015. Copyright Notice Copyright (c) 2014 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 @@ -176,24 +176,21 @@ amount of BGP state to all the edge routers. In many networks, the number of EBGP peers over which full Internet routing information is received would correlate directly to the number of paths present in each ASBR. This could easily result in tens of paths for each prefix. Notwithstanding this drawback, there are a number of reasons for sending more than just the single best path to the clients. Improved path diversity at the edge is a requirement for fast connectivity restoration, and a requirement for effective BGP level load - balancing. Protocol extensions like add-paths - [I-D.ietf-idr-add-paths] or [RFC6774] diverse-path allow for such - improved path diversity and can be used to address the same problems - addressed by the mechanisms proposed in this draft. + balancing. In practical terms, add/diverse path deployments are expected to result in the distribution of 2, 3 or n (where n is a small number) 'good' paths rather than all domain external paths. While the route reflector chooses one set of n paths and distributes those same n paths to all its route reflector clients, those n paths may not be the right n paths for all clients. In the context of the problem described above, those n paths will not necessarily include the closest egress point out of the network for each route reflector client. The mechanisms proposed in this document are likely to be @@ -912,22 +909,22 @@ IANA is requested to allocate a type code for the Standard BGP Community to be used for inter cluster propagation of angular position of the clients. IANA is requested to allocate a new type code from BGP OPEN Optional Parameter Types registry to be used for Group_ID propagation. 9. Acknowledgments Authors would like to thank Eric Rosen, Clarence Filsfils, Uli - Bornhauser Russ White, Jakob Heitz and Mike Shand for their valuable - input. + Bornhauser Russ White, Jakob Heitz, Mike Shand and Jon Mitchell for + their valuable input. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. @@ -970,28 +967,25 @@ Specific BGP Extended Community", RFC 5668, October 2009. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. [RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, November 2012. Authors' Addresses + Robert Raszuk - NTT I3 - 101 S Ellsworth Avenue Suite 350 - San Mateo, CA 94401 - US + Individual Email: robert@raszuk.net - Christian Cassar Cisco Systems 10 New Square Park Bedfont Lakes, FELTHAM TW14 8HA UK Email: ccassar@cisco.com Erik Aman TeliaSonera