Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a]

From: Robert Haas <[email-masked]>
Date: Thu, 06 May 2004 17:15:05 +0200

Maybe my last message on that topic went unnoticed, so I wanted to again 
stress the possibility to create an FE LFB (call it meta LFB, control 
LFB, etc) that can be configured, events can be subscribed to, etc. The 
difference between the FE LFB and the other "regular" LFBs is that no 
data packet traverses the FE LFB. The purpose of the FE LFB is to 
facilitate the control of the FE:

Examples:

- FE UP and DOWN don't need to be special ForCES messages. Instead, they 
can be events originated by the FE LFB.
- Configuring the interval timer for heartbeats messages can be done 
using a Config message to the hearbeat interval attribute of the FE LFB.

The reason to introduce this LFB versus creating specific ForCES 
messages is flexibility: at some point in time, if we need to enhance 
the ForCES protocol, we don't necessarily need to change the protocol 
itself. Instead, we can create a new version of the FE LFB that supports 
new features.

I'd like to have your comments on such an FE LFB.

Regards,
-Robert

-------- Original Message --------
Subject: 	Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a
Date: 	Wed, 05 May 2004 15:55:40 +0200
From: 	Robert Haas <[email-masked]>
Organization: 	IBM Research Lab
To: 	Wang,Weiming <[email-masked]>
CC: 	[email-masked]
References: 
<[email-masked]> 
<[email-masked]>

All,
I've seen some interesting ideas floating around regarding the number of 
messages needed. Let me illustrate the kind of messages I think we need 
with two scenari:

Usual scenario:
CE sends a Config message to FE. FE applies it and sends an appropriate 
response (ACK if successful or NACK otherwise). This can be the same 
message type with a flag that indicates the result.

Batching scenario with 2-phase commit:
CE sends a serie (batch or bundle, as you prefer) of Config messages to 
the FE, followed by a Commit message (which could be signalled with a 
flag in the last Config message). The FE returns a serie of responses to 
indicate that it got the messages, but DOES NOT apply them until the 
Commit comes. The Response to the Commit indicates if the batch of 
Config messages was successfully applied or not.

Conclusion:
You need a Config message type.
You may use a flag to indicate whether it's the message itself, an ACK, 
or an NACK.
You may use a flag to indicate if the message is one of a batch, or the 
last of the batch (i.e., the Commit).

In the Query case, as there is no 2-phase commit necessary:
You need a Query message type.
You may use a flag to indicate whether it's the message, an ACK, or an NACK.

I'd like to know more about the type of actions that can be performed on 
the LFBs according to the model. Maybe a Config and a Query are enough. 
But I don't know how the Event Generation is handled in the model. Can 
someone explain ?

For FE UP and DOWN, I'd rather include this in existing message types. 
For instance, define an FE LFB that can be acted upon, and events such 
as UP and DOWN may be subscribed to. Use the same messages and semantics 
as the one used for other LFBs.

You may apply the same reasoning to a Packet Redirect LFB, which 
produces packets as events.

Regards,
-Robert

Wang,Weiming wrote:

>----- Original Message -----
>From: "Khosravi, Hormuzd M" <[email-masked]>
>Hi All
>
>Here is the list of Protocol Messages based on final comments made by
>Jamal.
>
>Association Setup, Setup Resp msg
>Association Teardown msg
>[Weiming] I agree to use the name 'Association'. But I can not find where Jamal
>disagree to use only one msg approach, that is 'association msg'. Again, I have
>to say a flag is definitely enough to indicate the command 'setup' 'setup resp',
>and 'teardown'. Can you give reasons why they should be two msgs?
>
>Query/Query Resp msg (including Capability query)
>
>Config/Config Resp msg
>
>Subscribe/Unsubscribe msg
>[Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I
>don't think Jamal agrees this also.  A config or a Event msg can do this well.
>
>State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE,
>etc)
>
>Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc)
>
>[Weiming] I suggest just an 'Event msg' may be better.
>
>Packet Redirect msg
>
>Regards
>Hormuzd
>
>Best regards,
>Weiming
>
>
>
>
>_______________________________________________
>Forces-protocol mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>
>
>  
>

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

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

---

From: "Weiming Wang" <[email-masked]>
Date: Fri, 7 May 2004 11:57:19 +0800

Hi Robert, and all,

I'm very glad that your idea of FE LFB may quite meet with my idea anyway. Actually I called it 'FE Slave' instead of FE LFB. I think both of us think of this entity because we have realized that many of the functions in FE are actually beyond the scope of LFBs defined by FE models. These functions can also be described by using notions such as attibutes, events, capabilites, and states(UP/Down). Because these notions here are mainly effective for whole FE (that is, take whoe FE (at a coarse layer) as a managed entity), in my scheme, we just call then FE attributes, FE events, and FE capabilities, which are discriminated from LFB attributes, LFB events, and LFB capabilities.

