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

["Wang,Weiming" <[e-mail]>]

Hi Robert,

>To cover the case of a list of LFB Instances (reminds me of xcast ;-) we can
modify the LFBSelect TLV as follows:
>
>main hdr (eg type = config)
>|
>+--- T = LFBselect
>      |        |
>      |        +-- LFBCLASSID = target LFB class
>      |        |
>      |        |
>      |        +-- one more LFBInstance(s) = target LFB instance(s).
>                  [the size of this TLV tells how long the list is]
[Weiming]That's just the point I propose. I can see the TLV with three more
types (the types can firther be represented by tags or purely by different TLV
type):
1. List of Instances
The V format is a list of instances,  as InstanceId1, Instance Id 2, ...
Instance Id N, representing to address the insatnces individually
2. A range of Insatnces
The V format is a range of Insatnce, as InsatnceId1, Instance Id2, representing
to addresss insatnces from Id1 to Id2.
3. A combination of above two.
We may use some flags to represent if it is for individual instance or for range
instance description.
[/Weiming]

But in the case of a multicast, I would simply drop the LFBSelect TLV altogether
as it is redundant (the LFB Instances are already selected by the -virtualID-).
What do you think ?
[Weiming] I just think the virtualID scheme and the above explicit ID (real ID)
scheme are all necessary. virtualID multicast can address comparatively
infrequent change LFB groups, while real ID mulitpul addressing can address some
instant and frequent changed LFB groups.

Thank you for the post.

Weiming

Regards,
-Robert

Wang,Weiming wrote:
Hormuzd,

Thanks for reply.

----- Original Message -----
From: "Khosravi, Hormuzd M" <[e-mail]>
Weiming,

In majority of cases, most of us have only seen single LFB instances on
FEs.
[Weiming] I'm afraid this is not true. From my experience, it's very often we
have more than  one instances.

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)
[Weiming] Yes, we have proposed using an insatnce broadcast address to address
all instances. It's useful, but still from my experience, it's not enough. I'v
very often seen the case where there is only one insatnce that has different
config requriement than all other instances.

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

-----Original Message-----
From: Wang,Weiming [mailto:[e-mail]]
Sent: Monday, October 18, 2004 9:00 PM
To: [e-mail]
Cc: Khosravi, Hormuzd M; [e-mail]; Steven Blake (petri-meat);
Joel M. Halpern; Alan DeKok; [e-mail]; [e-mail];
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" <[e-mail]>

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" <[e-mail]>

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol



_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol





--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone [phone]  fax [phone]  http://www.zurich.ibm.com/~rha



_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol



_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol