Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review.

Robert Haas <rha@zurich.ibm.com> Sat, 23 October 2004 19:02 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 PAA15297 for <forces-protocol-web-archive@ietf.org>; Sat, 23 Oct 2004 15:02:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRN3-0002CA-5a for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:16:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR3x-0004sJ-Sm; Sat, 23 Oct 2004 14:56:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR1J-0004FB-Hj for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 14:53:41 -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 OAA14757 for <forces-protocol@ietf.org>; Sat, 23 Oct 2004 14:53:39 -0400 (EDT)
Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLREO-00024F-KB for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:07:13 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9NIqipA149556; Sat, 23 Oct 2004 14:52:45 -0400
Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NIqh4G117934; Sat, 23 Oct 2004 14:52:43 -0400
Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA82352; Sat, 23 Oct 2004 20:52:42 +0200
Message-ID: <417AA86E.2030209@zurich.ibm.com>
Date: Sat, 23 Oct 2004 20:52:30 +0200
From: Robert Haas <rha@zurich.ibm.com>
Organization: IBM Research Lab
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Weiming Wang <wmwang@mail.hzic.edu.cn>
Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review.
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1>
In-Reply-To: <005b01c4b907$242b1790$020aa8c0@wwm1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id i9NIqipA149556
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478
Content-Transfer-Encoding: quoted-printable
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong <donglg@mail.hzic.edu.cn>
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.0 (/)
X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7
Content-Transfer-Encoding: quoted-printable

Weiming,
Thanks for your valuable comments. I'll send an update to the text 
shortly. See some answers in-line.
Regards,
-Robert

Weiming Wang wrote:

>Hi Robert,
>
>A general comment is:
>I think the difference and the sameness of the FE protocol LFB and FE LFB with
>the general FE model LFBs should be specifically addressed.
>
>I can see the sameness is:
>
>1. a LFB class id and an instance id are used to address them.
>2. contains attributes, capabilities and events that can be operated via
>protocol messages.
>
>I can see the difference is:
>
>1. These LFBs will be lunched along the time the FE is started, before first
>ForCES protocol message is sent or received, and whose status  should not be
>allowed being changed by protocol messages then. Any status operation toward
>these LFBs will result in operation error.
>2. a defaut value for these LFB attributes are needed , and the instance IDs for
>these LFBs are also predefined (I suppose LFBs defined by FE model, whose
>instance is configured by PL msg). (you'v described this point)
>3. These LFBs will be defined as black blocks that do not have any input or
>output ports from FE LFB topology viewpoint.
>4. Followed 3, these LFBs will then not be included in FE LFB topology.
>
>  
>
Agreed.

>can now only think of these, we may have more later.
>
>Some more comments pls see inline for.
>
>regards,
>weiming
>
>----- Original Message -----
>From: "Robert Haas" <rha@zurich.ibm.com>
>
>All,
>Below is a new draft of the sections related to FE/Protocol LFBs. Please
>review.
>
>I will also try to add a table summarizing the operations allowed in
>each type of PL message. I sent it in a previous message.
>
>BTW, I find it a bit odd to have Query messages defined before Config
>messages in Section "Protocol Messages". Does anyone mind changing the
>order ?
>[Weiming]It's ok to me, and I also see it's not very normal compared with other
>systems. One difference with ForCES system is it' query message is first used
>than config msg(query capability). Anyway, i agree to change.
>
>Avri,
>Please send the xml files once you have updated them. I'll then
>incorporate my text below directly taking suggestions/comments into
>account, unless you want to do it ;-)
>
>BTW, we'll have to remove the State maintenance section and add a new
>chapter for these LFBs (new xml file ?).
>
>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.
>
>[Weiming]I just see some repeats here of this section with followed specific
>section.
>
>  
>
It's on purpose, because the section below will only appear a few pages 
later.

>--------------------------------------------------------------------------------
>-----------------------------------
>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 following LFBs are used to control the operation of the ForCES
>protocol and interact with FEs and CEs.
>[Weiming]I think more description include the difference and the sameness of
>these LFBs with FE model LFBs) should be described here.
>
>  
>
Done.

>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 can be manipulated
>using the standard PL messages.
>[Weiming]Except the LFB state operations.
>
>  
>
Agreed. Removed the sentence from text.

>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.
>[Weiming] do we need to tell which attributes whose value should be preset
>default values?
>
>  
>
We will have to describe each attribute in more details at some point. 
Not now.

>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(s) (list)
>    FE multicast ID(s) (list)
>[Weiming] Can these two be one attribute, only with two tables?
>
>  
>
FE unicast should actually not be a list (otherwise how does the FE 
decide which ID to use as Sender ?)

>    Association Expiry Timer
>    Heartbeat Interval
>    Primary CE
>    FE failover and restart policy
>[Weiming] I suppose to and CE failover or  leave policy, because it is
>important. It will tell what FE will do if it finds it can not connect to a CE
>and get command from it. By using this plicy, CE can in advance tell the FE to
>go inactive, totally go down, or just do whatever it can (graceful restart?) if
>CE fails.
>
>  
>
I thought that what you decribed is actually captured under the name "FE 
failover and restart policy" Or what does that mean ?

>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 replies 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
>    [the attributes below were previously under Query message]
>    Inter-FE topology
>    Intra-FE topology
>[Weiming] although I'm not very sure of other's thoughts, I think the attribute
>for FE DoS Protect policy should be needed.  This attribute will be transfered
>to TML layer via something (API ?).
>
>  
>
Added.

>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 FE LFB consists of the following elements:
>[Weiming] should be CE LFB?
>  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 ?]
>[Weiming] I see the CE LFB may only have events attributes appearing to FEs. I
>don't think CE attributes should be defined.
>  
>
OK

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol