draft-ietf-idr-route-oscillation-stop-02.txt   draft-ietf-idr-route-oscillation-stop-03.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: October 13, 2016 E. Chen Expires: November 1, 2016 E. Chen
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
April 11, 2016 April 30, 2016
BGP Persistent Route Oscillation Solutions BGP Persistent Route Oscillation Solutions
draft-ietf-idr-route-oscillation-stop-02 draft-ietf-idr-route-oscillation-stop-03
Abstract Abstract
This document presents two sets of paths for an address prefix that This document presents two sets of paths for an address prefix that
can be advertised by a BGP route reflector or confederation ASBR to can be advertised by a BGP route reflector or confederation ASBR to
eliminate the MED-induced route oscillations in a network. The first eliminate the MED-induced route oscillations in a network. The first
set involves all the available paths, and would achieve the same set involves all the available paths, and would achieve the same
routing consistency as the full IBGP mesh. The second set, which is routing consistency as the full IBGP mesh. The second set, which is
a subset of the first one, involves the neighbor-AS based Group Best a subset of the first one, involves the neighbor-AS based Group Best
Paths, and would be sufficient to eliminate the MED-induced route Paths, and would be sufficient to eliminate the MED-induced route
oscillations (subject to certain commonly adopted topological oscillations.
constrains).
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 October 13, 2016. This Internet-Draft will expire on November 1, 2016.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Advertise the Available Paths . . . . . . . . . . . . . . . . 3 3. Advertise All the Available Paths . . . . . . . . . . . . . . 3
4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 4 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3
5. Route Reflection and Confederation . . . . . . . . . . . . . 4 5. Route Reflection and Confederation . . . . . . . . . . . . . 4
5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 4
5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
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 MED attribute [RFC4271] has played a pivotal
role in virtually all of the known persistent IBGP route role in virtually all of the known persistent IBGP route
oscillations. For the sake of brevity, we use the term "MED-induced oscillations. For the sake of brevity, we use the term "MED-induced
route oscillation" hereafter to refer to a persistent IBGP route route oscillation" hereafter to refer to a persistent IBGP route
oscillation in which the MED plays a role. 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, clearly a route reflector or achieve consistent routing in a network, a route reflector or a
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 "right" 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. reflector or a confederation ASBR to prevent the condition.
In this document we present 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 constrains). 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 [I-D.ietf-idr-add-paths] for advertising multiple paths. No
other assumptions in functionality beyond the base BGP specification other assumptions in functionality beyond the base BGP specification
[RFC4271] is assumed. [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 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
speakers have consistent and equivalent routing information. Such a speakers have consistent and equivalent routing information. Such a
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
skipping to change at page 4, line 41 skipping to change at page 4, line 36
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 [I-D.ietf-idr-add-paths] for advertising multiple paths, and
in this case the neighbor-AS of a path may be used as the path in this case the neighbor-AS of a path may be used as the path
identifier of the path. identifier of the 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 constrains 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 [I-D.ietf-idr-add-paths], the following
revisions are proposed for BGP route reflection and BGP revisions are proposed for BGP route reflection and BGP
Confederation. Confederation.
skipping to change at page 6, line 35 skipping to change at page 6, line 32
number of the neighbor-AS's for a particular address prefix. The number of the neighbor-AS's 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 based rather than per path based. The number of the neighbor-AS's
for a particular address prefix is typically small because of the for a particular address prefix is typically small because of the
limited number of upstream providers for a customer and the nature of limited number of upstream providers for a customer and the nature of
advertising only customer routes at the inter-exchange points. advertising only 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
constrains 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 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. Note that the number of paths that need to be maintained and paths.
advertised can be greatly reduced by accepting MEDs from other
peering networks.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
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
helpful suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-13 (work in progress), December 2015. 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
 End of changes. 18 change blocks. 
23 lines changed or deleted 23 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/