Subject: Re: [issue 9] Fix LFB definition

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 19 Jan 2006 15:27:43 +0800

The issue is closed as being accepted.

Weiming

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 18, 2005 11:40 PM
Subject: Re: [issue 9] Fix LFB definition

> Hi,
>
> The LFB class definition has been modifed in the protocol draft as
> below:
>
> LFB (Logical Functional Block) Class (or Type) -- the basic building
> blocks that are operated on by the  Forces protocol. The LFB is a well
> defined, logically separable functional block that resides in the FE and
> is controlled by the CE via ForCES protocol. The LFB may reside at the
> FE's datapath and process packets or may be purely a control entity that
> is operated on by the CE.
>
> Thanks,
> Weiming
>
> ----- Original Message -----
> From: "Deleganes, Ellen M" <[email-masked]>
>
> I am also fine with this definition.
>
> Regards,
> Ellen
>
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Wang,Weiming
> Sent: Tuesday, August 16, 2005 8:38 AM
> To: [email-masked]
> Subject: Re: [issue 9] Fix LFB definition
>
> ----- Original Message -----
> From: "Jamal Hadi Salim" <[email-masked]>
> > BTW, I am really suprised at the weak definitions of LFB; i just
> glanced
> > at model and framework docs.
> >
> > Probably you want to emphasize the following:
> > - it resides at the FE (since we killed CE based LFBs)
> > - it _may_ process packets
> > - it is managed/controlled by the CE
> >
> > i.e something along:
> > "LFB classes are the basic building blocks that are operated on by the
> > Forces protocol. The LFB is a well defined, logically separable
> > functional block that resides in the FE and is controlled by the CE
> via
> > forces protocol. The LFB may reside at the FEs datapath and process
> > packets or may be purely a control entity that is operated on by the
> CE"
>
> I'm fine with the definition. How about model team thought? We need to
> be consistent between the protocol and the team on the definition.
>
> Jamal, when it is solved, I will immediately modify the definition in
> the protocol draft.
>
> Thanks,
> Weiming
>
> >
> > cheers,
> > jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 19 Jan 2006 15:36:03 +0800

The issue is to be closed as being rejected in one week if theres no further
comments.

thanks,
Weiming

-------------
Comments
Comment #394
[email-masked]
2005-11-25.08:24:36
removeDavid,

I think what FE needs to know is just the CE Heartbeat Dead Interval(CE HDI)
rather than the CE heartbeat interval, because the parameter does not make any
sense to FE for its use. This also means CE does not have to set the parameter
in the FE Protocol LFB definition.

Thanks,
Weiming

Comment #369
[email-masked]
2005-11-14.20:26:43
removeI could not find where the CE heartbeat interval (must be shorter than the
CE
HDI) was stated, nor could I find a place to set it. So this is still an open
issue.

Comment #354
[email-masked]
2005-10-23.16:50:31
removeresolved in draft -05

Comment #127
[email-masked]
2005-06-10.14:58:24
removesuperceeded by Issue 37 decsion to remove requirement for LFP protocol
LFB.
Need specifc text on default heartbeat intervals

[who to privide text?]

Comment #57
[email-masked]
2005-05-22.18:57:58
removeC.3.2  HBDI

   This attribute carries the Heartbeat Dead Interval in millisecs.

   TBD:
C.3.2

   The original goal for HBDI was for HA purposes - to discover if the
   CE is still around by sending a heartbeat message to the CE with an
   ACK flag in the mainheader to request for a response.  This hasnt
   been discussed in details yet; however, the general view at the time
   was for the FE to associate (failover) to another CE after that
   deadinterval period of not hearing from the CE - as defined by policy
   which resides in that same LFB definition.  Two such failover
   methodologies are mentiooned briefly infact in the protocol draft but
   since the current attributes are unknown, the details are missing
   from the xml.