draft-ietf-idr-route-oscillation-stop-04.txt   rfc7964.txt 
Network Working Group D. Walton Internet Engineering Task Force (IETF) D. Walton
Internet-Draft Cumulus Networks Request for Comments: 7964 Cumulus Networks
Intended status: Standards Track A. Retana Category: Standards Track A. Retana
Expires: February 9, 2017 E. Chen ISSN: 2070-1721 E. Chen
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
August 8, 2016 September 2016
BGP Persistent Route Oscillation Solutions Solutions for BGP Persistent Route Oscillation
draft-ietf-idr-route-oscillation-stop-04
Abstract Abstract
The routing information reduction by BGP Route Reflection or Routing information reduction by BGP Route Reflection or
Confederation can result in persistent internal BGP route Confederation can result in persistent internal BGP route
oscillations with certain routing setup and network topologies. This oscillations with certain routing setups and network topologies.
document specifies two sets of additional paths that can be used to This document specifies two sets of additional paths that can be used
eliminate these route oscillations in a network. to eliminate these route oscillations in a network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 9, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7964.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 16 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Advertise All the Available Paths . . . . . . . . . . . . . . 3 3. Advertise All the Available Paths . . . . . . . . . . . . . . 3
4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3
5. Route Reflection and Confederation . . . . . . . . . . . . . 4 5. Route Reflection and Confederation . . . . . . . . . . . . . 4
5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 4 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5
5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Why the Group Best Paths Are Adequate . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
As documented in [RFC3345], the routing information reduction by BGP As documented in [RFC3345], routing information reduction by BGP
Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result
in persistent IBGP route oscillations with certain routing setup and in persistent Internal BGP (IBGP) route oscillations with certain
network topologies. Except for a couple artificially engineered routing setups and network topologies. Except for a couple of
network topologies, the MULTI_EXIT_DISC attribute (MED) [RFC4271] has artificially engineered network topologies, the MULTI_EXIT_DISC (MED)
played a pivotal role in virtually all of the known persistent IBGP attribute [RFC4271] has played a pivotal role in virtually all known
route oscillations. For the sake of brevity, we use the term "MED- persistent IBGP route oscillations. For the sake of brevity, we use
induced route oscillation" hereafter to refer to a persistent IBGP the term "MED-induced route oscillation" hereafter to refer to a
route oscillation in which the MED plays a role. persistent IBGP route oscillation in which the MED plays a role.
In order to eliminate the MED-induced route oscillations and to In order to eliminate MED-induced route oscillations and to achieve
achieve consistent routing in a network, a route reflector or a consistent routing in a network, a route reflector or a confederation
confederation ASBR needs to advertise more than just the best path Autonomous System Border Router (ASBR) needs to advertise more than
for an address prefix. Our goal is to identify the necessary set of just the best path for an address prefix. Our goal is to identify
paths for an address prefix that needs to be advertised by a route the necessary set of paths for an address prefix that needs to be
reflector or a confederation ASBR to prevent the condition. advertised by a route reflector or a confederation ASBR to prevent
the condition.
In this document we describe two sets of paths for an address prefix In this document, we describe two sets of paths for an address prefix
that can be advertised by a BGP route reflector or confederation ASBR that can be advertised by a BGP route reflector or confederation ASBR
to eliminate the MED-induced route oscillations in a network. The to eliminate MED-induced route oscillations in a network. The first
first set involves all the available paths, and would achieve the set involves all the available paths, and would achieve the same
same routing consistency as the full IBGP mesh. The second set, routing consistency as the full IBGP mesh. The second set, which is
which is a subset of the first one, involves the neighbor-AS based a subset of the first one, involves the neighbor-AS-based Group Best
Group Best Paths, and would be sufficient to eliminate the MED- Paths, and would be sufficient to eliminate MED-induced route
induced route oscillations (subject to certain commonly adopted oscillations (subject to certain commonly adopted topological
topological constraints). constraints).
These paths can be advertised using the mechanism described in ADD- These paths can be advertised using the mechanism described in
PATH [RFC7911] for advertising multiple paths. No other assumptions ADD-PATH [RFC7911] for advertising multiple paths. No other
in functionality beyond the base BGP specification [RFC4271] are assumptions in functionality beyond the base BGP specification
made. [RFC4271] are made.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Advertise All the Available Paths 3. Advertise All the Available Paths
Observe that in a network that maintains a full IBGP mesh all the BGP Observe that in a network that maintains a full IBGP mesh, all the
speakers have consistent and equivalent routing information. Such a BGP speakers have consistent and equivalent routing information.
network is thus free of the MED-induced route oscillations and other Such a network is thus free of MED-induced route oscillations and
routing inconsistencies such as forwarding loops. other routing inconsistencies such as forwarding loops.
Therefore one approach is to allow a route reflector or a Therefore, one approach is to allow a route reflector or a
confederation ASBR to advertise all the available paths for an confederation ASBR to advertise all the available paths for an
address prefix. Clearly this approach would yield the same amount of address prefix. Clearly this approach would yield the same amount of
routing information and achieve the same routing consistency as the routing information and achieve the same routing consistency as the
full IBGP mesh in a network. full IBGP mesh in a network. In this document, "Available Paths"
refers to the advertisement of all the available paths.
This approach can be implemented using the mechanism described in This approach can be implemented using the mechanism described in
ADD-PATH [RFC7911] for advertising multiple paths for certain ADD-PATH [RFC7911] for advertising multiple paths for certain
prefixes. prefixes.
For the sake of scalability the advertisement of multiple paths For the sake of scalability, the advertisement of multiple paths
should be limited to those prefixes which are affected by MED-induced should be limited to those prefixes that are affected by MED-induced
route oscillation in a network carrying a large number of alternate route oscillation in a network carrying a large number of alternate
paths. A detailed description of how these oscillations can occur paths. A detailed description of how these oscillations can occur
can be found in [RFC3345]; the description of how a node would can be found in [RFC3345]; the description of how a node would
locally detect such condition is outside the scope of this document. locally detect such conditions is outside the scope of this document.
4. Advertise the Group Best Paths 4. Advertise the Group Best Paths
The term neighbor-AS for a route refers to the neighboring AS from The term "neighbor-AS" for a route refers to the neighboring
which the route was received. The calculation of the neighbor-AS is autonomous system (AS) from which the route was received. The
specified in Section 9.1.2.2 of [RFC4271], and Section 7.2 of calculation of the neighbor-AS is specified in Section 9.1.2.2 of
[RFC5065]. By definition the MED is comparable only among routes [RFC4271], and Section 5.3 of [RFC5065]. By definition, the MED is
with the same neighbor-AS. Thus the route selection procedures comparable only among routes with the same neighbor-AS. Thus, the
specified in [RFC4271] would conceptually involve two steps: first route selection procedures specified in [RFC4271] would conceptually
organize the paths for an address prefix into groups according to involve two steps: first, organize the paths for an address prefix
their respective neighbor-AS's, and calculate the most preferred one into groups according to their respective neighbor-ASes, and
(termed "Group Best Path") for each of the groups; Then calculate the calculate the most preferred one (termed "Group Best Path") for each
overall best path among all the Group Best Paths. of the groups; then, calculate the overall best path among all the
Group Best Paths.
As a generally recommended ([RFC4456], [RFC5065]) and widely adopted As a practice that is generally recommended (in [RFC4456] and
practice, a route reflection cluster or a confederation sub-AS should [RFC5065]) and widely adopted, a route reflection cluster or a
be designed such that BGP routes from within the cluster (or confederation sub-AS should be designed such that BGP routes from
confederation sub-AS) are preferred over routes from other clusters within the cluster (or confederation sub-AS) are preferred over
(or confederation sub-AS) when the decision is based on the IGP cost routes from other clusters (or confederation sub-AS) when the
to the BGP NEXT_HOP. This is typically done by setting IGP metrics decision is based on the IGP cost to the BGP NEXT_HOP. This is
for links within a cluster (or confederation sub-AS) to be much typically done by setting IGP metrics for links within a cluster (or
smaller than the IGP metrics for the links between the clusters (or confederation sub-AS) to be much smaller than the IGP metrics for the
confederation sub-AS). This practice helps achieve consistent links between the clusters (or confederation sub-AS). This practice
routing within a route reflection cluster or a confederation sub-AS. helps achieve consistent routing within a route reflection cluster or
a confederation sub-AS.
When the aforementioned practice for devising a route reflection When the aforementioned practice for devising a route reflection
cluster or confederation sub-AS is followed in a network, we claim cluster or confederation sub-AS is followed in a network, we claim
that the advertisement of all the Group Best Paths by a route that the advertisement of all the Group Best Paths by a route
reflector or a confederation ASBR is sufficient to eliminate the MED- reflector or a confederation ASBR is sufficient to eliminate
induced route oscillations in the network. This claim is validated MED-induced route oscillations in the network. This claim is
in Appendix A. validated in Appendix A.
Note that a Group Best Path for an address prefix can be identified Note that a Group Best Path for an address prefix can be identified
by the combination of the address prefix and the neighbor-AS. Thus by the combination of the address prefix and the neighbor-AS. Thus,
this approach can be implemented using the mechanism described in this approach can be implemented using the mechanism described in
ADD-PATH [RFC7911] for advertising multiple paths, and in this case ADD-PATH [RFC7911] for advertising multiple paths, and in this case,
the neighbor-AS of a path may be used as the path identifier of the the neighbor-AS of a path may be used as the path identifier of the
path. path.
It should be noted that the approach of advertising the Group Best It should be noted that the approach of advertising the Group Best
Paths requires certain topological constraints to be satisfied in Paths requires certain topological constraints to be satisfied in
order to eliminate the MED-induced route oscillation. Specific order to eliminate MED-induced route oscillation. Specific
topological considerations are described in [RFC3345]. topological considerations are described in [RFC3345].
5. Route Reflection and Confederation 5. Route Reflection and Confederation
To allow a route reflector or a confederation ASBR to advertise To allow a route reflector or a confederation ASBR to advertise
either the Available Paths or Group Best Paths using the mechanism either the Available Paths or Group Best Paths using the mechanism
described in ADD-PATH [RFC7911], the following revisions are proposed described in ADD-PATH [RFC7911], the following revisions are proposed
for BGP route reflection and BGP Confederation. for BGP Route Reflection and BGP Confederation.
5.1. Route Reflection 5.1. Route Reflection
For a particular <AFI, SAFI> a route reflector MUST include the <AFI, For a particular <Address Family Identifier (AFI), Subsequent Address
SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or Family (SAFI)>, a route reflector MUST include the <AFI, SAFI> with
the "Send/Receive" field set to 2 (send multiple paths) or
3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911] 3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911]
advertised to an IBGP peer. When the ADD-PATH Capability is also advertised to an IBGP peer. When the ADD-PATH Capability is also
received from the IBGP peer with the "Send/Receive" field set to 1 received from the IBGP peer with the "Send/Receive" field set to 1
(receive multiple paths) or 3 (send/receive multiple paths) for the (receive multiple paths) or 3 (send/receive multiple paths) for the
same <AFI, SAFI>, then the following procedures apply: same <AFI, SAFI>, then the following procedures apply:
If the peer is a route reflection client, the route reflector MUST If the peer is a route reflection client, the route reflector MUST
advertise to the peer the Group Best Paths (or the Available Paths) advertise to the peer the Group Best Paths (or the Available Paths)
received from its non-client IBGP peers. The route reflector MAY received from its non-client IBGP peers. The route reflector MAY
also advertise to the peer the Group Best Paths (or the Available also advertise to the peer the Group Best Paths (or the Available
Paths) received from its clients. Paths) received from its clients.
If the peer is a non-client, the route reflector MUST advertise to If the peer is a non-client, the route reflector MUST advertise to
the peer the Group Best Paths (or the Available Paths) received from the peer the Group Best Paths (or the Available Paths) received from
its clients. its clients.
5.2. Confederation 5.2. Confederation
For a particular <AFI, SAFI> a confederation ASBR MUST include the For a particular <AFI, SAFI>, a confederation ASBR MUST include the
<AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple <AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple
paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability
[RFC7911] advertised to an IBGP peer, and to a confederation external [RFC7911] advertised to an IBGP peer, and to a confederation external
peer. When the ADD-PATH Capability is also received from the IBGP peer. When the ADD-PATH Capability is also received from the IBGP
peer or the confederation external peer with the "Send/Receive" field peer or the confederation-external peer with the "Send/Receive" field
set to 1 (receive multiple paths) or 3 (send/receive multiple paths) set to 1 (receive multiple paths) or 3 (send/receive multiple paths)
for the same <AFI, SAFI>, then the following procedures apply: for the same <AFI, SAFI>, then the following procedures apply:
If the peer is internal, the confederation ASBR MUST advertise to the If the peer is internal, the confederation ASBR MUST advertise to the
peer the Group Best Paths (or the Available Paths) received from its peer the Group Best Paths (or the Available Paths) received from its
confederation external peers. confederation-external peers.
If the peer is confederation external, the confederation ASBR MUST If the peer is confederation-external, the confederation ASBR MUST
advertise to the peer the Group Best Paths (or the Available Paths) advertise to the peer the Group Best Paths (or the Available Paths)
received from its IBGP peers. received from its IBGP peers.
6. Deployment Considerations 6. Deployment Considerations
Some route oscillations, once detected, can be eliminated by simple Some route oscillations, once detected, can be eliminated by simple
configuration workarounds. As carrying additional paths impacts the configuration workarounds. As carrying additional paths impacts the
memory usage and routing convergence in a network, it is recommended memory usage and routing convergence in a network, it is recommended
that the impact be evaluated and the approach of using a that the impact be evaluated and the approach of using a
configuration workaround be considered in deciding whether to deploy configuration workaround be considered in deciding whether to deploy
the proposed mechanism in a network. In addition, the advertisement the proposed mechanism in a network. In addition, the advertisement
of multiple paths should be limited to those prefixes which are of multiple paths should be limited to those prefixes that are
affected by MED-induced route oscillation. affected by MED-induced route oscillation.
While the route reflectors or confederation ASBRs in a network need While the route reflectors or confederation ASBRs in a network need
to advertise the Group Best Paths or Available Paths, the vast to advertise the Group Best Paths or Available Paths, the vast
majority of the BGP speakers in the network only need to receive the majority of the BGP speakers in the network only need to receive the
Group Best Paths or Available Paths, which would involve only minor Group Best Paths or Available Paths, which would involve only minor
software changes. software changes.
It should be emphasized that in order to eliminate the MED-induced It should be emphasized that, in order to eliminate MED-induced route
route oscillations in a network using the approach of advertising the oscillations in a network using the approach of advertising the Group
Group Best Paths, the recommended practice for devising a route Best Paths, the recommended practice for devising a route reflection
reflection cluster or confederation sub-AS with respect to the IGP cluster or confederation sub-AS with respect to the IGP metrics
metrics ([RFC4456], [RFC5065]) should be followed. ([RFC4456] [RFC5065]) should be followed.
It is expected that the approach of advertising the Group Best Paths It is expected that the approach of advertising the Group Best Paths
would be adequate to achieve consistent routing for the vast majority would be adequate to achieve consistent routing for the vast majority
of the networks. For a network that has large number of alternate of the networks. For a network that has a large number of alternate
paths, the approach should be a good choice as the number of paths paths, the approach should be a good choice as the number of paths
advertised by a reflector or a confederation ASBR is bounded by the advertised by a reflector or a confederation ASBR is bounded by the
number of the neighbor-AS's for a particular address prefix. The number of the neighbor-ASes for a particular address prefix. The
additional states for an address prefix would also be per neighbor-AS additional states for an address prefix would also be per neighbor-AS
based rather than per path based. The number of the neighbor-AS's rather than per path. The number of neighbor-ASes for a particular
for a particular address prefix is typically small because of the address prefix is typically small because of the limited number of
limited number of upstream providers for a customer and the nature of upstream providers for a customer and the nature of advertising only
advertising only customer routes at the inter-exchange points. customer routes at the inter-exchange points.
The approach of advertising the Group Best Paths, however, may still The approach of advertising the Group Best Paths, however, may still
be inadequate for certain networks to avoid other routing be inadequate for certain networks to avoid other routing
inconsistencies such as forwarding loops. The required topological inconsistencies such as forwarding loops. The required topological
constraints could also be operationally challenging. In these cases constraints could also be operationally challenging. In these cases
the approach of advertising the Available Paths may be used, but the approach of advertising the Available Paths may be used, but
should be limited to those prefixes which are affected by MED-induced should be limited to those prefixes that are affected by MED-induced
route oscillation in a network carrying a large number of alternate route oscillation in a network carrying a large number of alternate
paths. paths.
7. IANA Considerations 7. Security Considerations
This memo includes no request to IANA.
8. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing BGP [RFC4271]. inherent in the existing BGP [RFC4271].
9. Acknowledgements 8. References
We would like to thank David Cook and Naiming Shen for their
contributions to the design and development of the solutions.
Many thanks to Tony Przygienda, Sue Hares, Jon Mitchell and Paul
Kyzivat for their helpful suggestions.
10. References
10.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <http://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007, DOI 10.17487/RFC5065, August 2007,
<http://www.rfc-editor.org/info/rfc5065>. <http://www.rfc-editor.org/info/rfc5065>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>. <http://www.rfc-editor.org/info/rfc7911>.
10.2. Informative References 8.2. Informative References
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana,
"Border Gateway Protocol (BGP) Persistent Route "Border Gateway Protocol (BGP) Persistent Route
Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345,
August 2002, <http://www.rfc-editor.org/info/rfc3345>. August 2002, <http://www.rfc-editor.org/info/rfc3345>.
Appendix A. Why the Group Best Paths Are Adequate? Appendix A. Why the Group Best Paths Are Adequate
It is assumed that the following common practice is followed. A It is assumed that the following common practice is followed. A
route reflection cluster or a confederation sub-AS should be designed route reflection cluster or a confederation sub-AS should be designed
such that the IGP metrics for links within a cluster (or such that the IGP metrics for links within a cluster (or
confederation sub-AS) are much smaller than the IGP metrics for the confederation sub-AS) are much smaller than the IGP metrics for the
links between the clusters (or confederation sub-AS). This practice links between the clusters (or confederation sub-AS). This practice
helps achieve consistent routing within a route reflection cluster or helps achieve consistent routing within a route reflection cluster or
a confederation sub-AS. a confederation sub-AS.
Observe that in a network that maintains full IBGP mesh only the Observe that in a network that maintains full IBGP mesh only, the
paths that survive the (Local_Pref, AS-PATH Length, Origin, MED) paths that survive the (Local_Pref, AS-PATH Length, Origin, and MED)
comparisons [RFC4271] would contribute to the route selection in the comparisons [RFC4271] would contribute to route selection in the
network. network.
Consider a route reflection cluster that sources one or more paths Consider a route reflection cluster that sources one or more paths
that would survive the (Local_Pref, AS-PATH Length, Origin, MED) that would survive the (Local_Pref, AS-PATH Length, Origin, and MED)
comparisons among all the paths in the network. One of these comparisons among all the paths in the network. One of these
surviving paths would be selected as the Group Best Path by the route surviving paths would be selected as the Group Best Path by the route
reflector in the cluster. Due to the constrain on the IGP metrics as reflector in the cluster. Due to the constraint on the IGP metrics
described previously, this path would remain as the Group Best Path as described previously, this path would remain as the Group Best
and would be advertised to all other clusters even after a path is Path and would be advertised to all other clusters even after a path
received from another cluster. is received from another cluster.
On the other hand, when no path in a route reflection cluster would On the other hand, when no path in a route reflection cluster would
survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons survive the (Local_Pref, AS-PATH Length, Origin, and MED) comparisons
among all the paths in the network, the Group Best Path (when exists) among all the paths in the network, the Group Best Path (when it
for a route reflector would be from another cluster. Clearly the exists) for a route reflector would be from another cluster.
advertise of the Group Best Path by the route reflector to the Clearly, the advertisement of the Group Best Path by the route
clients only depends on the paths received from other clusters. reflector to the clients only depends on the paths received from
other clusters.
Therefore there is no MED-induced route oscillation in the network as Therefore, there is no MED-induced route oscillation in the network
the advertisement of a Group Best Path to a peer does not depend on as the advertisement of a Group Best Path to a peer does not depend
the paths received from that peer. on the paths received from that peer.
The claim for the confederation can be validated similarly. The claim for the confederation can be validated similarly.
Acknowledgements
We would like to thank David Cook and Naiming Shen for their
contributions to the design and development of the solutions.
Many thanks to Tony Przygienda, Sue Hares, Jon Mitchell, and Paul
Kyzivat for their helpful suggestions.
Authors' Addresses Authors' Addresses
Daniel Walton Daniel Walton
Cumulus Networks Cumulus Networks
140C S. Whisman Rd. 140C S. Whisman Rd.
Mountain View, CA 94041 Mountain View, CA 94041
USA United States of America
Email: dwalton@cumulusnetworks.com Email: dwalton@cumulusnetworks.com
Alvaro Retana Alvaro Retana
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA United States of America
Email: aretana@cisco.com Email: aretana@cisco.com
Enke Chen Enke Chen
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: enkechen@cisco.com Email: enkechen@cisco.com
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA United States of America
Email: jgs@juniper.net Email: jgs@juniper.net
 End of changes. 55 change blocks. 
151 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/