Subject: Re: Multiple CEs talking to the same FE

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 14 Feb 2005 18:28:15 -0800

Robert,

My comments on this inline.... 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Robert Haas

Coming back to implementation issues that fire up in the protocol:

In the case of a single active CE, there can be multiple processes 
"hiding" behind the same CE ID, i.e., a process updating firewalling 
rules and another process updating the routing table, in parallel. We 
must be able to:

1) correlate at the CE the responses from the FE with the commands that 
were originated by each process.
2)  forward at the CE FE-event notifications to the appropriate 
processes that registered for it.

So if the CE ID is the same for all these processes, something is 
missing in the protocol  to support 1) and 2) ... Unless the ForCES PL 
decides to use different TCP/UDP ports for each process (I wouldn't 
recommend this), but this will anyway not solve 2).

[HK] This is more of an implementation issue than a protocol issue in my
opinion. You could have the ForCES protocol daemon demuxing between
different processes using a shim layer with standard IPC. The shim layer
would take care of translating requests from different processes to
different ForCES protocol message types, sequence nos, etc. Let me know
if this sounds reasonable or I am missing something here?

BTW, the multi-CE problem is something one should still think of while 
defining the model. Although the requirements draft only talks of a 
single active CE for each FE, it is a scalability issue if I can't run 
the firewalling and routing processes on two different boxes (i.e. two 
CEs). So let's at least consider the impact of the multi-manager problem

on the model so we don't close all the doors for future support.

[HK] I agree with Joel on this. I believe this is something which can be
addresses in a later rev of the protocol draft. We should focus on
getting the basic protocol messages/encoding correct at this point. That
itself is not a straight forward task cause of the many tradeoffs. We
can come back to the multi-CE issue in the next version of the protocol.

Regards
Hormuzd

Joel M. Halpern wrote:

> I thought we had agreed that for now we would focus on a single active

> CE per FE>  An FE that wants to be managed by several CEs is (I 
> thought) to pretend it is several FEs, probably with distinct
resources.
>
> The multi-manager problem is very very messy.
>

---

From: Robert Haas <[email-masked]>
Date: Tue, 15 Feb 2005 16:19:41 +0100

Hormuzd,

>if this sounds reasonable or I am missing something here?
How far did you go with your implementation of demuxing ? In our case, 
we found that relying on sequence numbers or message types is not useful 
when you want to direct an event notification coming from the FE to the 
appropriate process in the CE. But maybe you found a way to solve that ?

I hope that with our implementations we will find not only 
implementation issues, but protocol issues too. I doubt we can get the 
protocol right on the first shot.

>can come back to the multi-CE issue in the next version of the protocol.
I would treat this the same way we treated the keys: make provision for 
multi-CE support  in the model as early as possible as it may otherwise 
become more difficult to include it later.

For instance, whenever CEs register for events: the model should not 
only indicate with a boolean if a CE has registered to be notified when 
the event occurs, but also include a list of the CEs that have 
registered for the same event. Limited complexity for the model, almost 
no additional complexity for the protocol.

Regards,
-Robert

-- 
Dr. Robert R. 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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Feb 2005 10:31:00 -0500

I am missing something.
The event description I sent to the list had only the boolean.
Neither the protocol nor the model have any notion of multiple CEs talking 
to the FE.  Hence a list of CEs would not make a lot of sense to either entity.
And since the protocol does not have support for talking to multiple CEs 
simultaneously, a list of CEs would in fact invite a non-supportable behavior.

Yours,
Joel M. Halpern

At 10:19 AM 2/15/2005, Robert Haas wrote:
>For instance, whenever CEs register for events: the model should not only 
>indicate with a boolean if a CE has registered to be notified when the 
>event occurs, but also include a list of the CEs that have registered for 
>the same event. Limited complexity for the model, almost no additional 
>complexity for the protocol.

---

From: Robert Haas <[email-masked]>
Date: Tue, 15 Feb 2005 17:12:20 +0100

Joel M. Halpern wrote:

> Neither the protocol nor the model have any notion of multiple CEs 
> talking to the FE.

That's indeed the current (limited) view, I did not try to imply the 
opposite.

>   Hence a list of CEs would not make a lot of sense to either entity.

At this stage, I agree. But this can change in the future. IMHO, I doubt 
operators will like the monolithic approach of a single active CE per 
FE, although it would already be a substantial improvement to the 
current proprietary situation.

> And since the protocol does not have support for talking to multiple 
> CEs simultaneously, a list of CEs would in fact invite a 
> non-supportable behavior.

Currently, nothing in the protocol prevents an FE from setting up 
multiple associations, one for each CE. It is mostly a modelling issue.

Regards,
-Robert

>> only indicate with a boolean if a CE has registered to be notified 
>> when the event occurs, but also include a list of the CEs that have 
>> registered for the same event. Limited complexity for the model, 
>> almost no additional complexity for the protocol.
>
>
>