Subject: RE: [Forces-protocol] RE: updated notes on BNF and layout

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 11 Oct 2004 23:16:37 -0700

Weiming,

Thanks for posting and breaking your silence after a long time!
Pls see my comments below...(I didn't comment on 1 since it seems like
we have already resolved it for now)

-----Original Message-----
2. The Index issue.
I'v been trying to understand Joel's idea on the advantage ( easy
management )
of Index  used at the protocol layer, but based on my testbed
implementation, I
just find it seems not an easy thing as we may think to do this. I have
to do
extra things like matching and managing the Index in CE to protocol
application
layer and matching and managing the Index in FE protocol terminator to
base in
LFB. Without using this Index, I don't need to pay these extra
attentions, just
let the protocol application layer directly manage the LFB base.

[HK] I have similar experience on this. The index will add complexity to
the protocol depending on how and how much we use it. The main reason
why it was proposed (as I understand) was to support Get/Query
functions. If we could have some restrictions on these operations, it
would probably make like a lot easier. The thing that we do need in
addition to LFBClass:LFBInstanceID, is an identifier for the
TableID...so that would be the <path> in Zsolt/Steve's text. After that
all you need in most cases is an array of entries, that you would like
to Add/Del, etc from the FE. The index could be part of each entry
itself if defined in the data model instead of being specified
separately as part of the <path>

Although I think the above issues worth discussing, I agree with Hormuzd
that we
protocol team may need to begin the paper work now for the new version
protocol
draft right now, therefore I can currently live with current scheme,
which
actually quite the same as we'v had in the current draft, while leaving
the
above issues for more discussion.

[HK] Thanks Weiming. I plan to send updates to my sections in the draft
to the protocol team in this week...

Regards
Hormuzd

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2004 07:27:04 -0400

Thank you Hormuz, and my apology Weiming.  I now see why there is some 
distinction if all tables are small.  However, I think that we need to be 
able to fetch and update entries in small and large tables.

Let me try describing the element selection process with content 
addressing, as a contrast to the process I described with just indexing 
(where the index appears in the path selection.)

Let us suppose we have a structure which can be abbreviated:
    lfbclass:
       element fa-1: some type definition
       element fb-2: array of structure
            ? index ga-0: uint32 ?
            key element ga-1: some type definition
            element ga-2: some type definition
            element ga-3: array of structure
                ? index ha-0 ?
                key element ha-1: some type definition
                element ha-2: some type definition

Then, to select an ha-2, I would need a triple,
     the path fa-2, ga-3, ha-2
     the pair ga-1 and a value for the specific key 1
     the pair ha-1 and a value for the specific key 1

Including the explicit index as an entry in the structure does make things 
simpler, as it means that translation to that is just a GET.  Even if we 
only support indexing, I do not object to making the index a structure member.
And If we are going to support content indexing, we can avoid creating 
multiple operations by using the ga-0 and ha-0 where I put the ga-1 and 
ha-1 above.

That still seems more complex than just sending
     the path fa-2, index value 1, ga-3, index value 2, ha-2

I believe the key difference lies in the assumption about structuring th 
CE.  I assume the CE will need to have all the entries.  If it has the 
entries, then the CE can always provide the index, since in the worst case 
it just stores the index information with the other information it will 
need to find to look up the entry.  (Note that it always needs to check for 
entry existence before creating or modifying entries.)  So even if the 
preferred structure for the CE is some content tree, it can still easily 
use the index.
I do agree that this makes some more work for the FE in some cases.

As I am not sure which aspect is most important in peoples consideration, I 
will note that if it makes people happier to have the index in the 
structure even if we only index by simple uint32, that does not bother me.

Yours,
Joel

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 12 Oct 2004 21:01:37 +0800

Hi Joel,

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>

