Subject: [Idr] RE: FSM review - urgent (Tom and Alex please confirm changes)

From: "Susan Hares" <[email-masked]>
Date: Mon, 30 Jun 2003 16:44:45 -0400

Alex:

1) All States will start with a capital.
2) All bgp resources - will either 
	1) stay at "all BGP resources" or
	2) change to "All BGP resources for this BGP connection"
	
	Please work with Tom Petch to determine
	which of these two you both approve or
	I will leave it at "all BGP resources". 

3) Garbled text in Event23 is correct to the sentence: 

	Event23 is an administrative action
      called by implementation specific logic
      that determines that this connection
      needs to be dropped. 

[Alex/AD-review] Why "implementation-specific logic"?

[Sue]   Implementations code 6.8 in a particular form.
[Sue]    Policy + Administrative events creation is an 
[Sue]    Implementation specific logic.  FSM defines what
[sue]    happens on the wire.

4) > 8.2.1.1 Terms "active" and "passive"

>    The terms active and passive have been in our vocabulary for almost a
>    decade and have proven useful.

will be replaced with:

	The terms active and passive have been in the Internet operator's
      vocabulary for almost a decade and have proven useful.

	Please confirm (with Tom Petch and AD reviewers) that
	you like the replacement text.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 8:56 PM
To: Susan Hares
Subject: FSM review
>        Event23: OpenCollisionDump
> 
>               Definition: An event generated administratively
>                           when a connection collision has been
>                           detected while processing an incoming
>                           OPEN message and this connection has been
>                           selected to be disconnected. See Section
>                           6.8 for more information on collision
>                           detection.
> 
>                           Event23 is an administrative action
>                          called by implementation specific logic

[Alex/AD-review] Why "implementation-specific logic"?

[Sue:]   Implementations code 6.8 in a particular form.
[Sue]    Policy + Administrative events creation is an 
[Sue]    Implementation specific logic.  FSM defines what
[sue]    happens on the wire.

>                         that determines that this connection
>                         needs to be dropped.  The action
>                         the control of implementation specific
>                           policy.

Couldn't parse this sentence.

[sue]		The text was garbled.. thanks for the input!!
[sue]  	new text:  Event23 is an administrative action called
[sue]       by implementation specific logic that determines that 
[sue]       this connection needs to be dropped.  
[sue]
[sue]		leave the last sentence off.

> This event may occur if the FSM
>                           is implemented as two linked state machines.
> 
> 
>               Status:     Optional, depending on local system
> 
>               Optional
>               Attribute
>             Status:     If the state machine is to process this
>                           attribute in Established state,
>                            1) CollisionDetectEstablished
>                                flag SHOULD be set to TRUE
> 
> 
>                            Please note: The Open collision dump can occur
                                              ^^^^^^^^^^^^^^^^^^^
                                              OpenCollisionDump?
                                              
[Thanks for catching -- will turn to normalized form.]

>                            in Idle, Connect, Active, OpenSent, OpenConfirm
>                            without any optional flags being set.

[snip]
>    the idle state, or configured to remain passive, will attempt to

[Alex] "Idle" instead?

[Sue]  thanks - missed that one. idle.

>    connect to the other.  For the purpose of this discussion, the active
>    or connecting side of the TCP connection (the side of a TCP connection
>    sending the first TCP SYN packet) is called outgoing.  The passive or
>    listening side (the sender of the first SYN ACK) is called an incom-
>    ing connection. (See Section 8.2.1.1 for information on the terms
>    active and passive used below.)
> 
>    A BGP implementation MUST connect to and listen on TCP port 179 for
>    incoming connections in addition to trying to connect to peers.  For
>    each incoming connection, a state machine MUST be instantiated.

[alex] For each or only for a valid one. i.e, if I don't support unconfigured
[alex] peers and I receive a connection request from someone I don't know, I
[alex] should not create an FSM for it.

[Sue]  This text was agreed upon by lots of discussions.
[sue]  I am sure if I change it the working group last call will
[sue]  need to be redone.  Please tell me why other text associated with
[sue]  this text doesn't clarify this.  Propose text to the list. 

>    There exists a period in which the identity of the peer on the other
>    end of an incoming connection is known, but the BGP identifier is not
>    known.  During this time, both an incoming and an outgoing connection
>    for the same configured peering may exist. This is referred to as a
>    connection collision. (See Section 6.8.)
> 
>    A BGP implementation will have at most one FSM for each configured
>    peering plus one FSM for each incoming TCP connection for which the
>    peer has not yet been identified. Each FSM corresponds to exactly one
>    TCP connection.
> 
>
> 8.2.1.1 Terms "active" and "passive"
> 
> 
>    The terms active and passive have been in our vocabulary for almost a
>    decade and have proven useful.

