From owner-forces@PEACH.EASE.LSOFT.COM Sun May 2 14:23:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24911 for ; Sun, 2 May 2004 14:23:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLcR-0004sY-39 for forces-archive@ietf.org; Sun, 02 May 2004 14:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLbY-0004e5-00 for forces-archive@ietf.org; Sun, 02 May 2004 14:22:21 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BKLb9-0004OU-00 for forces-archive@IETF.ORG; Sun, 02 May 2004 14:21:55 -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 <15.00D938F6@cherry.ease.lsoft.com>; 2 May 2004 14:21:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14610777 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 2 May 2004 14:21:48 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 2 May 2004 14:21:01 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050211244229:3951 ; Sun, 2 May 2004 11:24:42 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> 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 05/02/2004 11:24:43 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2004 11:24:52 AM, Serialize complete at 05/02/2004 11:24:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083522049.1683.257.camel@jzny.localdomain> Date: Sun, 2 May 2004 14:20:49 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040429100859.0222b6f8@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-04-29 at 10:24, Joel M. Halpern wrote: > Let me try to separate issues a little. > > One aspect is how does an LFB class definition describe the decision > process (and parameters) used by an instance of that class to choose which > output to send a packet to. The current approach envisioned (and probably > not well described) in the model is taht the processing logic of an LFB > Class is described informally. We are not expecting to define a > pseudo-language for LFB processing logic. Rather we expect to use english > descriptions. This does imply that the writers of CEs will need to build > into the CE understanding of the relevant behavior of any LFB class it > needs to work with. We are not providing any noticeable assistance for the > CE understanding teh semantics of an LFB class. Yes, but to have sensible english or any other natural language, you need to remove ambiguities or be all encompassing. I used the pseudo-C to make such a point. I also happen to know that many people follow model documents in their implementations almost as if they were design documents ready to be whipped into code. > The textual description for an LFB class might say that the LFB validates > the IP header, and anything that fails the check is sent to the error > output singleton. Anything that passes the check has its meta-data > examined and branches by examining a dispatch table indexed by the > "service-class" meta-data element and giving the output index in the > normal-output port group. The example i gave shows the result of the processing making the call on the path taken. I indicated that consulting "arriving" metadata is part of the processing phase. You seem to be indicating the metadata, probably encoded in a previous LFB instance, is used to make post-processing path decision. I think we are saying the same thing from a mile view, the granularity may be different. To me its like you have two LFBs in one. I still dont see why you need a "port output group" with this example. Its almost like i view your port group as something which is a next stage LFB (relative to one being described). And even then probably the last LFB in a chain. Its main task being that faced with multiple output choices, of probably physical interfaces or channels, it has to make a decision which one of those to send to based on metadata it received on input (not output). I would call such a thing a output selector/muxer/demuxer/redirector LFB. While making sense in the context of an LFB topology doesnt always when enforced within a LFB instance. > Another LFB class definition might indicate that the LFB examines only the > MAC protocol, and sends packets to the IS-IS, IPv4, IPv6, MPLS, and error > outputs. One of those outputs only, correct? This is a better example for a group definition, but i feel still stretching it. you mention the error output a few times now; and thats the only other branch that seems to be standing out in the generic case, everything else fits in one group; in other words, I think that all LFBs will have an error/exception output, but semantic sugar for what that path means applies only to that class of LFB. i.e I see it as default path - which makes sense for what that specific LFB does. Same sample space: Its no different in my opinion than having a routes with a default gateway; or firewall policies with a default accept/drop rule. Are you saying the exception path is so common that you needed to define it? > (You might prefer a table driven LFB, but that is a different > debate.) For this later class, the CE gives orders connecting the > different outputs to the kinds of processing specific to that packet > type. There is much less of an issue with consistency between the logic of > the LFB instance, the connectivity created by the LFB, and the programming > provided by the human & policy machinery. i think the above was a good example, but still falls short on justification. > What we are trying to do is make it easier for the CE, FE, and human to > understand the semantics of the interfaces to the LFB class. If we only > allowed one variable-count port group in an LFB class definition, then the > naming of Singleton ports and output groups could be looked at as simply an > aliasing for the 1..n outputs of the LFB class. Such aliasing makes > understanding easier. How many groups of these outputs do you see? I only see one + the default path which i am willing to say is a separate group. You seem to be saying theres more. > When we started down taht path, we noticed that in some circumstances more > than one semantic classes might have a variable number of outputs. For > that case, named port groups is actually noticeably more flexible than just > aliasing the ports. the naming part i agree with absolutely; the grouping is something i am tagging along with just to settle this. The main challenge was whether the decision to select a path was somehow assumed in your english description. Now i am finding myself even questioning the grouping. > To elaborate, if I have OG1 which can have up to 10 > outputs and OG2 which can have up to 10 outputs, but the LFB can have only > 10 total outputs, there is no way to assign OG1 and OG2 as aliases against > ports 1-10 such that I can grow OG1 or OG2 as I need to as services are > added to the instance. With the port groups I can easily describe what I > am doing. I can achieve the same affect by just explicitly managing the > direct outputs, and keeping track of how I am using each 1 (a careful > examination of the configuration tables would probably allow a human to > determine which ports are being treated with semantic 1 and which ports are > being treated with semantic 2.) > > Now, I will readily admit that most cases I can craft right now that use > two variable output groups can easily be done with two cascaded > branchers. And may be better done that way. But I am reluctant to declare > that there can only be one variable sized output group just because I have > insufficient foresight. I may be halfway to understanding you then. In which case, the draft may be a little lean on describing things. Like i said earlier, in my analysis i dont see much more than one group and within a group infact a default branch if the LFB semantic needed such a branch. Like you i am not gonna claim sufficient foresight to say this will cover everything. I am also finding myself now struggling to justify the port groups. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon May 3 14:59:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20513 for ; Mon, 3 May 2004 14:59:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKifO-0006Xd-3W for forces-archive@ietf.org; Mon, 03 May 2004 14:59:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKieS-0006Qd-00 for forces-archive@ietf.org; Mon, 03 May 2004 14:58:53 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BKidV-0006Ja-00 for forces-archive@IETF.ORG; Mon, 03 May 2004 14:57:53 -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 <10.00D95462@cherry.ease.lsoft.com>; Mon, 3 May 2004 14:57:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14799105 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 May 2004 14:57:50 -0400 Approved-By: alan.dekok@IDT.COM Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 May 2004 14:39:41 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id CC0C01F0159; Mon, 3 May 2004 14:39:39 -0400 (EDT) Received: from idt.com (dhcp194.ott.idt.com [192.168.102.194]) by post.ott.idt.com (Postfix) with ESMTP id 163611F040D; Mon, 3 May 2004 14:36:48 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <409690FC.1000904@idt.com> Date: Mon, 3 May 2004 14:35:40 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083522049.1683.257.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > > The example i gave shows the result of the processing making the call on > the path taken. I indicated that consulting "arriving" metadata is part > of the processing phase. You seem to be indicating the metadata, > probably encoded in a previous LFB instance, is used to make > post-processing path decision. I think we are saying the same thing from > a mile view, the granularity may be different. To me its like you have > two LFBs in one. Almost. The issue is one which has been debated within the ForCES model group. If we have permit only the "redirector" LFB to redirect an input to one or more of N outputs, then many, many, other LFB's will almost always be followed by a redirector. Further, the XML descriptions of the LFB's become more complex, as the redirector now has properties (multiple outputs) which no other LFB shares. By placing some redirection ability within each LFB, the schema becomes more consistent, and many models of implementations become more obvious to the implementors. So in this case, an "IP validation LFB" can have two outputs: good packets, and bad packets. The benefit of having two outputs here is that the "metadata" which chooses between the two outputs is internal to the LFB. If we were to require a redirector to make this decision, that metadata MUST be external to the LFB, which means that the ForCES model needs to describe it. By keeping it in the LFB, it becomes "implementation defined". So long as the external behavior is consistent across implementations, it doesn't matter how that metadata is represented. These concepts should be clarified in the model draft. > I still dont see why you need a "port output group" with this example. > Its almost like i view your port group as something which is a next > stage LFB (relative to one being described). And even then probably the > last LFB in a chain. Its main task being that faced with multiple output > choices, of probably physical interfaces or channels, it has to make a > decision which one of those to send to based on metadata it received on > input (not output). I would call such a thing a output > selector/muxer/demuxer/redirector LFB. While making sense in the context > of an LFB topology doesnt always when enforced within a LFB instance. I understand, and I generally agree with you. It may make sense for the model document to describe these issues, and to explain via diagrams and examples how the current choice is imperfect, but solves some problems that would otherwise be awkward. > I may be halfway to understanding you then. In which case, the draft may > be a little lean on describing things. Like i said earlier, in my > analysis i dont see much more than one group and within a group infact a > default branch if the LFB semantic needed such a branch. Like you i am > not gonna claim sufficient foresight to say this will cover everything. > I am also finding myself now struggling to justify the port groups. They hide implementation choices which would otherwise have to be included explicitly in the model. By hiding them in the LFB's, we can simplify both the model, and the implementation. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Mon May 3 23:10:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18747 for ; Mon, 3 May 2004 23:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqKh-000336-SA for forces-archive@ietf.org; Mon, 03 May 2004 23:10:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqIX-0002qD-00 for forces-archive@ietf.org; Mon, 03 May 2004 23:08:46 -0400 Received: from vms.dc.lsoft.com ([209.119.1.27]) by ietf-mx with esmtp (Exim 4.12) id 1BKqG7-0002b9-00 for forces-archive@IETF.ORG; Mon, 03 May 2004 23:06:15 -0400 Received: from vms.dc.lsoft.com (127.0.0.1) by VMS.DC.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <13.0036DCCD@VMS.DC.LSOFT.COM>; Mon, 3 May 2004 23:06:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14840661 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 3 May 2004 23:01:30 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 May 2004 22:39:42 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050319433055:5389 ; Mon, 3 May 2004 19:43:30 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> 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 05/03/2004 07:43:31 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2004 07:43:33 PM, Serialize complete at 05/03/2004 07:43:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083638378.1039.63.camel@jzny.localdomain> Date: Mon, 3 May 2004 22:39:39 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <409690FC.1000904@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-05-03 at 14:35, Alan DeKok wrote: > > To me its like you have > > two LFBs in one. > > Almost. The issue is one which has been debated within the ForCES > model group. If we have permit only the "redirector" LFB to redirect an > input to one or more of N outputs, then many, many, other LFB's will > almost always be followed by a redirector. It is true there will be one of n outputs that an LFB instance will end up going to. Why you need a redirector for each case, i dont fully see. Ok, maybe the root issue is this "redirector" thing. I see the task of a redirector to be infact a stealer of packets. It takes a packet and redirects it to some hole - be it a port/channel/software device etc. Essentially, the topology of LFBs terminates once it hits a redirector at least in the local scope of its execution path. If you were to look at it the way i just described it, then a redirector is not needed for each LFB. It does seem like the model draft also defines a redirector as something that interconnets LFB instances. A better name for something like this is a "brancher". No pun intended. > Further, the XML > descriptions of the LFB's become more complex, as the redirector now has > properties (multiple outputs) which no other LFB shares. The XML thing is new - is having a output port group useful to the XML definition or makes it easier to describe? > By placing some redirection ability within each LFB, the schema > becomes more consistent, and many models of implementations become more > obvious to the implementors. So in this case, an "IP validation LFB" > can have two outputs: good packets, and bad packets. Again i have no problem with the two outputs or n outputs for that matter. > The benefit of having two outputs here is that the "metadata" which > chooses between the two outputs is internal to the LFB. If we were to > require a redirector to make this decision, that metadata MUST be > external to the LFB, which means that the ForCES model needs to describe > it. By keeping it in the LFB, it becomes "implementation defined". So > long as the external behavior is consistent across implementations, it > doesn't matter how that metadata is represented. In my view i see the folowing as the internal path: - packet comes into LFB instance - process packet by probably consulting metadata if need to. - select output based on processing result. you seem to say (and i have heard Joe say this as well i think): - packet comes into LFB instance - process packet - consult metadata to select output. Could this be another of deviating view points? [..] cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue May 4 11:44:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09187 for ; Tue, 4 May 2004 11:44:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL25y-0004Ty-Rf for forces-archive@ietf.org; Tue, 04 May 2004 11:44:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL250-0004Qm-00 for forces-archive@ietf.org; Tue, 04 May 2004 11:43:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BL242-0004Lv-00 for forces-archive@IETF.ORG; Tue, 04 May 2004 11:42:34 -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 <7.00D96AE8@cherry.ease.lsoft.com>; Tue, 4 May 2004 11:11:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 14946346 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 May 2004 11:11:16 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 May 2004 07:48:08 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6900831; Tue, 04 May 2004 07:48:07 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <409690FC.1000904@idt.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040504074504.02234b68@localhost> Date: Tue, 4 May 2004 07:47:48 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083638378.1039.63.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In my view, both of those are internal operations of the LFB. If an LFB is going to select an output based on its input meta-data (or select an output and attach an associated meta-data, or attach meta-data and send the p[acket to the associated output, or any order you like) that is internal processing of the LFB and needs to be described clearly in the LFB description. If, and only if, the situation is modelled as two LFBs, (one which generates the meta-data and passes the packet with the meta-data to a second LFB which uses the meta-data to select the output) then you have different processing. That is why Alan (I think), and I, view that second as more complex. Yours, Joel M. Halpern At 10:39 PM 5/3/2004 -0400, Jamal Hadi Salim wrote: >In my view i see the folowing as the internal path: >- packet comes into LFB instance >- process packet by probably consulting metadata if need to. >- select output based on processing result. > >you seem to say (and i have heard Joe say this as well i think): >- packet comes into LFB instance >- process packet >- consult metadata to select output. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 09:50:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13306 for ; Wed, 5 May 2004 09:50:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLMnG-0006No-5n for forces-archive@ietf.org; Wed, 05 May 2004 09:50:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMmG-00068v-00 for forces-archive@ietf.org; Wed, 05 May 2004 09:49:37 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLMlK-0005u7-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 09:48:38 -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 <19.00D987DE@cherry.ease.lsoft.com>; Wed, 5 May 2004 9:48:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15115707 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 09:48:36 -0400 Approved-By: alan.dekok@IDT.COM Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 May 2004 15:41:04 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 4B6D71F0251 for ; Tue, 4 May 2004 15:41:04 -0400 (EDT) Received: from idt.com (dhcp194.ott.idt.com [192.168.102.194]) by post.ott.idt.com (Postfix) with ESMTP id 9F4161F00F7 for ; Tue, 4 May 2004 15:36:22 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4097F072.3050409@idt.com> Date: Tue, 4 May 2004 15:35:14 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083638378.1039.63.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > It is true there will be one of n outputs that an LFB instance will end > up going to. Why you need a redirector for each case, i dont fully see. It depends on the conceptual model you use. If you split the LFB's by function, then an LFB which decides "IP packet good/bad" can a) mark the packet good/bad, and let a later LFB redirect the bad packets b) do the redirection itself. > Ok, maybe the root issue is this "redirector" thing. I see the task of a > redirector to be infact a stealer of packets. It takes a packet and > redirects it to some hole - be it a port/channel/software device etc. Exactly. > Essentially, the topology of LFBs terminates once it hits a redirector > at least in the local scope of its execution path. I'm not sure why. The topology of an IP network includes bridges and switches. A redirector is just another name for a bridge/switch, but in the context of LFB's. > The XML thing is new - is having a output port group useful to the XML > definition or makes it easier to describe? Someone else would have to answer that. > In my view i see the folowing as the internal path: > - packet comes into LFB instance > - process packet by probably consulting metadata if need to. > - select output based on processing result. I understand. But other models are possible. > you seem to say (and i have heard Joe say this as well i think): > - packet comes into LFB instance > - process packet > - consult metadata to select output. > > Could this be another of deviating view points? It's terminology. In the first example, you say "select output based on processing result". That processing result *is* metadata. There is a physical wire, or bit on a wire, which holds that result. That "result" data is separate from the packet data, and independent of it. Therefore, that "result" data is metadata. So to re-phrase your examples: - packet comes into LFB instance - process packet, and come to conclusion X - use X to select output That "X" is metadata. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 10:14:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14992 for ; Wed, 5 May 2004 10:14:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLN9v-0003t8-Fk for forces-archive@ietf.org; Wed, 05 May 2004 10:14:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN8v-0003ZC-00 for forces-archive@ietf.org; Wed, 05 May 2004 10:13:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7Y-00031T-03 for forces-archive@IETF.ORG; Wed, 05 May 2004 10:11:36 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLMsr-00039l-MD for forces-archive@IETF.ORG; Wed, 05 May 2004 09:56:25 -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 <9.00D98864@cherry.ease.lsoft.com>; Wed, 5 May 2004 9:56:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15116215 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 09:56:21 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 09:39:51 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i45Ddkn5136282; Wed, 5 May 2004 13:39:46 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i45DdjVH217328; Wed, 5 May 2004 15:39:45 +0200 Received: from zurich.ibm.com (dhcp69-238.zurich.ibm.com [9.4.69.238]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA46588; Wed, 5 May 2004 15:39:44 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id i45Ddkn5136282 Message-ID: <4098EEA0.4000404@zurich.ibm.com> Date: Wed, 5 May 2004 15:39:44 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <409690FC.1000904@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Alan, I assume the notion of "duplicator" is included in the model. Correct me=20 if I am wrong: can there be more than one simultaneous outputs as a=20 result of an LFB processing ? Take for example a non-intrusive=20 packet-capturing application that wants to redirect copies of packets=20 for analysis at the CE, while leaving the stream of packets untouched. Regards, -Robert Alan DeKok wrote: > Jamal Hadi Salim wrote: > >> >> The example i gave shows the result of the processing making the call = on >> the path taken. I indicated that consulting "arriving" metadata is par= t >> of the processing phase. You seem to be indicating the metadata, >> probably encoded in a previous LFB instance, is used to make >> post-processing path decision. I think we are saying the same thing fr= om >> a mile view, the granularity may be different. To me its like you have >> two LFBs in one. > > > Almost. The issue is one which has been debated within the ForCES > model group. If we have permit only the "redirector" LFB to redirect a= n > input to one or more of N outputs, then many, many, other LFB's will > almost always be followed by a redirector. Further, the XML > descriptions of the LFB's become more complex, as the redirector now ha= s > properties (multiple outputs) which no other LFB shares. > > By placing some redirection ability within each LFB, the schema > becomes more consistent, and many models of implementations become more > obvious to the implementors. So in this case, an "IP validation LFB" > can have two outputs: good packets, and bad packets. > > The benefit of having two outputs here is that the "metadata" which > chooses between the two outputs is internal to the LFB. If we were to > require a redirector to make this decision, that metadata MUST be > external to the LFB, which means that the ForCES model needs to describ= e > it. By keeping it in the LFB, it becomes "implementation defined". So > long as the external behavior is consistent across implementations, it > doesn't matter how that metadata is represented. > > These concepts should be clarified in the model draft. > >> I still dont see why you need a "port output group" with this example. >> Its almost like i view your port group as something which is a next >> stage LFB (relative to one being described). And even then probably th= e >> last LFB in a chain. Its main task being that faced with multiple outp= ut >> choices, of probably physical interfaces or channels, it has to make a >> decision which one of those to send to based on metadata it received o= n >> input (not output). I would call such a thing a output >> selector/muxer/demuxer/redirector LFB. While making sense in the conte= xt >> of an LFB topology doesnt always when enforced within a LFB instance. > > > I understand, and I generally agree with you. It may make sense for > the model document to describe these issues, and to explain via diagram= s > and examples how the current choice is imperfect, but solves some > problems that would otherwise be awkward. > >> I may be halfway to understanding you then. In which case, the draft m= ay >> be a little lean on describing things. Like i said earlier, in my >> analysis i dont see much more than one group and within a group infact= a >> default branch if the LFB semantic needed such a branch. Like you i am >> not gonna claim sufficient foresight to say this will cover everything. >> I am also finding myself now struggling to justify the port groups. > > > They hide implementation choices which would otherwise have to be > included explicitly in the model. By hiding them in the LFB's, we can > simplify both the model, and the implementation. > > Alan DeKok. > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 10:42:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16992 for ; Wed, 5 May 2004 10:42:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNbf-00037q-Cg for forces-archive@ietf.org; Wed, 05 May 2004 10:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNag-0002s1-00 for forces-archive@ietf.org; Wed, 05 May 2004 10:41:43 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLNZn-0002cW-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 10:40:47 -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 <15.00D98AE0@cherry.ease.lsoft.com>; Wed, 5 May 2004 10:40:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15123021 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 10:40:41 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 10:32:43 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6923192; Wed, 05 May 2004 10:32:42 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <409690FC.1000904@idt.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <5.1.0.14.0.20040505103128.023b83c0@localhost> Date: Wed, 5 May 2004 10:32:22 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4098EEA0.4000404@zurich.ibm.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Although we have not defined such an LFB class yet, it is certainly=20 permissible (and necessary for certain cases) to do so. Any one packet can only go one place, but an LFB can create as many packets= =20 as it needs to in order to do its job. Yours, Joel At 03:39 PM 5/5/2004 +0200, Robert Haas wrote: >Alan, >I assume the notion of "duplicator" is included in the model. Correct me=20 >if I am wrong: can there be more than one simultaneous outputs as a result= =20 >of an LFB processing ? Take for example a non-intrusive packet-capturing=20 >application that wants to redirect copies of packets for analysis at the=20 >CE, while leaving the stream of packets untouched. > >Regards, >-Robert > >Alan DeKok wrote: > >>Jamal Hadi Salim wrote: >> >>> >>>The example i gave shows the result of the processing making the call on >>>the path taken. I indicated that consulting "arriving" metadata is part >>>of the processing phase. You seem to be indicating the metadata, >>>probably encoded in a previous LFB instance, is used to make >>>post-processing path decision. I think we are saying the same thing from >>>a mile view, the granularity may be different. To me its like you have >>>two LFBs in one. >> >> >> Almost. The issue is one which has been debated within the ForCES >>model group. If we have permit only the "redirector" LFB to redirect an >>input to one or more of N outputs, then many, many, other LFB's will >>almost always be followed by a redirector. Further, the XML >>descriptions of the LFB's become more complex, as the redirector now has >>properties (multiple outputs) which no other LFB shares. >> >> By placing some redirection ability within each LFB, the schema >>becomes more consistent, and many models of implementations become more >>obvious to the implementors. So in this case, an "IP validation LFB" >>can have two outputs: good packets, and bad packets. >> >> The benefit of having two outputs here is that the "metadata" which >>chooses between the two outputs is internal to the LFB. If we were to >>require a redirector to make this decision, that metadata MUST be >>external to the LFB, which means that the ForCES model needs to describe >>it. By keeping it in the LFB, it becomes "implementation defined". So >>long as the external behavior is consistent across implementations, it >>doesn't matter how that metadata is represented. >> >> These concepts should be clarified in the model draft. >> >>>I still dont see why you need a "port output group" with this example. >>>Its almost like i view your port group as something which is a next >>>stage LFB (relative to one being described). And even then probably the >>>last LFB in a chain. Its main task being that faced with multiple output >>>choices, of probably physical interfaces or channels, it has to make a >>>decision which one of those to send to based on metadata it received on >>>input (not output). I would call such a thing a output >>>selector/muxer/demuxer/redirector LFB. While making sense in the context >>>of an LFB topology doesnt always when enforced within a LFB instance. >> >> >> I understand, and I generally agree with you. It may make sense for >>the model document to describe these issues, and to explain via diagrams >>and examples how the current choice is imperfect, but solves some >>problems that would otherwise be awkward. >> >>>I may be halfway to understanding you then. In which case, the draft may >>>be a little lean on describing things. Like i said earlier, in my >>>analysis i dont see much more than one group and within a group infact a >>>default branch if the LFB semantic needed such a branch. Like you i am >>>not gonna claim sufficient foresight to say this will cover everything. >>>I am also finding myself now struggling to justify the port groups. >> >> >> They hide implementation choices which would otherwise have to be >>included explicitly in the model. By hiding them in the LFB's, we can >>simplify both the model, and the implementation. >> >> Alan DeKok. >> > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 10:43:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17077 for ; Wed, 5 May 2004 10:43:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNcX-0003NQ-Pe for forces-archive@ietf.org; Wed, 05 May 2004 10:43:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNbX-00036m-00 for forces-archive@ietf.org; Wed, 05 May 2004 10:42:36 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLNaW-0002l7-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 10:41:32 -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.00D98A5E@cherry.ease.lsoft.com>; Wed, 5 May 2004 10:41:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15123219 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 10:41:32 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 10:40:19 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050507440555:7256 ; Wed, 5 May 2004 07:44:05 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> 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 05/05/2004 07:44:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:44:08 AM, Serialize complete at 05/05/2004 07:44:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083768015.1022.136.camel@jzny.localdomain> Date: Wed, 5 May 2004 10:40:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4097F072.3050409@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Tue, 2004-05-04 at 15:35, Alan DeKok wrote: > Jamal Hadi Salim wrote: > > > It is true there will be one of n outputs that an LFB instance will end > > up going to. Why you need a redirector for each case, i dont fully see. > > It depends on the conceptual model you use. If you split the LFB's > by function, then an LFB which decides "IP packet good/bad" can > > a) mark the packet good/bad, and let a later LFB redirect the bad packets > b) do the redirection itself. I dont have a problem with the multiple branches out of an LFB instance. Of course you can be as granular as you want and have it with two LFBs for the above. > > Ok, maybe the root issue is this "redirector" thing. I see the task of a > > redirector to be infact a stealer of packets. It takes a packet and > > redirects it to some hole - be it a port/channel/software device etc. > > Exactly. So lets settle this, since it is one of two issues i raised. Lets see where a redirector is typically used in common literature: - port redirector on Servers/firewalls --> used to imply a packet destined to a TCP/UDP/SCTP port X gets sent to another port instead. The redirection is the termination of that transaction on the local scope at least. - Port redirection on a lot of ethernet switches --> A packet coming on physical port X gets redirected to physical port Y based on some match. This may sound picky, but certainly redirectors you have in mind dont fit the above. So to settle this maybe you shoulc change the name to something like "selector" or "Muxer" or even "demuxer". Call an LFB a redirector if it terminates the topology. > > Essentially, the topology of LFBs terminates once it hits a redirector > > at least in the local scope of its execution path. > > I'm not sure why. The topology of an IP network includes bridges and > switches. A redirector is just another name for a bridge/switch, but in > the context of LFB's. Sure -- if you think of the LFB topology as spanning across multiple FEs. In that scenario, you can draw the whole network as a connection of LFBs. You could go as far as seeing a router/swicth etc as an LFB (how granualar do you wanna be?). Note, i would have zero problem with that approach; however, I think we did say we only wanna focus at the local scope of a single FE. > > The XML thing is new - is having a output port group useful to the XML > > definition or makes it easier to describe? > > Someone else would have to answer that. I am curious and willing to consider if i can see the justification for it as reasonable. > > In my view i see the folowing as the internal path: > > - packet comes into LFB instance > > - process packet by probably consulting metadata if need to. > > - select output based on processing result. > > I understand. But other models are possible. Absolutely. I dont wanna have one view though being the only one represented by the model. > > you seem to say (and i have heard Joe say this as well i think): > > - packet comes into LFB instance > > - process packet > > - consult metadata to select output. > > > > Could this be another of deviating view points? > > It's terminology. > > In the first example, you say "select output based on processing > result". That processing result *is* metadata. There is a physical > wire, or bit on a wire, which holds that result. That "result" data is > separate from the packet data, and independent of it. Therefore, that > "result" data is metadata. > > So to re-phrase your examples: > > - packet comes into LFB instance > - process packet, and come to conclusion X > - use X to select output > > That "X" is metadata. Ok, it is probably just semantics, let me clarify my view: * the result of internal processing is NOT metadata. Metadata MAY be produced as a side-effect of processing. The result of processing is a decision. Metadata is what gets carried around with the packet. Such metadata may be used/consulted/consumed in processing the packet; however, the processing is NOT dependent on receiving any metadata. In other words, using metadata in processing is LFB specific. Some LFBs will process just based on metadata others will never look at it even if it existed. The processing itself MAY create metadata which gets carried on the packet (or stashed in some shared memory) to be used by the next LFB or by the third LFB instance down the topology. The decision to go out which branch is NOT dependent on such created metadata rather it is dependent on the result/decision of the processing. Now, to my second contention point: Do you see more than two groups of outputs? To use the grouping scheme i only see two groups: - the general path (upto n outputs) - the exception path I know you are trying to be generic and say if i can have two groups then i can have X more. On the other extreme i see the two as one group really, i dont see why you need to have the exception/error as separate. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 10:53:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17722 for ; Wed, 5 May 2004 10:53:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNmZ-0006C1-DW for forces-archive@ietf.org; Wed, 05 May 2004 10:53:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNld-0005t7-00 for forces-archive@ietf.org; Wed, 05 May 2004 10:53:02 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLNke-0005aH-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 10:52:01 -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.00D98A06@cherry.ease.lsoft.com>; Wed, 5 May 2004 10:51:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15124039 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 10:51:56 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 10:51:25 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050507550658:7277 ; Wed, 5 May 2004 07:55:06 -0700 References: <409690FC.1000904@idt.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <5.1.0.14.0.20040505103128.023b83c0@localhost> 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 05/05/2004 07:55:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:55:14 AM, Serialize complete at 05/05/2004 07:55:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083768671.1022.156.camel@jzny.localdomain> Date: Wed, 5 May 2004 10:51:11 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Revised LFB input/output text Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040505103128.023b83c0@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 10:32, Joel M. Halpern wrote: > Although we have not defined such an LFB class yet, it is certainly > permissible (and necessary for certain cases) to do so. > Any one packet can only go one place, but an LFB can create as many packets > as it needs to in order to do its job. Actually, the mirror/duplicator LFB is an interesting contrast to the redirector LFB; using what i know of common literature usage, one steals packets(redirector) the other (nirror) just takes a copy of the packet possibly to a different topology and lets it go on its merry way. So how does the modelled topology look in your case for the two contrasts? I think it is a fundamental piece of the model. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 11:14:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20142 for ; Wed, 5 May 2004 11:14:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLO6h-0004nH-Md for forces-archive@ietf.org; Wed, 05 May 2004 11:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLO63-0004YG-00 for forces-archive@ietf.org; Wed, 05 May 2004 11:14:08 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLO5E-0004Hq-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 11:13: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 <6.00D98B4C@cherry.ease.lsoft.com>; Wed, 5 May 2004 11:13:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15126205 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 11:13:14 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 11:07:51 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6923351; Wed, 05 May 2004 11:07:50 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040505103128.023b83c0@localhost> <409690FC.1000904@idt.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <5.1.0.14.0.20040505103128.023b83c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040505110416.0224cb18@localhost> Date: Wed, 5 May 2004 11:07:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083768671.1022.156.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 From a topological point of view, the two are the same. They are each an LFB instance of an LFB class (two different classes). They each have one input, with meta-data tagging, and two outputs. One class is defined to use the meta-data to decide which of the two outputs to send the packet to. The other is defined to always send the packet on output 1, and sometimtes (depending upon the metadata) to make a copy of the packet, modify the meta-data and send the copy on output two. I would expect the outputs to have very different names in the two LFB class definitions. The first one might have outputs named IPv4 and IPv6, while the second might have outputs named normal and LEA. Connecting those outputs up properly is the job of the CE> Yours, Joel At 10:51 AM 5/5/2004 -0400, Jamal Hadi Salim wrote: >On Wed, 2004-05-05 at 10:32, Joel M. Halpern wrote: > > Although we have not defined such an LFB class yet, it is certainly > > permissible (and necessary for certain cases) to do so. > > Any one packet can only go one place, but an LFB can create as many > packets > > as it needs to in order to do its job. > >Actually, the mirror/duplicator LFB is an interesting contrast to the >redirector LFB; using what i know of common literature usage, one steals >packets(redirector) the other (nirror) just takes a copy of the packet >possibly to a different topology and lets it go on its merry way. >So how does the modelled topology look in your case for the two >contrasts? I think it is a fundamental piece of the model. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 11:26:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20789 for ; Wed, 5 May 2004 11:26:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOII-00003D-Au for forces-archive@ietf.org; Wed, 05 May 2004 11:26:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOHQ-0007aM-00 for forces-archive@ietf.org; Wed, 05 May 2004 11:25:53 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLOGU-0007KA-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 11:24:54 -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 <6.00D98B86@cherry.ease.lsoft.com>; Wed, 5 May 2004 11:24:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15127395 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 11:24:53 -0400 Approved-By: alan.dekok@IDT.COM Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 11:23:52 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id C72971F0166 for ; Wed, 5 May 2004 11:23:51 -0400 (EDT) Received: from idt.com (dhcp194.ott.idt.com [192.168.102.194]) by post.ott.idt.com (Postfix) with ESMTP id 826F31F0120 for ; Wed, 5 May 2004 11:23:51 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <409906C1.5060000@idt.com> Date: Wed, 5 May 2004 11:22:41 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083768015.1022.136.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > So lets settle this, since it is one of two issues i raised. Lets see > where a redirector is typically used in common literature: > - port redirector on Servers/firewalls --> used to imply a packet > destined to a TCP/UDP/SCTP port X gets sent to another port instead. The > redirection is the termination of that transaction on the local scope at > least. > - Port redirection on a lot of ethernet switches --> A packet coming on > physical port X gets redirected to physical port Y based on some match. > > This may sound picky, but certainly redirectors you have in mind dont > fit the above. I believe that they do. The one nit-pick is that you're group re-direction with session termination. Routers re-direct packets, and also update TTL/checksum, but no one pretends that updating TTL/checksum is related at all to redirection. > So to settle this maybe you shoulc change the name to > something like "selector" or "Muxer" or even "demuxer". Call an LFB a > redirector if it terminates the topology. The topology of the LFB's stops at an FE boundary. Within that context, redirectors are still useful. That is, an FE may be doing multiple things to packets. The ForCES model MUST include those multiple kinds of packet handling. e.g. A MAC bridge FE handles unicast and broadcast packets. Portions of the packet handling are the same, and other portions are different. So the "unicast packet handling" topology over-laps with the "broadcast packet handling" topology. However, both topologies are present in the same FE, and both are therefore represented in the LFB model. In this context, the re-director *is* used to terminate the "common packet handling" topology, and sends packets to the "uni/broad-cast packet handling" topology. So I understand your point. But since the topologies over-lap, the redirector is very useful. > Ok, it is probably just semantics, let me clarify my view: > * the result of internal processing is NOT metadata. Metadata MAY be > produced as a side-effect of processing. The result of processing is a > decision. Metadata is what gets carried around with the packet. This is the confusion I was trying to address in my "metadata vocabulary" draft. I'm updating the text, and will be adding it to the model document. The result of a decision IS meta-data. The result has physical presence somewhere in the LFB, or in the device implementing the LFB. In this context, the metadata is: a) internal to the LFB/device b) explicitly represented as some "result" of a decision process When the packet is sent out of the "IP validator" device, the device can do it in one of two ways: 1) Have one output, and attach the good/bad decision as metadata In this context, the metadata is: a) external to the device b) explicitly represented as bits on the wire, associated with the packet 2) have two outputs, for good/bad packets In this context, the metadata is: a) external to the device b) implicitly represented in the fact that bad packets are on the "bad" wire, and good packets are on the "good" wire. > The processing itself MAY create metadata which gets carried on the > packet (or stashed in some shared memory) to be used by the next LFB or > by the third LFB instance down the topology. In which case it's external to the LFB, and explicitly represented. > The decision to go out which branch is NOT dependent on such created > metadata rather it is dependent on the result/decision of the > processing. And that decision is metadata. Look at it as the LFB adding metadata to the packet internally, and then internally consuming that metadata when the branching decision is made. In all cases, the concept of the metadata is identical. The only difference is the scale at which you examine the metadata. e.g. Metadata which is explicitly represented in paths between LFB's or devices on an FE often never makes it out of the FE. Yet when you look at the router in which that FE sits, you can't realistically claim that the metadata doesn't exist. It does, just not at the current scale. > Now, to my second contention point: > Do you see more than two groups of outputs? To use the grouping scheme > i only see two groups: > - the general path (upto n outputs) > - the exception path > > I know you are trying to be generic and say if i can have two groups > then i can have X more. On the other extreme i see the two as one group > really, i dont see why you need to have the exception/error as separate. It's a good point. I'm not sure I have a clear answer for you there. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 11:52:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22289 for ; Wed, 5 May 2004 11:52:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOhO-0006rq-7Q for forces-archive@ietf.org; Wed, 05 May 2004 11:52:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOgS-0006b7-00 for forces-archive@ietf.org; Wed, 05 May 2004 11:51:44 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLOfY-0006Kk-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 11:50:48 -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 <7.00D98C34@cherry.ease.lsoft.com>; Wed, 5 May 2004 11:50:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15129944 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 11:50:46 -0400 Approved-By: alistair.munro@U4EATECH.COM Received: from 137.222.10.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 11:24:58 -0400 Received: from ncs.bris.ac.uk ([137.222.10.36]) by dirh.bris.ac.uk with esmtp (Exim 4.30) id 1BLOGW-0006vm-Ne; Wed, 05 May 2004 16:24:56 +0100 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by ncs.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id i45FMvW01213 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 5 May 2004 16:22:58 +0100 (BST) References: <1083768671.1022.156.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:01+1DAoWC1IRUzkTkLKWG27QozsjbEO23G7gM4ujnFKV5+NQw=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 Message-ID: <633040434.1083774177@EEN9169.een.bris.ac.uk> Date: Wed, 5 May 2004 16:22:57 +0100 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083768671.1022.156.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dear All, On the redirector and metadata/processing issues (Alan de Kok, Jamal's exchange), I think Alan's model is more general and precise and thus more acceptable to me at least. I didn't want to have a model that ruled out redirector/demux LFBs or aggregator/mux LFBs (selection based on metadata, no processing) and allowed only the mux/demux embedded in LFBs of greater functionality (selection based on internal processing results). The previous model appeared to allow only the latter, and this is not compatible with silicon that exists today. The current model text is better bar maybe some examples and text optimisations. Note: I take "processing" to mean a function that includes internal data or state supplied independently of the packet flow together with metadata. So just adding two metadatums (?) together isn't processing. Speaking as editor of the NPF FE model, where support of legacy silicon is essential, I believe this view is the consensus of the NPF members active in this area. But I'll have to let them speak for themselves. We might also be losing sight of the original issue (IMO), which was groups. No, I don't really understand them either, but I can live with them. The rules for using them seem clear enough to allow interoperability. >> Although we have not defined such an LFB class [duplicator] yet, it is certainly >> permissible (and necessary for certain cases) to do so. >> Any one packet can only go one place, but an LFB can create as many >> packets as it needs to in order to do its job. > > Actually, the mirror/duplicator LFB is an interesting contrast to the > redirector LFB; I think it is an unrelated function, not a contrast. Interesting nevertheless. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 12:12:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23056 for ; Wed, 5 May 2004 12:12:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLP0u-0004Bu-Qp for forces-archive@ietf.org; Wed, 05 May 2004 12:12:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOzp-0003wX-00 for forces-archive@ietf.org; Wed, 05 May 2004 12:11:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLOzR-0003hy-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 12:11:21 -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 <10.00D98D0D@cherry.ease.lsoft.com>; Wed, 5 May 2004 12:11:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15131481 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 12:11:20 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 12:09:18 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050509130542:7405 ; Wed, 5 May 2004 09:13:05 -0700 References: <1083768671.1022.156.camel@jzny.localdomain> <633040434.1083774177@EEN9169.een.bris.ac.uk> 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 05/05/2004 09:13:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 09:13:07 AM, Serialize complete at 05/05/2004 09:13:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083773355.1022.365.camel@jzny.localdomain> Date: Wed, 5 May 2004 12:09:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: output port groups WAS(Re: Revised LFB input/output text Comments: To: Alistair Munro To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <633040434.1083774177@EEN9169.een.bris.ac.uk> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Let me jump to this email because it puts us back on track - then i will revisit the other emails including this because they still have interesting discussion points. On Wed, 2004-05-05 at 11:22, Alistair Munro wrote: > We might also be losing sight of the original issue (IMO), which was > groups. No, I don't really understand them either, but I can live with > them. The rules for using them seem clear enough to allow interoperability. I can live with them as well. I see logically not more than two groups if you insist on grouping. Otherwise we need to explain why we need more. There was something about XML connotations needing it. Again, to reitarate my position i dont see why you need groups. The other contention point is the naming around "redirector". Both the above seem to me to be overzelous future-proofing design. Ok, there i said it. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 12:45:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25033 for ; Wed, 5 May 2004 12:45:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPWj-0005NL-9S for forces-archive@ietf.org; Wed, 05 May 2004 12:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPVk-00057M-00 for forces-archive@ietf.org; Wed, 05 May 2004 12:44:45 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLPUn-0004rl-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 12:43:45 -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 <9.00D98BD3@cherry.ease.lsoft.com>; Wed, 5 May 2004 12:42:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15134713 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 12:42:27 -0400 Approved-By: lily.l.yang@INTEL.COM Received: from 192.55.52.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 12:41:56 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by fmsfmr004.fm.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 i45Gg66p009024; Wed, 5 May 2004 16:42:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i45GfYJa015604; Wed, 5 May 2004 16:42:04 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 M2004050509411609712 ; Wed, 05 May 2004 09:41:16 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 09:41:16 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: output port groups WAS(Re: Revised LFB input/output text Thread-Index: AcQyu6agbAzo+osASsGzcqemxwXzTQAAYzWw X-OriginalArrivalTime: 05 May 2004 16:41:16.0256 (UTC) FILETIME=[C8D1EE00:01C432BF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDC1F@orsmsx408.jf.intel.com> Date: Wed, 5 May 2004 09:41:15 -0700 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable See below between [Yang, Lily L] and [/Yang, Lily L] -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, May 05, 2004 9:09 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: output port groups WAS(Re: Revised LFB input/output text Let me jump to this email because it puts us back on track - then i will revisit the other emails including this because they still have interesting discussion points. On Wed, 2004-05-05 at 11:22, Alistair Munro wrote: > We might also be losing sight of the original issue (IMO), which was > groups. No, I don't really understand them either, but I can live with > them. The rules for using them seem clear enough to allow interoperability. I can live with them as well. I see logically not more than two groups if you insist on grouping. Otherwise we need to explain why we need more. There was something about XML connotations needing it. Again, to reitarate my position i dont see why you need groups. [Yang, Lily L] Let me try one more time:=20 1) We don't live or die for "group". In another word, with or without, we can still make it work. 2) But, IMHO, the concept of "group" allows better delineation of the semantics in input/output. Take the example of one LFB with one "exception-output" and n "normal-output". Yes, you can represent that as output 0, 1, ... n (that is, just one group). But with this construct, you lose the semantic difference of output 0 from 1 to n. With the concept of grouping 1 to n together, you retain that semantic meaning in the construct itself. 3) What do we lose without "group"? I've shown that in 2). Now what do we lose with "group"? Does "group" impose more complexity for LFB designers? Absolutely not. Yes, it means one more concept to wrestle with in the model document, but if it is useful, then it is worthwhile. Besides, we are wrestling with it already :-) 4) No, the point about XML is misunderstood here. I think we all agree that we need to allow multiple outputs for some LFB so that they can fork. One argument is to allow it only for special LFBs like redirector. If we take that approach, it means the XML schema would not be the same for every LFB. That doesn't seem like a good design, and so the model team is more in favor of the generic schema that allows multiple output (including groups) for any LFB, as long as it makes sens. [/Yang, Lily L] The other contention point is the naming around "redirector". [Yang, Lily L] Don't seem too contentious to me. I don't mind if you have better name. I can live with demux if that makes you happier. [/Yang, Lily L]=20 Both the above seem to me to be overzelous future-proofing design. Ok, there i said it. [Yang, Lily L] Depends on the price you pay for that future-proofing. If it is cheap, why not? I think that is the case here. [/Yang, Lily L] cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 14:02:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00609 for ; Wed, 5 May 2004 14:02:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLQid-0003TN-4h for forces-archive@ietf.org; Wed, 05 May 2004 14:02:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQgp-000316-00 for forces-archive@ietf.org; Wed, 05 May 2004 14:00:16 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLQeQ-0002Dh-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 13:57:46 -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.00D98DFD@cherry.ease.lsoft.com>; Wed, 5 May 2004 13:57:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15141669 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 13:57:29 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 13:52:40 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050510562782:7604 ; Wed, 5 May 2004 10:56:27 -0700 References: <5.1.0.14.0.20040505103128.023b83c0@localhost> <409690FC.1000904@idt.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <5.1.0.14.0.20040505103128.023b83c0@localhost> <5.1.0.14.0.20040505110416.0224cb18@localhost> 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 05/05/2004 10:56:28 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 10:56:29 AM, Serialize complete at 05/05/2004 10:56:29 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083779557.1022.676.camel@jzny.localdomain> Date: Wed, 5 May 2004 13:52:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Revised LFB input/output text Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040505110416.0224cb18@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 11:07, Joel M. Halpern wrote: > From a topological point of view, the two are the same. > They are each an LFB instance of an LFB class (two different classes). > They each have one input, with meta-data tagging, and two outputs. > One class is defined to use the meta-data to decide which of the two > outputs to send the packet to. > > The other is defined to always send the packet on output 1, and sometimtes > (depending upon the metadata) to make a copy of the packet, modify the > meta-data and send the copy on output two. > > I would expect the outputs to have very different names in the two LFB > class definitions. The first one might have outputs named IPv4 and IPv6, > while the second might have outputs named normal and LEA. > > Connecting those outputs up properly is the job of the CE> Yes, the above should work. I think we have _different_ views of how things should work - which is almost implementation detailed. What worries me is that the definition of LFB classes, when the time comes, is going to be very contentious (at least with me). You seem to have a lot of dependicies on metadata - which may explain a lot of our disagreements. I can live with the above, just dont impose the usage of metadata on me. my view, to summarize: All LFBs can be looked at as reentrant clones of the LFB class. You can instantiate an LFB but it is useless unless bound to a packet path/topology. Once the CE creates the LFB topology (connects inputs to outputs), then theres no dependency on metadata to decide where to go next. The path decision is based on processing which is driven by state primarily. State could actually be static internal data like "always drop". Maybe i should present again over a concall to the design team what i presented at Mineapolis. or maybe i should output a draft. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 14:30:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03243 for ; Wed, 5 May 2004 14:30:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLRAZ-0004Wm-PU for forces-archive@ietf.org; Wed, 05 May 2004 14:30:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLR9e-0004F0-00 for forces-archive@ietf.org; Wed, 05 May 2004 14:30:02 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLR8q-0003y9-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 14:29:12 -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.00D98D9F@cherry.ease.lsoft.com>; Wed, 5 May 2004 14:29:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15143997 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 14:29:10 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 14:28:40 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050511322792:7658 ; Wed, 5 May 2004 11:32:27 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> <409906C1.5060000@idt.com> 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 05/05/2004 11:32:28 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 11:32:29 AM, Serialize complete at 05/05/2004 11:32:29 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083781717.1022.780.camel@jzny.localdomain> Date: Wed, 5 May 2004 14:28:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Metadata WAS(Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <409906C1.5060000@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 11:22, Alan DeKok wrote: > I believe that they do. The one nit-pick is that you're group > re-direction with session termination. Routers re-direct packets, and > also update TTL/checksum, but no one pretends that updating TTL/checksum > is related at all to redirection. [..] > In this context, the re-director *is* used to terminate the "common > packet handling" topology, and sends packets to the "uni/broad-cast > packet handling" topology. So I understand your point. But since the > topologies over-lap, the redirector is very useful. There are two extremes: 1) 10 mile view level: How big is the LFB topology and if it spans multiple devices? I think we draw a line at saying a single FE is the 10 mile view. Not to say the concept of redirecting on the egress of each device doesnt apply - we are just drawing a line. Once you say that, the redirection is mostly applicable at the egress of the FE. Nothing is saying you cant based on state at the middle of the topology decide to redirect and terminate the topology. 2) The microscopic view: Is an LFB itself a micromodel of the LFB? talking fractal modeling here ;-> I just think that such an approach, while generic and makes sense is complicating things. > > Ok, it is probably just semantics, let me clarify my view: > > * the result of internal processing is NOT metadata. Metadata MAY be > > produced as a side-effect of processing. The result of processing is a > > decision. Metadata is what gets carried around with the packet. > > This is the confusion I was trying to address in my "metadata > vocabulary" draft. I'm updating the text, and will be adding it to the > model document. > > The result of a decision IS meta-data. The result has physical > presence somewhere in the LFB, or in the device implementing the LFB. Interesting idea. > In this context, the metadata is: > > a) internal to the LFB/device > b) explicitly represented as some "result" of a decision process yikes ;-> Ok, i see where you are coming from. Its a little over the edge but not wrong. > When the packet is sent out of the "IP validator" device, the device > can do it in one of two ways: > > 1) Have one output, and attach the good/bad decision as metadata > In this context, the metadata is: > a) external to the device > b) explicitly represented as bits on the wire, associated with > the > packet Sure, b) is within the FE (or could be a shared mem location that is updated. > 2) have two outputs, for good/bad packets > In this context, the metadata is: > a) external to the device > b) implicitly represented in the fact that bad packets are on the > "bad" wire, and good packets are on the "good" wire. The only need for the metadata was to select one of two patbs. It doesnt seem to have much use outside the LFB. Let me clarify: In your definition _anything_ associated with a packets processing, including any decision, as long as it is not packet content is metadata. I think i agree with above definition i am just having a hard time swallowing it for a microscopic view of the LFB. In other words i see internal metadata as useful only within the bounds of the LFB. Once it goes out, it is external metadata - and since i am ignoring internal metadata, then theres only one type of metadata which you refer to as external. > > And that decision is metadata. Look at it as the LFB adding metadata > to the packet internally, and then internally consuming that metadata > when the branching decision is made. > > In all cases, the concept of the metadata is identical. The only > difference is the scale at which you examine the metadata. Yes, i understand you now - not sure if i like it. > e.g. Metadata which is explicitly represented in paths between LFB's > or devices on an FE often never makes it out of the FE. Yet when you > look at the router in which that FE sits, you can't realistically claim > that the metadata doesn't exist. It does, just not at the current scale. > Sure; like i said you can look at the FE as one fat LFB. You just gotta draw a line somewhere. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 14:41:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03856 for ; Wed, 5 May 2004 14:41:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLRL1-0007b3-Iw for forces-archive@ietf.org; Wed, 05 May 2004 14:41:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRK2-0007KG-00 for forces-archive@ietf.org; Wed, 05 May 2004 14:40:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLRIz-0006sj-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 14:39:41 -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 <9.00D98DEB@cherry.ease.lsoft.com>; Wed, 5 May 2004 14:39:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15145893 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 14:39:40 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 14:39:27 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050511431502:7678 ; Wed, 5 May 2004 11:43:15 -0700 References: <1083768671.1022.156.camel@jzny.localdomain> <633040434.1083774177@EEN9169.een.bris.ac.uk> 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 05/05/2004 11:43:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 11:43:16 AM, Serialize complete at 05/05/2004 11:43:16 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083782365.1023.802.camel@jzny.localdomain> Date: Wed, 5 May 2004 14:39:25 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Revised LFB input/output text Comments: To: Alistair Munro To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <633040434.1083774177@EEN9169.een.bris.ac.uk> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 11:22, Alistair Munro wrote: > Dear All, > > On the redirector and metadata/processing issues (Alan de Kok, Jamal's > exchange), I think Alan's model is more general and precise and thus more > acceptable to me at least. > > I didn't want to have a model that ruled out redirector/demux LFBs or > aggregator/mux LFBs (selection based on metadata, no processing) and > allowed only the mux/demux embedded in LFBs of greater functionality > (selection based on internal processing results). The previous model > appeared to allow only the latter, and this is not compatible with silicon > that exists today. Actually the only reason i am continuing this thread is because my thought is that the model i have in mind is left out ;-> > The current model text is better bar maybe some examples > and text optimisations. Valid examples would help. > Note: I take "processing" to mean a function that includes internal data or > state supplied independently of the packet flow together with metadata. So > just adding two metadatums (?) together isn't processing. Processing is what you do to come to a decision of "what next?". Actually now that i understand Alan's view, i am even more adamant to define it this way for simplicity's sake. > Speaking as editor of the NPF FE model, where support of legacy silicon is > essential, I believe this view is the consensus of the NPF members active > in this area. But I'll have to let them speak for themselves. > My approach may be slightly different. Come up with general and fit in the legacy devices. No need to restrict how much you can innovate because of legacy devices. I actually have a few legacy chips i modeled against. > > Actually, the mirror/duplicator LFB is an interesting contrast to the > > redirector LFB; > > I think it is an unrelated function, not a contrast. Interesting > nevertheless. Not from what Joel describes - and i can accept that point of view. I still think theres a contrast between something that takes a packet and another that introduces an extra one in the system. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 14:51:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04283 for ; Wed, 5 May 2004 14:51:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLRU6-0002Nq-7o for forces-archive@ietf.org; Wed, 05 May 2004 14:51:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRTK-00025Z-00 for forces-archive@ietf.org; Wed, 05 May 2004 14:50:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLRSJ-0001ly-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 14:49: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.00D98E0D@cherry.ease.lsoft.com>; Wed, 5 May 2004 14:49:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15146673 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 14:49:05 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 14:48:36 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050511522461:7698 ; Wed, 5 May 2004 11:52:24 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDC1F@orsmsx408.jf.intel.com> 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 05/05/2004 11:52:24 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 11:52:26 AM, Serialize complete at 05/05/2004 11:52:26 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083782914.1022.812.camel@jzny.localdomain> Date: Wed, 5 May 2004 14:48:34 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE0CDC1F@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Lily, On Wed, 2004-05-05 at 12:41, Yang, Lily L wrote: > > I can live with them as well. I see logically not more than two groups > if you insist on grouping. Otherwise we need to explain why we need > more. There was something about XML connotations needing it. > Again, to reitarate my position i dont see why you need groups. > > [Yang, Lily L] Let me try one more time: > 1) We don't live or die for "group". In another word, with or without, > we can still make it work. > 2) But, IMHO, the concept of "group" allows better delineation of the > semantics in input/output. As i said earlier, the input text is allowing me to ignor or lave with grouping so i am fine with it. The only challeneg is in the output. > Take the example of one LFB with one > "exception-output" and n "normal-output". Yes, you can represent that as > output 0, 1, ... n (that is, just one group). But with this construct, > you lose the semantic difference of output 0 from 1 to n. With the > concept of grouping 1 to n together, you retain that semantic meaning in > the construct itself. I am not sure i agree theres any semantic loss, but i can live with that because it doesnt make a difference for me. So, ok - two groups. > 3) What do we lose without "group"? I've shown that in 2). Now what do > we lose with "group"? Does "group" impose more complexity for LFB > designers? Absolutely not. Yes, it means one more concept to wrestle > with in the model document, but if it is useful, then it is worthwhile. > Besides, we are wrestling with it already :-) for one it is confusing. Ive asked for a sample of a legit example with more than one group + exception and noone is responding on that point;-> > 4) No, the point about XML is misunderstood here. I think we all agree > that we need to allow multiple outputs for some LFB so that they can > fork. One argument is to allow it only for special LFBs like redirector. > If we take that approach, it means the XML schema would not be the same > for every LFB. That doesn't seem like a good design, and so the model > team is more in favor of the generic schema that allows multiple output > (including groups) for any LFB, as long as it makes sens. > [/Yang, Lily L] > I think too much genericity may be dangerous. Because LFB class Y and class X need it doesnt equate class Z need it. Refer to my email to Alan; this is probably solvable by defining the granularity levels. > > The other contention point is the naming around "redirector". > [Yang, Lily L] Don't seem too contentious to me. I don't mind if you > have better name. I can live with demux if that makes you happier. > [/Yang, Lily L] Anything but redirector. > Both the above seem to me to be overzelous future-proofing design. Ok, > there i said it. > > [Yang, Lily L] Depends on the price you pay for that future-proofing. If > it is cheap, why not? I think that is the case here. > [/Yang, Lily L] > Confusion is not cheap friend ;-> cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 14:54:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04552 for ; Wed, 5 May 2004 14:54:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLRXe-0003U8-BI for forces-archive@ietf.org; Wed, 05 May 2004 14:54:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRWq-0003DN-00 for forces-archive@ietf.org; Wed, 05 May 2004 14:54:00 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLRW1-0002wc-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 14:53: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 <9.00D98E2B@cherry.ease.lsoft.com>; Wed, 5 May 2004 14:53:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15147060 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 14:53:08 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 14:44:53 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6924231 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 05 May 2004 14:44:52 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <633040434.1083774177@EEN9169.een.bris.ac.uk> <1083768671.1022.156.camel@jzny.localdomain> <633040434.1083774177@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040505144229.024ad908@localhost> Date: Wed, 5 May 2004 14:44:27 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083782365.1023.802.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I agree that the two (director and replicator) are very different LFBs. However, topological the placement and connections may well be identical. Yours, Joel M. Halpern PS: I have tried to use the phrase topology (specifically LFB topology) consistently. To me the full set of LFB instances and their connectivity within an FE. I would hate to get into the complexity of trying to describe multiple topologies within an FE. At 02:39 PM 5/5/2004 -0400, Jamal Hadi Salim wrote: > > > Actually, the mirror/duplicator LFB is an interesting contrast to the > > > redirector LFB; > > > > I think it is an unrelated function, not a contrast. Interesting > > nevertheless. > >Not from what Joel describes - and i can accept that point of view. I >still think theres a contrast between something that takes a packet and >another that introduces an extra one in the system. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 15:11:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05882 for ; Wed, 5 May 2004 15:11:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLRoF-0000We-K4 for forces-archive@ietf.org; Wed, 05 May 2004 15:11:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRnF-0000FV-00 for forces-archive@ietf.org; Wed, 05 May 2004 15:10:58 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLRmU-0007m0-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 15:10:10 -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.00D98ED6@cherry.ease.lsoft.com>; Wed, 5 May 2004 15:10:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15149132 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 15:10:09 -0400 Approved-By: lily.l.yang@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 15:09:05 -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 i45J99K7014557; Wed, 5 May 2004 19:09:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i45J93xF018905; Wed, 5 May 2004 19:09:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050512084904075 ; Wed, 05 May 2004 12:08:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 12:08:49 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: output port groups WAS(Re: Revised LFB input/output text Thread-Index: AcQy0bQWOPaAogFZRoaQbbEmwd//WgAAGQ1A X-OriginalArrivalTime: 05 May 2004 19:08:49.0401 (UTC) FILETIME=[65B4A690:01C432D4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE5C4318@orsmsx408.jf.intel.com> Date: Wed, 5 May 2004 12:08:49 -0700 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable see below ... -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim Sent: Wednesday, May 05, 2004 11:49 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: output port groups WAS(Re: Revised LFB input/output text Hi Lily, On Wed, 2004-05-05 at 12:41, Yang, Lily L wrote: > > I can live with them as well. I see logically not more than two groups > if you insist on grouping. Otherwise we need to explain why we need > more. There was something about XML connotations needing it. > Again, to reitarate my position i dont see why you need groups. > > [Yang, Lily L] Let me try one more time: > 1) We don't live or die for "group". In another word, with or without, > we can still make it work. > 2) But, IMHO, the concept of "group" allows better delineation of the > semantics in input/output. As i said earlier, the input text is allowing me to ignor or lave with grouping so i am fine with it. The only challeneg is in the output. Well, it is similar for the output -- you can use it or ignore it. > Take the example of one LFB with one > "exception-output" and n "normal-output". Yes, you can represent that = as > output 0, 1, ... n (that is, just one group). But with this construct, > you lose the semantic difference of output 0 from 1 to n. With the > concept of grouping 1 to n together, you retain that semantic meaning = in > the construct itself. I am not sure i agree theres any semantic loss, but i can live with that because it doesnt make a difference for me. So, ok - two groups. > 3) What do we lose without "group"? I've shown that in 2). Now what do > we lose with "group"? Does "group" impose more complexity for LFB > designers? Absolutely not. Yes, it means one more concept to wrestle > with in the model document, but if it is useful, then it is = worthwhile. > Besides, we are wrestling with it already :-) for one it is confusing. Ive asked for a sample of a legit example with more than one group + exception and noone is responding on that point;-> Going from 2 to n isn't a quantum jump here, so constraining to a = hard magic number like 2 instead of n just does not make much sense to = me. So I would argue if we allow 2, we should allow n. > 4) No, the point about XML is misunderstood here. I think we all agree > that we need to allow multiple outputs for some LFB so that they can > fork. One argument is to allow it only for special LFBs like = redirector. > If we take that approach, it means the XML schema would not be the = same > for every LFB. That doesn't seem like a good design, and so the model > team is more in favor of the generic schema that allows multiple = output > (including groups) for any LFB, as long as it makes sens. > [/Yang, Lily L] > I think too much genericity may be dangerous. Because LFB class Y and class X need it doesnt equate class Z need it. Refer to my email to Alan; this is probably solvable by defining the granularity levels. But remember we are defining a "general" FE model here that has = enough flexibity built in to allow for future innovation. IF LFB class X = and Y need something, then the model should *allow* it. By that, nobody = is saying every LFB has to use it. It is up to the LFB designers to = choose the right tool for the right job. But it is FE model's = responsibility to provide a powerful enough tool kit for them. If = someone sees everything as a nail just because he's got a hammer in his = hand, that is his own problem, not the hammer provider's fault.=20 > > The other contention point is the naming around "redirector". > [Yang, Lily L] Don't seem too contentious to me. I don't mind if you > have better name. I can live with demux if that makes you happier. > [/Yang, Lily L] Anything but redirector. I am sure you don't really mean it :-).=20 Ok, I admit I've said something just like that in other occasions. Now = you just make me realize this "election" mindset might be dangerous all = by itself :-) > Both the above seem to me to be overzelous future-proofing design. Ok, > there i said it. > > [Yang, Lily L] Depends on the price you pay for that future-proofing. = If > it is cheap, why not? I think that is the case here. > [/Yang, Lily L] > Confusion is not cheap friend ;-> Shhh, isn't that our trick for job security for us engineers ;-) cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 16:00:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08731 for ; Wed, 5 May 2004 16:00:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLSZW-0006f5-Uc for forces-archive@ietf.org; Wed, 05 May 2004 16:00:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLSYX-0006M4-00 for forces-archive@ietf.org; Wed, 05 May 2004 15:59:50 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLSXV-0005tj-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 15:58:45 -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.00D9907A@cherry.ease.lsoft.com>; Wed, 5 May 2004 15:58:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15153071 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 15:58:43 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 15:42:37 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050512462336:7782 ; Wed, 5 May 2004 12:46:23 -0700 References: <2AF68A477DD44C4EBCBE338C24E7A9EE5C4318@orsmsx408.jf.intel.com> 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 05/05/2004 12:46:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 12:46:26 PM, Serialize complete at 05/05/2004 12:46:26 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083786153.1023.845.camel@jzny.localdomain> Date: Wed, 5 May 2004 15:42:33 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE5C4318@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 15:08, Yang, Lily L wrote: > As i said earlier, the input text is allowing me to ignor or lave with > grouping so i am fine with it. The only challeneg is in the output. > > Well, it is similar for the output -- you can use it or ignore it. > 'fraid not. You have three sample alternatives for input. You only have one alternative for output. > for one it is confusing. Ive asked for a sample of a legit example with > more than one group + exception and noone is responding on that point;-> > > Going from 2 to n isn't a quantum jump here, so constraining to a > hard magic number like 2 instead of n just does not make much sense to > me. So I would argue if we allow 2, we should allow n. > Yeah, but it doesnt make sense to have more than two. Conclusion by induction doesnt apply in all cases. Ok, lets take a step back, i am claiming it doesnt even make sense to have two ;-> Actualy even one step back further, I am claiming one you dont need a group at all. All, i am asking for is justification. > I think too much genericity may be dangerous. Because LFB class Y and > class X need it doesnt equate class Z need it. > Refer to my email to Alan; this is probably solvable by defining the > granularity levels. > > But remember we are defining a "general" FE model here that has > enough flexibity built in to allow for future innovation. > IF LFB class X and Y need something, then the model should *allow* it. > By that, nobody is saying every LFB has to use it. It is up to the LFB > designers to choose the right tool for the right job. But it is FE > model's responsibility to provide a powerful enough tool kit for them. > If someone sees everything as a nail just because he's got a hammer in > his hand, that is his own problem, not the hammer provider's fault. > > What worries me is not the hammer ;-> Its someone down the road asking me how come i dont have a hammer when thats what the doc says;-> I have been bitten by loose syntax before. > > > > The other contention point is the naming around "redirector". > > [Yang, Lily L] Don't seem too contentious to me. I don't mind if you > > have better name. I can live with demux if that makes you happier. > > [/Yang, Lily L] > > > Anything but redirector. > I am sure you don't really mean it :-). > Ok, I admit I've said something just like that in other occasions. > Now you just make me realize this "election" mindset might be dangerous > all by itself :-) > I am actually quiet serious. Redirector in literature out there has very specific semantics on network equipment. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 5 20:30:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22325 for ; Wed, 5 May 2004 20:30:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLWmB-00014C-0F for forces-archive@ietf.org; Wed, 05 May 2004 20:30:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLWlP-0000m8-00 for forces-archive@ietf.org; Wed, 05 May 2004 20:29:24 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLWku-0000Sb-00 for forces-archive@IETF.ORG; Wed, 05 May 2004 20:28:52 -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 <20.00D99562@cherry.ease.lsoft.com>; Wed, 5 May 2004 20:28:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15174469 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 May 2004 20:28:50 -0400 Approved-By: Aaudu2000@AOL.COM Received: from 205.188.139.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 20:19:43 -0400 Received: from Aaudu2000@aol.com by imo-d20.mx.aol.com (mail_out_v37_r1.3.) id l.1f1.1fb351e2 (4246); Wed, 5 May 2004 20:19:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1083802771" X-Mailer: 9.0 for Windows sub 5017 Message-ID: <1f1.1fb351e2.2dcade93@aol.com> Date: Wed, 5 May 2004 20:19:31 EDT Reply-To: Aaudu2000@AOL.COM Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 -------------------------------1083802771 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello Jamal, I am not sure your view will work for a Classifier with one input and multiple outputs. If I have to assign different QoS to incoming packets due to some criteria which are computed in real-time, it seems fair to say that the meta-data so determined will be used to separate the packet stream into different queues for proper treatment. Such meta-data can only be determined dynamically, and I don't see how you can pre-determine it. Regards, Alex. In a message dated 5/5/2004 2:27:09 PM Central Standard Time, hadi@znyx.com writes: On Wed, 2004-05-05 at 11:07, Joel M. Halpern wrote: > From a topological point of view, the two are the same. > They are each an LFB instance of an LFB class (two different classes). > They each have one input, with meta-data tagging, and two outputs. > One class is defined to use the meta-data to decide which of the two > outputs to send the packet to. > > The other is defined to always send the packet on output 1, and sometimtes > (depending upon the metadata) to make a copy of the packet, modify the > meta-data and send the copy on output two. > > I would expect the outputs to have very different names in the two LFB > class definitions. The first one might have outputs named IPv4 and IPv6, > while the second might have outputs named normal and LEA. > > Connecting those outputs up properly is the job of the CE> Yes, the above should work. I think we have _different_ views of how things should work - which is almost implementation detailed. What worries me is that the definition of LFB classes, when the time comes, is going to be very contentious (at least with me). You seem to have a lot of dependicies on metadata - which may explain a lot of our disagreements. I can live with the above, just dont impose the usage of metadata on me. my view, to summarize: All LFBs can be looked at as reentrant clones of the LFB class. You can instantiate an LFB but it is useless unless bound to a packet path/topology. Once the CE creates the LFB topology (connects inputs to outputs), then theres no dependency on metadata to decide where to go next. The path decision is based on processing which is driven by state primarily. State could actually be static internal data like "always drop". Maybe i should present again over a concall to the design team what i presented at Mineapolis. or maybe i should output a draft. cheers, jamal -------------------------------1083802771 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello Jamal,
 
I am not sure your view will work for a Classifier with one input and m= ultiple outputs. If I
have to assign different QoS to incoming packets due to some criteria w= hich are computed
in real-time, it seems fair to say that the meta-data so dete= rmined will be used to separate
the packet stream into different queues for proper treatment.=   Such meta-data can only be
determined dynamically, and I don't see how you can pre-determine it.
 
Regards,
Alex. 
 
In a message dated 5/5/2004 2:27:09 PM Central Standard Time, hadi@znyx= .com writes:
On Wed, 2004-05-05 at 11:07, Joel M. Halpern w= rote:
> From a topological point of view, the two are the same.
>= ; They are each an LFB instance of an LFB class (two different classes).
= > They each have one input, with meta-data tagging, and two outputs.
&= gt; One class is defined to use the meta-data to decide which of the two
= > outputs to send the packet to.
>
> The other is defined to=20= always send the packet on output 1, and sometimtes
> (depending upon t= he metadata) to make a copy of the packet, modify the
> meta-data and=20= send the copy on output two.
>
> I would expect the outputs to h= ave very different names in the two LFB
> class definitions.  The= first one might have outputs named IPv4 and IPv6,
> while the second=20= might have outputs named normal and LEA.
>
> Connecting those ou= tputs up properly is the job of the CE>

Yes, the above should work= .

I think we have _different_ views of how things should work - which= is
almost implementation detailed. What worries me is that the definitio= n
of LFB classes, when the time comes, is going to be very contentious (a= t
least with me).
You seem to have a lot of dependicies on metadata -=20= which may explain a
lot of our disagreements.
I can live with the abov= e, just dont impose the usage of metadata on me.

my view, to summariz= e:
All LFBs can be looked at as reentrant clones of the LFB class. You ca= n
instantiate an LFB but it is useless unless bound to a packet
path/t= opology. Once the CE creates the LFB topology (connects inputs to
outputs= ), then theres no dependency on metadata to decide where to go
next. The=20= path decision is based on processing which is driven by state
primarily.=20= State could actually be static internal data like "always
drop".

M= aybe i should present again over a concall to the design team what i
pres= ented at Mineapolis. or maybe i should output a draft.

cheers,
jam= al
-------------------------------1083802771-- From owner-forces@PEACH.EASE.LSOFT.COM Thu May 6 08:15:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08455 for ; Thu, 6 May 2004 08:15:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLhmq-000789-Tm for forces-archive@ietf.org; Thu, 06 May 2004 08:15:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLhlr-0006k6-00 for forces-archive@ietf.org; Thu, 06 May 2004 08:14:36 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLhkt-0006La-00 for forces-archive@IETF.ORG; Thu, 06 May 2004 08:13: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 <18.00D9A2FC@cherry.ease.lsoft.com>; Thu, 6 May 2004 8:13:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15268618 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 May 2004 08:13:33 -0400 Approved-By: alistair.munro@U4EATECH.COM Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 May 2004 06:24:28 -0400 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.30) id 1BLg1x-0002NR-H2; Thu, 06 May 2004 11:23:05 +0100 Received: from EEN9169.een.bris.ac.uk (een9169.een.bris.ac.uk [137.222.189.169]) (authenticated (0 bits)) by ncsb.bris.ac.uk (8.11.7-20030918/8.11.6) with ESMTP id i46ALD817718 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 6 May 2004 11:21:13 +0100 (BST) References: <1083782365.1023.802.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:01dFQrkdm5jAWslaT7otq6WPqstqG0tObKWfOxvqS1oteCoPw=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <701336198.1083842473@EEN9169.een.bris.ac.uk> Date: Thu, 6 May 2004 11:21:13 +0100 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083782365.1023.802.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Jamal, >> Speaking as editor of the NPF FE model, where support of legacy silicon >> is essential,... > > My approach may be slightly different. Come up with general and fit in > the legacy devices. No need to restrict how much you can innovate > because of legacy devices. We had at least one good example where the model apparently excluded use of one specific approach, i.e. it was not general enough. So I agree with you, I think. But I wouldn't want to say that legacy constrains innovation. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eagroup.com From owner-forces@PEACH.EASE.LSOFT.COM Thu May 6 09:41:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12481 for ; Thu, 6 May 2004 09:41:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLj8H-0002vT-0a for forces-archive@ietf.org; Thu, 06 May 2004 09:41:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj7L-0002Wd-00 for forces-archive@ietf.org; Thu, 06 May 2004 09:40:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLj6f-00028K-00 for forces-archive@IETF.ORG; Thu, 06 May 2004 09:40: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 <17.00D9A6E9@cherry.ease.lsoft.com>; Thu, 6 May 2004 9:40:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15278231 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 May 2004 09:40:06 -0400 Approved-By: alan.dekok@IDT.COM Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 May 2004 16:28:43 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 4E5351F036A for ; Wed, 5 May 2004 16:28:41 -0400 (EDT) Received: from idt.com (dhcp194.ott.idt.com [192.168.102.194]) by post.ott.idt.com (Postfix) with ESMTP id 0087E1F009D for ; Wed, 5 May 2004 16:20:59 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> <409906C1.5060000@idt.com> <1083781717.1022.780.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <40994C65.2030507@idt.com> Date: Wed, 5 May 2004 16:19:49 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Metadata WAS(Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083781717.1022.780.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > There are two extremes: > 1) 10 mile view level: How big is the LFB topology and if it spans > multiple devices? > I think we draw a line at saying a single FE is the 10 mile view. I agree. I think the rest of the authors of the model document agree, too. > 2) The microscopic view: > Is an LFB itself a micromodel of the LFB? talking fractal modeling > here ;-> I just think that such an approach, while generic and makes > sense is complicating things. I agree here, too. As a benefit, however, it may be possible to occasionally use LFB terminology to describe events happening *inside* of an LFB. This is not to say that those events are part of the LFB model, but that we're simply using a pre-existing terminology for a related system. > Let me clarify: > In your definition _anything_ associated with a packets processing, > including any decision, as long as it is not packet content is metadata. But... that *is* the definition of metadata: "Data which is associated with the packet data, but which is not part of the packet data" > I think i agree with above definition i am just having a hard time > swallowing it for a microscopic view of the LFB. In other words i see > internal metadata as useful only within the bounds of the LFB. Once it > goes out, it is external metadata - and since i am ignoring internal > metadata, then theres only one type of metadata which you refer to as > external. I agree. But I prefer to be able to use the word "metadata" when I refer to events happening inside of an LFB. The qualifier of "internal" metadata is still important. >> In all cases, the concept of the metadata is identical. The only >>difference is the scale at which you examine the metadata. > > Yes, i understand you now - not sure if i like it. After working on/with this model for a number of years, it's the conclusion I've ended up with. The benefit is that the same terms can be used to describe events at different scales. So the vocabulary becomes simpler, the model becomes simpler, and it's easier for me to remember what I'm talking about. > Sure; like i said you can look at the FE as one fat LFB. You just gotta > draw a line somewhere. Exactly. In this context, we do not want to talk about LFB's outside of the scope (or scale) of an FE. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu May 6 11:51:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22131 for ; Thu, 6 May 2004 11:51:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLl9Y-0004xM-FO for forces-archive@ietf.org; Thu, 06 May 2004 11:51:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLl8h-0004Ti-00 for forces-archive@ietf.org; Thu, 06 May 2004 11:50:24 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BLl7e-0003yD-00 for forces-archive@IETF.ORG; Thu, 06 May 2004 11:49: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 <11.00D9A800@cherry.ease.lsoft.com>; Thu, 6 May 2004 11:49:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15291413 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 May 2004 11:49:15 -0400 Approved-By: ellen.m.deleganes@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 May 2004 11:47:21 -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 i46Flpdm000585; Thu, 6 May 2004 15:47:51 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.10 2004/03/01 19:21:36 root Exp $) with SMTP id i46FiwkQ018461; Thu, 6 May 2004 15:45:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050608471518650 ; Thu, 06 May 2004 08:47:15 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 08:47:16 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: output port groups WAS(Re: Revised LFB input/output text Thread-Index: AcQy22x83tTMrd7sStmoAdpHTUyeeAAHYyZg X-OriginalArrivalTime: 06 May 2004 15:47:16.0041 (UTC) FILETIME=[67EA1B90:01C43381] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07EEABFC0@orsmsx408.jf.intel.com> Date: Thu, 6 May 2004 08:47:13 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable My comments are embedded. Regards, Ellen Deleganes -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, May 05, 2004 12:43 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: output port groups WAS(Re: Revised LFB input/output text On Wed, 2004-05-05 at 15:08, Yang, Lily L wrote: > As i said earlier, the input text is allowing me to ignor or lave with > grouping so i am fine with it. The only challeneg is in the output. > > Well, it is similar for the output -- you can use it or ignore it. > 'fraid not. You have three sample alternatives for input. You only have one alternative for output. An output group can be decomposed into multiple singleton outputs in an implementation. The output groups are a convenient modeling concept to group logically similar outputs from a single LFB together. An implementation could either describe the outputs using a group notation or as individual outputs if it desires, I don't see why the FE model disallows the multiple singleton output method. > for one it is confusing. Ive asked for a sample of a legit example with > more than one group + exception and noone is responding on that point;-> > > Going from 2 to n isn't a quantum jump here, so constraining to a > hard magic number like 2 instead of n just does not make much sense to > me. So I would argue if we allow 2, we should allow n. > I can't think of a specific example offhand either, but someone might. Setting an artificial limit when it doesn't simplify anything doesn't make sense either if there is a possibility where someone might need more than two groups. Yeah, but it doesnt make sense to have more than two. Conclusion by induction doesnt apply in all cases. Ok, lets take a step back, i am claiming it doesnt even make sense to have two ;-> Actualy even one step back further, I am claiming one you dont need a group at all. All, i am asking for is justification. Like I stated before, groups are a convenience, not a necessity. I personally think that it is easier to see how a group (or groups) could be broken up into the individual singletons, than combined into a group. It becomes more difficult to tell what outputs make sense to group than if it is spelled out by the model to begin with. > I think too much genericity may be dangerous. Because LFB class Y and > class X need it doesnt equate class Z need it. > Refer to my email to Alan; this is probably solvable by defining the > granularity levels. > > But remember we are defining a "general" FE model here that has > enough flexibity built in to allow for future innovation. > IF LFB class X and Y need something, then the model should *allow* it. > By that, nobody is saying every LFB has to use it. It is up to the LFB > designers to choose the right tool for the right job. But it is FE > model's responsibility to provide a powerful enough tool kit for them. > If someone sees everything as a nail just because he's got a hammer in > his hand, that is his own problem, not the hammer provider's fault. > > What worries me is not the hammer ;-> Its someone down the road asking me how come i dont have a hammer when thats what the doc says;-> I have been bitten by loose syntax before. The model document is intended to allow flexibility in implementations - this was one of the explicit requirements on the model document. It is possible that no implementation will support all of the flexibility and extensibility spelled out by the model document. > > > > The other contention point is the naming around "redirector". > > [Yang, Lily L] Don't seem too contentious to me. I don't mind if you > > have better name. I can live with demux if that makes you happier. > > [/Yang, Lily L] > > > Anything but redirector. > I am sure you don't really mean it :-). > Ok, I admit I've said something just like that in other occasions. > Now you just make me realize this "election" mindset might be dangerous > all by itself :-) > I am actually quiet serious. Redirector in literature out there has very specific semantics on network equipment. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri May 7 10:21:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25144 for ; Fri, 7 May 2004 10:21:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6ES-00029s-Q1 for forces-archive@ietf.org; Fri, 07 May 2004 10:21:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6DU-0001h5-00 for forces-archive@ietf.org; Fri, 07 May 2004 10:20:45 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BM6CP-00010c-00 for forces-archive@IETF.ORG; Fri, 07 May 2004 10:19: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 <10.00D9C6DB@cherry.ease.lsoft.com>; Fri, 7 May 2004 10:19:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15454705 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 May 2004 10:19:35 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 May 2004 09:40:55 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050706444133:9932 ; Fri, 7 May 2004 06:44:41 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> <409906C1.5060000@idt.com> <1083781717.1022.780.camel@jzny.localdomain> <40994C65.2030507@idt.com> 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 05/07/2004 06:44:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 06:44:43 AM, Serialize complete at 05/07/2004 06:44:43 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083937252.1034.118.camel@jzny.localdomain> Date: Fri, 7 May 2004 09:40:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Metadata WAS(Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <40994C65.2030507@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 16:19, Alan DeKok wrote: > > 2) The microscopic view: > > Is an LFB itself a micromodel of the LFB? talking fractal modeling > > here ;-> I just think that such an approach, while generic and makes > > sense is complicating things. > > I agree here, too. BTW, i apologize i missed out a little important detail. I meant to say the LFB being a micromodel of the LFB topology is where the fractal model comes in (in other words you microtopologies within a topology). This i find as unneeded complexity. > As a benefit, however, it may be possible to occasionally use LFB > terminology to describe events happening *inside* of an LFB. This is > not to say that those events are part of the LFB model, but that we're > simply using a pre-existing terminology for a related system. Like i said it makes sense technically. I am probably just blocking my mind from accepting it a) because its new approach - preference to play it safe comes first. I would rather not experiment and b) i get this nudging that it may be missing something. Call me a luddite if you want. > > Let me clarify: > > In your definition _anything_ associated with a packets processing, > > including any decision, as long as it is not packet content is metadata. > > But... that *is* the definition of metadata: "Data which is > associated with the packet data, but which is not part of the packet data" > Grrr - You are right, but i still dont like it ;-> I think we should restrict usage of that term on the inside-LFB aspect and be a little more specific. At the end of it all you want people to understand what the heck you are saying - it is always safe to start with commonly understood terms. You have just lumped a DMA descriptor, function return code, saved stack state and everything that happens within microcontext of an LFB execution path into one. > > I think i agree with above definition i am just having a hard time > > swallowing it for a microscopic view of the LFB. In other words i see > > internal metadata as useful only within the bounds of the LFB. Once it > > goes out, it is external metadata - and since i am ignoring internal > > metadata, then theres only one type of metadata which you refer to as > > external. > > I agree. But I prefer to be able to use the word "metadata" when I > refer to events happening inside of an LFB. The qualifier of "internal" > metadata is still important. > Ok, some serious text is needed to clarify some of these points. I posted question on the metadata a while back but my last email wasnt responded to. You should probably provide an alias for internal metadata. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri May 7 11:15:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25157 for ; Fri, 7 May 2004 10:21:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6ET-00029x-Fa for forces-archive@ietf.org; Fri, 07 May 2004 10:21:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6DV-0001hD-00 for forces-archive@ietf.org; Fri, 07 May 2004 10:20:45 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BM6CU-0001Ca-00 for forces-archive@IETF.ORG; Fri, 07 May 2004 10:19:42 -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 <17.00D9C6B1@cherry.ease.lsoft.com>; Fri, 7 May 2004 10:19:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15454713 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 May 2004 10:19:42 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 May 2004 09:41:00 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050706444674:9934 ; Fri, 7 May 2004 06:44:46 -0700 References: <468F3FDA28AA87429AD807992E22D07EEABFC0@orsmsx408.jf.intel.com> 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 05/07/2004 06:44:47 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 06:44:48 AM, Serialize complete at 05/07/2004 06:44:48 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1083937257.1037.120.camel@jzny.localdomain> Date: Fri, 7 May 2004 09:40:58 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07EEABFC0@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-05-06 at 11:47, Deleganes, Ellen M wrote: > An output group can be decomposed into multiple singleton outputs > in an implementation. The output groups are a convenient modeling > concept to group logically similar outputs from a single LFB together. > An implementation could either describe the outputs using a group > notation or as individual outputs if it desires, I don't see why the FE > model disallows the multiple singleton output method. > [..] > I can't think of a specific example offhand either, but someone > might. Setting an artificial limit when it doesn't simplify anything > doesn't make sense either if there is a possibility where someone might > need more than two groups. > > Ok, heres what you need to do so we can move on (I have about a million other comments on the model draft. I am also eagerly awaiting a response on the metadata from moons ago to be responded to). 1)I honestly dont think "redirector" is the right noun. If you insist on using it, please explain the current common usage of the term and the generalization of it. Probably something with the word "mux" in it would be useful. I think another term that needs to be scrubbed/defined is the "port" into/outof the LFB 2)If you insist on using "output groups" and "ports" (both of which i dont like) then you need to strengthen your text in a big way. I apologize for bringing this up again: As an example since you are struggling to find an example for more than two port groups, you clearly have no need for more than two - i would like to point out (again!) that you dont need more than one, and that if you dont need more than one, then you dont need the term "group". I should add, however, i am willing to live with for a middle ground good text explaining these details. Sorry, cant come up with non-biased text; so i will leave that to you hoping you understand my view. > The model document is intended to allow flexibility in > implementations - this was one of the explicit requirements on the model > document. It is possible that no implementation will support all of the > flexibility and extensibility spelled out by the model document. > Its clearly not flexible enough if i am trying hard to fit myself within it;-> I think the model is fine to capture all sorts of ideas, but the basics must be right. The outputs and inputs are basic.[1] cheers, jamal [1]Theres a lot of stuff i am throwing out or ignoring because the model is trying to cover everything under the sun. Example i wouldnt give a rats ass about inheritance of LFBs. I am sure someone with a product or trying to get a phd thesis would disagree. I am just being practical. From lzn_press@mail.com Sat May 8 20:10:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04550 for ; Sat, 8 May 2004 20:10:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMbtf-0003hs-5I for forces-archive@ietf.org; Sat, 08 May 2004 20:10:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMbsp-0003JE-00 for forces-archive@ietf.org; Sat, 08 May 2004 20:09:32 -0400 Received: from [148.243.186.197] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BMbs3-0002Y2-00; Sat, 08 May 2004 20:08:46 -0400 From: "Brasil 2004: . uve" To: enum-admin@ietf.org Subject: A propriedade, em vias de extinção? cf.: eos 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 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 08 May 2004 20:08:46 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.9 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment

(ref.:suv) Aos caros amigos, atenciosamente, Ferreira Passos/ConstruNews.

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (6)

Brasil 2004: direito de propriedade, em vias de extinção?

Caso não houver uma reação, em poucos anos a propriedade terá se transformado numa reminiscência histórica, e o velho sonho marxista se realizado na apatia e indiferença da chamada "burguesia", adverte Lindenberg

"Patrulhas", mordaça, anestesia

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas populares" inspiradas na teologia da libertação e nos Fóruns Sociais Mundiais. Assim, os meios de comunicação e a sociedade brasileira estão sendo "patrulhados", amordaçados, anestesiados.

Duas ameaças

* Em seu recente artigo "O direito de propriedade, instituição em vias de extinção?", da Série Temas Patrulhados, Lindenberg afirma que o direito de propriedade, no Brasil, está sendo vítima de duas ameaças implacáveis: o aumento da carga tributária - uma das mais altas do mundo - e os movimentos dos sem-terra e sem-teto, inspirados na teologia da libertação e no modelo cubano de produção de miséria.

"Burguesia": sem reação?

* Citando testemunhas de especialistas, o autor constata que se todos os projetos de majoração de impostos que estão sendo discutidos no Congresso forem aprovados, em poucos anos o direito de propriedade terá se transformado numa reminiscência histórica . O velho sonho marxista teria se realizado assim sem grandes reações por parte da "burguesia", anestesiada.

