--- 1/draft-ietf-idr-custom-decision-07.txt 2017-02-03 13:13:09.268417834 -0800 +++ 2/draft-ietf-idr-custom-decision-08.txt 2017-02-03 13:13:09.292418406 -0800 @@ -1,19 +1,19 @@ Inter-Domain Routing A. Retana Internet-Draft Cisco Systems, Inc. Intended status: Standards Track R. White -Expires: May 4, 2016 Ericsson - November 1, 2015 +Expires: August 7, 2017 LinkedIn + February 3, 2017 BGP Custom Decision Process - draft-ietf-idr-custom-decision-07 + draft-ietf-idr-custom-decision-08 Abstract The BGP specification describes a Decision Process for selecting the best route. This process uses a series of steps, made up of path attributes and other values, to first determine the Degree of Preference of a route and later as tie breakers. While existing mechanisms may achieve some of the same results described in this document, they can only do so through extensive configuration such as matching communities to explicit policy and/or route preference @@ -34,60 +34,61 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . 3 - 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. Security 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 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 - A.1. Changes between the -00 and -01 versions. . . . . . . . . 9 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 + A.1. Changes between the -00 and -01 versions. . . . . . . . . 10 A.2. Changes between the -01 and -02 versions. . . . . . . . . 10 A.3. Changes between the -02 and -03 versions. . . . . . . . . 10 A.4. Changes between the -03 and -04 versions. . . . . . . . . 10 A.5. Changes between the -04 and -05 versions. . . . . . . . . 10 A.6. Changes between the -05 and -06 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 The BGP specification defines a Decision Process [RFC4271] for selecting the best route. This process uses a series of steps, made up of path attributes and other values, to first determine the Degree of Preference of a route and later as tie breakers. While existing mechanisms may achieve some of the same results described in this document, they can only do so through extensive configuration such as matching communities to explicit policy and/or route preference @@ -129,39 +130,45 @@ Type Field: The value of the high-order octet is determined by provisioning [RFC4360]. IANA has assigned the codepoint value 0x01 to 'Cost Community' in both the Transitive Opaque Extended Community Sub- Types registry and the Non-Transitive Opaque Extended Community Sub-Types registry. Value Field: - The Value field contains three distinct sub-fields, described + The Value field contains four distinct sub-fields, described below: - +------------------------------+ + 0 1 2 3 4 5 6 7 + +--------------------------------------+ | Point of Insertion (1 octet) | - +------------------------------+ - | Community-ID (1 octet) | - +------------------------------+ + +--------------------------------------+ + | R | Community-ID (7 bits) | + +--------------------------------------+ | Cost (4 octets) | - +------------------------------+ + | | + | | + | | + +--------------------------------------+ The Point of Insertion (POI) sub-field indicates *after*, or *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 - Decision Process. In this case the Cost Community is - considered after, or instead of, the step where the path - attribute is considered. + Decision Process. In this case the POA is related to the step + where the path attribute is considered. The Decision Process includes some steps that do not correspond to any path attribute; the following values are defined: 128 ABSOLUTE_VALUE - Indicates that the Cost Community MUST be considered as the first step in determining the Degree of Preference of a route (Section 9.1.1 of [RFC4271]). If two routes have the same Cost, then the rest of the Calculation of Degree of Preference is to be followed. @@ -174,126 +181,134 @@ [RFC4271]. 131 BGP_ID - Indicates that the Cost Community MUST be considered after the BGP Identifier (or ORIGINATOR_ID [RFC4456]) has been compared. This document creates a new Cost Community Point of Insertion Registry (Section 7.1) that includes the relevant path attributes and these other values. - The Community-ID sub-field contains an identifier to distinguish - between multiple instances of the Cost Community. The high-order - bit indicates that the Cost Community MUST replace the step - indicated by the POI in the Decision Process. + The Replace Bit (R-bit) is a single-bit field, that when set + indicates that the Cost Community MUST replace the step indicated + by the POI in the Decision Process. - If the high-order bit is set, the Cost in the Cost Community - may replace the value of a path attribute at a specific step in - the Decision Process, but not the attribute itself. For - example, if the high-order bit is set with the AS_PATH POI, the - AS_PATH attribute would still be used for loop prevention - [RFC4271], but the Cost would replace its length in the - Decision Process. + If the R-bit is not set, then the POA is after the step in the + Decision Process indicated by the POI, which may result in an + additional step. If the R-bit is set, then the POA is at the + step identified by the POI. - The high-order bit MUST be ignored when used with the - ABSOLUTE_VALUE POI. + If the R-bit is set, the Cost in the Cost Community replaces + 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 used such that the "AIGP-enhanced interior cost" replaces the "interior cost" tie breaker in the Decision Process, and the - high-order bit is set with the IGP_COST POI, then the Cost - Community SHOULD be ignored in favor of the process described - in Section 4.2 of [RFC7311]. + R-bit is set with the IGP_COST POI, then the Cost Community + SHOULD be ignored in favor of the process described in + 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 value assigned by the network administrator that is significant to their administrative domain. The default Cost is 0x7FFFFFFF (half the maximum). If the Cost Community is inserted after a step in the Decision Process, and is therefore only compared to other Cost Communities, the lower Cost MUST be preferred. If the Cost Community replaces a step in the Decision Process, it MUST be treated exactly as the value it is replacing would be treated. It is up to the network administrator to select the appropriate Cost to use when replacing a specific step; the method to do that is outside the scope of this document. 4. Operation 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 - 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, - 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. If the POI is not valid for the local Decision Process implementation, then the Cost Community SHOULD be silently ignored. - Multiple Cost Communities may indicate the same POI. All the Cost - Communities for a specific POI MUST be considered starting with the + Multiple Cost Communities may indicate the same POA. All the Cost + Communities for a specific POA MUST be considered starting with the 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 lowest Cost MUST be silently ignored. 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. If a range of routes is to be aggregated and the resultant aggregate path attributes do not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate SHOULD have an Extended Communities path attribute which contains the set union of all the Cost Communities 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. If the non-transitive version of a Cost Community is received across an Autonomous System boundary, then the receiver MUST strip it off the BGP update, and ignore it during the Decision Process. 5. Deployment Considerations The mechanisms described in this document may be used to modify the Decision Process arbitrarily. It is important that a consistent Decision Process be maintained across the local Autonomous System to 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 - support the mechanisms described in this document. + AS that may have to consider the Cost Community MUST support the + mechanisms described in this document. Any mechanism which allows the modification of the Decision Process is capable of forming persistent routing loops in the control plane. + Network administrators deploying the Cost Community MUST ensure that - each impacted router in the network supports them, including the POIs - deployed within their network. This is similar in scope to a network - administrator who uses communities [RFC1997] combined with filters or - other policies to modify the Decision Process of BGP speakers. - Consistency must be enforced at an administrative level. + each impacted router supports them mechanisms in this document for + the POIs deployed within their network. This is similar in scope to + a network administrator who uses communities [RFC1997] combined with + filters or other policies to modify the Decision Process of BGP + speakers. Consistency must be enforced at an administrative level. 6. Security Considerations This document defines a new Extended Community, called the Cost Community, which may be used to customize the Decision Process. As such, the considerations outlined in [RFC4360] and [RFC4271] do not change. To minimize the potential of creating routing loops (Section 5) or otherwise affecting the Decision Process in unintended ways, the propagation of Cost Communities MUST be disabled by default and MUST be explicitly enabled by the network administrator. Furthermore, all - transitive Cost Communities received across an Autonomous System - boundary without explicit configuration MUST be stripped off the BGP - update, and ignored during the Decision Process. + Cost Communities received across an Autonomous System boundary + without explicitly being enabled MUST be stripped off the BGP update, + and ignored during the Decision Process. An ill-designed policy deployment using the Cost Community (e.g. one where there is no consistent POI support throughout the AS) may result in persistent routing loops that could result in loss of traffic. The design and implementation of policies for best route selection are outside the scope of this document. 7. IANA Considerations IANA has assigned the codepoint value 0x01 to 'Cost Community' in @@ -446,25 +462,36 @@ A.7. Changes between the -06 and -07 versions o The review from Bruno Decraene and Eric Rosen resulted in several important changes related to the clarity and consistency of the document. o Added considerations for co-existence with AIGP. 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 Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Email: aretana@cisco.com + Russ White - Ericsson + LinkedIn Apex, NC 27539 USA - Email: russw@riw.us + Email: russ@riw.us