Subject: Response to FSM input

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Dec 2002 12:14:55 -0500

Siva:

Thanks for the comments.  It helps to catch all
the nits in the specification.  I've sent response
to your comments 1-10 in this email.  I'll send the
rest of the replies in groups of 10. 

Here's a summary of the 

Comment 1 - no consensus
Comment 2a - out of date (No IdleHold Timer exists) 
Comment 2b - no consensus, can't remove due to OpenSent state
		 action.

Comment 3 - no text proposed, do we want all options
		specified in 8.1 (7 options) 
		Please review and comment on text 
 
Comment 4 - agree
Comment 5 - no text proposed, no consensus
Comment 6 - no consensus on the text
Comment 7 - see comment 3, no consensus
Comment 8 - question, no text 
Comment 9 - agree, I supplied text 
Comment 10 - agree to remove text in option,
		 different text for definition.

Sue Hares

==========

comment 1: 

1) removal of peer oscillation damping 

The reason we should not remove the peer oscillation damping
from the state machine:

  1) Deployed implementations support peer oscillation damping 
  2) Hooks for the additions in the FSM cannot be added later.

These hooks are optional and do not need to be implemented. 

2) Idle HoldTimer in draft-18

  Perhaps this is an old comment.  I don't find IdleHoldTimer
  in the messages.

3) HoldTime and HoldTimer

   The Hold Time is specified on page 13 of the draft-18 specification
   as to the value and size.  The text in OpenSent requires
   both a HoldTime and HoldTimer value.
===========
   OpenSent:
   
    In this state BGP waits for an Open Message from its peer.  
   
    When an OPEN message is received, all fields are checked 
    for correctness.  If there are no errors in the OPEN message 
    [Event 18] the local system:
        - resets the Open Delay timer to zero,
        - reset BGP Connect Timer to zero, 
        - sends a KEEPALIVE message and
        - sets a KeepAlive timer (via the text below)
        - sets the hold timer according to the negotiated value 
          (see Section 4.2), and 
        - changes its state to OpenConfirm.

    If the negotiated hold time value is zero, then the Hold and
    KeepAlive timers are not started. If the value of the Autonomous
    System field is the same as the local Autonomous System number,
    then the connection is an "internal" connection; otherwise, it
    is an "external" connection.   (This will impact UPDATE processing
    as described below.)
  
===================
The earlier comments on the list indicated we need to collect what
timers or Timer values were utilized in the FSM.  I believe Alex
made this comment last January.  (the list archives will have
this information.)

So, I don't see any way to

Comment 3: optional parameters specified

Please suggest text.  We have the following optional parameters:

1) Delay Open
2) Accept unconfigured peers
3) automatic start [Event 3] 
4) passive TCP establishment (optional)
	4 + 5 = Event 5
5) BGP_stop_flap (BGP Peer oscillation) [Event 6] 
6)automatic stop [Event 7] 
7)Collision detect in Established State 

If you want some of the optional parameters specified, let's
catch all.  Please suggest text and location.  It could
go in 8.1.
--------------------------------
Comment 4

Old Text: 
  Event 1: Manual Start
      Definition: Administrator manually starts peer connection.

 ... 
  Event 2: Manual Stop 
	 Definition: Local system administrator manually stops the 
		       peer connection. 
New Text: 
  Event1: Manual start
       Definition: Local system administrator manually starts the
		       bgp connection.

  ... 
  Event 2: Manual stop:
	  Definition: Local system administrator manually stops the 
			  bgp connection.

agree? 
---------------
Comment 5: 

5) Event3, Event5, Event6 and Event7

5a) 
=========
  Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
		  archives for a discussion of the Bad Route

    http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html

  The "event" sequences are new with this version of the FSM
  to identify particular events by number. 
5b
======

  Can we give examples of these events, as implemneted by curent
  implementations ? This will be of help to new implementaions.

  An example of Auto Stop is already present in the Update event
  handling section, and we can move that to this place as well.

