Subject: [Idr] Issue 11 - section 8.1.5

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

Alex:

My understanding is that some portions of 6.8
are still governed by policy (that is implementation
specific logic).   I'll send comments with text in
next message.  Please use issue 11 - section 8.1.5 as
title to track these.

Below is the current status of issue 11 for your reference.

Sue

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

Issue 11: section 8.1.5

  issue 11a: editorial
  issue 11b: event 23 comments 

  status: 11a consensus
	  11b no consensus

  Editor's:  11a - accept changes
	     11b - awaiting consensus

AD comments
----------------------

..
>        Event23: Open collision dump
> 
>               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 disconnected. See Section
'to be disconnected'
>                           6.8 for more information on collision
>                           detection.
> 
>                           Event23 is an administrative based only
'based on'?
>                           implementation specific policy. This
>                           Event may occur if the FSM is implemented
>                           as two linked state machines.
> 
> 
>               Status:     Optional, depending on local system
> 
>               Optional
>               Attributes: If the state machine is to process this
>                           attribute in Established state,
>                            1) Peform Collision detect in Established
'Perform'
>                                flag SHOULD be set.

Alex's comments
-----------------

> 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.

This part is related to the collision detection, right?
Clearly both sides need to agree on which transport connection
to bring down, and the logic for this is described in 6.8.
While the exact code is implementation specific, the _logic_
should not be, however the text sounds like it is completely
up to the implementor how to generate OpenCollisionDump.

Tom Petch's comments
-----------------------------------------------------------------------------

8.1.5 BGP Message-based Events

       Event19: BGPOpen

              Definition: An event is generated when a valid OPEN
                          message has been received.

              Status:     Mandatory
              Optional
              Attribute
	      Status:     1) DelayOpen flag SHOULD not be set to TRUE.
                          2) OpenDelayTimer SHOULD not be running.

       Event20: BGPOpen with OpenDelayTimer running

              Definition: An event is generated when a valid OPEN
                          message has been received for a peer
                          that has a successfully established
                          transport connection and is currently
                          delaying the sending of a BGP open
                          message.
              Status:     Optional
              Optional
              Attribute  1) DelayOpen SHOULD be set to TRUE.
	      Status:    2) OpenDelayTimer SHOULD be running

       Event21: BGPHeaderErr

              Definition: An event is generated when a received
                          BGP message header is not valid.

              Status:     Mandatory

       Event22: BGPOpenMsgErr

              Definition: An event is generated when an OPEN message
                          has been received with errors.

              Status:     Mandatory

       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
			  that determines that this connection
			  needs to be dropped.  The action **(something is missing here)
			  the control of implementation specific
                          policy. This event may occur if the FSM
                          is implemented as two linked state machines.

[new text: This action [may be generated] under the control of
           impementation specific policy.]
[Added to fsm-v4] 

              Status:     Optional, depending on local system

              Optional
              Attribute
	      Status:	  If the state machine is to process this
                          attribute in Established state,
                           1) CollisionDetectEstablished**(State)
                               flag SHOULD be set to TRUE

                           Please note: The Open collision dump  **(OpenCollisionDump)can occur
                           in Idle, Connect, Active, OpenSent, OpenConfirm
                           without any optional flags being set.

[accepted]

       Event24: NotifMsgVerErr

              Definition: An event is generated when a
                          NOTIFICATION message with "version
                          error" is received.

              Status:     Mandatory

       Event25: NotifMsg

              Definition: An event is generated when a
                          NOTIFICATION messages **(message)is received and
                          the error code is anything but
                          "version error".

[accepted, in fsm-v4]

              Status:     Mandatory

       Event26: KeepAliveMsg

              Definition: An event is generated when a KEEPALIVE
                         message is received.

              Status:     Mandatory

       Event27: UpdateMsg

              Definition: An event is generated when a valid
                          UPDATE message is received.

              Status:     Mandatory

       Event28: UpdateMsgErr

              Definition: An event is generated when an invalid
                          UPDATE message is received.

              Status:     Mandatory

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

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