Subject: RE: BGP draft-19 - FSM input needed from developers

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Jan 2003 17:28:36 -0500

Curtis:

Thanks for the input.  It is indeed "connection collision".
I've fixed the text.

[I think this is a new issue for Andrew to track]

Sue

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Monday, January 20, 2003 3:10 PM
To: Susan Hares
Cc: [email-masked]; Russ White; Matt Richardson; [email-masked];
[email-masked]
Subject: Re: BGP draft-19 - FSM input needed from developers 

In message <[email-masked]
m>, "Susan Hares" writes:
> 
> The following state machine issues were queried to the list between 12/2 - 12
> /20 
> 
> The following issues need input from developers:
> 
> 	13.2, 13.4, 13.6 
> 
> ========================================================
> 
> 	13.2 -  Connect state, Event 14th
> 
> 	      Event 14: 
> 		receipt of a valid TCP connection with an invalid or unconfigur
> ed peer
> 	         	
> 
> 	      Should the peer:
> 		1) Treat it as a valid response, and enters the active state
> 		   to watch for a another TCP connection with a valid peer.
> 
> 		2) treat it as an invalid response, reject the connection and s
> ee if a valid
> 		   configured one comes iwthin the connect timer's window.
> 
> 	         Without further input, I will select option 2. 
> 	
> 	13.4 TCP connection events in state machine
> 
> 		Do the implementors require Events 13 - 17 in the State machine
> ?
> 
> 		Event 13 - TCP connection valid indication
> 		Event 14 - TCP connection invalid indication
> 		Event 15 - TCP connection request acknowedged
> 		Event 16 - TCP connection confirmed
> 		Event 17 - TCP connection fails 
> 
> 		Choice 1:  Events 13 - 17 are mandatory
> 		Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 1
> 7 be mandator.
> 
> 		If no one objects, we will use Choice 2.
> 
> 	13.6   FSM Missing Next States
> 
> 		In the Open Confirm state, a valid Open message [Event 22] is r
> eceived.  
> 		The BGP Peer connection is check to ee if there is a collision 
> per 
> 		section 6.8.  If this connection is to be dropped due to the ca
> ll collision,
> 		the local system will drop the call by:
> 
> 			- sending a NOTIFICATION with a CEASE,
> 			- resets the Connect timer (to zero),
> 			- releases all BGP resources 
> 				(this includes stopping the Open Delay Timer an
> d reseting it to zero),
> 			- increments the ConnectRetryCnt by 1 (connect retry co
> unt), and
> 			- optionally performs a BGP peer oscilation damping pro
> cessing, and
> 			- enters the Idle State.
> 
> 		Implementors need to verify if this text and the text for Event
>  22 allows all implementors
> 		to perform the necessary Call Collision actions.
> 
> 		If no objects, we will use this text.
> 
> 
> Thank you for your help.
> 
> Sue Hares

All fine except there is no "call collision".  Perhaps you mean
"connection collision".  There seem to be 4 instances of "call
collision" that should be replaced with "connection collision" in the
draft.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 20 Jan 2003 17:48:27 -0500

In message <[email-masked]
> [I think this is a new issue for Andrew to track]

Sue,

If there is no argument against this maybe we can just call it a minor
editorial change and not bother tracking it as an issue.

Curtis

---

From: [email-masked]
Date: Mon, 20 Jan 2003 16:40:52 -0800

Sue, 

I agree with Curtis on this, if someone objects, I'll open an issue and
we can track the discussion.  If you feel strongly that it should be
on the issues list anyway, let me know and I'll put it there.

Andrew