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

Jamal Hadi Salim <hadi@znyx.com> Sat, 23 October 2004 19:15 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16742 for <forces-protocol-web-archive@ietf.org>; Sat, 23 Oct 2004 15:15:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRZi-0002MM-MD for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:29:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRLi-0002c1-Bo; Sat, 23 Oct 2004 15:14:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRJX-0001AF-3I for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:12:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16434 for <forces-protocol@ietf.org>; Sat, 23 Oct 2004 15:12:29 -0400 (EDT)
Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRWc-0002Jw-Et for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:26:03 -0400
Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102312145921:39197 ; Sat, 23 Oct 2004 12:14:59 -0700
From: Jamal Hadi Salim <hadi@znyx.com>
To: Robert Haas <rha@zurich.ibm.com>
In-Reply-To: <417AA8B6.1040601@zurich.ibm.com>
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com>
Organization: ZNYX Networks
Message-Id: <1098558745.1097.42.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 23 Oct 2004 15:12:26 -0400
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:15:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:15:01 PM, Serialize complete at 10/23/2004 12:15:01 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
Content-Transfer-Encoding: 7bit
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, Weiming Wang <wmwang@mail.hzic.edu.cn>, forces-protocol@ietf.org, avri@psg.com, Ligang Dong <donglg@mail.hzic.edu.cn>
Subject: [Forces-protocol] querry message (path vs attribute)
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: hadi@znyx.com
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Content-Transfer-Encoding: 7bit

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
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol