Subject: [forces] LFB properties

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 3 Jul 2013 06:56:16 -0400

This is a request in relation to the model extension draft.

Often when debugging issues between CE and FE we are interested in
finding sent/received messages/errors per LFB instance at each
layer in the NE cluster.
i.e i want to find out for each FE what each LFB instance has
in terms of stats in its communication to the CE. This has nothing
to do with what such an LFB would have in its data part stats (which
should be part of the model for the specific LFB).

Our implementation experience indicates we need this for every LFB
without exception. While currently we are doing this through some
management interface - I would like to propose an "LFB property"
(just like we have Table properties) which would have simple stats
per LFB instance. The stats are:
send {pkts, bytes, errors} and receive {pkts, bytes, errors}

Thoughts?

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 3 Jul 2013 16:33:31 +0300

Greetings Jamal,

I think this is a useful info to have, but I think we may have some issues.

Firstly, I'm unsure of whether statistics may be properties from a model
point of view.

Secondly, I think we'll have an addressing problem.

If you define LFB properties how will you get that property?

Main Header -> LFB Selector (Class/Instance) -> Operation TLV (Get Prop) 

Unless we have only one property this will work.

But what if we have more than one, you'll need to add a Path Data TLV.

This will create an ambiguity of whether that Path Data refers to either a
component or the LFB itself.

Regards,

Evangelos Haleplidis.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jamal Hadi Salim
Sent: Wednesday, July 03, 2013 1:56 PM
To: [email-masked]
Subject: [forces] LFB properties

layer in the NE cluster. 

Thoughts?

cheers,

jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 3 Jul 2013 10:23:32 -0400

Greetings Evangelos,

On Wed, Jul 3, 2013 at 9:33 AM, Haleplidis Evangelos <[email-masked]>wrote:

> Greetings Jamal,****
> ** **
> ****
> ** **
> Firstly, I’m unsure of whether statistics may be properties from a model
> point of view.****
>
> **
>

>From a purist view, I agree that properties belong to components and
LFB instances are not exactly components. However:
Given that ForCES LFB instance stats are always going to be needed this
could be
looked at as an attribute of the LFB instance. We represent attributes as
properties.
So I would argue it would be reasonable to have LFB properties.

> **
>
> Secondly, I think we’ll have an addressing problem.****
>
> If you define LFB properties how will you get that property?****
>
> ** **
>
> Main Header -> LFB Selector (Class/Instance) -> Operation TLV (Get Prop) *
> ***
>
> Unless we have only one property this will work.****
>
> But what if we have more than one, you’ll need to add a Path Data TLV.****
>
> component or the LFB itself.****
>
> **
>

Good point.
We should mandate that LFB instance properties cannot be in the form of a
struct.
i.e it should be a flat space.
So a GETPROP to /FE/2/LFB class X/instance 10/1
will return property 1 (which in this case would be stats).
It would be ambigous if we had a path of:

GETPROP to /FE/2/LFB class X/instance 10/1/1
because that could be intepreted to mean the property id 1 of component ID
1.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 4 Jul 2013 01:01:47 +0300

Greetings Jamal,

[ΕΗ] It is reasonable for LFB to have properties. 

It'd be good, if possible, to get some views for other people as well in
regards to having LFB stats as properties.

We can discuss this as well at the meeting.

Good point.

[ΕΗ] It would mean that we don't allow structs and arrays as well. 

That would indeed solve the problem of ambiguity, but it's a bit limiting in
a model perspective. 

And I guess these LFB properties should be optional as well.

cheers,

jamal

Regards,

Evangelos Haleplidis.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 5 Jul 2013 06:29:49 -0400

Greetings Evangelos,

On Wed, Jul 3, 2013 at 6:01 PM, Haleplidis Evangelos <[email-masked]>wrote:

>
>  *[ΕΗ] It is reasonable for LFB to have properties. *
>
> *It’d be good, if possible, to get some views for other people as well in
> regards to having LFB stats as properties.*
>
> *We can discuss this as well at the meeting.*****
>
>

Indeed - are you able to add this to the model extension draft?

>  *[ΕΗ] It would mean that we don’t allow structs and arrays as well. *
>
> *That would indeed solve the problem of ambiguity, but it’s a bit
> limiting in a model perspective. *
>
> *And I guess these LFB properties should be optional as well.*****
>
> **
>

All our properties are currently non-complex. I guess we've never had to
think about justifying
that until now.

cheers,
jamal