* No entanto, para as pessoas de bom senso, em geral, e para os católicos, em particular, essa escalada contra a propriedade constitui uma flagrante desobediência da lei divina e da lei natural, sem falar que caracterizará um golpe a mais na já combalida instituição familiar.

Reta ordem socioeconômica

* No artigo "O direito de propriedade, instituição em vias de extinção?" se lembra com abundante argumentação que a propriedade constitui pedra de ângulo da estrutura econômica e um dos princípios fundamentais de uma reta ordem socioeconômica. E não só por razões econômicas, perfeitamente válidas, mas também e principalmente por razões de ordem moral e religiosa.

Outros itens

* Outros itens desenvolvidos no artigo de Lindenberg, que oferecemos gratuitamente, por e-mail, junto com a Introdução do livro "Os católicos e a economia de mercado":

- Família e propriedade

- Propriedade e princípio ontológico

- Propriedade, autonomia, personalidad

- Bolo, fatias e solução

- Economias socializadas versus bom senso

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 From owner-forces@PEACH.EASE.LSOFT.COM Mon May 10 13:44:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19430 for ; Mon, 10 May 2004 13:44:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEos-0004Ez-CW for forces-archive@ietf.org; Mon, 10 May 2004 13:44:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEo2-0003uC-00 for forces-archive@ietf.org; Mon, 10 May 2004 13:43:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BNEnE-0003ZN-00 for forces-archive@IETF.ORG; Mon, 10 May 2004 13:42: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 <5.00DA079C@cherry.ease.lsoft.com>; Mon, 10 May 2004 13:42:20 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 15920930 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 May 2004 13:42:19 -0400 Approved-By: alan.dekok@IDT.COM Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 May 2004 13:11:46 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id AAB381F0064 for ; Mon, 10 May 2004 13:11:45 -0400 (EDT) Received: from idt.com (dhcp194.ott.idt.com [192.168.102.194]) by post.ott.idt.com (Postfix) with ESMTP id 31C701F0055 for ; Mon, 10 May 2004 13:11:45 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> <409906C1.5060000@idt.com> <1083781717.1022.780.camel@jzny.localdomain> <40994C65.2030507@idt.com> <1083937252.1034.118.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <409FB785.2010005@idt.com> Date: Mon, 10 May 2004 13:10:29 -0400 Reply-To: Alan DeKok Sender: Forwarding and Control Element Separation From: Alan DeKok Subject: Re: Metadata WAS(Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1083937252.1034.118.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > BTW, i apologize i missed out a little important detail. I meant to say > the LFB being a micromodel of the LFB topology is where the fractal > model comes in (in other words you microtopologies within a topology). > This i find as unneeded complexity. Perhaps I wasn't clear. I *don't* see the "micromodel" as part of the ForCES LFB model. However, in common conversation about ForCES, it's useful to use similar terminology, where possible. > Like i said it makes sense technically. I am probably just blocking my > mind from accepting it a) because its new approach - preference to play > it safe comes first. "Play it safe", how? Calling something a MUX is describing what it does, independent of where it exists in the network. >> But... that *is* the definition of metadata: "Data which is >>associated with the packet data, but which is not part of the packet data" > > Grrr - You are right, but i still dont like it ;-> I think we should > restrict usage of that term on the inside-LFB aspect and be a little > more specific. Which is why my metadata draft was using vocabulary like "internal metadata". It's clearly not outside of the LFB, but *something* logically exists, and we need a name for it. Calling it "metadata" outside of the LFB, and "a decision" inside of the LFB is awkward. Even when an LFB produces metadata externally, there *must* be some internal representation of it, before it's produced. Why not call it "metadata" ? > At the end of it all you want people to understand what > the heck you are saying - it is always safe to start with commonly > understood terms. You have just lumped a DMA descriptor, function return > code, saved stack state and everything that happens within microcontext > of an LFB execution path into one. "... into one common vocabulary", yes. A CPU is a CPU is a CPU, no matter if it's x86 or PPC. The generic term applies to them all, and the specific terms describe an implementation. > Ok, some serious text is needed to clarify some of these points. I will be adding text about this to the draft. > I posted question on the metadata a while back but my last email wasnt > responded to. You should probably provide an alias for internal > metadata. Could you post your question again? I think I lost it... Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 12 12:40:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25072 for ; Wed, 12 May 2004 12:40:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwmV-0001VR-PB for forces-archive@ietf.org; Wed, 12 May 2004 12:40:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwl5-0000mA-00 for forces-archive@ietf.org; Wed, 12 May 2004 12:39:04 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BNwjC-00004d-00 for forces-archive@IETF.ORG; Wed, 12 May 2004 12:37:06 -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.00DA4680@cherry.ease.lsoft.com>; Wed, 12 May 2004 12:37:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16285881 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 May 2004 12:36:58 -0400 Approved-By: ellen.m.deleganes@INTEL.COM Received: from 192.55.52.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 May 2004 12:36:19 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.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 i4CGavul004770; Wed, 12 May 2004 16:36:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i4CGYvZ7016700; Wed, 12 May 2004 16:36:40 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 M2004051209360804668 ; Wed, 12 May 2004 09:36:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 09:35:44 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: output port groups WAS(Re: Revised LFB input/output text Thread-Index: AcQ0Pl4bUYeAUIHVQCC86r7h3xOW7wD/uthQ X-OriginalArrivalTime: 12 May 2004 16:35:44.0744 (UTC) FILETIME=[2C1D7680:01C4383F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07EFA1CDE@orsmsx408.jf.intel.com> Date: Wed, 12 May 2004 09:35:44 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I should have been clearer in the first paragraph. In the last sentence what I really meant to say is: I don't believe the FE model intends to disallow an implementation from specifying multiple singleton outputs. I view the output group as a convenient concept or notation, to describe multiple outputs with similar characteristics. Whether an array is used to specify the members of the group or individual names are given to each singleton output is completely up to the implementer. It doesn't take that much imagination to see that individual outputs within an output group could be specified as individual units. It is slightly more difficult to determine which outputs have enough in common to put into a group, and the model team is attempting to describe when it is appropriate to group outputs. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, May 07, 2004 6:41 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: output port groups WAS(Re: Revised LFB input/output text On Thu, 2004-05-06 at 11:47, Deleganes, Ellen M wrote: > An output group can be decomposed into multiple singleton outputs > in an implementation. The output groups are a convenient modeling > concept to group logically similar outputs from a single LFB together. > An implementation could either describe the outputs using a group > notation or as individual outputs if it desires, I don't see why the FE > model disallows the multiple singleton output method. > [..] > I can't think of a specific example offhand either, but someone > might. Setting an artificial limit when it doesn't simplify anything > doesn't make sense either if there is a possibility where someone might > need more than two groups. > > Ok, heres what you need to do so we can move on (I have about a million other comments on the model draft. I am also eagerly awaiting a response on the metadata from moons ago to be responded to). 1)I honestly dont think "redirector" is the right noun. If you insist on using it, please explain the current common usage of the term and the generalization of it. Probably something with the word "mux" in it would be useful. I think another term that needs to be scrubbed/defined is the "port" into/outof the LFB 2)If you insist on using "output groups" and "ports" (both of which i dont like) then you need to strengthen your text in a big way. I apologize for bringing this up again: As an example since you are struggling to find an example for more than two port groups, you clearly have no need for more than two - i would like to point out (again!) that you dont need more than one, and that if you dont need more than one, then you dont need the term "group". I should add, however, i am willing to live with for a middle ground good text explaining these details. Sorry, cant come up with non-biased text; so i will leave that to you hoping you understand my view. > The model document is intended to allow flexibility in > implementations - this was one of the explicit requirements on the model > document. It is possible that no implementation will support all of the > flexibility and extensibility spelled out by the model document. > Its clearly not flexible enough if i am trying hard to fit myself within it;-> I think the model is fine to capture all sorts of ideas, but the basics must be right. The outputs and inputs are basic.[1] cheers, jamal [1]Theres a lot of stuff i am throwing out or ignoring because the model is trying to cover everything under the sun. Example i wouldnt give a rats ass about inheritance of LFBs. I am sure someone with a product or trying to get a phd thesis would disagree. I am just being practical. From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Fri May 14 10:28:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25371 for ; Fri, 14 May 2004 10:28:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdfQ-0004Ro-W3 for forces-archive@ietf.org; Fri, 14 May 2004 10:28:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdea-0003wb-00 for forces-archive@ietf.org; Fri, 14 May 2004 10:27:12 -0400 Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx with esmtp (Exim 4.12) id 1BOddR-0003Qp-00 for forces-archive@IETF.ORG; Fri, 14 May 2004 10:26:01 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <6.004A1F0A@grape.ease.lsoft.com>; Fri, 14 May 2004 10:26:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16602765 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 May 2004 10:26:00 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 May 2004 10:15:52 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051407200358:3485 ; Fri, 14 May 2004 07:20:03 -0700 References: <5.1.0.14.0.20040428094440.02467df8@localhost> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <2AF68A477DD44C4EBCBE338C24E7A9EE5C42CB@orsmsx408.jf.intel.com> <5.1.0.14.0.20040428094440.02467df8@localhost> <5.1.0.14.0.20040429100859.0222b6f8@localhost> <1083522049.1683.257.camel@jzny.localdomain> <409690FC.1000904@idt.com> <1083638378.1039.63.camel@jzny.localdomain> <4097F072.3050409@idt.com> <1083768015.1022.136.camel@jzny.localdomain> <409906C1.5060000@idt.com> <1083781717.1022.780.camel@jzny.localdomain> <40994C65.2030507@idt.com> <1083937252.1034.118.camel@jzny.localdomain> <409FB785.2010005@idt.com> 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 05/14/2004 07:20:03 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/14/2004 07:20:05 AM, Serialize complete at 05/14/2004 07:20:05 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1084540211.1036.178.camel@jzny.localdomain> Date: Fri, 14 May 2004 10:15:49 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata WAS(Re: Revised LFB input/output text Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <409FB785.2010005@idt.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Mon, 2004-05-10 at 13:10, Alan DeKok wrote: > Jamal Hadi Salim wrote: > > Like i said it makes sense technically. I am probably just blocking my > > mind from accepting it a) because its new approach - preference to play > > it safe comes first. > > "Play it safe", how? Calling something a MUX is describing what it > does, independent of where it exists in the network. > The problem is people are used to certain terminology. Playing it safe is sticking to such terminology. To change it (even when it makes sense such as in some of the cases in the LFB) requires indoctrination. None of that indoctrination has happened - otherwise we wouldnt be debating ;-> > Which is why my metadata draft was using vocabulary like "internal > metadata". It's clearly not outside of the LFB, but *something* > logically exists, and we need a name for it. Calling it "metadata" > outside of the LFB, and "a decision" inside of the LFB is awkward. Metadata is such a generic term that it may end being confusing. People are used to describing things in a certain way. Refer to my comments about indoctrination requirements above to make the concept a success. > Even when an LFB produces metadata externally, there *must* be some > internal representation of it, before it's produced. Why not call it > "metadata" ? I am not against the idea. I just think its too revolutionary. Humans like evolutions better. > Could you post your question again? I think I lost it... I think the thread starts here: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0403&L=forces&T=0&F=&S=&P=2267 I will read it again and see if it is indeed the right one. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri May 14 10:28:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25399 for ; Fri, 14 May 2004 10:28:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOdfV-0004SU-Ds for forces-archive@ietf.org; Fri, 14 May 2004 10:28:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdef-0003xH-00 for forces-archive@ietf.org; Fri, 14 May 2004 10:27:18 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BOddY-0003SQ-00 for forces-archive@IETF.ORG; Fri, 14 May 2004 10:26: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.00DAAAE7@cherry.ease.lsoft.com>; Fri, 14 May 2004 10:26:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16602787 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 May 2004 10:26:07 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 May 2004 10:15:55 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051407200704:3486 ; Fri, 14 May 2004 07:20:07 -0700 References: <468F3FDA28AA87429AD807992E22D07EFA1CDE@orsmsx408.jf.intel.com> 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 05/14/2004 07:20:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/14/2004 07:20:08 AM, Serialize complete at 05/14/2004 07:20:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1084540533.1036.186.camel@jzny.localdomain> Date: Fri, 14 May 2004 10:15:53 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: output port groups WAS(Re: Revised LFB input/output text Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07EFA1CDE@orsmsx408.jf.intel.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Wed, 2004-05-12 at 12:35, Deleganes, Ellen M wrote: > I should have been clearer in the first paragraph. In the last sentence > what I really meant to say is: I don't believe the FE model intends to > disallow an implementation from specifying multiple singleton outputs. I > view the output group as a convenient concept or notation, to describe > multiple outputs with similar characteristics. Whether an array is used > to specify the members of the group or individual names are given to > each singleton output is completely up to the implementer. It doesn't > take that much imagination to see that individual outputs within an > output group could be specified as individual units. It is slightly more > difficult to determine which outputs have enough in common to put into a > group, and the model team is attempting to describe when it is > appropriate to group outputs. The logic doesnt make sense. Lets see: You create something called a output group and then by induction logic create even more extensions to it. Somehow you overlooked if there was a requirement for it to begin with? Why is this an afterthought? The problem is i actually think you have a reason for it - which maybe implementation specific. I wish you would come out and describe what it is because you are not making any progress convincing me (Neither I convincing you). cheers, jamal > Regards, > Ellen > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Friday, May 07, 2004 6:41 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: output port groups WAS(Re: Revised LFB input/output text > > On Thu, 2004-05-06 at 11:47, Deleganes, Ellen M wrote: > > > > An output group can be decomposed into multiple singleton > outputs > > in an implementation. The output groups are a convenient modeling > > concept to group logically similar outputs from a single LFB together. > > An implementation could either describe the outputs using a group > > notation or as individual outputs if it desires, I don't see why the > FE > > model disallows the multiple singleton output method. > > > > [..] > > > I can't think of a specific example offhand either, but someone > > might. Setting an artificial limit when it doesn't simplify anything > > doesn't make sense either if there is a possibility where someone > might > > need more than two groups. > > > > > > Ok, heres what you need to do so we can move on (I have about a million > other comments on the model draft. I am also eagerly awaiting a response > on the metadata from moons ago to be responded to). > > 1)I honestly dont think "redirector" is the right noun. If you insist > on using it, please explain the current common usage of the term and the > generalization of it. Probably something with the word "mux" in it would > be useful. I think another term that needs to be scrubbed/defined > is the "port" into/outof the LFB > > 2)If you insist on using "output groups" and "ports" (both of which i > dont like) then you need to strengthen your text in a big way. > I apologize for bringing this up again: As an example since you are > struggling to find an example for more than two port groups, you clearly > have no need for more than two - i would like to point out (again!) that > you dont need more than one, and that if you dont need more than one, > then you dont need the term "group". I should add, however, i am willing > to live with for a middle ground good text explaining these details. > Sorry, cant come up with non-biased text; so i will leave that to you > hoping you understand my view. > > > The model document is intended to allow flexibility in > > implementations - this was one of the explicit requirements on the > model > > document. It is possible that no implementation will support all of > the > > flexibility and extensibility spelled out by the model document. > > > > Its clearly not flexible enough if i am trying hard to fit myself within > it;-> I think the model is fine to capture all sorts of ideas, but the > basics must be right. The outputs and inputs are basic.[1] > > cheers, > jamal > > [1]Theres a lot of stuff i am throwing out or ignoring because the model > is trying to cover everything under the sun. > Example i wouldnt give a rats ass about inheritance of LFBs. I am sure > someone with a product or trying to get a phd thesis would disagree. I > am just being practical. From owner-forces@PEACH.EASE.LSOFT.COM Fri May 14 17:27:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29005 for ; Fri, 14 May 2004 17:27:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOkD8-0002pD-HY for forces-archive@ietf.org; Fri, 14 May 2004 17:27:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkC8-0002LY-00 for forces-archive@ietf.org; Fri, 14 May 2004 17:26:17 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BOkB6-0001hu-00 for forces-archive@IETF.ORG; Fri, 14 May 2004 17:25:12 -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 <15.00DABD9B@cherry.ease.lsoft.com>; Fri, 14 May 2004 17:25:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 16655173 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 May 2004 17:25:10 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 May 2004 17:23:44 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6955073 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 14 May 2004 17:23:43 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <468F3FDA28AA87429AD807992E22D07EFA1CDE@orsmsx408.jf.intel.com> <468F3FDA28AA87429AD807992E22D07EFA1CDE@orsmsx408.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040514171749.0237bc08@localhost> Date: Fri, 14 May 2004 17:23:14 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: output port groups WAS(Re: Revised LFB input/output text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1084540533.1036.186.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Would it sufficiently address your concerns if in the definition of the rules for LFB class definition (the schema for the LFB class XML) for output ports from an LFB, the definition allowed any number of named singleton output ports, and only allowed up to one named output port group? Would you like a similar restriction on the definition for the input side? If that would leave you significantly more comfortable, I am willing to accept that. Yours, Joel M. Halpern PS: Just to be clear, I do not think that the protocol or the LFB class schema will be more complex if we allow multiple groups. Since the LFB class definition will only be more complex it actually uses multiple output groups, I would prefer that the schema allowed for that. However, since it seems likely that LFB classes which should use multiple groups are rare, I can live without the capability. At 10:15 AM 5/14/2004 -0400, Jamal Hadi Salim wrote: >On Wed, 2004-05-12 at 12:35, Deleganes, Ellen M wrote: > > I should have been clearer in the first paragraph. In the last sentence > > what I really meant to say is: I don't believe the FE model intends to > > disallow an implementation from specifying multiple singleton outputs. I > > view the output group as a convenient concept or notation, to describe > > multiple outputs with similar characteristics. Whether an array is used > > to specify the members of the group or individual names are given to > > each singleton output is completely up to the implementer. It doesn't > > take that much imagination to see that individual outputs within an > > output group could be specified as individual units. It is slightly more > > difficult to determine which outputs have enough in common to put into a > > group, and the model team is attempting to describe when it is > > appropriate to group outputs. > >The logic doesnt make sense. Lets see: >You create something called a output group and then by induction logic >create even more extensions to it. Somehow you overlooked if there was a >requirement for it to begin with? Why is this an afterthought? > >The problem is i actually think you have a reason for it - which maybe >implementation specific. I wish you would come out and describe what it >is because you are not making any progress convincing me (Neither I >convincing you). > > >cheers, >jamal From vmp_press@mail.com Sat May 29 19:28:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27883 for ; Sat, 29 May 2004 19:28:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUDG4-0005ys-Ok for forces-archive@ietf.org; Sat, 29 May 2004 19:28:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUDEd-0005Xt-00 for forces-archive@ietf.org; Sat, 29 May 2004 19:27:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUDDf-0005Bn-00; Sat, 29 May 2004 19:26:27 -0400 Received: from [200.61.188.90] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BUDDQ-0000y7-9i; Sat, 29 May 2004 19:26:20 -0400 From: "Atualidade Brasileira . fmn" To: edu-discuss-admin@ietf.org Subject: Revolução de 64 e esquecimento . ivu X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 29 May 2004 19:26:20 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.8 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora

(ref.:ixk) Aos caros amigos, aguardando, se possível, vossa valiosa opinião. Atenciosamente, Ferreira-Passos, Atualidade Brasileira.

Lindenberg:LinkToFreeTranslator (English, Español, Deutsche, Français, etc.)

Série Temas Patrulhados (7)

A Revolução de 64 e o esquecimento de sua razão de ser

No 40o. aniversário, o levantamento cívico-militar foi largamente comentado, mas a sua causa profunda, inexplicavelmente omitida, afirma Lindenberg

* No 40o. aniversário da Revolução de 31 de março de 1964, que depôs o presidente esquerdista João Goulart, o histórico episódio foi comentado, discutido e esmiuçado em dezenas de artigos e livros, a causa principal do movimento de 64 foi silenciada de maneira quase unânime por seus detratores, e também por não poucos de seus simpatizantes, constata Adolpho Lindenberg em artigo da Série Temas Patrulhados.

* Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

* Neste artigo sobre a Revolução de 64, o autor explica que a sua causa profunda esteve nos rumos cada vez mais esquerdizantes do governo Goulart e na crescente reação do povo brasileiro contra tais rumos; e que as Marchas da Família com Deus e pela Liberdade expressaram bem a inconformidade não somente da classe média, mas da grande maioria da população brasileira para com a comunização do país (SolicitoGratuitamenteEsteArtigoCompleto).

* Se a Revolução não tivesse ocorrido, tudo indica que nosso país teria evoluído para um regime socialista, à semelhança da Cuba castrista, ou do Chile de Allende, continua o autor, acrescentando que as "reformas de base", incluindo uma radical reforma agrária, a política de estatizações e a "demonização" dos Estados Unidos, teriam sido apenas os passos iniciais de um vasto programa de socialização do país.

* Tudo isso, não só com o apóio das lideranças mais radicais, mas também com as "bênçãos" da chamada "esquerda católica". É o que se depreende da ideologia e das metas de figuras exponenciais da era janguista, a começar pelo próprio presidente Goulart, mas também por figuras civis e eclesiásticas de destaque na época, como Leonel Brizola, dom Hélder Câmara, Francisco Julião e outros.

* Pelo inegável apoio e participação de todas as camadas da população com que contou, a Revolução de 64 não pode ser reduzida a um "golpe militar", como pretendem as esquerdas, nem tampouco identificada inteiramente com os rumos e atos do regime militar que lhe sucedeu, ou desqualificada pelos censuráveis atos de torturas acontecidos durante esse regime.

* Entre outros esquecimentos a respeito da Revolução de 64, o articulista constata que os analistas brasileiros que neste 40o. aniversário abordaram o tema, não fizeram sequer uma referência ao papel fundamental do movimento Tradição, Família, Propriedade na criação do clima ideológico e psicológico, na opinião pública brasileira e católica, que levou à Revolução de 64 (EnviarGratuitamenteInfoTFP-Revolução64). O referido silêncio - talvez se pudesse falar até de "patrulhamento" - contrasta com diversos estudos de "brasilianistas" estrangeiros publicados ao longo dos anos, muitos deles de esquerda, que tiveram a honestidade intelectual de reconhecer esse papel fundamental da TFP (EnviarGratuitamenteInfoBrasilianistas ).

* A difusão do livro "Reforma Agrária - Questão de Consciência", escrito por Plinio Corrêa de Oliveira em colaboração com dois bispos e um economista, e as públicas polêmicas dessa entidade com membros da ala esquerda do episcopado e da Ação Católica, tiveram tal relevância que a elas aludiu o presidente Goulart, em tom amargo, em discurso televisionado ao País, um dia antes de sua queda (EnviarGratuitamenteDiscursoGoulart).

* O esquecimento da causa profunda e do contexto histórico nacional em que se deu a Revolução de 64 poderá trazer sérios prejuízos à chamada "memória histórica" do Brasil, pois as novas gerações se verão afetadas por uma espécie de "lacuna" ou "amnésia" a respeito desse período, ou, na melhor das hipóteses, passarão a serem (des)informadas por uma visão profundamente distorcida desse processo, conclui Lindenberg.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EnviarEsteArtigoCompletoGratuitamente(No.7)

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática da Revolução de 64 abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873