Subject: RE: [Forces-protocol] topic 2:: HA

From: [email-masked]
Date: Tue, 27 Apr 2004 16:25:08 -0400

Hello All,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext [email-masked]
> Sent: Tuesday, April 27, 2004 2:09 PM
> To: [email-masked]
> Subject: Re: [Forces-protocol] topic 2:: HA
> 
> 
> Hi Weiming,
> 
> On 27 apr 2004, at 11.29, Weiming Wang wrote:
> 
> > Hi Avri,
> >
> > I may have an opinion different  from yours on multi-CEs . 
> I think the 
> > CE-CE
> > communication is fundamental for multi-CE parallelly 
> working scenario 
> > to work.
> 
> I guess I don't see this as necessary, though it does make it easier.

<RamG>
Most  of the network intelligence and services (like Routing,QoS, Mobility, Security) logic
operates from CE. Hence the CE-CE consideration is good. 
<RamG>

> 
> > As far as I can think of currently, I can not reach  other better 
> > means than
> > CE-CE direct communications for inter-CE state 
> syncronization. I'm not 
> > sure if
> > you have a better approach for this issue.
> 
> I am not going to argue it is better, but rather it is a scheme for 
> making things work in the absence of CE-CE communications.
> 
<RamG>

You have to remember that most of the mangaement interfaces (SNMP or CLI) talks to CE, using CE-CE has been
adopted in various products and also in various standards.

<RamG>

> Basically an FE is responsible for informing all CEs it has 
> association 
> with of which other CEs it is in association with - sending 
> notification every time a new association is created or is lost. This 
> way all CEs know who else is talking
> 

<RamG>
What you are giving is one possible approach. But CE-CE is one of the important aspect also.
<RamG>

Regards
Ramg

> Additionally an FE needs the capability to report it state to an CE.  
> So any CE in association can request a reporting of the FE 
> state (this 
> is needed in general, not just for this purpose - I think)
> 

> > Pls also see some more reply inline.
> > Thank you.
> >
> > Weiming
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> >>
> >> On 27 apr 2004, at 08.56, Jamal Hadi Salim wrote:
> >>
> >>> On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote:
> >>>
> >>>> At any time there is one Primary CE controlling the FE 
> and there can
> >>>> be
> >>>> multiple secondary CEs. The FE PL is aware of the primary and
> >>>> secondary
> >>>> CEs. This information (primary, secondary CEs) is 
> configured in the 
> >>>> FE
> >>>> during pre-association by FEM.
> >>
> >> I am not sure I agree with this since there could be a 
> load share or a
> >> specialization opportunity that doing this would prevent.
> >
> >>
> >>>>
> >>>> [Weimng] Then the TML in FE knows the redundant CE id 
> list, but how
> >>>> the PL knows
> >>>> this? And we should also let CEs (primary and redundant 
> ) know all
> >>>> the redundant
> >>>> CEs' ids, so that CE can send 'move' command to FE.
> >>>
> >>> Maybe we can have information advertised in some protocol message?
> >>> Perhaps a "config" message is needed if we are not going 
> to have an
> >>> always-on FEM-CEM.
> >>
> >> I don't think the FE should, or even can, count on CE-CE
> >> communications.  I also think that secondary CE could establish
> >> adjacency with an FE at any time during the operation of the NE.
> >>
> >> One way to deal with this is to have a FE announce any CE 
> rlatioship 
> >> it
> >> establishes to the CEs.  this way, even if there is no CE-CE
> >> communucation, at least the CE will know who else is 
> talking to an Fe.
> >>
> > [Weiming] If there is no CE-CE comm., the CE has to do from scratch 
> > (only with
> > the FE providing some limited  state infomation). In this 
> case, it's 
> > of very
> > little help for the CE to even know who the FE used to talk with.
> 
> [ad] I agree that knowing who had been Primary (assuming 
> there is only 
> a single primary) is not as useful in this case.  Still the Fe should 
> be able to supply a rather complete picture of its state if so 
> required.
> 
> 
> >>>
> >>>> In order to support fast failover, the FE will establish 
> association
> >>>> (joining) as well as complete the capability exchange with the 
> >>>> Primary
> >>>> as well as Secondary CEs.
> >>>>
> >>>> [Weiming] FE joining is needed for secondary CE, but the 
> capability
> >>>> exchange
> >>>> not, because we can assume at this time, the secondary CE has 
> >>>> already
> >>>> had the
> >>>> information via the CE-CE syn. mechanism.
> >>>
> >>> Makes sense.
> >>
> >> I do not believe we can count on this.
> >>
> > [Weiming] I think the "copy" mode between CE-CE is the 
> simplest mode 
> > for
> > syncronization. If we even can not count on this 'copy' 
> mode,  we may 
> > also not
> > able to count on other modes to parallel the CE states. I 
> think to do 
> > like to
> > let FE broadcast to other redundant CEs actually also only 
> let the CE 
> > partially
> > know something instead of everything.
> 
> 
> [ad] Yet even that mode is not fool proof since there may be a gap 
> between the last CE copy state operation and the time of the failure.
> 
> [ad]Please note I am not saying that CE-CE coordination is not a good 
> thing, I just don't think it should be required and even if 
> required I 
> don't see it as infallible.  There still needs to be a way to 
> query the 
> FE to show its complete state and it still has to be up to the FE to 
> inform its CEs of new CEs in the mix..
> 
> 
> 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

---

From: [email-masked]
Date: Tue, 27 Apr 2004 22:04:17 -0400

> What you are giving is one possible approach. But CE-CE is one of the 

[ad] Yes, CE-CE is a possible approach, and yes it is used frequently. 
But it does not guarantee coordination and is not currently in the 
charter.  My argument is that we should provide the functionality to 
make ForCES work even in the absence of CE-CE communications.

a.