Subject: [Idr] RE: FSM review - comments on Administrative events 8.1.1

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2003 09:42:39 -0400

Alex:

Do you have a proposed text that would make
the administrative events section (8.1.1)
clear?

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 8:49 PM
To: Susan Hares
Cc: Tom Petch; [email-masked]; [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue-

 It seems that the proposed text does not clarify much.
 Maybe I should explain better what I found unclear...

 The text says:

      Each event below has [...] what optional session
      attributes SHOULD be set at each stage.

 Let's take an event for example:

       Event3: AutomaticStart

              Definition: Local system automatically starts the
                          BGP connection.

              Status:     Optional, depending on local system

              Optional
              Attribute
              Status:     1) AutomaticStart SHOULD be set if this event occurs.
                          2) If the PassiveTCPEstablishment optional session
                             attribute is supported, it SHOULD be set to FALSE.
                          3) If the DampPeerOscillation is supported, it
                             SHOULD be set to FALSE when this event occurs.

  So we have the "Optional Attribute Status" part. The text is not
  clear whether "SHOULD be set" is the condition that should be
  checked to make sure the event makes sense or the action upon the
  event. It seems it should be the former, but the text can be read
  both ways.
 
Alex

> Alex and Tom:

> Suggested changed text in 8.1.2 -- please approve as AD reviewers.

> AD comments:

>> 8.1.2 Administrative Events
>> 
>> 
>>    Please note that only Event 1 (manual start) and Event 2 (manual
>>    stop) are mandatory administrative events. All other administrative
>>    events are optional (Events 3-8).   Each event below has a name,
>>    definition, status (mandatory or optional), and what optional session
>>    attributes SHOULD be set at each stage.  

> Can we make it clear whether these settings are the conditions under
> which a given event is considered valid, or actions when an even is
> seen?

> Also, if those are the conditions, what should be done when the
> settings are different?

> ==========

> Text Resolution:

> 8.1.2 Administrative Events

>    An administrative event is an event in which the operator interface
>    and BGP Policy engine signal the BGP finite state machine to start 
>    or stop the BGP state machine.  The basic start and stop indication
>    are augmented by optional session attributes to signal a certain
>    type of start or stop mechanism to the BGP FSM. An example of this 
>    combination is event 5:  AutomaticStart_with_PassiveTCPEstablishment.
>    With this event, the BGP implementation signals to the BGP FSM
>    that the implementation is using an Automatic Start with option
>    to use a Passive TCP Establishment.  The Passive TCP establishment
>    signals that this BGP FSM will wait for the remote side to start
>    the TCP establishment. 

>    Please note that only Event 1 (manual start) and Event 2 (manual
>    stop) are mandatory administrative events. All other administrative
>    events are optional (Events 3-8).   Each event below has a name,
>    definition, status (mandatory or optional), and what optional session
>    attributes SHOULD be set at each stage.   

>    The settings of optional session attributes may be implied by some
>    implementations and not settable by external operator. Section 8.2.1.5
>    describes these implied settings of the optional session attributes.
>    The administrative states described below may also be implied
>    by some implementations and not directly settable by an external
>    operator.  Section 8.2.1.4 describes these implied states further. 

>        Event1: ManualStart

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