Subject: Re: [Idr] WG Last Call on BGP Graceful Restart

From: "Tom Petch" <[email-masked]>
Date: Fri, 9 Jul 2004 18:43:45 +0100

A bit late I am afraid but ...

I do think some aspects of this lack clarity and could do with more precise
and consistent wording in order to increase the likelihood of compatible
implementations..

1) The End-of-RIB marker is a good thing, the I-D keeps saying so but ...If
there has been no exchange of Graceful Restart Capability, can it still be
sent? SHOULD NOT it? or what?  And if there has been an exchange, again
SHOULD it, MUST it?

Section 5 says it is a good thing with no qualification; section 7 talks of
the 'intention' of sending the marker after a GRC exchange (not our normal
SHOULD/MUST language); section 6 says the procedures for the Receiving
Speaker are defined in section 6.2 (actually 7.2) and here there is a SHALL
but this only covers the restarting case; what about the initial startup -
SHALL, SHOULD?

2) FSM
I do not understand the pairing of TcpConnection_Valid (Event 14) with
Tcp_CR_Acked (Event 16); normally it is TcpConnectionConfirmed (Event 17)
that is paired with Event 14.  Event 14 is the first sign of a remote
speaker trying to talk to us; Event 17 is a later step in that process.
Event 16 is the end result of us initiating a connection to the remote
speaker.

So we negotiate Graceful Restart capability for at least one AFI/SAFI, lose
the TCP connection and do not notice, miss Event 14 because our engine does
not generate it, get Event 17 and this is the first indication that we are
about to become a Receiving Speaker; in response, we terminate the session
killing all Graceful Restart.  What have I got wrong?

3) forwarding state is used in several places and is never clearly defined;
I think it should be.  In 7.1 it talks of

'the forwarding state for the BGP routes in the Loc-RIB, and SHALL mark
them as stale'

suggesting that forwarding state is a set of flags, of which one is stale,
in Loc-RIB; elsewhere it seems to be the Loc-RIB (but not the forwarding
table?).  If all we are doing is unicast BGP4, with no extensions, it
probably does not matter but as BGP more complex, I believe it will.

4) In 7.1 we have
' When the Restarting Speaker restarts,  possible it SHOULD retain, if
possible, '

My first thought was that this is one too many 'possible's; on reflection,
it is two too many; I do not believe we should be qualifying SHOULD at
all - it is defined in RFC2119 and it is not for us to vary that.

Tom Petch

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 17 June 2004 20:04
Subject: [Idr] WG Last Call on BGP Graceful Restart

>Folks,
>
>This is to start the WG Last Call on advancing
draft-ietf-idr-restart-10.txt
>to a Proposed Standard. Since the the previous version of this document
>already went through the WG Last Call, the main focus of this Last
>Call is the new text on Finite State Machine.
>
>The Last Call ends July 1, 2004.
>
>Yakov.
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

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