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

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Sun, 24 October 2004 11:54 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 HAA21944 for <forces-protocol-web-archive@ietf.org>; Sun, 24 Oct 2004 07:54:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhAe-0004fD-L5 for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:08:25 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLguD-0000b4-Hv; Sun, 24 Oct 2004 07:51:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLgr9-0008Us-LR for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 07:48:16 -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 HAA21459 for <forces-protocol@ietf.org>; Sun, 24 Oct 2004 07:48:14 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLh4M-0004YS-6b for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:01:56 -0400
Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CLgqx-0003Dn-1A for forces-protocol@ietf.org; Sun, 24 Oct 2004 07:48:05 -0400
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:02:55 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000087176@mail.gsu.cn>; Sun, 24 Oct 2004 19:38:47 +0800
Message-ID: <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn>
From: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
To: <hadi@znyx.com>, "Robert Haas" <rha@zurich.ibm.com>, <avri@psg.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> <1098558745.1097.42.camel@jzny.localdomain>
Date: Sun, 24 Oct 2004 19:40:52 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, Ligang Dong <donglg@mail.hzic.edu.cn>, forces-protocol@ietf.org
Subject: [Forces-protocol] Re: querry message (path vs attribute)
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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.3 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121

Jamal,

Firstly, I think it may be unwise to remove some editorial note when the isuuse
is still under discussion. I can clearly see many different opinions regarding
the issue. Then, some of my thougt on adding such an editorial note as below.

Regards,
Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>

>
> I think we need to add a definition for attribute.
> As far as iam concerned there is no such thing as a "attribute ID".
[Weiming] Then, I just can not see how we can recognize different attributes in
a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather than
standadized by IETF, therefore it's impossible to recoganize different
attributes by 'path', and more, if the attribute ID is defined by USERS, there
will be no interoperability. What I see the 'Attribute ID' is a standardized by
IANA Identifier that is assigned to different attributes in all LFBs.

> 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
I see it may be important, the reason is as above.
> because that wuill be the lement you are pointing to.
> so lets remove this from the query section
[Weiming]I'v already put the 'path' as main select and the 'attribute ID/table
ID' as a select for discussion. I don't have any intention to deny the 'path'.
Therefore, I don't think it's reasonable currently to remove the note.

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