Subject: [Idr] Issue 7 - from Tom Petch's comments on Draft

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Jul 2003 12:13:07 -0400

Tom and Alex: 

Here's a list of issues to resolve based on your
editorial comments on the new section 8.1.1.
This section was added to respond to the
AD-review the clarify the use of the Optional
Session attributes. 

Please review my comments below on Tom's comments.
Since this section is new in response to the 
AD-Comments, to speed things up - I'd like both
of you to agree to any of these editorial changes: 
	
	Issue A: Are administrative events issued to the
		   BGP peer session or BGP FSM?

	Issue B: Use of "Value" or Values for the description
		   in 8.1.1

	Issue C: Comment at the end of section 8.1.1 to 
		   indicate how existing implementations have
		   coded the optional session attributes. 

Sue 

7) issue 7: Issue: section 8.1.1 - Optional Events linked to Optional Session Attributes

  Issue: 
	A) Are the administrative events issued to the BGP peer session or 
	   to the BGP FSM?

  	   We can declare these to be linked to the BGP peer session.

	old text:
			The term "automatic" refers to
			a start being issued to BGP FSM occurs when such logic
			determines that the BGP peer session should
			be restarted.
			
	new text:

			The term "automatic" refers to
			a start being issued to the BGP peer connection FSM
			when such logic determines that the BGP peer session 
                  should be restarted.

     B) Value or Values in the following text

	Suggested change:

	Values:		True or False
                          **(Value: singular I prefer throughout)

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

	Example text: 

	Option 2:	AllowAutomaticStop

	Description:	This BGP peer session option indicates that the BGP
			session allows "automatic" stopping of the BGP session.
			An "automatic" stop is defined as a stop under the
			control of implementation specific logic.  The
			implementation specific logic is outside the scope
			of this specification. 

	Values:		True or False

      [depends on the resolution of the flags]  
   
     **(I think True and False are best but the pre-existing text almost
        everywhere refers to flags being set or reset so I think this causes
        a few hundred more changes which you need to make.)

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

   C) Comment at the end of 8.1.1

      old text: 

       Note: The optional session attributes clarify the BGP FSM description
             for existing features of BGP implementations.  The 
             optional session attributes may be pre-defined for an
	     implementation and not readable via management interfaces
             for existing correct implementations.  As newer BGP Mobs
             (version 2 and beyond) are supported, these fields will be
	     accessable via a management interface.

      Tom Petch: 
	**(I do not understand the first part of this note)

Sue

===============
Full text of Tom Petches comments: 

8.1 Events for the BGP FSM

8.1.1 Optional Events linked to Optional Session attributes

   The Inputs to the BGP FSM are events.  Events can either be mandatory or
   optional.  Some optional events are linked to optional session attributes.
   Optional session attributes enable several groups of FSM functionality.

   The description below describes the linkage between FSM functionality, events
   and the optional session attributes. 

   Group 1: Automatic Administrative Events (Start/Stop) 

	Optional Session Attributes: AllowAutomaticStart, AllowAutomaticStart**(Stop not Start),
                                     IdleHoldTimer, DampPeerOscillations
	
	Option 1:	AllowAutomaticStart
	
	Description:	A BGP peer session can be started and stopped by 
			administrative control.  This administrative control
			can either be manual, based on operator intervention,
			or under the control of logic specific to
			a BGP implementation. The term "automatic" refers to
			a start being issued 

issue A:

**to the BGP FSM**(remove phrase - the start goes to the BGP peer session, not the FSM - which may optionally receive an event)
  when such logic

[see discussion]
			determines that the BGP peer session session**(session duplicated) should
			be restarted.
[accepted as editorial] 

			The AllowAutomaticStart option**(attribute? flag?) specifies that this
			BGP session supports automatic starting of the BGP
			session.

[accepted as editorial for flags] 

			If**(the) BGP implementation supports AllowAutomaticStart,  

[accepted as editorial] 
		        the peer may be repeatedly restarted. Two other
			options control the rate at which the automatic
			restart occurs: IdleHoldTimer and 
			DampPeerOscillations. The IdleHoldTimer specifies
                        how long the Peer is held in the Idle state prior to
                        allowing the next automatic restart.  The 
                        DampPeerOscillations option specifies that the
                        implementation engages additional logic to
			damp the oscillations of BGP peers in the face of 
                        sequences of automatic start and automatic stop.
			An example of such logic is an increase of the 
			time set in the IdleHoldTimer if the BGP peer
			oscillates connectivity (connected/disconnected)
			repeatedly within a time period.  

issue B: 
	Values:		True or False
     **(Value: singular I prefer throughout)

    [depends on the the resolution of the flags]  

     **(I think True and False are best but the pre-existing text almost
        everywhere refers to flags being set or reset so I think this causes
        a few hundred more changes which you need to make.)

