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

From: "John G. Scudder" <[email-masked]>
Date: Thu, 30 Mar 2006 12:05:22 -0500

Bill,

I'm equally sorry for the delay in responding! 
I'll just address your FSM comments.

At 11:13 AM -0400 8/12/05, Bill Fenner wrote:
>I'm sorry that these are so late, especially since I found only a couple of
>concerns.

...

>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?

In short, no, we don't want to wait for an OPEN. 
You can determine that you've got a restarting 
connection simply by inspecting the IP address of 
the remote system.  This doesn't seem 
exceptionally well spelled out in the base FSM, 
but if you read between the lines vigorously 
enough it's there.  More importantly, it's true 
in practice.

So, I'd say the draft is correct in spirit, but 
in reviewing it I see that the words are kind of 
broken (in part because the base spec changed 
since we wrote the draft, and in part because as 
you point out TcpConnectionFails has more baggage 
than we wanted).

Here's a proposal for wording that matches the 
FSM of RFC 4271.  It kind of mashes a piece of 
the Idle state into the handling of a TCP 
connection arrival (Events 16 and 17) in 
Established.  It would be possible to introduce 
yet another state instead, but I see no 
particular benefit to doing so (especially since 
it'd be one of those zero-second transient 
states).

    The specific state machine modifications to [BGP-4] Section 8.2.2 are
    as follows. 
   
    In the Idle state, make the following change.  Replace this text:
   
         - initializes all BGP resources for the peer connection,

    with
   
         - initializes all BGP resources for the peer connection,
           other than those resources required in order to retain routes
           according to section 7.2 of this (Graceful Restart)
           specification,
   
    In the Established state, make the following changes.
   
    Replace this text:

       In response to an indication that the TCP connection is
       successfully established (Event 16 or Event 17), the second
       connection SHALL be tracked until it sends an OPEN message.

    with

       If the Graceful Restart capability with one or more AFI/SAFI has
       not been received for the session, then in response to an
       indication that a TCP connection is successfully established
       (Event 16 or Event 17), the second connection SHALL be tracked
       until it sends an OPEN message.

       However, if the Graceful Restart capability with one or more
       AFI/SAFI has been received for the session, then in response to
       Event 16 or Event 17 the local system:
      
         - retains all routes associated with this connection according
           to section 7.2 of this (Graceful Restart) specification,

         - releases all other BGP resources,

         - drops the TCP connection associated with the ESTABLISHED
           session,

         - initializes all BGP resources for the peer connection,
           other than those required in order to retain routes according
           to section 7.2,

         - sets ConnectRetryCounter to zero,

         - starts the ConnectRetryTimer with the initial value,

         - changes its state to Connect.

    Replace this text:

       If the local system receives a NOTIFICATION message (Event 24 or
       Event 25) or a TcpConnectionFails (Event 18) from the underlying
       TCP, the local system:

         - 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.

    with
   
       If the local system receives a NOTIFICATION message (Event 24 or
       Event 25) or if the Graceful Restart capability with one or more
       AFI/SAFI has not been received for the session and the local
       system receives a TcpConnectionFails (Event 18) from the
       underlying TCP, the local system:

         - 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.

       However, if the Graceful Restart capability with one or more
       AFI/SAFI has been received for the session and the local system
       receives a TcpConnectionFails (Event 18) from the underlying TCP,
       the local system:
      
         - sets the ConnectRetryTimer to zero,

         - retains all routes associated with this connection according
           to section 7.2 of this (Graceful Restart) specification,

         - releases all other BGP resources,

         - drops the TCP connection,

         - increments the ConnectRetryCounter by 1,

         - changes its state to Idle.

As a reminder, the idea is for this to correspond 
to what the prose in section 7.2 of the draft 
says, to wit:

    When the Restarting Speaker restarts, the Receiving Speaker may or
    may not detect the termination of the TCP session with the Restarting
    Speaker, depending on the underlying TCP implementation, whether or
    not [BGP-AUTH] is in use, and the specific circumstances of the
    restart.  In case it does not detect the TCP reset and still
    considers the BGP session as being established, it SHALL treat the
    subsequent open connection from the peer as an indication of TCP
    reset and act accordingly (when the Graceful Restart Capability has
    been received from the peer). See Section 8 for a description of this
    behavior in terms of the BGP finite state machine.

    "Acting accordingly" in this context means that the previous TCP
    session SHOULD be closed, and the new one retained.  Note that this
    behavior differs from the default behavior, as specified in [BGP-4]
    section 6.8.  Since the previous connection is considered to be
    reset, no NOTIFICATION message should be sent -- the previous TCP
    session is simply closed.

    When the Receiving Speaker detects TCP reset for a BGP session with a
    peer that has advertised the Graceful Restart Capability, it SHALL
    retain the routes received from the peer for all the address families
    that were previously received in the Graceful Restart Capability, and
    SHALL mark them as stale routing information. To deal with possible
    consecutive restarts, a route (from the peer) previously marked as
    stale SHALL be deleted. The router SHOULD NOT differentiate between
    stale and other routing information during forwarding.

and so on.

Regards,

--John

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