Subject: [issue 7] All PL messages addressed to only LFBs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 21 Nov 2004 18:42:58 -0800

Hi All,

Here is one open issue that I would like to add to the issue list...

All PL Messages terminate at LFBs or All messages are addressed to only
LFBs,

In other words, there cannot be any PL messages addressed on a CE wide
or FE wide basis

Jamal, Robert, myself had discussed this towards the end of our last
conference call and both Robert and myself were of the opinion that this
should not be a requirement. We already have some exceptions to this in
the protocol...HeartBeat messages and Event messages need not be
addressed to specific LFBs are addressed to entire CE or FE. We do agree
that in the current protocol grammar, all information is represented as
LFBs, but this does not require the above.

Anyways we can start the discussion on this here,

Thanks

Hormuzd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 21 Nov 2004 23:05:06 -0500

I agree.  While all information manipulation messages are aimed at
LFBs, I think that things like keep-alive ought to be protocol level
messages between the FE and the CE.  There may be other such
messages in the future.  (For example, if we ever need to negotiate
information rather than just discover capabilities, that will likely be a
CE-FE exchange.)

Yours,

Joel

At 09:42 PM 11/21/2004, Khosravi, Hormuzd M wrote:

Hi
All,

Here is one open issue that I would like to add to the issue list…

In other words, there cannot be any PL messages addressed on a CE wide or
FE wide basis

Jamal, Robert, myself had discussed this towards the end of our last
conference call and both Robert and myself were of the opinion that this
should not be a requirement. We already have some exceptions to this in
the protocol…HeartBeat messages and Event messages need not be addressed
to specific LFBs are addressed to entire CE or FE. We do agree that in
the current protocol grammar, all information is represented as LFBs, but
this does not require the above.

Thanks

Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 22 Nov 2004 07:59:24 -0500

On Sun, 2004-11-21 at 23:05, Joel M. Halpern wrote:
> messages between the FE and the CE.  There may be other such messages
> in the future.  (For example, if we ever need to negotiate information
> rather than just discover capabilities, that will likely be a CE-FE
> exchange.)
>

The whole point of having FE Object and FE protocol Object is so that
messages aimed at the "FE" can go to one of those. This should be an
opportunity to justify CE complemantary entities (CE object and CE
protocol objects).

This keeps the grammar lean and mean. You dont need exceptions just for
keepalives to the FE, let them go to the FE protocol object, You dont
need to have associations go to the "CE", let them go to the CE object.

i.e grammar stays (forever) as:

PL level PDU : = MAINHDR<LFBselect>+
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER:= <OPERATION [<path-data>]*>+

instead of:

PL level PDU : = MAINHDR <HB>|<ASSOC>|<YETTOBEDEFINED>|<LFBselect>+
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER:= <OPERATION [<path-data>]*>+
HB := ...
ASSOC := ...
YETTOBEFEFINED1 := ...
YETTOBEFEFINED2 := ...

You save almost nothing in terms of parsing in processing cycles by
keeping it that way. And you loose in elegance/consistency departments
by having exceptions to the rule.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2004 09:29:02 -0500

This introduces the notion of the CE object, and of the FE sending GET and
SET operations to the CE.  It is not clear to me that this is a good thing
at all.
I think this may be taking protocol symmetry past where it belongs.  ForCES
is not a symmetric environment.  The CE is smart.  The FE is (relatively) dumb.

To put it another way, when SNMP needs to create "operations" they end up
making table entries which do magic things when they are set.  In ForCES, I
would prefer not to do that.  Obviously, when we want to cause special data
plane behavior we will do that by setting LFB fields.  However, when we
want to perform protocol operations, I would prefer not to direct them
through objects.  While an FE or a CE might choose to have an explicit
state machine for managing and monitoring keepalives, that is not a
required implementation.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 22 Nov 2004 09:58:01 -0500

> SET operations to the CE.  It is not clear to me that this is a good thing

There are cases where it is semantically fine for the FE to send
unsolicited messages. off top of my head: Association messages or async
events such as an FE departing from the cluster.

> state machine for managing and monitoring keepalives, that is not a

I see it as a convinience in the protocol design rather than targeting
tables[1]. This is the role the core LFBs play - one of convinience to
have syntatic consistency.

Given the above arguement you make, should we then kill the concept of
the FE protocol object then?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Nov 2004 10:26:45 -0500

If there are parameters of the FE protocol behavior that the CE needs to be
able to query or set, then the FE protocol object is an nice abstraction
for those.
At the moment, I am not sure what information goes in there.  If the only
information is the keep-alive interval, it is probably not worth
having.  If there is more informatio, and particularly if we are going to
need some structured information, then the FE protocol object is a big win.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 22 Nov 2004 21:16:02 -0500

All Forces messages target some end attribute or other.
An FE joining a NE is a SET on something at the CE. That something is
what a CE object would be responsible for managing.

So:
In addition to being a convinience in the protocol design (simplifying
the grammar and syntatic consistency), it makes it easier to manage
various attributes if they are owned by a specific entity (which is then
addressed when accessing the attribute).

For that same reason i would keep the FE protocol object around so that
it can own protocol related attributes at the FE.
Its a nice abstraction.

cheers,
jamal