[Alex] Ed: personalization and time dependency?
[Sue]  Can we replace "our vocabulary" with "the Internet operator' vocabulary"
[Sue]  
[Sue]  I need your confirmation, the working groups, Tom Petch's, and Jeff 
[Sue]  Haas on this comment. 

>   The words active and passive have
>    slightly different meanings applied to a TCP connection or applied to
>    a peer.  There is only one active side and one passive side to any
>    one TCP connection per the definition above and the state machine
>    below. When a BGP speaker is configured active, it may end up on
>    either the active or passive side of the connection that eventually
>    gets established.  Once the TCP connection is completed, it doesn't
>    matter which end was active and which end was passive.  The only
>    difference is which side of the TCP connection has port number 179.
> 
> 
> 
> 8.2.1.2 FSM and collision detection
> 
> 
>    There is one FSM per BGP connection.  Prior to determining what peer
>    a connection is associated with a bgp session there may be 
> 
> 
> 
> 
> Expiration Date September 2003                                 [Page 46]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>    two connections for a given peer.  There SHOULD be no more than one
>    connection per peer session.

[Alex] Does this assume that a peer is identified by the Router ID?
[Alex] Don't existing implementations use IP addresses instead?

[Sue:] My understanding is the remote side is identified by IP address.
[Sue:] The local side has lots of confirmation knobs?  So, what exactly
[Sue:] Do you mean with this comment?  Can you suggest text that
[sue:] would be a replacement? 

>    The collision detection identifies the case where there is more than
>    one connection per peer and provides guidance for which connection to
>    get rid of.  When this occurs, the corresponding FSM for the connec-
>    tion that is closed SHOULD be disposed of.
> 
>
[snip]..

> 8.2.1.5 FSM actions that are implementation dependent.
> 
>    The BGP FSM specifies at certain points that BGP initialization will
>    occur or that BGP resources will be delete.  The initialization of the
>    BGP FSM and the associate resources depend on the policy portion of
>    the BGP implementation.  The details of these actions are outside
>    the scope of the FSM document.   

[Alex] So, does it really add any value to talk about them here if
[Alex] we don't define what those really are?

[Sue] The FSM actions clarify the actions of the protocol interaction.
[Sue] We cannot simply wave our standards hands and say "implementation"
[Sue] be non-conformant to many working BGP implementations.  Unless
[Sue] you provide some latitude for implementations to have implied
[Sue] optional connection (was session) attributes - you make all
[Sue] implementations obsolete.  My understanding of the ADs charter
[Sue] for this re-write is that type of obsoleting fell under the
[Sue] BAD idea category.  Please clarify this comment.

        - changes its state to Active.
[...]

>       Connect State:
> 
>         In this state, BGP FSM is waiting for the TCP connection to
>         be completed.
> 
> 
>         The start events [Events 1, 3-7] are ignored in connect
>         state.
> 
>         In response to a ManualStop event [Event2], the local system:
>            - drops the TCP connection,
>            - releases all BGP resources,

[Alex] all resources? 

[Sue start] - All appropriate resources for this BGP connection (or session).
[Sue]	  The text was agreed upon.  AGain - I am willing to change the
[Sue]	  text if it is incorrect or to add "BGP connection resources".
[Sue]
[Sue]   But!!! - you (or your AD reviewers)  and Tom Petch must agree
[Sue]   on the comment so I don't go back/forth on comment, or you
[Sue]	  must decide to over-rule Tom.
[Sue end] 

>            - sets ConnectRetryCounter to zero, 
>            - stops the ConnectRetryTimer and sets ConnectRetryTimer
>              to zero, and
> 
> 
> 
> Expiration Date September 2003                                 [Page 48]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>            - changes its state to Idle.
> 
> 
>         In response to the ConnectRetryTimer_Expires event [Event
>         9], the local system:
>            - drops the TCP connection,
>            - restarts the ConnectRetryTimer,
>            - stops the OpenDelayTimer and resets the timer to zero,
>            - initiates a TCP connection to the other BGP peer,
>            - continues to listen for a connection that may be
>              initiated by the remote BGP peer, and
>            - stays in Connect state.
> 
>         If the OpenDelayTimer_Expires event [Event12] occurs in the
>         Connect state, the local system:
>            - sends an OPEN message to its peer,
>            - sets the HoldTimer to a large value, and
>            - changes its state to OpenSent.
> 
>         If the BGP FSM receives a TCPConnection_valid event
>         [Event 14], the TCP connection is processed, and
>         the connection remains in the Connect state.
> 
>         If the BGP FSM receives a ReceiveTCPInvalid event [Event 15]:
>         the local system rejects the TCP connection, and the connection
>         remains in the Connect state.
> 
>         If the TCP connection succeeds [Event 16 or
>         Event 17], the local system checks the DelayOpen attribute prior
>         to processing.  If the DelayOpen attribute is set, the local system:
>              - stops the ConnectRetryTimer (if running) and sets the
>              ConnectRetryTimer to zero,
>              - sets the Open Delay timer to the initial value, and
>              - stays in the Connect state.
>         If the DelayOpen attribute is not set, the local system:
>              - stops the ConnectRetryTimer (if running) and sets the
>              ConnectRetryTimer to zero,
>              - completes BGP initialization
>              - sends an OPEN message to its peer,
>              - sets HoldTimer to a large value, and
>              - changes its state to OpenSent.
> 
>         A hold timer value of 4 minutes is suggested.
> 
>         If the TCP connection fails (TCPConnectionFails [Event18]),
>         the local system checks the OpenDelayTimer.  If the
>         OpenDelayTimer is running, the local system:
>             - restarts the ConnectRetryTimer with initial value,
>             - stops the OpenDelayTimer and resets value to zero,
>             - continues to listen for a connection that may be
> 
> 
> 
> Expiration Date September 2003                                 [Page 49]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>               initiated by the remote BGP peer, and
>             - changes its state to Active.
> 
>         If the OpenDelayTimer is not running, the local system:
>            - stops the ConnectRetryTimer to zero,
>            - drops the TCP connection,
>            - releases all BGP resources, and

all bgp resources?

>            - changes its state to Idle.
> 
>         If an OPEN message is received while the OpenDelayTimer is
>         running [Event 20], the local system:
> 
>            - stops the ConnectRetryTimer (if running) and
>            sets the ConnectRetryTimer to zero,
>            - completes the BGP initialization,
>            - stops and clears the OpenDelayTimer
>              (sets the value to zero),
>            - sends an OPEN message,
>            - sends a KEEPALIVE message,
>            - if the HoldTimer initial value is non-zero,
>                    - starts the keepalive timer to inital value and
>                    - resets the hold timer to the negotiated value,
>              else if HoldTimer Initial value is zero,
>                    - resets the keepalive timer and
>                    - resets the HoldTimer value to zero, 
>            - and changes its state to OpenConfirm.
> 
>         If the value of the autonomous system field is the same as the local
>         Autonomous System number, set the connection status to an internal
>         connection; otherwise it is "external".
> 
>         If BGP message header checking detects an error [Event 21] or
>         OPEN message checking detects an error [Event 22] (see section
>         6.2), the local system:
>            - [optionally] If the SendNOTIFICATIONwithoutOpen attribute 
>               is set to TRUE, then the local system first sends
>               a NOTIFICATION message with the appropriate error
>               code, and then
> 
>            - stops the ConnectRetryTimer (if running)
>              and sets the ConnectRetryTimer to zero,
>            - releases all BGP resources,

all bgp resources?

>            - drops the TCP connection,
>            - increments the ConnectRetryCount by 1,
>            - [optionally] performs peer oscillation damping
>            if the DampPeerOscillation attribute is set to TRUE, and 
>            - changes its state to Idle.
> 
>         If a NOTIFICATION message is received with a version
>         error[Event24], the local system checks the OpenDelayTimer.
>         If the OpenDelayTimer is running, the local system:
>            - stops the ConnectRetryTimer (if running) 
>            and sets the ConnectRetryTimer to zero,
>            - stops and resets the Open Delay timer (sets to zero),
>            - releases all BGP resources,

all bgp resources

>            - drops the TCP connection, and
> 
> 
> 
> Expiration Date September 2003                                 [Page 50]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>            - changes its state to Idle.
> 
>         If the Open Delay timer is not running, the local system:
>            - stops the ConnectRetryTimer and sets the
>            ConnectRetryTimer to zero,
>            - releases all BGP resources,

ditto throughout the rest of the doc

I glanced through the rest seems fine, _assuming_ that you checked
the correctness of the FSM.

Thanks.

Alex

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 30 Jun 2003 16:44:45 -0400

Alex:

will be replaced with:

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 8:56 PM
To: Susan Hares
Subject: FSM review

                                              ^^^^^^^^^^^^^^^^^^^
                                              OpenCollisionDump?

[snip]

[Alex] "Idle" instead?

[snip]..

[Alex] all resources? 

all bgp resources?

all bgp resources?

all bgp resources

Thanks.

Alex