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

Jamal Hadi Salim <hadi@znyx.com> Mon, 08 November 2004 11:36 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23811 for <forces-protocol-web-archive@ietf.org>; Mon, 8 Nov 2004 06:36:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR7pp-0005nd-4S for forces-protocol-web-archive@ietf.org; Mon, 08 Nov 2004 06:37:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR7nL-0002Ad-Be; Mon, 08 Nov 2004 06:34:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR7i8-0001i6-5z for forces-protocol@megatron.ietf.org; Mon, 08 Nov 2004 06:29:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23102 for <forces-protocol@ietf.org>; Mon, 8 Nov 2004 06:29:21 -0500 (EST)
Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR7id-0005ff-Rg for forces-protocol@ietf.org; Mon, 08 Nov 2004 06:29:57 -0500
Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004110803330680:14252 ; Mon, 8 Nov 2004 03:33:06 -0800
Subject: Re: [Fwd: [Forces-protocol] Presentation oftheoptionsforLFB-levelmulticast]
From: Jamal Hadi Salim <hadi@znyx.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
In-Reply-To: <130001c4c54e$28fb5f20$845c21d2@Necom.hzic.edu.cn>
References: <4189F776.4080306@zurich.ibm.com> <1099700691.1038.2.camel@jzny.localdomain> <005101c4c408$dc341600$020aa8c0@wwm1> <1099752095.1037.11.camel@jzny.localdomain> <003201c4c46d$1bbce4a0$020aa8c0@wwm1><004201c4c4ec$61d34c20$020aa8c0@wwm1> <1099829057.2165.18.camel@jzny.localdomain> <00bd01c4c536$fb418ee0$020aa8c0@wwm1> <1099885892.2167.13.camel@jzny.localdomain> <130001c4c54e$28fb5f20$845c21d2@Necom.hzic.edu.cn>
Organization: ZNYX Networks
Message-Id: <1099913354.2172.67.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2
Date: 08 Nov 2004 06:29:15 -0500
X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/08/2004 03:33:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 11/08/2004 03:33:13 AM, Serialize complete at 11/08/2004 03:33:13 AM
Content-Type: multipart/mixed; boundary="=-g09QXlKwzipKB0hddpaz"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c25c25eef92c03b403abac6c7c688517
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "\(Ram Gopal \)" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, joel@STEVECROCKER.COM, Patrick Droz <dro@zurich.ibm.com>, David.Putzolu@intel.com, Dong Ligang <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: hadi@znyx.com
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4824b9ef1b1988f2983d420e78cedc0a

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
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol