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

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

Zsolt,

Thank you for your intensive reply.

Yes, what I suggest is trying a multicast config (that is, the data is the same
for all instances) at pure instance layer by use of a very simple and explicit
multipul instance scheme. I understand your scheme for multicast at both FE
layer and instance layer. It's ture defining such a scheme can supply much more
powerful function than purely by use of explicit instances for object
addressing. Actually I think we have considered such scheme during protocol
design (by use of multicast FE id address and LFB isntance id address).I also
agree that the scheme you presented below to use an FE attribute to define
instance multicast group is practical to realize such multicast. What I just see
is, apart from using FEs and Instance multicast address, to use multipul
explicit instances is still valuable for customers. For example, consider there
are two LFBs that have one same attribute data to config, and the attribute data
is quite lenthy in protocol text. Because there is only one message to use,
users may be tired of defining a specific instance multicast group for such only
one time config. But they will definitely  be very tired of repeating the lenthy
protocol text. In this case, by use of multipul instances, I'm sure they will be
very happy.

Thank you.

Weiming

----- Original Message -----
From: "Zsolt Haraszti" <[e-mail]>

> I suggested this already way back, and now I bring this up again.
>
> First, I firmly believe that we must support multicast (and I think
> that is what Weiming is bringing up in his recent emails; if not,
> then I still do not understand the issue, so please explain; but the
> rest of this email is still valid.).
>
> Second, dividing the LFB address into two components, class ID and
> instance ID, and splitting the two into two TLVs have nothing
> to do with solving multicast.
What I think is to use a TLV to structuraly represent instances, for example, to
use a range structure for a range of instances.
>
> I define multicast in the ForCES context as sending the same
> configuration requests to a set of LFB instances, with the additional
> constraints:
> - the (LFB) instances that are targeted are of the same type (class)
> - the instances may reside over multiple FEs
> - although one or more instances of a certain class maybe target of a
>   a multicast request on a certain FE, there may be other instances of
>   the same class on the FE that are NOT part of the multicast request.
>   In other words, we must be able to selectively target only a sub-set
>   of the instances of the same class on any FE (that's why it's
>   multicast and not broadcast).
> - when LFB instances on multiple FEs are part of the same tree, the
>   LFB instances on one FE may have a different set of instance
>   IDs than LFBs on another FE.
>


> Further observations:
> - For all the practical cases where I see this useful, the multicast
>   groups may change over time, but rather infrequently.  That is,
>   potentially a large number of config requests may be sent to the
>   LFBs before the group membership changes.
> - In some cases the same LFB instance may be a member of multiple
>   multicast groups simultaneously.
>
> Example:
>
> An FE may have 4 instances of IP prefix lookup LFBs,
> each serving one channelized physical interface with potentially a
> large number of channels, each channel configured as an IP interface.
> There may be more than one FEs in the system.  Consider two cases: one
> without VRFs and one with VRFs.
>
> When there are no VRFs, the same FIB needs to be loaded into
> all the 4 LFBs (to all FEs if you have more than one).  And
> all subsequent updates to the FIB must be mirrored to all these
> LFBs.
>
> When there are VRFs and the interfaces can use overlapping address
> spaces (an all too common case for modern IPv4 edge routers),
> then we have a more refined situation.  The CE maintains as many
> separate FIBs as many VRFs are in use.  What needs to be loaded
> into a given LFB instance depends on the VRF membership of the
> interfaces served by the given instance.  That may change when
> the interface configurations change, which can be considered
> infrequent compared to route changes in the FIB.  A brute-force
> solution would be to mirror all VRFs to all LFB instances; this
> does not scale very well.  A more desirable solution is to download
> selectively the right content to the rigth LFBs.  So in this
> case we must be able to selectively form a multicast group for
> each VRF and make sure only those LFB instances are members which
> serve one or more interfaces that belong to the VRF.  Since
> the same LFB instance may serve interfaces of many VRFs, the
> LFB must receive the config request of multiple groups.
>
> The proposed model:
>
> Considering all the above, the notion of configurable multicast
> groups seems very appealing.  The idea is very similar to multicast
> trees in IP networks.  This is what was suggested earlier:
>
> We introduce a stateful multicast group model in which the CE can
> configure the FE to define and manage multicast groups.  This
> can be done, e.g., via a special attribute of the FE class instance.
> The heart of the model is a multicast table attribute in the FE
> object, outlined as follows:
>
> MTABLE := ARRAY of MGROUP
> MGROUP := {CID, MIID, IID-LIST}
> IID-LIST := ARRAY of IID
>
> where:
> - CID is an LFB class ID
> - IID is an LFB instance ID, valid on the FE
> - MIID is a "virtual" instance ID from a pre-defined "multicast" range,
>   i.e., it is not the actual IID of any instance on the FE.
>
> The CE can add/remove entries in the MTABLE, creating/removing multicast
> groups.
>
> The CE can also add/remove IIDs in the IID-LIST of any existing group,
> that is, grow or shrink the membership in a given group.
>
> Once a group is set, all subsequent requests using a CID:MIID
> address will be delivered to all LFB instances in the referred group.
>
> Benefits:
> - The above schema supports well the case of overlapping memberships.
> - Using the same group address across mutiple FEs will enable efficient
>   multi-FE multicasts, i.e., the same message can be sent to multiple
>   FEs.  This is because the CE can assign an MIID for each multicast
>   tree, so a config message with given CID:MIID address in the LFB TLV
>   will address the right set of LFB instances on all FEs.
>
> Cheers,
> Zsolt
>
> On Tue, 2004-10-19 at 00:00, Wang,Weiming wrote:
> > 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
> > > > >
> > > >
> > > >
> > >
> --
> Zsolt Haraszti                Phone:  [phone]
> Modular Networks              Mobile:      [phone]
>                               Email:  [e-mail]
>



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