Subject: graceful restart TCP reset discovery (was Re>Are dynamic capabili ties really necessary ...)

From: "Tsillas, Jim" <[email-masked]>
Date: Thu, 11 Jul 2002 15:20:34 -0400

Ben,

You are correct. I was thinking about the case where TCP is
reset due to "fast external fallover". In this case, the
forwarding plane is down and if it stays down for more than
the graceful restart timeout, the receiving speaker resorts to
normal restart.

Sections 6.1 and 6.2 go into good detail on this. The length
of time it takes to determine if TCP has reset is implementation
dependent. One way to detect TCP reset is to look for a new
session for the same peer (since the neighbor will try to
intiate a new session when it restarts). Another way is to rely
on "fast-external-fallover" being turned on. Otherwise you just
have to wait for either the keepalive expiration or the TCP timeout.

There is also an obscure case with some (probably most) TCPs where
the restarting speaker has not yet attempted to open the session but
the receiving speaker attempts to send data on a non-existing session.
This causes the restarting speaker to send a FIN back. There are
probably other equally obscure cases which are implementation dependent.

Once TCP reset is detected, we start the graceful restart timeout
period. This means that in some cases, the total timeout can
also include the amount of time it took to discover the TCP
session has been reset. The draft makes no distinction as far
as how the session was reset, as far as timeout is concerned.

-Jim.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 2:43 PM
To: 'Tsillas, Jim'; Abarbanel, Benjamin; 'Yakov Rekhter'; Srihari R.
Sangli
Cc: [email-masked]'
Subject: RE: Are dynamic capabilities really necessary if peers support
gr acef ul restart? 

> graceful restart can also be useful when the control plane
> is implemented separately from the forwarding plane. When
> this is true, the control place can reset (or fail-over)
> while the forwarding plane is unaffected. The reset, can
> be made transparent to the forwarding plane. Graceful
> restart can also serve to limit the scope of the reset to
> just the given speaker and its neighbors. In other words,
> the reset state doesn't propagate through the network.
>

Thanks for the clarification. It would be nice if applicable uses for
gracefull restart were added to the draft. 

> The case which you point out (where TCP is broken) is actually
> not covered since a broken TCP session implies a broken
> forwarding plane.
> 

I disagree, this is taken out of draft-ietf-idr-restart-05.txt, 
Abstract section 2.
                                    
 "Finally,procedures are outlined for temporarily retaining routing
information
  across a TCP transport reset." 

I assume it means we hold routing information after the forwarding plane
is broken (BGP peering session dropped), right?

> -Jim.
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[email-masked]]
> Sent: Thursday, July 11, 2002 1:05 PM
> To: 'Yakov Rekhter'; Srihari R. Sangli
> Cc: Tsillas, Jim; [email-masked]'
> Subject: RE: Are dynamic capabilities really necessary if 
> peers support
> gr acef ul restart? 
> 
> 
> Yakov:
>   The only time I think gracefull restart is usefull is if 
> two peers are
> operating
> fine, but the TCP connection is broken by the network. In the 
> case that
> either peer drops the session or either peer reboot/crash, I 
> dont see much
> value in gracefull restart.
> 
> Did I miss something?
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Thursday, July 11, 2002 12:55 PM
> > To: Srihari R. Sangli
> > Cc: Tsillas, Jim; [email-masked]'
> > Subject: Re: Are dynamic capabilities really necessary if 
> > peers support
> > gracef ul restart? 
> > 
> > 
> > Srihari,
> > 
> > > > It seems we are entering major discussion on dynamic
> > > > capabilities and the can of worms is open. Can anyone
> > > > think of a scenario where a dynamic capabilities
> > > > negotiation is still needed if we have graceful restart?
> > > 
> > > Talking about address-families exchanged between BGP speakers, the
> > > dynamic capability is useful for enabling a new address-family or
> > > disabling a address-family w/o disrupting the session and/or other
> > > address-families. It is also useful for turning ON/OFF 
> > other capabilities
> > > (like ORF, etc)  without much disruption. 
> > 
> > Just to clarify, in the presence of graceful restart the disruption
> > you refer to above is just the disruption in the routing peering
> > between the two speakers. There is no disruption in the 
> > data/forwarding
> > plane and no disruption in any other routing peering. Correct ?
> > 
> > Yakov.
> > 
>