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

"Weiming Wang" <wmwang@mail.hzic.edu.cn> Sun, 07 November 2004 17:27 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06473 for <forces-protocol-web-archive@ietf.org>; Sun, 7 Nov 2004 12:27:11 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqp2-0007gU-O9 for forces-protocol-web-archive@ietf.org; Sun, 07 Nov 2004 12:27:37 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqfl-0006Fc-8Q; Sun, 07 Nov 2004 12:17:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqXt-0003bu-PJ for forces-protocol@megatron.ietf.org; Sun, 07 Nov 2004 12:09:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05368 for <forces-protocol@ietf.org>; Sun, 7 Nov 2004 12:09:38 -0500 (EST)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQqY2-0007Ih-Su for forces-protocol@ietf.org; Sun, 07 Nov 2004 12:10:05 -0500
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.341813895; Mon, 8 Nov 2004 01:31:59 +0800 (CST)
Received: from wwm1 (unverified [219.82.185.32]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000103842@mail.gsu.cn>; Mon, 8 Nov 2004 01:12:07 +0800
Message-ID: <004c01c4c4ed$08882590$020aa8c0@wwm1>
From: "Weiming Wang" <wmwang@mail.hzic.edu.cn>
To: "Robert Haas" <rha@zurich.ibm.com>
References: <4189F776.4080306@zurich.ibm.com> <002a01c4c406$2bdce040$020aa8c0@wwm1> <418E2B60.3050706@zurich.ibm.com>
Subject: Re: [Forces-protocol] Presentation of the options for LFB-level multicast]
Date: Mon, 8 Nov 2004 01:12:58 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 3.7 (+++)
X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, "\(Ram Gopal \)" <ram.gopal@nokia.com>, Avri Doria <avri@acm.org>, forces-protocol@ietf.org, Jamal Hadi Salim <hadi@znyx.com>, Dong Ligang <donglg@mail.hzic.edu.cn>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1431079823=="
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 3.7 (+++)
X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df

Hi Robert,
  ----- Original Message ----- 
  From: Robert Haas 
  To: Weiming Wang 
  Cc: forces-protocol@ietf.org ; Jamal Hadi Salim ; Khosravi, Hormuzd M ; Avri Doria ; Dong Ligang ; (Ram Gopal ) 
  Sent: Sunday, November 07, 2004 10:04 PM
  Subject: 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" ?
  [Weimign]I think currently we may need the latter more. The requirements fo LFB-class level mcast may still need more experience to find its necessity. Actually What I meant was I just can not see the big difference between the LF-ID mcast and the virtual LFB instance ID mcast. It seems identical to me. maybe I missed something. 

  Thank you.
  Weiming

    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 

      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
_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol