Subject: [Forces-protocol] RE: updated notes on BNF and layout

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 7 Oct 2004 12:02:16 -0700

Jamal, Joel,

This looks very good, I am glad you guys have worked out your
differences. Thanks for the effort!
It is also in line with the text that Steve, Zsolt have sent out.

The next thing that needs to be done, I think is the protocol team
should start working on the draft, having conference calls, etc. if
needed. The deadline for the draft submission is 25th Oct so we should
shoot to have something by the 22nd. Anyways I will send out an email to
the protocol team to discuss this in more detail.

Thanks again & regards
Hormuzd 

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Thursday, October 07, 2004 9:37 AM
To: Joel M. Halpern
Cc: [email-masked]; Steve Blake; [email-masked];
[email-masked]; Khosravi, Hormuzd M; [email-masked];
Yang, Lily L; [email-masked]; Alan DeKok; Deleganes, Ellen M;
[email-masked]; Robert Haas
Subject: updated notes on BNF and layout

Joel and myself have put an update to the earlier doc. Its now a
singular view. The issue on the tables and attribute update is open
pending on discussions on the table doc currently being discussed.
The decision on how things get laid out is in the hands of the protocol
team although this document bridges a lot of the views between the model
and the protocol side of things and so is a very good start.

Lets please start the ball rolling again on this and discuss.

cheers,
jamal

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

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 11 Oct 2004 10:54:46 -0700

Jamal,

-----Original Message-----

> Structuring the address into a 
> [<class-id>:<instance-id-within-that-class>] serves only a secondary
> purpose: diagnostics.  I think it is a good purpose.  I do not really
> like to bloat the id to 64-bit just for that purpose, but I can live
> with that, AS LONG AS THE ID APPEARS AS ONE 64-BIT BLOCK IN THE
> PROTOCOL.  I think it is a very bad idea to split the 64-bit id into 2
> separate TLVs.  Many entities involved in the ForCES protocol handling
> will not care about the class and would like to treat the LFB instance
> ID as a flat logical address.  For these, it is a benefit if the id is
> in one continuous block in the PL payload.

Ok, folks - how about we move forward assuming the two are in the same
TLV. There are bigger issues to be tackled and i think time spent on
this has exceeded its value threshold(I am using the term "I" since i am
the only one it seems arguing for the separation). 
I will update the doc.
So 32 bit (16:16) or 64 bit (32:32)?
 
[HK] Thanks for coming to an agreement on this. I agree there are bigger
issues, not sure why we spent so much energy on this one. Lets go with
16:16 for now, we can always change this in later versions of the draft
if absolutely needed. So essentially, the draft needs no update on this
issue :-)

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 11 Oct 2004 23:34:53 -0700

Joel,

Based on my implementation experience, I must say that Weiming has
pointed out some very good points regarding indexing as is being
proposed currently. I have to agree with the points that Weiming is
making.

On 1, if you have a small table, if needed you can query the entire
table, thus you don't need any indexing.

On 2, I think you have misunderstood Weiming's point, but I may be
wrong. In any case, in the example that you have given there is no need
of indexing atleast in the Query/Get operation since the CE would like
to get the entire table that has been created on a FE during
initialization, not individual entries.

On 3, using indexing defined in the FE model e.g., as part of the data
structure which defines an entry in a table, will be a lot easier to
manage in the protocol than having it separated as part of the <path>
before the actual data.

Anyways these are just some clarifications, based on my point of
view...i am fine with the current scheme if most of you think its
necessary.

regards
Hormuzd

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, October 11, 2004 8:10 PM
To: Wang,Weiming; Khosravi, Hormuzd M
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Yang, Lily L; Alan DeKok;
Deleganes, Ellen M; Robert Haas; Steven Blake; [email-masked]
Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout

I suspect I am missing some useful ideas you are trying to communicate, 
because I am not following the items you list.

With regard to item 1, indices are needed for small tables and for big 
tables.  The appropriateness of direct indexing versus content indexing
is 
quite independent of table size.

With regard to item 2, my point is hat in order for the CE to be able to
go 
through and extract the contents of the table, there must be direct 
(non-content) indices.  This extraction is necessary since the FE may 
initially have created table entries for any tables, and the CE needs to

know about these.  (It becomes even more important in failover
scenarios, 
but since we have not spelled those out, I want to be cautious about
using 
those to justify anything.)
In some sense, these tables are limited.  In order to avoid needing to 
create the equivalent of SNMP get next, we need something whose behavior
is 
more predictable than arbitrary indices.

With regard to item 3, I believe that if we just use 32 bit indices, the

protocol can be greatly simplified.  We simply include the index in the 
appropriate position in the element selector.
So if item 1 of an LFB is a table, then 1.7 is the 7th entry in the 
table.  If the table includes a strucutre, which is an item 2, then
1.7.2 
is the element selected by tag 2 from th structure at the seventh
position 
of the array selected by tag 1.  And so on.
This allows a single, simple mechanism to reference any element within
an 
LFB, no atter how many arrays or structures it is nested within.
Assuming we can assign suitable identifiers for the related properties
of 
an array (which I believe is also easy) we can get away with a small
number 
of operations for the entire LFB element operation suite (GET, SET,
CREATE 
and DELETE for array entries).

Yours,
Joel M. Halpern

At 10:42 AM 10/12/2004 +0800, Wang,Weiming wrote:
>1. Sometimes, especially for some very small tables, we do needn't
index, but
>if we use protocol index, we then have to use it.
>2. Make the index definition quite limited and inflexible.
>For instance, I'm not sure if the protocol index is global in all FEs
or 
>not. If
>not, then form the case where there is a main table in CE while
scattered 
>tables
>in FEs, the maintainance of Index may become very complicated. On
contrary, if
>the index is defined by FE data model or even by users, we may have
more
>flexible scheme to deal with this, e.g., using segmented Index.
>3. Complicate the definition of protocols greatly.