[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Inter-Domain Routing                                           A. Retana
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                R. White
Expires: October 22, 2015                                       Ericsson
                                                          April 20, 2015


                      BGP Custom Decision Process
                   draft-ietf-idr-custom-decision-06

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.

   This document defines a new Extended Community, called the Cost
   Community, which may be used in tie breaking during the best path
   selection process.  The end result is a local custom decision
   process.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 October 22, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Retana & White          Expires October 22, 2015                [Page 1]


Internet-Draft         BGP Custom Decision Process            April 2015


   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
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Cost Community Point of Insertion Registry . . . . .   7
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
     B.1.  Changes between the -00 and -01 versions. . . . . . . . .   8
     B.2.  Changes between the -01 and -02 versions. . . . . . . . .   8
     B.3.  Changes between the -02 and -03 versions. . . . . . . . .   8
     B.4.  Changes between the -03 and -04 versions. . . . . . . . .   8
     B.5.  Changes between the -04 and -05 versions. . . . . . . . .   9
     B.6.  Changes between the -05 and -06 versions. . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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
      beginning of the decision process.  There is no way to configure
      the LOCAL_PREF such that the MED, IGP metric, and other metrics
      are considered before breaking a tie.

   o  MED: The MULTI_EXIT_DISC is an indicator of which local entrance
      point an AS would like a peering AS to use; MED isn't suitable to
      break the tie between two equal cost paths learned from two peer



Retana & White          Expires October 22, 2015                [Page 2]


Internet-Draft         BGP Custom Decision Process            April 2015


      ASes.  MED is also compared before the IGP metric; there is no way
      to set the MED so a path with a higher IGP metric is preferred
      over a path with a lower IGP metric.

   o  IGP Metric: It is possible, using the IGP metric, to influence
      individual paths with otherwise equal cost metrics, but only by
      changing the next hop towards each path, and configuring the IGP
      costs of reaching each next hop.  This method is cumbersome, and
      prone to confusion and error.

   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.

   This document defines a new Extended Community, called the Cost
   Community, which may be used in tie breaking during the best path
   selection process.  The end result is a custom decision process.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].




3.  The BGP Cost Community

   The BGP Cost Community is an Opaque Extended Community [RFC4360]
   defined as follows:

   Type Field:
      The value of the high-order octet of this Opaque Extended
      Community is 0x03 or 0x43.  The value of the low-order octet of
      the extended type field for this community is 0x01.

   Value Field:
      The Value field contains three distinct sub-fields, described
      below:







Retana & White          Expires October 22, 2015                [Page 3]


Internet-Draft         BGP Custom Decision Process            April 2015


                     +------------------------------+
                     | Point of Insertion (1 octet) |
                     +------------------------------+
                     | Community-ID (1 octet)       |
                     +------------------------------+
                     | Cost (4 octets)              |
                     +------------------------------+

      The Point of Insertion sub-field contains the value of the path
      attribute *after* which this community MUST be considered during
      the best path selection process.



         The BGP 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 path.

         129  IGP_COST - Indicates that the Cost Community MUST be
            considered after the interior (IGP) distance to the next-hop
            has been compared.

         130  EXTERNAL_INTERNAL - Indicates that the Cost Community MUST
            be considered after the paths advertised by BGP speakers in
            a neighboring autonomous system (if any) have been selected.

         131  BGP_ID - Indicates that the Cost Community MUST be
            considered after the BGP Identifier (or ORIGINATOR_ID
            [RFC4456]) has been compared.

      The Community-ID sub-field contains an identifier to distinguish
      between multiple instances of the Cost Community.  The high-order
      bit is reserved to indicate that the Cost Community MUST replace
      the path attribute specified by the Point of Insertion during the
      best path selection process.

      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).







Retana & White          Expires October 22, 2015                [Page 4]


Internet-Draft         BGP Custom Decision Process            April 2015


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 MUST also be 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 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) 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 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.







Retana & White          Expires October 22, 2015                [Page 5]


Internet-Draft         BGP Custom Decision Process            April 2015


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
   Allocation process [RFC7120].  Values 128 through 191 are to be
   assigned using the "IETF Consensus" policy.  Values 192 through 254
   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.

8.  Acknowledgements

   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.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.



Retana & White          Expires October 22, 2015                [Page 6]


Internet-Draft         BGP Custom Decision Process            April 2015


   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, January 2014.

9.2.  Informative References

   [BGP_EXT]  Internet Assigned Numbers Authority, "BGP Extended
              Communities", 2010, <http://www.iana.org/assignments/
              bgp-extended-communities>.

   [BGP_PAR]  Internet Assigned Numbers Authority, "BGP Parameters",
              2010, <http://www.iana.org/assignments/bgp-parameters/>.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, April 2006.

Appendix A.  Cost Community Point of Insertion Registry

   The tables below document the initial Cost Community Point of
   Insertion Registry

                   +---------+-------------------------+
                   | Range   | Registration Procedure  |
                   +---------+-------------------------+
                   | 0       | Reserved                |
                   | 1-127   | Standards Action        |
                   | 128-191 | IETF Consensus          |
                   | 192-254 | First Come First Served |
                   | 255     | Reserved                |
                   +---------+-------------------------+

                          Registration Procedure
















Retana & White          Expires October 22, 2015                [Page 7]


Internet-Draft         BGP Custom Decision Process            April 2015


      +--------+-------------------+--------------------------------+
      | Value  | Code              | Reference                      |
      +--------+-------------------+--------------------------------+
      | 1      | ORIGIN            | RFC4271                        |
      | 2      | AS_PATH           | RFC4271                        |
      | 3      | Unassigned        |                                |
      | 4      | MULTI_EXIT_DISC   | RFC4271                        |
      | 5      | LOCAL_PREF        | RFC4271                        |
      | 6-25   | Unassigned        |                                |
      | 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

B.1.  Changes between the -00 and -01 versions.

   o  Updated authors' contact information.

   o  Editorial changes in the "Operations" and "Acknowledgement"
      sections.

B.2.  Changes between the -01 and -02 versions.

   o  Updated authors' contact information.

   o  Added text to replace a step in the selection process.

   o  Minor edits.

B.3.  Changes between the -02 and -03 versions.

   o  No changes; just a refresh.

B.4.  Changes between the -03 and -04 versions.

   o  Updated authors' contact information.








Retana & White          Expires October 22, 2015                [Page 8]


Internet-Draft         BGP Custom Decision Process            April 2015


B.5.  Changes between the -04 and -05 versions.

   o  Updated authors' contact information.

B.6.  Changes between the -05 and -06 versions.

   o  Updated RFC 7120 reference (from RFC 4020).

Authors' Addresses

   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC  27709
   USA

   Email: aretana@cisco.com


   Russ White
   Ericsson

   Email: russw@riw.us




























Retana & White          Expires October 22, 2015                [Page 9]


Html markup produced by rfcmarkup 1.113, available from https://tools.ietf.org/tools/rfcmarkup/