Subject: Re: Table model and config operators in ForCES rev. 2

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

Hi Zsolt,

Thanks for your prompt reply!
Pls see my comments below... 

-----Original Message-----
>
> The one comment I did have is for some of the operations '!' seemed to
> change the semantics of the operation. My understanding from the text
> was that the basic reason for Operation! is to say that no error
> reporting or response is needed for that particular operation.
However,
> the text seemed to imply that the operation behaved different with !,
> which is not a good idea...the semantics should be
consistent...Example,
No, the "!" version has very little to do with the suppressed error
feedback.  (The "!" notation may have been misleading..., sorry.)

The SET! does what the text says: execute the SET request even though
the entry does not yet exist (essentially creating it).  Or in
case of INS!, overwrite the entry if it already exists.

The SET! and INS! operators are semantically redundant (identical),
but the SET, INS, and SET!(=INS!) operators represent three different
configuration request semantics.  (Irrespectively how it is mapped
to protocol syntax.)

[HK] Thanks, this clarification helps, I got a very different impression
from your text.
I think all you need is ADD==INS and UPDATE==SET!, I am not sure if just
SET is really needed ??

> 4.1.6  SET
> If table[idx] exists, overwrite  its  content  with  provided  <data>,
> report error otherwise.
>
> 4.1.7  SET!
> If table[idx] exists, overwrite  its  content  with  provided  <data>,
> create new entry with idx otherwise.-> SET/UPDATE should either do
this
> in both cases or none at all. The only thing different with ! is that
> the error reporting is not needed back to the CE.
>
> Let me know your thoughts ?
>
> Another point that Jamal was also making, regarding index being part
of
> the entry definition itself...I agree with this...Example, I see
>
> SET <path>, idx, <data> ...being encoded in the protocol msg as
> SET <path>, <data-including idx>
>
Again, that is a syntax issue.  Semantically it is still a separate
peace of information that you need to carry.

But since you brought it up, what do you mean by <data-including idx>?
Whatever you do, that <data-including idx> = idx, <data>, so the SET
message will be:
        SET <path>, <data-including idx> = SET <path>, idx, <data>
What is the difference?  Are you reading TLV boundaries or design
group boundaries into the grouping?

[HK] Yes, I was thinking more along the lines of adding an array of
entries in terms of the protocol messages, TLVs, etc...I agree with your
explanation.

Thanks
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Oct 2004 09:30:54 -0400

I just realized something else:
With separation of index into a separate clause, it means table
operations are restricted to row operations.
In other words, i couldnt operate on foo1 of row index 2; i would
need to operate on row index 2. Perhaps one of the block operations
covers this scenario? or maybe we need one?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 Oct 2004 09:44:29 -0400

Given an LFB class with a table (array) of structures, where the structure
contains an element foo, it is necessary that the protocol operation be
able to reference the foo element of the structure at table entry 1.
It is also necessary that if the table (t) contains a structure which
contains a table (u) with a structure containing an element bar, I need to
be able to get to the bar within the second element of the u in the third
entry in t.
We need to be able to reference
lfb_instance: faa (a top level element
lfb_instance: t[1] (a table entry)
lfb_instance: t[2].foo (a structure element in a table entry)
lfb_instance: t[3].u[2].bar

I prefer to do this by including the indices in line with the element
selection.  This seems to work naturally with uint32 indexes.

It does not bother me if content selection can not be used this way.  (I
believe the result would be that most implementation would only use content
addressing for the rare reverse translation needed to check the CE table
structures.)

Yours,
Joel

---

From: Zsolt Haraszti <[email-masked]>
Date: Fri, 8 Oct 2004 10:40:43 -0400

> operations are restricted to row operations.

As opposed to what?
(1)  Multi-entry operations (multiple rows)
     Or...
(2)  Operation in a single field of a table entry (row) when
     the table entry is a struct?
     Or...
(3)  Operating on a subset of fields (more than one field,
     but not the whole struct) in a struct-type table entry?

(1) and (2) are both supported.   The block operations are
intended to support (1). (2) is supported by specifying the
field, also by an index, as part of the path.  (Using Joel's
Class A example, the path (2, 8, 1) specifies the string field
(named N) in struct "star" in the idx=8 entry of table C.)

> covers this scenario? or maybe we need one?

What is not explicitly supported yet is (3).  To illustrate
this let me extend the star struct in Class A in the following
way:
        struct star {
        [1]     string[32]      N
        [2]     array of {
                   int32   X
                }               Arr
        [3]     int32           Y       # new field
        [4]     uint32          Z       # new field

So what is not supported is a compact operation to set, e.g.,
N and Y (without affecting the other fields).
You can of course use two separate SET operations, i.e.,
SET path=(2, 8, 1) "spinoza"
SET path=(2, 8, 4) 0xdeadbeef
and that may be sufficient.  Other options would include
extending the block operations to structs (was that what
you Jamal referred to?).

Cheers,
Zsolt
--
Zsolt Haraszti                Phone:  +1 919-765-0027/2017
Modular Networks              Mobile:      +1 919-522-2337
                              Email:  [email-masked]

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Oct 2004 11:21:10 -0400

> (named N) in struct "star" in the idx=8 entry of table C.)

Ok, so 2 is covered. It was actually what i was referencing in my email.

2 is a subset of 3 - so how to extend the constructs of 2 to cover 3?
3 is very legit need - think updating a set of NH pointers in a LPM
table to point to new NH.

> extending the block operations to structs (was that what

I think if you could select a row block, then you should be able to
select a column block in the same manner. In otherwords, a 2 dimension
matrix operation with each dimension possibly being a block/range.
This should cover all possible scenarios. This assumes that the Ids in
the class definition are being sequentially allocated.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Oct 2004 11:19:35 -0400

> selection.  This seems to work naturally with uint32 indexes.

   That is reasonable.

> It does not bother me if content selection can not be used this way.

   I think this was discussed earlier.  Content selection should be done
ONLY on the leaves of the tree referencing element(s).  The alternative
is to be able to express things like "arrays looking like FOO, with
elements looking like BAR, with sub-elements looking like BAZ".

   There may be many entries returned.  And not all of them may be of
the same type.  e.g. "find elements containing IP address 1.2.3.4".
There may be routing table and ACL table entries which match that request.

   Restricting addressing to known structures and indexes ensures that
the returned results are managable, and knowable.

   Alan DeKok.