Subject: BGP-19: Issue 34-35, 40-48

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Jan 2003 10:47:12 -0500

Andrew and Siva: 

summary: 
	consensus:  34, 35, 43.47 
	possible consensus: 41,44
	no consensus, discussion needed: 40, 42, 48, 54 

-----------

Issue 34 -

I think that Siva and I have consensus on issue 34. 
I changed the text to "fails" based on other comments.

Issue 35 - I accept Siva's changes, please mark 
           this as consensus. 

Issue 40 - Clearing of the Connection Retry timer 

	We need to discuss our two points of view
	here.  This should be marked as no consensus
	
Issues 41  -
	question: Connect state, event 14 - will this happen? 
	
	My resolution: Let event 14 be optional. 
      Not all BGP implementations support it. 

	Siva - Does this let us reach consensus?

Issue 42 -  Handling events 20, 21 in Connect and Active states

	state: non-consensus

	I suggest we don't send a "NOTIFICATION" when
	Event 20 or Event 21 is received in Conect or Active state.

Issue 43: 
	
	state: consensus
	focus: editorial 
	I'll accept the text change from Siva with small editorial
	modification below. 

	old text: 
		-resets the connect retry timer (sets to zero)
		- clears the open delay timer 

	new text:
		- if the connect retry timer is running, 
			clear the connect retry timer (set to zero).
		 if the open delay timer is running,
			clear the open delay timer (set to zero).

	Siva - please confirm that this change is acceptable for
	the default case.  

Issue 44 

	Please reply if you have additional concerns, otherwise
	we will leave the text alone.

Issue 45
	status: change to consensus
	
	I'll  agree with Jeff, Tom and you.  Please consider this
	item in consensus.  I'll change the text.

Issue 47 - Event 19 in Active state 
	status: change to consensus 

	New text

	- if the hold timer value is non-zero,
		- starts the keepalive timer to initial value,  
		- resets the hold timer to the negotiated value,
	- else if the hold timer is zero
		- resets the keepalive timer (set to zero),
		- resets the hold timer to zero.

Issue 48 - 
	 status: non-consensus 
	
	 do you have any further comments.  If not, I'll leave
	the text as:

    state.
 
    A manual stop event[Event2], the local system:
        - Sends a NOTIFICATION with a Cease,
        - releases all BGP resources including
		- stopping the OPen delay timer 
        - drops the TCP connection, 
        - sets ConnectRetryCnt (connect retry count) to zero
        - resets the connect retry timer (sets to zero),
        - changes its state to Idle.

Issue 52 - 
	status: non-consensus 

		<----	Open [Open sent state]
	open ---->  
			[Event 18 in Open Sent 
		<----- Keepalive 

	Event 18:
		- clears BGP delay timer
		- resets BGP connect timer
		- sends Keepalive message
		- if negotiated hold timer is zero,
			o reset keepalive timer,
			o reset hold timer.

		- if negotiated hold timer is non-zero
			o set keepalive timer,
			o set hold timer to negotiated value. 

	Here the question is, do you want to send a 2nd
	keepalive if the keepalive timer expires in 
	Open Confirm.  

     The current draft allows this until the hold timer 
     expires.   The sequence would be:

			<---- open [open sent]
		open -->  [event 18]

			<-----keepalive

				[keepalive timeout [Event 11]
			<---- Keepalive

				[Keepalive time out [Event 11]
			<--- Keepalive

				[hold time-out, Event 10]
			<---Notification
			    drop TCP connection

---

From: [email-masked]
Date: Tue, 21 Jan 2003 14:11:59 -0800

Hi Sue,

Responses are inline.

> 	no consensus, discussion needed: 40, 42, 48, 54 

Done.

> Issue 35 - I accept Siva's changes, please mark 

Done.

> 	here.  This should be marked as no consensus

Already at No Consensus in 2.1:

----------------------------------------------------------------------------
40) Clearing the Connection Retry Timer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we remove the redundant resets from the text?  Or leave them
  to allow action routines to be shared across multiple states?

> 	Siva - Does this let us reach consensus?

Updated this issue, waiting Siva's response.

> 	Event 20 or Event 21 is received in Conect or Active state.

Updated the issue.

> 	Siva - please confirm that this change is acceptable for

Since you've substantively accepted Siva's suggestion, I'll put this
at consensus, unless someone wants to reopen it.

> 	we will leave the text alone.

Sicne there have been on objections, I'll move this to consensus.  We
can reopen it if it is still an issue.

> 	item in consensus.  I'll change the text.

Done.

> 		- resets the hold timer to zero.

This seems to address Siva's concerns, this issue is at consensus, if
there are objections, we can reopen it.

>         - changes its state to Idle.

Updated the issue.

> 				[hold time-out, Event 10]

I think we're waiting for more implementor's responses on this one.

Andrew

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Jan 2003 16:53:04 -0500

> I think we're waiting for more implementor's responses on this one.

GateD will start its keepalive timer while in this state, so multiple
keepalives will be sent.

As someone previously said, this is a "yawn" issue.  But to choose one
way or the other, we may potentially make someone in non-compliance.

Does anyone else care to respond on their implementation's behavior?

-- 
Jeff Haas 
NextHop Technologies