I'd like to show some of the contents to see if they meet your thoughts:
For FE events, we may have:
.FE state events (FE Up/Down/Active/Inactive/Failover)
.FE heartbeat
.FE DoS alert
.FE capability change
.FE TML events

For FE capability, we may have
.Currently supported ForCES protocol version by the FE
.Currently supported ForCES FE model by the FE
.Some TML capability description

Fe FE attributes, via which we may able to do:
. To setup or negotiate a version of FE model or the ForCES protocol
. To setup many policies for the FE, for which FE model is not able to do (out of its scope), e.g.,
  - FE failover and restart policy (such as graceful restart or not)
  - FE heartbeat policy (such as the intervals for the heartbeat, etc)

. FE events subscribe/unsubscribe (including to start or stop heartbeats)
. for TML management if needed.

Anyway, any management that is out of the scope of FE model can be put in the FE LFB/ FE slave entity. That is I think our idea, is it right?

Cheers,
Weiming

----- Original Message ----- 
  From: Robert Haas 
  To: [email-masked] 
  Sent: Thursday, May 06, 2004 11:15 PM
  Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a]

  Maybe my last message on that topic went unnoticed, so I wanted to again stress the possibility to create an FE LFB (call it meta LFB, control LFB, etc) that can be configured, events can be subscribed to, etc. The difference between the FE LFB and the other "regular" LFBs is that no data packet traverses the FE LFB. The purpose of the FE LFB is to facilitate the control of the FE:

  Examples:

  - FE UP and DOWN don't need to be special ForCES messages. Instead, they can be events originated by the FE LFB.
  - Configuring the interval timer for heartbeats messages can be done using a Config message to the hearbeat interval attribute of the FE LFB.

  The reason to introduce this LFB versus creating specific ForCES messages is flexibility: at some point in time, if we need to enhance the ForCES protocol, we don't necessarily need to change the protocol itself. Instead, we can create a new version of the FE LFB that supports new features.

  Regards,
  -Robert

---

From: Robert Haas <[email-masked]>
Date: Fri, 07 May 2004 11:32:02 +0200

Weiming,
Yes, I think we have very much the same view on this issue. I called it 
FE LFB because from a protocol point of view, setting FE attributes (and 
other operations) will be done the same way as to any other (real) LFB. 
Hormuzd pointed out that the model team could take over the definition 
of this particular FE LFB. I think it should not. While the model team 
can define the general structure of LFBs, we'll have to fill the FE LFB 
with content, i.e., define the events and attributes of interest to run 
the ForCES protocol. The list you have put up already seems very 
reasonable to me.

I hope that by defining such an FE LFB we can limit the amount of 
message types that must be defined for the ForCES protocol.

Regards,
-Robert

Weiming Wang wrote:

>  
> Hi Robert, and all,
>  
> I'm very glad that your idea of FE LFB may quite meet with my idea 
> anyway. Actually I called it 'FE Slave' instead of FE LFB. I think 
> both of us think of this entity because we have realized that many of 
> the functions in FE are actually beyond the scope of LFBs defined by 
> FE models. These functions can also be described by using notions such 
> as attibutes, events, capabilites, and states(UP/Down). Because these 
> notions here are mainly effective for whole FE (that is, take whoe FE 
> (at a coarse layer) as a managed entity), in my scheme, we just call 
> then FE attributes, FE events, and FE capabilities, which are 
> discriminated from LFB attributes, LFB events, and LFB capabilities.
>  
> Anyway, any management that is out of the scope of FE model can be put 
> in the FE LFB/ FE slave entity. That is I think our idea, is it right?
>  
> Cheers,
> Weiming
>  
>     From: Robert Haas <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>     Maybe my last message on that topic went unnoticed, so I wanted to
>     again stress the possibility to create an FE LFB (call it meta
>     LFB, control LFB, etc) that can be configured, events can be
>     subscribed to, etc. The difference between the FE LFB and the
>     other "regular" LFBs is that no data packet traverses the FE LFB.
>     The purpose of the FE LFB is to facilitate the control of the FE:
>
>     Examples:
>
>     - FE UP and DOWN don't need to be special ForCES messages.
>     Instead, they can be events originated by the FE LFB.
>     - Configuring the interval timer for heartbeats messages can be
>     done using a Config message to the hearbeat interval attribute of
>     the FE LFB.
>
>     messages is flexibility: at some point in time, if we need to
>     enhance the ForCES protocol, we don't necessarily need to change
>     the protocol itself. Instead, we can create a new version of the
>     FE LFB that supports new features.
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 07 May 2004 08:39:01 -0400

Robert/Weiming,

I apologize for actually not saying anything on this subject.
Initially i was confused ;->

I think the "thing" you are describing adds value, the problem is
whether it should be called an LFB, LFB-wannabe, FE-manager. To be
honest it is almost like an implementation level architecture detail. I
also dont see how you can reduce the number of message types. For
example, it should be possible to target hearbeats to any LFB not just
to this "thing".
Are you suggesting it is a "muxer" of all heartbeats etc? 

I am not against it, i think it will ease the implementations; i am just
trying to formulate its need in my head.

cheers,
jamal

On Fri, 2004-05-07 at 05:32, Robert Haas wrote:
> Weiming,
> Yes, I think we have very much the same view on this issue. I called
> it FE LFB because from a protocol point of view, setting FE attributes
> (and other operations) will be done the same way as to any other
> (real) LFB. Hormuzd pointed out that the model team could take over
> the definition of this particular FE LFB. I think it should not. While
> the model team can define the general structure of LFBs, we'll have to
> fill the FE LFB with content, i.e., define the events and attributes
> of interest to run the ForCES protocol. The list you have put up
> already seems very reasonable to me.
> 
> > both of us think of this entity because we have realized that many
> > of the functions in FE are actually beyond the scope of LFBs defined
> > by FE models. These functions can also be described by using notions
> > such as attibutes, events, capabilites, and states(UP/Down). Because
> > these notions here are mainly effective for whole FE (that is, take
> > whoe FE (at a coarse layer) as a managed entity), in my scheme, we
> > just call then FE attributes, FE events, and FE capabilities, which
> > are discriminated from LFB attributes, LFB events, and LFB
> > capabilities.
> >  
> > Anyway, any management that is out of the scope of FE model can be
> > put in the FE LFB/ FE slave entity. That is I think our idea, is it
> > right?
> >  
> > Cheers,
> > Weiming
> >  
> >         Maybe my last message on that topic went unnoticed, so I
> >         wanted to again stress the possibility to create an FE LFB
> >         (call it meta LFB, control LFB, etc) that can be configured,
> >         events can be subscribed to, etc. The difference between the
> >         FE LFB and the other "regular" LFBs is that no data packet
> >         traverses the FE LFB. The purpose of the FE LFB is to
> >         - Configuring the interval timer for heartbeats messages can
> >         be done using a Config message to the hearbeat interval
> >         attribute of the FE LFB.
> >         
> >         The reason to introduce this LFB versus creating specific
> >         ForCES messages is flexibility: at some point in time, if we
> >         need to enhance the ForCES protocol, we don't necessarily
> >         need to change the protocol itself. Instead, we can create a
> >         new version of the FE LFB that supports new features.
> >         

hÇ¬¦º-¡Ê%™¨¥Šx%ŠËE¢·²šè¶‡(–'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?~ŠÜzÊk¢Ú¢

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 7 May 2004 21:32:57 +0800

Hi Jamal,

I think the focus we are discussing is if there are something that shoud be
operated via ForCES protocol, while at the same time, is out of the
accessibility of LFBs defined by FE model. Now we can see that FE model has
mainly treated LFBs as the elements for forwarding process, that is, they are
mainly along the packet datapathes (at least one datapathes in or out of it). I
just a little worry if an LFB like a heartbeat generator can be included in.
Moreover, even if  heartbeat can be treated as a LFB, we still have many left as
I mentioned below. I agree that to define the 'thing' may not reduce msg number.
My main idea is whether we specifically distinguish the 'thing', it exists in
our protocol. Or, from other perspective, I just want to say that we may need to
define some FE attributes, capabilities, and events by ourseves in our ForCES
protocol, which we may not rely on FE model to define.

BR
Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 07 May 2004 14:53:10 -0400

Weiming,

I think the idea is valuable. The problem is the broad definition of an
LFB. Is this "thing" an LFB? Example, is something that offloads a
protocol but does its work in the control CPU (and not on the datapath)
say of an FE fitting to be called an LFB? Take an example of an OSPF
offloading of heartbeats to an FE. It will not reside in the datapath,
but it sure got its major component in the CE. All it does on the FE is
periodically send hello/heartbeats out the interfaces it was configured
to and myabe once in a while complain about inaccessibility of certain
routes etc.
Now, If you can model the OSPF component as an LFB then i agree with
you, this "thing"  could also be modelled as a speacial LFB.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 8 May 2004 12:34:34 +0800

Jamal,

I'm afraid our discussion has come to the same point. Actually my idea is a
little different from Robert's in that, i would not call the 'thing' a LFB,
because many of its functions actually have to be ready there even before the
ForCES protocol begin to run, e.g., the protocol version information, the TML
capability. While for a LFB, I more think it should be lunched by our protocol,
that is, should work only after the protocol core runs. I agree with Robert in
that, we do have such a 'thing' in the protocol, which I'm afraid not included
in our current protocol contents. The 'thing' has its attributes, capabilities,
evnets, which we need to describe in our protocol text.
To be more presie, I just think we need to define some attributes, capabilities,
events by ourselves in our protocol, which can not be defined by FE model.

Cheers,
Weiming