Re: [Idr] draft-ietf-idr-bgp4-26.txt: active state (page 61)

Thanks for your response.

I am deriving :

on detecting an inbound connection attempt :
1) In the connect state,  continue to be in the
connect state; process the new connection with a new
fsm in active state. I am not sure you could 'choose'
to close the outbound connection fsm as that would
cause
both sides to potentially close the connection same
way.

2) In the active state ( no outbound connection
pending ), associate the inbound connection with the
current fsm.

Question : Suppose unconfigured peers were never
allowed by the draft (as i suppose is reality), is it
correct to say that one could've used source tcp
address comparison as a means to break the tie as soon
as it is detected? (assuming both sides use this
mechanism).

-skumar.

--- Tom Petch <nwnetworks@dial.pipex.com> wrote:

> Probably two connections.  Event 17 in the Connect
> state should have been
> preceded by Event 14 TcpConnection_Valid in Connect
> state, most likely with
> DelayOpenTimer running.
> 
> But the intention of this fsm is to model all that
> happens between a particular
> pair of configured peers with a single fsm at each
> end.  (Modelling each
> connection between a particular pair of peers as an
> fsm requires a different set
> of events and states; it was discussed but would
> have greater changes to the
> existing specification which was not considered
> within the remit of the WG).
> The challenge then is, as discussed in 8.2.1, that
> the identifier of the peer is
> not known until OPENs are exchanged, so each tcp
> connection may start as a
> separate fsm and then when it becomes apparent that
> there is already an fsm for
> this peer,  6.8 BGP connection collision detection 
> comes into play and you end
> up with one.  But you are not required to implement
> it this way as long as the
> appearance you present conforms with the
> specification.  You may choose to know
> from the TCP SYN that this packet relates to an
> existing fsm and not create a
> second.
> 
> As with any fsm, it is a matter of judgement what
> states there are, what events
> there are.  What you see is considered the best
> compromise.  Read section 8.2.1
> carefully; it says what there is to be said.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "saravana kumar" <skumar_saravana@yahoo.com>
> To: "Tom Petch" <nwnetworks@dial.pipex.com>;
> <idr@ietf.org>
> Sent: Thursday, June 02, 2005 11:22 PM
> Subject: Re: [Idr] draft-ietf-idr-bgp4-26.txt:
> active state (page 61)
> 
> 
> > correction: Read that as Event 17.
> > -skumar.
> > --- Tom Petch <nwnetworks@dial.pipex.com> wrote:
> >
> > > I don't follow you here.  Event 16 I would
> regard as
> > > outbound connection
> > > complete; I sent SYN, received SYN-ACK and sent
> ACK
> > > (TCP three-way handshake).
> > > Connection established, I send BGP OPEN (or
> start
> > > the DelayOpen timer); I don't
> > > see a second connection.
> > >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "saravana kumar"
> <skumar_saravana@yahoo.com>
> > > To: "Tom Petch" <nwnetworks@dial.pipex.com>;
> > > <idr@ietf.org>
> > > Sent: Thursday, June 02, 2005 4:35 PM
> > > Subject: Re: [Idr] draft-ietf-idr-bgp4-26.txt:
> > > active state (page 61)
> > >
> > > > In the connect state, if Event 16 happens
> (inbound
> > > > connection was successful), the draft suggests
> > > > "sending an open or start open delay timer."
> > > >
> > > > Aren't there two connections (fsms ) to track
> here
> > > :
> > > > one for the pending outbound connection and
> the
> > > > inbound connection?
> > > >
> > > > Thanks,
> > > > -skumar.
> > > >
> > > <snip>
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Discover Yahoo!
> > Get on-the-go sports scores, stock quotes, news
> and more. Check it out!
> > http://discover.yahoo.com/mobile.html
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www1.ietf.org/mailman/listinfo/idr
> 
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr