draft-ietf-idr-bgp-optimal-route-reflection-04.txt   draft-ietf-idr-bgp-optimal-route-reflection-05.txt 
IDR Working Group R. Raszuk IDR Working Group R. Raszuk
Internet-Draft NTT MCL Internet-Draft NTT I3
Intended status: Standards Track C. Cassar Intended status: Standards Track C. Cassar
Expires: June 7, 2013 Cisco Systems Expires: December 06, 2013 Cisco Systems
E. Aman E. Aman
TeliaSonera TeliaSonera
B. Decraene B. Decraene
France Telecom
S. Litkowski S. Litkowski
Orange Orange
December 4, 2012 June 04, 2013
BGP Optimal Route Reflection (BGP-ORR) BGP Optimal Route Reflection (BGP-ORR)
draft-ietf-idr-bgp-optimal-route-reflection-04 draft-ietf-idr-bgp-optimal-route-reflection-05
Abstract Abstract
[RFC4456] asserts that, because the Interior Gateway Protocol (IGP) [RFC4456] asserts that, because the Interior Gateway Protocol (IGP)
cost to a given point in the network will vary across routers, "the cost to a given point in the network will vary across routers, "the
route reflection approach may not yield the same route selection route reflection approach may not yield the same route selection
result as that of the full IBGP mesh approach." One practical result as that of the full IBGP mesh approach." One practical
implication of this assertion is that the deployment of route implication of this assertion is that the deployment of route
reflection may thwart the ability to achieve hot potato routing. Hot reflection may thwart the ability to achieve hot potato routing. Hot
potato routing attempts to direct traffic to the closest AS egress potato routing attempts to direct traffic to the closest AS egress
skipping to change at page 2, line 5 skipping to change at page 2, line 5
services, tunneled (LSP/IP tunneling) networks with centralized route services, tunneled (LSP/IP tunneling) networks with centralized route
reflectors became commonplace. This is one type of common deployment reflectors became commonplace. This is one type of common deployment
where it would be impractical to satisfy the constraints described in where it would be impractical to satisfy the constraints described in
Section 11 of [RFC4456]. Yet, in such an environment, hot potato Section 11 of [RFC4456]. Yet, in such an environment, hot potato
routing policy remains desirable. routing policy remains desirable.
This document proposes two new solutions which can be deployed to This document proposes two new solutions which can be deployed to
facilitate the application of closest exit point policy centralized facilitate the application of closest exit point policy centralized
route reflection deployments. route reflection deployments.
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). 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 June 7, 2013. This Internet-Draft will expire on December 06, 2013.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 5 2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . 5
3. Best path selection for BGP hot potato routing from 3. Best path selection for BGP hot potato routing from
customized IGP network position . . . . . . . . . . . . . . . 7 customized IGP network position . . . . . . . . . . . . . . . 6
3.1. Client's perspective best path selection algorithm . . . . 8 3.1. Client's perspective best path selection algorithm . . . 7
3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . . 8 3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . 7
3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . . 9 3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . 8
3.2. Aside: Configuration-based flexible route reflector 3.2. Aside: Configuration-based flexible route reflector
placement . . . . . . . . . . . . . . . . . . . . . . . . 10 placement . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Route reflector client grouping . . . . . . . . . . . . . 10 3.3. Route reflector client grouping . . . . . . . . . . . . . 9
3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 11 3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 10
3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . 12
4. Angular distance approximation for BGP warm potato routing . 13 4. Angular distance approximation for BGP warm potato routing . 12
4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 14 4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 13
4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 15 4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 14
4.3. Centralized vs distributed route reflectors . . . . . . . 16 4.3. Centralized vs distributed route reflectors . . . . . . . 15
5. Client's perspective policy based best path selection . . . . 17 5. Client's perspective policy based best path selection . . . . 16
5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . . 19 5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . 19
6. Deployment considerations . . . . . . . . . . . . . . . . . . 20 6. Deployment considerations . . . . . . . . . . . . . . . . . . 19
7. Security considerations . . . . . . . . . . . . . . . . . . . 21 7. Security considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
There are three types of BGP deployments within Autonomous Systems There are three types of BGP deployments within Autonomous Systems
today: full mesh, confederations and route reflection. today: full mesh, confederations and route reflection.
BGP route reflection is the most popular way to distribute BGP routes BGP route reflection is the most popular way to distribute BGP routes
between BGP speakers belonging to the same administrative domain. between BGP speakers belonging to the same administrative domain.
Traditionally route reflectors have been deployed in the forwarding Traditionally route reflectors have been deployed in the forwarding
path and carefully placed on the POP to core boundaries. That model path and carefully placed on the POP to core boundaries. That model
of BGP route reflector placement has started to evolve. The of BGP route reflector placement has started to evolve. The
placement of route reflectors outside the forwarding path was placement of route reflectors outside the forwarding path was
triggered by applications which required traffic to be tunneled from triggered by applications which required traffic to be tunneled from
AS ingress PE to egress PE: for example L3VPN. AS ingress PE to egress PE: for example L3VPN.
This evolving model of intra-domain network design has enabled This evolving model of intra-domain network design has enabled
deployments of centralized route reflectors. Initially this model deployments of centralized route reflectors. Initially this model
was only employed for new address families e.g. L3VPNs, L2VPNs etc was only employed for new address families e.g. L3VPNs, L2VPNs etc
With edge to edge MPLS or IP encapsulation also being used to carry With edge to edge MPLS or IP encapsulation also being used to carry
internet traffic, this model has been gradually extended to other BGP internet traffic, this model has been gradually extended to other BGP
address families including IPv4 and IPv6 Internet routing. This is address families including IPv4 and IPv6 Internet routing. This is
also applicable to new services achieved with BGP as control plane also applicable to new services achieved with BGP as control plane
for example 6PE. for example 6PE.
Such centralized route reflectors can be placed on the POP to core Such centralized route reflectors can be placed on the POP to core
boundaries, but they are often placed in arbitrary locations in the boundaries, but they are often placed in arbitrary locations in the
core of large networks. core of large networks.
skipping to change at page 7, line 5 skipping to change at page 6, line 18
Besides these solutions to manage hot potato routing, there are Besides these solutions to manage hot potato routing, there are
deployment scenarios where service providers want to have more deployment scenarios where service providers want to have more
control of traffic exiting the AS by assigning per client preference control of traffic exiting the AS by assigning per client preference
to gateways. to gateways.
This document proposes to introduce a solution to perform a policy This document proposes to introduce a solution to perform a policy
based route-reflection to address those scenarios. This solution has based route-reflection to address those scenarios. This solution has
the same requirements (regarding path diversity) and advantages than the same requirements (regarding path diversity) and advantages than
the two IGP metric based solutions. the two IGP metric based solutions.
3. Best path selection for BGP hot potato routing from customized IGP 3. Best path selection for BGP hot potato routing from customized IGP
network position network position
This section describes a method for calculating the order of This section describes a method for calculating the order of
preference of BGP paths from the point of view of each separate route preference of BGP paths from the point of view of each separate route
reflector client. More specifically, the route reflector will reflector client. More specifically, the route reflector will
compute the IGP metric to the BGP nexthop from the position of the compute the IGP metric to the BGP nexthop from the position of the
client to which the resulting path will be distributed, if the IGP client to which the resulting path will be distributed, if the IGP
metric is the tie breaker applied to a set of possible paths. In the metric is the tie breaker applied to a set of possible paths. In the
subsequent model authors will propose virtual reflector placement at subsequent model authors will propose virtual reflector placement at
operator's selected IGP location. operator's selected IGP location.
skipping to change at page 9, line 18 skipping to change at page 8, line 31
Hierarchy introduces two challenges: Hierarchy introduces two challenges:
The first challenge is that the RR IGP view may differ from a 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 client IGP view by virtue of one or the other having a summarized
view versus the other. Summarization, by its nature, loses view versus the other. Summarization, by its nature, loses
information. Consider the example where a client within a PoP information. Consider the example where a client within a PoP
sees two prefixes with two metrics for two egress points within sees two prefixes with two metrics for two egress points within
the PoP, but where the RR only sees a single summary covering the PoP, but where the RR only sees a single summary covering
reachability to both nexthops as injected by the ABR. For reachability to both nexthops as injected by the ABR. For
clarification purposes in the case of ISIS by ABR we refer to clarification purposes in the case of ISIS by ABR we refer to L1/
L1/L2 node. However it needs to be observed that inter area L2 node. However it needs to be observed that inter area networks
networks running LDP are required to disable summarisation of all running LDP are required to disable summarisation of all FEC
FEC advertised in LDP (typically all loopbacks) unless [RFC5283] advertised in LDP (typically all loopbacks) unless [RFC5283] is
is deployed. Such deployments are not likely to suffer deployed. Such deployments are not likely to suffer summarization
summarization difficulties. difficulties.
The second challenge is that in cases where the client is in a 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 different level of hierarchy from the RR, the RR can not build a
Shortest Path First (SPF) tree with the client node as root, Shortest Path First (SPF) tree with the client node as root,
simply because the topology derived by the IGP will not include simply because the topology derived by the IGP will not include
the client node. It will instead only include reachability to the the client node. It will instead only include reachability to the
client from one or more ABRs. In order to overcome this problem, 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 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 RR would then determine the shortest distance from a client which
lives behind the ABRs, to a nexthop, by adding the advertised lives behind the ABRs, to a nexthop, by adding the advertised
skipping to change at page 13, line 44 skipping to change at page 12, line 50
retaining all available paths (potentially 10s) per each prefix at retaining all available paths (potentially 10s) per each prefix at
the edge. the edge.
The proposal allows for a fast and safe transition to BGP control The proposal allows for a fast and safe transition to BGP control
plane route reflection without compromising an operator's closest plane route reflection without compromising an operator's closest
exit operational principle. Hot potato routing is important to most exit operational principle. Hot potato routing is important to most
ISPs. The inability to perform hot potato routing effectively stops ISPs. The inability to perform hot potato routing effectively stops
migrations to centralized route reflection and edge-to-edge LSP/IP migrations to centralized route reflection and edge-to-edge LSP/IP
encapsulation for traffic to IPv4 and IPv6 prefixes. encapsulation for traffic to IPv4 and IPv6 prefixes.
4. Angular distance approximation for BGP warm potato routing 4. Angular distance approximation for BGP warm potato routing
This section describes an alternative solution to the use of IGP This section describes an alternative solution to the use of IGP
topology information to virtually position the RR at the client topology information to virtually position the RR at the client
location in the network. This solution involves modeling the network location in the network. This solution involves modeling the network
topology as a set of elements (regions, PoPs or routers) arranged in topology as a set of elements (regions, PoPs or routers) arranged in
a circle. Route reflector clients and inter-domain exit points would a circle. Route reflector clients and inter-domain exit points would
then be statically assigned to those elements such that one can then be statically assigned to those elements such that one can
compute the angular distance between route-reflector clients and the compute the angular distance between route-reflector clients and the
various exit points in order to infer the distance between any two various exit points in order to infer the distance between any two
elements. This measure of distance can be used as an effective elements. This measure of distance can be used as an effective
alternative to the IGP distance as a tie breaker in the path alternative to the IGP distance as a tie breaker in the path
skipping to change at page 14, line 37 skipping to change at page 13, line 42
CLIENT B CLIENT B
POP4 POP1 N1 POP4 POP1 N1
CORE CORE
RR(s) POP2 N2 RR(s) POP2 N2
N5 POP3 POP2 N3 N5 POP3 POP2 N3
CLIENT A CLIENT A
POP3 POP3
N - represents the different exit points for a given prefix. POP2 is N - represents the different exit points for a given prefix. POP2 is
a geographically large PoP with two paths; N2 and N3. a geographically large PoP with two paths; N2 and N3.
In a deployment where the centralized RRs tie break on the basis of In a deployment where the centralized RRs tie break on the basis of
their IGP-based view of the network, N1 above would be advertised to their IGP-based view of the network, N1 above would be advertised to
all clients on the basis that it is closest to the RR. Path N4 would all clients on the basis that it is closest to the RR. Path N4 would
be a more appropriate choice for client B. Similarly, N5 would be be a more appropriate choice for client B. Similarly, N5 would be
more appropriate for client A since path N5 is closer to client A more appropriate for client A since path N5 is closer to client A
then path N1. then path N1.
skipping to change at page 22, line 14 skipping to change at page 21, line 14
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, February 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Chen, E., Retana, A., 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-
draft-ietf-idr-add-paths-07 (work in progress), June 2012. add-paths-08 (work in progress), December 2012.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
[RFC1998] Chen, E. and T. Bates, "An Application of the BGP [RFC1998] Chen, E. and T. Bates, "An Application of the BGP
Community Attribute in Multi-home Routing", RFC 1998, Community Attribute in Multi-home Routing", RFC 1998,
August 1996. August 1996.
[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114,
RFC 4384, February 2006. RFC 4384, February 2006.
skipping to change at page 22, line 42 skipping to change at page 21, line 42
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668, October 2009. Specific BGP Extended Community", RFC 5668, October 2009.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
RFC 5714, January 2010. 5714, January 2010.
[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. [RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,
November 2012. November 2012.
Authors' Addresses Authors' Addresses
Robert Raszuk Robert Raszuk
NTT MCL NTT I3
101 S Ellsworth Avenue Suite 350 101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401 San Mateo, CA 94401
US US
Email: robert@raszuk.net Email: robert@raszuk.net
Christian Cassar Christian Cassar
Cisco Systems Cisco Systems
10 New Square Park 10 New Square Park
Bedfont Lakes, FELTHAM TW14 8HA Bedfont Lakes, FELTHAM TW14 8HA
UK UK
Email: ccassar@cisco.com Email: ccassar@cisco.com
Erik Aman Erik Aman
TeliaSonera TeliaSonera
Marbackagatan 11 Marbackagatan 11
Farsta, SE-123 86 Farsta SE-123 86
Sweden Sweden
Email: erik.aman@teliasonera.com Email: erik.aman@teliasonera.com
Bruno Decraene Bruno Decraene
France Telecom Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux cedex 9, 92794 Issy les Moulineaux cedex 9 92794
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
9 rue du chene germain 9 rue du chene germain
Cesson Sevigne, 35512 Cesson Sevigne 35512
France France
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
 End of changes. 24 change blocks. 
57 lines changed or deleted 54 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/