> Thank you Hormuz, and my apology Weiming.
I was very busy that  kept me join less, and will still be busy till next
Monday, I even can not reply your this email very fully :(

>I now see why there is some
That's just the point. Then the path will appear just as:
        fa-2: ga-0: ha-0
I don't see the difference with what you use protocol index as below. Could you
explain more on the difference? I can see the only difference is the above is
defined in the protocol Data entry while the below will be defined outside the
entry.

>From this point, I see more about what I mentioned the protocol 32bit index will
quite be limited. In this case above(index for recursive tables), it seems the
32bit protocol index will be segmented. Then this implies the FE model will have
to define how the 32 bit index will be used, or else I suppose there will be
interoperability problem between different vendors. This actually has lead to a
quite embarassing case, that is, the LFB definition in FE model  will have to
pay attention to terminology (the index) used by the protocol.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2004 09:32:02 -0400

For clarity, no matter which structure we use, with nested tables each 
table has its own index.  With content indexes, each table has a content 
field that is its key (or maybe more than one such field).  With straight 
indexing, each table has a 32 bit index.  We do not try to partition a 
single 32 bit index across nested tables.  That would indeed be extremely ugly.

Each entry (fa-2, index value 1, ga-3, index value 2, ha-2) is a 32 bit 
entry that selects a "thing". fa-2 selects the whole table. index value 1 
selects the entry from the table.

The difference between the two mechanisms is simply taht when there is only 
a single, always 32 bit, index, one can naturally include it in the path 
with no need for type / length indication for the "key".  When we do 
content addressing, we need each key to have at least a length, and for 
clarity probably a type code (i.e. a number assigned by some library to the 
type of information used as the index).

Yours,
Joel

PS: While I dislike the complexity of content addressing, it does have 
value and if the rough consensus is to use it I can live with it.  It is 
not a show stopper for me as long as all tables always have simple indices 
as well.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 Oct 2004 10:57:52 -0400

Updated little doc based on recent discussions.
I hope i havent missed anything said.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Oct 2004 14:01:57 -0400

In order to speed up the discussion so both sides can make sense
of what is being said on the path selection, Ive put some thoughts 
in a little document and will continue updating so as to capture
the discussion. Its easier to capture the discussion in this one
centralized note.

Please respond.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Oct 2004 14:18:05 -0400

A couple of comments, some relating to this, and some relating to the 
underlying operation description.

Firstly, I am somewhat uncomfortable with the block operations.  I have 
trouble actually seeing cases where one will need to GET (or even more 
rarely) SET a specific block in a table, but not the whole table.

Secondly, I wonder if it is worth the extra wrappers just to allow multiple 
path-data sets in the same operation TLV.  If we restrict things to one 
path-data per operation TLV, things get simpler.

Related to the above, I think that the flags are in the ID_TLV because each 
target may have different flag settings.  But these flags really modify the 
operation, not the target.  (Thus, semantically I would like the flags on 
the operation.  Which is fine if there is one target per operation.)

Having a TLV to hold the ID_TLV and having an ID_COUNT is redundant.  (At 
which point I get repetitive., sorry.)  If we have one target per 
operation, then we just put the ID_COUNT, id-sequence in the header of the 
operation.  There is no need for an extra TLV to hold it.  I am not sure 
where / how to put in the date for associative keying.

Also, I would like to require that associative keys always be unique, so 
the F_APPEND should not be needed or permitted.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Oct 2004 15:14:24 -0400

Thanks for responding Joel.

> rarely) SET a specific block in a table, but not the whole table.

One example i can think of is say you want to update all NH entries
in an LPM instance X previously pointing to NH table instance Y index 10
to now point to NH Table instance Y index 20.
You could send multiple batched messages or one with block/ranges.

> path-data per operation TLV, things get simpler.

I am indifferent. One wastes 32 more bits than the other. 
I would vouch for simplicty at the cost of 32 more bits.

> the operation.  Which is fine if there is one target per operation.)

fine with me. Other people please comment on this.

> where / how to put in the date for associative keying.

But how do you know where the ID ends?
Are you suggesting to move IDs and flags into the operation TLV?

> the F_APPEND should not be needed or permitted.

Just threw it in there because it exists in BSD and Linux and has some
uses there. Fine with getting rid of it.

Other people please speak up.

cheers,
jamal

---

From: Zsolt Haraszti <[email-masked]>
Date: Thu, 14 Oct 2004 15:14:54 -0400

> rarely) SET a specific block in a table, but not the whole table.
Here is an example:

At the CE's layer a diffserv policy on an interface will contain a
number of policy class definitions, each based on an ACL.  When this is
translated into entries in a classifier LFB table in the FE, you will
have a block of consecutive entries corresponding to each policy class
(the number of entries will correlate with the complexity of the ACL).

When I add a new policy class to the configuration at the CLI, this will
require to add a bunch of entries to the classifier table (also touching
other LFBs, but I focus on the classifier in this example).  In this
scenario I certainly do not need to change the whole table, but I need
to add a bunch of entries.

Similarly, if one or more policy classes are deleted, a large number
of entries (but not the whole table) needs to be deleted from the LFB's
table.

If a classifier table in the Classifier holds the filters for more than
one interface, block ADD/DEL operations will be required when Diffserv
is enabled/disabled on one or a subset of the interfaces.

Regarding GET operations: the same granularity must be provided when
grabbing the counter content.  The CLI may issue a request for the
diffserv counters associated with just one interface, or just one
policy.

The most skepticism regarding ForCES is coming from the efficiency
angle.  I think it is imperative that we enable efficient encoding
of block operations.
 
> path-data per operation TLV, things get simpler.
I agree with this one.

> the operation.  Which is fine if there is one target per operation.)

Agree.

This is all before actually reading Jamal's recent posting...

/zsolt