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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 8 Mar 2004 21:55:05 -0800

Yes, I agree. Its getting difficult to follow 3 different discussions at
the same time. If we continue in this random fashion, it will be
difficult to make progress.

Regards 
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, March 08, 2004 12:38 PM
To: [email-masked]
Cc: [email-masked]; Ligang Dong; [email-masked]
Subject: Re: [Forces-protocol] Future question for the discussion

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

cheers,
jamal

On Mon, 2004-03-08 at 15:31, Alex Audu wrote:
> 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:
> 
> >
> > 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.
> >
> >>
> >> Besides, can you give more detail about the limitation of the 
> >> 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.
> >
> >
> > _______________________________________________
> > Forces-protocol mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/forces-protocol
> 
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol

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

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