Graceful Restart Mechanism for BGP
draft-ietf-idr-restart-13

INTRODUCTION, paragraph 0:


        Pekka Savola raised some concerns on June 14 on the tcpm list
        (where the TCP Simple AuthenticationOption was discussed). Are
        these valid? (Also, what is " GR helper mode?" The draft doesn't
        mention it.)
 
        From Pekka'e email:
        Enabling Graceful Restart can cause black holes and loops under
        valid and rather common scenarios (e.g., power loss, forwarding
        plane crash).  It has been designed in such a fashion that it
        cannot be enabled by default due to these bad effects, the users
        must know what they are doing. [1] As such, major router vendors
        do not enable graceful restart by default.  It is not clear to me
        whether major router vendors enable graceful restart helper-mode by
        default.  Helper mode is required for GR to be used.
        [1] I made an IETF Last call comment about this.  The text was
        improved slightly in -11 but as the applicability and usefulness
        of GR seemed to be felt to be out of scope from interoperability
        perspective, these issues were not further discussed.


INTRODUCTION, paragraph 12:

>    This document describes a mechanism for BGP that would help minimize
>    the negative effects on routing caused by BGP restart. An End-of-RIB
>    marker is specified and can be used to convey routing convergence
>    information.  A new BGP capability, termed "Graceful Restart
>    Capability", is defined which would allow a BGP speaker to express
>    its ability to preserve forwarding state during BGP restart. Finally,
>    procedures are outlined for temporarily retaining routing information
>    across a TCP transport reset.

        The term "reset" has a specific meaning in TCP (sending a segment
        with the RST flag set). I think GR is also applicable to TCP
        connections that terminate without an RST. Wording should be changed
        to this effect; also elsewhere in the text.


Section 3., paragraph 1:

>    An UPDATE message with no reachable NLRI and empty withdrawn NLRI is
>    specified as the End-Of-RIB Marker that can be used by a BGP speaker
>    to indicate to its peer the completion of the initial routing update
>    after the session is established. For IPv4 unicast address family,
>    the End-Of-RIB Marker is an UPDATE message with the minimum length
>    [BGP-4].  For any other address family, it is an UPDATE message that
>    contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no
>    withdrawn routes for that <AFI, SAFI>.

        Nit: Expand NLRI, RIB, AFI, SAFI, etc.
        (Or point to document that defines terminology.)

Section 4:

Capability value: Consists of the "Restart Flags" field, "Restart
      Time" field, and zero or more of the tuples <AFI, SAFI, Flags for
      address family> as follows:

As the Capability value field is restricted to at maximum 255 octets. I think one should specify what the maximum number of <AFI, SAFI, Flags for address family> triplets that the capability option can hold. I assume the number of normally used triplets is small so that the limit of 63 triplets is not a problem. I would suggest changing the above value definition to:

Capability value: Consists of the "Restart Flags" field, "Restart
      Time" field, and zero to 63 of the tuples <AFI, SAFI, Flags for
      address family> as follows:

First, as mentioned, tcpmd5 is adequate protection.  However there are
a lot of environments where this is not available.  I think another
solution would be to provide configuration of the new TCP behavior on
a per-peer basis.  I realize that this capability is not all that
useful without the new TCP behavior.  I'm willing to look at other
proposed mechanisms for protecting against this attack once the
security consideration is updated to describe the attack in sufficient
detail that I can analyze the risk.

Do the changes to the finite state machine mean this updates RFC 4271?