draft-ietf-idr-aigp-17.txt   draft-ietf-idr-aigp-18.txt 
Network Working Group Pradosh Mohapatra Network Working Group Pradosh Mohapatra
Internet Draft Cumulus Networks Internet Draft Cumulus Networks
Intended Status: Proposed Standard Intended Status: Proposed Standard
Expires: October 8, 2014 Rex Fernando Expires: October 28, 2014 Rex Fernando
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
James Uttaro James Uttaro
ATT ATT
April 8, 2014 April 28, 2014
The Accumulated IGP Metric Attribute for BGP The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-17.txt draft-ietf-idr-aigp-18.txt
Abstract Abstract
Routing protocols that have been designed to run within a single Routing protocols that have been designed to run within a single
administrative domain ("IGPs") generally do so by assigning a metric administrative domain ("IGPs") generally do so by assigning a metric
to each link, and then choosing as the installed path between two 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 nodes the path for which the total distance (sum of the metric of
each link along the path) is minimized. BGP, designed to provide each link along the path) is minimized. BGP, designed to provide
routing over a large number of independent administrative domains routing over a large number of independent administrative domains
("autonomous systems"), does not make its path selection decisions ("autonomous systems"), does not make its path selection decisions
skipping to change at page 4, line 43 skipping to change at page 4, line 43
each running BGP. There are several reasons why a single each running BGP. There are several reasons why a single
administrative domain may be broken into several ASes (which, in this administrative domain may be broken into several ASes (which, in this
case, are not really "autonomous".) It may be that the existing IGPs 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 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 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 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 policy is desired than can be supported by an IGP. In such
deployments, it can be useful to allow BGP to make its routing deployments, it can be useful to allow BGP to make its routing
decisions based on the IGP metric, so that BGP chooses the "shortest" 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 path between two nodes, even if the nodes are in two different ASes
within that same administrative domain. We will refer to the set of within that same administrative domain.
ASes in a common administrative domain as an "AIGP Administrative
Domain".
There are in fact some implementations that already do something like There are in fact some implementations that already do something like
this, using BGP's MULTI_EXIT_DISC (MED) attribute to carry a value 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 based on IGP metrics. However, that doesn't really provide IGP-like
"shortest path" routing, as the BGP decision process gives priority "shortest path" routing, as the BGP decision process gives priority
to other factors, such as the AS_PATH length. Also, the standard 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 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. properly accumulated so that it covers all the links along the path.
In this document, we define a new optional, non-transitive BGP In this document, we define a new optional, non-transitive BGP
attribute, called the "Accumulated IGP Metric Attribute", or "AIGP attribute, called the "Accumulated IGP Metric Attribute", or "AIGP
attribute", and specify the procedures for using it. attribute", and specify the procedures for using it.
The specified procedures prevent the AIGP attribute from "leaking The specified procedures prevent the AIGP attribute from "leaking
out" past an AIGP administrative domain boundary into the Internet. 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 The specified procedures also ensure that the value in the AIGP
attribute has been accumulated all along the path from the attribute has been accumulated all along the path from the
destination, i.e., that the AIGP attribute does not appear when there destination, i.e., that the AIGP attribute does not appear when there
are "gaps" along the path where the IGP metric is unknown. are "gaps" along the path where the IGP metric is unknown.
3. AIGP Attribute 3. AIGP Attribute
The AIGP Attribute is an optional non-transitive BGP Path Attribute. The AIGP Attribute is an optional non-transitive BGP Path Attribute.
The attribute type code for the AIGP Attribute is 26. The attribute type code for the AIGP Attribute is 26.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
This document defines only a single such TLV, the "AIGP TLV". The This document defines only a single such TLV, the "AIGP TLV". The
AIGP TLV is encoded as follows: AIGP TLV is encoded as follows:
- Type: 1 - Type: 1
- Length: 11 - Length: 11
- Accumulated IGP Metric. - Accumulated IGP Metric.
The value field of the AIGP TLV is always 8 bytes long. IGP The value field of the AIGP TLV is always 8 octets long, and its
metrics are frequently expressed as 4-octet values, and this value is interpreted as an unsigned 64-bit integer. IGP metrics
ensures that the AIGP attribute can be used to hold the sum of an are frequently expressed as 4-octet values. By using an 8-octet
arbitrary number of 4-octet values. field, we ensure that the AIGP attribute can be used to hold the
sum of a arbitrary number of 4-octet values.
When an AIGP attribute is created, it SHOULD contain no more than one 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 AIGP TLV. However, if it contains more than one AIGP TLV, only the
first one is used as described in Section 3.4 and Section 4. In the first one is used as described in Section 3.4 and Section 4. In the
remainder of this document, we will use the term "value of the AIGP 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. 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 Any other AIGP TLVs in the AIGP attribute MUST be passed along
unchanged if the AIGP attribute is passed along. unchanged if the AIGP attribute is passed along.
3.1. Applicability Restrictions and Cautions 3.1. Applicability Restrictions and Cautions
 End of changes. 6 change blocks. 
11 lines changed or deleted 12 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/