Subject: Optional System attributes that are timers - Issue 2

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Jul 2003 09:53:45 -0400

Alex:

Tom is requesting that the optional session attributes follow
the following template

	1) Flag  - to indicate that the optional timer is used
	2) Time - to indicate the initial value for the timer
	3) Timer - running timer

The Two timers that this refers to are:
	
	1) OpenDelayTimer
	2) IdleHoldTimer

Please confirm (or deny) that you and the AD reviewer
[want/don't want] to require this change to allow the 
document to go forward.

Sue Hares

[issue 2: Timers] 

New text in section 8

   The optional Session attributes are listed below. These optional
   attributes may be supported either per connection or per local sys-
   tem:

            1) AcceptConnectionsUnconfiguredPeers
	2) AllowAutomaticStart
	3) AllowAutomaticStop
	4) CollisionDetectEstablishedState
	5) DampPeerOscillations
	6) DelayOpen 
            7) DelayOpenTime
	8) DelayOpenTimer
	9) IdleHold
          10) IdleHoldTime
          11) IdleHoldTimer
          12) PassiveTCPEstablishment
          13) SendNOTIFICATIONwithoutOPEN
          14) TrackTCPState
   
  The optional session attributes support different features of the BGP
  functionality that have implications for the BGP FSM state
  transitions.   Two groups of the attributes relate to timers: 
         group 1: DelayOpen, DelayOpenTime, DelayOpenTimer
         group 2: IdleHold, IdleHoldtime, IdleHoldtimer

  The first parameter (DelayOpen, IdleHold) is an optional attribute 
  that indicates that the Timer function is active.  The "Time" value
  specifies the initial value for Timer (DelayOpenTime, IdleHoldTime).
  The "Timer" value specifies the actual timer. 

  Please refer to section 8.1.1 for an explanation
  of the interaction between these optional attributes and the Events
  signaled to the state machine.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2003 11:13:34 -0400

Mitchell:

The following is the resolution for issue 2.  Please
let me know if you wish to have it changed.   

Note on your comments:  

1) Denotation of one-shot or periodic - is an implementation
   specific detail.   My understanding of implementations
   are that this is implemented in different ways in different
   implementations.

2) The addition of a "delta" list is a technical addition
   that does not represent the current BGP implementations.

Sue Hares

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

2) Timer format (flag, time, timer)  [issue 2] 

issue 2a: Timer format does not follow format of timers that
	have time, and Timer.  Time is used for initial
	time set for Timer.  Timer is the running timer.

resolution 2a: Optional session attributes associated with timers
		   will have flag for support, Intial time setting and
		   Timer.

		   For example
			DelayOpen - flag indicating support
			DelayOpenTime - Initial time setting for timer
			DelayOpenTimer - timer for Delaying open

	       granularity: seconds, milliseconds, or u-seconds will
			    be specified with the timer.

Tom Petch's comments in: fsm-v2ac.txt
-------------------------------------------------

Yet this problem goes deeper; the required attributes include time and timer, 
for Hold and KeepAlive and the base text uses these consistently - time is in
seconds, timer expires.  The optional attributes have DelayOpen and OpenDelayTimer
(or IdleHoldTimer alone) but no Time in the list.  But the text then talks of
DelayOpenTime with a value in seconds, DelayOpen as a true/false flag while
IdleHoldTimer has a value in seconds; this is a mess.  
Prior to this change, we had a flag that was set/reset, true/false, 
and a timer that was started, stopped, reset etc (sometimes set to zero) 
but most references were to a functioning object, not a time value; 
now we have three and potential confusion.  If the mandatory attributes have both
time and timer, then the optional should be the same.  I do not see one obviously
right answer for what they should be.  
Probably ditch the flag (which smacks of implementation detail), 
have a DelayOpenTime, value in seconds; and an OpenDelayTimer, 
which is optionally implemented, which expires, is set to zero and
has a Value: ??? (don't know - trouble is, a timer is an FSM in itself): 
both attributes present or both attributes absent.  You choose - and I will flag the detailed changes.   

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 5:36 PM
To: Susan Hares
Cc: [email-masked]; Alex Zinin; Tom Petch; [email-masked]; Susan
Hares; [email-masked]
Subject: Re: Optional System attributes that are timers - Issue 2

To the group minus the idr email alias,

	Hopefully these comments aren't too orthoginal to
	the discussion since I am not up to speed within
	the referenced doc.

	But, I would think that these items could
	be identifing (additional) timer attributes.

	1) Flag -> Enable / Disable would be my initial assumption
	   to identify if a optional timer is currently used.

	+++ 4) Granularity :  of secs, ms, usecs for the timers
	      
	+++ 5) Remaining time : depending on implimentation would
	       be a walk thru a delta list or directly associated
	       with the timer.

	+++ 6) Periodic or one-shot timer classification..

	+++ 7) timer handle : unique but opaque way of identifying
	       between two different timers..

	Thanks,
		Mitchell Erblich
		Sr Software Engineer
		---------------------------

>   signaled to the state machine.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2003 11:13:34 -0400

Mitchell:

Note on your comments:  

Sue Hares

		   For example

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 5:36 PM
To: Susan Hares
Cc: [email-masked]; Alex Zinin; Tom Petch; [email-masked]; Susan
Hares; [email-masked]

	      

	Thanks,
		Mitchell Erblich
		Sr Software Engineer