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

Steven Blake <slblake@petri-meat.com> Thu, 21 October 2004 19:24 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 PAA09994 for <forces-protocol-web-archive@ietf.org>; Thu, 21 Oct 2004 15:24:25 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKikg-00047i-4L for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 15:37:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiSe-0003zb-HR; Thu, 21 Oct 2004 15:18:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiGX-0002P9-0k for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 15:06:29 -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 PAA07183 for <forces-protocol@ietf.org>; Thu, 21 Oct 2004 15:06:23 -0400 (EDT)
Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiTA-0003gU-Ev for forces-protocol@ietf.org; Thu, 21 Oct 2004 15:19:31 -0400
Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CKiAj-0007Ue-9r; Thu, 21 Oct 2004 15:00:25 -0400
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
From: Steven Blake <slblake@petri-meat.com>
To: Robert Haas <rha@zurich.ibm.com>
In-Reply-To: <417573E8.7070502@zurich.ibm.com>
References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com>
Content-Type: text/plain
Message-Id: <1098385216.2340.239.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2)
Date: Thu, 21 Oct 2004 15:00:17 -0400
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - petri-meat.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
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>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit

On Tue, 2004-10-19 at 16:07, Robert Haas wrote:

> I think Zsolt has specified the multicast at LFB Instance-level very
> well. We had some discussions with Joel a while back and such a table
> with pointers from a -virtualID- to a list of LFB Instances was
> considered the way to go.

Agreed.

> But the subtle difference betwen Zsolt's proposal and the current
> approach taken in the protocol draft is that the PL-message
> destination ID is the -virtualID-, instead of introducing a new MIID.
> See Section 5 point g in the protocol draft.
> 
> I would favor the current approach for the following reasons (but I am
> not religious and want to hear other opinions):
> 
> 1)  -virtualID- must be unique NE-wide. The PL-level addressing IDs
> are by definition unique NE-wide.

Agreed.

> 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.

So for the canonical case of being able to multicast routing updates to
multiple FEs, we would need both a PL-level multicast FEID, and a
LFBselect TLV-level mulicast LFB instance ID (MIID).

> To cover the case of a list of LFB Instances (reminds me of xcast ;-)
> we can modify the LFBSelect TLV as follows:
> main hdr (eg type = config)|
> +--- T = LFBselect
>      |        |
>      |        +-- LFBCLASSID = target LFB class
>      |        |
>      |        |
>      |        +-- one more LFBInstance(s) = target LFB instance(s). 
>                   [the size of this TLV tells how long the list is]

I'm not sure this is needed.  If we have multiple LFB instances of a
certain class on an FE sharing configuration data, I would like to see
that explicitly represented in the model (a todo from the August IETF
that I haven't followed through on yet), rather than xcast'ing config
messages.


Regards,

// Steve


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