headers
Joel M. Halpern | 1 Feb 2005 15:52

Re: updated path data text

Since things went momentarily quiet, let me take a crack at what I think we 
have discussed.

Weiming has asked for some efficiency in referencing related components.
I have asked that we use unique, pre-declared keys.
Jamal (and others I think) have asked for block operations.
We are still discussing where index (subscript) values go.  For this 
description, I am going to put them with content keys.
     I would really like to be able to put the common case of simple subscripts
     into the data path.  This can be done using a flag if we restrict content
     keying to the leaf reference.  As we do not have agreement on that, I am
     NOT including that in this description.

I think that would give:

OPER TLV := <PATH-DATA>+
PATH-DATA := <PATH> [DATAINFO]
PATH := flags IDcount <IDs>
DATAINFO := <SELECTOR>* <DATA>*
SELECTOR := BLKINFO | KEYINFO | IDXINFO
DATA := DATARAW | <PATH-DATA>+
KEYINFO := KeyID DATARAW
IDXINFO := uint32
DATARAW := encoded data representing ForCES LFB information.
     This can represent a simple value, a structure, a string, an array,
     or any other declared ForCES type.
     The questions of whether this is a packed representation, a TLV
     structure, or something else is a separable, and separate, discussion.

IDs are identifiers of elements of LFBs or structures.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joel M. Halpern | 1 Feb 2005 20:27

Re: updated path data text

Following up on this, I have been batting an idea for the path / index / 
key encoding back and forth.  The following changes the PATH and Selector 
encoding, with the goal of simplifying the common cases:

There is one more variation that occurs to me.  This is not what I sent to 
the list, and has some advantages and disadvantages.  Tell me what you think.

Suppose we declare that block and content indexing can only be applied at 
the end of a path. Given nesting, this does not restrict what can be 
described, just where one has to split the TLVs.
Then, we declare that indexes are included in the path sequence.

Suppose we take two flag bits, and declare the meanings as:
    00 last not a table (normal case), includes the case where the last
       is an indexed selection of a table element.
    01 last is the entire table
    10 last is a block selection from the table.  See BLK TLV
    11 last is a content keyed selection from the table, see KEY TLV
And the there is exactly one BLK or KEY TLV, and that is present only if 
the bits are set.
(Arguably, the 01 combination is redundant, but the bits are available and 
it provides clarity.)

So, to select x1 from table2 entry 4 inside table1 entry 10 we would have
OPER TLV
     PATH flag = 00, count = 5, IDS = 1.10.2.4.1
as we would like.

To select, from all table1s, the x1s of the 4the element of table2, we 
would have
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jamal Hadi Salim | 1 Feb 2005 21:47

Re: updated path data text

Looks very good and resolves the table of  tables issue i had.

Should cover both what i need as well as Weimings IMO.
I will run through all use cases later; and if we get an ACK from
Weiming i will fixup the doc with this update.

cheers,
jamal

On Tue, 2005-02-01 at 14:27, Joel M. Halpern wrote:
> Following up on this, I have been batting an idea for the path / index / 
> key encoding back and forth.  The following changes the PATH and Selector 
> encoding, with the goal of simplifying the common cases:
> 
> There is one more variation that occurs to me.  This is not what I sent to 
> the list, and has some advantages and disadvantages.  Tell me what you think.
> 
> Suppose we declare that block and content indexing can only be applied at 
> the end of a path. Given nesting, this does not restrict what can be 
> described, just where one has to split the TLVs.
> Then, we declare that indexes are included in the path sequence.
> 
> Suppose we take two flag bits, and declare the meanings as:
>     00 last not a table (normal case), includes the case where the last
>        is an indexed selection of a table element.
>     01 last is the entire table
>     10 last is a block selection from the table.  See BLK TLV
>     11 last is a content keyed selection from the table, see KEY TLV
> And the there is exactly one BLK or KEY TLV, and that is present only if 
> the bits are set.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 2 Feb 2005 06:04

Re: [3]Re: path data textt update

