Subject: [Idr] AD Review comments on draft-ietf-idr-restart

From: Bill Fenner <[email-masked]>
Date: Fri, 12 Aug 2005 11:13:49 -0400

I'm sorry that these are so late, especially since I found only a couple of
concerns.

1. Very minor - the document needs an IANA Considerations section,
probably just one sentence asking to change the reference for
64 from [Chen] to this document.

2. There's a new timer introduced (upper bound on the amount of time a
router defers its route selection) which MUST be supported but there's
no guidance on a default value or whether it should be used at all
by default.  (It may be easiest to just say that it SHOULD not be
configured to be used by default, and the upper bound is left to be
chosen by configuration by the user; if there's some guidance as to
how to set it that'd be even better)

3. In the description of the state machine modification, I'm concerned
that the literal interpretation of

      If the Graceful Restart capability with one or more AFI/SAFI has
      been received for the session, then TcpConnectionConfirmed (Event
      17) is treated as TcpConnectionFails (Event 18).

is that the new connection is torn down -- in Established state,
the FSM says that receiving a TcpConnectionFails means

              - sets the ConnectRetryTimer to zero,
              - deletes all routes associated with this connection,
              - releases all the BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCounter by 1,
              - changes its state to Idle.

and clearly in graceful restart you don't want to do most of those things.

In fact, you don't know that it's a restarting connection until you've
gotten the OPEN on the new connection, right?  You probably want to
be modifying the "If a valid OPEN message (BGPOpen (Event 19)) is received"
condition in the Established state of the FSM?

  Bill

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Paul Jakma <[email-masked]>
Date: Fri, 12 Aug 2005 18:10:34 +0100 (IST)

On Fri, 12 Aug 2005, Bill Fenner wrote:

> In fact, you don't know that it's a restarting connection until 
> you've gotten the OPEN on the new connection, right?

A concern here, is that the GR peer assumes forwarding will stay up. 
So NOTIFY/CEASE now becomes (between GR negotiated peers):

 	"I'm shutting down (implicit: assume I keep forwarding in place)"

However, in light of other discussions, that assumption presents a 
problem for possible future IDR work that intends to try gracefully 
handle shutdown of forwarding - ie the ability to say:

 	"I'm shutting down"

without any assumptions is lost between GR peers.

(The assumption is bounded by timers, but that introduces delays for 
any graceful full-shutdown work..)

It /might/ be an idea to require GR peers to explicitely signal their 
intent to keep forwarding up during restart, or even just:

 	"I'm restarting"

And let this new CEASE sub-code carry the assumption (or maybe 
ADMIN_RESET would suffice?)

(No idea whether it's a good idea to use sub-codes for anything other 
than informational content).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who is flogged by fate and laughs the louder is a masochist.