Re: [Fwd: [Forces-protocol] Presentation oftheoptionsforLFB-levelmulticast]

[Jamal Hadi Salim <[e-mail]>]

On Sun, 2004-11-07 at 23:48, Wang,Weiming wrote:

> [Weiming]I'v seen the difference. What you refered here as content based
> searching actually in my slides still belongs to the index-based path. In your
> example of NOP attributes, you only have one level of table, when you put the
> second level of table (that is, the Datatable in the NOP LFB you mentioned,
> which sub field is another table), you will see that anything is based on what
> you mean content based searching (which actually isn't content based).  Pls read
> other part of my slides where I think content based searching is quite different
> thing, something like:
> 
> Path = {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1}
> 
> where you can see the difference is, in this path, there is no index, instead
> there are values for terminal nodes. Do you think a path can include values? I
> think no, therefore, my opinion is that the path except the attribute ID part
> should be inside the 'Data' field.
> 
> Anyway, I think what you mean content based searching is different from what I
> mean, and you actually still have not mentioned content based searching in your
> example.
> 

I did not elaborate on content addressing, just listed it as a bullet of
"under discussion" mostly because we as a protocol team have not
disccussed it since we are stuck on this that i thought is a difference
all along - just like we have not discussed block operations for the
same reasons. 

As a reminder from the doc posted by Steve (Sep 20 if you want to review
thread of discussion which i think you participated in) which described
the different table operation requirements:

---
4.3  Associative (Key-Based) Operators

In the following operators the following additional notations are used:
<key>:   Refers to the identification of the key. Note that the same
         table may be addressable by more than one key.  Indirectly,
         the key refers to the field in the table entry that will
         be compared to the <key-val>.
<mode>   Search modes as described in section 2 (e.g., exact match,
         all that match prefix, longest prefix match, range, etc.)
<key-val>  Data to be compared to the entry fields that are used as
           key. What is provided in <key-val> depends on the <key>
           and also on <mode>.
--------

Note the key-val is the value to be compared. We have no difference in
nested tables, so the expression you supplied applies here quiet well to
access content.

I have attached this document.

I also posted another document to try and map this document to
protocol-speak that i worked on. That document (was posted 2-3 weeks ago
to the protocol team) is attached. We have not reached that discussion
point is the reason this document or suggested BNF is not seen on my
slides.

Weiming, to be honest i still dont see the difference. I am giving you
the benefit of doubt given past experience with you - I think the may be
a difference. All i am saying is i dont see it.

What i would like to ask the chairs at this point is to make some time
for your presentation if possible. I will try to rush through mine and
allocate maybe 5 minutes at the end for yours if they dont have time.
Let other people judge. It is too bad we dont have you physically here.

[What you are forcing me to do now is talk more about content based
access as well as have a nested table example - which i wasnt planning
to do. The reason i have to talk more about it now is in order for
people who have no clue what this is to make a comparison against your
slides]

cheers,
jamal

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