draft-ietf-idr-aigp-05.txt   draft-ietf-idr-aigp-06.txt 
Network Working Group Pradosh Mohapatra Network Working Group Pradosh Mohapatra
Internet Draft Rex Fernando Internet Draft Rex Fernando
Intended Status: Proposed Standard Eric C. Rosen Intended Status: Proposed Standard Eric C. Rosen
Expires: September 29, 2011 Cisco Systems, Inc. Expires: December 23, 2011 Cisco Systems, Inc.
James Uttaro James Uttaro
ATT ATT
March 29, 2011 June 23, 2011
The Accumulated IGP Metric Attribute for BGP The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-05.txt draft-ietf-idr-aigp-06.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 5, line 21 skipping to change at page 5, line 21
out" past an AIGP administrative domain boundary into the Internet. out" past an AIGP administrative domain boundary into the Internet.
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 value The attribute type code for the AIGP Attribute is 26.
field of the AIGP Attribute is defined here to be a set of TLVs
(elements encoded as "Type/Length/Value"). However, this document The value field of the AIGP Attribute is defined here to be a set of
defines only a single such TLV, the AIGP TLV, that contains the elements encoded as "Type/Length/Value" (i.e., a set of "TLVs").
Accumulated IGP Metric. The AIGP TLV is encoded as shown in Figure Each such TLV is encoded as shown in Figure 1.
1. An AIGP Attribute MUST NOT contain more than one AIGP TLV.
0 1 2 3 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 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=1 | Length | | | Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| Accumulated IGP Metric | | Value |
| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AIGP Attribute AIGP TLV
Figure 1 Figure 1
- Type: A single octet encoding the AIGP Attribute Type. Only type - Type: A single octet encoding the TLV Type. Only type 1, "AIGP
1 is defined in this document. TLV", is defined in this document.
- Length: Two octets encoding the length in octets of the attribute, - Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an including the type and length fields. The length is encoded as an
unsigned binary integer. unsigned binary integer. (Note that the minimum length is 3,
indicating that no value field is present.)
The length of the AIGP TLV is always 11. - A value field containing zero or more octets.
- Accumulated IGP Metric: For a type 1 AIGP attribute, the value This document defines only a single such TLV, the "AIGP TLV". The
field is always 8 bytes long. IGP metrics are frequently AIGP TLV is encoded as follows:
expressed as 4-octet values, and this ensures that the AIGP
attribute can be used to hold the sum of an arbitrary number of - Type: 1
4-octet values.
- Length: 11
- Accumulated IGP Metric.
The value field of the AIGP TLV is always 8 bytes long. IGP
metrics are frequently expressed as 4-octet values, and this
ensures that the AIGP attribute can be used to hold the sum of an
arbitrary number of 4-octet values.
3.1. Applicability Restrictions and Cautions 3.1. Applicability Restrictions and Cautions
This document only considers the use of the AIGP attribute in This document only considers the use of the AIGP attribute in
networks where each router uses tunneling of some sort to deliver a networks where each router uses tunneling of some sort to deliver a
packet to its BGP next hop. Use of the AIGP attribute in networks packet to its BGP next hop. Use of the AIGP attribute in networks
that do not use tunneling is outside the scope of this document. that do not use tunneling is outside the scope of this document.
If a Route Reflector supports the AIGP attribute, but some of its If a Route Reflector supports the AIGP attribute, but some of its
clients do not, then the routing choices that result may not all clients do not, then the routing choices that result may not all
skipping to change at page 12, line 41 skipping to change at page 12, line 41
The spurious introduction, though error or malfeasance, of an AIGP The spurious introduction, though error or malfeasance, of an AIGP
attribute, could result in the selection of paths other than those attribute, could result in the selection of paths other than those
desired. desired.
Improper configuration on both ends of an EBGP connection could Improper configuration on both ends of an EBGP connection could
result in an AIGP attribute being passed from one service provider to result in an AIGP attribute being passed from one service provider to
another. This would likely result in an unsound selection of paths. another. This would likely result in an unsound selection of paths.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Rajiv Asati, Clarence Filsfils, The authors would like to thank Waqas Alam, Rajiv Asati, Clarence
Robert Raszuk, Yakov Rekhter, Samir Saad, and John Scudder for their Filsfils, Robert Raszuk, Yakov Rekhter, Samir Saad, John Scudder, and
input. Shyam Sethuram for their input.
9. Authors' Addresses 9. Authors' Addresses
Rex Fernando Rex Fernando
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Email: rex@cisco.com Email: rex@cisco.com
Pradosh Mohapatra Pradosh Mohapatra
skipping to change at page 14, line 12 skipping to change at page 14, line 12
[BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S.
Hares, RFC 4271, January 2006. Hares, RFC 4271, January 2006.
11. Informative References 11. Informative References
[ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P. [ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P.
Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr- Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr-
fast-conn-restore-01.txt, March 2011. fast-conn-restore-01.txt, March 2011.
[BESTEXT], "Advertisement of the Best External Route in BGP", P. [BESTEXT], "Advertisement of the Best External Route in BGP", P.
Marques, R. Fernando, E. Chen, P. Mohapatra, draft-ietf-idr-best- Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf-
external-03.txt, March 2011. idr-best-external-04.txt, April 2011.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", S. Bradner, March 1997 Levels.", S. Bradner, March 1997.
 End of changes. 15 change blocks. 
30 lines changed or deleted 36 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/