--- 1/draft-ietf-idr-restart-01.txt	2006-02-04 23:31:19.000000000 +0100
+++ 2/draft-ietf-idr-restart-02.txt	2006-02-04 23:31:19.000000000 +0100
@@ -1,19 +1,20 @@
+
 Network Working Group          Srihari Ramachandra (Procket Networks)
 Internet Draft                       Yakov Rekhter (Juniper Networks)
-Expiration Date: January 2002         Rex Fernando (Procket Networks)
+Expiration Date: July 2002            Rex Fernando (Procket Networks)
                                       John G. Scudder (Cisco Systems)
                                          Enke Chen (Redback Networks)
 
                    Graceful Restart Mechanism for BGP
 
-                     draft-ietf-idr-restart-01.txt
+                     draft-ietf-idr-restart-02.txt
 
 1. Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
@@ -163,24 +164,24 @@
 
        The most significant bit is defined as the Forwarding State
        bit which can be used to indicate if the forwarding state for
        the <AFI, Sub-AFI> has indeed been preserved during the previous
        BGP restart. When set (value 1), the bit indicates that the
        forwarding state has been preserved.
 
        The remaining bits are reserved.
 
    The advertisement of this capability by a BGP speaker also implies
-   that it will generate the End-of-RIB marker upon completion of its
-   initial routing update to its peer.  The value of the "Restart Time"
-   field is irrelevant in the case that the capability does not carry
-   any <AFI, Sub-AFI>.
+   that it will generate the End-of-RIB marker (for all address families
+   exchanged) upon completion of its initial routing update to its peer.
+   The value of the "Restart Time" field is irrelevant in the case that
+   the capability does not carry any <AFI, Sub-AFI>.
 
 6. Operation
 
    A BGP speaker may advertise the Graceful Restart Capability for an
    address family to its peer only if it has the ability to preserve its
    forwarding state for the address family when BGP restarts.
 
    Even if the speaker does not have the ability to preserve its
    forwarding state for any address family during BGP restart, it is
    still recommended that the speaker advertise the Graceful Restart
@@ -222,23 +223,24 @@
    of the OPEN message.  Unless allowed via configuration, the
    "Forwarding State" bit for an address family in the capability can be
    set only if the forwarding state has indeed been preserved for that
    address family during the restart.
 
    Once the session between the Restarting Speaker and the Receiving
    Speaker is re-established, the Restarting Speaker will receive and
    process BGP messages from its peers. However, it shall defer route
    selection for an address family until it receives the End-of-RIB
    marker from all its peers (excluding the ones with the "Restart
-   State" bit set in the received capability). It is noted that prior to
-   route selection, the speaker has no routes to advertise to its peers
-   and no routes to update the forwarding state.
+   State" bit set in the received capability and excluding the ones
+   which do not advertise the graceful restart capability).  It is noted
+   that prior to route selection, the speaker has no routes to advertise
+   to its peers and no routes to update the forwarding state.
 
    In situations where both IGP and BGP have restarted, it might be
    advantageous to wait for IGP to converge before the BGP speaker
    performs route selection.
 
    After the BGP speaker performs route selection, the forwarding state
    of the speaker shall be updated and any previously marked stale
    information shall be removed. The Adj-RIB-Out can then be advertised
    to its peers. Once the initial update is complete for an address
    family (including the case that there is no routing update to send),