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

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 24 Nov 2004 14:08:22 -0800

Jamal,

I don't think that the FE sending an unsolicited messages to the CE,
such as an "I'm here" or "I'm leaving" message, is the same kind of
class of messages as the SET operation the CE sends to configure the FE
(or the LFBs within an FE). 

I agree with Joel, there is an inherent asymmetry to the CE/FE protocol.
The LFBs are FE constructs and were not intended to be CE constructs. I
don't understand why you are arguing that the termination point for a
message addressed to the CE should be an LFB, or LFB-like thing (what
you are calling a CE object). If you now state the termination point for
a message addressed to a CE is now an LFB, it seems the FE would have to
know which CE object to address for various messages in order to
maintain interoperability. This doesn't seem either to be necessary or
desirable because it puts more burden on the "dumb" FE when all it
should have to do is send a message to the CE to which it was
associated, not have to understand the inner workings of that CE.

Regards,
Ellen Deleganes

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, November 22, 2004 7:27 AM
To: [email-masked]
Subject: Re: [issue 7] All PL messages addressed to only LFBs?

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

At 09:58 AM 11/22/2004, Jamal Hadi Salim wrote:
>On Mon, 2004-11-22 at 09:29, Joel M. Halpern wrote:
> > 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.
>
>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.
>
> > 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.
>
>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: Jamal Hadi Salim <[email-masked]>
Date: Wed, 24 Nov 2004 19:35:21 -0500

Ellen,

I actually take issue with the asymetry connation to addressing of
LFBs. The protocol is definetely master-slave, no doubt asyemtry exists
in directionality. Having said that:
All LFB messages have addressed in them some LFB selector whether they
come from the FE as responses or unsolicited or issued by the CE.
Please scan the draft.

We reached at a point (just before the IETF) where we were discussing
whether there was need for two more core LFBs at the CE - a CE object
and CE protocol object. Unfortunately that discussion was never complete
before we abandoned the team[1]. The purpose of these as was being
discussed then was to provide symettry to the equivalently named FE core
LFBs. The role of core LFBs is to aggregate messages sent to the two
entities (FE || CE). I was arguing against naming these core entities as
LFBs in the earlier discussions because they dont fit the vanilla
classical definition. They do however make a lot of sense to be refered
as so to ease the grammar and addressing.

An FE needs to know at least of the existence of the two FE/CE pair
LFBs. Likewise i would say, so would a CE.
So the "iam here" and "i am leaving" would be a perfect fit addressed to
a CE object LFB because they end up setting some manageable attribute on
the CE[1].

cheers,
jamal

[1] At the moment those messages target an FE object LFB in the LFB
selector - which clearly doesnt exist on the CE.