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

"Joel M. Halpern" <joel@stevecrocker.com> Fri, 12 November 2004 16:19 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 LAA16418 for <forces-protocol-web-archive@ietf.org>; Fri, 12 Nov 2004 11:19:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeAC-0003qb-5r for forces-protocol-web-archive@ietf.org; Fri, 12 Nov 2004 11:20:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdvt-0002k6-0W; Fri, 12 Nov 2004 11:05:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSdkz-0007Ig-7V for forces-protocol@megatron.ietf.org; Fri, 12 Nov 2004 10:54:37 -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 KAA14370 for <forces-protocol@ietf.org>; Fri, 12 Nov 2004 10:54:34 -0500 (EST)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdmM-0003C4-Dt for forces-protocol@ietf.org; Fri, 12 Nov 2004 10:56:04 -0500
Received: from [130.129.133.92] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7934171; Fri, 12 Nov 2004 10:54:27 -0500
Message-Id: <6.1.2.0.0.20041112105212.03a87ec0@localhost>
X-Sender: joel@stevecrocker.com@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 12 Nov 2004 10:54:16 -0500
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>, <hadi@znyx.com>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
In-Reply-To: <154401c4c8be$a236d360$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> <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> <154401c4c8be$a236d360$845c21d2@Necom.hzic.edu.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

Yes, I am happy to repeat the path and data TLVs inside an OP TLV.
I just want all of the path information in the path TLV and the data in the 
data TLV.

My reference to SNMP is because one of the ugly things for SNMP is that if 
you want to fetch an entire table you have to fetch each individual element 
with a full OID for each one.  (And their OIDs are much longer than our 
path identifiers, for various historical reasons.)

Yours,
Joel

At 08:50 AM 11/12/2004, Wang,Weiming wrote:
>If we really want to optimize for cases with
>shared path, we could do so by allowing more complex nested TLVs.
>[Weiming]Do you mean multiple path-data TLVs in one OpTLV? If is, I agree 
>well.
>It helps well for multiple Attributes, but helps little to save Attribute IDs.
>
>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.
>[Weiming] Sorry, I can not catch it well. Could you explain a little more?
>thanks.
>
>As a minor point, note that getting / setting multiple elements can be done
>by sending multiple target selection TLVs.
>[Weiming] This is even more expensive, which means we are repeating LFB class
>and LFB instance ID as well as Attribute ID.
>
>Thank you.
>Weiming


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