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

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

Zsolt,

----- Original Message -----
From: "Zsolt Haraszti" <[e-mail]>
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?


> Weiming,
>
> I have a very hard time to resonate with your examples, and therefore
> with your reasoning.
>
> For one, if you end up needing 64k LFBs from the same class, I think
> you or we did something wrong with the model.  Sure you mean it an
> extreme case, but I think it is a misleading one.  I envision
> practical LFB models having up to a few hundred LFB instances, where
> multiple instances of the same class will be in very different roles
> (e.g., a Classifier LFB supporting Diffserv versus a Classifier
> LFB supporting IPsec, etc.), hence more often not sharing any config
> data than sharing some.
I think Joel has expained some. Actually I have no doult agreeing with you that
different instances may have different roles there fore may have different
attribute values, but we can not exclude that there are many cases the
attributes of instances are the same. From my current experiences, I'v already
seen the same attribute values needed for schedulers, queues, ports, policers,
and even classifiers. Note that what I mean the 'same' is not the same for all
data of insatnces, there can be only one attribute data entry that are set the
same, then the value of multiple addressing appears. Even if we have say 10
instances, to repeat the same data for 10 times is already boring thing to do.

> For two, displacing the two parts of the LFB address (class ID and
> instance ID) in the protocol is a much bigger concern to me than to
> allow ad-hoc/state-less multicast addressing.  It would be in some
> sense similar to if in the IP header the (sub-)network address and
> host-address part of the IP address were placed in distant offsets.
I see your thought here, and I actually like this, not at all exclude this. I
just think both the multicast address based mulitple addressing and the explicit
multiple addressing should all be needed. For multicast address based, it's more
fit for those insatnces that have more same data to set and the multicast group
are more permanent comparatively. For explicit based, it's more fit for some
instant use of the same data setup for instances. I try to show an example to
clear this as, say 10 insatnces, 1-5 need to setup same parameter1, 2-6 to set
same parameter2, 3-10 to set p3, 4-6 to set pa4, etc. In this case, to setup
many multicast group is really not applicable, but by using a very handy
explicit muliple addressing, it just makes things very easy.

> For three, on state-less versus state-ful multicast:  Your example
> below is based on the very extreme case when you have a SINGLE
> config message addressed to a VERY LARGE number of LFB instances
> of the same class.  I have not yet seen a practical case for this
> scenario.  I reiterate that multicast groups are not ad-hoc, and
> there will be typically a large number of config updates sent to a
> group after the group is formed.
>
I'm not sure if you mean explicit multiple instance addressing is state-less and
defining specific multicat group is stateful. I agree the latter is not ad-hoc.

> Regards,
> Zsolt
>

Thank you.
Weiming




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