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

[Robert Haas <[e-mail]>]

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" <[e-mail]>
>
>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 [phone]  fax [phone]  http://www.zurich.ibm.com/~rha


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