draft-ietf-idr-route-oscillation-stop-00.txt   draft-ietf-idr-route-oscillation-stop-01.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: August 6, 2015 E. Chen Expires: April 9, 2016 E. Chen
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
February 2, 2015 October 7, 2015
BGP Persistent Route Oscillation Solutions BGP Persistent Route Oscillation Solutions
draft-ietf-idr-route-oscillation-stop-00 draft-ietf-idr-route-oscillation-stop-01
Abstract Abstract
In this document we present two sets of paths for an address prefix In this document we present 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-
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 August 6, 2015. This Internet-Draft will expire on April 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 20 skipping to change at page 2, line 20
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 the Available Paths . . . . . . . . . . . . . . . . 3
4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 4
5. Route Reflection and Confederation . . . . . . . . . . . . . 4 5. Route Reflection and Confederation . . . . . . . . . . . . . 4
5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . 7
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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 constrains).
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. PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. No
other assumptions in functionality beyond the base BGP specification
[RFC4271] is assumed.
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 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 44 skipping to change at page 3, line 46
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 [I-D.ietf-idr-add-paths] for advertising multiple paths for
certain prefixes. certain 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. paths. A detailed description of how these oscillations can occur
can be found in [RFC3345]; the description of how a node would
locally detect such condition 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 AS from
which the route was received. The calculation of the neighbor-AS is which the route was received. The calculation of the neighbor-AS is
specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of
[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
skipping to change at page 4, line 34 skipping to change at page 4, line 42
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 constrains to be satisfied in
order to eliminate the MED-induced route oscillation. In addition, order to eliminate the MED-induced route oscillation. Specific
the BGP speakers still depend on the route selection by the route topological considerations are described in [RFC3345].
reflector or the confederation ASBR. As the route selection involves
the comparison of the nexthop's IGP metrics which are specific to a
particular BGP speaker, the routing information advertised by a route
reflector or a confederation ASBR may still be inadequate to avoid
other routing inconsistencies such as forwarding loops in certain
networks.
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.
5.1. Route Reflection 5.1. Route Reflection
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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 constrains 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. Note that the number of paths that need to be maintained and
advertised can be greatly reduced by accepting the IGP metric based advertised can be greatly reduced by accepting MEDs from other
MEDs from other peering networks. 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].
skipping to change at page 7, line 20 skipping to change at page 7, line 20
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-10 (work in progress), October 2014. add-paths-10 (work in progress), October 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<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, April 2006. (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<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, August 2007. System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<http://www.rfc-editor.org/info/rfc5065>.
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, August 2002. Oscillation Condition", RFC 3345, DOI 10.17487/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.
 End of changes. 14 change blocks. 
23 lines changed or deleted 29 lines changed or added

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