headers
Wang,Weiming | 7 Sep 2007 19:45
Picon
Favicon

Re: Model terminology issue

Joel,

If you need any help on the text work that we may help, please just let us know. 

thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <joel <at> stevecrocker.com>

> The basic change is to refer to the pieces as components.  I have to 
> go through the document and see how many variations on that term I need.
> I will send an email to the list with the exact terms.  I will get 
> this done by this weekend.
> 
> Joel
> 
> At 05:31 PM 8/23/2007, Avri Doria wrote:
> >hi,
> >
> >you did not ask, but i can make the changes to the protocol draft.
> >
> >btw,  what are we changing them to?
> >
> >a.
> >
> >On 23 aug 2007, at 07.02, Patrick Droz wrote:
> >
> >>here is an extract of the minutes from the last IETF:
> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
B. J. Kang | 12 Sep 2007 13:19
Picon

ForCES Protocol Implementation Issues

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?

    2.In Appendix D, there are a lot of use cases. But I want to clean contents 
of a table, how can i do?

    3.If I use KEY_INFO to search data, then three rows are matched,what is 
the result about "DEL", "SET", and "GET"？all are set, deleted, or only one row?

    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?

    5.Are there some information about routing tables synchronization between 
CE and FE? I think that it is a important issue, isn't it?

Can anyone give me hints about these? Thanks a lot
Permalink | Reply | 2 comments |
headers
Joel M. Halpern | 12 Sep 2007 15:37

Re: ForCES Protocol Implementation Issues

I can comment on a few of these items.

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?
>
>     2.In Appendix D, there are a lot of use 
> cases. But I want to clean contents
>of a table, how can i do?

If you want to reset the contents of a table, 
simply make the table (not an element of the 
table, but the table itself) the target of a SET 
operation, and provide the contents you want to 
set it to  (including a 0 length content, which will create an empty table.)

>     3.If I use KEY_INFO to search data, then three rows are matched,what is
>the result about "DEL", "SET", and "GET"¡Hall 
>are set, deleted, or only one row?

KEY_INFO will always select just one entry.  It 
is an error to try to create a second entry with 
KEY_INFO that duplicates an existing entry, and 
the FE is required to detect the error and prevent the creation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jamal Hadi Salim | 12 Sep 2007 16:43

Re: ForCES Protocol Implementation Issues

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?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
B. J. Kang | 13 Sep 2007 06:50
Picon

Re: ForCES Protocol Implementation Issues

On Wed, 12 Sep 2007 09:37:58 -0400, Joel M. Halpern 
<joel <at> stevecrocker.com> wrote:

>I can comment on a few of these items.
>
>At 07:19 AM 9/12/2007, 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?

I have already seen both the article "Protocol" and "Model",but i don't see any 
more information about this(FEO Adminup). I have read them and tried to 
implement them about several mouths, may I lose some thing? 

>>
>>     2.In Appendix D, there are a lot of use 
>> cases. But I want to clean contents
>>of a table, how can i do?
>
>
>If you want to reset the contents of a table, 
>simply make the table (not an element of the 
>table, but the table itself) the target of a SET 
>operation, and provide the contents you want to 
>set it to  (including a 0 length content, which will create an empty table.)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joel M. Halpern | 13 Sep 2007 08:04

Re: ForCES Protocol Implementation Issues

For every table (array) in a Forces Object there is a properties 
object (accessible via the protocol) which includes the first free 
table entry, as well as the last used table entry.  So the 
information the CE needs is always available.
In fact, since the CE generally created the table, and created the 
entries, it is anticipated that the CE will normally have a mirror 
copy with any annotation information it wants, obviating the need to 
query these fields.

Yours,
Joel M. Halpern

At 12:50 AM 9/13/2007, =?BIG5?Q?B._J._Kang?= wrote:
>If I want to add a new route, I must to know which row is free. This 
>is a funny
>thing. With MySql, I can only assign the data and don't care about which
>entry is free. Using the ForCES Protocol, operations with tables may be a
>difficult thing? I think it is unreasonable, isn't it?
Permalink | Reply | 0 comments |
headers
SUBSCRIBE FORCES B. J. Kang | 13 Sep 2007 08:59
Picon

Re: ForCES Protocol Implementation Issues

On Thu, 13 Sep 2007 02:04:42 -0400, Joel M. Halpern 
<joel <at> stevecrocker.com> wrote:

