Re: [Forces-protocol] Presentation of the options for LFB-level multicast]

Weiming,
Sorry, the slides were made as a support for the presentation, so they 
are not very explicit alone. 

There is no LFB-class mcast.

Do you think it is important to add class mcast, i.e., "send this config 
command to all LFB of class X in FE a", or "send this config command to 
all LFB of class X in the NE" ?

At the moment, this can be done using three alternatives: a PL-ID mcast 
group, a virtual LFB instance ID, or list of LFB instances ID, each of 
which containing all the LFB instances of class X. So the question is, 
do we want to introduce a fourth alternative ?

Regards,
-Robert

Weiming Wang wrote:

> Hi Robert,
>  
> Just one tiny point. I still cannot see the vital difference between 
> the Merged mcast and Split mcast. Do you mean the main difference is 
> the Merged mcast is for LFB class mcast while the Split mcast is for 
> LFB Instance ID mcast only?  If possible, I think adding some more to 
> explain (or define) the m1 and i1 may help more or less, especially to 
> indicate if m1 is for LFB class and LFB instance, while il is only for 
> LFB instance IDs.
>  
> Cheers,
> Weiming
>
>     ----- Original Message -----
>     From: Robert Haas <mailto:rha@zurich.ibm.com>
>      
>     Hi All,
>     I haven't seen any message on ForCES in the last 2 days, so I
>     smell sth fishy. I post again my presentation here.
>     Cheers,
>     -Robert
>
>     -------- Original Message --------
>     Subject: 	[Forces-protocol] Presentation of the options for
>     LFB-level multicast
>     Date: 	Tue, 02 Nov 2004 22:12:20 +0100
>     From: 	Robert Haas <rha@zurich.ibm.com>
>     Organization: 	IBM Research Lab
>     To: 	<forces-protocol@ietf.org> <forces-protocol@ietf.org>
>
>
>
>All,
>
>Attached is a short presentation for the next IETF that summarizes the 
>three options for LFB-level multicast:
>- merged (among the current proposal in the draft),
>- split (among the current proposals in the draft, called VPN, and 
>Zsolt's proposal),
>-  xcat (Weiming's proposal).
>
>Also, there is a slide with the issue Jamal raised about unnecessarily 
>repeating the class ID for commands destined to LFBs of the same class. 
>Personally, I think the overhead is minimal. Maybe your view is different ?
>
>Please review the slides and let me know if you have comments/suggestions.
>
>Depending on the chosen solution(s), we may have to define a TLV for the 
>LFB Instance ID, as this can be a normal ID, a virtual ID (MIID), a 
>list, or a range.
>
>
>Regards,
>-- 
>Robert Haas
>IBM Zurich Research Laboratory
>Säumerstrasse 4
>CH-8803 Rüschlikon/Switzerland
>phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
>
>
>    
>
>
>-- 
>Robert Haas
>IBM Zurich Research Laboratory
>Säumerstrasse 4
>CH-8803 Rüschlikon/Switzerland
>phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
>
>     ------------------------------------------------------------------------
>     _______________________________________________
>     Forces-protocol mailing list
>     Forces-protocol@ietf.org
>     https://www1.ietf.org/mailman/listinfo/forces-protocol
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha