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

"Weiming Wang" <wmwang@mail.hzic.edu.cn> Sat, 13 November 2004 03:43 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 WAA25919 for <forces-protocol-web-archive@ietf.org>; Fri, 12 Nov 2004 22:43:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSoqD-0000kP-Tk for forces-protocol-web-archive@ietf.org; Fri, 12 Nov 2004 22:44:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSomr-0006he-1l; Fri, 12 Nov 2004 22:41:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSole-0006OY-6T for forces-protocol@megatron.ietf.org; Fri, 12 Nov 2004 22:40:02 -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 WAA25771 for <forces-protocol@ietf.org>; Fri, 12 Nov 2004 22:39:59 -0500 (EST)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSon3-0000Wy-DJ for forces-protocol@ietf.org; Fri, 12 Nov 2004 22:41:35 -0500
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.341813895; Sat, 13 Nov 2004 12:03:42 +0800 (CST)
Received: from wwm1 (unverified [219.82.171.206]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000110982@mail.gsu.cn>; Sat, 13 Nov 2004 11:38:23 +0800
Message-ID: <008a01c4c932$f2674b20$020aa8c0@wwm1>
From: Weiming Wang <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><154401c4c8be$a236d360$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20041112105212.03a87ec0@localhost>
Subject: Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]
Date: Sat, 13 Nov 2004 11:43:23 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
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.4 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30

Joel, as well as Jamal,

----- Original Message -----
From: "Joel M. Halpern" <joel@stevecrocker.com>

> 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.)
I think we are the same at this point. Actually I'm afraid this is even a little
more to my view on puting some subpaths in the data field. I think Jamal's
latest post has also noticed this, that is, a pure data format may become quite
difficult to describe a whole table here, instead, to allow to associate the
data with some subpath will make it easier. Jamal mentioned to put index of the
table in the data in this whole table response case, I think that the response
data structure may be better structured something like (say the table has field
as (f1, f2, f3)):
        index =1, f1=2, f2=3, f3=4
        index =2, f1=5, f2=6, f3=7
this means the field id and the index is also included in the data field, rather
than only the data value is included. In this way, data encoding becomes much
simpler, it actually makes us not necessary to define individual data encoding
for all individual LFB attributes, because the format can apply to all
regardless of their different field definitions.

Of course, this is only simple show for the use of combining subpath with data.
I can see other cases where such approach may be vital. Say we need to express a
need to "get a routing table (table ID =4, field is (f1, f2, f3) as above) with
all f1=2 or  f2=3 entries". In this case, we need to express a logical
relationship 'OR' for the two paths 4.f1 and 4.f2. I can see that to express the
'OR' is more ugly between the 'path-data' than in the data field only. The
original 'path-data' approach may have to be something like:
        path= 4.f1
        data=2
        .....  (need to add something to express the logical relation 'OR' for
the two 'path-data's)
       path=4.f2
        data=3

My proposed approach will be something like:
        Attribute ID= 4
        data = < f1=2 'OR' f2=3>

I just think it is more flexible for later one.

Cheers,
Weiming
>
> 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
>



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