Subject: Re: Protocol Operations

From: "Putzolu, David" <[email-masked]>
Date: Tue, 8 Feb 2005 09:17:21 -0800

Thanks Jamal.

I would be very hesitant to put in more complexity to the protocol 
than there already is, especially as it already is fairly rich.
I've always viewed complexity as a penalty on the entire protocol,
so I guess I would phrase the question presented below slightly
differently:

Is it fair to punish the entire protocol with additional complexity
to benefit an uncommon case?

Regards,
David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, February 08, 2005 9:14 AM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations

On Tue, 2005-02-08 at 11:49, Putzolu, David wrote:
> (speaking just as another technical guy here) 
> 
> This seems overly complex to me.  Is there a common case that
motivates
> the need for this?

Weiming wants to be able to set data values as he walks hierachies of
attributes. As an example, tables which may have cells pointing to other
tables which may have cells pointing to other tables etc - and you want
to set cell in first table, then cell in following table etc. 

I think its a reasonable desire, but i contend it is not common.
It is fair to punish the uncommon cases and have them do more work
(parsing). Hence i would claim its ok to complicate things for that
scenario. Unless i missed the target of your comment as to what is
complex.

[Take a look at some of the examples in the text where i have been
capturing things to see some of what i think is common].

cheers,
jamal

