Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 10:22:05 -0800

Hi Joel,

I was wondering we don't need the following Operations:
DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE,
CANCEL.

Let me know what I am missing here, but these Operations do need to be
supported.

Another comment on the protocol grammar, I still don't see a good reason
why we need Flags in PATH. The Operation Flag bits can clearly be
supported via the Operation type (ADD, Del, UPDATE) and the Selector
bits can also be a subfield in the Operation, rather that part of each
PATH. Having Flags as part of PATH seems quite inefficient to me. 

Also, is this correct in the current grammar ->
DATA := [DATARAW] | <PATH-DATA>+ ??

Regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 02, 2005 7:12 AM
To: [email-masked]
Subject: [FORCES] 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 
is being created.  It would seem that we can cover this with the 
flags.  The returned result will include the information as to what
index 
was assigned to the value
2) Any create operation in a table must be checked by the FE logic to 
ensure that all key values of the new data content are unique in the 
table.  This is a consequence of the requirement that keys be unique.
This 
applies whether the create is using indexing or content keying to
identify 
the new value.
3) Similarly, any modify operation that modifies a table key must be 
checked by the FE to ensure that uniqueness is met.
3') The corollary to the above is that swapping the key values between
two 
entries may be a little tricky.  If both SETs are in the same OPERATION
TLV 
should we require the FE to be smart enough to realize that the values
are 
unique after both changes?  Or should we require that one of them get 
changed to an unused value first?
4) It is perfectly valid to specify a create operation for an entire
entry 
in a table, and specify a key.  Depending upon flag settings this will 
either ensure that the key is not used, or allow overwriting of the
entry 
if it is already there.  It is actually valid for the data being written
to 
have a different (but still unique) key value.  (It would probably only
be 
useful in a modify operation.)  Said another way, changing keys on
entries 
is allowed as long as uniqueness is preserved.

Yours,
Joel

PS: No, I did not talk about Notify.  I expect it looks a lot like a GET

response, but I have not thought about it much.

At 08:34 AM 2/2/2005, Weiming Wang wrote:
>Jamal,
>
>----- Original Message -----
>From: "Jamal Hadi Salim" <[email-masked]>
>Subject: Re: path data textt update
>
>
> >
> > 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"
> >
> > I think these are valid operations - therefore search key needs to
> > be represented separately from subpath and should not have
dependence of
> > what the msg type is.
>I'm afraid You'v raised a very good point that we need to address 
>specifically,
>that is, how a MODIFY/REPLACE operation will affect our current BNF. 
>Obviously a
>MODIFY operation usually needs to include two data parts in the
message: 
>the old
>data(or condition), the new data. I now understand what you are trying
is 
>to use
>the KEY to specifically INDICATE it is the old data (or condition)
part. I
>understand more that this kind of INDICATE is actually realized by the
type in
>the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV"
is
>specified for the old data (or condition) only. With this thought, I 
>suppose you
>may also mean every field in an LFB attribute can be a KEY, because
every 
>field
>can probably be replaced/modified.
>
>As a result, I have to say yes, such KEYINFO TLV is necessary, or in
another
>word, should be separately expressed in BNF, but I also have to say the
data
>format for the KEYINFO TLV is actually the same as the general
PATH-DATA 
>format,
>that is, the KEYID there is actually a subpath instead of only a KeyID.
>
>Now come back to the KEY idea Joel proposed. I think a best way to say
Joel's
>idea is "not all subfields are allowed as searching indices". I'm sure 
>this kind
>of Keys are only a subset of keys used in the KEYINFO TLV for
MODIFY/REPLACE
>operations, because as I mentioned above, we should allow all writable 
>fields in
>an attributes replacable, though we not allow some fields as searching 
>indices.
>As a result, to better solve this, I'm afraid we need to see how
KEYINFO TLV
>should actually be composed. My idea is, for MODIFY operations, the old

>data (or
>condition) part may include general subpath-data, as well as KEYs as
Joel
>proposed.
>
>I'm keeping thinking of this ...
>
>Cheers,
>Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 13:49:29 -0500

We may need a Delete operation to remove table entries.
UPDATE / REPLACE / CREATE are currently expected to be flag settings on 
SET.  Depending upon whether we can simplify the protocol operation 
structure, and whether one prefers flats or type codes, we might be able to 
make the operations instead of flags.  I don't have much of a 
preference.  Jamal like's flags, so I was going with that.

SUBSCRIBE / UNSUBSCRIBE is supposed to be a variable setting.  Remember 
that there is only one active CE.  Hence, if we have an LFB variable for 
whether a given event is to be reported, the CE can set or unset that 
variable.  This avoids creating extra state that affects operations but is 
invisible.

(Not sure what CANCEL would be, so I don't know how that would be covered.)

Yours,
Joel