Subject: [forces] model request

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 4 Feb 2014 08:28:47 -0500

I feel need for Model extension to introduce Events for
FEO LFB class instantiation and destruction.

My use case - I wrote a simple monitor app. It does the following:

a) subscribe to listen to FEs associating and disassociating
b) When an FE associates to the controller, probe it for all
all LFBs it supports and what versions
c) subscribe to events on LFB instances of interest

At this point we have state for FE + LFB instances stored within
the App. We get events and in the simple case we just log them
(but think of refreshing a GUI etc).
My problem:
I have no way of asynchronously knowing if an LFB instance
to which i am subscribed-to for events is destroyed. Or a new one
is instantiated so i can subscribe-to events should i need to.

This event will help alleviate that pain.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 04 Feb 2014 16:33:32 -0500

There seem to be two sub-cases of this, one of which is rare, and the 
other of which seems irrelevant.

There is the rare case of the FE creating LFB instances on its own. 
This is legal, and arguably an event to detect this would be useful. 
But I can not imagine this is what you are looking for.

The other possibility is that your monitor is distinct from the CE, and 
you want to know about CE creation and deletion of the LFB instances. 
The only problem with taht is that by architecture we currently don't 
have provision for interacting with multiple CEs.  If there is itnerest 
from I2RS we may need to address that gap, but without addressing that I 
don't see how something can be subscribed to FE events about CE actions.

Yours,
Joel
On 2/4/14, 8:28 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Feb 2014 06:43:39 -0500

Joel,
I havent thought of the rare case you mention - but it would be taken care here
as well. The scenario i described is not related to multiple CEs,
rather multiple
apps.
In our implementation:
We may have multiple applications talking to one or more CEs.
The monitor example would be such an app which is passive, but other
apps(eg a CLI) may be actively instantiating/destroying LFBs.
In the case of multiple controllers, only the master of a specific CE is allowed
to do writes to that FE. So apps will have to go via this sync point.

cheers,
jamal

cheers,
jamal

On Tue, Feb 4, 2014 at 4:33 PM, Joel <[email-masked]> wrote:
> There seem to be two sub-cases of this, one of which is rare, and the other
> of which seems irrelevant.
>
> There is the rare case of the FE creating LFB instances on its own. This is
> legal, and arguably an event to detect this would be useful. But I can not
> imagine this is what you are looking for.
>
>
> The other possibility is that your monitor is distinct from the CE, and you
> want to know about CE creation and deletion of the LFB instances. The only
> problem with taht is that by architecture we currently don't have provision
> for interacting with multiple CEs.  If there is itnerest from I2RS we may
> need to address that gap, but without addressing that I don't see how
> something can be subscribed to FE events about CE actions.
>
> Yours,
> Joel
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Feb 2014 06:46:35 -0500

Meant:
"only the master of a specific FE is allowed to do writes to that FE"
Of course all other CEs will (read) receive events they subscribed to whether
they are connected to the master or backup CE(s).
(as per CEHA).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Feb 2014 07:05:38 -0500

Ok, not that early in the morning and i am sipping my coffee but still
typoing away;-> Meant:
"of course all other Apps subscribed to a specific event whether
connected to the master or backup CEs will receive events"

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Wed, 05 Feb 2014 10:50:20 -0500

THe question of the archtiecture of the interaction of applications with 
the controller is a layer above that at which the ForCES protocol 
operates.  Specifically, the protocol should not be generating events 
which are meaningless to the CE, just so the CE can pass them on to 
apps.  If the CE wants to do that, it should do so by local means.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Feb 2014 16:35:11 -0500

On Wed, Feb 5, 2014 at 10:50 AM, Joel <[email-masked]> wrote:
> THe question of the archtiecture of the interaction of applications with the
> controller is a layer above that at which the ForCES protocol operates.

This is true.

> Specifically, the protocol should not be generating events which are
> meaningless to the CE, just so the CE can pass them on to apps.  If the CE
> wants to do that, it should do so by local means.
>

I think this is a  reasonable arguement but it is a little too strong
to say it is
meaningless to the CE. For me, it has meaning to backup CEs
because I have apps connected to the backup CEs.
In hot standby mode, such apps receive any events they subscribed to.
These events come from the FE.
If i read you correctly: What you are asking is basically I worry
at the master CE level of synchronizing to other CEs when
instantiate/destroy happens via master CE.
I believe this could be done -  but it is a lot cheaper for such an
event to come from the FE.

cheers,
jamal

>>> you