>For every table (array) in a Forces Object there is a properties
>object (accessible via the protocol) which includes the first free
>table entry, as well as the last used table entry.  So the
>information the CE needs is always available.
>In fact, since the CE generally created the table, and created the
>entries, it is anticipated that the CE will normally have a mirror
>copy with any annotation information it wants, obviating the need to
>query these fields.
>

What you mean is that I can get the information about which row is free 
without getting all the contents of a table to find the index of free rows?

Because I try to implement Failover, I can not think that Backup CEs have the 
mirror copy of all FEs.

Thanks a lot

>Yours,
>Joel M. Halpern
>
>At 12:50 AM 9/13/2007, B. J. Kang wrote:
>>If I want to add a new route, I must to know which row is free. This
>>is a funny
>>thing. With MySql, I can only assign the data and don't care about which
>>entry is free. Using the ForCES Protocol, operations with tables may be a
>>difficult thing? I think it is unreasonable, isn't it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 13 Sep 2007 16:35

Re: ForCES Protocol Implementation Issues

On Thu, 2007-13-09 at 00:50 -0400, B. J. Kang wrote:

> I have already seen both the article "Protocol" and "Model",but i don't see any 
> more information about this(FEO Adminup). I have read them and tried to 
> implement them about several mouths, may I lose some thing? 

FEO LFB belongs to the model; the text in the protocol mentions it in
passing and not in greater detail. Sorry, I should have been more
specific in my response to you:
Section 8.2 of version 7 of the model talks about FEO LFB attribute
FEState which is of type FEStatusValue that contains a possibility of
setting Admin to disable or operational status to on/off. "Admin up" is
intended to mean configuring that attribute to Admin enabled.
The discussion as i recall was to not have adminEnable enumeration
because operational enable in this case implied Admin enabled.
Looking at the model draft i saw that FEState is defined as read-only. 

So you actually bring two issues that need to be fixed:
1)Since the model is still being edited, I think we need to change that
control to be read-write instead of read-only. Does that make sense
Joel?
2) Since this has caused some headache, to avoid the next person having
the same issue, the protocol needs to be very explicit

I have tried to open tracker issues but it seems down; 
Joel, Avri - i guess the only way to keep track of this is write it down
somewhere?

In any case, B. J. Kang, thanks for bringing these issues up.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 13 Sep 2007 16:42

Re: ForCES Protocol Implementation Issues

On Thu, 2007-13-09 at 00:50 -0400, B. J. Kang wrote:

> >If you want to reset the contents of a table, 
> >simply make the table (not an element of the 
> >table, but the table itself) the target of a SET 
> >operation, and provide the contents you want to 
> >set it to  (including a 0 length content, which will create an empty table.)
> >
> 
> Thanks for your answer. But it is a normal solution, or a trick?

No, it is not a trick - rather design intent.
If you look at the examples, you will see some that dump the whole table
with GET operation. Likewise a table flush/delete will be of the same
nature with the appropriate operation. The path points to the object,
the operation says what to do.
Do you think we need to be explicit on this issue?

cheers,
jamal
Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 15 Sep 2007 18:20

Re: ForCES Protocol Implementation Issues

If we want the FEState to be the way that a cE administratively 
disables and FE, then we would need to make a larger change.  When I 
drafted the FEState component, my expectation was that 
administratively disable would reflect non-Forces interaction, such 
as a "disable" CLI command.
Given that the other two values (operationally disabled and 
operationally enabled) can not be used as the value in a set 
operation, I think that to change this we would have to create two 
separate variables, a read-write admin-status and a read-only 
operation-status.  (I thought we had that at one point and decided 
not to keep it, but I could be confused.)

Yours,
Joel

At 10:35 AM 9/13/2007, Jamal Hadi Salim wrote:
>On Thu, 2007-13-09 at 00:50 -0400, B. J. Kang wrote:
>
> > I have already seen both the article "Protocol" and "Model",but i 
> don't see any
> > more information about this(FEO Adminup). I have read them and tried to
> > implement them about several mouths, may I lose some thing?
>
>FEO LFB belongs to the model; the text in the protocol mentions it in
>passing and not in greater detail. Sorry, I should have been more
>specific in my response to you:
>Section 8.2 of version 7 of the model talks about FEO LFB attribute
>FEState which is of type FEStatusValue that contains a possibility of
>setting Admin to disable or operational status to on/off. "Admin up" is
>intended to mean configuring that attribute to Admin enabled.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane