Subject: [Forces-protocol] Future question for the discussion

From: [email-masked]
Date: Mon, 8 Mar 2004 20:20:29 +0900

Hi,

One of the difference between the protocols is the use of peer-peer 
model versus the master-slave model.  Having worked with the 
master-slave model in GSMP, I found it to have limitations and think 
this should also be on the topics for discussion.

a.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Ligang Dong" <[email-masked]>
Date: Mon, 8 Mar 2004 21:08:23 +0800

hi, 
I cited one sentence from the ForCES Framework Protocol,  "The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters." Do you mean that we should change this framework protocol?

Besides, can you give more detail about the limitation of the master-slave model in GRMP.
thanks
dong

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 08, 2004 7:20 PM
Subject: [Forces-protocol] Future question for the discussion

> ŠÜzÊk¢Ú¢YšŠX§‚X¬´Z+që)®‹hr‰bz×è®m¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£÷èÇ¬¦º-¡Ê%

---

From: [email-masked]
Date: Mon, 8 Mar 2004 22:28:02 +0900

On 8 mar 2004, at 22.08, Ligang Dong wrote:

> hi,
> I cited one sentence from the ForCES Framework Protocol,  "The ForCES 
> protocol is a master-slave protocol in which FEs are slaves and CEs 
> are masters." Do you mean that we should change this framework 
> protocol?

Well, and I don't know if it time for this yet, but we have 2 models 
being presented.  As far as I understand it netlink2 is using a peer to 
peer model of communications while Fact and GRMP are using a 
master-slave model of communications.

I don't disagree that the FE gets its LFB state etc. from the CE, in 
this it has a more restricted scope of responsibility.  The issues I 
have with master/slave protocols are not which controls the state of 
the other, but rather in the protocol messaging and in who can initiate 
an exchange of info.

> master-slave model in GRMP.

I was speaking of limitations I had found working with GSMP, another 
master-slave protocol,  not GRMP.   As the information in the so called 
slave got more complex with optical switching we had the to stretch the 
notion of what a 'slave' was permitted to do and to communicate or its 
own initiative.  At times it felt awkward.

But I really just wanted to put this topic on the table for a later 
timely discussion.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Mar 2004 08:42:35 -0500

> this should also be on the topics for discussion.

We should definetely add this to the list of discussions.
I am resending the list below:

0) ID on the header.
1) Encoding
2) Multiple channels/connections
3) Transport: unicast/multicast/broadcast 
{ TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 
4) Congestion control
5) Reliability
6) Security
7) High availability
8) Capability exchange
9) The FEM/CEM interface
10) Support for vendor functions
11) Cross check with model draft before it is published
12) Master Slave or peer-peer?

I personally dont think we should care what the model or
requirements draft says. What we want to have is a good
protocol (as an example there are a few issues not mentioned
in the requirements already on the list above).
For this reason i feel like scratching issue 11 from the list.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 13:54:21 -0600

Hi Avri,

Could you give more details on thge type of limitations you encountered 
while working
with Master/Slave model?  That will really help us.

Thanks,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 14:31:29 -0600

Hi Avri,

You can ignore my previous e-mail requesting for more info on your 
concerns about
Master/Slave protocols. I see that you have provided adequate response 
as seen below.

Sure we can debate the merits/de-merits of peer-to-peer  vs 
master/slave. But you have
to chose the protocol that models the environment or system you are 
trying to distribute.
Certainly, the CE has control of the entire NE. So it is the master. It 
also has the final
say as to which FE leaves the NE group and when. Say an active FE1 is 
being removed
from service. There is a redundant FE2 that is inservice. A typical 
scenario will be as follows:

1) FE1 tells its CE that it is about to go out of service.
2) CE gets the message, informs FE2 to go active to replace the outgoing FE1
3) FE2 receives the message, goes active and sends an ACK to CE.
4) CE then sends an ACK to FE1 telling it that it can now go out of service.

If we don't do this,  FE1 could go out of service and cause a break in 
service.
The fact that FE1 doesn't do anything unless its been told by CE to is 
the precept
of master/slave control.  You can't have a slave doing things 
independently at random.

This is just one example,..and we can find many other scenarios to  support
the fact that peer-to-peer model is not ideal for ForCEs.  For example,  can
an FE cuase a CE to be removed?  Who determines  who's to join the NE 
group? etc

Regards,
Alex.

[email-masked] wrote:

>> are masters." Do you mean that we should change this framework protocol?
>
>
> being presented.  As far as I understand it netlink2 is using a peer 
> to peer model of communications while Fact and GRMP are using a 
> the other, but rather in the protocol messaging and in who can 
> initiate an exchange of info.
>
>>
> master-slave protocol,  not GRMP.   As the information in the so 
> called slave got more complex with optical switching we had the to 
> stretch the notion of what a 'slave' was permitted to do and to 
> communicate or its own initiative.  At times it felt awkward.
>

---

From: Alex Audu <[email-masked]>
Date: Mon, 08 Mar 2004 14:34:36 -0600

Jamal,

We can't ignore the model. It feeds into the the protocol work.

Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Mar 2004 15:38:05 -0500

Folks,
Could we please hold onto getting into this issue?
It is listed as issue #12 at the moment.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Mar 2004 15:43:14 -0500

Alex,
As Ellen pointed out: addressing it does not stop us from
reaching a consensus on a merger.
Do you think we should still keep it? another way to do it is
to make it the lowest priority then if we never get to it it wouldnt
matter.

cheers,
jamal

---

From: "Ligang Dong" <[email-masked]>
Date: Tue, 9 Mar 2004 08:38:28 +0800

hi,

From the view of the administration, the CE is the master and the FE is the slave. 
In other words, the CE takes the responsibility of administrating the FEs. 
Without the administration (e.g., asking the FE to upload the LFB) of the CE, the FE without any LFBs can do nothing. 
Furthermore, this kind of master-slave does not exclude that the FE initiates an exchange of info. , 
which is already supported in GRMP.
Obviously, the scenario in the ForCES protocol is closer to master-slave model than the peer-to-peer model.

Besides, till now, the limitation, which you described about GSMP, of the master-slave model has not happened in the ForCES protocol. 

dong

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Mar 2004 07:42:11 -0500

Last day before a response is due to the WG.
I think we made some great progress and i have no doubt givent the
current atmosphere consensus will be reached.
Do we have to give a detailed response to the WG or can we 
just say "consensus for a merger has been reached"?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 19 Mar 2004 23:00:56 +0800

I suggest first try to just say it, then if there are several differences, we
may need to go to details to judge it.

Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Mar 2004 10:44:17 -0500

> may need to go to details to judge it.

This is also my line of thinking. No point in being too verbose
especially if we are still disecting things.

cheers,
jamal

---

From: [email-masked]
Date: Sat, 20 Mar 2004 01:00:02 +0900

I think it may be worth saying that the groups believes it can reach a 
merge (assuming everyone in the team thinks so and is willing) and then 
following up with a report of where consensus is being reached and 
where there are open issues.  Could be good to see some discussion of 
some of the thornier issues on the full list.

And then of course there is the issue of figuring out how to do the 
merge and then doing it.

a.