--- 1/draft-ietf-idr-bgp-optimal-route-reflection-04.txt 2013-06-04 19:14:36.839507748 +0100 +++ 2/draft-ietf-idr-bgp-optimal-route-reflection-05.txt 2013-06-04 19:14:36.887508965 +0100 @@ -1,25 +1,24 @@ IDR Working Group R. Raszuk -Internet-Draft NTT MCL +Internet-Draft NTT I3 Intended status: Standards Track C. Cassar -Expires: June 7, 2013 Cisco Systems +Expires: December 06, 2013 Cisco Systems E. Aman TeliaSonera B. Decraene - France Telecom S. Litkowski Orange - December 4, 2012 + June 04, 2013 BGP Optimal Route Reflection (BGP-ORR) - draft-ietf-idr-bgp-optimal-route-reflection-04 + draft-ietf-idr-bgp-optimal-route-reflection-05 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 @@ -39,83 +38,83 @@ services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 June 7, 2013. + This Internet-Draft will expire on December 06, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 5 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . 5 3. Best path selection for BGP hot potato routing from - customized IGP network position . . . . . . . . . . . . . . . 7 - 3.1. Client's perspective best path selection algorithm . . . . 8 - 3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . . 8 - 3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . . 9 + customized IGP network position . . . . . . . . . . . . . . . 6 + 3.1. Client's perspective best path selection algorithm . . . 7 + 3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . 7 + 3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . 8 3.2. Aside: Configuration-based flexible route reflector - placement . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.3. Route reflector client grouping . . . . . . . . . . . . . 10 - 3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 11 - 3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4. Angular distance approximation for BGP warm potato routing . 13 - 4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 14 - 4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 15 - 4.3. Centralized vs distributed route reflectors . . . . . . . 16 - 5. Client's perspective policy based best path selection . . . . 17 - 5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . . 19 - 6. Deployment considerations . . . . . . . . . . . . . . . . . . 20 - 7. Security considerations . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 + placement . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Route reflector client grouping . . . . . . . . . . . . . 9 + 3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 10 + 3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Angular distance approximation for BGP warm potato routing . 12 + 4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 13 + 4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 14 + 4.3. Centralized vs distributed route reflectors . . . . . . . 15 + 5. Client's perspective policy based best path selection . . . . 16 + 5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . 19 + 6. Deployment considerations . . . . . . . . . . . . . . . . . . 19 + 7. Security considerations . . . . . . . . . . . . . . . . . . . 20 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction There are three types of BGP deployments within Autonomous Systems today: full mesh, confederations and route reflection. BGP route reflection is the most popular way to distribute BGP routes between BGP speakers belonging to the same administrative domain. Traditionally route reflectors have been deployed in the forwarding path and carefully placed on the POP to core boundaries. That model @@ -353,26 +352,26 @@ Hierarchy introduces two challenges: The first challenge is that the RR IGP view may differ from a client IGP view by virtue of one or the other having a summarized view versus the other. Summarization, by its nature, loses information. Consider the example where a client within a PoP sees two prefixes with two metrics for two egress points within the PoP, but where the RR only sees a single summary covering reachability to both nexthops as injected by the ABR. For - clarification purposes in the case of ISIS by ABR we refer to - L1/L2 node. However it needs to be observed that inter area - networks running LDP are required to disable summarisation of all - FEC advertised in LDP (typically all loopbacks) unless [RFC5283] - is deployed. Such deployments are not likely to suffer - summarization difficulties. + clarification purposes in the case of ISIS by ABR we refer to L1/ + L2 node. However it needs to be observed that inter area networks + running LDP are required to disable summarisation of all FEC + advertised in LDP (typically all loopbacks) unless [RFC5283] is + deployed. Such deployments are not likely to suffer summarization + difficulties. The second challenge is that in cases where the client is in a different level of hierarchy from the RR, the RR can not build a Shortest Path First (SPF) tree with the client node as root, simply because the topology derived by the IGP will not include the client node. It will instead only include reachability to the client from one or more ABRs. In order to overcome this problem, the RR could compute an SPF tree from the ABRs in the area. The RR would then determine the shortest distance from a client which lives behind the ABRs, to a nexthop, by adding the advertised @@ -935,23 +931,23 @@ [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. 10.2. Informative References [I-D.ietf-idr-add-paths] - Walton, D., Chen, E., Retana, A., and J. Scudder, - "Advertisement of Multiple Paths in BGP", - draft-ietf-idr-add-paths-07 (work in progress), June 2012. + Walton, D., Retana, A., Chen, E., and J. Scudder, + "Advertisement of Multiple Paths in BGP", draft-ietf-idr- + add-paths-08 (work in progress), December 2012. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC1998] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996. [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, February 2006. @@ -963,58 +959,57 @@ [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, October 2009. - [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", - RFC 5714, January 2010. + [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 MCL + NTT I3 101 S Ellsworth Avenue Suite 350 San Mateo, CA 94401 US 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 Marbackagatan 11 - Farsta, SE-123 86 + Farsta SE-123 86 Sweden Email: erik.aman@teliasonera.com Bruno Decraene - France Telecom + Orange 38-40 rue du General Leclerc - Issy les Moulineaux cedex 9, 92794 + Issy les Moulineaux cedex 9 92794 France Email: bruno.decraene@orange.com Stephane Litkowski Orange 9 rue du chene germain - Cesson Sevigne, 35512 + Cesson Sevigne 35512 France Email: stephane.litkowski@orange.com