Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

"Wang,Weiming" <wmwang@mail.hzic.edu.cn> Fri, 12 November 2004 14:20 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 JAA05072 for <forces-protocol-web-archive@ietf.org>; Fri, 12 Nov 2004 09:20:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScJC-0000zE-Mi for forces-protocol-web-archive@ietf.org; Fri, 12 Nov 2004 09:21:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc6o-0002Wr-Il; Fri, 12 Nov 2004 09:09:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc4i-0001uu-DU for forces-protocol@megatron.ietf.org; Fri, 12 Nov 2004 09:06:52 -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 JAA03926 for <forces-protocol@ietf.org>; Fri, 12 Nov 2004 09:06:50 -0500 (EST)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSc5y-0000e2-RE for forces-protocol@ietf.org; Fri, 12 Nov 2004 09:08:18 -0500
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.341813895; Fri, 12 Nov 2004 22:29:53 +0800 (CST)
Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000110526@mail.gsu.cn>; Fri, 12 Nov 2004 22:04:42 +0800
Message-ID: <155001c4c8c0$5eb73ec0$845c21d2@Necom.hzic.edu.cn>
From: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
To: <hadi@znyx.com>, "Joel M. Halpern" <joel@stevecrocker.com>
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> <132001c4c551$86023150$845c21d2@Necom.hzic.edu.cn> <1099911200.2169.29.camel@jzny.localdomain> <134f01c4c585$216584c0$845c21d2@Necom.hzic.edu.cn> <4191299F.4020809@zurich.ibm.com> <142a01c4c6d6$13569980$845c21d2@Necom.hzic.edu.cn> <1100100893.2210.24.camel@jzny.localdomain> <14fc01c4c79f$75231f20$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20041111091015.03bafec0@localhost>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
Date: Fri, 12 Nov 2004 22:03:20 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "\(Ram Gopal \)" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, 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
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.3 (/)
X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af

Joel,

One more thing is, for index based searching, after some operation such as add,
delete and modify, the table actually will also become a random table rather
than a linear one regarding the index. In this case, I see that the index
actually plays no more efficient role other than a general content searching,
i.e., it has actually become content(the content is the index) based searching.
Therefore, in this case, I cannot see any advantage to explicitly define Index
in the protocol over to just define the 'index' as a field in the table
structure. For latter, the path will not include any explicit index anymore, to
do index based operation is to assign an  'index'  field value.

Cheers,
Weiming

----- Original Message -----
From: "Joel M. Halpern" <joel@stevecrocker.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>cn>; <hadi@znyx.com>
Cc: "Robert Haas" <rha@zurich.ibm.com>om>; "Khosravi, Hormuzd M"
<hormuzd.m.khosravi@intel.com>om>; "(Ram Gopal )" <ram.gopal@nokia.com>om>; "Avri
Doria" <avri@acm.org>rg>; <forces-protocol@ietf.org>rg>; "Patrick Droz"
<dro@zurich.ibm.com>om>; <David.Putzolu@intel.com>om>; "Dong Ligang"
<donglg@mail.hzic.edu.cn>
Sent: Thursday, November 11, 2004 10:14 PM
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level
multicast]


Within an LFB, there are two common classes of multiple references (GETs
and SETs).
1) All of the elements being referenced are within the exact same
structure, but you do not want to get / set the entire structure.  In this
case, all of the path descriptors except the last are identical.
2) One is referencing different things in the LFB.  In that case, one is
just as likely to change the first path identifier (what I think you mean
by attribute ID) as any other part of the path.

Hence, I can see no argument for treating the first path element any
differently from the others.  If we really want to optimize for cases with
shared path, we could do so by allowing more complex nested TLVs.

Note that because we allow references to full tables and structures which
make full SNMP OID references so expensive are less of an issue in our work.

As a minor point, note that getting / setting multiple elements can be done
by sending multiple target selection TLVs.

Yours,
Joel M. Halpern

At 10:35 PM 11/10/2004, Wang,Weiming wrote:
>Hi Jamal,
>
>----- Original Message -----
>From: "Jamal Hadi Salim" <hadi@znyx.com>
>
> > Hi Weiming,
> >
> > I am not sure if this is what you are saying all along, but i think it
> > may be valuable to have "relative" path encoding.
>In some way, you may call it a thought of relative path. My view is actually
>from following thought:
>1. A single path is not enough for an operation. In some cases, we may need to
>assign several paths for an single operation, e.g.,   we may at the same time
>need to set value to 1.2.3 and 1.2.4 where 3 and 4 are field IDs for the same
>table. We may also possibly need to set 1.1 in the same operation.
>2. It's quite unnecessary we may set different Attributes in one single
>operation, therefore the AttrID part is always the same.
>
>Based on above, I think that:
>1. It may be very complex to have one specific 'path'  in one 'path' format to
>express the actual paths like 1.2.3 and 1.2.4 and 1.1 simulteneously , but it
>would be much simpler to have Data field to express it, like the data
>format as:
>     subpath(1.2.3) value, subpath(1.2.4) value, subpath(1.1) value
>2. for all subpaths, the head AttrID part is the same, and this is also
>the only
>part that are the same.
>
>Therefore, my thought is the AttrID part is defined in the protocol,
>leaving the
>subpath go along with the data.
>
> >
> > i.e you say parent-path=1,2,3,4 then everything else is relative to
> > that.
>The only possible common parent path is the Attribute ID.
>
> > Example if you say 5 afterwards for relative path, then the full path
> > is: 1,2,3,4,5.
> >
> > I still dont think that "5" should be in the data portion though.
>When we have more than one subpath that should be expressed, you may see the
>necessity for this.
>
>
>Cheers,
>Weiming
>
> >
> > cheers,
> > jamal
> >
> > On Tue, 2004-11-09 at 22:33, Wang,Weiming wrote:
> > > Hi Robert,
> > >
> > > Thank you very much to bring the slides to the meeting.
> > >
> > >  ----- Original Message -----
> > >         From: Robert Haas
> > >         Subject: Re: [Fwd: [Forces-protocol] Presentation of the
> > >         options for LFB-level multicast]
> > >
> > >         All,
> > >         I presented Weiming's slides just after Jamal's presentation
> > >         yesterday. No divergence of views on the principle of how to
> > >         describe paths was found.
> > >
> > >         Whereas, according to his slides, Weiming considers that the
> > >         distinction of Attribute, field, and index, must be reflected
> > >         in the path notation, the consensus in the room was that this
> > >         is not necessary: a path could be x.y.z, where it is clear
> > >         that x must be an attribute, and y and z can be field or
> > >         index. No need to mention it explicitely in the path notation.
> > >         [Weiming] Actually this is not the key point. While I'm just a
> > >         little afraid it may lead to ambiguity if , e.g., z can be a
> > >         field ID or a subscript without tag to indicate it.
> > >         The path can be constructed with index-search or
> > >         content-search. The consensus in the room was that the path
> > >         should include the whole thing, not only the first attribute,
> > >         as opposed to Weiming's suggestion on the last slide.
> > >         [Weiming]This is really the key point. We need to verify if it
> > >         is possible for a single 'path'  format to describe all need
> > >         for path. I just think that, apart from the attribute ID part,
> > >         others are tightly combined with Data. We may feel difficulty
> > >         to try to separate path explicitly.
> > >         Content-search remains to be defined more precisely, as well
> > >         as block access. So it is too early to disagree ;-)
> > >
> > >         Regards,
> > >         -Robert
> > >
> > >         Thank you again.
> > >         Weiming
> > >         Wang,Weiming wrote:
> > >
> > >         > Jamal,
> > >         >
> > >         > ----- Original Message -----
> > >         > From: "Jamal Hadi Salim" <hadi@znyx.com>
> > >         >
> > >         >
> > >         > > On Mon, 2004-11-08 at 00:12, Wang,Weiming wrote:
> > >         > >
> > >         > > > Jamal,
> > >         > > > ----- Original Message -----
> > >         > > > From: "Jamal Hadi Salim" <hadi@znyx.com>
> > >         > > > To: "Weiming Wang" <wmwang@mail.hzic.edu.cn>
> > >         > > >
> > >         > > >
> > >         > > > > I still dont see what where we have differences. If
> Robert
>can see that
> > >         > > > > difference i think it would be worth presenting it.
> > >         > > > >
> > >         > > >
> > >         > > > Sorry, but I don't think it's very proper for you to try to
>stop an
> > >         > > >
> > >         >
> > >         > individual
> > >         >
> > >         > > > presentation :)
> > >         > > >
> > >         > >
> > >         > > The first step is to understand what you are trying to show.
> > >         > > Look at how many emails it took for you to say "i see the
>difference".
> > >         > >
> > >         >
> > >         > Sorry, I know the difference very well, just can not see
> why you
>cannot catch
> > >         > it. That's just the 'i see the difference' mean.
> > >         >
> > >         > Cheers,
> > >         > Weiming
> > >         >
> > >         >
> > >         > > So i am not trying to stop your presentation rather trying to
>understand
> > >         > > what you are saying. Let me go back and read your other email
>now.
> > >         > >
> > >         > > cheers,
> > >         > > jamal
> > >         > >
> > >         > > PS:- Everyone i have talked to here upto before i went to bed
>did not
> > >         > > see any difference. This includes Robert.
> > >         > >
> > >         > >
> > >         >
> > >         >
> > >         >
> > >         >
> > >         >
> > >
> > >
> > >         --
> > >         Robert Haas
> > >         IBM Zurich Research Laboratory
> > >         Säumerstrasse 4
> > >         CH-8803 Rüschlikon/Switzerland
> > >         phone +41-1-724-8698  fax +41-1-724-8578
>http://www.zurich.ibm.com/~rha
> > >
> > >
> > > ______________________________________________________________________
> > >
> > > _______________________________________________
> > > Forces-protocol mailing list
> > > Forces-protocol@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/forces-protocol
> >
> >




_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol