Re: ForCES Protocol Implementation Issues

[Jamal Hadi Salim <[e-mail]>]

On Wed, 2007-12-09 at 09:37 -0400, Joel M. Halpern wrote:
> I can comment on a few of these items.
>

more comments:

> At 07:19 AM 9/12/2007, =?BIG5?Q?B._J._Kang?= wrote:
> >I try to implement the ForCES Protocol, but i have some implementation
> >problems.
> >
> >     1.In the article
> > "draft-ietf-forces-protocol-11", Figure 8, it says that CE
> >can send a "Config FEO Adminup" message if FEs got ready. But I don't see
> >any more information about this? Can anyone show me about the detail of
> >starting a fe?

The paragraph above that diagram tries to describe things.
Unfortunately you need to know what the base LFBs are before you can
implement anything. The paragraphs above refer you to the Model draft.
I would suggest looking at both the model and the protocol drafts at the
same time.
LFBx implies some LFB called "x". FEO implies FE Object LFB. "Config FEO
Admin up" is as described in the paragraph above meant to have the
setting of the FEO LFB Admin Status attribute set.
If this is not sufficient description please make some suggestions.


> >     4.If I want to add a new data to a table,
> > but i don't want to use index (to
> >know which row is free), how can i do?
>
> As I recall, the CE is currently required to pick
> the entry.  There was an operation that would
> just use the next free entry, and return the
> index in the results, but as I recall we removed
> that as excessive complication.  (I don't have
> time to check carefully on this, sorry.)

This is accurate as per my recollection.

> >     5.Are there some information about routing
> > tables synchronization between
> >CE and FE? I think that it is a important issue, isn't it?
>
> The FEs controlled by a CE inherently lack the

I am sure you mean "lag" instead of "lack"

> CE.  But not by much.  It is actually the case
> even in real world routers that the actual
> operational FIB lags the results of the routing
> calculation.  And those calculations lag the
> routing updates, which lag the causes ...  Or, to
> put it another way, such lags are considered very normal and not a problem.
>

I would also add that when you do a routing/forwarding LFB(s), you would
worry about such issues. i.e this is not to be taken care of by the
protocol; the protocol provides the mechanisms for synchronising but the
LFB defines the data that needs to be synchronised.

cheers,
jamal