=====

	Option 2:	AllowAutomaticStop

	Description:	This BGP peer session option indicates that the BGP
			session allows "automatic" stopping of the BGP session.
			An "automatic" stop is defined as a stop under the
			control of implementation specific logic.  The
			implementation specific logic is outside the scope
			of this specification. 

	Values:		True or False

	Option 3:	IdleHoldtimer**(Timer)

[accepted] 

	Description:	The IdleHoldTimer aids in controlling BGP peer oscillation.
			An implementation that does not support persistent peer 
                        oscillation damping may not have this timer.

			The Idle Hold Timer **(IdleHoldTimer)is used to keep the BGP peer in Idle
			for a particular duration.  The IdleHoldtimer**(IdleHoldTimer) expired event
			is described in section 8.1.3.
[accepted] 

	Values:		time in seconds

	Option 4:	DampPeerOscillations

	Description:	The DampPeerOscillations optional session attribute
                        indicates that this BGP session is using logic 
                        that damps BGP peer oscillations in the Idle State.

	Value:		True or False

   Group 2: Unconfigured Peers

   	Optional Session Attributes: AcceptConnectionsUnconfiguredPeers

	Option 1:	AcceptConnectionsUnconfiguredPeers

	Description:	The BGP FSM optionally allows the acceptance of BGP peer
                        sessions from neighbors that are not pre-configured.  The 
                        "AcceptConnectionsUnconfiguredPeers" optional session
                        attribute allows the FSM to support the state transitions
			that allow the implementation to accept or reject these
			unconfigured peers.

			The AcceptConnectionsUnconfiguredPeers has security
			implications. Please refer to the BGP Vulnerabilities
			document[xxx]** for details.

	Value:		True or False

   Group 3: TCP processing

	Optional Session Attributes: PassiveTCPEstablishment, TrackTCPState

	Option 1:	PassiveTCPEstablishment
	
	Description:	This option indicates that the BGP FSM will passively wait
                        for the remote BGP peer to establish the BGP TCP session.

	value:		True or False

	Option 2: 	TrackTCPState

	Description:	The BGP FSM normally tracks the result of a TCP connection
			attempt rather than individual TCP messages.  Optionally,
			the BGP FSM can support additional interaction with the TCP 
			session negotiation. The interaction with the TCP events may
                        increase the amount of logging the BGP peer session
			requires and the number of BGP FSM changes.

** Suggest 'The BGP FSM normally tracks the end result of a TCP connection request. 
[accepted]
 
** Optionally, the BGP FSM may track the progress of the underlying three-way handshake;
** this increases the number of TCP related events, of BGP FSM state changes and of the 
** amount of logging required.'

[leave this out unless you wish additional]

	Value:		True or False

   Group 4:  BGP Message Processing

	Optional Session Attributes: DelayOpen, DelayOpenTimer**(OpenDelayTimer), 
				     SendNOTIFICATIONwithoutOPEN,
                                     ConnectionDetectEstablishedState 

	Option 1:	DelayOpen

	Description: 	The DelayOpen optional session attribute allows
		        implementations to be configured to delay sending an
			OPEN message for specific time period (DelayOpenTime).
                        The delay allows the remote BGP Peer time to 
			send the first OPEN message. 

	Value:		True or False

	Option 2:	DelayOpenTimer**(OpenDelayTimer)

	Description:	The DelayOpenTimer**(OpenDelayTimer) optional session attribute specifies a
                        time that the local system will wait prior to sending an
                        OPEN essage on the connection.

	Value:		Time in seconds

	Option 3:	SendNOTIFICIATONw**(NotificationW)**ithoutOPEN

[sendNOTIFICATIONwithoutOPEN - will be final text]

	Description:	The SendNOTIFICIATONw**(NotificationW)**ithoutOPEN allows a peer to send a 
			NOTIFICATION without first sending an OPEN message.  Without
			this optional attribute, the session assumes that an OPEN
			message must be received by a peer prior to the peer sending a
			NOTIFICATION message.  

	Value:		True or False

	Option 4:	CollisionDetectEstablishedState

	Description:	Normally, a Detect Collision (6.8) will
			be ignored in the Established state.  This optional 
			session attribute indicates that this BGP session will
			support processing a detected collision in the
                        Established state.		  
**(suggest)
	Description:	Normally, a collision detected in the Established state (6.8) 
			will be ignored.  This optional	session attribute indicates a collision
			detected in the Established state will be processed.
		  
	Value:		True or False

   Note:  The optional session attributes clarify the BGP FSM description
          for existing features of BGP implementations.  The 
          optional session attributes may be pre-defined for an
	  implementation and not readable via management interfaces
          for existing correct implementations.  As newer BGP MIBs
          (version 2 and beyond) are supported, these fields will be
	  accessable via a management interface.

**(I do not understand the first part of this note)

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