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

[Steven Blake <[e-mail]>]

On Thu, 2004-10-21 at 16:16, Robert Haas wrote:

> Let me disuss this with a more detailed example. Suppose instances
> LFBx1 and LFBx2 in FE x and LFBy1 in FE y must be configured with the
> same values.
> 
> With the "layer-breaking" model, the CE assigns a mcast ID m to which
> FE x and FE y listen. FE x has a table with an entry (m, {LFBx1,
> LFBx2}), and FE y an entry (m, {LFBy1}).
> 
> With Zsolt's model, the CE assigns a mcast ID m to which FE x and FE y
> listen. The CE also defines an MIID M. FE x has a table with an entry
> (m) and FE y an entry (m) (basically, the groups those FEs belong to).
> Then FE x has another table (M, {LFBx1, LFBx2}), and FE y (M,
> {LFBy1}).

Right.

> I do agree that in your model, if you wanted to address another set of
> LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same
> mcast id m could be used, and you would simply define another M'. The
> tables would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}).
> 
> Now, even though we have way enough ~2^30 mcast IDs, I understand why
> you favor your approach. Note that in the current draft, this was
> stated as a possiblity (but instead of specifying a -virtualID-, I
> wrote VPN ID, quite the same idea).
> 
> Do you think we should explicitely forbid the "layer-breaking" option,
> or could we use both ?

Yes.  I consider it analogous to mixing IP addresses and ports.  It
requires a special case in the message parser, and it just doesn't look
clean.

Note that I don't see much use in needing to map a single LFB instance
ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the
need for multicast within the FE.  What is really needed is a
CE-assigned LFB instance ID alias that can be used on many FEs to allow
coordination of multicast table updates.


Regards,

// Steve


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