--- 1/draft-ietf-idr-custom-decision-00.txt 2012-05-28 12:14:14.277341826 +0200 +++ 2/draft-ietf-idr-custom-decision-01.txt 2012-05-28 12:14:14.293390451 +0200 @@ -1,19 +1,19 @@ Inter-Domain Routing A. Retana Internet-Draft Hewlett-Packard Co. Intended status: Standards Track R. White -Expires: May 24, 2012 Cisco Systems, Inc. - November 21, 2011 +Expires: November 19, 2012 Verisign + May 18, 2012 BGP Custom Decision Process - draft-ietf-idr-custom-decision-00 + draft-ietf-idr-custom-decision-01 Abstract The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. @@ -31,51 +31,52 @@ 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 24, 2012. + This Internet-Draft will expire on November 19, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. The BGP Cost Community . . . . . . . . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Cost Community Point of Insertion Registry . . . . . . 7 + Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction There are a number of metrics available within the BGP decision process [RFC4271] which can be used to determine the exit point for traffic, but there is no metric, or combination of metrics, which can be used to break a tie among generally equal paths. o LOCAL_PREF: The LOCAL_PREF is an absolute tie breaker near the @@ -165,62 +166,67 @@ The Cost sub-field contains a value assigned by the network administrator and that is significant to the local autonomous system. The lower cost MUST be preferred. The default value is 0x7FFFFFFF (half the maximum value). 4. Operation The network administrator may use the Cost Community to assign a value to a path originated or learned from a peer in any part of the - local domain. The Point of Insertion may also be specified using the - values assigned by IANA (Section 6) or this document. + local domain. The Point of Insertion is also specified using the + values defined in Appendix A. If a BGP speaker receives a path that contains the Cost Community, it SHOULD consider its value at the Point of Insertion specified, when calculating the best path [RFC4271]. If the Point of Insertion is not valid for the local best path selection implementation, then the Cost Community SHOULD be silently ignored. Paths that do not contain the Cost Community (for a valid, particular Point of Insertion) MUST be considered to have the default value. Multiple Cost Communities may indicate the same Point of Insertion. In this case, the Cost Community with the lowest Community-ID is considered first. In other words, all the Cost Communities for a specific Point of Insertion MUST be considered, starting with the one with the lowest Community-ID. - If a range of routes is to be aggregated and the resultant aggregates + 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 Point of Insertion (and with the same Community-ID), 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 SHOULD strip it off + an Autonomous System boundary, then the receiver MUST strip it off the BGP update, and ignore it when running the selection process. 5. Deployment Considerations The mechanisms described in this document may be used to modify the BGP path selection process arbitrarily. It is important that a consistent path selection process be maintained across the local Autonomous System to avoid potential routing loops. In other words, if the Cost Community is used, all the nodes in the AS that may have to consider this new community at any Point of Insertion SHOULD be aware of the mechanisms described in this document. -6. IANA Considerations +6. Security Considerations + + This document introduces no new security concerns to BGP or other + specifications referenced in this document. + +7. IANA Considerations IANA is asked to assign the type values indicated in Section 3 to the Cost Community in the BGP Opaque Extended Community registry [BGP_EXT]. Section 3 also defines a series of values to be used to indicate steps in the best path selection process that do not map directly to a path attribute. IANA is expected to maintain a registry for the Cost Community Point of Insertion values. Values 1 through 127 are to be assigned using the "Standards Action" policy or the Early @@ -229,32 +235,26 @@ are to be assigned using the "First Come First Served" policy. Values 0 and 255 are reserved for future use and SHOULD NOT be used. All the policies mentioned are documented in [RFC5226]. Some of the values in this new registry match the values assigned in the BGP Path Attributes registry [BGP_PAR]. It is RECOMMENDED that an effort be made to assign the same values in both tables when applicable. The table in Appendix A shows the initial allocations for the new Cost Community Point of Insertion registry. -7. Security Considerations - - This document introduces no new security concerns to BGP or other - specifications referenced in this document. - 8. Acknowledgements - The authors would like to thank Chris Whyte, Khamsa Enaya, John - Scudder, Tom Barron, Eric Rosen, Barry Friedman, Gargi Nalawade, - Ruchi Kapoor, Chandra Appanna, Keyur Patel and Pradosh Mohapatra for - their comments and suggestions. We would like to also thank Dan - Tappan for the Opaque Extended Community type. + There have been many people who have shown their support and provided + valuable input, comments and implementations -- the authors would + like to thank all of them! We would like to also thank Dan Tappan + for the Opaque Extended Community type. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. @@ -311,27 +311,35 @@ | 26 | AIGP | draft-ietf-idr-aigp | | 27-127 | Unassigned | | | 128 | ABSOLUTE_VALUE | draft-ietf-idr-custom-decision | | 129 | IGP_COST | draft-ietf-idr-custom-decision | | 130 | EXTERNAL_INTERNAL | draft-ietf-idr-custom-decision | | 131 | BGP_ID | draft-ietf-idr-custom-decision | +--------+-------------------+--------------------------------+ Point of Insertion Codes +Appendix B. Change Log + + The following are the changes with respect to the -00 version. + + o Updated authors' contact information. + + o Editorial changes in the "Operations" and "Acknowledgement" + sections. + Authors' Addresses Alvaro Retana Hewlett-Packard Co. 2610 Wycliff Road Raleigh, NC 27607 USA Email: alvaro.retana@hp.com - Russ White - Cisco Systems, Inc. - 7025 Kit Creek Rd. - Research Triangle Park, NC 27709 + Verisign + 12061 Bluemont Way + Reston, VA 20190 USA - Email: russwh@cisco.com + Email: riwhite@verisign.com