Re: [Forces-protocol] RE: GET/SET in one msg ?

"Joel M. Halpern" <jhalpern@MEGISTO.com> Thu, 21 October 2004 19:48 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 PAA12859 for <forces-protocol-web-archive@ietf.org>; Thu, 21 Oct 2004 15:48:30 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj7y-0004pk-2x for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 16:01:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKitq-0000Cn-Vn; Thu, 21 Oct 2004 15:47:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKifH-0005rj-EP for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 15:31:59 -0400
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 PAA10731 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 15:31:57 -0400 (EDT)
Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKirm-0004Ge-48 for forces-protocol@ietf.org; Thu, 21 Oct 2004 15:45:05 -0400
Received: from JLaptop.megisto.com ([192.168.20.234]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 15:30:55 -0400
Message-Id: <5.1.0.14.0.20041021152630.022f5218@mail.megisto.com>
X-Sender: jhalpern@mail.megisto.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Oct 2004 15:30:38 -0400
To: Zsolt Haraszti <zsolt@modularnet.com>, "Wang,Weiming" <wmwang@mail.hzic.edu.cn>
From: "Joel M. Halpern" <jhalpern@MEGISTO.com>
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
In-Reply-To: <1098383190.2883.386.camel@localhost.localdomain>
References: <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 21 Oct 2004 19:30:56.0030 (UTC) FILETIME=[7C3FEBE0:01C4B7A4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, "Steven Blake (petri-meat)" <slblake@petri-meat.com>, forces-protocol@ietf.org, Jamal Hadi Salim <hadi@znyx.com>, Alan DeKok <alan.dekok@idt.com>, Ellen M Deleganes <ellen.m.deleganes@intel.com>, "Yang, Lily L" <lily.l.yang@intel.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: 2409bba43e9c8d580670fda8b695204a

While I do not think it is common, I do think that some implementations 
without misusing the model will end up with that many or more LFB instances 
of a single class.
The example I gave before is an FE serving an OC48 which can be subdivided 
for fixed rate ports down to DS0.  You can argue that we should invent a 
multi-port LFB, but that does not seem an inevitable situation.

The odd aspect of this is the if we implement sending the same update to 
multiple LFB instances, it will actually be easier to make some changes if 
the ports are separate LFBs than it will be if they are table entries in a 
single LFB.
Or else we end up needing block selection syntax for SETs, with implicit 
element replication.  Which suggests we are doing something wrong, since 
that would mean 3 levels of multicast replication inside the system.

Yours,
Joel

At 02:26 PM 10/21/2004 -0400, Zsolt Haraszti wrote:
>For one, if you end up needing 64k LFBs from the same class, I think
>you or we did something wrong with the model.


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