A typical key declaration would be in the array declaration.
For example, suppose we have
    structure foostruct
        ipv4address: id = 1, type = bytestring4
        ipv4prefixlength: id = 2, type = integer 0..32
        addressmatchclass: id = 3, type = int
        assoicatedinfo: id = 4, type = somestructure

Then in some LFB we have an array declaration
     lfbtable: id = 1, array, variable,
        type = foostruct
        key akey: keyid = 1, ipv4address, ipv4prefixlength
declares that the array has a key, made up of the ipv4 address and ipv4 
prefix length.  And the keyid for this key is 1  (The name akey is just for 
human consumption).
If there is another unique field or field combination that can be used as a 
key, that would be an additional key line.  Maybe somestruct has a entryid 
field, so we get
        key bkey: keyid = 2, associatedinfo.entryid
assuming that entryids are unique.

There is no need to declare the type of the key because the key is not a 
field distinct from those within the structure of the array 
element.  Rather, the key is a declaration about information within that 
structure.

Thus, when one finds a path that references lfbtable, with content keying, 
then if one finds keyid 1 in the keying TLV, the FE knows that the 
reference is to the ipv4address and prefix length, and that the data will 
be the combination of those two fields as if they were a structure.  If the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jamal Hadi Salim | 2 Feb 2005 12:07

Re: path data textt update

Weiming,

On Mon, 2005-01-31 at 09:34, Weiming Wang wrote:
> Jamal,
> 
> Pls allow me to reply your two posts in this one, because I see the focus is the
> same.
> 
> ----- Original Message -----
> From: "Jamal Hadi Salim" <hadi <at> ZNYX.COM>
> To: <FORCES <at> PEACH.EASE.LSOFT.COM>
> Sent: Monday, January 31, 2005 4:05 AM
> Subject: Re: path data textt update
> 
> >
> > KEYINFO does not set any value; it is merely describing how to search
> > and find what to delete.
> I see the points now. I think it is the Message Type and the Operation TLV Type
> together that will define "SET", "DELETE", or "QUERY"(which actually a find),
> rather than the operations will be implied by KEYINFO or SUBPATHINFO.   When the
> command is "SET", the SUBPATH-DATA defines the the fields and the data to be
> set. When the command is a "DELETE" or "QUERY", the SUBPATH-DATA or the KEY-DATA
> can  then be used as a content searching fields and matching data. Anyway, I
> think SUBPATH is only an expression instead of an operation, and a KEY is only a
> special field for searching.

What about SET | REPLACE? This is not DEL or QUERY ....
Example: "replace all entries which match key1=10 with 1111"
or "for all entries with KEY1=10.0.0.24/32, replace table.nh with value
3"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 2 Feb 2005 12:11

Re: [3]Re: path data textt update

For the record: This is fine with me. It also seems fine with Weiming.
The only remaining thing it seems is whether keyids need to be defined
as separate entities within the message. I think they should; i dont
think Weiming does so far. If we can resolve that we can close this
and i can go back to updating the doc (which will give us a chance to
progress to less contentious but nevertheless interesting issues).

cheers,
jamal

On Wed, 2005-02-02 at 00:04, Joel M. Halpern wrote:
> A typical key declaration would be in the array declaration.
> For example, suppose we have
>     structure foostruct
>         ipv4address: id = 1, type = bytestring4
>         ipv4prefixlength: id = 2, type = integer 0..32
>         addressmatchclass: id = 3, type = int
>         assoicatedinfo: id = 4, type = somestructure
> 
> Then in some LFB we have an array declaration
>      lfbtable: id = 1, array, variable,
>         type = foostruct
>         key akey: keyid = 1, ipv4address, ipv4prefixlength
> declares that the array has a key, made up of the ipv4 address and ipv4 
> prefix length.  And the keyid for this key is 1  (The name akey is just for 
> human consumption).
> If there is another unique field or field combination that can be used as a 
> key, that would be an additional key line.  Maybe somestruct has a entryid 
> field, so we get
>         key bkey: keyid = 2, associatedinfo.entryid
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 2 Feb 2005 12:16

Re: updated path data text

On Wed, 2005-02-02 at 06:02, Weiming Wang wrote:
> A general comment is this scheme meets my thoughts quite well. I'm glad we reach
> this point.
> 

