draft-ietf-idr-custom-decision-07.txt   draft-ietf-idr-custom-decision-08.txt 
Inter-Domain Routing A. Retana Inter-Domain Routing A. Retana
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. White Intended status: Standards Track R. White
Expires: May 4, 2016 Ericsson Expires: August 7, 2017 LinkedIn
November 1, 2015 February 3, 2017
BGP Custom Decision Process BGP Custom Decision Process
draft-ietf-idr-custom-decision-07 draft-ietf-idr-custom-decision-08
Abstract Abstract
The BGP specification describes a Decision Process for selecting the The BGP specification describes a Decision Process for selecting the
best route. This process uses a series of steps, made up of path best route. This process uses a series of steps, made up of path
attributes and other values, to first determine the Degree of attributes and other values, to first determine the Degree of
Preference of a route and later as tie breakers. While existing Preference of a route and later as tie breakers. While existing
mechanisms may achieve some of the same results described in this mechanisms may achieve some of the same results described in this
document, they can only do so through extensive configuration such as document, they can only do so through extensive configuration such as
matching communities to explicit policy and/or route preference matching communities to explicit policy and/or route preference
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 4, 2016. This Internet-Draft will expire on August 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2017 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. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3 3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Cost Community Point of Insertion Registry . . . . . . . 7 7.1. Cost Community Point of Insertion Registry . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
A.1. Changes between the -00 and -01 versions. . . . . . . . . 9 A.1. Changes between the -00 and -01 versions. . . . . . . . . 10
A.2. Changes between the -01 and -02 versions. . . . . . . . . 10 A.2. Changes between the -01 and -02 versions. . . . . . . . . 10
A.3. Changes between the -02 and -03 versions. . . . . . . . . 10 A.3. Changes between the -02 and -03 versions. . . . . . . . . 10
A.4. Changes between the -03 and -04 versions. . . . . . . . . 10 A.4. Changes between the -03 and -04 versions. . . . . . . . . 10
A.5. Changes between the -04 and -05 versions. . . . . . . . . 10 A.5. Changes between the -04 and -05 versions. . . . . . . . . 10
A.6. Changes between the -05 and -06 versions. . . . . . . . . 10 A.6. Changes between the -05 and -06 versions. . . . . . . . . 10
A.7. Changes between the -06 and -07 versions . . . . . . . . 10 A.7. Changes between the -06 and -07 versions . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 A.8. Changes between the -07 and -08 versions . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The BGP specification defines a Decision Process [RFC4271] for The BGP specification defines a Decision Process [RFC4271] for
selecting the best route. This process uses a series of steps, made selecting the best route. This process uses a series of steps, made
up of path attributes and other values, to first determine the Degree up of path attributes and other values, to first determine the Degree
of Preference of a route and later as tie breakers. While existing of Preference of a route and later as tie breakers. While existing
mechanisms may achieve some of the same results described in this mechanisms may achieve some of the same results described in this
document, they can only do so through extensive configuration such as document, they can only do so through extensive configuration such as
matching communities to explicit policy and/or route preference matching communities to explicit policy and/or route preference
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Type Field: Type Field:
The value of the high-order octet is determined by provisioning The value of the high-order octet is determined by provisioning
[RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost [RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost
Community' in both the Transitive Opaque Extended Community Sub- Community' in both the Transitive Opaque Extended Community Sub-
Types registry and the Non-Transitive Opaque Extended Community Types registry and the Non-Transitive Opaque Extended Community
Sub-Types registry. Sub-Types registry.
Value Field: Value Field:
The Value field contains three distinct sub-fields, described The Value field contains four distinct sub-fields, described
below: below:
+------------------------------+ 0 1 2 3 4 5 6 7
| Point of Insertion (1 octet) | +--------------------------------------+
+------------------------------+ | Point of Insertion (1 octet) |
| Community-ID (1 octet) | +--------------------------------------+
+------------------------------+ | R | Community-ID (7 bits) |
| Cost (4 octets) | +--------------------------------------+
+------------------------------+ | Cost (4 octets) |
| |
| |
| |
+--------------------------------------+
The Point of Insertion (POI) sub-field indicates *after*, or The Point of Insertion (POI) sub-field indicates *after*, or
*instead of*, which step in the Decision Process the Cost *instead of*, which step in the Decision Process the Cost
Community MUST be considered. Community MUST be considered. The Point of Application (POA)
refers to the step in the Decision Process where the Cost
Community is effectively considered -- the relationship between
the POI and the POA is determined by the Replace Bit (see below).
The value of the POI may reference a path attribute used in the The value of the POI may reference a path attribute used in the
Decision Process. In this case the Cost Community is Decision Process. In this case the POA is related to the step
considered after, or instead of, the step where the path where the path attribute is considered.
attribute is considered.
The Decision Process includes some steps that do not correspond The Decision Process includes some steps that do not correspond
to any path attribute; the following values are defined: to any path attribute; the following values are defined:
128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be
considered as the first step in determining the Degree of considered as the first step in determining the Degree of
Preference of a route (Section 9.1.1 of [RFC4271]). If two Preference of a route (Section 9.1.1 of [RFC4271]). If two
routes have the same Cost, then the rest of the Calculation routes have the same Cost, then the rest of the Calculation
of Degree of Preference is to be followed. of Degree of Preference is to be followed.
skipping to change at page 4, line 50 skipping to change at page 5, line 9
[RFC4271]. [RFC4271].
131 BGP_ID - Indicates that the Cost Community MUST be 131 BGP_ID - Indicates that the Cost Community MUST be
considered after the BGP Identifier (or ORIGINATOR_ID considered after the BGP Identifier (or ORIGINATOR_ID
[RFC4456]) has been compared. [RFC4456]) has been compared.
This document creates a new Cost Community Point of Insertion This document creates a new Cost Community Point of Insertion
Registry (Section 7.1) that includes the relevant path Registry (Section 7.1) that includes the relevant path
attributes and these other values. attributes and these other values.
The Community-ID sub-field contains an identifier to distinguish The Replace Bit (R-bit) is a single-bit field, that when set
between multiple instances of the Cost Community. The high-order indicates that the Cost Community MUST replace the step indicated
bit indicates that the Cost Community MUST replace the step by the POI in the Decision Process.
indicated by the POI in the Decision Process.
If the high-order bit is set, the Cost in the Cost Community If the R-bit is not set, then the POA is after the step in the
may replace the value of a path attribute at a specific step in Decision Process indicated by the POI, which may result in an
the Decision Process, but not the attribute itself. For additional step. If the R-bit is set, then the POA is at the
example, if the high-order bit is set with the AS_PATH POI, the step identified by the POI.
AS_PATH attribute would still be used for loop prevention
[RFC4271], but the Cost would replace its length in the
Decision Process.
The high-order bit MUST be ignored when used with the If the R-bit is set, the Cost in the Cost Community replaces
ABSOLUTE_VALUE POI. the value of a path attribute at a specific step in the
Decision Process, but not the attribute itself. For example,
if the R-bit is set with the AS_PATH POI, the AS_PATH attribute
would still be used for loop detection [RFC4271], but the Cost
would replace its length in the Decision Process.
The R-bit MUST be ignored when used with the ABSOLUTE_VALUE
POI.
If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is If the Accumulated IGP Metric Attribute (AIGP) [RFC7311] is
used such that the "AIGP-enhanced interior cost" replaces the used such that the "AIGP-enhanced interior cost" replaces the
"interior cost" tie breaker in the Decision Process, and the "interior cost" tie breaker in the Decision Process, and the
high-order bit is set with the IGP_COST POI, then the Cost R-bit is set with the IGP_COST POI, then the Cost Community
Community SHOULD be ignored in favor of the process described SHOULD be ignored in favor of the process described in
in Section 4.2 of [RFC7311]. Section 4.2 of [RFC7311].
The Community-ID sub-field contains an identifier to distinguish
between multiple instances of the Cost Community.
The Cost sub-field is a 32-bit unsigned integer. It contains a The Cost sub-field is a 32-bit unsigned integer. It contains a
value assigned by the network administrator that is significant to value assigned by the network administrator that is significant to
their administrative domain. The default Cost is 0x7FFFFFFF (half their administrative domain. The default Cost is 0x7FFFFFFF (half
the maximum). the maximum).
If the Cost Community is inserted after a step in the Decision If the Cost Community is inserted after a step in the Decision
Process, and is therefore only compared to other Cost Process, and is therefore only compared to other Cost
Communities, the lower Cost MUST be preferred. Communities, the lower Cost MUST be preferred.
If the Cost Community replaces a step in the Decision Process, If the Cost Community replaces a step in the Decision Process,
it MUST be treated exactly as the value it is replacing would it MUST be treated exactly as the value it is replacing would
be treated. It is up to the network administrator to select be treated. It is up to the network administrator to select
the appropriate Cost to use when replacing a specific step; the the appropriate Cost to use when replacing a specific step; the
method to do that is outside the scope of this document. method to do that is outside the scope of this document.
4. Operation 4. Operation
The network administrator may use the Cost Community to assign a Cost The network administrator may use the Cost Community to assign a Cost
to a route originated, or learned from a peer, in any part of their to a route originated, or learned from a peer, in any part of their
administrative domain. The POI MUST also be specified. administrative domain. The POA MUST also be specified by the
combination of the POI and the R-bit.
If a BGP speaker receives a route that contains the Cost Community, If a BGP speaker receives a route that contains the Cost Community,
it MUST consider its Cost at the POI specified, during the Decision it MUST consider its Cost at the POA specified, during the Decision
Process. Process.
If the POI is not valid for the local Decision Process If the POI is not valid for the local Decision Process
implementation, then the Cost Community SHOULD be silently ignored. implementation, then the Cost Community SHOULD be silently ignored.
Multiple Cost Communities may indicate the same POI. All the Cost Multiple Cost Communities may indicate the same POA. All the Cost
Communities for a specific POI MUST be considered starting with the Communities for a specific POA MUST be considered starting with the
one(s) with the lowest Community-ID. If multiple Cost Communities, one(s) with the lowest Community-ID. If multiple Cost Communities,
for the same POI, with the same Community-ID are received for the for the same POA, with the same Community-ID are received for the
same route from the same peer, then all except the one with the same route from the same peer, then all except the one with the
lowest Cost MUST be silently ignored. lowest Cost MUST be silently ignored.
Routes that do not contain the Cost Community (for a valid, Routes that do not contain the Cost Community (for a valid,
particular POI), or a Community-ID present in a route from another particular POA), or a Community-ID present in a route from another
peer, MUST be considered to have the default Cost. peer, MUST be considered to have the default Cost.
If a range of routes is to be aggregated and the resultant aggregate If a range of routes is to be aggregated and the resultant aggregate
path attributes do not carry the ATOMIC_AGGREGATE attribute, then the path attributes do not carry the ATOMIC_AGGREGATE attribute, then the
resulting aggregate SHOULD have an Extended Communities path resulting aggregate SHOULD have an Extended Communities path
attribute which contains the set union of all the Cost Communities attribute which contains the set union of all the Cost Communities
from all of the aggregated routes. If multiple Cost Communities for from all of the aggregated routes. If multiple Cost Communities for
the same POI (and with the same Community-ID) exist, then only the the same POA (and with the same Community-ID) exist, then only the
ones with the highest Cost SHOULD be included. ones with the highest Cost SHOULD be included.
If the non-transitive version of a Cost Community is received across If the non-transitive version of a Cost Community is received across
an Autonomous System boundary, then the receiver MUST strip it off an Autonomous System boundary, then the receiver MUST strip it off
the BGP update, and ignore it during the Decision Process. the BGP update, and ignore it during the Decision Process.
5. Deployment Considerations 5. Deployment Considerations
The mechanisms described in this document may be used to modify the The mechanisms described in this document may be used to modify the
Decision Process arbitrarily. It is important that a consistent Decision Process arbitrarily. It is important that a consistent
Decision Process be maintained across the local Autonomous System to Decision Process be maintained across the local Autonomous System to
avoid potential routing loops. In other words, all the nodes in the avoid potential routing loops. In other words, all the nodes in the
AS that may have to consider the Cost Community at any POI MUST AS that may have to consider the Cost Community MUST support the
support the mechanisms described in this document. mechanisms described in this document.
Any mechanism which allows the modification of the Decision Process Any mechanism which allows the modification of the Decision Process
is capable of forming persistent routing loops in the control plane. is capable of forming persistent routing loops in the control plane.
Network administrators deploying the Cost Community MUST ensure that Network administrators deploying the Cost Community MUST ensure that
each impacted router in the network supports them, including the POIs each impacted router supports them mechanisms in this document for
deployed within their network. This is similar in scope to a network the POIs deployed within their network. This is similar in scope to
administrator who uses communities [RFC1997] combined with filters or a network administrator who uses communities [RFC1997] combined with
other policies to modify the Decision Process of BGP speakers. filters or other policies to modify the Decision Process of BGP
Consistency must be enforced at an administrative level. speakers. Consistency must be enforced at an administrative level.
6. Security Considerations 6. Security Considerations
This document defines a new Extended Community, called the Cost This document defines a new Extended Community, called the Cost
Community, which may be used to customize the Decision Process. As Community, which may be used to customize the Decision Process. As
such, the considerations outlined in [RFC4360] and [RFC4271] do not such, the considerations outlined in [RFC4360] and [RFC4271] do not
change. change.
To minimize the potential of creating routing loops (Section 5) or To minimize the potential of creating routing loops (Section 5) or
otherwise affecting the Decision Process in unintended ways, the otherwise affecting the Decision Process in unintended ways, the
propagation of Cost Communities MUST be disabled by default and MUST propagation of Cost Communities MUST be disabled by default and MUST
be explicitly enabled by the network administrator. Furthermore, all be explicitly enabled by the network administrator. Furthermore, all
transitive Cost Communities received across an Autonomous System Cost Communities received across an Autonomous System boundary
boundary without explicit configuration MUST be stripped off the BGP without explicitly being enabled MUST be stripped off the BGP update,
update, and ignored during the Decision Process. and ignored during the Decision Process.
An ill-designed policy deployment using the Cost Community (e.g. one An ill-designed policy deployment using the Cost Community (e.g. one
where there is no consistent POI support throughout the AS) may where there is no consistent POI support throughout the AS) may
result in persistent routing loops that could result in loss of result in persistent routing loops that could result in loss of
traffic. The design and implementation of policies for best route traffic. The design and implementation of policies for best route
selection are outside the scope of this document. selection are outside the scope of this document.
7. IANA Considerations 7. IANA Considerations
IANA has assigned the codepoint value 0x01 to 'Cost Community' in IANA has assigned the codepoint value 0x01 to 'Cost Community' in
skipping to change at page 10, line 39 skipping to change at page 11, line 5
A.7. Changes between the -06 and -07 versions A.7. Changes between the -06 and -07 versions
o The review from Bruno Decraene and Eric Rosen resulted in several o The review from Bruno Decraene and Eric Rosen resulted in several
important changes related to the clarity and consistency of the important changes related to the clarity and consistency of the
document. document.
o Added considerations for co-existence with AIGP. o Added considerations for co-existence with AIGP.
o Security Considerations. o Security Considerations.
A.8. Changes between the -07 and -08 versions
o Clarified the Security Considerations to ensure that routers don't
apply the Cost Community by default.
o Separated the high-order bit in the Community-ID into its oen
field (for clarity). Called it the Replace Bit (R-bit).
o Introduced the POA concept.
Authors' Addresses Authors' Addresses
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 USA
Email: aretana@cisco.com Email: aretana@cisco.com
Russ White Russ White
Ericsson LinkedIn
Apex, NC 27539 Apex, NC 27539
USA USA
Email: russw@riw.us Email: russ@riw.us
 End of changes. 32 change blocks. 
59 lines changed or deleted 85 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/