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

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