The Accumulated IGP Metric Attribute for BGP
Extracted elements (24)
BGP does not natively use inter-AS metrics because local distance changes would violate Internet scaling principles if globally propagated, and inter-domain routing policy must not be forced to be revealed or agreed upon across administrative boundaries. The AIGP attribute is scoped to a single AIGP administrative domain to avoid these problems.
The Value field of the AIGP TLV is 8 octets (64-bit unsigned integer) rather than 4 octets to ensure the attribute can hold the sum of an arbitrary number of 4-octet IGP metric values without overflow.
Using MED to carry IGP metrics (as some implementations already do) does not provide true IGP-like shortest path routing because BGP's decision process gives priority to AS_PATH length over MED, and MED does not ensure proper accumulation of IGP metrics along the full path.
Deployment should use best-external route advertisement and ADD-PATH procedures alongside AIGP to allow BGP speakers to choose from multiple routes. Without these, Route Reflectors may pass only paths optimal for themselves, leading to non-optimal choices by clients.
The AIGP attribute is only applicable in networks where each router uses tunneling to deliver packets to the BGP next hop. Use in other scenarios is outside the scope of this document. If a Route Reflector supports AIGP but some clients do not, routing choices may not reflect the intended policy.
The AIGP procedures are unlikely to give sensible results when the attribute crosses multiple IGP domains using different IGP protocols (e.g., OSPF and IS-IS) or when metric semantics differ (bandwidth vs. latency) across domains. Such cross-domain use is outside the scope of this document.
A BGP speaker MUST NOT add the AIGP attribute to any route for which it does not set itself as the next hop.
A malformed AIGP attribute MUST be treated as an unrecognized non-transitive attribute and quietly discarded without passing it to other BGP peers. An attribute is malformed if it has the transitive bit set or if its first AIGP TLV contains the maximum value 0xffffffffffffffff (SHOULD discard).
An AIGP attribute MUST NOT be considered malformed merely because it contains more than one TLV of a given type or contains TLVs of unknown types.
Any change in the recursively-resolved AIGP TLV values along a route's next-hop chain MUST trigger a new AIGP computation for that route.
If R1 does not change the next hop of the route, R1 MUST NOT change the AIGP attribute value. The AIGP value MUST be capped at 0xffffffffffffffff and incrementing MUST NOT cause wrap-around.
Implementations MUST support a configuration item AIGP_ORIGINATE (enabled/disabled) controlling creation and attachment of the AIGP attribute to routes. The default value MUST be 'disabled'.
Implementations MUST support a per-session configuration item AIGP_SESSION (enabled/disabled). For IBGP sessions and EBGP sessions within a BGP Confederation, the default SHOULD be 'enabled'. For all other EBGP sessions, the default MUST be 'disabled'.
The AIGP attribute MUST NOT be sent on any BGP session for which AIGP_SESSION is disabled. If received on a disabled session, it MUST be treated as an unrecognized non-transitive attribute and discarded, though the receipt SHOULD be logged in a rate-limited manner.
The AIGP-based tie-breaking procedures MUST be executed BEFORE any of the standard BGP tie-breaking procedures in RFC 4271 Section 9.1.2.2. Routes without an AIGP TLV are removed from consideration when any routes have an AIGP TLV.
When an AIGP attribute is created, it SHOULD contain no more than one AIGP TLV. If it contains more than one, only the first is used; any additional AIGP TLVs MUST be passed along unchanged.
When R1 changes the next hop from R2 to R1 and R1's route to R2 is an IGP-learned or non-recursive static route, R1 MUST increase the AIGP TLV value by adding the distance from R1 to R2, and the increase MUST be by a non-zero amount.
For AIGP-based path selection, a router R computes value A for each candidate route T as: A = T's AIGP TLV value + IGP distance from R to T's next hop. The route with the lowest A wins; routes not tied for lowest A are removed from consideration.
The AIGP attribute is an optional, non-transitive BGP path attribute with type code 26. Its value field contains a set of TLV elements. Only one TLV type (type 1, the AIGP TLV) is defined in this document.
This document replaces the BGP 'interior cost' tie-breaker with an 'AIGP-enhanced interior cost': for a route with next hop N, this equals the AIGP TLV value of the installed route to N (computed per Section 3.4.3) plus the IGP distance from R1 to the recursively-resolved BGP next hop of N.
When recursive next-hop resolution is needed and R1 changes the next hop, the AIGP TLV value is computed via an iterative procedure: starting from the received value A, accumulate AIGP TLV values along the recursive chain until a non-recursive next hop is reached, then add the IGP distance to that hop.
IANA assigned codepoint 26 in the 'BGP Path Attributes' registry to the AIGP attribute. IANA also created a new 'BGP AIGP Attribute Types' registry with a single-octet Type field (values 1-255; 0 reserved), registration procedure 'Standards Action', with Type 1 defined as 'AIGP'.
Spurious introduction of an AIGP attribute (through error or malfeasance) could result in selection of unintended paths. Improper configuration on both ends of an EBGP connection could allow the AIGP attribute to pass between service providers, resulting in unsound path selection.
The AIGP TLV encoding: Type is 1 octet (value 1), Length is 2 octets (value 11) encoding total TLV length including Type and Length fields, and Value is 8 octets containing the accumulated IGP metric as an unsigned 64-bit integer.