From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 4 00:35:19 2004 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 XAA20017 for ; Sun, 3 Oct 2004 23:50:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE8ZV-0002fN-De for forces-archive@IETF.ORG; Sun, 03 Oct 2004 11:46:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00E9E802@cherry.ease.lsoft.com>; 3 Oct 2004 11:37:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38367406 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 3 Oct 2004 11:37:19 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 3 Oct 2004 11:36:20 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100308390460:11860 ; Sun, 3 Oct 2004 08:39:04 -0700 References: <1092188616.2662.2.camel@localhost.localdomain> <1095702145.2340.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/03/2004 08:39:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/03/2004 08:39:07 AM, Serialize complete at 10/03/2004 08:39:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1096817777.1048.285.camel@jzny.localdomain> Date: Sun, 3 Oct 2004 11:36:17 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Steve Blake To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1095702145.2340.15.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Steve/Zsolt On Mon, 2004-09-20 at 13:42, Steven Blake wrote: > After some discussions between the model and protocol design teams, > Zsolt Haraszti and I took the to-do to put together a proposal on how > LFB tables could be modeled and managed in the protocol. Finally got to peruse the doc over a large coffee. A few things: 1) In reference to the approach from Joel (that i posted a while back), an index is part of the path. You seem to have separated it. It actually does seem to make sense to do so for two reasons: a) an index is a dynamic runtime notation as opposed to a "static" class time definition. b) facilitates the block operations by having it separate. I am not sure if you had this in mind - thought id mention it. 2) You seem to preclude using the index as part of an entry definition. I think thats a legit usage. 3) Indices should be reusable when elements dissapear. 4) associative addressing/keying Hrm. I reread this twice and something is still bothering me. It does have an implicit "search" built in. First you search for _all_ references of the key and then operate on them. We have not talked about putting a search message on the protocol because it hasnt made any sense (so far maybe). Now you could also be meaning an atomic search_and_operate in which case that implies offloading the search to the FE. Not sure how wise that is. When do you see this as valuable? Wouldnt it just make sense for the CE to keep track of the state and infact such queries - if they need to be the sent to the FE (in the case the CE cant resolve them) - should first be translated into a proper path with proper indices (probably block indexing) then sent? 5) I am not sure i agree that INS and DEL are the only two operations needed. As an example: You could just instantiate a row without updating its values. And later update its values. So an ADD which is what you may be refering to as an INS is infact the two operations: an atomic CREATE (gives default values of say all 0s)+UPDATE (enter new values. An UPDATE could happen at any point to say update a cell. I think this specific subject is larger than just table items - so i will punt for now (but hope you would remove that assertion you have). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 4 17:46:38 2004 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 RAA29772 for ; Mon, 4 Oct 2004 17:46:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEaoR-0006UT-W8 for forces-archive@IETF.ORG; Mon, 04 Oct 2004 17:56:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EA0616@cherry.ease.lsoft.com>; Mon, 4 Oct 2004 17:46:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38557561 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 4 Oct 2004 17:46:36 -0400 Approved-By: slblake@PETRI-MEAT.COM Received: from 209.152.177.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Oct 2004 17:33:22 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CEaSR-0005OM-52; Mon, 04 Oct 2004 17:33:23 -0400 References: <1092188616.2662.2.camel@localhost.localdomain> <1095702145.2340.15.camel@localhost.localdomain> <1096817777.1048.285.camel@jzny.localdomain> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 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 - peach.ease.lsoft.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Message-ID: <1096925598.2341.39.camel@localhost.localdomain> Date: Mon, 4 Oct 2004 17:33:19 -0400 Reply-To: Steven Blake Sender: Forwarding and Control Element Separation From: Steven Blake Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1096817777.1048.285.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit On Sun, 2004-10-03 at 11:36, Jamal Hadi Salim wrote: > Finally got to peruse the doc over a large coffee. > A few things: > 1) In reference to the approach from Joel (that i posted a while back), > an index is part of the path. You seem to have separated it. It actually > does seem to make sense to do so for two reasons: > a) an index is a dynamic runtime notation as opposed to a "static" class > time definition. > b) facilitates the block operations by having it separate. > > I am not sure if you had this in mind - thought id mention it. That is exactly what we had in mind. > 2) You seem to preclude using the index as part of an entry definition. > I think thats a legit usage. We don't intend to preclude having the index as part of the entry definition. If the index is defined as part of an entry in the class model, then the INS command (not INS_IDX) would be used to insert the entry. I'm not sure what you think is a legit usage: allowing the index as part of an entry, or not? > 3) Indices should be reusable when elements dissapear. Agreed. > 4) associative addressing/keying > > Hrm. I reread this twice and something is still bothering me. > It does have an implicit "search" built in. First you search for _all_ > references of the key and then operate on them. Not always. For example, if the associative addressing operation is 'exact match', you wouldn't expect to match more than one entry. > We have not talked about putting a search message on the protocol > because it hasnt made any sense (so far maybe). Actually, associate addressing was on the agenda of the last conference call. > Now you could also be meaning an atomic search_and_operate in which case > that implies offloading the search to the FE. Not sure how wise that is. > When do you see this as valuable? The example most often mentioned is searching for an IP prefix entry by prefix value, rather than by index (so you wouldn't have to maintain the indices allocated to each FE for a particular prefix table). > Wouldnt it just make sense for the CE to keep track of the state and > infact such queries - if they need to be the sent to the FE (in the case > the CE cant resolve them) - should first be translated into a proper > path with proper indices (probably block indexing) then sent? It's a question of how much state you have to and want to mirror on the CE. Strictly speaking, associative addressing is not mandatory, because you could always maintain copies of each and every table on the CE. There are some potential efficiency gains to be had if you support it, and the proponents should have the burden of quantifying them. > 5) I am not sure i agree that INS and DEL are the only two operations > needed. As an example: > You could just instantiate a row without updating its values. And later > update its values. So an ADD which is what you may be refering to as an > INS is infact the two operations: > an atomic CREATE (gives default values of say all 0s)+UPDATE (enter new > values. An UPDATE could happen at any point to say update a cell. In the vernacular of the proposal, INS == ADD, SET == UPDATE. The assumption underlying this is that the entries already exist, so you don't have to create individual rows, for instance, you just have to set them to non-default values (default usually zero and inactive, but specified in the class definition). With INS_IDX and DEL_IDX only, you could maintain complete synchronization of state between the CE and FE. Of course nobody is proposing to limit the operation set to only these two. > I think this specific subject is larger than just table items - so i > will punt for now (but hope you would remove that assertion you have). Did my comment clarify the situation? Regards, // Steve From owner-forces@PEACH.EASE.LSOFT.COM Mon Oct 4 21:31:46 2004 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 VAA17182 for ; Mon, 4 Oct 2004 21:31:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEeKM-0005xa-Qd for forces-archive@IETF.ORG; Mon, 04 Oct 2004 21:41:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00EA07E0@cherry.ease.lsoft.com>; Mon, 4 Oct 2004 21:31:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38578875 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 4 Oct 2004 21:31:47 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Oct 2004 21:30:35 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i951XwJk007992 for ; Tue, 5 Oct 2004 01:33:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i951XqHg009462 for ; Tue, 5 Oct 2004 01:33:52 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100418303224786 for ; Mon, 04 Oct 2004 18:30:32 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 18:30:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-forces-protocol-00.txt Thread-Index: AcSnKMAIjL/RMfyJS1WKgFUgzEAmjwA3O07gAJ02p/AAAA65wA== X-OriginalArrivalTime: 05 Oct 2004 01:30:32.0933 (UTC) FILETIME=[E8104950:01C4AA7A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E02C2A328@orsmsx408> Date: Mon, 4 Oct 2004 18:30:32 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: FW: I-D ACTION:draft-ietf-forces-protocol-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable FYI...the original draft with minor editorial updates, Hormuzd -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, September 30, 2004 12:32 PM To: i-d-announce@ietf.org Cc: forces@peach.ease.lsoft.com Subject: I-D ACTION:draft-ietf-forces-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Protocol Specification Author(s) : A. Doria Filename : draft-ietf-forces-protocol-00.txt Pages : 60 Date : 2004-9-30 =09 This specification documents the Forwarding and Control Element Seperation protocol. This protocol is desgined to be used between a Control Element and a Forwarding Element in a Routing Network Element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-protocol-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 5 11:15:38 2004 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 LAA06742 for ; Tue, 5 Oct 2004 11:15:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErBl-0003ka-Qx for forces-archive@IETF.ORG; Tue, 05 Oct 2004 11:25:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00EA19C2@cherry.ease.lsoft.com>; Tue, 5 Oct 2004 11:15:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38678556 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 5 Oct 2004 11:15:38 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 5 Oct 2004 11:14:15 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100508165691:13833 ; Tue, 5 Oct 2004 08:16:56 -0700 References: <1092188616.2662.2.camel@localhost.localdomain> <1095702145.2340.15.camel@localhost.localdomain> <1096817777.1048.285.camel@jzny.localdomain> <1096925598.2341.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/05/2004 08:16:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/05/2004 08:16:59 AM, Serialize complete at 10/05/2004 08:16:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1096989251.1034.32.camel@jzny.localdomain> Date: Tue, 5 Oct 2004 11:14:11 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Steve Blake To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1096925598.2341.39.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit On Mon, 2004-10-04 at 17:33, Steven Blake wrote: > On Sun, 2004-10-03 at 11:36, Jamal Hadi Salim wrote: > > 2) You seem to preclude using the index as part of an entry definition. > > I think thats a legit usage. > > We don't intend to preclude having the index as part of the entry > definition. If the index is defined as part of an entry in the class > model, then the INS command (not INS_IDX) would be used to insert the > entry. > > I'm not sure what you think is a legit usage: allowing the index as part > of an entry, or not? Allowing it as part of a table entry in addition to it being a path defining entity. > > 4) associative addressing/keying > > > > Hrm. I reread this twice and something is still bothering me. > > It does have an implicit "search" built in. First you search for _all_ > > references of the key and then operate on them. > > Not always. For example, if the associative addressing operation is > 'exact match', you wouldn't expect to match more than one entry. > It would still necessitate a search of some form which would be a _lot_ more complex than that of a simple index. In your text you do refer to the associative piece as a "search" key; - the index is more of a path identifier. > > We have not talked about putting a search message on the protocol > > because it hasnt made any sense (so far maybe). > > Actually, associate addressing was on the agenda of the last conference > call. I know - I am just trying to replace it in context now that you have put it in text. > > Now you could also be meaning an atomic search_and_operate in which case > > that implies offloading the search to the FE. Not sure how wise that is. > > When do you see this as valuable? > > The example most often mentioned is searching for an IP prefix entry > by prefix value, rather than by index (so you wouldn't have to maintain > the indices allocated to each FE for a particular prefix table). The search by prefix as a datapath operation is understandable. In a management perspective though (as in the case of a CE asking a FE to reference an entry in a table), does it not make sense to maintain indices even if they dont make sense from a datapath perspective? > > Wouldnt it just make sense for the CE to keep track of the state and > > infact such queries - if they need to be the sent to the FE (in the case > > the CE cant resolve them) - should first be translated into a proper > > path with proper indices (probably block indexing) then sent? > > It's a question of how much state you have to and want to mirror on the > CE. Strictly speaking, associative addressing is not mandatory, because > you could always maintain copies of each and every table on the CE. > There are some potential efficiency gains to be had if you support it, > and the proponents should have the burden of quantifying them. If you assume that CE and FE states would be in sync - a valid assumption i believe - then i see the efficiency as having more state at the CE. I am not sure now which side Joel was on, but could you hint one value on doing it at the FE with a search key? > > I think this specific subject is larger than just table items - so i > > will punt for now (but hope you would remove that assertion you have). > > Did my comment clarify the situation? It does. I think its easier to look at what you specified as requirements then we (the protocol team) would discuss how best to meet those requirements. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 5 11:33:28 2004 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 LAA08013 for ; Tue, 5 Oct 2004 11:33:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErSc-0005zV-QJ for forces-archive@IETF.ORG; Tue, 05 Oct 2004 11:43:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EA1874@cherry.ease.lsoft.com>; Tue, 5 Oct 2004 11:33:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38680260 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 5 Oct 2004 11:33:03 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 5 Oct 2004 11:23:40 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7691638 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 05 Oct 2004 11:23:38 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <1096925598.2341.39.camel@localhost.localdomain> <1092188616.2662.2.camel@localhost.localdomain> <1095702145.2340.15.camel@localhost.localdomain> <1096817777.1048.285.camel@jzny.localdomain> <1096925598.2341.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20041005112011.023e0b40@localhost> Date: Tue, 5 Oct 2004 11:23:04 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Table model and config operators in ForCES rev. 2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1096989251.1034.32.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I tend to think that all we need is simply indexed tables from a management perspective. All "searching" would then be the responsibility of the CE, using the tables it has. I think that will keep the protocol simpler and keep the FE simpler in most cases. In a few cases where the FE natural implementation is a memory associative structure (hash or tree), this would be somewhat more effort for the FE to support. (Note that real CAMs are actually a case where the index method works find, since those naturally have real indexes for management, while supporting context lookups for data plane.) Yours, Joel At 11:14 AM 10/5/2004 -0400, Jamal Hadi Salim wrote: > > > Wouldnt it just make sense for the CE to keep track of the state and > > > infact such queries - if they need to be the sent to the FE (in the case > > > the CE cant resolve them) - should first be translated into a proper > > > path with proper indices (probably block indexing) then sent? > > > > It's a question of how much state you have to and want to mirror on the > > CE. Strictly speaking, associative addressing is not mandatory, because > > you could always maintain copies of each and every table on the CE. > > There are some potential efficiency gains to be had if you support it, > > and the proponents should have the burden of quantifying them. > >If you assume that CE and FE states would be in sync - a valid >assumption i believe - then i see the efficiency as having more state at >the CE. >I am not sure now which side Joel was on, but could you hint one value >on doing it at the FE with a search key? From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 6 14:29:43 2004 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 OAA20299 for ; Wed, 6 Oct 2004 14:29:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFGh3-0004ek-Kb for forces-archive@IETF.ORG; Wed, 06 Oct 2004 14:39:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EA360A@cherry.ease.lsoft.com>; Wed, 6 Oct 2004 14:29:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38869655 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 6 Oct 2004 14:29:21 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 6 Oct 2004 14:23:02 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7698255 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 06 Oct 2004 14:23:01 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <1092188616.2662.2.camel@localhost.localdomain> <1092188616.2662.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20041006141858.024c5d48@localhost> Date: Wed, 6 Oct 2004 14:22:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Two questions on Table model and config operators in ForCES rev. 2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1095702145.2340.15.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Aren't INS_IDX! and SET! identical operations? Allowing value based indexing to match multiple entries seems a mistake. It makes "key" not a key. It seems to me that if we are going to allow associative access at all, it should only be to identified key fields and only when those fields are actually sufficiently unique keys. Yours, Joel M. Halpern At 01:42 PM 9/20/2004 -0400, you wrote: >After some discussions between the model and protocol design teams, >Zsolt Haraszti and I took the to-do to put together a proposal on how >LFB tables could be modeled and managed in the protocol. The attached >file is what we came up with. > >Please review and send comments to the list. > > >Regards, > >// Steve From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 7 00:50:21 2004 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 AAA22775 for ; Thu, 7 Oct 2004 00:50:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFQO6-00063p-KV for forces-archive@IETF.ORG; Thu, 07 Oct 2004 01:00:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EA42CE@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 0:50:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38939487 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 00:50:22 -0400 Approved-By: zsolt@MODULARNET.COM Received: from 204.85.2.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 00:49:51 -0400 Received: (qmail 12548 invoked by uid 530); 7 Oct 2004 04:49:50 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.823442 secs); 07 Oct 2004 04:49:50 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 7 Oct 2004 04:49:50 -0000 References: <1092188616.2662.2.camel@localhost.localdomain> <1092188616.2662.2.camel@localhost.localdomain> <5.1.0.14.0.20041006141858.024c5d48@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit Message-ID: <1097124404.2782.2.camel@localhost.localdomain> Date: Thu, 7 Oct 2004 00:46:44 -0400 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Modular Networks, Inc. Subject: Re: Two questions on Table model and config operators in ForCES rev. 2 Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20041006141858.024c5d48@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Wed, 2004-10-06 at 14:22, Joel M. Halpern wrote: > Aren't INS_IDX! and SET! identical operations? Yes, they are; one can be eliminated. My mistake. > > Allowing value based indexing to match multiple entries seems a > mistake. It makes "key" not a key. It seems to me that if we are going to > allow associative access at all, it should only be to identified key fields > and only when those fields are actually sufficiently unique keys. I tend to agree. /zsolt > Yours, > Joel M. Halpern > > At 01:42 PM 9/20/2004 -0400, you wrote: > >After some discussions between the model and protocol design teams, > >Zsolt Haraszti and I took the to-do to put together a proposal on how > >LFB tables could be modeled and managed in the protocol. The attached > >file is what we came up with. > > > >Please review and send comments to the list. > > > > > >Regards, > > > >// Steve -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 7 02:59:19 2004 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 CAA15833 for ; Thu, 7 Oct 2004 02:59:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFSOt-0005U6-2L for forces-archive@IETF.ORG; Thu, 07 Oct 2004 03:09:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00EA435A@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 2:59:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38948600 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 02:59:14 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 02:58:39 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i977268c006482; Thu, 7 Oct 2004 07:02:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i976ncJF028753; Thu, 7 Oct 2004 06:49:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100623583732531 ; Wed, 06 Oct 2004 23:58:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 23:58:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Table model and config operators in ForCES rev. 2 Thread-Index: AcSfQCk4e/RPMJe0QvqhFI2KsgzCdQM97jcg X-OriginalArrivalTime: 07 Oct 2004 06:58:37.0522 (UTC) FILETIME=[11D1B320:01C4AC3B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E025791A0@orsmsx408> Date: Wed, 6 Oct 2004 23:55:22 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Steven Blake To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Steve, Zsolt, Thanks a lot for taking the time and effort to do this! Overall I think it looks very good, we are definitely getting much closer now, I think. This is obviously written more like requirements for the protocol team rather than imposing any particular message types, which is a very good idea. The one comment I did have is for some of the operations '!' seemed to change the semantics of the operation. My understanding from the text was that the basic reason for Operation! is to say that no error reporting or response is needed for that particular operation. However, the text seemed to imply that the operation behaved different with !, which is not a good idea...the semantics should be consistent...Example, 4.1.6 SET If table[idx] exists, overwrite its content with provided , report error otherwise. 4.1.7 SET! If table[idx] exists, overwrite its content with provided , create new entry with idx otherwise.-> SET/UPDATE should either do this in both cases or none at all. The only thing different with ! is that the error reporting is not needed back to the CE. Let me know your thoughts ? Another point that Jamal was also making, regarding index being part of the entry definition itself...I agree with this...Example, I see SET , idx, ...being encoded in the protocol msg as=20 SET , Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake Sent: Monday, September 20, 2004 10:42 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Table model and config operators in ForCES rev. 2 After some discussions between the model and protocol design teams, Zsolt Haraszti and I took the to-do to put together a proposal on how LFB tables could be modeled and managed in the protocol. The attached file is what we came up with. Please review and send comments to the list. Regards, // Steve From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 7 17:22:27 2004 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 RAA28516 for ; Thu, 7 Oct 2004 17:22:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFfsK-0005Pt-FZ for forces-archive@IETF.ORG; Thu, 07 Oct 2004 17:32:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EA543B@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 17:22:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39055460 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 17:22:23 -0400 Approved-By: zsolt@MODULARNET.COM Received: from 204.85.2.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 17:21:52 -0400 Received: (qmail 17521 invoked by uid 530); 7 Oct 2004 21:21:52 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.850167 secs); 07 Oct 2004 21:21:52 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 7 Oct 2004 21:21:51 -0000 References: <468F3FDA28AA87429AD807992E22D07E025791A0@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit Message-ID: <1097183927.2894.26.camel@localhost.localdomain> Date: Thu, 7 Oct 2004 17:18:48 -0400 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Modular Networks, Inc. Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025791A0@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit On Thu, 2004-10-07 at 02:55, Khosravi, Hormuzd M wrote: > Steve, Zsolt, > > Thanks a lot for taking the time and effort to do this! Overall I think > it looks very good, we are definitely getting much closer now, I think. > > This is obviously written more like requirements for the protocol team > rather than imposing any particular message types, which is a very good > idea. That was the idea. > > The one comment I did have is for some of the operations '!' seemed to > change the semantics of the operation. My understanding from the text > was that the basic reason for Operation! is to say that no error > reporting or response is needed for that particular operation. However, > the text seemed to imply that the operation behaved different with !, > which is not a good idea...the semantics should be consistent...Example, > No, the "!" version has very little to do with the suppressed error feedback. (The "!" notation may have been misleading..., sorry.) The SET! does what the text says: execute the SET request even though the entry does not yet exist (essentially creating it). Or in case of INS!, overwrite the entry if it already exists. The SET! and INS! operators are semantically redundant (identical), but the SET, INS, and SET!(=INS!) operators represent three different configuration request semantics. (Irrespectively how it is mapped to protocol syntax.) The suppression of error feedback -- or in general error handling -- is a whole separate story and was not (yet) addressed in the discussion. Once the basics are agreed, we should go there too. > 4.1.6 SET > If table[idx] exists, overwrite its content with provided , > report error otherwise. > > 4.1.7 SET! > If table[idx] exists, overwrite its content with provided , > create new entry with idx otherwise.-> SET/UPDATE should either do this > in both cases or none at all. The only thing different with ! is that > the error reporting is not needed back to the CE. > > Let me know your thoughts ? > > Another point that Jamal was also making, regarding index being part of > the entry definition itself...I agree with this...Example, I see > > SET , idx, ...being encoded in the protocol msg as > SET , > Again, that is a syntax issue. Semantically it is still a separate peace of information that you need to carry. But since you brought it up, what do you mean by ? Whatever you do, that = idx, , so the SET message will be: SET , = SET , idx, What is the difference? Are you reading TLV boundaries or design group boundaries into the grouping? In single-entry table operations, I can actually envision the idx be voluntarily be regarded as part of the path information. Cheers, Zsolt > > Regards > Hormuzd > > > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Steven Blake > Sent: Monday, September 20, 2004 10:42 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Table model and config operators in ForCES rev. 2 > > After some discussions between the model and protocol design teams, > Zsolt Haraszti and I took the to-do to put together a proposal on how > LFB tables could be modeled and managed in the protocol. The attached > file is what we came up with. > > Please review and send comments to the list. > > > Regards, > > // Steve -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 7 19:11:24 2004 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 TAA08495 for ; Thu, 7 Oct 2004 19:11:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFhZl-0003jT-NO for forces-archive@IETF.ORG; Thu, 07 Oct 2004 19:21:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EA55D0@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 19:11:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39066721 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 19:11:24 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 19:10:57 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i97NBGxA018631; Thu, 7 Oct 2004 23:11:16 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i97NE01I022471; Thu, 7 Oct 2004 23:14:14 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100716105130626 ; Thu, 07 Oct 2004 16:10:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 16:10:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Table model and config operators in ForCES rev. 2 Thread-Index: AcSss8QLAEl8xQmXQNWlj3vvLz6FKwACGwjg X-OriginalArrivalTime: 07 Oct 2004 23:10:51.0217 (UTC) FILETIME=[E3692C10:01C4ACC2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> Date: Thu, 7 Oct 2004 16:10:50 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Hi Zsolt, Thanks for your prompt reply! Pls see my comments below...=20 -----Original Message----- > > The one comment I did have is for some of the operations '!' seemed to > change the semantics of the operation. My understanding from the text > was that the basic reason for Operation! is to say that no error > reporting or response is needed for that particular operation. However, > the text seemed to imply that the operation behaved different with !, > which is not a good idea...the semantics should be consistent...Example, > No, the "!" version has very little to do with the suppressed error feedback. (The "!" notation may have been misleading..., sorry.) The SET! does what the text says: execute the SET request even though the entry does not yet exist (essentially creating it). Or in case of INS!, overwrite the entry if it already exists. The SET! and INS! operators are semantically redundant (identical), but the SET, INS, and SET!(=3DINS!) operators represent three different configuration request semantics. (Irrespectively how it is mapped to protocol syntax.) [HK] Thanks, this clarification helps, I got a very different impression from your text. I think all you need is ADD=3D=3DINS and UPDATE=3D=3DSET!, I am not sure = if just SET is really needed ?? > 4.1.6 SET > If table[idx] exists, overwrite its content with provided , > report error otherwise. > > 4.1.7 SET! > If table[idx] exists, overwrite its content with provided , > create new entry with idx otherwise.-> SET/UPDATE should either do this > in both cases or none at all. The only thing different with ! is that > the error reporting is not needed back to the CE. > > Let me know your thoughts ? > > Another point that Jamal was also making, regarding index being part of > the entry definition itself...I agree with this...Example, I see > > SET , idx, ...being encoded in the protocol msg as > SET , > Again, that is a syntax issue. Semantically it is still a separate peace of information that you need to carry. But since you brought it up, what do you mean by ? Whatever you do, that =3D idx, , so the SET message will be: SET , =3D SET , idx, What is the difference? Are you reading TLV boundaries or design group boundaries into the grouping? [HK] Yes, I was thinking more along the lines of adding an array of entries in terms of the protocol messages, TLVs, etc...I agree with your explanation. Thanks Hormuzd From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Oct 8 09:33:57 2004 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 JAA23217 for ; Fri, 8 Oct 2004 09:33:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFv2a-0006e1-Mj for forces-archive@IETF.ORG; Fri, 08 Oct 2004 09:44:13 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00EA68C9@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:33:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39171443 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:33:56 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 09:30:58 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100806333822:18151 ; Fri, 8 Oct 2004 06:33:38 -0700 References: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 06:33:38 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 06:33:40 AM, Serialize complete at 10/08/2004 06:33:40 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1097242254.1042.682.camel@jzny.localdomain> Date: Fri, 8 Oct 2004 09:30:54 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit I just realized something else: With separation of index into a separate clause, it means table operations are restricted to row operations. In other words, i couldnt operate on foo1 of row index 2; i would need to operate on row index 2. Perhaps one of the block operations covers this scenario? or maybe we need one? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 8 09:56:57 2004 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 JAA24443 for ; Fri, 8 Oct 2004 09:56:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvOY-00072d-2d for forces-archive@IETF.ORG; Fri, 08 Oct 2004 10:07:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EA6722@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:56:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39173182 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:56:35 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 09:44:47 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7707913 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 08 Oct 2004 09:44:45 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20041008093846.023fe008@localhost> Date: Fri, 8 Oct 2004 09:44:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Table model and config operators in ForCES rev. 2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1097242254.1042.682.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Given an LFB class with a table (array) of structures, where the structure contains an element foo, it is necessary that the protocol operation be able to reference the foo element of the structure at table entry 1. It is also necessary that if the table (t) contains a structure which contains a table (u) with a structure containing an element bar, I need to be able to get to the bar within the second element of the u in the third entry in t. We need to be able to reference lfb_instance: faa (a top level element lfb_instance: t[1] (a table entry) lfb_instance: t[2].foo (a structure element in a table entry) lfb_instance: t[3].u[2].bar I prefer to do this by including the indices in line with the element selection. This seems to work naturally with uint32 indexes. It does not bother me if content selection can not be used this way. (I believe the result would be that most implementation would only use content addressing for the rare reverse translation needed to check the CE table structures.) Yours, Joel At 09:30 AM 10/8/2004 -0400, Jamal Hadi Salim wrote: >I just realized something else: >With separation of index into a separate clause, it means table >operations are restricted to row operations. >In other words, i couldnt operate on foo1 of row index 2; i would >need to operate on row index 2. Perhaps one of the block operations >covers this scenario? or maybe we need one? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 8 10:44:03 2004 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 KAA00582 for ; Fri, 8 Oct 2004 10:44:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFw8S-0008LG-5l for forces-archive@IETF.ORG; Fri, 08 Oct 2004 10:54:20 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EA6863@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 10:44:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39177682 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 10:44:01 -0400 Approved-By: zsolt@MODULARNET.COM Received: from 204.85.2.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 10:43:47 -0400 Received: (qmail 22279 invoked by uid 530); 8 Oct 2004 14:43:46 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.821788 secs); 08 Oct 2004 14:43:46 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 8 Oct 2004 14:43:45 -0000 References: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> <1097242254.1042.682.camel@jzny.localdomain> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit Message-ID: <1097246443.3348.37.camel@localhost.localdomain> Date: Fri, 8 Oct 2004 10:40:43 -0400 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Modular Networks, Inc. Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1097242254.1042.682.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 09:30, Jamal Hadi Salim wrote: > I just realized something else: > With separation of index into a separate clause, it means table > operations are restricted to row operations. As opposed to what? (1) Multi-entry operations (multiple rows) Or... (2) Operation in a single field of a table entry (row) when the table entry is a struct? Or... (3) Operating on a subset of fields (more than one field, but not the whole struct) in a struct-type table entry? (1) and (2) are both supported. The block operations are intended to support (1). (2) is supported by specifying the field, also by an index, as part of the path. (Using Joel's Class A example, the path (2, 8, 1) specifies the string field (named N) in struct "star" in the idx=8 entry of table C.) > In other words, i couldnt operate on foo1 of row index 2; i would > need to operate on row index 2. Perhaps one of the block operations > covers this scenario? or maybe we need one? What is not explicitly supported yet is (3). To illustrate this let me extend the star struct in Class A in the following way: struct star { [1] string[32] N [2] array of { int32 X } Arr [3] int32 Y # new field [4] uint32 Z # new field So what is not supported is a compact operation to set, e.g., N and Y (without affecting the other fields). You can of course use two separate SET operations, i.e., SET path=(2, 8, 1) "spinoza" SET path=(2, 8, 4) 0xdeadbeef and that may be sufficient. Other options would include extending the block operations to structs (was that what you Jamal referred to?). Cheers, Zsolt > > cheers, > jamal -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 8 11:34:39 2004 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 LAA04953 for ; Fri, 8 Oct 2004 11:34:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwvO-0001Ep-TF for forces-archive@IETF.ORG; Fri, 08 Oct 2004 11:44:58 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EA6945@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 11:34:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39181891 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 11:34:32 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 11:21:14 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100808235393:18298 ; Fri, 8 Oct 2004 08:23:53 -0700 References: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> <1097242254.1042.682.camel@jzny.localdomain> <1097246443.3348.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 08:23:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 08:23:55 AM, Serialize complete at 10/08/2004 08:23:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1097248870.1072.14.camel@jzny.localdomain> Date: Fri, 8 Oct 2004 11:21:10 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1097246443.3348.37.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 10:40, Zsolt Haraszti wrote: > On Fri, 2004-10-08 at 09:30, Jamal Hadi Salim wrote: > > I just realized something else: > > With separation of index into a separate clause, it means table > > operations are restricted to row operations. > > As opposed to what? > (1) Multi-entry operations (multiple rows) > Or... > (2) Operation in a single field of a table entry (row) when > the table entry is a struct? > Or... > (3) Operating on a subset of fields (more than one field, > but not the whole struct) in a struct-type table entry? > > (1) and (2) are both supported. The block operations are > intended to support (1). (2) is supported by specifying the > field, also by an index, as part of the path. (Using Joel's > Class A example, the path (2, 8, 1) specifies the string field > (named N) in struct "star" in the idx=8 entry of table C.) > Ok, so 2 is covered. It was actually what i was referencing in my email. 2 is a subset of 3 - so how to extend the constructs of 2 to cover 3? 3 is very legit need - think updating a set of NH pointers in a LPM table to point to new NH. > > In other words, i couldnt operate on foo1 of row index 2; i would > > need to operate on row index 2. Perhaps one of the block operations > > covers this scenario? or maybe we need one? > > What is not explicitly supported yet is (3). To illustrate > this let me extend the star struct in Class A in the following > way: > struct star { > [1] string[32] N > [2] array of { > int32 X > } Arr > [3] int32 Y # new field > [4] uint32 Z # new field > > So what is not supported is a compact operation to set, e.g., > N and Y (without affecting the other fields). > You can of course use two separate SET operations, i.e., > SET path=(2, 8, 1) "spinoza" > SET path=(2, 8, 4) 0xdeadbeef > and that may be sufficient. Other options would include > extending the block operations to structs (was that what > you Jamal referred to?). I think if you could select a row block, then you should be able to select a column block in the same manner. In otherwords, a 2 dimension matrix operation with each dimension possibly being a block/range. This should cover all possible scenarios. This assumes that the Ids in the class definition are being sequentially allocated. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Oct 9 00:58:48 2004 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 AAA28972 for ; Sat, 9 Oct 2004 00:58:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG9Tm-0005Wf-62 for forces-archive@IETF.ORG; Sat, 09 Oct 2004 01:09:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00EA769F@cherry.ease.lsoft.com>; Sat, 9 Oct 2004 0:58:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39258295 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 9 Oct 2004 00:58:47 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 9 Oct 2004 00:58:15 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i994wcsa028712; Sat, 9 Oct 2004 04:58:38 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9951chb005511; Sat, 9 Oct 2004 05:01:38 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100821580907379 ; Fri, 08 Oct 2004 21:58:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 21:58:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Table model and config operators in ForCES rev. 2 Thread-Index: AcStRUgJEAmYhvtiQAG1CPQls53qtwAdsO6g X-OriginalArrivalTime: 09 Oct 2004 04:58:10.0143 (UTC) FILETIME=[92CAAEF0:01C4ADBC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E025791B0@orsmsx408> Date: Fri, 8 Oct 2004 21:57:55 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Table model and config operators in ForCES rev. 2 Comments: cc: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable In most cases (more than 95%) all you need is (1) below...i.e. operations on single or multiple row entries in a table...very rarely will we need 2 or 3. Even if 2 and 3 are needed, they can easily be accomplished using 1.=20 I hope we don't have to over design the protocol to support the uncommon case, regards Hormuzd -----Original Message----- On Fri, 2004-10-08 at 09:30, Jamal Hadi Salim wrote: > I just realized something else: > With separation of index into a separate clause, it means table > operations are restricted to row operations. As opposed to what? (1) Multi-entry operations (multiple rows) Or... (2) Operation in a single field of a table entry (row) when the table entry is a struct? Or... (3) Operating on a subset of fields (more than one field, but not the whole struct) in a struct-type table entry? From owner-forces@PEACH.EASE.LSOFT.COM Tue Oct 12 11:35:48 2004 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 LAA01678 for ; Tue, 12 Oct 2004 11:35:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOrY-0007tK-Gz for forces-archive@IETF.ORG; Tue, 12 Oct 2004 11:46:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EABE7E@cherry.ease.lsoft.com>; Tue, 12 Oct 2004 11:35:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39624536 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 12 Oct 2004 11:35:41 -0400 Approved-By: alan.dekok@IDT.COM Received: from 66.46.215.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Oct 2004 11:22:51 -0400 Received: from [127.0.0.1] (dhcp195.ott.idt.com [192.168.102.195]) by post.ott.idt.com (Postfix) with ESMTP id 6CF2D1F0003; Tue, 12 Oct 2004 11:22:50 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> <468F3FDA28AA87429AD807992E22D07E02CEBCCC@orsmsx408> <5.1.0.14.0.20041008093846.023fe008@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <416BF607.5030603@idt.com> Date: Tue, 12 Oct 2004 11:19:35 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Table model and config operators in ForCES rev. 2 Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20041008093846.023fe008@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > We need to be able to reference > lfb_instance: faa (a top level element > lfb_instance: t[1] (a table entry) > lfb_instance: t[2].foo (a structure element in a table entry) > lfb_instance: t[3].u[2].bar > > I prefer to do this by including the indices in line with the element > selection. This seems to work naturally with uint32 indexes. That is reasonable. > It does not bother me if content selection can not be used this way. I think this was discussed earlier. Content selection should be done ONLY on the leaves of the tree referencing element(s). The alternative is to be able to express things like "arrays looking like FOO, with elements looking like BAR, with sub-elements looking like BAZ". There may be many entries returned. And not all of them may be of the same type. e.g. "find elements containing IP address 1.2.3.4". There may be routing table and ACL table entries which match that request. Restricting addressing to known structures and indexes ensures that the returned results are managable, and knowable. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Oct 21 19:32:05 2004 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 TAA29379 for ; Thu, 21 Oct 2004 19:32:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmcO-0001sc-Kf for forces-archive@IETF.ORG; Thu, 21 Oct 2004 19:45:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EBA9D7@cherry.ease.lsoft.com>; Thu, 21 Oct 2004 19:32:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41062552 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Oct 2004 19:32:05 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 21 Oct 2004 19:31:19 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LNZ9iv007072; Thu, 21 Oct 2004 23:35:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LNYfxa018838; Thu, 21 Oct 2004 23:34:55 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102116310916134 ; Thu, 21 Oct 2004 16:31:09 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 16:31:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Call for Agenda Items, ForCES WG Meeting, IETF 61 Thread-Index: AcS3xgpj952fW/chQxu7NKn1tLhSRQ== X-OriginalArrivalTime: 21 Oct 2004 23:31:09.0150 (UTC) FILETIME=[0B237FE0:01C4B7C6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Thu, 21 Oct 2004 16:31:07 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Call for Agenda Items, ForCES WG Meeting, IETF 61 Comments: cc: Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable All, The ForCES working group is scheduled to meet from 1300-1500 on Monday, November 8th at IETF 61. This is a call for agenda items for the meeting. Please send agenda requests to myself (david.putzolu@intel.com) and my co-chair (dro@zurich.ibm.com) with the following information: Title of presentation: Presenter: Time requested: Associated drafts:=20 Presentation file: (may be provided at meeting) The deadline for agenda time requests is Monday, November 1 at 11:00 ET. -David From owner-forces@PEACH.EASE.LSOFT.COM Fri Oct 22 12:37:03 2004 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 MAA18909 for ; Fri, 22 Oct 2004 12:37:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2cQ-0001p0-2D for forces-archive@IETF.ORG; Fri, 22 Oct 2004 12:50:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00EBB872@cherry.ease.lsoft.com>; Fri, 22 Oct 2004 12:36:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41181832 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 22 Oct 2004 12:36:56 -0400 Approved-By: alex.audu@ALCATEL.COM Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 22 Oct 2004 12:30:20 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i9MGUJ2Q022780 for ; Fri, 22 Oct 2004 11:30:19 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41793599.ABEA175A@alcatel.com> Date: Fri, 22 Oct 2004 11:30:18 -0500 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: draft-audu-forces-iptml-00 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Hello, I have uploaded an initial proposal (draft-audu-forces-iptml-00.txt) for IP-TML to the IETF draft editor. Meanwhile, you can get a copy from: http://www.sstanamera.com/~forces/Drafts/draft-audu-forces-iptml-00.txt Thanks, Alex. From owner-forces@PEACH.EASE.LSOFT.COM Wed Oct 27 13:57:33 2004 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 NAA27244 for ; Wed, 27 Oct 2004 13:57:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMsH2-00032G-Km for forces-archive@IETF.ORG; Wed, 27 Oct 2004 14:11:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00EC3A47@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 13:57:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42029275 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 13:57:24 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 13:55:17 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9RHsunx007432 for ; Wed, 27 Oct 2004 17:54:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9RHvnIQ024416 for ; Wed, 27 Oct 2004 17:59:00 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102710551004805 for ; Wed, 27 Oct 2004 10:55:10 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 10:55:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Call for ForCES Agenda Items and Draft Agenda, IETF 61 Thread-Index: AcS8ThmUJrvHh8ozTOW0zXyn7ZrJig== X-OriginalArrivalTime: 27 Oct 2004 17:55:10.0336 (UTC) FILETIME=[1A071800:01C4BC4E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Wed, 27 Oct 2004 10:55:09 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Call for ForCES Agenda Items and Draft Agenda, IETF 61 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable All, The ForCES working group is scheduled to meet from 1300-1500 on Monday, November 8th at IETF 61. This is a second call for agenda items for the meeting. Please send agenda requests to myself (david.putzolu@intel.com) and my co-chair (dro@zurich.ibm.com) with the following information: Title of presentation: Presenter: Time requested: Associated drafts:=20 Presentation file: (may be provided at meeting) The deadline for agenda time requests is Monday, November 1 at 11:00 ET. -David --- agenda --- Forwarding and Control Element Separation (ForCES)=20 Agenda, IETF 61 Monday, November 8, 2004, 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner =20 DRAFT AGENDA: 10 min - WG status & Agenda Bash - chairs 15 min - IP TML Proposal - Alex Audu draft-audu-forces-iptml-00.txt (Updated October 22, 2004)