fantastic

> I'll give more comments soon on the detailed issues Joel further proposed.
> 

Other than this and the keyid email which details?

> Sorry that the very slow "confirmation request" response from the list recently
> makes my post always too late to appear. Not sure if others also suffer from
> this problem?
> 

I dont seem to have any issues.

cheers,
jamal
Permalink | Reply | 0 comments |
headers
Weiming Wang | 2 Feb 2005 12:02
Picon

Re: updated path data text

A general comment is this scheme meets my thoughts quite well. I'm glad we reach
this point.

I'll give more comments soon on the detailed issues Joel further proposed.

Sorry that the very slow "confirmation request" response from the list recently
makes my post always too late to appear. Not sure if others also suffer from
this problem?

Cheers,
Weiming
----- Original Message -----
From: "Joel M. Halpern" <joel <at> STEVECROCKER.COM>
To: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Wednesday, February 02, 2005 3:27 AM
Subject: Re: updated path data text

> Following up on this, I have been batting an idea for the path / index /
> key encoding back and forth.  The following changes the PATH and Selector
> encoding, with the goal of simplifying the common cases:
>
> There is one more variation that occurs to me.  This is not what I sent to
> the list, and has some advantages and disadvantages.  Tell me what you think.
>
> Suppose we declare that block and content indexing can only be applied at
> the end of a path. Given nesting, this does not restrict what can be
> described, just where one has to split the TLVs.
> Then, we declare that indexes are included in the path sequence.
>
> Suppose we take two flag bits, and declare the meanings as:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel M. Halpern | 2 Feb 2005 15:49

Re: updated path data text

For simplicity and generality, and to avoid accidentally limiting 
ourselves, my view is that field identifiers and table indexes should both 
be represented in 32 bit unsigned inttegers.  If we were to leave 
subscripts separate from the path elements, we could argue that subscripts 
would be 32 bits, but field identifiers would be 16 bits.    On the other 
hand, one can argue that it is easier to process the path components if 
they are 32 bits long.

To put it differently, I would prefer to concentrate on whether the 
combined path is the right thing.  If it is, then we can afford to use 32 
bit field identifiers.  If it is not right to combine them, then we can 
decide whether to use 16 or 32 bit field identifiers.

Yours,
Joel

At 08:53 AM 2/2/2005, Weiming Wang wrote:
>Joel,
>
>Before we decide how index is placed in the path, I have a related question to
>ask first. I see that the bits for index may be different from that for 
>fields,
>for index may probably range more than 64k, but fields may be enough with
>32bits. I haven't followed the related discussions before, therefore, do 
>we have
>any consensus on the bits for fields and indices?
>
>Yours,
>Weiming
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 2 Feb 2005 16:12

Protocol Operations

I think that there are only three operations at the moment:
GET
SET
NOTIFY

In terms of the format I presented, the structure of these operations is as 
follows.
A GET request includes one or more base path TLVs and each may include one 
or more nested path TLVs.  Each path TLV may include a KEY TLV for content 
selection, where the data in the key TLV is the value of the selected key 
field.
A GET response will look like a GET request, with DATA filled in along with 
each terminal PATH TLV.

A SET request include one or more base path TLVs each of which may include 
one or more nested path TLVs.  Each Path TLV may include a KEY TLV to 
indicate which element of the table is being selected, where the data value 
in the KEY TLV represents a value being sought.  Flags indicate what should 
happen if the selected entry (index or content selected) is not found.  The 
flags can allow or prohibit creation of an entry that does not exist, and 
allow or prohibit modification of an entry that does exist.  (The 
combination must not create and must not modify is not particularly useful.)
Each terminal path TLV will also have a data block providing the 
information that is to be placed into the selected element.
The selected element may be the whole item identified by a key.  It may be 
a field in the structured identified by a key.

There are a couple of interesting cases to be covered.
1) It would be nice to be able to say "create, and give me an index".  This 
would be a case where no index and no key is provided, but a single element
(Continue reading)

Permalink | Reply | 11 comments |

Gmane