headers
Jamal Hadi Salim | 3 Oct 2004 17:36

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

Steve/Zsolt

On Mon, 2004-09-20 at 13:42, Steven Blake wrote:
> 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.

Finally got to peruse the doc over a large coffee.
A few things:
1) In reference to the approach from Joel (that i posted a while back),
an index is part of the path. You seem to have separated it. It actually
does seem to make sense to do so for two reasons:
a) an index is a dynamic runtime notation as opposed to a "static" class
time definition.
b) facilitates the block operations by having it separate.

I am not sure if you had this in mind - thought id mention it.

2) You seem to preclude using the index as part of an entry definition.
I think thats a legit usage.

3) Indices should be reusable when elements dissapear.

4) associative addressing/keying

Hrm. I reread this twice and something is still bothering me.
It does have an implicit "search" built in. First you search for _all_
references of the key and then operate on them.
We have not talked about putting a search message on the protocol
because it hasnt made any sense (so far maybe).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steven Blake | 4 Oct 2004 23:33

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

On Sun, 2004-10-03 at 11:36, Jamal Hadi Salim wrote:

> Finally got to peruse the doc over a large coffee.
> A few things:
> 1) In reference to the approach from Joel (that i posted a while back),
> an index is part of the path. You seem to have separated it. It actually
> does seem to make sense to do so for two reasons:
> a) an index is a dynamic runtime notation as opposed to a "static" class
> time definition.
> b) facilitates the block operations by having it separate.
>
> I am not sure if you had this in mind - thought id mention it.

That is exactly what we had in mind.

> 2) You seem to preclude using the index as part of an entry definition.
> I think thats a legit usage.

We don't intend to preclude having the index as part of the entry
definition.  If the index is defined as part of an entry in the class
model, then the INS command (not INS_IDX) would be used to insert the
entry.

I'm not sure what you think is a legit usage: allowing the index as part
of an entry, or not?

> 3) Indices should be reusable when elements dissapear.

Agreed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Khosravi, Hormuzd M | 5 Oct 2004 03:30
Picon
Favicon

FW: I-D ACTION:draft-ietf-forces-protocol-00.txt

FYI...the original draft with minor editorial updates,

Hormuzd

-----Original Message-----
From: i-d-announce-bounces <at> ietf.org
[mailto:i-d-announce-bounces <at> ietf.org] On Behalf Of
Internet-Drafts <at> ietf.org
Sent: Thursday, September 30, 2004 12:32 PM
To: i-d-announce <at> ietf.org
Cc: forces <at> peach.ease.lsoft.com
Subject: I-D ACTION:draft-ietf-forces-protocol-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Forwarding and Control Element
Separation Working Group of the IETF.

        Title           : ForCES Protocol Specification
        Author(s)       : A. Doria
        Filename        : draft-ietf-forces-protocol-00.txt
        Pages           : 60
        Date            : 2004-9-30
	
This specification documents the Forwarding and Control Element
Seperation protocol.  This protocol is desgined to be used between a
Control Element and a Forwarding Element in a Routing Network
Element.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 5 Oct 2004 17:14

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

On Mon, 2004-10-04 at 17:33, Steven Blake wrote:
> On Sun, 2004-10-03 at 11:36, Jamal Hadi Salim wrote:

> > 2) You seem to preclude using the index as part of an entry definition.
> > I think thats a legit usage.
>
> We don't intend to preclude having the index as part of the entry
> definition.  If the index is defined as part of an entry in the class
> model, then the INS command (not INS_IDX) would be used to insert the
> entry.
>
> I'm not sure what you think is a legit usage: allowing the index as part
> of an entry, or not?

Allowing it as part of a table entry in addition to it being a path
defining entity.

> > 4) associative addressing/keying
> >
> > Hrm. I reread this twice and something is still bothering me.
> > It does have an implicit "search" built in. First you search for _all_
> > references of the key and then operate on them.
>
> Not always.  For example, if the associative addressing operation is
> 'exact match', you wouldn't expect to match more than one entry.
>

It would still necessitate a search of some form which would be a _lot_
more complex than that of a simple index.
In your text you do refer to the associative piece as a "search" key;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel M. Halpern | 5 Oct 2004 17:23

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

I tend to think that all we need is simply indexed tables from a management
perspective.  All "searching" would then be the responsibility of the CE,
using the tables it has.  I think that will keep the protocol simpler and
keep the FE simpler in most cases.  In a few cases where the FE natural
implementation is a memory associative structure (hash or tree), this would
be somewhat more effort for the FE to support.  (Note that real CAMs are
actually a case where the index method works find, since those naturally
have real indexes for management, while supporting context lookups for data
plane.)

Yours,
Joel

At 11:14 AM 10/5/2004 -0400, Jamal Hadi Salim wrote:
> > > Wouldnt it just make sense for the CE to keep track of the state and
> > > infact such queries - if they need to be the sent to the FE (in the case
> > > the CE cant resolve them) - should first be translated into a proper
> > > path with proper indices (probably block indexing) then sent?
> >
> > It's a question of how much state you have to and want to mirror on the
> > CE.  Strictly speaking, associative addressing is not mandatory, because
> > you could always maintain copies of each and every table on the CE.
> > There are some potential efficiency gains to be had if you support it,
> > and the proponents should have the burden of quantifying them.
>
>If you assume that CE and FE states would be in sync - a valid
>assumption i believe - then i see the efficiency as having more state at
>the CE.
>I am not sure now which side Joel was on, but could you hint one value
>on doing it at the FE with a search key?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 6 Oct 2004 20:22

Two questions on Table model and config operators in ForCES rev. 2

Aren't INS_IDX! and SET! identical operations?

Allowing value based indexing to match multiple entries seems a
mistake.  It makes "key" not a key.  It seems to me that if we are going to
allow associative access at all, it should only be to identified key fields
and only when those fields are actually sufficiently unique keys.

Yours,
Joel M. Halpern

At 01:42 PM 9/20/2004 -0400, you wrote:
>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
Permalink | Reply | 1 comment |
headers
Zsolt Haraszti | 7 Oct 2004 06:46

Re: Two questions on Table model and config operators in ForCES rev. 2

On Wed, 2004-10-06 at 14:22, Joel M. Halpern wrote:
> Aren't INS_IDX! and SET! identical operations?

Yes, they are; one can be eliminated.  My mistake.

>
> Allowing value based indexing to match multiple entries seems a
> mistake.  It makes "key" not a key.  It seems to me that if we are going to
> allow associative access at all, it should only be to identified key fields
> and only when those fields are actually sufficiently unique keys.

I tend to agree.

/zsolt

> Yours,
> Joel M. Halpern
>
> At 01:42 PM 9/20/2004 -0400, you wrote:
> >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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Khosravi, Hormuzd M | 7 Oct 2004 08:55
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Zsolt Haraszti | 7 Oct 2004 23:18

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

On Thu, 2004-10-07 at 02:55, Khosravi, Hormuzd M wrote:
> 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.

That was the 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,
>
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Khosravi, Hormuzd M | 8 Oct 2004 01:10
Picon
Favicon

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

Hi Zsolt,

Thanks for your prompt reply!
Pls see my comments below... 

-----Original Message-----
>
> 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,
>
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.)

[HK] Thanks, this clarification helps, I got a very different impression
from your text.
(Continue reading)

Permalink | Reply | 502 comments |

Gmane