> -David
> 
> 
> > -----Original Message-----
> > From: Forwarding and Control Element Separation 
> > [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> > Sent: Tuesday, February 08, 2005 6:16 AM
> > To: [email-masked]
> > Subject: Re: [FORCES] Protocol Operations
> > 
> > I am not sure i got the SETRESULT; going by what Weiming asked for
> > earlier, we have the following facilities:
> > 
> > To set data to a 3-deep path offset:
> > path-data
> > 	path1
> > 	optional selector
> > 	path-data
> > 		path2
> > 		optional selector
> > 		path-data
> > 			path3
> > 			optional selector
> > 			dataraw
> > 
> > 
> > If a response is asked back, thats exactly how the response would
look
> > like as well.
> > 
> > The other way which is to set data on multiple nested paths:
> > 
> > path-data
> > 	path1
> > 	optional selector
> > 	dataraw
> > path-data
> > 	path2
> > 	optional selector
> > 	dataraw
> > path-data
> > 	path3
> > 	optional selector
> > 	dataraw
> > 
> > Granted the end result will be grossly ineefficient since it 
> > will have a
> > lot of redundant information in the three path-datas above if path1
is
> > relative to path2 and path3 is realtive to path2.
> > For this we can use what i have seen in a few classifiers as an
> > optimization; these sorts of classifiers hacve a  "continue"
construct
> > which translates to "continue looking up where you last left off".
> > We can have something similar as a flag - so on path2 and 
> > path3 it would
> > say "the previous path+selector counts as part of this path". 
> > So path1 +
> > its selectors will be part of path2+ its selectors, which is also
part
> > of path3 and its selectors. Clearly the flag is not useful on 
> > the first
> > path-data it involves inheritance and can be ignored there.
> > 
> > Heres my worry: I think what Weiming wants in this case is a 
> > corner case
> > which while we must satisfy the end result should not break the
simple
> > design rule of "optimize for the majority"
> > 
> > cheers,
> > jamal
> > 
> > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote:
> > > You raise an interesting question of where the element by 
> > element SET 
> > > results go.
> > > 
> > > One of the drawbacks of allowing multiple path-data 
> > elements inside a 
> > > operation TLV is that it no longer suffices to return the 
> > response code at 
> > > the operation TLV level.
> > > Therefore, I would presume, we will have to return the 
> > response codes in 
> > > the individual path-data TLVs.
> > > I would not want to return the results as a separate 
> > parallel TLV, as that 
> > > would imply some kind of matching that would get quite 
> > confusing.  I 
> > > suppose that means that the actual syntax becomes:
> > > 
> > > DATAINFO := [SELECTOR] [<PATH-DATA>+ | <DATARAW>+ | <SETRESULT>+]
> > > 
> > > Where SET Result is used only in the response to a SET, and 
> > occurs where 
> > > the DATARAW elements were in the set request, indicating 
> > for each dataraw 
> > > whether it was successfully set.
> > > 
> > > Yours,
> > > Joel
> > > 
> > > At 11:22 PM 2/7/2005, Wang,Weiming wrote:
> > > >It quite gets to me that the list server often ate my 
> > posts. I do have 
> > > >sent some mails but that cann't be seen on the list till now.
> > > >
> > > >Hopefully  this post can work.
> > > >
> > > >----- Original Message -----
> > > >From: "Joel M. Halpern" <[email-masked]>
> > > >Subject: Re: Protocol Operations
> > > >
> > > >
> > > > > I actually think we could get away with:
> > > > >
> > > > > DATAINFO := [SELECTOR] [<DATARAW> | <PATH-DATA>+]
> > > > >
> > > > > and just leave out the "DATA" line.  I believe this 
> > allows the nesting, is
> > > > > decidable by the parser, and does what we need.
> > > > >
> > > > > we can in fact collapse further in the BNF to:
> > > > >
> > > > > PATH-DATA TLV := <PATH> [SELECTOR] [<DATA>+ | <PATH-DATA>+]
> > > >
> > > >Yes, this makes it more clear, but I still see the value 
> > to modify it to:
> > > >
> > > >PATH-DATA TLV := <PATH> [SELECTOR] [<PATH-DATA>+] [<DATA>+]
> > > >
> > > >I suppose  a SET request that has format as "path 
> > path-data1 path-data2 
> > > >path-data3", whos response will have format as "path 
> > path-data1 path-data2 
> > > >path-data3 data", the last data TLV is for the SET result 
> > responses.
> > > >
> > > >Cheers,
> > > >Weiming
> >

---

From: "Putzolu, David" <[email-masked]>
Date: Tue, 8 Feb 2005 10:54:43 -0800

(chair hat off as usual...)

I don't have any objection to flags.

I would prefer to use *either* operations *or* flags, but not both.
Having two ways to do the same thing in a protocol usually just leads to
more test cases and interop problems.

-David  

-----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
>
>[mailto:[email-masked]] On Behalf Of Joel M. Halpern
>Sent: Wednesday, February 02, 2005 7:12 AM
>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,
> >
> >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: "Putzolu, David" <[email-masked]>
Date: Tue, 8 Feb 2005 11:56:53 -0800

I'm somewhat worried by how difficult implementing this cancel operation
would be.  Does the FE have to buffer all commands it ever received (or
at least over a window of time) and provide a way to roll them back,
even if they where not flagged as a transaction?  Seems exceedingly
difficult from an implementation point of view! 

-David

-----Original Message-----
Sent: Tuesday, February 08, 2005 11:19 AM

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

At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote:
>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.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 15:28:23 -0800

Joel,

I completely agree with your comment regarding the key for content
selection, I think this should be fixed and defined by the LFB
definition.

I would also like to see a reduction in the number of combinations
possible. The more combinations we have, the more difficult it will be
to get interoperable implementations.

Regards
Hormuzd
P.s. I am happy to contribute...hopefully my comments are helpful.

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

Note that if key's are not unique then it is not possible o know how
many 
things will be selected by a content selection.  Please let us stay away

from that.
Note further that at the moment we at least have the simplification that

one can not do blocks and keys at the same time.

Note that all 6 of the cases above have been requested explicitly on the

list.  I would be more than happy to see a reduction in the number of 
combinations we support.

And I am VERY happy to see any comments from someone other than me, 
Weiming, and Jamal.

Thank you,
Joel

PS: Successful GET responses look like SET requests.  GET requests can
not 
have DATARAW elements, but can have nested PATH-DATA.  DELETE requests 
would parallel GETs.

At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote:
>Also, another comment I made -> is this correct in the current grammar
>->