Subject: Comments 30-36 from Siva

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Dec 2002 16:18:18 -0500

Siva:

thanks again for all the comments.
Let's keep working until we get a few
more of these into the consensus model.

=======================
Here's the summary:

31 - no consensus, question

	issue resolved one way last Jan-March
	Clearing of Hold time included in
	Clear BGP resources. 

32 - no consensus, 
	issue resolve one way last Jan - March
	Clearing of keep alive timer included
	in Clear BGP resources

33 - no consensus, query implementations 

	Exact Open Exchange is being debated.
	What exactly occurs in implementations?

34 - consensus to pull mibs.

35 - no consensus, text approach suggested

36 - no consensus, no desire to open issue

	[author/chair hat on] 

	I tried to add new state 
	in 1Q 2002.  Don't want to go through
	another 3-4 months of debate.  If purchasers
	of boxes w/BGP mandate, we'll reconsider.
	[author/chair hat off] 

Sue Hares

===========================
31) Clearing Hold timer in OpenSent, OpenConfirm and Established State

> In all event handling where we go to Idle state, we need to clear the
> Hold Timer as well.

response: 
&Earlier comments (last January -March on mailing list), indicating that
&
&	- Clearing the BGP resources
&
&included clearing the Hold timer as well.  Do you disagree? 

===============
32) Clearing Keepalive timer in OpenConfirm and Established State

>In all event handling where we go to Idle state, we need to clear the
>Keepalive Timer as well.

response:
& Again, earlier comments (Last January - March on mail list indicated that
& clearing the BGP resources included this.  Are you suggesting that
&  we break this out from BGP resources.

[I used to have a number of these timers broken out.]

====================================

33) Handling Event 18 in the OpenSent state

>Why do we start the Keepalive timer at this stage ? Isn't it sufficient =
>to do so when we move into Established state ?

An earlier comment from Tom (and you) requested the following:

		<---Open
			[Open sent state]

	Open-->	
			[Event 18]
			
		<---Open
		<---Keepalive
			[Action from Event 18 in Open Sent]
			[Open Confirm]
	Keepalive -> [Event 25]
			
			[established]

What do implementations do?  We'll have to query implementations.

=============
34) Established State

> Some event handling in the Established state do not set the MIB Reason =
>when
> handling an event that causes an error. Can we add this ?

we have pulled out all the MIB reason codes. 

=======================

General Comments
==========================================

35) For the events whose status is optional, can we state the impact of =
not
   supporting them (in terms of any interoperability issues). I =
understand that
   most of the optional events will not have such an impact; but a =
clarification
   statement for the optional events would benefit new implementors.

Response:  Much of the support of optional parameters depends on policy.
	     I could put a short note about the optional events and
	     parameters as part of 8.1.5 or 8.2.1.3
	
	     I think it fits better in 8.1.5.

Optional: Events: 3-8, 12, 13-14[my suggestion]
			19, 22
	     
	    Timers: Idle Hold Timer
		      Open Delay Timer

Required flags for optional parameters:

		Open Delay Flag
		BGP Stop Flap 

(I'm sure I've missed a few after 24 hours of non-stop comment
 resolution).  If this is on the right track, I'll try to write
something up.

===========================

36) Is delaying the sending of an OPEN message a standrad industry =
practice ?

> Also, in the FSM, this has been handled by practically implementing a
>   sub-state each, within the CONNECT and ACTIVE states. Won't the FSM
>   look more simple if we just had a new DelayOpen state that we could
>   move into ?

[author hat on] 
ok, I tried the "new state" approach last January (2002), it went down to a
resounding defeat.  I'm not likely to try to this again.

So, yes I proposed new states.  No, it did not have consensus.
No, I do not think it advisable to re-open thie issues.

Whether we have sub-states or a new state, it will operate and function the
same. The purist may like it more, but I really don't want to re-enter
the 2-3 month debate on new states. 
[author hat off]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Dec 2002 18:22:28 -0500

Sue,

> 			[Action from Event 18 in Open Sent]

I'm assuming the second OPEN going from right to left is a typo.
If it isn't, thats a FSM error to the peer on the left.

Theoretically, an implementation that utilizes its keepalive timer
to send the first keepalive to transition to Established is
still interoperable.  However:

o Keepalives can be disabled by negotiating hold time of zero
o We really shouldn't need to restart the Keepalive timer.
  If there is a delay in the keepalive that transitions from
  OpenConfirm to Established, its due to the transport connection.
  It should be reliable and it *should* get through.  If it
  doesn't, there's other problems and the hold timer for the
  peer on the right should do the Right Thing and drop the
  connection.

> What do implementations do?  We'll have to query implementations.

GateD at least waits to enter the Established state prior to starting
the KeepAlive timer.

-- 
Jeff Haas 
NextHop Technologies