[Forces-protocol] querry message (path vs attribute)

[Jamal Hadi Salim <[e-mail]>]

I think we need to add a definition for attribute.
As far as iam concerned there is no such thing as a "attribute ID".
What you specify is a path similar to an OID. Whether that path
happens to be on an attribute, a table, an entry is not important
because that wuill be the lement you are pointing to.
so lets remove this from the query section

-----
       Editorial Note:  There is a debate on whether we should use a
                        'Path' or simply an 'Attribute ID' or a 'Table
                        ID' here at the protocol layer.  A Path is used
                        for data indexing for a table, while an
                        'Attribute ID' or a 'Table ID' only specify
                        which attribute or table to use, leaving table
                        index to be included in followed data.
----

cheers,
jamal





On Sat, 2004-10-23 at 14:53, Robert Haas wrote:
> All,
> Attached is the text updated according to Weiming's comments.
> 
> Regards,
> -Robert
> 
> 
> ------------------------------------------------------------------------------------------------------------------- 
> 
> We can remove sections 3.3.2 and 3.3.3, and replace them with a single 
> section that provides an overview of what these "special LFBs":
> 
> New section 3.3.2:
> 
> Whereas four key PL messages have a specific type assigned (Association 
> Setup, Response, and Teardown, as well as Heartbeat) mostly for 
> simplicity and monitoring reasons, all other PL messages follow the LFB 
> structure as this provides more flexibility for future enhancements. In 
> addition, this shows how the ForCES protocol itself can be controlled by 
> the very same type of structures (LFBs) as it uses to control functions 
> such as IP forwarding, filtering, etc.
> 
> To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, 
> and CE LFB. These LFBs are detailed in Section XXX. An short description 
> is provided here:
> 
> The FE Protocol LFB is a logical entity in each FE that is used to 
> control the ForCES protocol. The CE operates on this LFB to subscribe or 
> unsubscribe to Heartbeat messages, define the Heartbeat interval, or 
> discover which ForCES protocol version and which TMLs the FE supports. 
> The FE Protocol LFB also contains the various ForCES ID to be used: 
> unicast IDs and table of the PL multicast IDs the FE must be listening to.
> [TBD: I don't think we need a CE Protocol LFB]
> 
> The FE LFB (referred to as "FE attributes" in the model draft) should 
> not be confused with the FE Protocol Object. The FE LFB is a logical 
> entity in each FE and contains attributes relative to the FE itself, and 
> not to the operation of the ForCES protocol between the CE and the FE. 
> Such attributes can be FEState (refer to model draft), vendor, etc. The 
> FE LFB contains in particular an table that maps a virtual LFB Instance 
> ID to one or more Instance IDs of LFBs in the FE.
> 
> The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical 
> entity in each CE and contains attributes relative to the CE itself, and 
> not to the operation of the ForCES protocol between the CE and the FE. 
> This LFB can be used to convey event notifications from a CE to FEs. 
> Some events may be sent by the CE without prior subscription by the FEs.
> 
> ------------------------------------------------------------------------------------------------------------------- 
> 
> The following section should be inserted just before the "Protocol 
> Messages" section. It provides the detail (in english, not xml) of the 
> LFBs.
> 
> Chapter X: FE, CE, and Protocol LFBs.
> 
> The FE LFB, CE LFB, and FE Protocol LFB are used to control the 
> operation of the ForCES protocol and interact with FEs and CEs.
> Although these LFBs have the same form and interface as other LFBs, they 
> are special in many respects: they have fixed well-known LFB Class and 
> Instance IDs. They are statically defined (no dynamic instantiation 
> allowed) and their status cannot be changed by the protocol: any 
> operation to change the state of such LFBs (for instance, in order to 
> disable the LFB) must result in an error. Moreover, these LFBs must 
> exist before the first ForCES message can be sent or received. All 
> attributes in these LFBs must have pre-defined default values. Finally, 
> these LFBs do not have input nor output ports and do not integrate into 
> the intra-FE LFB topology.
> 
> Section X.1 FE Protocol LFB
> 
> The FE Protocol LFB is a logical entity in each FE that is used to 
> control the ForCES protocol. The FE Protocol LFB Class ID is assigned 
> the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There 
> must always be one and only one instance of the FE Protocol LFB in an 
> FE. The values of the attributes in the FE Protocol LFB have pre-defined 
> default values that are specified here. Unless explicit changes are made 
> to these values using Config messages from the CE, these default values 
> MUST be used for the operation of the protocol.
> 
> The FE Protocol Object consists of the following elements:
> 
> FE Protocol events that can be subscribed/unsubscribed:
>    FE heartbeat
>    FE TML events (TBD)
> FE Protocol capabilities (read-only):
>    Supported ForCES protocol version(s) by the FE
>    Supported ForCES FE model(s) by the FE
>    Some TML capability description(s)
>  FE Protocol attributes (can be read and set):
>    Current version of the ForCES protocol
>    Current version of the FE model
>    FE unicast ID
>    FE multicast ID(s) (list)
>    Association Expiry Timer
>    Heartbeat Interval
>    Primary CE
>    FE failover and restart policy
>    CE failover and restart policy [XXX: what is the diff with FE failover ?]
>  
> [TBD: define default values for each attribute if applicable]
> 
> Section X.2
> 
> The FE LFB is a logical entity in each FE and contains attributes 
> relative to the FE itself, and not to the operation of the ForCES 
> protocol.  The FE LFB Class ID is assigned the value 0x2. The FE LFB 
> Instance ID is assigned the value 0x1. There must always be one and only 
> one instance of the FE LFB in an FE.
> 
> The FE LFB consists of the following elements:
> FE Events:
>    FEAllEvents (subscribing to this corresponds to subscribing to all 
> events below)
>    FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover)
>    FE DoS alert
>    FE capability change
>  FE attributes:
>    FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode 
> [Note: this replaces the State Maintenance messages])
>    MIID table (a list of virtual LFB Instance IDs that map to a list of 
> Instance IDs of LFBs in that FE [Refer to Zsolt's note])
>    FE Behavior Exp. Timer
>    HA Mode
>    FE DoS protection policy
>    [the attributes below were previously under Query message]
>    Inter-FE topology
>    Intra-FE topology
> 
> 
> Section X.3
> 
> The CE LFB is a logical entity in each CE and contains attributes 
> relative to the CE itself, and not to the operation of the ForCES protocol.
> 
> The CE LFB consists of the following elements:
>  CE Events:
>    CEAllEvents (subscribing to this corresponds to subscribing to all 
> events below) [Do we want to allow an FE to explicitely subscribe to CE 
> events ?]
>    CEStatusChange (events that signal CE 
> Up/Down/Active/Inactive/Failover)  [Such events do not necessarily need 
> to be subscribed to, they can fire even without subscription and inform 
> the FE]
> 
> [TBD: what else do we need in the CE LFB ?]


_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol