doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7311.txt b/doc/rfc/rfc7311.txt
new file mode 100644
index 0000000..a6b064e
--- /dev/null
+++ b/doc/rfc/rfc7311.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      P. Mohapatra
+Request for Comments: 7311                              Sproute Networks
+Category: Standards Track                                    R. Fernando
+ISSN: 2070-1721                                                 E. Rosen
+                                                     Cisco Systems, Inc.
+                                                               J. Uttaro
+                                                                    AT&T
+                                                             August 2014
+
+
+              The Accumulated IGP Metric Attribute for BGP
+
+Abstract
+
+   Routing protocols that have been designed to run within a single
+   administrative domain (IGPs) generally do so by assigning a metric to
+   each link and then choosing, as the installed path between two nodes,
+   the path for which the total distance (sum of the metric of each link
+   along the path) is minimized.  BGP, designed to provide routing over
+   a large number of independent administrative domains (autonomous
+   systems), does not make its path-selection decisions through the use
+   of a metric.  It is generally recognized that any attempt to do so
+   would incur significant scalability problems as well as inter-
+   administration coordination problems.  However, there are deployments
+   in which a single administration runs several contiguous BGP
+   networks.  In such cases, it can be desirable, within that single
+   administrative domain, for BGP to select paths based on a metric,
+   just as an IGP would do.  The purpose of this document is to provide
+   a specification for doing so.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7311.
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 1]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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. Specification of Requirements ...................................4
+   3. AIGP Attribute ..................................................4
+      3.1. Applicability Restrictions and Cautions ....................6
+      3.2. Handling a Malformed AIGP Attribute ........................6
+      3.3. Restrictions on Sending/Receiving ..........................6
+      3.4. Creating and Modifying the AIGP Attribute ..................7
+           3.4.1. Originating the AIGP Attribute ......................7
+           3.4.2. Modifications by the Originator .....................8
+           3.4.3. Modifications by a Non-Originator ...................8
+   4. Decision Process ...............................................10
+      4.1. When a Route Has an AIGP Attribute ........................11
+      4.2. When the Route to the Next Hop Has an AIGP Attribute ......11
+   5. Deployment Considerations ......................................12
+   6. IANA Considerations ............................................13
+   7. Security Considerations ........................................13
+   8. Acknowledgments ................................................13
+   9. References .....................................................14
+      9.1. Normative Reference .......................................14
+      9.2. Informative References ....................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 2]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+1.  Introduction
+
+   There are many routing protocols that have been designed to run
+   within a single administrative domain.  These are known collectively
+   as "Interior Gateway Protocols" (IGPs).  Typically, each link is
+   assigned a particular "metric" value.  The path between two nodes can
+   then be assigned a "distance", which is the sum of the metrics of all
+   the links that belong to that path.  An IGP selects the "shortest"
+   (minimal distance) path between any two nodes, perhaps subject to the
+   constraint that if the IGP provides multiple "areas", it may prefer
+   the shortest path within an area to a path that traverses more than
+   one area.  Typically, the administration of the network has some
+   routing policy that can be approximated by selecting shortest paths
+   in this way.
+
+   BGP, as distinguished from the IGPs, was designed to run over an
+   arbitrarily large number of administrative domains ("autonomous
+   systems" or "ASes") with limited coordination among the various
+   administrations.  BGP does not make its path-selection decisions
+   based on a metric; there is no such thing as an "inter-AS metric".
+   There are two fundamental reasons for this:
+
+   -  The distance between two nodes in a common administrative domain
+      may change at any time due to events occurring in that domain.
+      These changes are not propagated around the Internet unless they
+      actually cause the border routers of the domain to select routes
+      with different BGP attributes for some set of address prefixes.
+      This accords with a fundamental principle of scaling, viz., that
+      changes with only local significance must not have global effects.
+      If local changes in distance were always propagated around the
+      Internet, this principle would be violated.
+
+   -  A basic principle of inter-domain routing is that the different
+      administrative domains may have their own policies, which do not
+      have to be revealed to other domains and which certainly do not
+      have to be agreed to by other domains.  Yet, the use of an inter-
+      AS metric in the Internet would have exactly these effects.
+
+   There are, however, deployments in which a single administration runs
+   a network that has been sub-divided into multiple, contiguous ASes,
+   each running BGP.  There are several reasons why a single
+   administrative domain may be broken into several ASes (which, in this
+   case, are not really autonomous.)  It may be that the existing IGPs
+   do not scale well in the particular environment; it may be that a
+   more generalized topology is desired than could be obtained by use of
+   a single IGP domain; it may be that a more finely grained routing
+   policy is desired than can be supported by an IGP.  In such
+   deployments, it can be useful to allow BGP to make its routing
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 3]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   decisions based on the IGP metric, so that BGP chooses the shortest
+   path between two nodes, even if the nodes are in two different ASes
+   within that same administrative domain.
+
+   There are, in fact, some implementations that already do something
+   like this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a
+   value based on IGP metrics.  However, that doesn't really provide
+   IGP-like shortest path routing, as the BGP decision process gives
+   priority to other factors, such as the AS_PATH length.  Also, the
+   standard procedures for use of the MED do not ensure that the IGP
+   metric is properly accumulated so that it covers all the links along
+   the path.
+
+   In this document, we define a new optional, non-transitive BGP
+   attribute, called the "Accumulated IGP Metric Attribute", or "AIGP
+   attribute", and specify the procedures for using it.
+
+   The specified procedures prevent the AIGP attribute from "leaking
+   out" past an administrative domain boundary into the Internet.  We
+   will refer to the set of ASes in a common administrative domain as an
+   "AIGP administrative domain".
+
+   The specified procedures also ensure that the value in the AIGP
+   attribute has been accumulated all along the path from the
+   destination, i.e., that the AIGP attribute does not appear when there
+   are "gaps" along the path where the IGP metric is unknown.
+
+2.  Specification of Requirements
+
+   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.  AIGP Attribute
+
+   The AIGP attribute is an optional, non-transitive BGP path attribute.
+   The attribute type code for the AIGP attribute is 26.
+
+   The value field of the AIGP attribute is defined here to be a set of
+   elements encoded as "Type/Length/Value" (i.e., a set of TLVs).  Each
+   such TLV is encoded as shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 4]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     Type      |         Length                |               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+    ~                                                               ~
+    |                           Value                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
+
+                           Figure 1: AIGP TLV
+
+   -  Type: A single octet encoding the TLV Type.  Only type 1, "AIGP
+      TLV", is defined in this document.  Use of other TLV types is
+      outside the scope of this document.
+
+   -  Length: Two octets encoding the length in octets of the TLV,
+      including the Type and Length fields.  The length is encoded as an
+      unsigned binary integer.  (Note that the minimum length is 3,
+      indicating that no Value field is present.)
+
+   -  Value: A field containing zero or more octets.
+
+   This document defines only a single such TLV, the "AIGP TLV".  The
+   AIGP TLV is encoded as follows:
+
+   -  Type: 1
+
+   -  Length: 11
+
+   -  Value: Accumulated IGP Metric.
+
+      The value field of the AIGP TLV is always 8 octets long, and its
+      value is interpreted as an unsigned 64-bit integer.  IGP metrics
+      are frequently expressed as 4-octet values.  By using an 8-octet
+      field, we ensure that the AIGP attribute can be used to hold the
+      sum of an arbitrary number of 4-octet values.
+
+   When an AIGP attribute is created, it SHOULD contain no more than one
+   AIGP TLV.  However, if it contains more than one AIGP TLV, only the
+   first one is used as described in Sections 3.4 and 4.  In the
+   remainder of this document, we will use the term "value of the AIGP
+   TLV" to mean the value of the first AIGP TLV in the AIGP attribute.
+   Any other AIGP TLVs in the AIGP attribute MUST be passed along
+   unchanged if the AIGP attribute is passed along.
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 5]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+3.1.  Applicability Restrictions and Cautions
+
+   This document only considers the use of the AIGP attribute in
+   networks where each router uses tunneling of some sort to deliver a
+   packet to its BGP next hop.  Use of the AIGP attribute in other
+   scenarios is outside the scope of this document.
+
+   If a Route Reflector supports the AIGP attribute but some of its
+   clients do not, then the routing choices that result may not all
+   reflect the intended routing policy.
+
+3.2.  Handling a Malformed AIGP Attribute
+
+   When receiving a BGP Update message containing a malformed AIGP
+   attribute, the attribute MUST be treated exactly as if it were an
+   unrecognized non-transitive attribute.  That is, it "MUST be quietly
+   ignored and not passed along to other BGP peers" (see [BGP], Section
+   5).  This is equivalent to the "attribute discard" action specified
+   in [BGP-ERROR].
+
+   Note that an AIGP attribute MUST NOT be considered to be malformed
+   because it contains more than one TLV of a given type or because it
+   contains TLVs of unknown types.
+
+   If a BGP path attribute is received that has the AIGP attribute
+   codepoint but also has the transitive bit set, the attribute MUST be
+   considered to be a malformed AIGP attribute and MUST be discarded as
+   specified in this section.
+
+   If an AIGP attribute is received and its first AIGP TLV contains the
+   maximum value 0xffffffffffffffff, the attribute SHOULD be considered
+   to be malformed and SHOULD be discarded as specified in this section.
+   (Since the TLV value cannot be increased any further, it is not
+   useful for metric-based path selection.)
+
+3.3.  Restrictions on Sending/Receiving
+
+   An implementation that supports the AIGP attribute MUST support a
+   per-session configuration item, AIGP_SESSION, that indicates whether
+   the attribute is enabled or disabled for use on that session.
+
+   -  For Internal BGP (IBGP) sessions, and for External BGP (EBGP)
+      sessions between members of the same BGP Confederation
+      [BGP-CONFED], the default value of AIGP_SESSION SHOULD be
+      "enabled".
+
+   -  For all other External BGP (EBGP) sessions, the default value of
+      AIGP_SESSION MUST be "disabled".
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 6]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   The AIGP attribute MUST NOT be sent on any BGP session for which
+   AIGP_SESSION is disabled.
+
+   If an AIGP attribute is received on a BGP session for which
+   AIGP_SESSION is disabled, the attribute MUST be treated exactly as if
+   it were an unrecognized non-transitive attribute.  That is, it "MUST
+   be quietly ignored and not passed along to other BGP peers" (see
+   [BGP], Section 5).  However, the fact that the attribute was received
+   SHOULD be logged (in a rate-limited manner).
+
+3.4.  Creating and Modifying the AIGP Attribute
+
+3.4.1.  Originating the AIGP Attribute
+
+   An implementation that supports the AIGP attribute MUST support a
+   configuration item, AIGP_ORIGINATE, that enables or disables its
+   creation and attachment to routes.  The default value of
+   AIGP_ORIGINATE MUST be "disabled".
+
+   A BGP speaker MUST NOT add the AIGP attribute to any route whose path
+   leads outside the AIGP administrative domain to which the BGP speaker
+   belongs.  When the AIGP attribute is used, changes in IGP routing
+   will directly impact BGP routing.  Attaching the AIGP attribute to
+   customer routes, Internet routes, or other routes whose paths lead
+   outside the infrastructure of a particular AIGP administrative domain
+   could result in BGP scaling and/or thrashing problems.
+
+   The AIGP attribute may be added only to routes that satisfy one of
+   the following conditions:
+
+   -  The route is a static route, not leading outside the AIGP
+      administrative domain, that is being redistributed into BGP;
+
+   -  The route is an IGP route that is being redistributed into BGP;
+
+   -  The route is an IBGP-learned route whose AS_PATH attribute is
+      empty; or
+
+   -  The route is an EBGP-learned route whose AS_PATH contains only
+      ASes that are in the same AIGP administrative domain as the BGP
+      speaker.
+
+   A BGP speaker R MUST NOT add the AIGP attribute to any route for
+   which R does not set itself as the next hop.
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 7]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the
+   routes of a particular IGP that are redistributed into BGP" (where "a
+   particular IGP" might be OSPF or IS-IS).  Other policies determining
+   when and whether to originate an AIGP attribute are also possible,
+   depending on the needs of a particular deployment scenario.
+
+   When originating an AIGP attribute for a BGP route to address prefix
+   P, the value of the AIGP TLV is set according to policy.  There are a
+   number of useful policies, some of which are in the following list:
+
+   -  When a BGP speaker R is redistributing into BGP an IGP route to
+      address prefix P, the IGP will have computed a distance from R to
+      P.  This distance MAY be assigned as the value of the AIGP TLV.
+
+   -  A BGP speaker R may be redistributing into BGP a static route to
+      address prefix P, for which a distance from R to P has been
+      configured.  This distance MAY be assigned as the value of the
+      AIGP TLV.
+
+   -  A BGP speaker R may have received and installed a BGP-learned
+      route to prefix P, with next hop N.  Or it may be redistributing a
+      static route to P, with next hop N.  Then:
+
+      *  If R has an IGP route to N, the IGP-computed distance from R to
+         N MAY be used as the value of the AIGP TLV of the route to P.
+
+      *  If R has a BGP route to N, and an AIGP TLV attribute value has
+         been computed for that route (see Section 3.4.3), that value
+         MAY be used as the AIGP TLV value of the route to P.
+
+3.4.2.  Modifications by the Originator
+
+   If BGP speaker R is the originator of the AIGP attribute of prefix P,
+   and the distance from R to P changes at some point, R SHOULD issue a
+   new BGP update containing the new value of the AIGP TLV of the AIGP
+   attribute.  (Here we use the term "distance" to refer to whatever
+   value the originator assigns to the AIGP TLV, however it is computed;
+   see Section 3.4.1.) However, if the difference between the new
+   distance and the distance advertised in the AIGP TLV is less than a
+   configurable threshold, the update MAY be suppressed.
+
+3.4.3.  Modifications by a Non-Originator
+
+   Suppose a BGP speaker R1 receives a route with an AIGP attribute
+   whose value is A and with a next hop whose value is R2.  Suppose also
+   that R1 is about to redistribute that route on a BGP session that is
+   enabled for sending/receiving the attribute.
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 8]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   If R1 does not change the next hop of the route, then R1 MUST NOT
+   change the AIGP attribute value of the route.
+
+   In all the computations discussed in this section, the AIGP value
+   MUST be capped at its maximum unsigned value 0xffffffffffffffff.
+   Increasing the AIGP value MUST NOT cause the value to wrap around.
+
+   Suppose R1 changes the next hop of the route from R2 to R1.  If R1's
+   route to R2 is either (a) an IGP-learned route or (b) a static route
+   that does not require recursive next hop resolution, then R1 MUST
+   increase the value of the AIGP TLV by adding to A the distance from
+   R1 to R2.  This distance is either the IGP-computed distance from R1
+   to R2 or some value determined by policy.  However, A MUST be
+   increased by a non-zero amount.
+
+   It is possible that R1 and R2 above are EBGP neighbors and that there
+   is a direct link between them on which no IGP is running.  Then, when
+   R1 changes the next hop of a route from R2 to R1, the AIGP TLV value
+   MUST be increased by a non-zero amount.  The amount of the increase
+   SHOULD be such that it is properly comparable to the IGP metrics.
+   For example, if the IGP metric is a function of latency, then the
+   amount of the increase should be a function of the latency from R1 to
+   R2.
+
+   Suppose R1 changes the next hop of the route from R2 to R1 and R1's
+   route to R2 is either (a) a BGP-learned route or (b) a static route
+   that requires recursive next-hop resolution.  Then, the AIGP TLV
+   value needs to be increased in several steps, according to the
+   following procedure.  (Note that this procedure is ONLY used when
+   recursive next-hop resolution is needed.)
+
+   1.  Let Xattr be the new AIGP TLV value.
+
+   2.  Initialize Xattr to A.
+
+   3.  Set XNH to R2.
+
+   4.  Find the route to XNH.
+
+   5.  If the route to XNH does not require recursive next-hop
+       resolution, get the distance D from R1 to XNH.  (Note that this
+       condition cannot be satisfied the first time through this
+       procedure.)  If D is above a configurable threshold, set the AIGP
+       TLV value to Xattr+D.  If D is below a configurable threshold,
+       set the AIGP TLV value to Xattr.  In either case, exit this
+       procedure.
+
+
+
+
+
+Mohapatra, et al.            Standards Track                    [Page 9]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   6.  If the route to XNH is a BGP-learned route that does NOT have an
+       AIGP attribute, then exit this procedure and do not pass on any
+       AIGP attribute.  If the route has an AIGP attribute without an
+       AIGP TLV, then the AIGP attribute MAY be passed along unchanged.
+
+   7.  If the route to XNH is a BGP-learned route that has an AIGP TLV
+       value of Y, then set Xattr to Xattr+Y and set XNH to the next hop
+       of this route.  (The intention here is that Y is the AIGP TLV
+       value of the route as it was received by R1, without having been
+       modified by R1.)
+
+   8.  Go to step 4.
+
+   The AIGP TLV value of a given route depends on (a) the AIGP TLV
+   values of all the next hops that are recursively resolved during this
+   procedure, and (b) the IGP distance to any next hop that is not
+   recursively resolved.  Any change due to (a) in any of these values
+   MUST trigger a new AIGP computation for that route.  Whether a change
+   due to (b) triggers a new AIGP computation depends upon whether the
+   change in IGP distance exceeds a configurable threshold.
+
+   If the AIGP attribute is carried across several ASes, each with its
+   own IGP domain, it is clear that these procedures are unlikely to
+   give a sensible result if the IGPs are different (e.g., some OSPF and
+   some IS-IS) or if the meaning of the metrics is different in the
+   different IGPs (e.g., if the metric represents bandwidth in some IGP
+   domains but represents latency in others).  These procedures also are
+   unlikely to give a sensible result if the metric assigned to inter-AS
+   BGP links (on which no IGP is running) or to static routes is not
+   comparable to the IGP metrics.  All such cases are outside the scope
+   of the current document.
+
+4.  Decision Process
+
+   Support for the AIGP attribute involves several modifications to the
+   tie-breaking procedures of the BGP "phase 2" decision described in
+   [BGP], Section 9.1.2.2.  These modifications are described in
+   Sections 4.1 and 4.2.
+
+   In some cases, the BGP decision process may install a route without
+   executing any tie-breaking procedures.  This may happen, e.g., if
+   only one route to a given prefix has the highest degree of preference
+   (as defined in [BGP], Section 9.1.1).  In this case, the AIGP
+   attribute is not considered.
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 10]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   In other cases, some routes may be eliminated before the tie-breaking
+   procedures are invoked, e.g., routes with AS-PATH attributes
+   indicating a loop or routes with unresolvable next hops.  In these
+   cases, the AIGP attributes of the eliminated routes are not
+   considered.
+
+4.1.  When a Route Has an AIGP Attribute
+
+   Assuming that the BGP decision process invokes the tie-breaking
+   procedures, the procedures in this section MUST be executed BEFORE
+   any of the tie-breaking procedures described in [BGP], Section
+   9.1.2.2 are executed.
+
+   If any routes have an AIGP attribute containing an AIGP TLV, remove
+   from consideration all routes that do not have an AIGP attribute
+   containing an AIGP TLV.
+
+   If router R is considering route T, where T has an AIGP attribute
+   with an AIGP TLV,
+
+   -  then R must compute the value A, defined as follows: set A to the
+      sum of (a) T's AIGP TLV value and (b) the IGP distance from R to
+      T's next hop.
+
+   -  remove from consideration all routes that are not tied for the
+      lowest value of A.
+
+4.2.  When the Route to the Next Hop Has an AIGP Attribute
+
+   Suppose that a given router R1 is comparing two BGP-learned routes,
+   such that either:
+
+   -  the two routes have equal AIGP TLV values, or else
+
+   -  neither of the two routes has an AIGP attribute containing an AIGP
+      TLV.
+
+   The BGP decision process as specified in [BGP] makes use, in its tie-
+   breaking procedures, of "interior cost", defined as follows:
+
+      interior cost of a route is determined by calculating the metric
+      to the NEXT_HOP for the route using the Routing Table.
+
+   This document replaces the "interior cost" tie breaker of [BGP] with
+   a tie breaker based on the "AIGP-enhanced interior cost".  Suppose
+   route T has a next hop of N.  The "AIGP-enhanced interior cost" from
+   node R1 to node N is defined as follows:
+
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 11]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+   -  Let R2 be the BGP next hop of the route to N after all recursive
+      resolution of the next hop is done.  Let m be the IGP distance (or
+      in the case of a static route, the configured distance) from R1 to
+      R2.
+
+   -  If the installed route to N has an AIGP attribute with an AIGP
+      TLV, set A to its AIGP TLV value, computed according to the
+      procedure in Section 3.4.3.
+
+   -  If the installed route to N does not have an AIGP attribute with
+      an AIGP TLV, set A to 0.
+
+   -  The "AIGP-enhanced interior cost" of route T is the quantity A+m.
+
+   The "interior cost" tie breaker of [BGP] is then applied, using the
+   "AIGP-enhanced interior cost" instead of the "interior cost" as
+   defined in [BGP].
+
+5.  Deployment Considerations
+
+   -  Using the AIGP attribute to achieve a desired routing policy will
+      be more effective if each BGP speaker can use it to choose from
+      among multiple routes.  Thus, it is highly recommended that the
+      procedures of [BESTEXT] and [ADD-PATH] be used in conjunction with
+      the AIGP attribute.
+
+   -  If a Route Reflector does not pass all paths to its clients, then
+      it will tend to pass the paths for which the IGP distance from the
+      Route Reflector itself to the next hop is smallest.  This may
+      result in a non-optimal choice by the clients.
+
+   -  When the procedures of this document are deployed, it must be
+      understood that frequent changes of the IGP distance towards a
+      certain prefix may result in equally frequent transmission of BGP
+      updates about that prefix.
+
+   -  In an IGP deployment, there are certain situations in which a
+      network link may be temporarily assigned a metric whose value is
+      the maximum metric value (or close to the maximum) for that IGP.
+      This is known as "costing out" the link.  A link may be "costed
+      out" to deflect traffic from the link before the link is actually
+      brought down or to discourage traffic from using a link until all
+      the necessary state for that link has been set up (e.g.,
+      [LDP-IGP-SYNC]).  This assumes, of course, that a path containing
+      a "costed out" link will have a total distance that is larger than
+      any alternate path within the same IGP area; in that case, the
+      normal IGP decision process will choose the path that does not
+      contain the "costed out" link.
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 12]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+      Costing out a link will have the same effect on BGP routes that
+      carry the AIGP attribute.  The value of the AIGP TLV will be
+      larger for a route (to a given prefix) that contains a "costed
+      out" link than for a route (to the same prefix) that does not.  It
+      must be understood, though, that a route that carries an AIGP
+      attribute will be preferred to a route that does not, no matter
+      what the value of the AIGP TLV is.  This is similar to the
+      behavior in, e.g., an OSPF area, where an intra-area route is
+      preferred to an inter-area or external route, even if the intra-
+      area route's distance is large.
+
+6.  IANA Considerations
+
+   IANA has assigned the codepoint 26 in the "BGP Path Attributes"
+   registry to the AIGP attribute.
+
+   IANA has created a registry for "BGP AIGP Attribute Types".  The Type
+   field consists of a single octet, with possible values from 1 to 255.
+   (The value 0 is "Reserved".)  The registration procedure for this
+   registry is "Standards Action".  Type 1 is defined as "AIGP" and
+   refers to this document.
+
+7.  Security Considerations
+
+   The spurious introduction, through error or malfeasance, of an AIGP
+   attribute could result in the selection of paths other than those
+   desired.
+
+   Improper configuration on both ends of an EBGP connection could
+   result in an AIGP attribute being passed from one service provider to
+   another.  This would likely result in an unsound selection of paths.
+
+8.  Acknowledgments
+
+   The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas,
+   Ron Bonica, Bruno Decraene, Brian Dickson, Clarence Filsfils, Sue
+   Hares, Anoop Kapoor, Pratima Kini, Thomas Mangin, Robert Raszuk,
+   Yakov Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Shyam
+   Sethuram, and Ilya Varlashkin for their input.
+
+
+
+
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 13]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+9.  References
+
+9.1.  Normative Reference
+
+   [BGP]          Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+                  Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+                  2006.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [ADD-PATH]     Walton, D., Retana, A., Chen, E., and J. Scudder,
+                  "Advertisement of Multiple Paths in BGP", Work in
+                  Progress, October 2013.
+
+   [BESTEXT]      Marques, P., Fernando, R., Mohapatra, P., and H.
+                  Gredler, "Advertisement of the best external route in
+                  BGP", Work in Progress, January 2012.
+
+   [BGP-CONFED]   Traina, P., McPherson, D., and J. Scudder, "Autonomous
+                  System Confederations for BGP", RFC 5065, August 2007.
+
+   [BGP-ERROR]    Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
+                  "Revised Error Handling for BGP UPDATE Messages", Work
+                  in Progress, June 2014.
+
+   [LDP-IGP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP
+                  Synchronization", RFC 5443, March 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 14]
+
+RFC 7311              AIGP Metric Attribute for BGP          August 2014
+
+
+Authors' Addresses
+
+   Pradosh Mohapatra
+   Sproute Networks
+
+   EMail: mpradosh@yahoo.com
+
+
+   Rex Fernando
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA  95134
+   US
+
+   EMail: rex@cisco.com
+
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA, 01719
+   US
+
+   EMail: erosen@cisco.com
+
+
+   James Uttaro
+   AT&T
+   200 S. Laurel Avenue
+   Middletown, NJ 07748
+   US
+
+   EMail: uttaro@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohapatra, et al.            Standards Track                   [Page 15]
+