--- 1/draft-ietf-idr-aigp-17.txt	2014-04-28 07:14:21.591816548 -0700
+++ 2/draft-ietf-idr-aigp-18.txt	2014-04-28 07:14:21.623817323 -0700
@@ -1,26 +1,26 @@
 
 Network Working Group                                  Pradosh Mohapatra
 Internet Draft                                          Cumulus Networks
 Intended Status: Proposed Standard
-Expires: October 8, 2014                                    Rex Fernando
+Expires: October 28, 2014                                   Rex Fernando
                                                            Eric C. Rosen
                                                      Cisco Systems, Inc.
 
                                                             James Uttaro
                                                                      ATT
 
-                                                           April 8, 2014
+                                                          April 28, 2014
 
               The Accumulated IGP Metric Attribute for BGP
 
-                       draft-ietf-idr-aigp-17.txt
+                       draft-ietf-idr-aigp-18.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
@@ -141,38 +141,38 @@
    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
    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.  We will refer to the set of
-   ASes in a common administrative domain as an "AIGP Administrative
-   Domain".
+   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 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
    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.
@@ -206,24 +206,25 @@
 
   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.
+      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 a 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 Section 3.4 and Section 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.
 
 3.1. Applicability Restrictions and Cautions