Graceful Restart Mechanism for BGP
RFC 4724
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Lars Eggert No Objection
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.)
(Bill Fenner; former steering group member) Yes
(David Kessens; former steering group member) Yes
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; former steering group member) (was Discuss) Yes
(Ross Callon; former steering group member) Yes
(Brian Carpenter; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss, No Objection) No Objection
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:
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection
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.
(Ted Hardie; former steering group member) No Objection
Do the changes to the finite state machine mean this updates RFC 4271?