idnits 2.17.1 draft-retana-bgp-custom-decision-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1771]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2796 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2042 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alvaro Retana 3 Internet Draft Russ White 4 Expiration Date: April 2003 Cisco Systems, Inc. 5 File name: draft-retana-bgp-custom-decision-00.txt October 2002 7 BGP Custom Decision Process 8 draft-retana-bgp-custom-decision-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The BGP specification [RFC1771] defines a Decision Process for 34 installation of routes into the Loc-RIB. This process takes into 35 account an extensive series of path attributes, which can be 36 manipulated to indicate preference for specific paths. It is 37 cumbersome (if at all possible) for the end user to define policies 38 that will select, after partial comparison, a path based on 39 subjective local (domain and/or node) criteria. 41 This document defines a new Extended Community [EXT_COMM], called the 42 Cost Community, which may be used in tie breaking during the best 43 path selection process. The end result is a local custom decision 44 process. 46 1. Introduction 48 There are a number of metrics available within the BGP decision 49 process [RFC1771] which can be used to determine the exit point for 50 traffic, but there is no metric, or combination of metrics, which can 51 be used to break a tie among generally equal paths. 53 o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the 54 beginning of the decision process. There is no way to configure 55 the LOCAL_PREF such that the MED, IGP metric, and other metrics 56 are considered before breaking a tie. 58 o MED: The MULTI_EXIT_DISC is an indicator of which local entrance 59 point an AS would like a peering AS to use; MED isn't suitable 60 to break the tie between two equal cost paths learned from two 61 peer ASes. MED is also compared before the IGP metric; there is 62 no way to set the MED so a path with a higher IGP metric is pre- 63 ferred over a path with a lower IGP metric. 65 o IGP Metric: It is possible, using the IGP metric, to influence 66 individual paths with otherwise equal cost metrics, but only by 67 changing the next hop towards each path, and configuring the IGP 68 costs of reaching each next hop. This method is cumbersome, and 69 prone to confusion and error. 71 2. Specification of Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 3. The BGP Cost Community 79 The BGP Cost Community is an Opaque Extended Community [EXT_COMM] 80 defined as follows: 82 Type Field: 84 The value of the high-order octet of the extended Type Field is 85 0x43, which indicates it is non-transitive. The value of the 86 low-order octet of the extended type field for this community 87 is TBD. 89 Value Field 91 The Value field contains three distinct sub-fields, described 92 below: 94 +------------------------------+ 95 | Point of Insertion (1 octet) | 96 +------------------------------+ 97 | Community-ID (1 octet) | 98 +------------------------------+ 99 | Cost (4 octets) | 100 +------------------------------+ 102 The Point of Insertion sub-field contains the value of the 103 path attribute [BGP_PAR] *after* which this community MUST 104 be considered during the best path selection process. 106 The BGP decision process [RFC1771] includes some steps 107 that do not correspond to any path attribute; the follow- 108 ing values are defined: 110 Value Meaning 112 128 113 ABSOLUTE_VALUE - Indicates that the Cost Community 114 MUST be considered as the first step in determining 115 the Degree of Preference of a path. 117 129 118 IGP_COST - Indicates that the Cost Community MUST be 119 considered after the interior (IGP) distance to the 120 next-hop has been compared. 122 130 123 EXTERNAL_INTERNAL - Indicates that the Cost Commun- 124 ity MUST be considered after the paths advertised by 125 BGP speakers in a neighbouring autonomous system (if 126 any) have been selected. 128 131 129 BGP_ID - Indicates that the Cost Community MUST be 130 considered after the BGP Identifier (or 131 ORIGINATOR_ID [RFC2796]) has been compared. 133 The Community-ID sub-field contains an identifier to distin- 134 guish between multiple instances of the Cost Community. 136 The Cost sub-field contains a value assigned by the network 137 administrator and that is significant to the local auto- 138 nomous system. The lower cost MUST be preferred. The 139 default value is 0x7FFFFFFF (half the maximum value). 141 4. Operation 143 The network administrator may use the Cost Community to assign a 144 value to a path originated or learned by a peer in any part of the 145 local domain. The Point of Insertion may also be specified using the 146 values defined in the IANA registry [BGP_PAR] or this document. 148 If a BGP speaker receives a path that contains the Cost Community, it 149 MUST consider its value at the Point of Insertion specified, when 150 calculating the best path [RFC1771]. 152 If the Point of Insertion is not valid for the local best path selec- 153 tion implementation, then the Cost Community is silently ignored. 154 Paths that do not contain the Cost Community (for a valid, particular 155 Point of Insertion) are considered to have the default value. 157 Multiple Cost Communities may indicate the same Point of Insertion. 158 In this case, the Cost Community with the lowest Community-ID is con- 159 sidered first. In other words, all the Cost Communities for a 160 specific Point of Insertion are considered, starting with the one 161 with the lowest Community-ID. 163 If a range of routes is to be aggregated and the resultant aggregates 164 path attributes do not carry the ATOMIC_AGGREGATE attribute, then the 165 resulting aggregate should have an Extended Communities path attri- 166 bute which contains the set union of all the Cost Communities from 167 all of the aggregated routes. If multiple Cost Communities for the 168 same Point of Insertion (and with the same Community-ID), then only 169 the ones with the highest Cost SHOULD be included. 171 The Cost Community is a non-transitive Extended Community [EXT_COMM]. 172 If a Cost Community is received across an Autonomous System boundary, 173 then the receiver SHOULD strip it off the BGP update, and ignore it 174 when running the selection process. 176 4.1. Deployment Considerations 178 The mechanisms described in this document may be used to modify the 179 BGP path selection process arbitrarily, within an AS. It is impor- 180 tant that a consistent path selection process be maintained across 181 the local Autonomous System to avoid potential routing loops. In 182 other words, if the Cost Community is used, all the nodes in the AS 183 that may have to consider this new community at any Point of Inser- 184 tion SHOULD be aware of the mechanisms described in this document. 186 5. IANA Considerations 188 The section titled "The BGP Cost Community" defines a series of 189 values to be used to indicate steps in the best path selection pro- 190 cess [RFC1771] that do not map directly to a path attribute. IANA is 191 expected to maintain the registry for these values. Values 128 192 through 191 are to be assigned by IANA using the "IETF Consensus" 193 policy defined in RFC2434 [RFC2434]. Values 192 through 254 are for 194 "Private Use" as defined in RFC2434 [RFC2434]. 196 The Value space defined above matches the one already used and main- 197 tained by IANA to assign BGP path attributes [BGP_PAR]. It is RECOM- 198 MENDED that the values specified in this document are added to the 199 current registry [BGP_PAR] and the process to register new attributes 200 be updated [RFC2042]. 202 6. Security Considerations 204 This document introduces no new security concerns to BGP or other 205 specifications referenced in this document. 207 7. Acknowledgments 209 We would like to thank Chris Whyte, Khamsa Enaya, John Scudder, Tom 210 Barron, Eric Rosen, Barry Friedman, Gargi Nalawade, Ruchi Kapoor and 211 Chandra Appanna for their comments and suggestions. We would like to 212 also thank Dan Tappan for the Opaque Extended Community type. 214 8. References 216 [RFC1771] 217 Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 218 1771, March 1995. 220 [EXT_COMM] 221 Sangli, S., Tappan, D., and Rekhter, Y., "BGP Extended Communities 222 Attribute", Work in Progress (draft-ietf-idr-bgp-ext-communities- 223 05.txt), May 2002. 225 [RFC2119] 226 Bradner, S., "Key words for use in RFCs to Indicate Requirement 227 Levels", RFC 2119, March 1997. 229 [BGP_PAR] 230 Internet Assigned Numbers Authority, "BGP Parameters", 231 http://www.iana.org/assignments/bgp-parameters. 233 [RFC2796] 234 Bates, T., Chandra, R., and Chen, E., "BGP Route Reflection - An 235 Alternative to Full Mesh IBGP", RFC 2796, April 2000. 237 [RFC2434] 238 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 239 siderations Section in RFCs", RFC 2434, October 1998. 241 [RFC2042] 242 Manning, B., "Registering New BGP Attribute Types", RFC 2042, 243 January 1997. 245 9. Authors' Addresses 247 Alvaro Retana 248 Cisco Systems, Inc. 249 7025 Kit Creek Rd. 250 Research Triangle Park, NC 27709 251 Email: aretana@cisco.com 253 Russ White 254 Cisco Systems, Inc. 255 7025 Kit Creek Rd. 256 Research Triangle Park, NC 27709 257 Email: riw@cisco.com