--- 1/draft-ietf-idr-aigp-05.txt 2011-06-23 17:15:23.000000000 +0200 +++ 2/draft-ietf-idr-aigp-06.txt 2011-06-23 17:15:23.000000000 +0200 @@ -1,24 +1,24 @@ Network Working Group Pradosh Mohapatra Internet Draft Rex Fernando Intended Status: Proposed Standard Eric C. Rosen -Expires: September 29, 2011 Cisco Systems, Inc. +Expires: December 23, 2011 Cisco Systems, Inc. James Uttaro ATT - March 29, 2011 + June 23, 2011 The Accumulated IGP Metric Attribute for BGP - draft-ietf-idr-aigp-05.txt + draft-ietf-idr-aigp-06.txt 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 @@ -165,55 +165,61 @@ out" past an AIGP administrative domain boundary into the Internet. 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. 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 TLVs - (elements encoded as "Type/Length/Value"). However, this document - defines only a single such TLV, the AIGP TLV, that contains the - Accumulated IGP Metric. The AIGP TLV is encoded as shown in Figure - 1. An AIGP Attribute MUST NOT contain more than one AIGP TLV. + 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. 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=1 | Length | | + | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ - | Accumulated IGP Metric | - | +-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... - AIGP Attribute + AIGP TLV Figure 1 - - Type: A single octet encoding the AIGP Attribute Type. Only type - 1 is defined in this document. + - Type: A single octet encoding the TLV Type. Only type 1, "AIGP + 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 - 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 - field 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. + This document defines only a single such TLV, the "AIGP TLV". The + AIGP TLV is encoded as follows: + + - Type: 1 + + - 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 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 networks that do not use tunneling 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 @@ -490,23 +497,23 @@ The spurious introduction, though 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 Rajiv Asati, Clarence Filsfils, - Robert Raszuk, Yakov Rekhter, Samir Saad, and John Scudder for their - input. + The authors would like to thank Waqas Alam, Rajiv Asati, Clarence + Filsfils, Robert Raszuk, Yakov Rekhter, Samir Saad, John Scudder, and + Shyam Sethuram for their input. 9. Authors' Addresses Rex Fernando Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 Email: rex@cisco.com Pradosh Mohapatra @@ -532,15 +539,15 @@ [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. Hares, RFC 4271, January 2006. 11. Informative References [ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P. Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr- fast-conn-restore-01.txt, March 2011. [BESTEXT], "Advertisement of the Best External Route in BGP", P. - Marques, R. Fernando, E. Chen, P. Mohapatra, draft-ietf-idr-best- - external-03.txt, March 2011. + Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf- + idr-best-external-04.txt, April 2011. [RFC2119] "Key words for use in RFCs to Indicate Requirement - Levels.", S. Bradner, March 1997 + Levels.", S. Bradner, March 1997.