draft-ietf-idr-route-oscillation-stop-03.txt   draft-ietf-idr-route-oscillation-stop-04.txt 
Network Working Group D. Walton Network Working Group D. Walton
Internet-Draft Cumulus Networks Internet-Draft Cumulus Networks
Intended status: Standards Track A. Retana Intended status: Standards Track A. Retana
Expires: November 1, 2016 E. Chen Expires: February 9, 2017 E. Chen
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
April 30, 2016 August 8, 2016
BGP Persistent Route Oscillation Solutions BGP Persistent Route Oscillation Solutions
draft-ietf-idr-route-oscillation-stop-03 draft-ietf-idr-route-oscillation-stop-04
Abstract Abstract
This document presents two sets of paths for an address prefix that The routing information reduction by BGP Route Reflection or
can be advertised by a BGP route reflector or confederation ASBR to Confederation can result in persistent internal BGP route
eliminate the MED-induced route oscillations in a network. The first oscillations with certain routing setup and network topologies. This
set involves all the available paths, and would achieve the same document specifies two sets of additional paths that can be used to
routing consistency as the full IBGP mesh. The second set, which is eliminate these route oscillations in a network.
a subset of the first one, involves the neighbor-AS based Group Best
Paths, and would be sufficient to eliminate the MED-induced route
oscillations.
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 November 1, 2016. This Internet-Draft will expire on February 9, 2017.
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 37 skipping to change at page 2, line 34
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7 Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
As documented in [RFC3345], the routing information reduction by BGP As documented in [RFC3345], the 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 IBGP route oscillations with certain routing setup and
network topologies. Except for a couple artificially engineered network topologies. Except for a couple artificially engineered
network topologies, the MED attribute [RFC4271] has played a pivotal network topologies, the MULTI_EXIT_DISC attribute (MED) [RFC4271] has
role in virtually all of the known persistent IBGP route played a pivotal role in virtually all of the known persistent IBGP
oscillations. For the sake of brevity, we use the term "MED-induced route oscillations. For the sake of brevity, we use the term "MED-
route oscillation" hereafter to refer to a persistent IBGP route induced route oscillation" hereafter to refer to a persistent IBGP
oscillation in which the MED plays a role. route oscillation in which the MED plays a role.
In order to eliminate the MED-induced route oscillations and to In order to eliminate the MED-induced route oscillations and to
achieve consistent routing in a network, a route reflector or a achieve consistent routing in a network, a route reflector or a
confederation ASBR needs to advertise more than just the best path confederation ASBR needs to advertise more than just the best path
for an address prefix. Our goal is to identify the necessary set of for an address prefix. Our goal is to identify the necessary set of
paths for an address prefix that needs to be advertised by a route paths for an address prefix that needs to be advertised by a route
reflector or a confederation ASBR to prevent the condition. 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 the MED-induced route oscillations in a network. The
first set involves all the available paths, and would achieve the first set involves all the available paths, and would achieve the
same routing consistency as the full IBGP mesh. The second set, same routing consistency as the full IBGP mesh. The second set,
which is a subset of the first one, involves the neighbor-AS based which is a subset of the first one, involves the neighbor-AS based
Group Best Paths, and would be sufficient to eliminate the MED- Group Best Paths, and would be sufficient to eliminate the MED-
induced route oscillations (subject to certain commonly adopted induced route oscillations (subject to certain commonly adopted
topological constraints). topological constraints).
These paths can be advertised using the mechanism described in ADD- These paths can be advertised using the mechanism described in ADD-
PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. No PATH [RFC7911] for advertising multiple paths. No other assumptions
other assumptions in functionality beyond the base BGP specification in functionality beyond the base BGP specification [RFC4271] are
[RFC4271] are made. 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 BGP
skipping to change at page 3, line 37 skipping to change at page 3, line 34
network is thus free of the MED-induced route oscillations and other network is thus free of the MED-induced route oscillations and other
routing inconsistencies such as forwarding loops. 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.
This approach can be implemented using the mechanism described in This approach can be implemented using the mechanism described in
ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths for ADD-PATH [RFC7911] for advertising multiple paths for certain
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 which 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 condition is outside the scope of this document.
4. Advertise the Group Best Paths 4. Advertise the Group Best Paths
skipping to change at page 4, line 15 skipping to change at page 4, line 11
[RFC5065]. By definition the MED is comparable only among routes [RFC5065]. By definition the MED is comparable only among routes
with the same neighbor-AS. Thus the route selection procedures with the same neighbor-AS. Thus the route selection procedures
specified in [RFC4271] would conceptually involve two steps: first specified in [RFC4271] would conceptually involve two steps: first
organize the paths for an address prefix into groups according to organize the paths for an address prefix into groups according to
their respective neighbor-AS's, and calculate the most preferred one their respective neighbor-AS's, and calculate the most preferred one
(termed "Group Best Path") for each of the groups; Then calculate the (termed "Group Best Path") for each of the groups; Then calculate the
overall best path among all the Group Best Paths. overall best path among all the Group Best Paths.
As a generally recommended ([RFC4456], [RFC5065]) and widely adopted As a generally recommended ([RFC4456], [RFC5065]) and widely adopted
practice, a route reflection cluster or a confederation sub-AS should practice, a route reflection cluster or a confederation sub-AS should
be designed such that the IGP metrics for links within a cluster (or be designed such that BGP routes from within the cluster (or
confederation sub-AS) are much smaller than the IGP metrics for the confederation sub-AS) are preferred over routes from other clusters
links between the clusters (or confederation sub-AS). This practice (or confederation sub-AS) when the decision is based on the IGP cost
helps achieve consistent routing within a route reflection cluster or to the BGP NEXT_HOP. This is typically done by setting IGP metrics
a confederation sub-AS. for links within a cluster (or confederation sub-AS) to be much
smaller than the IGP metrics for the links between the clusters (or
confederation sub-AS). This practice 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 the MED-
induced route oscillations in the network. This claim is validated induced route oscillations in the network. This claim is validated
in Appendix A. 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 [I-D.ietf-idr-add-paths] for advertising multiple paths, and ADD-PATH [RFC7911] for advertising multiple paths, and in this case
in this case the neighbor-AS of a path may be used as the path the neighbor-AS of a path may be used as the path identifier of the
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 the 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 [I-D.ietf-idr-add-paths], the following described in ADD-PATH [RFC7911], the following revisions are proposed
revisions are proposed for BGP route reflection and BGP for BGP route reflection and BGP Confederation.
Confederation.
5.1. Route Reflection 5.1. Route Reflection
Depending on the configuration, for a particular <AFI, SAFI> a route For a particular <AFI, SAFI> a route reflector MUST include the <AFI,
reflector SHOULD include the <AFI, SAFI> with the "Send/Receive" SAFI> with the "Send/Receive" field set to 2 (send multiple paths) or
field set to 2 (send multiple paths) or 3 (send/receive multiple 3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911]
paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] advertised advertised to an IBGP peer. When the ADD-PATH Capability is also
to an IBGP peer. When the ADD-PATH Capability is also received from received from the IBGP peer with the "Send/Receive" field set to 1
the IBGP peer with the "Send/Receive" field set to 1 (receive (receive multiple paths) or 3 (send/receive multiple paths) for the
multiple paths) or 3 (send/receive multiple paths) for the same <AFI, same <AFI, SAFI>, then the following procedures apply:
SAFI>, then the following procedures shall be followed:
If the peer is a route reflection client, the route reflector SHOULD 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. Depending on the received from its non-client IBGP peers. The route reflector MAY
configuration, the route reflector MAY also advertise to the peer the also advertise to the peer the Group Best Paths (or the Available
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 SHOULD 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
Depending on the configuration, for a particular <AFI, SAFI> a For a particular <AFI, SAFI> a confederation ASBR MUST include the
confederation ASBR SHOULD include the <AFI, SAFI> with the "Send/ <AFI, SAFI> with the "Send/Receive" field set to 2 (send multiple
Receive" field set to 2 (send multiple paths) or 3 (send/receive paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability
multiple paths) in the ADD-PATH Capability [I-D.ietf-idr-add-paths] [RFC7911] advertised to an IBGP peer, and to a confederation external
advertised to an IBGP peer, and to a confederation external peer. peer. When the ADD-PATH Capability is also received from the IBGP
When the ADD-PATH Capability is also received from the IBGP peer or peer or the confederation external peer with the "Send/Receive" field
the confederation external peer with the "Send/Receive" field set to set to 1 (receive multiple paths) or 3 (send/receive multiple paths)
1 (receive multiple paths) or 3 (send/receive multiple paths) for the for the same <AFI, SAFI>, then the following procedures apply:
same <AFI, SAFI>, then the following procedures shall be followed:
If the peer is internal, the confederation ASBR SHOULD advertise to If the peer is internal, the confederation ASBR MUST advertise to the
the peer the Group Best Paths (or the Available Paths) received from peer the Group Best Paths (or the Available Paths) received from its
its confederation external peers. confederation external peers.
If the peer is confederation external, the confederation ASBR SHOULD 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
skipping to change at page 7, line 5 skipping to change at page 6, line 48
8. Security Considerations 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 9. Acknowledgements
We would like to thank David Cook and Naiming Shen for their We would like to thank David Cook and Naiming Shen for their
contributions to the design and development of the solutions. contributions to the design and development of the solutions.
Many thanks to Tony Przygienda, Sue Hares and Jon Mitchel for their Many thanks to Tony Przygienda, Sue Hares, Jon Mitchell and Paul
helpful suggestions. Kyzivat for their helpful suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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-13 (work in progress), December 2015.
[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>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>. <http://www.rfc-editor.org/info/rfc4456>.
[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,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>.
10.2. Informative References 10.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
 End of changes. 21 change blocks. 
66 lines changed or deleted 63 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/