Graceful Restart Mechanism for BGP
RFC 4724

Note: This ballot was opened for revision 13 and is now closed.

(Ross Callon) Yes

(Bill Fenner) Yes

(David Kessens) Yes

Comment (2006-06-21 for -)
No email
send info
Comments from the Ops directorate by Simon Leinen:

This is a BGP extension that allows forwarding to continue while a BGP
speaker is restarted, and BGP to orderly resume when the session comes
up again.  The changes to BGP are fairly minimal, and well motivated.
The document is well written and looks like an excellent basis for
interoperable implementations.  It also covers possible operational
issues.  I believe this is a useful addition to our toolset.

(Mark Townsley) (was Discuss) Yes

(Jari Arkko) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-06-21 for -)
No email
send info
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.)

(Ted Hardie) No Objection

Comment (2006-06-19 for -)
No email
send info
Do the changes to the finite state machine mean this updates RFC 4271?

(Sam Hartman) (was Discuss) No Objection

Comment (2006-06-22)
No email
send info
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.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Magnus Westerlund (was Discuss, No Objection) No Objection

Comment (2006-06-20)
No email
send info
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: