Subject: RE: TCP state machine doubts

From: Susan Hares <[email-masked]>
Date: Wed, 21 Aug 2002 15:27:57 -0400

Ben:

I do not think the RIB synchronization points interact with
the connection machine (bringing the machine into Established state,
and dropping it out of connection state.  The only RIB interaction is
the keeping the routes or throwing all routes away.

Most of the route changes and RIB synchronization within the update
state has to do with later drafts (route refresh, graceful restart,etc.)

Can you make a specific suggestion to improving either the
FSM words or the FSM document regarding the RIB synchronization
points?

Sue
At 05:50 PM 7/30/2002 -0400, Abarbanel, Benjamin wrote:
>Jeff:
>   The FSM state machine actions taken are internal sequenced procedures.
>These
>actions could get messy and possibly execute out of sequence when there is a
>multi-threads implemenatation. Although the FSM is preoccupied mostly with
>the setting up and tearing down the peering sessions, in the processing of
>these states certain multi-threaded sensitive processing rules should be
>defined.
>
>For Example:
>============
>Define locks around the various RIB synchronization points and mentioned
>when to take them and when to release them if a state transition has occured
>via the various action statements. This will gaurantee that the RIB data is
>protected from parallel thread execution. It really does not matter which
>thread takes the lock or which thread releases it.  If RIB resource is
>locked, what happens to the state machine when state changing events are
>seen. (E.G. Session disconnected by TCP or Peer. What happens when an
>operator configuration command shuts down a peer session or the whole BGP
>engine?
>
>I know this is getting very detailed, but the FSM is a gray area between the
>internal and external world.
>
>
>Ben
>
>
>
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[email-masked]]
> > Sent: Tuesday, July 30, 2002 4:52 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Susan Hares'; Kunihiro Ishiguro; BGP mailing list
> > Subject: Re: TCP state machine doubts
> >
> >
> > On Thu, Jul 25, 2002 at 11:19:11AM -0400, Abarbanel, Benjamin wrote:
> > > There are various phases that BGP goes through that one
> > > might want to use multiple threads. The inter-locking or
> > inter-working
> > > between the threads could affect the state transitions. For
> > example, Say you
> > > are in Establish state and something happens to the session
> > and it is
> > > disconnected. In a single threaded environment it is easy,
> > first come, first
> > > served. In a multi-threaded case with thread priorities and
> > interruptions,
> > > it might get tricky at times. Some assumptions or
> > expectations by the state
> > > machine on actions it should take with regards to semaphore
> > locks (RIB
> > > Table, etc.), thread prioritization, processing,
> > pre-emption and so forth
> > > might be helpfull. Maybe these actions should only be
> > suggestions not
> > > required ways for implementations.
> >
> > There are certain situations where the FSM suggests that things be
> > done in certain events where an implementation *could* do things
> > in a slightly different order.
> >
> > For example, after the TCP connection has completed, you are supposed
> > to send your messages *before* reading the socket.  In a
> > multi-threaded
> > environment, you may obviously not do this.  Indeed, for passive or
> > unconfigured peers, you may not even send your message immediately.
> >
> > The FSM would suggest where your synchronization points need to go.
> > Happily, most of this work seems to need to be done during
> > peering setup.
> >
> > For the most part, like the 3-rib abstraction, you should be able
> > to do whatever you want inside your black box so long as it looks
> > right on the wire.  The FSM gives guidance on what probably is
> > happening in the box to get things out as you expect them to.
> >
> > More specific examples might be helpful.
> >
> > > Ben
> >
> > --
> > Jeff Haas
> > NextHop Technologies
> >

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 21 Aug 2002 11:41:12 -0400

Sue:
  Just a follow up suggestion. Can we improve the wording within the FSM
document to mention any sensitivy to RIB synchronization points if such 
features as Route Refresh or Gracefull Restart, etc. are introduced in the
spec?

Thanks,
Ben