Subject: Re: Comments 21-30

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

Siva: 

This is my response to your comments
21-30.  Thanks again for all the comments.
Your review, Tom Petches, and Jeff's
may help tighten the text.

Please review my response. Let's
see what we can get further consensus on.

thanks for your hard work,

Sue
===================

Summary: 

21 - no consensus, see questions

22 - no consensus, 
	suggest folding this comment into
	discussion on events 13-17 on list

23 - no consensus, no text 
24 - no consensus, alternative text suggested
25 - move to own mail thread 
26 - move to mail thread on events 13-17
27 - move to mail thread on events 13-17

28 - no consensus, but close

	good catch on the 4 minutes,
	Please choose one of the alternative
	texts. 

29 -no consensus, see my alternative text
30 -no consensus
	
	mail list indicated no routes in
	active state.

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

21) Clearing of Connection Retry Timer:

There are a few sections where the FSM draft states that the Connection
Retry timer needs to be reset, wheras the conenct retry timer had been
cleared prior to entering that state. We can remove these instructions
to clear the connect retry timer.

List of places where the connect retry timer need not be cleared

    a) Handling of Event 19 in the Connect State
    b) Handling of Events 12 in the Active State
    c) All cases where it is refered to in the OpenSent,
       OpenConfirm and Established states

Comment:
	1) Does it hurt to have the connect retry timer cleared
	   at these points, since it has already been cleared. 
	
	I felt it eased the implementations to allow the action
	routines to be shared across as many states as possible.
	You can see this a bit more actively. 

====================
22) Handling of Event 14 in the Connect state

>  If the transport connection receives an indication
>  that is invalid or unconfigured. [Event 14]:
>     - the TCP connection is rejected.
>
> I don't understand how we would get this event while in this state.

See my earlier comments (1-10) on the connection state.
It happens in implementations which track the TCP state more
closely.  I suggest that Event 14 become optional. 

===============================================================
23) Handling events 20, 21 in the Connect State and Active State

We need to consider the case where we receive events 20 (message
header error) and 21 (Open message error) when the delay timer is 
running.

Since the connection has been established at this point, we need to 
send a Notification message and then terminate the connection.

Alternative comments: 

	1) We have not sent an Open statement.
	2) Why do we have to send an Notification? I see no justification
	   for it. 
	  
Suggestion: 
	Do you have implementations that send notification?  Do
	you know of others that don't. 

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

24) Handling the default events in the Connect state

The BGP Delay OpenTimers needs to be cleared if it is running.

>How about adding this:
>
> % - If the ConnectRetry Timer is running
> % -    Clear the Connect Retry timer
> % - Otherwise
> % -    Clear the BGP Delay Open Timer

response: 
	By the default you mean the text:

 In response to any other events[Events 7-8, 10-11, 18,
	20-27], the local system: 

"resets" to me implies stops and clears.  I think the
text is clear than the text above.  
------------
Is this the replacement text you imply above:
	- resets the connect retry timer (sets to zero),
	- clears the BGP Delay timer (sets to zero),
	- increments the ConnectRetryCnt (connect retry count) by 1,
	- [optionally] performs bgp peer oscillation damping, and
	- goes to Idle text:  

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

25) Handling Event 23 (Notify with version mismatch error) in Connect
   and OpenSent

>This is currently being handled in the default event processing =
> section.
> However, we do not need to go through the peer oscillation damping
> process in this case. Can we change the wordings to reflect this, or
> move this out of peer oscillation damping processing ?

response:

1)  There is no default event handling process in the text, you
    will need to specify the text.

2) The state table below (hares-statemt-03.txt) states shows
   the changes

-------------    
Event 23  
states:
current    Idle Connect Active Open-Sent Open-Cnf  Establish
	     ----------------------------------------------------
next state Idle  Idle    Idle  Idle      Idle       Idle
           -----------------------------------------------
action     V      D       D     Y        Y           T
           ==============================================

 V - Indicate FSM errors and ignore.
 D - 1) resets the connect retry timer (sets to zero),
     2) drops the TCP connection, 
     2) releases all BGP resources,
     3) increments the ConnectRetryCnt (connect retry count) by 1,
     4) [optionally] performs the bgp peer oscillation damping, and
       Goes to Idle state.

  Y  1) resets the connect retry timer (sets to zero),
     2) Drops the TCP connection,
     3) releases all BGP resources,
     4) [optionally] 

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

26) Handling Event 17 in The connect state

>  If the transport connection fails (timeout or transport
>  disconnect) [Event17], the local system:
>      - changes its state to Active.=20

>If the transport connection fails when the BGP Open Delay timer is
> running, should we still be going into the Active state ?

see mail thread on eventse 13-17

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

27) Handling Event 17 in Active state

We should now move into Idle state. Can we add

% - Goes to Idle state

See mail thread on events 13-17, 
=====================================

28) Handling Event 19 in the Active state

>	- Set the Hold timer to a large value (4 minutes),

Since OPEN messages have been exchanged, can we change this to

%	- If the negotiated Hold time is not 0, set the Hold time to
%     - the negotiated value

The text in Active and Open Sent needs to be the same.
The text in Open Sent is:
	- sets the Hold timer according to the negotiated value
	  (see section 4.2), and 

Which text do you prefer?

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

29) Handling Event 2 in Active state

>> A manual stop event[Event2], the local system:
>>	- Sends a notification with a Cease,
>>	- drops the Transport connection,=20
> 
>These two actions are possible only if a transport connection had =
> already been established. How about changing the text to
>
> % - If a transport connection had been successfully established
> % - Send a Notification with a Cease
> % - Drop the Transport Connection

How about this text:

 A manual stop event [Event 2], the local system
	- Drop the TCP connection, 
	- Release all BGP resources,
	- resets the connection retry timer [sets to zero],
	- goes to Idle.

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

30) Default event handling in Active State

To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes

Comment: Yakov and Jeff noted, there are no routes in
	   Active state.

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

---

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

> 	you know of others that don't. 

This points out a potential issue.
From section 4.2 of -18:
: 4.2 OPEN Message Format
: 
:    After a TCP is established, the first message sent by each side is an
:    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
:    confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
:    KEEPALIVE, and NOTIFICATION messages may be exchanged.

This text implies that NOTIFICATIONs can only be sent once we
have sent an open and then a keepalive, generally meaning we're in the
Established state.

Anyone suggestions for modifying the wording?

Section 6.1 (Message header error) is one situation that implies
that a NOTIFICATION can be sent without sending even an OPEN message.
Note that since the base FSM implies that we send an OPEN message
immediately when we have a completed trasnport connection, we SHOULD
be in at least OpenSent.  However, the DelayOpen timer means that we
MAY send a NOTIFICATION when we are in the Connect state.

GateD, at least, will not send a NOTIFICATION without first sending
an OPEN.

We need to pick one: You can send NOTIFICATIONS before OPEN or before
OPEN if the OpenDelay timer is running.  However, we MUST fix the text
above.

In this particular case, I think the issue is separate from the issues
for events 13-17 since this isn't particular to how deep the BGP 
implementation meddles in the TCP implementation.

If we are in the Connect state, because we have an incoming transport
connection that has completed, but we have the OpenDelay timer
running and the transport connection is closed, we can simply
drop into Active after resetting the ConnectRetry timer and clearing
the OpenDelay timer (if set/exists).  In the case of an unconfigured
peer, we can discard the FSM instance.

I'm rather confused.  Under exactly what circumstances can we be
in the Active state and have an active TCP connection at all?
Ditto for having any BGP resources?

Going to Idle is fine.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Dec 2002 08:03:29 -0800

Jeff,

> Anyone suggestions for modifying the wording?

I have two suggestions:

1. Delete the last sentence in the above paragraph

  or 

2. Delete "and NOTIFICATION" in the last sentence in the above paragraph

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Dec 2002 11:06:18 -0500

Yakov,

> 1. Delete the last sentence in the above paragraph

I would suggest this option.

> 2. Delete "and NOTIFICATION" in the last sentence in the above paragraph

This option could be interpreted as NOTIFICATIONs not being legal here.

-- Jeff

-- 
Jeff Haas 
NextHop Technologies