Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 11:02:53 -0800

Having Operations as part of Flags, seems quite inefficient to me.
We will have a single Operation TLV which could have multiple PATHs.
It will be a lot simpler as well as efficient to have the Operation
defined in the beginning of this TLV, rather than in each PATH Flag.
Thus my preference. 

Regarding Subscribe, Unsubscribe, I am fine with having it as a LFB
variable setting, but this should be clearly explained in the text. 

The reason for CANCEL command was basically to nullify or cancel a
previously configured operation on the FE which is not done in a certain
period of time.

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, February 08, 2005 10:49 AM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations

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

At 01:22 PM 2/8/2005, Khosravi, Hormuzd M wrote:
>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 14:19:01 -0500

I would expect "cancel" to operate on a request level.  That is, a PDU 
carrying OPERATION TLVs would have an ID of some sort for the whole PDU, 
and a Cancel message would use that same overall ID to indicate what was 
being cancelled.  That is, "cancel" is at a higher syntactic level than we 
have been discussing.

As a separate matter, I think that Cancel is likely to be ambiguous in 
effect, so I am not sure that we should try to support it.  The race 
conditions are "interesting".

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 14:39:37 -0500

> defined in the beginning of this TLV, rather than in each PATH Flag.

I think you meant having "flags as part of the operations" as opposed to
"operations as part of Flags"? Otherwise i am not sure which flags you
are refering to. Did you read the text i have been posting?

cheers,
jamal