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

"Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com> Tue, 19 October 2004 08:37 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 EAA01253 for <forces-protocol-web-archive@ietf.org>; Tue, 19 Oct 2004 04:37:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJpgq-0007PX-B4 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 04:49:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpAJ-0007YH-8o; Tue, 19 Oct 2004 04:16:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJopR-0004Y0-8a for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 03:54:46 -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 DAA27849 for <forces-protocol@ietf.org>; Tue, 19 Oct 2004 03:54:38 -0400 (EDT)
Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJp1V-0006hU-UX for forces-protocol@ietf.org; Tue, 19 Oct 2004 04:07:14 -0400
Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9J7sXxn000678; Tue, 19 Oct 2004 07:54:33 GMT
Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9J7lmrh026119; Tue, 19 Oct 2004 07:47:48 GMT
Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101900535705960 ; Tue, 19 Oct 2004 00:53:57 -0700
Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 00:53:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Forces-protocol] RE: GET/SET in one msg ?
Date: Tue, 19 Oct 2004 00:51:51 -0700
Message-ID: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408>
Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ?
Thread-Index: AcS1kJoRQaburKgcSmWWNaIPX57HBwAHsSMg
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
To: "Wang,Weiming" <wmwang@mail.hzic.edu.cn>, hadi@znyx.com
X-OriginalArrivalTime: 19 Oct 2004 07:53:57.0519 (UTC) FILETIME=[C9A609F0:01C4B5B0]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Content-Transfer-Encoding: quoted-printable
Cc: ram.gopal@nokia.com, zsolt@nc.rr.com, "Joel M. Halpern" <jhalpern@MEGISTO.com>, "Steven Blake (petri-meat)" <slblake@petri-meat.com>, forces-protocol@ietf.org, Alan DeKok <alan.dekok@idt.com>, "Deleganes, Ellen M" <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: 3d7f2f6612d734db849efa86ea692407
Content-Transfer-Encoding: quoted-printable

Weiming,

In majority of cases, most of us have only seen single LFB instances on
FEs.
In any case, your requirement can easily be solved by defining a special
Instance ID for LFBs that addresses all instances of that LFB on the FE.
I thought we already had some text along these lines in the protocol
draft (probably the header section)

regards
Hormuzd
p.s. I haven't read Zsolt's email on this yet...

-----Original Message-----
From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] 
Sent: Monday, October 18, 2004 9:00 PM
To: hadi@znyx.com
Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat);
Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org;
Deleganes, Ellen M; Yang, Lily L
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?

Jamal,Hormuzd, and Joel,

I think we have already have the issue as an editorial note as below:

       Editorial Note:
                        1.  Under discussion is, when an 'FE Protocol
...

                        2.  Under discussion is, do we need to support
                            multiple objects addressing at the LFB Type
                            and LFB Instance layer? One simple way to
                            support multiple LFB types or instances is
                            to use TLVs to identify the group of Type
                            IDs and Instance IDs, rather than only one
                            Type and Instance ID.  A range of Instance
                            IDs may also be supported in this way.

Hormuzd and Joel, do you really think it is not the case? I remember
Joel
supposed there might be thousands of instances with same LFB calss.  In
this
case, if we do not support a range of intance addressing, it actually
makes our
protocol unpractical.

regards,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
>
> So far you are the second person who has shown desire for this. I was
> the other person; both of us are driven by implementation experience.
> How about we just keep it as a note in the draft for now (for progress
> reasons)?
> Hopefully implementation experience will show the error of whats being
> proposed right now, then we can come back and fix it?
>
> cheers,
> jamal
>
>
> On Mon, 2004-10-18 at 10:20, Weiming Wang wrote:
> > Hi Jamal,
> >
> > main hdr (eg type = config)
> >      |
> >      |
> >      +--- T = LFBselect
> >      |        |
> >      |        +-- LFBCLASSID = target LFB class
> >      |        |
> >      |        |
> >      |        +-- LFBInstance = target LFB instance
> >
> > [Weiming] The more I'm thinking, the more I see the value to address
multipul
> > LFB instances here (I can now live with single LFB class). To speak
of this,
I
> > have an aspire  to show my yesterday experience with my GRMP test
platform
> > (sorry I have to mention it). As you know, GRMP  does not support
multipul
LFB
> > instance addressing.  Yesterday, we had to prepare a show of the
platform to
> > guests from our sponsors. Before the show, we spent near one hour to
operate
on
> > the menu to construct a scenario, in which there were 5 output port,
5
> > associated schedulers (LFBs), and several other LFBs that have many
instances.
> > unfortunately, we faced a problem with one of the machine. Then we
had to do
it
> > again.  At that time, I had a VERY VERY strong desire that batch
configuration
> > based on multipul LFB isntance addressing can be used.
> >
> > I can see very simple scheme to include multipul instances here (by
ranging,
or
> > by enum, or by both). Definitely, I believe this will greatly
improve our
> > protocol.
> >
> > I sincerely hope this be considered seriously by gentlemen.
> >
> > Best regards,
> > Weiming
> >
> >      |        |
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >
> > In other words: Very similar to the way we have it already except
> > the naming has changed and we can target multiple
> > operations and multiple paths in an LFB instance
> > ----- Original Message -----
> > From: "Jamal Hadi Salim" <hadi@znyx.com>
> > >
> > > Welcome back Weiming. I have updated the text with the
query/response.
> > > The only outstanding issue is 6.7. Please weigh in.
> > > I think we are ready top start making updates.
> > >
> > > cheers,
> > > jamal
> > >
> >
> >
>



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