I believe that examples are outside the scope of this specification.
If you have text clarifying the event descriptions, please send it in.

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

6) Event 4,5 Definition

>	   Definition: Administrator manually start the peer
>                       Connection, but has the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing the connection.

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

>My understanding is this is used to indicate a peer configuration
>where we start the state machine, and wait for an incoming connection
>request from the configured peer. Can we re-phrase this section to
>indicate this.

>How about something like:
>
>% The passive flag indicates that the state machine will wait for
>% specified peer to initiate a connection with the local system. If
>% this does not happen within a specific time (hold time), the local
>% system will then also attempt to initiate connection with the
>% specified peer.

The text in 8.2.1.1 indicates the definition of the passive flag. 

6a) 
==========
My understanding of your text is that you want to replace in both
sets of text: 

"The passive flag indicates the peer will listen prior to 
 establishing a connection".  

with: 

"The passive flag indicates that the state machine will wait for the
specified peer to initiate a connection with a local system.

The problem with this sentence is that in the "unconfigured" case
the phrase "specified" peer is confusing.  I think the original text
is clearer. 
6b)
==========
If this does not happen within a specific time (hold time), the local
system will then also attempt to initiate (a) connection with the
specified peer.

My comments: Again, the "specified peer" term is confusing.  Also,
the 2nd half of the statement mixes the actions of the state machine
with the events.  I believe this muddies the text instead of
clarifying it. 
 
=================
Comment 7 -

Event 6 - (not specified, please confirm) 

>  Won't a variant of this with bgp_stop_flap option set be requried ?
>  We can also achieve the same by using the bgp_stop-Flap option as a
>  flag that is provided as an input to the state machine.

see comment number 3.  bgp_stop_flap is an option.  

This state machine description has many events to describe the
mixture of options and actions.  I believe it has a better clarity
than testing lots of flags within a state. 

A proof in case, is that many people are making comments about
specific transitions. 

============
Comment 8 - 

8) Event 5 Definition

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

> Is it correct that this event will occur only when we want to restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an unconfigured peer ?

The automatic start function is an implementation specific mechanism.
This text does not seek to restrict it in any fashion.

================
9) Timer Events Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>
> Event9: connect retry timer expires
>
>           Definition: An event triggered by the expiration of=20
> Event10: hold time expires
>
>	   Definition: An event generated when the HoldTimer=20

We can use any one of these terms (trigerred by/generated when) for all
timer event definitions to make it look more consistent.

agree: Will use "generate" 

Event 8: An event generated when the Idle Hold timer expires.
Event 9: An event generated when the ConnectRetry timer expires.
Event 10: An event generated when the Hold timer expires.  
Event 11: An event generated when the Keepalive timer expires
Event 12: An event generated when the Delay BGP Open timer expires.

Please confirm that this change to the definitions is agreeable to
you.

================
10) Event 8 Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>                       Hold Timer is only used when persistent =20
>                       BGP oscillation damping functions are=20
>                       enabled. =20
>
>           Status: 	Optional.  Used when persistent
>			BGP peer oscillation damping functions
>			are enabled.=20

The status repeats the senetnce in the definition. Can we remove the
sentence from the Status, or replace with a different definition.

Do you think the defenition below would fit ?

% An event trigerred by the expiry of the Idle Hold timer, indicating
% that the session has completed waiting for a back-off period to
% prevent flap, and may now proceed to take any further systemm
% initiated action for this session. 

text change suggestion for 1st sentence that I'll agree to.

 An event trigerred by the expiry of the Idle Hold timer, indicating
 that the session has completed waiting for a back-off period to
 prevent bgp peer oscillation.

Please confirm that you will agree to this.

=================
End of comments on 1st 10 issues.

Sue

------- Message 4

Date:    Fri, 29 Nov 2002 19:46:06 +0530
From:    "Sivananda Ramnath - CTD, Chennai." <[email-masked]>
To:      [email-masked], Yakov Rekhter <[email-masked]>
cc:      [email-masked]
Subject: Comments on draft 18

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

- ------_=_NextPart_000_01C297B1.DB0F1700
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

    Attached are some comments that I have on draft-ietf-idr-bgp4-18.

    Please have a look at these and tell me if the same can be raised to the
mailing list as well.

Thanks,
Siva
([email-masked])

- ------_=_NextPart_000_01C297B1.DB0F1700
Content-Type: text/plain;
	name="BGP_Issues.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="BGP_Issues.txt"

All quoted sections of the original document have been prefixed by a '> =
'
All lines of proposed text have been prefixed by a '% '

1) Performing of peer oscillation damping:

Since this feature is going to be added in a new draft, and its
addition will change the operation of the state machine, can we remove
all mention of it in the state machine ? As part of this removal, can
we also remove the IdleHold Timer from the FSM since it is not useful
in the absence of peer oscillation damping ?

The draft that describes this procedure can then describe the change
in the state machine required to do this.

2) Session Attributes:

> Session Attributes required for each connection are;=20

>   1) state
>   2) Connect Retry timer
>   3) Hold timer
>   4) Hold time
>   5) Keepalive timer

Why have a Hold Timer and a Hold Time ? Can we replace this with just
Hold timer ?

Can we also add the following session attributes:

a) DelayBgpOpenTimer
b) IdleHold Timer (in case we choose not to remove this from the bas =
FSM)

Can we also add the following flag to the session attributes:
a) DelayOpen Flag

3) All sessions attributes:

  There are some attributes that are common to all sessions of the =
system.
  Can we call these out as well:

  * Accept Connections from unconfigured peers (Enabled/Disabled)
  * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
    not to remove it from base spec)

4) Description for Event1/Event2

> Event1: Manual start=20
>
>	   Definition: Administrator manually starts peer
>                       connection

> Event2: Manual stop

>	   Definition: Local system administrator manually=20
>                       stops the peer connection.

We can make these look consistent by using the Term Administrator or
Local System administrator in both cases.

5) Event3, Event5, Event6 and Event7

  Can we give examples of these events, as implemneted by curent
  implementations ? This will be of help to new implementaions.

  An example of Auto Stop is already present in the Update event
  handling section, and we can move that to this place as well.

6) Event 4,5 Definition

>	   Definition: Administrator manually start the peer
>                       Connection, but has the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing the connection.

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

My understanding is this is used to indicate a peer configuration
where we start the state machine, and wait for an incoming connection
request from the configured peer. Can we re-phrase this section to
indicate this.

How about something like:

% The passive flag indicates that the state machine will wait for
% specified peer to initiate a connection with the local system. If
% this does not happen within a specific time (hold time), the local
% system will then also attempt to initiate connection with the
% specified peer.

7) Event 4,5

  Won't a variant of this with bgp_stop_flap option set be requried ?
  We can also achieve the same by using the bgp_stop-Flap option as a
  flag that is provided as an input to the state machine.

8) Event 5 Definition

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

Is it correct that this event will occur only when we want to restart
a connection (after it had been terminated due to some reason beside
administrative action) that we had accepted from an unconfigured peer ?

9) Timer Events Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>
> Event9: connect retry timer expires
>
>           Definition: An event triggered by the expiration of=20
> Event10: hold time expires
>
>	   Definition: An event generated when the HoldTimer=20

We can use any one of these terms (trigerred by/generated when) for all
timer event definitions to make it look more consistent.

10) Event 8 Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>                       Hold Timer is only used when persistent =20
>                       BGP oscillation damping functions are=20
>                       enabled. =20
>
>           Status: 	Optional.  Used when persistent
>			BGP peer oscillation damping functions
>			are enabled.=20

The status repeats the senetnce in the definition. Can we remove the
sentence from the Status, or replace with a different definition.

Do you think the defenition below would fit ?

% An event trigerred by the expiry of the Idle Hold timer, indicating
% that the session has completed waiting for a back-off period to
% prevent flap, and may now proceed to take any further systemm
% initiated action for this session.

11) Event 10 (Hold timer)

  We use the hold timer for two purposes

  * Waiting for an open message (with a default value of 240 seconds)
  * Waiting for Keepalives (with a default value of 90 seconds)

  Can we use two different timers (or at least call them two different
  timer events) ?

12) Event 12

> Event12: DelayBGP Open timer expires [changed]
>=09
>	   Definition: A timer that delays sending of the BGP
>	               Open message for n seconds after the
>                       Transport connection has been completed.=20

The Definition seems to better define what the timer is, rather than =
what
its expiry means. Can we change it to reflect this ?

13) Event 13, 14 definition

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that TCP connection
>                       request with a valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.

a) How about changing this slighty to:
%	   Definition: Event indicating receiving a TCP connection
%                       request with a valid source IP address and TCP=20
%                       port, and valid destination IP address=20
%                       and TCP Port.  The definition of=20

b) Is it correct that Destination IP address validation is used when we
do not wish to accept BGP connections on one of the local IP addresses
(either because we wish to accept such addresses on only our loopback
interfaces, or because the address to which we received the connection
was not the optimal interface with which to speak to the sender) ? If
so, can we add this to the description ?

14) Event 13,14

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that transport
>                       Request valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.

a) I am unclear as to what validation of source and destination port =
mean.

The source port's value should be of no concern to connection =
receipient
system.

The destination port cannot be invalid, since BGP would not receive the
connection request in such a situation.

b) I think it will be useful to state what we consider to be an invalid
IP address.

15) Event 17

> Event17: TCP connection fails

This event can occur even when the transport connection is closed by
the other end. Since this does not reflect a 'failure ', can we change
the event name to

% Event17: TCP connection termination

16) Events related to BGP Messages

Can we make the definition style across these events consistent ?

17) Event 19 Definition

> Event19: BGPOpen with BGP Delay Open Timer running [changed]
>
>           Definition: An event indicating that a valid Open=20
>                       Message has been successful=20
>                       established for a peer that is=20
>                       currently delaying the sending of an=20
>                       BGP Open message.=20

The definition appears a little fragmented. How about:

% Definition: An event indicating that a valid OPEN
%             Message has been received for a peer
%             that has a successfully established
%             transport connection and is currently
%             delaying the seending of a BGP open
%             message

18) Event 22 Definition

a)=20

> Event22: Open collision discard
>
>           Definition: An event generated administratively=20
>                       when a connection Collision has been=20
>                       detected while processing an incoming =20
>                       Open message. This connection has been=20

Isn't this event 'automatically' generated, since it is a system
generated event ?=20

b)

>                       Event 22 is an administrative could=20
>                       occur if FSM is implemented as two=20
>

The word event is missing. How about

%                       Event 22 is an automatic event that
%                       could occur if FSM is implemented as two=20

19) FSM Description: ConnectRetry Count

The Connect Retry count is updated by the FSM but never used. In the
absence of peer oscillation damping, will this be used to stop
connection establishment attempts after a certain maximum number ?
Can we include the use of this counter in some place ?

20) Handling Event 7 (Auto Stop) to Idle State processing:

The handling of Event 7 is missing from the Idle State processing. Can
we add this ? How about replacing

> An manual stop event (Event2) is ignored in the Idle state.

with

% Manual stop (Event 2) and Auto stop (Event 7) events are ignored
% in the Idle 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

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.

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.

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

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 ?

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 ?

27) Handling Event 17 in Active state

We should now move into Idle state. Can we add

% - Goes to Idle state

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

29) Handling Event 2 in the 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

30) Default event handling in Active State

To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes

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.

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.

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 ?

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 ?

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.

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 ?

- ------_=_NextPart_000_01C297B1.DB0F1700--

--