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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 6 Oct 2004 23:55:22 -0700

Steve, Zsolt,

Thanks a lot for taking the time and effort to do this! Overall I think
it looks very good, we are definitely getting much closer now, I think.

This is obviously written more like requirements for the protocol team
rather than imposing any particular message types, which is a very good
idea.

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,

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>

Regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Steven Blake
Sent: Monday, September 20, 2004 10:42 AM
To: [email-masked]
Subject: [FORCES] Table model and config operators in ForCES rev. 2

After some discussions between the model and protocol design teams,
Zsolt Haraszti and I took the to-do to put together a proposal on how
LFB tables could be modeled and managed in the protocol.  The attached
file is what we came up with.

Please review and send comments to the list.

Regards,

// Steve

---

From: Zsolt Haraszti <[email-masked]>
Date: Thu, 7 Oct 2004 17:18:48 -0400

> rather than imposing any particular message types, which is a very good

That was the idea.

> 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.)

The suppression of error feedback -- or in general error handling -- is
a whole separate story and was not (yet) addressed in the discussion.
Once the basics are agreed, we should go there too.

> 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?

In single-entry table operations, I can actually envision the idx be
voluntarily be regarded as part of the path information.

Cheers,
Zsolt

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