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

Robert Haas <rha@zurich.ibm.com> Fri, 22 October 2004 01:00 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 VAA18043 for <forces-protocol-web-archive@ietf.org>; Thu, 21 Oct 2004 21:00:06 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnzZ-0007yV-RB for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:13:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl9Q-0000DJ-Ju; Thu, 21 Oct 2004 18:11:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjNB-0002W7-0J for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:17:21 -0400
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 QAA16867 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 16:17:18 -0400 (EDT)
Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjZq-0005sD-Qn for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:30:27 -0400
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LKGiJ8381662 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 16:16:44 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LKGiAm150162 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 14:16:44 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LKGhsd024817 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 14:16:43 -0600
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LKGeVF024697; Thu, 21 Oct 2004 14:16:41 -0600
Received: from [9.145.255.13] (sig-9-145-255-13.de.ibm.com [9.145.255.13]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA79856; Thu, 21 Oct 2004 22:16:33 +0200
Message-ID: <41781915.1030401@zurich.ibm.com>
Date: Thu, 21 Oct 2004 22:16:21 +0200
From: Robert Haas <rha@zurich.ibm.com>
Organization: IBM Research Lab
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steven Blake <slblake@petri-meat.com>
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain>
In-Reply-To: <1098385216.2340.239.camel@localhost.localdomain>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, "Yang, Lily L" <lily.l.yang@intel.com>, Zsolt Haraszti <zsolt@nc.rr.com>, "Joel M. Halpern" <jhalpern@MEGISTO.com>, forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok <alan.dekok@idt.com>, "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>, "Wang, Weiming" <wmwang@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="===============0459089876=="
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339

Steve,

Steven Blake wrote:

>>2)  Messages addressed to a group of LFBs that spans FE A and B should
>>not be delivered to FE C. So a PL-level multicasting is anyway needed
>>. Adding an additional MIID would then be redundant.
>>    
>>
>
>Eliminating the MIID (or any LFB instance ID) from these messages would
>be a very bad layering violation.  We need the PL-level multicast to
>scope the message delivery to FEs A & B, but not C (in fact, for
>efficiency, we need the multicast FEID to map to a TML "multicast"
>group).  I wouldn't suggest mixing in any LFB class/instance ID
>semantics into the FEID beyond that.
>
>LFBclass/instance ID multicasting is still needed primarily for scoping
>messages to instances of a class on multiple FEs that need to share a
>configuration (e.g., global prefix/nexthop table updates).
>Since we have assumed that the FE assigns LFB instance IDs, the CE
>cannot normally coordinate LFB instance ID assignment between FEs such
>that a single PL message addressed to a FE multicast group will be
>accepted by multiple LFB instances.  But if we introduce MIIDs which are
>assigned by the CE, then the CE can achieve the coordination.
>
>  
>
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}).

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 ?

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

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol