From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 1 10:35: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 KAA29153 for ; Sun, 1 Feb 2004 10:35:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJXB-0001sh-00 for forces-archive@ietf.org; Sun, 01 Feb 2004 10:29:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnJUZ-000130-00 for forces-archive@ietf.org; Sun, 01 Feb 2004 10:26:39 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AnJIy-000591-00 for forces-archive@IETF.ORG; Sun, 01 Feb 2004 10:14:36 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CC7CA6@cherry.ease.lsoft.com>; 1 Feb 2004 10:14:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 205943 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 1 Feb 2004 10:14:34 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 1 Feb 2004 10:14:34 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004020107153476:21139 ; Sun, 1 Feb 2004 07:15:34 -0800 References: <1074874628.2805.22.camel@empress.torrentnet.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 02/01/2004 07:15:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/01/2004 07:15:36 AM, Serialize complete at 02/01/2004 07:15:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1075648470.1034.335.camel@jzny.localdomain> Date: Sun, 1 Feb 2004 10:14:30 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Metadata model for the ForCES model Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1074874628.2805.22.camel@empress.torrentnet.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: 7bit Hi Zsolt, Some comments: + I think with FE-FE metadata we are now treading into FE-FE domain. I have no problem with this, at least the model related to the metadata would be good to see in the draft. A lot of chip vendors (and box vendors) already have protocols implementing interFE metadata transfers as proprietary - they call them "stacking protocols" (typically attached to a frame). While it may be too early to get involved in such a beast, i think it should be put into consideration (it is only mentioned in passing). I had a conversation on this in MPLS with Alan Dekok and wouldnt mind coauthoring a draft with interested people. + The first 3 sections are well written Theres a claim that register based metadata is "more efficient". This claim is not substantiated in any text. Also not sure why a scheme on how metadata is _implemented_ needs to be mentioned in a model. Metadata "moves" with the packet. Model shouldnt care how. + section 4 The Proposed Metadata Model - I think a TLV with flags would be appropriately model metadata. [tag = type; split the type bits into some 4 bits for flags] I also think there is no reason to limit the length to 32 bits hence the reason a TLV would be a good represantation. + section 5 Metadata Production and Consumption "There may be multiple consumers for the same metadata" is repeated twice. - wasnt clear on the "conditional" aspect of metadata; could you provide a real example? + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata Production Isnt the tag selector itself metadata? I think starting this section you may be treading into implementation specifics. An LFB should be able to receive a number of metadata and ignore some of them either based on LFB config or a metadata-selector passed with the packet. +section 9 Metadata Usage Categories - "this value also is the value what the metadata carries between the LFBs" ^^^^ ----> should be "that" - "Another way of setting up binding relations is when a naturally occurring unique identifier of the consumer's object" What is the event that would cause this? Is it a packet arrival or a CE reading something off the FE? - "is used as a reference (and as a value" ---> you need to close the brackets - "definiton" typo - "The value of the enumerated metadata may or may not be conveyed via the ForCES protocol between the CE and FE." Didnt grasp that. How are LFBs on an FE supposed to cooperate on values of metadata if they are not synced in this case? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 16:15: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 QAA03467 for ; Tue, 3 Feb 2004 16:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7tY-00067u-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 16:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7sg-00061q-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 16:14:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7s0-0005vW-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 16:14:08 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CCBF1E@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 16:14:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 649414 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 16:14:06 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 16:14:06 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i13LE1J19972; Tue, 3 Feb 2004 16:14:01 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i13LE1v64694; Tue, 3 Feb 2004 16:14:01 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id i13LDx300146; Tue, 3 Feb 2004 16:13:59 -0500 (EST) References: <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1075842838.8133.203.camel@empress.torrentnet.com> Date: Tue, 3 Feb 2004 16:13:59 -0500 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: Re: Metadata model for the ForCES model Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1075648470.1034.335.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, Thanks for your valuable comments. See my replies embedded. On Sun, 2004-02-01 at 10:14, Jamal Hadi Salim wrote: > Hi Zsolt, > > Some comments: > > + I think with FE-FE metadata we are now treading into FE-FE > domain. I have no problem with this, at least the model related to the > metadata would be good to see in the draft. A lot of chip vendors (and > box vendors) already have protocols implementing interFE metadata > transfers as proprietary - they call them "stacking protocols" > (typically attached to a frame). While it may be too early to get > involved in such a beast, i think it should be put into consideration > (it is only mentioned in passing). Good comment. The consideration I had was that we nail down an LFB-to-LFB communication model which should be independent of whether the communicating LFBs are on the same FE or on two or more separate FEs. This model does not specify how the communication happens, it only says that if we want to define LFB classes and program LFBs instance via the ForCES protocol, this is how we have to think about passing per-packet state from one LFB to another. So, so far the model text leaves the actual implementation of LFB-to-LFB communication completely open (well, the ForCES model does not ever require that LFBs within an FE are implemented as distinct processing stages...). Within an FE I expect that the vendors will always have infinite freedom how the ForCES model is realized. Between FEs's, however, the model does put some requirements on the implementation. At the minimum, it implies that a certain set of information (i.e., the set of metadata that is present at the exit point on FE1 and needed for further processing on FE2) must be passed _in some way_ between the two FEs. How it is passed is left to the vendors at this point. One can speculate that many vendors would benefit from something less proprietary, so I expect that ForCES will eventually start working on that area. When the work starts, it will have to take this metadata model into consideration. > I had a conversation on this in MPLS > with Alan Dekok and wouldnt mind coauthoring a draft with interested > people. I'm sure it will be useful. Let me know if I can help. > > + The first 3 sections are well written > Theres a claim that register based metadata is "more efficient". This > claim is not substantiated in any text. Also not sure why a scheme > on how metadata is _implemented_ needs to be mentioned in a model. > Metadata "moves" with the packet. Model shouldnt care how. OK, the text was written with the primary intent to drive the metadata discussion to a conclusion (first within the model team, then within the ForCES WG), and with the secondary intent to offer text fragments to the new revision of the model draft. But I expect only a portion of this text will go into the revised draft. Much of the motivation/justification text, including the above, will probably not make it. > > + section 4 The Proposed Metadata Model > > - I think a TLV with flags would be appropriately model metadata. > [tag = type; split the type bits into some 4 bits for flags] Your thinking may be to protocol driven. Again, this model--so far-- is mainly to describe a reference model w.r.t. how data passing should be envisioned when defining LFBs, their attributes, and the CE-FE protocol communication. It is not about how to actually pass metadata among LFBs. For the above (reduced) scope, it has some benefits to regard most metadata values as 32 bit integers. BTW, what is the intended usage of the flags? > I also think there is no reason to limit the length to 32 bits > hence the reason a TLV would be a good represantation. See my comments above. > > + section 5 Metadata Production and Consumption > "There may be multiple consumers for the same metadata" > is repeated twice. > - wasnt clear on the "conditional" aspect of metadata; could you provide > a real example? I do not have very strong examples to support this. What I had in mind was cases when the need for a metadata depends on the value of another metadata. For example, one metadata is a RESULTKEY, and another is an ERRORCODE. RESULTKEY is normally used to encode the result of an operation (e.g., a search in a table), and a special value (0) encodes the lack of result. When RESULTKEY=0, then ERRORCODE tells more about the reason of the miss. When RESULTKEY!=0, then ERRORCODE is meaningless, so it can be omitted. I know that this can be done in other ways (embedding the error codes into the RESULTKEY value space; or making ERRORCODE mandatory, but ignore it in downstream LFBs if RESULTKEY!=0, etc.) Once we go through the exercise of creating a library of fully defined LFBs and putting together useful configurations we may conclude that there is no need for this feature. Then we can pull this out. Until then, I left it in a space-holder. But I can be convinced... > > + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata > Production > > Isnt the tag selector itself metadata? I think starting this section > you may be treading into implementation specifics. I am disconnected here. Consider an Re-director LFB that can be instantiated to split traffic into multiple streams based on some input metadata. For example, one instance splits based on a classifier key (CLASSID), another splits based on COLOR, a third based on protocolo type (PROTO). This will be realized by an LFB class that will have the following features (simplistic approach): 1) Variable number of outputs 2) An attribute that tells the LFB which metadata tag to look for 3) A table of entries, where each entry will contain a metadata value (as a condition), and a port reference (where to send the packet). So the selector is an attribute of the LFB, read (or possibly written) by the CE via the ForCES protocol. The metadata values of the table entries should be generic enough to accommodate (almost) arbitrary metadata. I see a benefit to make such a field in the table entry a 32-bit integer field (which would serve 95% of the expected metadata types based on our pre-study); that is what motivates to have a generic data type for most metadata. > An LFB should be able to receive a number of metadata and ignore some of > them either based on LFB config or a metadata-selector passed with the > packet. The LFB will use all metadata that is either specified in the LFB specification (XML document) or referred by one of the input metadata tag-selectors. The latter is only applicable to LFB classes that use variable/configurable tag selection. All other metadata will be ignored by the LFB. > > +section 9 Metadata Usage Categories > - "Another way of setting up binding relations is when a > naturally occurring unique identifier of the consumer's object" > What is the event that would cause this? Is it a packet arrival or > a CE reading something off the FE? Let me illustrate what I meant here with an example: Lets say the consumer LFB has a table of things. You may insert a new entry in the table. The operation returns with a table entry index, which can be used in subsequent incremental table management. In the same time, the index can also be used as a way to refer to the given entry from another LFB. E.g, when an upstream LFB wants to refer to one of the table entries, it can send the index in a well-defined metadata. That index is what I consider "naturally occuring," meaning that it exists anyway and it can also be used as a binding metadata. So to answer the original question: the event is a configuration event on the LFB by the CE. > - "The value of the enumerated metadata may or may not be conveyed > via the ForCES protocol between the CE and FE." > > Didnt grasp that. How are LFBs on an FE supposed to cooperate on values > of metadata if they are not synced in this case? Consider a Rate Meter LFB that emits COLOR as metadata. Consider a downstream Rate Meter LFB that uses the COLOR metadata to do further rate metering. To neither of the LFB instances would we ever communicate COLOR as part of the CE-FE communication. It is all built in in the specification of the LFB class and the specification of the COLOR metadata. So this is an example when the enumerated metadata is not conveyed between the CE and FE. Consider now the same Rate Meter LFB emitting the COLOR and a downstream Redirector LFB set up to split the traffic into three paths based on the COLOR. When configuring the Redirector LFB, we would have to tell the LFB to 1) Listen to COLOR metadata 2) Go to port 1, if COLOR=RED, port 2 if YELLOW, and port 3 if GREEN. So in this case we would explicitly convey colors (COLOR values) across the CE-FE interface. > > cheers, > jamal > Thanks for taking your time for going through this. /zsolt > From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 16:57: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 QAA07650 for ; Tue, 3 Feb 2004 16:57:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8YC-00050I-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 16:57:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8XK-0004us-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 16:56:51 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8X1-0004og-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 16:56:31 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00CCC0D4@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 16:56:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 654602 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 16:56:30 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 16:56:30 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6162708 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 16:56:27 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20040203165405.01ac1948@localhost> Date: Tue, 3 Feb 2004 16:56:05 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1075842838.8133.203.camel@empress.torrentnet.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=none autolearn=no version=2.60 Interesting. I had not read your meta-data description as addressing that. I had assumed that the only reason for talking about FE-FE level meta-data was to make clear it was out of scope. Since packets leaving an FE are presumed to be IP packets, I would expect normally want those to be just plain vamilla IP packets. Some implementations may use the available information to try to do something extra. That has been true of all routers. But I would not expect it to be within scope for ForCES. Yours, Joel M. Halpern At 04:13 PM 2/3/2004 -0500, Zsolt Haraszti wrote: >The consideration I had was that we nail down an >LFB-to-LFB communication model which should be independent of >whether the communicating LFBs are on the same FE or on two or more >separate FEs. This model does not specify how the communication >happens, it only says that if we want to define LFB classes and program >LFBs instance via the ForCES protocol, this is how we have to think >about passing per-packet state from one LFB to another. So, so far >the model text leaves the actual implementation of LFB-to-LFB >communication completely open (well, the ForCES model does not ever >require that LFBs within an FE are implemented as distinct processing >stages...). > >Within an FE I expect that the vendors will always have infinite >freedom how the ForCES model is realized. > >Between FEs's, however, the model does put some requirements on the >implementation. At the minimum, it implies that a certain set of >information (i.e., the set of metadata that is present at the >exit point on FE1 and needed for further processing on FE2) must be >passed _in some way_ between the two FEs. How it is passed is left >to the vendors at this point. One can speculate that many vendors >would benefit from something less proprietary, so I expect that >ForCES will eventually start working on that area. When the work >starts, it will have to take this metadata model into consideration. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 17:17: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 RAA08457 for ; Tue, 3 Feb 2004 17:17:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8rg-00076B-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 17:17:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8qY-0006ux-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 17:16:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8pu-0006po-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 17:16:02 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00CCC300@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 17:16:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 656314 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 17:16:01 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 17:16:01 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i13MFxR23729; Tue, 3 Feb 2004 17:15:59 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i13MFvJ69768; Tue, 3 Feb 2004 17:15:57 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA21041; Tue, 3 Feb 2004 17:15:55 -0500 (EST) References: <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Steven Blake Message-ID: <1075846555.18290.174.camel@newcastle.torrentnet.com> Date: Tue, 3 Feb 2004 17:15:55 -0500 Reply-To: Steven Blake Sender: Forwarding and Control Element Separation From: Steven Blake Organization: Ericsson IP Infrastructure Subject: Re: Metadata model for the ForCES model Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040203165405.01ac1948@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.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote: > Interesting. I had not read your meta-data description as addressing that. > I had assumed that the only reason for talking about FE-FE level meta-data > was to make clear it was out of scope. Since packets leaving an FE are > presumed to be IP packets, I would expect normally want those to be just > plain vamilla IP packets. > Some implementations may use the available information to try to do > something extra. That has been true of all routers. But I would not > expect it to be within scope for ForCES. Ingress FE X receives packet, performs forwarding lookup, determines packet should exit node on output interface Z on FE Y, via nexthop W. Packet is forwarded to from FE X to Y. How does FE Y determine Z & W? o Y performs duplicate forwarding lookup o Y uses metadata passed from FE X to convey Z & W. Either case involves CE-FE configuration on Y. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 17:30: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 RAA09729 for ; Tue, 3 Feb 2004 17:30:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao942-0001Pq-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 17:30:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao939-0001L5-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 17:29:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ao92Q-0001G3-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 17:28:59 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CCC1AB@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 17:28:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 656282 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 17:28:50 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 17:27:10 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6162813 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 17:25:23 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20040203171927.01adfc50@localhost> Date: Tue, 3 Feb 2004 17:25:01 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1075846555.18290.174.camel@newcastle.torrentnet.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=none autolearn=no version=2.60 Given that the Fi reference point is explicitly outside of scope ("is not currently defined by the ForCES architecture"), I had assumed that for now the only choice was for FE Y to perform a duplicate lookup. Or, to phrase it differently, I would say that under the current environment FE X would determine that its next hop is FE Y, and FE Y would determine that its next hop is W. It is certainly true that this requires CE configuration of FE X and FE Y. But it does not require or expect any metadata to be passed from FE X to FE Y. In general, given that Fi is outside of scope, I think of all traffic to another FE as if it were to another NE. Yours, Joel M. Halpern At 05:15 PM 2/3/2004 -0500, Steven Blake wrote: >On Tue, 2004-02-03 at 16:56, Joel M. Halpern wrote: > > > Interesting. I had not read your meta-data description as addressing that. > > I had assumed that the only reason for talking about FE-FE level meta-data > > was to make clear it was out of scope. Since packets leaving an FE are > > presumed to be IP packets, I would expect normally want those to be just > > plain vamilla IP packets. > > Some implementations may use the available information to try to do > > something extra. That has been true of all routers. But I would not > > expect it to be within scope for ForCES. > >Ingress FE X receives packet, performs forwarding lookup, determines >packet should exit node on output interface Z on FE Y, via nexthop W. >Packet is forwarded to from FE X to Y. How does FE Y determine Z & W? >o Y performs duplicate forwarding lookup >o Y uses metadata passed from FE X to convey Z & W. > >Either case involves CE-FE configuration on Y. > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure +1 919-472-9913 From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 20:15: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 UAA15877 for ; Tue, 3 Feb 2004 20:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoBdo-00028h-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 20:15:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoBcw-000249-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 20:14:50 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoBcR-0001z0-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 20:14:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CCC5ED@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 20:14:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672198 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 20:14:10 -0500 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 20:14:10 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i141Rcep010084 for ; Wed, 4 Feb 2004 02:27:40 +0100 Mime-Version: 1.0 (Apple Message framework v609) References: <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.609) Approved-By: avri@ACM.ORG Message-ID: <680E96E6-56AF-11D8-9657-000393CC2112@acm.org> Date: Wed, 4 Feb 2004 10:13:57 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040203171927.01adfc50@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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On 2004-02-04, at 07.25, Joel M. Halpern wrote: > In general, given that Fi is outside of scope, I think of all traffic > to > another FE as if it were to another NE. > Wouldn't that violate the rule that an NE, no matter how many parts it is composed of, should appear to be a single entity. If we assume that FE-FE messaging is normal IP as if it were NE-NE then we may have problems meeting that requirement. I agree the current charter prohibits making FE-FE protocols a work item, but I don't think that eliminates the need for implementations to have a solution other then the passing of straight IP packets. Including a metadata model that covers this seems like a good idea. Personally I am glad someone is working on it. I know I am more concerned with the WG getting the model right then worrying about specific protocol implementations. a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 20:24: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 UAA16031 for ; Tue, 3 Feb 2004 20:24:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoBmY-0002s9-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 20:24:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoBlX-0002n6-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 20:23:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoBkb-0002iQ-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 20:22:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CCC63E@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 20:22:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672590 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 20:22:30 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 20:22:30 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6163179 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 20:22:28 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20040203201908.01ad5298@localhost> Date: Tue, 3 Feb 2004 20:22:05 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <680E96E6-56AF-11D8-9657-000393CC2112@acm.org> 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 I do not believe that would violate single system appearence at all. Appearing as a single system is a matter of management protocol interactions and routing protocol advertisements. It has nothing to do with the packets flowing between FEs. Yours, Joel M. Halpern At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >On 2004-02-04, at 07.25, Joel M. Halpern wrote: > >>In general, given that Fi is outside of scope, I think of all traffic >>to >>another FE as if it were to another NE. > >Wouldn't that violate the rule that an NE, no matter how many parts it >is composed of, should appear to be a single entity. If we assume that >FE-FE messaging is normal IP as if it were NE-NE then we may have >problems meeting that requirement. > >I agree the current charter prohibits making FE-FE protocols a work >item, but I don't think that eliminates the need for implementations to >have a solution other then the passing of straight IP packets. >Including a metadata model that covers this seems like a good idea. >Personally I am glad someone is working on it. I know I am more >concerned with the WG getting the model right then worrying about >specific protocol implementations. > >a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 21:05: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 VAA17117 for ; Tue, 3 Feb 2004 21:05:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoCQF-0006U3-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 21:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCPX-0006P2-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 21:05:04 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoCOw-0006Jv-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 21:04:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00CCC5FA@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 21:04:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676404 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 21:04:24 -0500 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 21:04:24 -0500 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i142Hpep010149 for ; Wed, 4 Feb 2004 03:17:53 +0100 Mime-Version: 1.0 (Apple Message framework v609) References: <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203201908.01ad5298@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.609) Approved-By: avri@ACM.ORG Message-ID: <7056F02A-56B6-11D8-9657-000393CC2112@acm.org> Date: Wed, 4 Feb 2004 11:04:17 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040203201908.01ad5298@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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Well, if IP is used between FEs, without any metadata in the exchange, then wouldn't it involve forwarding as it it were a hop? And while it is true that the receiving FE could treat the packet specially and not modify the packet based on the extra hop, this would involve implicit 'metadata' that this wasn't being forwarded from outside the NE and not as if between NEs. Also, wouldn't there be a concern with the assignment of IP addresses to each of the FEs. Or would this be done based on some internal private IP address space. Maybe I don't really understand what you mean when you say an FE passes a packet to another FE as if it were being passed to another NE. a. On 2004-02-04, at 10.22, Joel M. Halpern wrote: > I do not believe that would violate single system appearence at all. > Appearing as a single system is a matter of management protocol > interactions and routing protocol advertisements. It has nothing to do > with the packets flowing between FEs. > > Yours, > Joel M. Halpern > > At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >> >>> In general, given that Fi is outside of scope, I think of all traffic >>> to >>> another FE as if it were to another NE. >> >> Wouldn't that violate the rule that an NE, no matter how many parts it >> is composed of, should appear to be a single entity. If we assume >> that >> FE-FE messaging is normal IP as if it were NE-NE then we may have >> problems meeting that requirement. >> >> I agree the current charter prohibits making FE-FE protocols a work >> item, but I don't think that eliminates the need for implementations >> to >> have a solution other then the passing of straight IP packets. >> Including a metadata model that covers this seems like a good idea. >> Personally I am glad someone is working on it. I know I am more >> concerned with the WG getting the model right then worrying about >> specific protocol implementations. >> >> a. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 21:27: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 VAA18362 for ; Tue, 3 Feb 2004 21:27:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoClh-0001me-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 21:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCkn-0001eu-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 21:27:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoCkE-0001Yg-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 21:26:26 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CCC57A@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 21:26:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 677246 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 21:26:26 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 21:26:26 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6163275 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 21:26:23 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203201908.01ad5298@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <5.1.0.14.0.20040203212122.01af1d08@localhost> Date: Tue, 3 Feb 2004 21:25:59 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <7056F02A-56B6-11D8-9657-000393CC2112@acm.org> 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 There probably is an issue of hop count. Personally, I consider such double decrementing a very good idea, as it avoids accidental internal loops. Other than that, the IP addresses are just the interface IP addresses of the NE. If the links between the FEs are multi-access, they will need IP addresses. They will need them even if that network is otherwise concealed, and even if the protocol were not IP. One can craft all sorts of reasons why it might be nice to treat the Fi links differently. And later, we might choose to do so. But the topology and scope documents clearly state that we are not defining a protocol for that. And we can meet a reasonable definition of a "single system image" without defining or using a special protocol on those links. Given that the system works when we treat those links as carrying IP over BACK (ie any technology used for the interconnect which supports IP packets) it seems that we keep our work bounded and within defined scope if for now we just use that. Yours, Joel M. Halpern At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >Well, if IP is used between FEs, without any metadata in the exchange, >then wouldn't it involve forwarding as it it were a hop? And while it >is true that the receiving FE could treat the packet specially and not >modify the packet based on the extra hop, this would involve implicit >'metadata' that this wasn't being forwarded from outside the NE and not >as if between NEs. > >Also, wouldn't there be a concern with the assignment of IP addresses >to each of the FEs. Or would this be done based on some internal >private IP address space. > >Maybe I don't really understand what you mean when you say an FE passes >a packet to another FE as if it were being passed to another NE. > >a. > >On 2004-02-04, at 10.22, Joel M. Halpern wrote: > >>I do not believe that would violate single system appearence at all. >>Appearing as a single system is a matter of management protocol >>interactions and routing protocol advertisements. It has nothing to do >>with the packets flowing between FEs. >> >>Yours, >>Joel M. Halpern >> >>At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>> >>>>In general, given that Fi is outside of scope, I think of all traffic >>>>to >>>>another FE as if it were to another NE. >>> >>>Wouldn't that violate the rule that an NE, no matter how many parts it >>>is composed of, should appear to be a single entity. If we assume >>>that >>>FE-FE messaging is normal IP as if it were NE-NE then we may have >>>problems meeting that requirement. >>> >>>I agree the current charter prohibits making FE-FE protocols a work >>>item, but I don't think that eliminates the need for implementations >>>to >>>have a solution other then the passing of straight IP packets. >>>Including a metadata model that covers this seems like a good idea. >>>Personally I am glad someone is working on it. I know I am more >>>concerned with the WG getting the model right then worrying about >>>specific protocol implementations. >>> >>>a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 3 22:35:53 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 WAA20076 for ; Tue, 3 Feb 2004 22:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoDpS-0000mQ-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 22:35:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoDoZ-0000gl-00 for forces-archive@ietf.org; Tue, 03 Feb 2004 22:35:00 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoDnq-0000aW-00 for forces-archive@IETF.ORG; Tue, 03 Feb 2004 22:34:15 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00CCC749@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 22:34:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 684837 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 22:34:12 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 22:34:12 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i143YBn40098; Tue, 3 Feb 2004 22:34:11 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i143YAW92982; Tue, 3 Feb 2004 22:34:10 -0500 (EST) Received: from ericsson.com (sun01.torrentnet.com [4.18.161.124]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id i143YA719132; Tue, 3 Feb 2004 22:34:10 -0500 (EST) User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203212122.01af1d08@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <4020681A.2050007@ericsson.com> Date: Tue, 3 Feb 2004 22:33:46 -0500 Reply-To: zsolt.haraszti@ericsson.com Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Subject: Re: Metadata model for the ForCES model Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040203212122.01af1d08@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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit A couple of comments: 1. The fact is that most real distributed (multiblade) routers forward metadata from one blade (e.g., ingresss) to another (e.g., egress). This simply allows optimal distribution of processing functions across the involved FEs. Not only that they forward metadata in addition to the IP packet being sent, but it may also be that the packet is not a complete/valid IP packet. Since this is all within the node, it's all legitimate. 2. Just because it is not an IP packet or not only an IP packet, it does not mean that ForCES must include it in its scope. If it is not in the scope, so be it. Then it will be left for the vendors, or to some other standards bodies to deal with it. (FYI, the NPF is addressing the inter-FE metadata encapsulation via a messaging LFB and messaging protocol). BTW, I think the ForCES work is still very useful, even if the inter-FE messaging is not in its scope. 3. Even if the inter-FE messaging could be put into the ForCES scope, we should still ignore it for the time being, and focus on the model and the CE-FE communication. /zsolt Joel M. Halpern wrote: > There probably is an issue of hop count. Personally, I consider such > double decrementing a very good idea, as it avoids accidental internal > loops. > > Other than that, the IP addresses are just the interface IP addresses of > the NE. If the links between the FEs are multi-access, they will need IP > addresses. They will need them even if that network is otherwise > concealed, and even if the protocol were not IP. > > One can craft all sorts of reasons why it might be nice to treat the Fi > links differently. And later, we might choose to do so. But the topology > and scope documents clearly state that we are not defining a protocol for > that. And we can meet a reasonable definition of a "single system image" > without defining or using a special protocol on those links. > Given that the system works when we treat those links as carrying IP over > BACK (ie any technology used for the interconnect which supports IP > packets) it seems that we keep our work bounded and within defined scope if > for now we just use that. > > Yours, > Joel M. Halpern > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > >> Well, if IP is used between FEs, without any metadata in the exchange, >> then wouldn't it involve forwarding as it it were a hop? And while it >> is true that the receiving FE could treat the packet specially and not >> modify the packet based on the extra hop, this would involve implicit >> 'metadata' that this wasn't being forwarded from outside the NE and not >> as if between NEs. >> >> Also, wouldn't there be a concern with the assignment of IP addresses >> to each of the FEs. Or would this be done based on some internal >> private IP address space. >> >> Maybe I don't really understand what you mean when you say an FE passes >> a packet to another FE as if it were being passed to another NE. >> >> a. >> >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >> >>> I do not believe that would violate single system appearence at all. >>> Appearing as a single system is a matter of management protocol >>> interactions and routing protocol advertisements. It has nothing to do >>> with the packets flowing between FEs. >>> >>> Yours, >>> Joel M. Halpern >>> >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>> >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>> >>>>> In general, given that Fi is outside of scope, I think of all traffic >>>>> to >>>>> another FE as if it were to another NE. >>>> >>>> >>>> Wouldn't that violate the rule that an NE, no matter how many parts it >>>> is composed of, should appear to be a single entity. If we assume >>>> that >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have >>>> problems meeting that requirement. >>>> >>>> I agree the current charter prohibits making FE-FE protocols a work >>>> item, but I don't think that eliminates the need for implementations >>>> to >>>> have a solution other then the passing of straight IP packets. >>>> Including a metadata model that covers this seems like a good idea. >>>> Personally I am glad someone is working on it. I know I am more >>>> concerned with the WG getting the model right then worrying about >>>> specific protocol implementations. >>>> >>>> a. > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 4 12:33:16 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 MAA16370 for ; Wed, 4 Feb 2004 12:33:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQtp-00066V-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 12:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQsr-0005x5-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 12:32:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoQrv-0005md-00 for forces-archive@IETF.ORG; Wed, 04 Feb 2004 12:31:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00CCDAF2@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 12:31:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 782568 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 12:31:12 -0500 Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 12:31:12 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i14HVA8d013791; Wed, 4 Feb 2004 11:31:10 -0600 (CST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203212122.01af1d08@localhost> <4020681A.2050007@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Audu Message-ID: <40212C5D.D94A2F2@alcatel.com> Date: Wed, 4 Feb 2004 11:31:09 -0600 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Metadata model for the ForCES model Comments: To: zsolt.haraszti@ericsson.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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I am assuming this meta-data thing is all in context of having the CE successfully configure the FEs. Unless this requires FE-FE communication, I don't see any reasons for extending this to include FE-FE. Regards, Alex. Zsolt Haraszti wrote: > A couple of comments: > > 1. The fact is that most real distributed (multiblade) routers > forward metadata from one blade (e.g., ingresss) to another > (e.g., egress). This simply allows optimal distribution of > processing functions across the involved FEs. > Not only that they forward metadata in addition to the IP packet > being sent, but it may also be that the packet is not a > complete/valid IP packet. Since this is all within the node, > it's all legitimate. > > 2. Just because it is not an IP packet or not only an IP packet, > it does not mean that ForCES must include it in its scope. > If it is not in the scope, so be it. Then it will be left > for the vendors, or to some other standards bodies to deal > with it. (FYI, the NPF is addressing the inter-FE metadata > encapsulation via a messaging LFB and messaging protocol). > BTW, I think the ForCES work is still very useful, even if > the inter-FE messaging is not in its scope. > > 3. Even if the inter-FE messaging could be put into the ForCES > scope, we should still ignore it for the time being, and > focus on the model and the CE-FE communication. > > /zsolt > > Joel M. Halpern wrote: > > There probably is an issue of hop count. Personally, I consider such > > double decrementing a very good idea, as it avoids accidental internal > > loops. > > > > Other than that, the IP addresses are just the interface IP addresses of > > the NE. If the links between the FEs are multi-access, they will need IP > > addresses. They will need them even if that network is otherwise > > concealed, and even if the protocol were not IP. > > > > One can craft all sorts of reasons why it might be nice to treat the Fi > > links differently. And later, we might choose to do so. But the topology > > and scope documents clearly state that we are not defining a protocol for > > that. And we can meet a reasonable definition of a "single system image" > > without defining or using a special protocol on those links. > > Given that the system works when we treat those links as carrying IP over > > BACK (ie any technology used for the interconnect which supports IP > > packets) it seems that we keep our work bounded and within defined scope if > > for now we just use that. > > > > Yours, > > Joel M. Halpern > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > >> Well, if IP is used between FEs, without any metadata in the exchange, > >> then wouldn't it involve forwarding as it it were a hop? And while it > >> is true that the receiving FE could treat the packet specially and not > >> modify the packet based on the extra hop, this would involve implicit > >> 'metadata' that this wasn't being forwarded from outside the NE and not > >> as if between NEs. > >> > >> Also, wouldn't there be a concern with the assignment of IP addresses > >> to each of the FEs. Or would this be done based on some internal > >> private IP address space. > >> > >> Maybe I don't really understand what you mean when you say an FE passes > >> a packet to another FE as if it were being passed to another NE. > >> > >> a. > >> > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > >> > >>> I do not believe that would violate single system appearence at all. > >>> Appearing as a single system is a matter of management protocol > >>> interactions and routing protocol advertisements. It has nothing to do > >>> with the packets flowing between FEs. > >>> > >>> Yours, > >>> Joel M. Halpern > >>> > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > >>> > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > >>>> > >>>>> In general, given that Fi is outside of scope, I think of all traffic > >>>>> to > >>>>> another FE as if it were to another NE. > >>>> > >>>> > >>>> Wouldn't that violate the rule that an NE, no matter how many parts it > >>>> is composed of, should appear to be a single entity. If we assume > >>>> that > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have > >>>> problems meeting that requirement. > >>>> > >>>> I agree the current charter prohibits making FE-FE protocols a work > >>>> item, but I don't think that eliminates the need for implementations > >>>> to > >>>> have a solution other then the passing of straight IP packets. > >>>> Including a metadata model that covers this seems like a good idea. > >>>> Personally I am glad someone is working on it. I know I am more > >>>> concerned with the WG getting the model right then worrying about > >>>> specific protocol implementations. > >>>> > >>>> a. > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 4 12:37:13 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 MAA16680 for ; Wed, 4 Feb 2004 12:37:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQxf-0006Zw-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 12:37:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQwg-0006TZ-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 12:36:15 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoQvk-0006N0-00 for forces-archive@IETF.ORG; Wed, 04 Feb 2004 12:35:16 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00CCDA2F@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 12:35:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 782700 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 12:35:03 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 12:35:03 -0500 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i14HZ1BN020455 for ; Wed, 4 Feb 2004 17:35:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i14HZ1Zu027145 for ; Wed, 4 Feb 2004 17:35:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020409345711830 for ; Wed, 04 Feb 2004 09:34:57 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 09:34:55 -0800 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: Call for Agenda Items & Drafts, ForCES Meeting @ IETF 59 Thread-Index: AcPrRTNikjKMnVY7TrKM44P58W98Aw== X-OriginalArrivalTime: 04 Feb 2004 17:34:55.0475 (UTC) FILETIME=[34088430:01C3EB45] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8023CABA7@orsmsx409.jf.intel.com> Date: Wed, 4 Feb 2004 09:34:55 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Call for Agenda Items & Drafts, ForCES Meeting @ IETF 59 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 All, Please send me requests for agenda time at the ForCES meeting at IETF 59. If possible, also send over any presentation materials available ahead of time so that the can be made available at the ForCES website. All agenda requests should be made by Monday, February 23. The deadline for submission of new (-00) drafts is Monday, February 9th at 0900 ET. For revisions to=20 existing drafts (-01, -02, etc.), the deadline is Monday, February 16th 0900 ET. Current ForCES agenda information can be found at the ForCES website at: http://www.sstanamera.com/~forces/Ietf59/index.html Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 4 13:02:25 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 NAA17999 for ; Wed, 4 Feb 2004 13:02:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRM3-0001iH-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 13:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRLF-0001c4-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 13:01:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoRKZ-0001VH-00 for forces-archive@IETF.ORG; Wed, 04 Feb 2004 13:00:55 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CCDA32@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 13:00:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 784362 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 13:00:42 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 13:00:42 -0500 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i14I0elf012449 for ; Wed, 4 Feb 2004 18:00:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i14I1SOX005058 for ; Wed, 4 Feb 2004 18:01:35 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 M2004020410003806830 for ; Wed, 04 Feb 2004 10:00:38 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 10:00:39 -0800 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: Interim meeting update (was: FORCES] Protocol Selection Process: Merger Suggestion) Thread-Index: AcPrSMuEe4ns8VGORr+BdPb/jqS/gQ== X-OriginalArrivalTime: 04 Feb 2004 18:00:39.0125 (UTC) FILETIME=[CC1ED050:01C3EB48] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8023CABCA@orsmsx409.jf.intel.com> Date: Wed, 4 Feb 2004 10:00:38 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Interim meeting update (was: FORCES] Protocol Selection Process: Merger Suggestion) 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All,=20 After having reviewed possible dates, venues, and logistics,=20 it appears that an interim ForCES meeting in mid-February is=20 not feasible at this time. Having a ForCES meeting on Sunday, February 29, at the=20 IETF 59 hotel site is still under consideration. A final decision will be forthcoming by this Wednesday. Cheers, David P.S. Sorry if this is a duplicate, appeared to bounce to me. > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Friday, January 23, 2004 11:05 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Protocol Selection Process: Merger Suggestion > Importance: High >=20 > All, >=20 > After reviewing the protocol submissions it appears that each of the=20 > proposals has valuable features that merit inclusion in the ForCES=20 > protocol. >=20 > Patrick and I would like to urge the various authors to evaluate=20 > whether a merger of the protocols, selecting the best features of=20 > each, would be possible. >=20 > In order to expedite this process we are considering holding and=20 > interim working group meeting two weeks prior to the next IETF where=20 > interested parties could meet for a day to focus on producing a "best=20 > of all worlds" proposal. >=20 > Please contact Patrick or I if you would be interested in attending=20 > such a meeting. >=20 > Thanks, > David & Patrick > co-chairs, IETF ForCES Working Group >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 4 21:06: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 VAA13354 for ; Wed, 4 Feb 2004 21:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYua-0006un-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 21:06:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYth-0006q7-00 for forces-archive@ietf.org; Wed, 04 Feb 2004 21:05:41 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoYtM-0006ke-00 for forces-archive@IETF.ORG; Wed, 04 Feb 2004 21:05:20 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CCE5FD@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 21:05:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 839857 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 21:05:20 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 21:05:20 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1526js0018843 for ; Thu, 5 Feb 2004 02:06:45 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.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1520own029638 for ; Thu, 5 Feb 2004 02:01:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020418045712401 for ; Wed, 04 Feb 2004 18:04:57 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 18:04:57 -0800 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: ForCES Design Meeting Info: Sunday, February 29 @ IETF Hotel in Korea Thread-Index: AcPrjHOtecf/qeyoRsGMbnELux82eg== X-OriginalArrivalTime: 05 Feb 2004 02:04:57.0533 (UTC) FILETIME=[7447FED0:01C3EB8C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8023CAE15@orsmsx409.jf.intel.com> Date: Wed, 4 Feb 2004 18:04:57 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Design Meeting Info: Sunday, February 29 @ IETF Hotel in Korea 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 All, A ForCES design meeting with open attendance=20 is tentatively scheduled with the following=20 date/time/location: Time: Sunday, February 29, 10:00am Local time Location: Lotte Hotel-Seoul, Korea The goal of this meeting will be to determine if a merged protocol proposal is possible, and if so, to begin moving forward on creating such a proposal. Note that it would be desirable if interested parties work ahead of time to come prepared to the meeting with proposals. A phone bridge will be provided for remote=20 participants to call in to. Please email me if you will be attending. If you cannot attend at this time but could attend a later time on Sunday, please email me=20 with that information. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 10:54: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 KAA20488 for ; Thu, 5 Feb 2004 10:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolqF-00057y-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 10:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolpI-00050i-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 10:54:01 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AoloK-0004uR-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 10:53:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00CCFA62@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 10:52:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 941811 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 10:52:59 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 10:52:58 -0500 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.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i15ETts2005069 for ; Thu, 5 Feb 2004 15:55:41 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.7 2003/12/18 18:58:10 root Exp $) with SMTP id i13MqgeJ025095 for ; Tue, 3 Feb 2004 22:53:51 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020314573331907 for ; Tue, 03 Feb 2004 14:57:33 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 14:57:33 -0800 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: Interim meeting update (was: RE: [FORCES] Protocol Selection Process: Merger Suggestion) Thread-Index: AcPh49OOZz+IiUb0R3yokYJaOPLBjwIxEOPg X-OriginalArrivalTime: 03 Feb 2004 22:57:33.0726 (UTC) FILETIME=[1C0973E0:01C3EAA9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8023CA9D3@orsmsx409.jf.intel.com> Date: Tue, 3 Feb 2004 14:57:33 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Interim meeting update (was: RE: [FORCES] Protocol Selection Process: Merger Suggestion) 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 All,=20 After having reviewed possible dates, venues, and logistics, it appears that an interim ForCES meeting in mid-February is not feasible at this time. Having a ForCES meeting on Sunday, February 29, at the IETF 59 hotel site is still under consideration. A final decision will be forthcoming by this=20 Wednesday. Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David > Sent: Friday, January 23, 2004 11:05 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] Protocol Selection Process: Merger Suggestion > Importance: High >=20 > All, >=20 > After reviewing the protocol submissions it appears that each=20 > of the proposals has valuable features that merit inclusion=20 > in the ForCES protocol. >=20 > Patrick and I would like to urge the various authors to=20 > evaluate whether a merger of the protocols, selecting the=20 > best features of each, would be possible.=20 >=20 > In order to expedite this process we are considering holding=20 > and interim working group meeting two weeks prior to the next=20 > IETF where interested parties could meet for a day to focus=20 > on producing a "best of all worlds" proposal. >=20 > Please contact Patrick or I if you would be interested in=20 > attending such a meeting. >=20 > Thanks, > David & Patrick > co-chairs, IETF ForCES Working Group >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 11:57:00 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 LAA23782 for ; Thu, 5 Feb 2004 11:57:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomoH-00046z-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 11:57:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomnQ-00042V-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 11:56:09 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aomn3-0003xU-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 11:55:45 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00CCFAE2@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 11:46:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 951913 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 11:46:31 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 11:46:31 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004020508472934:30089 ; Thu, 5 Feb 2004 08:47:29 -0800 References: <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <1075842838.8133.203.camel@empress.torrentnet.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 02/05/2004 08:47:29 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/05/2004 08:47:31 AM, Serialize complete at 02/05/2004 08:47:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1075999587.1022.100.camel@jzny.localdomain> Date: Thu, 5 Feb 2004 11:46:27 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: Zsolt Haraszti To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1075842838.8133.203.camel@empress.torrentnet.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: 7bit On Tue, 2004-02-03 at 16:13, Zsolt Haraszti wrote: > On Sun, 2004-02-01 at 10:14, Jamal Hadi Salim wrote: [..] > Between FEs's, however, the model does put some requirements on the > implementation. At the minimum, it implies that a certain set of > information (i.e., the set of metadata that is present at the > exit point on FE1 and needed for further processing on FE2) must be > passed _in some way_ between the two FEs. How it is passed is left > to the vendors at this point. One can speculate that many vendors > would benefit from something less proprietary, so I expect that > ForCES will eventually start working on that area. When the work > starts, it will have to take this metadata model into consideration. Just to clarify what i was refering to is communication over something like XAUI or CSIX inter-connected LFBs/FEs. It may get funky with path MTUs with ethernet for example. I am also not about to change chip vendors view of the world on already deployed products. However i see no reason not to have the metadata carried along with the packet. I think it will be a good idea you add text to at least emphasize things in regards to LFBs across FEs. I agree on it being beyond ForCES as is now. > only a portion of this text will go into the revised draft. Much of > the motivation/justification text, including the above, will probably > not make it. When you make changes please post a diff -du of the two files. It is easier to read. I think the idea of mentioning "registers" should be left out of the text. > > + section 4 The Proposed Metadata Model > > > > - I think a TLV with flags would be appropriately model metadata. > > [tag = type; split the type bits into some 4 bits for flags] > Your thinking may be to protocol driven. Again, this model--so far-- > is mainly to describe a reference model w.r.t. how data passing should > be envisioned when defining LFBs, their attributes, and the CE-FE > protocol communication. It is not about how to actually pass > metadata among LFBs. For the above (reduced) scope, it has some > benefits to regard most metadata values as 32 bit integers. You have defined a Tag (that T) which takes a Value (that V). I believe you could model better by not restricting the L to 4. > BTW, what is the intended usage of the flags? I was thinking you could carry the permissions for example such as READ, WRITE etc; maybe they dont fit. > > > > + section 5 Metadata Production and Consumption > > "There may be multiple consumers for the same metadata" > > is repeated twice. > > - wasnt clear on the "conditional" aspect of metadata; could you provide > > a real example? > I do not have very strong examples to support this. What I had > in mind was cases when the need for a metadata depends on the > value of another metadata. For example, one metadata is a > RESULTKEY, and another is an ERRORCODE. RESULTKEY is normally > used to encode the result of an operation (e.g., a search in > a table), and a special value (0) encodes the lack of result. > When RESULTKEY=0, then ERRORCODE tells more about the reason > of the miss. When RESULTKEY!=0, then ERRORCODE is meaningless, > so it can be omitted. I know that this can be done in other ways > (embedding the error codes into the RESULTKEY value space; > or making ERRORCODE mandatory, but ignore it in downstream > LFBs if RESULTKEY!=0, etc.) I see where you are going with it - it may be overkill. To me this further strengthens the need to model based on TLVs. Clearly ERRORCODE. and RESULTKEY are related; you are already refering to embedding them together...... > Once we go through the exercise of creating a library of fully > defined LFBs and putting together useful configurations we may > conclude that there is no need for this feature. Then we can pull > this out. Until then, I left it in a space-holder. But I can > be convinced... The conditionals are attributes of LFB topology; you may have taken the approach that the topology definition needs metadata to route the packet amongst LFBs (which is an implementation detail). I think you should leave it in for now. > > > > + section 7 Fixed Tag, Variable Tag, and Configurable Tag Metadata > > Production > > > > Isnt the tag selector itself metadata? I think starting this section > > you may be treading into implementation specifics. > I am disconnected here. Consider an Re-director LFB that can be > instantiated to split traffic into multiple streams based on some > input metadata. For example, one instance splits based on a classifier > key (CLASSID), another splits based on COLOR, a third based on > protocolo type (PROTO). This will be realized by an LFB class that > will have the following features (simplistic approach): > 1) Variable number of outputs > 2) An attribute that tells the LFB which metadata tag to look for > 3) A table of entries, where each entry will contain a metadata > value (as a condition), and a port reference (where to send > the packet). > So the selector is an attribute of the LFB, read (or possibly written) > by the CE via the ForCES protocol. Making it an attribute is fine. I was more looking at the view that the producer of the metadatum may also define the tag selector and permissions as metadata which is consumed downstream. > The metadata values of the > table entries should be generic enough to accommodate (almost) > arbitrary metadata. I see a benefit to make such a field in the > table entry a 32-bit integer field (which would serve 95% of > the expected metadata types based on our pre-study); that is what > motivates to have a generic data type for most metadata. Ok, based on your statement above, i see why i was having problems with restricting it to 32-bit. I would define metadata as "execution markers"; the only reason you need metadata is so that you dont repeat work the packet has already been put through. Using metadata for table lookups furher downstream is only a subset of that domain. To illustrate: (The linux kernel does this - apologies for going into imp. its the best example i could think of that you could validate) You could design it such that LFB execution completion could be deffered when preempted by higher prio work. In this case you may wanna later reenter the same LFB but skip some code. This is useful in NPs as well. To achieve this you need to store in metadata not just code pointers but data processed so far. > > +section 9 Metadata Usage Categories > > > - "Another way of setting up binding relations is when a > > naturally occurring unique identifier of the consumer's object" > > What is the event that would cause this? Is it a packet arrival or > > a CE reading something off the FE? > Let me illustrate what I meant here with an example: > Lets say the consumer LFB has a table of things. You may insert a > new entry in the table. The operation returns with a table entry > index, which can be used in subsequent incremental table > management. In the same time, the index can also be used as a > way to refer to the given entry from another LFB. E.g, when an > upstream LFB wants to refer to one of the table entries, it can > send the index in a well-defined metadata. That index is what I > consider "naturally occuring," meaning that it exists anyway > and it can also be used as a binding metadata. So to answer the > original question: the event is a configuration event on the LFB > by the CE. > Reading all the above (and ignoring usage of metadata for a moment) it seems to me you are saying theres two types of metadata from a initial production pespective. Theres metadata that maybe we should call "static" that gets produced by the CE as an LFB attribute. Theres also dynamic metadata that gets created or destroyed by other events such as packet arrivals on the producer LFB or timers expiring (eg a cache table entry creation/deletion). > > - "The value of the enumerated metadata may or may not be conveyed > > via the ForCES protocol between the CE and FE." > > > > Didnt grasp that. How are LFBs on an FE supposed to cooperate on values > > of metadata if they are not synced in this case? > Consider a Rate Meter LFB that emits COLOR as metadata. Consider > a downstream Rate Meter LFB that uses the COLOR metadata to do further > rate metering. To neither of the LFB instances would we ever > communicate COLOR as part of the CE-FE communication. It is all > built in in the specification of the LFB class and the specification > of the COLOR metadata. So this is an example when the enumerated > metadata is not conveyed between the CE and FE. > Right - but the attribute is still part of the LFB setup (via CE-FE protocol). i.e from a LFB topology level theres still synchronization that is happening. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 11:58: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 LAA23817 for ; Thu, 5 Feb 2004 11:58:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AompH-0004CT-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 11:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomoL-00047k-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 11:57:06 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aomo8-00042s-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 11:56:52 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CCF9D4@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 11:56:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 955219 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 11:56:18 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 11:56:18 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004020508571687:30112 ; Thu, 5 Feb 2004 08:57:16 -0800 References: <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203165405.01ac1948@localhost> <1075648470.1034.335.camel@jzny.localdomain> <1074874628.2805.22.camel@empress.torrentnet.com> <1075648470.1034.335.camel@jzny.localdomain> <5.1.0.14.0.20040203165405.01ac1948@localhost> <5.1.0.14.0.20040203171927.01adfc50@localhost> <5.1.0.14.0.20040203201908.01ad5298@localhost> <5.1.0.14.0.20040203212122.01af1d08@localhost> <4020681A.2050007@ericsson.com> <40212C5D.D94A2F2@alcatel.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 02/05/2004 08:57:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/05/2004 08:57:18 AM, Serialize complete at 02/05/2004 08:57:18 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1076000173.1024.113.camel@jzny.localdomain> Date: Thu, 5 Feb 2004 11:56:14 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: alex.audu@alcatel.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <40212C5D.D94A2F2@alcatel.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: 7bit The problem (challenge actually) is this stuff exists already. Looking the other way may not be the best option. I agree with Zsolt's statements below. If we want to say its outside the scope, then the text on metdata that Zsolt posted is overkill already and may need a lot of chopping. cheers, jamal On Wed, 2004-02-04 at 12:31, Alex Audu wrote: > I am assuming this meta-data thing is all in context of having the CE > successfully > configure the FEs. Unless this requires FE-FE communication, I don't see any > reasons for extending this to include FE-FE. > > Regards, > Alex. > > > Zsolt Haraszti wrote: > > > A couple of comments: > > > > 1. The fact is that most real distributed (multiblade) routers > > forward metadata from one blade (e.g., ingresss) to another > > (e.g., egress). This simply allows optimal distribution of > > processing functions across the involved FEs. > > Not only that they forward metadata in addition to the IP packet > > being sent, but it may also be that the packet is not a > > complete/valid IP packet. Since this is all within the node, > > it's all legitimate. > > > > 2. Just because it is not an IP packet or not only an IP packet, > > it does not mean that ForCES must include it in its scope. > > If it is not in the scope, so be it. Then it will be left > > for the vendors, or to some other standards bodies to deal > > with it. (FYI, the NPF is addressing the inter-FE metadata > > encapsulation via a messaging LFB and messaging protocol). > > BTW, I think the ForCES work is still very useful, even if > > the inter-FE messaging is not in its scope. > > > > 3. Even if the inter-FE messaging could be put into the ForCES > > scope, we should still ignore it for the time being, and > > focus on the model and the CE-FE communication. > > > > /zsolt > > > > Joel M. Halpern wrote: > > > There probably is an issue of hop count. Personally, I consider such > > > double decrementing a very good idea, as it avoids accidental internal > > > loops. > > > > > > Other than that, the IP addresses are just the interface IP addresses of > > > the NE. If the links between the FEs are multi-access, they will need IP > > > addresses. They will need them even if that network is otherwise > > > concealed, and even if the protocol were not IP. > > > > > > One can craft all sorts of reasons why it might be nice to treat the Fi > > > links differently. And later, we might choose to do so. But the topology > > > and scope documents clearly state that we are not defining a protocol for > > > that. And we can meet a reasonable definition of a "single system image" > > > without defining or using a special protocol on those links. > > > Given that the system works when we treat those links as carrying IP over > > > BACK (ie any technology used for the interconnect which supports IP > > > packets) it seems that we keep our work bounded and within defined scope if > > > for now we just use that. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > > > >> Well, if IP is used between FEs, without any metadata in the exchange, > > >> then wouldn't it involve forwarding as it it were a hop? And while it > > >> is true that the receiving FE could treat the packet specially and not > > >> modify the packet based on the extra hop, this would involve implicit > > >> 'metadata' that this wasn't being forwarded from outside the NE and not > > >> as if between NEs. > > >> > > >> Also, wouldn't there be a concern with the assignment of IP addresses > > >> to each of the FEs. Or would this be done based on some internal > > >> private IP address space. > > >> > > >> Maybe I don't really understand what you mean when you say an FE passes > > >> a packet to another FE as if it were being passed to another NE. > > >> > > >> a. > > >> > > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > > >> > > >>> I do not believe that would violate single system appearence at all. > > >>> Appearing as a single system is a matter of management protocol > > >>> interactions and routing protocol advertisements. It has nothing to do > > >>> with the packets flowing between FEs. > > >>> > > >>> Yours, > > >>> Joel M. Halpern > > >>> > > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > > >>> > > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > > >>>> > > >>>>> In general, given that Fi is outside of scope, I think of all traffic > > >>>>> to > > >>>>> another FE as if it were to another NE. > > >>>> > > >>>> > > >>>> Wouldn't that violate the rule that an NE, no matter how many parts it > > >>>> is composed of, should appear to be a single entity. If we assume > > >>>> that > > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may have > > >>>> problems meeting that requirement. > > >>>> > > >>>> I agree the current charter prohibits making FE-FE protocols a work > > >>>> item, but I don't think that eliminates the need for implementations > > >>>> to > > >>>> have a solution other then the passing of straight IP packets. > > >>>> Including a metadata model that covers this seems like a good idea. > > >>>> Personally I am glad someone is working on it. I know I am more > > >>>> concerned with the WG getting the model right then worrying about > > >>>> specific protocol implementations. > > >>>> > > >>>> a. > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 12:05:21 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 MAA24362 for ; Thu, 5 Feb 2004 12:05:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomwM-0005Dt-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aomvo-000556-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:04:49 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AomuT-0004ne-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 12:03:25 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CCFA11@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 12:03:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 956620 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 12:03:24 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 12:03:23 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004020509042303:30134 ; Thu, 5 Feb 2004 09:04:23 -0800 References: <52D13A805349A249960B9943E5590BD8023CAE15@orsmsx409.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 02/05/2004 09:04:23 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/05/2004 09:04:24 AM, Serialize complete at 02/05/2004 09:04:24 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1076000593.1026.129.camel@jzny.localdomain> Date: Thu, 5 Feb 2004 12:03:13 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: ForCES Design Meeting Info: Sunday, February 29 @ IETF Hotel in Korea Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <52D13A805349A249960B9943E5590BD8023CAE15@orsmsx409.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit David, For this to be effective good representation from all protocol drafts in atome format would be needed. So far 75% of the netlink2 draft authors (we have a new oauthor) have confirmed they wont be going. I dont think the concal alone would cut it. So i suggest we defer this until after Seoul. It would be a good idea to start discussion via email (which should initially be restricted to protocol authors only and opened up after to other people to reduce noise). cheers, jamal On Wed, 2004-02-04 at 21:04, Putzolu, David wrote: > All, > > A ForCES design meeting with open attendance > is tentatively scheduled with the following > date/time/location: > > Time: Sunday, February 29, 10:00am Local time > Location: Lotte Hotel-Seoul, Korea > > The goal of this meeting will be to determine if a > merged protocol proposal is possible, and if so, to > begin moving forward on creating such a proposal. > Note that it would be desirable if interested > parties work ahead of time to come prepared to the > meeting with proposals. > > A phone bridge will be provided for remote > participants to call in to. > > Please email me if you will be attending. > If you cannot attend at this time but could > attend a later time on Sunday, please email me > with that information. > > Thanks, > David From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 12:43: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 MAA25496 for ; Thu, 5 Feb 2004 12:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonWp-0000v2-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:43:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AonVs-0000qR-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:42:05 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AonVD-0000lr-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 12:41:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CCFC3E@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 12:41:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 960315 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 12:41:22 -0500 Received: from 192.52.57.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 12:41:22 -0500 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i15HfKcg004589; Thu, 5 Feb 2004 17:41:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i15HfDKN015573; Thu, 5 Feb 2004 17:41:14 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 M2004020509411205633 ; Thu, 05 Feb 2004 09:41:12 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 09:41:13 -0800 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: Metadata model for the ForCES model Thread-Index: AcPsCRQiH44U8QP5QySmHjbQmYZb0wABJeCQ X-OriginalArrivalTime: 05 Feb 2004 17:41:13.0203 (UTC) FILETIME=[3F96FC30:01C3EC0F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB1ED@orsmsx410.jf.intel.com> Date: Thu, 5 Feb 2004 09:41:11 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Metadata model for the ForCES model 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jamal -- I don't quite understand your last statement below. Don't you = agree: 1) FE-FE is indeed out of scope for now. 2) In prinicple, the metadata model that Zsolt posted is still necessary = (i.e., not overkill) even just for intra-FE (LFB to LFB) metadata = modeling. 3) It is extra nice (bonus) if this same metadata model can work across = both intra-FE and inter-FE domain.=20 It is absolutely important for the WG to agree on 1) and 2) above. 3) is = optional but nice to have, so lets not be too concerned about it for the = time being. Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim Sent: Thursday, February 05, 2004 8:56 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Metadata model for the ForCES model The problem (challenge actually) is this stuff exists already. Looking the other way may not be the best option. I agree with Zsolt's statements below. If we want to say its outside the scope, then the text on metdata that Zsolt posted is overkill already and may need a lot of chopping. cheers, jamal On Wed, 2004-02-04 at 12:31, Alex Audu wrote: > I am assuming this meta-data thing is all in context of having the CE > successfully > configure the FEs. Unless this requires FE-FE communication, I don't = see any > reasons for extending this to include FE-FE. > > Regards, > Alex. > > > Zsolt Haraszti wrote: > > > A couple of comments: > > > > 1. The fact is that most real distributed (multiblade) routers > > forward metadata from one blade (e.g., ingresss) to another > > (e.g., egress). This simply allows optimal distribution of > > processing functions across the involved FEs. > > Not only that they forward metadata in addition to the IP packet > > being sent, but it may also be that the packet is not a > > complete/valid IP packet. Since this is all within the node, > > it's all legitimate. > > > > 2. Just because it is not an IP packet or not only an IP packet, > > it does not mean that ForCES must include it in its scope. > > If it is not in the scope, so be it. Then it will be left > > for the vendors, or to some other standards bodies to deal > > with it. (FYI, the NPF is addressing the inter-FE metadata > > encapsulation via a messaging LFB and messaging protocol). > > BTW, I think the ForCES work is still very useful, even if > > the inter-FE messaging is not in its scope. > > > > 3. Even if the inter-FE messaging could be put into the ForCES > > scope, we should still ignore it for the time being, and > > focus on the model and the CE-FE communication. > > > > /zsolt > > > > Joel M. Halpern wrote: > > > There probably is an issue of hop count. Personally, I consider = such > > > double decrementing a very good idea, as it avoids accidental = internal > > > loops. > > > > > > Other than that, the IP addresses are just the interface IP = addresses of > > > the NE. If the links between the FEs are multi-access, they will = need IP > > > addresses. They will need them even if that network is otherwise > > > concealed, and even if the protocol were not IP. > > > > > > One can craft all sorts of reasons why it might be nice to treat = the Fi > > > links differently. And later, we might choose to do so. But the = topology > > > and scope documents clearly state that we are not defining a = protocol for > > > that. And we can meet a reasonable definition of a "single system = image" > > > without defining or using a special protocol on those links. > > > Given that the system works when we treat those links as carrying = IP over > > > BACK (ie any technology used for the interconnect which supports = IP > > > packets) it seems that we keep our work bounded and within defined = scope if > > > for now we just use that. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: > > > > > >> Well, if IP is used between FEs, without any metadata in the = exchange, > > >> then wouldn't it involve forwarding as it it were a hop? And = while it > > >> is true that the receiving FE could treat the packet specially = and not > > >> modify the packet based on the extra hop, this would involve = implicit > > >> 'metadata' that this wasn't being forwarded from outside the NE = and not > > >> as if between NEs. > > >> > > >> Also, wouldn't there be a concern with the assignment of IP = addresses > > >> to each of the FEs. Or would this be done based on some internal > > >> private IP address space. > > >> > > >> Maybe I don't really understand what you mean when you say an FE = passes > > >> a packet to another FE as if it were being passed to another NE. > > >> > > >> a. > > >> > > >> On 2004-02-04, at 10.22, Joel M. Halpern wrote: > > >> > > >>> I do not believe that would violate single system appearence at = all. > > >>> Appearing as a single system is a matter of management protocol > > >>> interactions and routing protocol advertisements. It has = nothing to do > > >>> with the packets flowing between FEs. > > >>> > > >>> Yours, > > >>> Joel M. Halpern > > >>> > > >>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: > > >>> > > >>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: > > >>>> > > >>>>> In general, given that Fi is outside of scope, I think of all = traffic > > >>>>> to > > >>>>> another FE as if it were to another NE. > > >>>> > > >>>> > > >>>> Wouldn't that violate the rule that an NE, no matter how many = parts it > > >>>> is composed of, should appear to be a single entity. If we = assume > > >>>> that > > >>>> FE-FE messaging is normal IP as if it were NE-NE then we may = have > > >>>> problems meeting that requirement. > > >>>> > > >>>> I agree the current charter prohibits making FE-FE protocols a = work > > >>>> item, but I don't think that eliminates the need for = implementations > > >>>> to > > >>>> have a solution other then the passing of straight IP packets. > > >>>> Including a metadata model that covers this seems like a good = idea. > > >>>> Personally I am glad someone is working on it. I know I am = more > > >>>> concerned with the WG getting the model right then worrying = about > > >>>> specific protocol implementations. > > >>>> > > >>>> a. > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 12:52: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 MAA25753 for ; Thu, 5 Feb 2004 12:52:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonfX-0001hE-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:52:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoned-0001bY-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 12:51:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aondj-0001WS-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 12:50:11 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00CCFD9B@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 12:50:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 960789 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 12:50:09 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 12:50:09 -0500 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004020509510628:30226 ; Thu, 5 Feb 2004 09:51:06 -0800 References: <26BDFAFFB541B047B24179002EBE6D278CB1ED@orsmsx410.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 02/05/2004 09:51:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/05/2004 09:51:10 AM, Serialize complete at 02/05/2004 09:51:10 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1076003403.1027.138.camel@jzny.localdomain> Date: Thu, 5 Feb 2004 12:50:03 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Metadata model for the ForCES model Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB1ED@orsmsx410.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-02-05 at 12:41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) is optional but nice to have, so lets not be too concerned about it for the time being. > I dont see why modelling 3) should be any different. The transporting of such metadata is definetely out of scope. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 15:06: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 PAA02213 for ; Thu, 5 Feb 2004 15:06:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoplH-0000Kp-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 15:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopkJ-0000F9-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 15:05:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AopjO-00009D-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 15:04:10 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CCFF26@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 15:04:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 976588 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 15:04:09 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 15:04:08 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AopjL-000Grl-KX for FORCES@PEACH.EASE.LSOFT.COM; Thu, 05 Feb 2004 20:04:07 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Alex Zinin Message-ID: <9392792839.20040205120323@psg.com> Date: Thu, 5 Feb 2004 12:03:23 -0800 Reply-To: Alex Zinin Sender: Forwarding and Control Element Separation From: Alex Zinin Subject: IESG on draft-ietf-forces-framework 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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- FYI, the IESG approved the draft-ietf-forces-framework document this morning. A formal announcement to appear shortly. Thanks all for good work! -- Alex http://www.psg.com/~zinin/ From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 15:17:08 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 PAA03519 for ; Thu, 5 Feb 2004 15:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopvw-0001eo-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 15:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopuy-0001YM-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 15:16:08 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Aopu5-0001Ry-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 15:15:13 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CCFD8F@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 15:15:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 977237 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 15:15:13 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 15:15:13 -0500 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i15KFB09012226; Thu, 5 Feb 2004 20:15:11 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i15KG7Op003432; Thu, 5 Feb 2004 20:16:08 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 M2004020512150611928 ; Thu, 05 Feb 2004 12:15:06 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 12:15:03 -0800 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: [FORCES] IESG on draft-ietf-forces-framework Thread-Index: AcPsIzwqfneOblrWREWkCdZY94h33gAAS3Xg X-OriginalArrivalTime: 05 Feb 2004 20:15:03.0294 (UTC) FILETIME=[BD2719E0:01C3EC24] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8023CB04B@orsmsx409.jf.intel.com> Date: Thu, 5 Feb 2004 12:15:02 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: IESG on draft-ietf-forces-framework Comments: To: Alex Zinin 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Congratulations all on a job well done, and thank you Alex & a host of others (including IESG members, routing directorate, security advisors, and more) for all your help & patience! Cheers, David=20 > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin > Sent: Thursday, February 05, 2004 12:03 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] IESG on draft-ietf-forces-framework >=20 > Folks- >=20 > FYI, the IESG approved the draft-ietf-forces-framework=20 > document this morning. A formal announcement to appear shortly. >=20 > Thanks all for good work! >=20 > -- > Alex > http://www.psg.com/~zinin/ >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 20:09:16 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 UAA21686 for ; Thu, 5 Feb 2004 20:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AouUd-0000Ef-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 20:09:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AouTg-0000Bx-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 20:08:17 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AouSl-00008W-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 20:07:19 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CD06E6@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 20:07:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1003267 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 20:07:17 -0500 Received: from 129.254.16.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 20:07:17 -0500 Received: from [129.254.191.55] (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1JZZ8GXP; Fri, 6 Feb 2004 10:10:18 +0900 Mime-Version: 1.0 (Apple Message framework v609) References: <26BDFAFFB541B047B24179002EBE6D278CB1ED@orsmsx410.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.609) Approved-By: avri@ACM.ORG Message-ID: Date: Fri, 6 Feb 2004 10:07:08 +0900 Reply-To: avri@acm.org Sender: Forwarding and Control Element Separation From: avri@acm.org Subject: Re: Metadata model for the ForCES model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D278CB1ED@orsmsx410.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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I don't think I quite agree. Yes FE-FE _protocols_ are out of scope. but LFB - LFB even when across FE should not be out of scope for the model. How that info get conveyed across the FE boundary is out of scope, but the info should not be. So I guess I am saying that I see (3) as more then just nice. a. On 6 feb 2004, at 02.41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you > agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still > necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) > metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work > across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) > is optional but nice to have, so lets not be too concerned about it > for the time being. > > Lily > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Thursday, February 05, 2004 8:56 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Metadata model for the ForCES model > > > The problem (challenge actually) is this stuff exists already. > Looking the other way may not be the best option. > I agree with Zsolt's statements below. > If we want to say its outside the scope, then the text on metdata > that Zsolt posted is overkill already and may need a lot of chopping. > > cheers, > jamal > > On Wed, 2004-02-04 at 12:31, Alex Audu wrote: >> I am assuming this meta-data thing is all in context of having the CE >> successfully >> configure the FEs. Unless this requires FE-FE communication, I >> don't see any >> reasons for extending this to include FE-FE. >> >> Regards, >> Alex. >> >> >> Zsolt Haraszti wrote: >> >>> A couple of comments: >>> >>> 1. The fact is that most real distributed (multiblade) routers >>> forward metadata from one blade (e.g., ingresss) to another >>> (e.g., egress). This simply allows optimal distribution of >>> processing functions across the involved FEs. >>> Not only that they forward metadata in addition to the IP packet >>> being sent, but it may also be that the packet is not a >>> complete/valid IP packet. Since this is all within the node, >>> it's all legitimate. >>> >>> 2. Just because it is not an IP packet or not only an IP packet, >>> it does not mean that ForCES must include it in its scope. >>> If it is not in the scope, so be it. Then it will be left >>> for the vendors, or to some other standards bodies to deal >>> with it. (FYI, the NPF is addressing the inter-FE metadata >>> encapsulation via a messaging LFB and messaging protocol). >>> BTW, I think the ForCES work is still very useful, even if >>> the inter-FE messaging is not in its scope. >>> >>> 3. Even if the inter-FE messaging could be put into the ForCES >>> scope, we should still ignore it for the time being, and >>> focus on the model and the CE-FE communication. >>> >>> /zsolt >>> >>> Joel M. Halpern wrote: >>>> There probably is an issue of hop count. Personally, I consider >>>> such >>>> double decrementing a very good idea, as it avoids accidental >>>> internal >>>> loops. >>>> >>>> Other than that, the IP addresses are just the interface IP >>>> addresses of >>>> the NE. If the links between the FEs are multi-access, they will >>>> need IP >>>> addresses. They will need them even if that network is otherwise >>>> concealed, and even if the protocol were not IP. >>>> >>>> One can craft all sorts of reasons why it might be nice to treat >>>> the Fi >>>> links differently. And later, we might choose to do so. But the >>>> topology >>>> and scope documents clearly state that we are not defining a >>>> protocol for >>>> that. And we can meet a reasonable definition of a "single system >>>> image" >>>> without defining or using a special protocol on those links. >>>> Given that the system works when we treat those links as carrying >>>> IP over >>>> BACK (ie any technology used for the interconnect which supports IP >>>> packets) it seems that we keep our work bounded and within defined >>>> scope if >>>> for now we just use that. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >>>> >>>>> Well, if IP is used between FEs, without any metadata in the >>>>> exchange, >>>>> then wouldn't it involve forwarding as it it were a hop? And >>>>> while it >>>>> is true that the receiving FE could treat the packet specially and >>>>> not >>>>> modify the packet based on the extra hop, this would involve >>>>> implicit >>>>> 'metadata' that this wasn't being forwarded from outside the NE >>>>> and not >>>>> as if between NEs. >>>>> >>>>> Also, wouldn't there be a concern with the assignment of IP >>>>> addresses >>>>> to each of the FEs. Or would this be done based on some internal >>>>> private IP address space. >>>>> >>>>> Maybe I don't really understand what you mean when you say an FE >>>>> passes >>>>> a packet to another FE as if it were being passed to another NE. >>>>> >>>>> a. >>>>> >>>>> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >>>>> >>>>>> I do not believe that would violate single system appearence at >>>>>> all. >>>>>> Appearing as a single system is a matter of management protocol >>>>>> interactions and routing protocol advertisements. It has nothing >>>>>> to do >>>>>> with the packets flowing between FEs. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>>>> >>>>>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>>>>> >>>>>>>> In general, given that Fi is outside of scope, I think of all >>>>>>>> traffic >>>>>>>> to >>>>>>>> another FE as if it were to another NE. >>>>>>> >>>>>>> >>>>>>> Wouldn't that violate the rule that an NE, no matter how many >>>>>>> parts it >>>>>>> is composed of, should appear to be a single entity. If we >>>>>>> assume >>>>>>> that >>>>>>> FE-FE messaging is normal IP as if it were NE-NE then we may have >>>>>>> problems meeting that requirement. >>>>>>> >>>>>>> I agree the current charter prohibits making FE-FE protocols a >>>>>>> work >>>>>>> item, but I don't think that eliminates the need for >>>>>>> implementations >>>>>>> to >>>>>>> have a solution other then the passing of straight IP packets. >>>>>>> Including a metadata model that covers this seems like a good >>>>>>> idea. >>>>>>> Personally I am glad someone is working on it. I know I am more >>>>>>> concerned with the WG getting the model right then worrying about >>>>>>> specific protocol implementations. >>>>>>> >>>>>>> a. >>>> >>>> >>>> > From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 5 20:39: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 UAA22497 for ; Thu, 5 Feb 2004 20:39:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aouxl-0001Gr-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 20:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoux8-0001Ek-00 for forces-archive@ietf.org; Thu, 05 Feb 2004 20:38:43 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AouwI-0001An-00 for forces-archive@IETF.ORG; Thu, 05 Feb 2004 20:37:50 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CD05DE@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 20:37:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1005774 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 20:37:48 -0500 Received: from 146.152.216.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 20:37:48 -0500 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i161blUv031407; Fri, 6 Feb 2004 01:37:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i161cROv027084; Fri, 6 Feb 2004 01:38:43 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020517374611675 ; Thu, 05 Feb 2004 17:37:46 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 17:37:46 -0800 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: Metadata model for the ForCES model Thread-Index: AcPsTZp3UuXSi3M6RtC5Nmdd2NMPjwAAXwtw X-OriginalArrivalTime: 06 Feb 2004 01:37:46.0136 (UTC) FILETIME=[D24E5180:01C3EC51] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D278CB1FF@orsmsx410.jf.intel.com> Date: Thu, 5 Feb 2004 17:37:45 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Metadata model for the ForCES model Comments: To: avri@acm.org 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ok. Let me try to ask this differently then: 1) Is there anything in this metadata model proposal that would not work = for LFB-LFB crossing FE boundary? 2) Is there anything in this model that is ONLY useful for LFB-LFB = crossing FE boundary?=20 My own answeres to both these questions are No. Bottom line: I don't see how this distinction (crossing FE or not) = affect the substance of the metadata model here.=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of avri@acm.org Sent: Thursday, February 05, 2004 5:07 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Metadata model for the ForCES model I don't think I quite agree. Yes FE-FE _protocols_ are out of scope. but LFB - LFB even when across FE should not be out of scope for the model. How that info get conveyed across the FE boundary is out of scope, but the info should not be. So I guess I am saying that I see (3) as more then just nice. a. On 6 feb 2004, at 02.41, Yang, Lily L wrote: > Jamal -- I don't quite understand your last statement below. Don't you > agree: > 1) FE-FE is indeed out of scope for now. > 2) In prinicple, the metadata model that Zsolt posted is still > necessary (i.e., not overkill) even just for intra-FE (LFB to LFB) > metadata modeling. > 3) It is extra nice (bonus) if this same metadata model can work > across both intra-FE and inter-FE domain. > > It is absolutely important for the WG to agree on 1) and 2) above. 3) > is optional but nice to have, so lets not be too concerned about it > for the time being. > > Lily > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM]On Behalf Of Jamal Hadi Salim > Sent: Thursday, February 05, 2004 8:56 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Metadata model for the ForCES model > > > The problem (challenge actually) is this stuff exists already. > Looking the other way may not be the best option. > I agree with Zsolt's statements below. > If we want to say its outside the scope, then the text on metdata > that Zsolt posted is overkill already and may need a lot of chopping. > > cheers, > jamal > > On Wed, 2004-02-04 at 12:31, Alex Audu wrote: >> I am assuming this meta-data thing is all in context of having the CE >> successfully >> configure the FEs. Unless this requires FE-FE communication, I >> don't see any >> reasons for extending this to include FE-FE. >> >> Regards, >> Alex. >> >> >> Zsolt Haraszti wrote: >> >>> A couple of comments: >>> >>> 1. The fact is that most real distributed (multiblade) routers >>> forward metadata from one blade (e.g., ingresss) to another >>> (e.g., egress). This simply allows optimal distribution of >>> processing functions across the involved FEs. >>> Not only that they forward metadata in addition to the IP packet >>> being sent, but it may also be that the packet is not a >>> complete/valid IP packet. Since this is all within the node, >>> it's all legitimate. >>> >>> 2. Just because it is not an IP packet or not only an IP packet, >>> it does not mean that ForCES must include it in its scope. >>> If it is not in the scope, so be it. Then it will be left >>> for the vendors, or to some other standards bodies to deal >>> with it. (FYI, the NPF is addressing the inter-FE metadata >>> encapsulation via a messaging LFB and messaging protocol). >>> BTW, I think the ForCES work is still very useful, even if >>> the inter-FE messaging is not in its scope. >>> >>> 3. Even if the inter-FE messaging could be put into the ForCES >>> scope, we should still ignore it for the time being, and >>> focus on the model and the CE-FE communication. >>> >>> /zsolt >>> >>> Joel M. Halpern wrote: >>>> There probably is an issue of hop count. Personally, I consider >>>> such >>>> double decrementing a very good idea, as it avoids accidental >>>> internal >>>> loops. >>>> >>>> Other than that, the IP addresses are just the interface IP >>>> addresses of >>>> the NE. If the links between the FEs are multi-access, they will >>>> need IP >>>> addresses. They will need them even if that network is otherwise >>>> concealed, and even if the protocol were not IP. >>>> >>>> One can craft all sorts of reasons why it might be nice to treat >>>> the Fi >>>> links differently. And later, we might choose to do so. But the >>>> topology >>>> and scope documents clearly state that we are not defining a >>>> protocol for >>>> that. And we can meet a reasonable definition of a "single system >>>> image" >>>> without defining or using a special protocol on those links. >>>> Given that the system works when we treat those links as carrying >>>> IP over >>>> BACK (ie any technology used for the interconnect which supports IP >>>> packets) it seems that we keep our work bounded and within defined >>>> scope if >>>> for now we just use that. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 11:04 AM 2/4/2004 +0900, avri@acm.org wrote: >>>> >>>>> Well, if IP is used between FEs, without any metadata in the >>>>> exchange, >>>>> then wouldn't it involve forwarding as it it were a hop? And >>>>> while it >>>>> is true that the receiving FE could treat the packet specially and >>>>> not >>>>> modify the packet based on the extra hop, this would involve >>>>> implicit >>>>> 'metadata' that this wasn't being forwarded from outside the NE >>>>> and not >>>>> as if between NEs. >>>>> >>>>> Also, wouldn't there be a concern with the assignment of IP >>>>> addresses >>>>> to each of the FEs. Or would this be done based on some internal >>>>> private IP address space. >>>>> >>>>> Maybe I don't really understand what you mean when you say an FE >>>>> passes >>>>> a packet to another FE as if it were being passed to another NE. >>>>> >>>>> a. >>>>> >>>>> On 2004-02-04, at 10.22, Joel M. Halpern wrote: >>>>> >>>>>> I do not believe that would violate single system appearence at >>>>>> all. >>>>>> Appearing as a single system is a matter of management protocol >>>>>> interactions and routing protocol advertisements. It has nothing >>>>>> to do >>>>>> with the packets flowing between FEs. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> At 10:13 AM 2/4/2004 +0900, avri@acm.org wrote: >>>>>> >>>>>>> On 2004-02-04, at 07.25, Joel M. Halpern wrote: >>>>>>> >>>>>>>> In general, given that Fi is outside of scope, I think of all >>>>>>>> traffic >>>>>>>> to >>>>>>>> another FE as if it were to another NE. >>>>>>> >>>>>>> >>>>>>> Wouldn't that violate the rule that an NE, no matter how many >>>>>>> parts it >>>>>>> is composed of, should appear to be a single entity. If we >>>>>>> assume >>>>>>> that >>>>>>> FE-FE messaging is normal IP as if it were NE-NE then we may = have >>>>>>> problems meeting that requirement. >>>>>>> >>>>>>> I agree the current charter prohibits making FE-FE protocols a >>>>>>> work >>>>>>> item, but I don't think that eliminates the need for >>>>>>> implementations >>>>>>> to >>>>>>> have a solution other then the passing of straight IP packets. >>>>>>> Including a metadata model that covers this seems like a good >>>>>>> idea. >>>>>>> Personally I am glad someone is working on it. I know I am more >>>>>>> concerned with the WG getting the model right then worrying = about >>>>>>> specific protocol implementations. >>>>>>> >>>>>>> a. >>>> >>>> >>>> > From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 9 13:44:05 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 NAA03681 for ; Mon, 9 Feb 2004 13:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGO5-0004OH-00 for forces-archive@ietf.org; Mon, 09 Feb 2004 13:44:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGN0-0004CO-00 for forces-archive@ietf.org; Mon, 09 Feb 2004 13:42:58 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AqGM4-00040w-00 for forces-archive@IETF.ORG; Mon, 09 Feb 2004 13:42:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CD6509@cherry.ease.lsoft.com>; Mon, 9 Feb 2004 13:41:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1501513 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 9 Feb 2004 13:41:56 -0500 Received: from 132.151.1.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Feb 2004 13:31:56 -0500 Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1AqGCM-0005XL-5X; Mon, 09 Feb 2004 13:31:58 -0500 X-test-idtracker: no Approved-By: Nobody Message-ID: Date: Mon, 9 Feb 2004 13:31:58 -0500 Reply-To: The IESG Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Document Action: 'Forwarding and Control Element Separation (ForCES) Framework' to Informational RFC Comments: cc: Internet Architecture Board , RFC Editor 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=none autolearn=no version=2.60 The IESG has approved the following document: - 'Forwarding and Control Element Separation (ForCES) Framework ' as an Informational RFC This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 17 10:45: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 KAA07408 for ; Tue, 17 Feb 2004 10:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7Pz-0002V0-00 for forces-archive@ietf.org; Tue, 17 Feb 2004 10:45:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Ns-00024N-00 for forces-archive@ietf.org; Tue, 17 Feb 2004 10:43:41 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1At7Lw-0001fa-00 for forces-archive@IETF.ORG; Tue, 17 Feb 2004 10:41:41 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CE36F2@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 10:41:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2581662 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 10:41:39 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 10:31:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04660; Tue, 17 Feb 2004 10:31:36 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: dinaras@CNRI.RESTON.VA.US Message-ID: <200402171531.KAA04660@ietf.org> Date: Tue, 17 Feb 2004 10:31:36 -0500 Reply-To: Internet-Drafts@ietf.org Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-model-02.txt 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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Forwarding Element Functional Model Author(s) : L. Yang Filename : draft-ietf-forces-model-02.txt Pages : 101 Date : 2004-2-17 This document defines the forwarding element (FE) model used in the Forwarding and Control Plane Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft [1]. A list of the basic logical functional blocks (LFBs) is also defined in the LFB class library to aid the effort in defining individual LFBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17103147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17103147.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 17 11:51:19 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 LAA16326 for ; Tue, 17 Feb 2004 11:51:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8RN-0004h1-00 for forces-archive@ietf.org; Tue, 17 Feb 2004 11:51:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8QL-0004cp-00 for forces-archive@ietf.org; Tue, 17 Feb 2004 11:50:18 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1At8Py-0004ZM-00 for forces-archive@IETF.ORG; Tue, 17 Feb 2004 11:49:54 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CE385C@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 11:49:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2593386 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 11:49:30 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 11:49:30 -0500 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.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1HGqcLi026034 for ; Tue, 17 Feb 2004 16:52:38 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.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1HGhunH027496 for ; Tue, 17 Feb 2004 16:44:55 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021708492800311 for ; Tue, 17 Feb 2004 08:49:28 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Feb 2004 08:49:27 -0800 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: I-D ACTION:draft-ietf-forces-model-02.txt Thread-Index: AcP1bI1NyR5tBbcXSJ2r8odHJWVLJQABoXHw X-OriginalArrivalTime: 17 Feb 2004 16:49:27.0687 (UTC) FILETIME=[0183D970:01C3F576] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D271560C9@orsmsx410.jf.intel.com> Date: Tue, 17 Feb 2004 08:49:27 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, all -- The FE model design team just published v02 of the FE model document. The entire document has been edited throughout, but most notably some major progress has been reflected in this revision: 1) 3.2.4 "metadata" section is completely rewritten, with the metadata model that was published to this list by Zsolt a few weeks ago. We believe most comments we've received so far are addressed in this revision. 2) Section 4 "model and schema for LFB classes" is rewritten, with formal XML schema specified at the end of the section. 3) Section 5 "FE Attributes and Capabilities" now is completed with also formal XML schema specification, that was also published to the list a few weeks ago by Joel. 4) The old section 6 in v01 was a place holder for LFB topology and now gone because the content of LFB topology is merged into "FE attributes and Capabilities" in Section 5. The comments we received are also incorporated into this new revision. 5) Section 6 "LFB Class Library" (old section 7 in v01) is also revised significantly with now 18 LFB classes that include the most commonly found functions for IP processing, forwarding and QoS. 6) Section 7 "satisfying the requirements" (old section 8 in v01) is also revised considerably. With this revision, the major pieces that make up the FE model are now in place, with the exception of a few minor features here and there (e.g., class inheritance is not fully flushed out in the LFB schema). We hope this revision would provide timely input into the protocol development. In the meantime, we hope the WG and especially the protocol designers would take time to review and provide feedback on the FE model, so that we can refine it to the satisfaction of the WG in the next few months. Thank you all, Lily -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 17, 2004 7:32 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: I-D ACTION:draft-ietf-forces-model-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Forwarding Element Functional Model Author(s) : L. Yang Filename : draft-ietf-forces-model-02.txt Pages : 101 Date : 2004-2-17 This document defines the forwarding element (FE) model used in the Forwarding and Control Plane Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft [1]. A list of the basic logical functional blocks (LFBs) is also defined in the LFB class library to aid the effort in defining individual LFBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From yvcnoticiaurgente@hotmail.com Thu Feb 19 12:44: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 MAA29119 for ; Thu, 19 Feb 2004 12:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsDw-0003e7-00 for forces-archive@ietf.org; Thu, 19 Feb 2004 12:44:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsCy-0003Vh-00 for forces-archive@ietf.org; Thu, 19 Feb 2004 12:43:33 -0500 Received: from [61.153.233.94] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtsBt-0003Hn-00; Thu, 19 Feb 2004 12:42:27 -0500 From: "Mato Grosso: . qeh" To: enum-admin@ietf.org Subject: Alertam sobre perigo de aftosa em fazendas invadidas por índios ref.: efn 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: Thu, 19 Feb 2004 12:42:27 -0500 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=10.8 required=5.0 tests=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, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 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 * 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

cod.: (foe) EnEspañol:TraductorGratuitoAutomático - InEnglish:FreeAutomaticTranslator

Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por índios

Conselho Indigenista Missionário (Cimi), Fundação Nacional do Índio (Funai) e ONGs são acusadas de "fabricar" conflitos entre índios e proprietários rurais, que já causaram numerosas vítimas, como um dirigente pecuarista recentemente assassinado em Santa Catarina

CAMPO GRANDE, Fevr. 19, 2004 (AB) - "Há uma preocupação enorme com relação ao estado sanitário do rebanho bovino estimado em 9 mil cabeças, nas 14 fazendas invadidas por índios na região de Japorã, perto da fronteira com o Paraguai". "Mato Grosso do Sul é livre de aftosa, mediante vacinação, o Estado possui o 1o. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milhões e 700 mil cabeças, contribuindo com uma porcentagem significativa das exportações de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanitário teria de imediato uma enorme repercussão econômica em nível local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Indígenas da Federação da Agricultura e Pecuária de Mato Grosso do Sul (Famasul) (DrQuintino:DesejoContato - DrQuintino:DesejoContatoDeImprensa). A tensão e a violência na região fez com que a Agência Estadual de Defesa Sanitária Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigilância e vacinação do rebanho das fazendas invadidas por índios guaranis, caiuás e ñandeva.

Quintino acrescentou a preocupação existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Missionário (Cimi), e favorecidos pela Fundação Nacional do Índio, segundo já foi documentado no relatório da CPI do Funai, na Câmara dos Deputados". O assessor da Famasul informou que os índios, contrariamente ao informado por alguns meios de imprensa, "não abandonaram nenhuma das 14 fazendas invadidas, e até o momento não permitiram o trabalho de perícia judicial para avaliar a destruição causada".

Brasília: deputado Zauith denúncia "manipulação" de índios

Também ontem, em Brasília, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da Câmara para "denunciar os conflitos indígenas" que vem ocorrendo em todo o País, incentivados pela "atuação de determinadas organizações internacionais, que chegam a ameaçar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os índios a invadir as propriedades rurais". Zauith acrescentou que esse "cenário devastador" já vem causando "uma retração nos investimentos no agronegócio em Mato Grosso do Sul", atividade que "é o principal pilar da economia sul-matogrossense" (DepZauith:DiscursoCompleto).

Santa Catarina: Cimi e Funai fomentam caos, diz Federação da Agricultura

A Federação da Agricultura do Estado de Santa Catarina (Faesc), em nota de repúdio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabeça por indígenas que ameaçavam invadir propriedades rurais, afirma que sua morte "revela a dramática dimensão a que chegaram os conflitos entre índios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organizações, motivadas por objetivos inconfessáveis, fomentam o embate e exasperam a crise, tentando criar um cenário de caos e desordem", sendo "notória, nesse aspecto, a ação do Conselho Indigenista Missionário (Cimi), cujos agentes imiscuem-se nas áreas indígenas para fomentar a discórdia". Enquanto a Fundação Nacional do Índio (Funai) oscila entre a inércia e a omissão, nada fazendo em favor da paz e da tranqüilidade", sendo sua atuação "marcada pela influência de ONGs" (Faesc:TextoCompleto).

040219AB / Atualidade Brasileira

 LINKS:

DrQuintino/Famasul:DesejoContato

DrQuintino/Famasul:DesejoContatoUrgente

DrQuintino/Famasul:DesejoContatoDeImprensa

DepZauith:DiscursoCompleto

Faesc:TextoCompleto

AtualidadeBrasileira:MinhaOpinião

AtualidadeBrasileira:Concordo

AtualidadeBrasileira:Discordo

AtualidadeBrasileira:DocumentaçãoUsada

AtualidadeBrasileira:Remover

A difusão deste comunicado, com uma finalidade exclusivamente informativa, é de responsabilidade da agência Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomendável, mas não necessário, citar a fonte.

 

 

From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 19 13:49:16 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 NAA14501 for ; Thu, 19 Feb 2004 13:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AttEa-00000H-00 for forces-archive@ietf.org; Thu, 19 Feb 2004 13:49:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AttDj-0007lu-00 for forces-archive@ietf.org; Thu, 19 Feb 2004 13:48:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AttCw-0007jW-00 for forces-archive@IETF.ORG; Thu, 19 Feb 2004 13:47:34 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CF18E0@cherry.ease.lsoft.com>; Thu, 19 Feb 2004 13:47:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2942942 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 19 Feb 2004 12:09:15 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Feb 2004 12:09:12 -0500 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.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1JHAwlk012772 for ; Thu, 19 Feb 2004 17:10:58 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.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1JHABSe025479 for ; Thu, 19 Feb 2004 17:10:37 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021909090923217 for ; Thu, 19 Feb 2004 09:09:09 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2004 09:09:09 -0800 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: Announcement: Open design team formed to examine possibility of merged protocol proposal Thread-Index: AcP3CxaqwAmfQgCiQ9KZehZl7vDXVQ== X-OriginalArrivalTime: 19 Feb 2004 17:09:09.0983 (UTC) FILETIME=[170B66F0:01C3F70B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD80264F739@orsmsx409.jf.intel.com> Date: Thu, 19 Feb 2004 09:09:09 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Announcement: Open design team formed to examine possibility of merged protocol proposal 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 All, In order to make progress on the protocol=20 selection process, Patrick & I would like=20 to examine whether a common protocol proposal is feasible. More specifically, we would like to see whether a merged proposal, based on the best aspects of each of the currently existing ForCES protocol proposals, can be made. In order to do this we are forming a short- lived design team that is chartered with=20 examining the aspects of the currently=20 existing protocol proposals, seeing what=20 common ground there is, and determining=20 whether the common ground is sufficient=20 for coming up with a single merged proposal. This design team is tasked with coming up with a report to the working group after one month's time, by March 20, 2004. =20 Patrick & I will be participating in the=20 design team to help make sure that good=20 progress is made. =20 Membership in this design team is open and we expect work to begin immediately. If you are interested in participating please email me or Patrick. =20 -David & Patrick From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 23 18:33:19 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 SAA02468 for ; Mon, 23 Feb 2004 18:33:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvPZh-0003VA-00 for forces-archive@ietf.org; Mon, 23 Feb 2004 18:33:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvPYQ-0003FC-00 for forces-archive@ietf.org; Mon, 23 Feb 2004 18:32:03 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AvPWS-0002tl-00 for forces-archive@IETF.ORG; Mon, 23 Feb 2004 18:30:00 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00D001C9@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 18:29:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3618242 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 18:29:52 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 18:29:52 -0500 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.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1NNVT7q006276 for ; Mon, 23 Feb 2004 23:31:30 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1NNV4uG007628 for ; Mon, 23 Feb 2004 23:31:08 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 M2004022315293626174 for ; Mon, 23 Feb 2004 15:29:36 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Feb 2004 15:29:42 -0800 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: No bonus Interim Meeting for ForCES @ IETF 59 Thread-Index: AcP6ZOJbEShvig2uSCOTITVYwLWy8A== X-OriginalArrivalTime: 23 Feb 2004 23:29:42.0561 (UTC) FILETIME=[E9F95110:01C3FA64] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD802704A05@orsmsx409.jf.intel.com> Date: Mon, 23 Feb 2004 15:29:33 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: No bonus Interim Meeting for ForCES @ IETF 59 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 All, As it turns out, of the people attending the Korea IETF, arrival and other schedules are varied enough that getting=20 sufficient ForCES participants together on Sunday for=20 productive work is not feasible. As such, there will be no *additional interim* ForCES meeting @ IETF 59. However, I encourage all attendees to try to get together at least at the reception to work on making protocol progress. That being said, ForCES *IS* scheduled for Tuesday, March 2 @ 0900, and that meeting will be held. Please plan=20 on attending! -David From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 10:33: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 KAA08608 for ; Fri, 27 Feb 2004 10:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwjzB-0004tV-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:33:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awjy1-0004es-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:31:58 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Awjwq-0004Qf-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 10:30:44 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00D07107@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 10:30:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4229165 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 10:30:42 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 10:30:42 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RFUee72925; Fri, 27 Feb 2004 10:30:40 -0500 (EST) Received: from goldspot.torrentnet.com (goldspot.torrentnet.com [4.18.161.89]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RFUdi63015; Fri, 27 Feb 2004 10:30:39 -0500 (EST) Received: from localhost (anurag@localhost) by goldspot.torrentnet.com (8.11.6/8.11.6) with ESMTP id i1RFUbR08944; Fri, 27 Feb 2004 10:30:37 -0500 X-Authentication-Warning: goldspot.torrentnet.com: anurag owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Anurag Bhargava Message-ID: Date: Fri, 27 Feb 2004 10:30:37 -0500 Reply-To: anurag.bhargava@ericsson.com Sender: Forwarding and Control Element Separation From: Anurag Bhargava Subject: ForCES model Comments: To: Zsolt.Haraszti@ericsson.com, steven.blake@ericsson.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=none autolearn=no version=2.60 Hello, I see that we have metadata Expected and metadata Produced in the schema in draft-ietf-forces-model-02.txt. I was wondering if we should also add an additional information which will give an idea that the metadata should be passed transparently. It will still be part of the above classes but will provide the LFB implementor that this metadata should be passed unmodified. This will impose the needed restricion. And in my mind could be part of the standard FE model Any comments.. -- anurag From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 10:40: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 KAA09328 for ; Fri, 27 Feb 2004 10:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awk6Q-0006JU-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awk5X-0006BS-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:39:44 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Awk4i-00062Z-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 10:38:52 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00D07263@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 10:38:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4234639 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 10:38:51 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 10:38:47 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1RFgAhu018457; Fri, 27 Feb 2004 15:42:10 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.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1RFe8kL021089; Fri, 27 Feb 2004 15:40:21 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 M2004022707384419136 ; Fri, 27 Feb 2004 07:38:44 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Feb 2004 07:38:44 -0800 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: ForCES model Thread-Index: AcP9Rq2yFWprqLwuThmtFOiieC7y6QAADwjA X-OriginalArrivalTime: 27 Feb 2004 15:38:44.0100 (UTC) FILETIME=[C8455C40:01C3FD47] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Yang, Lily L" Message-ID: <26BDFAFFB541B047B24179002EBE6D271560E4@orsmsx410.jf.intel.com> Date: Fri, 27 Feb 2004 07:38:43 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: ForCES model Comments: To: anurag.bhargava@ericsson.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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable That seems impossible to do -- because the metadata that an LFB passes transparently really depend on the other LFBS in the datapath, that is, the LFBS before and after this LFB in question. So the LFB itself does not have that knowledge at all prior to run time. But that is the kind of information the LFB itself (or the CE) can infer at run time, once the LFB topology is known.=20 For example, if LFB A, B, C (in that order) form the datapath, B has to pass whatever metadata that is produced by A and expected by C.=20 Right?=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava Sent: Friday, February 27, 2004 7:31 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: ForCES model Hello, I see that we have metadata Expected and metadata Produced in the schema in draft-ietf-forces-model-02.txt. I was wondering if we should also add an additional information which will give an idea that the metadata should be passed transparently. It will still be part of the above classes but will provide the LFB implementor that this metadata should be passed unmodified. This will impose the needed restricion. And in my mind could be part of the standard FE model Any comments.. -- anurag From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 10:54:19 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 KAA09921 for ; Fri, 27 Feb 2004 10:54:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkJh-00002D-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:54:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkIj-0007kD-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 10:53:22 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AwkHl-0007eU-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 10:52:21 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00D07209@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 10:52:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4235884 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 10:52:19 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 10:52:19 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RFqBe74264; Fri, 27 Feb 2004 10:52:11 -0500 (EST) Received: from goldspot.torrentnet.com (goldspot.torrentnet.com [4.18.161.89]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RFqAi64684; Fri, 27 Feb 2004 10:52:10 -0500 (EST) Received: from localhost (anurag@localhost) by goldspot.torrentnet.com (8.11.6/8.11.6) with ESMTP id i1RFqAV08966; Fri, 27 Feb 2004 10:52:10 -0500 X-Authentication-Warning: goldspot.torrentnet.com: anurag owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Anurag Bhargava Message-ID: Date: Fri, 27 Feb 2004 10:52:10 -0500 Reply-To: anurag.bhargava@ericsson.com Sender: Forwarding and Control Element Separation From: Anurag Bhargava Subject: Re: ForCES model Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <26BDFAFFB541B047B24179002EBE6D271560E4@orsmsx410.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=none autolearn=no version=2.60 I see your point. But if we look at it from the LFB's perspective. For example, LFB A expects metadata 1 and at the same time also needs to be passed on or produced so that it can be consumed at a later stage, having this information will be helpful. I don't know the topology but yet know that it will be used by later LFBs. For example, Meter LFB will use the frame length and also the Queue LFB. So, when we define Meter LFB, atleast in that definition, we can say that length metadata should be passed by this Meter LFB. But if the model doesn't provide this information, how will each LFB know. -- anurag On Fri, 27 Feb 2004, Yang, Lily L wrote: > That seems impossible to do -- because the metadata that an LFB passes > transparently really depend on the other LFBS in the datapath, that is, > the LFBS before and after this LFB in question. So the LFB itself does > not have that knowledge at all prior to run time. But that is the kind > of information the LFB itself (or the CE) can infer at run time, once > the LFB topology is known. > > For example, if LFB A, B, C (in that order) form the datapath, B has to > pass whatever metadata that is produced by A and expected by C. > > Right? > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava > Sent: Friday, February 27, 2004 7:31 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: ForCES model > > Hello, > > I see that we have metadata Expected and metadata Produced in the > schema > in draft-ietf-forces-model-02.txt. > > I was wondering if we should also add an additional information which > will give an idea that the metadata should be passed transparently. It > will still be part of the above classes but will provide the LFB > implementor > that this metadata should be passed unmodified. This will impose the > needed > restricion. And in my mind could be part of the standard FE model > > Any comments.. > > -- > anurag > From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 11:12:34 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 LAA10824 for ; Fri, 27 Feb 2004 11:12:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwkbM-0001v7-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 11:12:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwkaP-0001of-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 11:11:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Awka2-0001iB-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 11:11:14 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00D0733F@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 11:11:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4239165 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 11:11:13 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 11:11:12 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RGB7E75483; Fri, 27 Feb 2004 11:11:07 -0500 (EST) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RGB7G66359; Fri, 27 Feb 2004 11:11:07 -0500 (EST) Received: from ericsson.com (oasis.torrentnet.com [198.78.51.102]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id i1RGB6T09313; Fri, 27 Feb 2004 11:11:06 -0500 (EST) User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <403F6BA7.1060702@ericsson.com> Date: Fri, 27 Feb 2004 11:09:11 -0500 Reply-To: zsolt.haraszti@ericsson.com Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Subject: Re: ForCES model Comments: To: anurag.bhargava@ericsson.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: 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 Anurag, It is a default behavior of any LFB to pass all "un-interesting" metadata transparently. Any metadata that is not explicitly or implicitly used (read/produced) by the LFB fall into this category. This should be in the draft somewhere. Some implementations will have inherent physical limitations and will not be able to provide this default behavior. We are currently looking into if and how such limitations should be expressed by via the model. Suggestions are welcome. /zsolt Anurag Bhargava wrote: > I see your point. But if we look at it from the LFB's perspective. For > example, LFB A expects metadata 1 and at the same time also needs to be > passed on or produced so that it can be consumed at a later stage, having > this information will be helpful. I don't know the topology but yet know > that it will be used by later LFBs. > > For example, > Meter LFB will use the frame length and also the Queue LFB. So, when we > define Meter LFB, atleast in that definition, we can say that length > metadata should be passed by this Meter LFB. But if the model doesn't > provide this information, how will each LFB know. > > -- > anurag > > On Fri, 27 Feb 2004, Yang, Lily L wrote: > > >>That seems impossible to do -- because the metadata that an LFB passes >>transparently really depend on the other LFBS in the datapath, that is, >>the LFBS before and after this LFB in question. So the LFB itself does >>not have that knowledge at all prior to run time. But that is the kind >>of information the LFB itself (or the CE) can infer at run time, once >>the LFB topology is known. >> >>For example, if LFB A, B, C (in that order) form the datapath, B has to >>pass whatever metadata that is produced by A and expected by C. >> >>Right? >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Anurag Bhargava >>Sent: Friday, February 27, 2004 7:31 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: ForCES model >> >>Hello, >> >> I see that we have metadata Expected and metadata Produced in the >>schema >>in draft-ietf-forces-model-02.txt. >> >> I was wondering if we should also add an additional information which >>will give an idea that the metadata should be passed transparently. It >>will still be part of the above classes but will provide the LFB >>implementor >>that this metadata should be passed unmodified. This will impose the >>needed >>restricion. And in my mind could be part of the standard FE model >> >>Any comments.. >> >>-- >>anurag >> > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 12:12:21 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 MAA14546 for ; Fri, 27 Feb 2004 12:12:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlXD-00022U-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 12:12:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlWF-0001xB-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 12:11:24 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AwlVH-0001rf-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 12:10:23 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00D07349@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 12:10:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4234591 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 12:10:17 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 12:10:17 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1RHCDVB007367 for ; Fri, 27 Feb 2004 17:12:13 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1RHBRGx006248 for ; Fri, 27 Feb 2004 17:12:26 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004022709101529083 for ; Fri, 27 Feb 2004 09:10:15 -0800 Received: from fmsmsx405.amr.corp.intel.com ([132.233.42.209]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Feb 2004 09:10:15 -0800 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: I-D ACTION:draft-ietf-forces-model-02.txt Thread-Index: AcP1bI1NyR5tBbcXSJ2r8odHJWVLJQABoXHwAfhHhuA= X-OriginalArrivalTime: 27 Feb 2004 17:10:15.0542 (UTC) FILETIME=[916CE960:01C3FD54] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Cain, Gamil" Message-ID: <89597CBB41D2094A81EAD6C801D5322104511853@fmsmsx405.fm.intel.com> Date: Fri, 27 Feb 2004 09:10:15 -0800 Reply-To: "Cain, Gamil" Sender: Forwarding and Control Element Separation From: "Cain, Gamil" Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt Comments: To: "Yang, Lily L" 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Lily et all, Here's my feedback on the latest FE model: - Section 2.4, first sentence is a bit confusing and should probably be broken into two sentences. - Section 3.2.3, the first paragraph mentions "frame type". I would suggest staying consistent with terms. Either use "frame type" or "packet type" but not both. - Last paragraph before section 3.2.4.3, is this "harmonization" out of scope for ForCES? Does ForCES assume this is something that will be taken up by some external organization (i.e. NPF)? Section 4.5.3 and 4.5.4 should probably be swapped in the document. Section 4.5.3 makes use of the element before it's formally described in section 4.5.4 Section 4.5.6: The augmentation concept could be described a bit clearer. What advantage does this concept have over using the schema elements already defined (, , , etc.)? Section 4.7, last paragraph: How useful is a schema for an LFB class that only contains the name, synopsis, and version? It might be good to add some text to this paragraph saying that it is expected that a class definition will have more then just these three elements. Section 4.7.2: Third paragraph is a repeat of the last sentence of the first paragraph. Section 4.7.3: Does the LFB class need to also specify what metadata it passes through? I would think not, but it might be good to add a paragraph describing the LFB classes behavior wrt pass-through metadata. Section 4.7.5: Is there (or should there be) a requirement for an instance of an LFB class to specify capabilities for all attributes it supports? If not, should there at least be some guidance in this document that describes what types of capability information should be exposed? Section 6.1: What is meant by the static attribute "port type"? Examples would be helpful. Section 6.1: In some devices, the physical port link speed is a configurable, as opposed to static, attribute (e.g. a framer that can do DS3 and OC-3 or OC-12). How would one go about modeling such a device, using the current Port LFB class definition? Or would you not model such a device as a single LFB, but rather as multiple LFBs that can be enabled/disabled (e.g. a DS3 Port LFB, a OC-3 Port LFB, etc. all managing the same physical device)? Section 8.6, 2nd paragraph: There's a reference to a section 9.5 which does not exist. Regards, Gamil Cain Software Architect Intel Research & Development 916.356.9153 mailto:gamil.cain@intel.com =20 >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L >Sent: Tuesday, February 17, 2004 8:49 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt > >Hi, all -- > >The FE model design team just published v02 of the FE model document. >The entire document has been edited throughout, but most notably some >major progress has been reflected in this revision: >1) 3.2.4 "metadata" section is completely rewritten, with the metadata >model that was published to this list by Zsolt a few weeks ago. We >believe most comments we've received so far are addressed in this >revision. >2) Section 4 "model and schema for LFB classes" is rewritten, with >formal XML schema specified at the end of the section. >3) Section 5 "FE Attributes and Capabilities" now is completed with also >formal XML schema specification, that was also published to the list a >few weeks ago by Joel. >4) The old section 6 in v01 was a place holder for LFB topology and now >gone because the content of LFB topology is merged into "FE attributes >and Capabilities" in Section 5. The comments we received are also >incorporated into this new revision. >5) Section 6 "LFB Class Library" (old section 7 in v01) is also revised >significantly with now 18 LFB classes that include the most commonly >found functions for IP processing, forwarding and QoS. >6) Section 7 "satisfying the requirements" (old section 8 in v01) is >also revised considerably. > >With this revision, the major pieces that make up the FE model are now >in place, with the exception of a few minor features here and there >(e.g., class inheritance is not fully flushed out in the LFB schema). We >hope this revision would provide timely input into the protocol >development. In the meantime, we hope the WG and especially the protocol >designers would take time to review and provide feedback on the FE >model, so that we can refine it to the satisfaction of the WG in the >next few months. > > >Thank you all, > >Lily > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of >Internet-Drafts@ietf.org >Sent: Tuesday, February 17, 2004 7:32 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: I-D ACTION:draft-ietf-forces-model-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Forwarding and Control Element >Separation Working Group of the IETF. > > Title : ForCES Forwarding Element Functional Model > Author(s) : L. Yang > Filename : draft-ietf-forces-model-02.txt > Pages : 101 > Date : 2004-2-17 > >This document defines the forwarding element (FE) model used in the >Forwarding and Control Plane Separation (ForCES) protocol. The >model represents the capabilities, state and configuration of >forwarding elements within the context of the ForCES protocol, so >that control elements (CEs) can control the FEs accordingly. More >specifically, the model describes the logical functions that are >present in an FE, what capabilities these functions support, and >how these functions are or can be interconnected. This FE model is >intended to satisfy the model requirements specified in the ForCES >requirements draft [1]. A list of the basic logical functional >blocks (LFBs) is also defined in the LFB class library to aid the >effort in defining individual LFBs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the >message. > >Internet-Drafts are also available by anonymous FTP. Login with the >username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-forces-model-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-forces-model-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail >readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 27 14:29:27 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 OAA19283 for ; Fri, 27 Feb 2004 14:29:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awnfs-0002GG-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 14:29:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awney-0002AF-00 for forces-archive@ietf.org; Fri, 27 Feb 2004 14:28:33 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Awne2-000248-00 for forces-archive@IETF.ORG; Fri, 27 Feb 2004 14:27:34 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00D0768D@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 14:27:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4248611 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 14:27:32 -0500 Received: from 198.78.51.110 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 14:27:31 -0500 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RJROV88193; Fri, 27 Feb 2004 14:27:24 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id i1RJRMg81984; Fri, 27 Feb 2004 14:27:22 -0500 (EST) Received: from empress.torrentnet.com (empress.torrentnet.com [4.18.161.79]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id OAA06257; Fri, 27 Feb 2004 14:27:17 -0500 (EST) Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-Transfer-Encoding: 7bit Approved-By: Zsolt Haraszti Message-ID: <1077910037.14033.16.camel@empress.torrentnet.com> Date: Fri, 27 Feb 2004 14:27:17 -0500 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Organization: Ericsson IPI Subject: FACT draft truncated on ForCES website Comments: To: David Putzolu , Patrick Droz 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit David, Patrick, The FACT protocol I-D (ver 06) is corrupted at the ForCES website. The document ends at page 7. I presume this is the current draft version. /zsolt From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 29 19:49:13 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 TAA19335 for ; Sun, 29 Feb 2004 19:49:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxbcP-0004fC-00 for forces-archive@ietf.org; Sun, 29 Feb 2004 19:49:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxbbQ-0004ad-00 for forces-archive@ietf.org; Sun, 29 Feb 2004 19:48:14 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1AxbaS-0004Ru-00 for forces-archive@IETF.ORG; Sun, 29 Feb 2004 19:47:12 -0500 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00D0A94E@cherry.ease.lsoft.com>; Mon, 1 Mar 2004 19:47:05 +1900 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4528920 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 29 Feb 2004 19:47:03 -0500 Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 29 Feb 2004 19:47:03 -0500 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.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i210oVwW000479 for ; Mon, 1 Mar 2004 00:50:31 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i210fhrV010387 for ; Mon, 1 Mar 2004 00:41:44 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 M2004022916470005168 for ; Sun, 29 Feb 2004 16:47:00 -0800 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 Feb 2004 16:47:00 -0800 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: Feedback on ForCES Model v02 Thread-Index: AcP1bI1NyR5tBbcXSJ2r8odHJWVLJQABoXHwAGinHvA= X-OriginalArrivalTime: 01 Mar 2004 00:47:00.0285 (UTC) FILETIME=[B4C056D0:01C3FF26] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Approved-By: "Putzolu, David" Message-ID: <52D13A805349A249960B9943E5590BD8027C601F@orsmsx409.jf.intel.com> Date: Sun, 29 Feb 2004 16:46:59 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Feedback on ForCES Model v02 Comments: To: "Yang, Lily L" 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 [hat off] Hi Lily et al. Just finished reading the draft, below is my feedback. Abstract: "Forwarding and Control Plane Separation" should be "Forwarding and Control *Element* Separation" - oops! LFB metadata definition: It seems to me that implementations might do more than encode metadata differently, they might transport it differently (i.e. if a FE has a classification processor and a traffic management processor, they might use a shared memory region, or a streaming interface, or some other interface to share metadata) or they might not even have the metadata at all (i.e. if a NPU performs both classification and traffic shaping, but directly associates classification entries --> traffic shaping entries, it might not even have the metadata in the actual fast path, but instead use the metadata to setup the entries). Maybe say: The FE model defines how such metadata is identified,=20 produced and consumed by the LFBs, but not how metadata=20 is encoded within an implementation. , "identified, produced and consumed by the LFBs, but not how per-packet=20 state is implemented within actual hardware" Section 2.3 says: Definition of the various payloads of ForCES messages=20 (irrespective of the transport protocol ultimately selected)=20 cannot proceed in a systematic fashion until a formal=20 definition of the objects being configured and managed (the=20 FE and the LFBs within) is undertaken.=20 This paragraph confused me a bit. My belief is that one *can* proceed in defining how LFBs are carried, identified, and queried, without having to specify that a scheduler uses a 64 bit unsigned int for representing minimum service rate in bits per second. This is analogous to how SNMP protocol messages could be defined before all MIBs where defined. Page 12 shows "internal control" in the figure. This is confusing because the LFBs are still part of the ForCES model of the actual FE implementation. Perhaps say "LFB manipulation" or "per-LFB interactions" here? Page 13 replace "new LFB class can" with "new LFB classes can" Section 3.2.1 Input group is confusing to me. If it is only a way of identifying which LFB sourced a packet to another FE, which not simply assert that LFBs are able to determine which input connection # a packet arrived on? Does input group offer anything more than this? =20 Section 3.2.2 It isn't clear what the use of an output group is. How would a FE or LFB use it? LPM is the example=20 given but doesn't make sense. If the LFB classifies a packet=20 it will likely have a specific next LFB connection to send=20 it on. The alternative is to just say "send this packet on=20 that output group" - but that makes for unpredictable / unspecified behavior, which is (correctly) identified as=20 undesirable. Section 3.2.3 bottom of page 16: The underlying=20 implementation may not be passing the packet at=20 all. E.g. an IP packet in an PPPoverATMAAL5 frame might=20 actually consist of a scattered bunch of pointers to=20 pieces of the packet. I'd suggest just shortening the=20 2nd paragraph to say: "logically operates on, but this has no implications on how packets are stored or moved in the underlying implementation." Section 3.2.3 bottom of page 17: Isn't it possible that the underlying implementation not actually have metadata in the fast path? E.g. LFB 1 may associate metadata with a packet: Address/mask: 10.0.0.0/255.0.0.0 --> metadata for next hop 1 and LFB 2 might associate that metadata with some action: packet w/metadata value 1 --> send out port 3 But the underlying implementation might not have any metadata in the fast path, e.g.: Address/mask 10.0.0.0/255.0.0.0 --> send out port 3 Admittedly, there is software in between that stores the metadata to then "cook" the data into the hardware representation, but the point is the hardware may not even have metadata. So I'd suggest saying: "While it is important to define the metadata types passing between LFBs, it is not necessary to define the encoding mechanism used for LFBs for that metadata. As with the ForCES model in general, no constraints are placed on underlying FE implementation of metadata as long as the FE behaves in a fashion that one would predict given a particular metadata=20 configuration. In the next paragraph the term marking is overloaded. Replace "marked" with "associated". 3.2.4.1 Forwarded is overloaded. Replace "forwarded=20 by the LFB" with "passed on to the next LFB". 3.2.4.2 Why must there be at least one producer and one consumer? While I can see the need for a=20 consumer to require an upstream producer (aside: it would be better if each metadata consumer LFB, even=20 non-optional ones, also specify what happens if the=20 expected metadata is not present), there is no real=20 need for each producer require a down graph consumer. 3.2.5 last para: Why are FEs disallowed from supporting multiple versions of a particular class?=20 3.3.1 While hardware could influence topology, I think it is more important that the data path be modeled in a clear fashion. If a single hardware classifier is=20 used for two logically different classifications (e.g. in IP in IP tunneling, one classification on the outer, another on the inner DIP), that still would be better represented as two separate LFB instances, unless one specifically wants to reuse the same classification=20 entries (e.g. an ACL where any access to certain ports is to be blocked, whether on the inside or outside of an IPinIP or IPsec tunnel mode connection). 3.3.1 Page 28/9 It says "One way to encode...". Not=20 sure of the relevance of that. Is it the suggested mechanism or the actual mechanism used in this document? If so say so! 4.7 Re: editor's note: Should LFB class names=20 be managed by IANA? 4.7.2 Re: Omitting the tag when a LFB has no input ports - what about having a reserved "None" value? Explicitly using a "none" statement tends to catch=20 errors better than omission of the statement,=20 which can happen by mistake and be a difficult bug to catch. 4.7.3 Same comment 5.2.1.1 Make it mandatory that the element be present - same reasoning as above, minimizes errors of omission. 5.2.2.4.1 Don't understand what namespace this is. FE has no way of knowing what names the CE is assigning to other FEs, so this must be something that the other FEs communicate to the FE - should be a valid identifier prior to CE<->FE connection, otherwise this becomes a chicken & egg problem. Each FE should have some unique ID - maybe just use a MAC address perhaps that the FE owns. Or is this what 5.2.2.4.4 is? Section 6 general comment: This seems to be a very good start on the following charter deliverable: o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task. I remember some discussion about splitting this off. Do you think this should remain in the base model draft,=20 or should it be split off as a separate doc/draft? Section 6 general comment: Some ASCII art of each of the LFBs showing inputs, outputs, etc., would be=20 helpful. 6.1 Ports are tricky things. If a single LFB represents both send and receive then all FE graphs will look like cycles, which is rather confusing (and hard for a machine to parse). Of course, splitting ports also is confusing - if one downed a receive LFB it would down the whole port, affecting the transmit LFB as well. This isn't a new issue, but the doc doesn't really explain how it will be addressed - better to put a stake in the ground one way or the other. 6.2 Same comment applies 6.5 The bullet ". that is maintained at a downstream LFB" appears out of context, what is it referring to? 6.8 mentions a "Modifier LFB" that is not explained or mentioned elsewhere. 3.2.4 Mentions a Header Modifier LFB that is also not mentioned elsewhere - should both of these be "Packet Header Rewriter LFB"? 6.9 mentions packet length metadata (also 6.6 and 6.13) -=20 this is not really explained. Since it is associated with all packets, it seems like it need not really=20 be called out as metadata (perhaps treat it as implicit metadata that all LFBs know about, just as all LFBs can implicitly see the contents of the packet). An alternative would be to say that every packet has special RO metadata always associated with it such as length. 6.17 Why are encapsulation & decapsulation together in one LFB? Seems confusing - isn't encap & decap usually separate functions, performed on separate packet streams? 8.7 Need to address what happens to packets arriving at/ transiting a FE during reconfiguration. Do they get=20 dropped on disconnected inter-LFB links? Start filling queues? Something else? 10. A model-specific security issue that should be mentioned is the risk of misconfiguring a LFB graph resulting in insecure behaviors. Having software on a CE reconfigure=20 a LFB graph is a very easy way to shoot yourself in the foot. That's all I had. Overall this document is looking very good, once the remaining editor's notes are addressed and the WG has had a chance to properly review it I think it will be ready to proceed. -David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Yang, Lily L > Sent: Tuesday, February 17, 2004 8:49 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] I-D ACTION:draft-ietf-forces-model-02.txt >=20 > Hi, all -- >=20 > The FE model design team just published v02 of the FE model document. > The entire document has been edited throughout, but most notably some > major progress has been reflected in this revision: > 1) 3.2.4 "metadata" section is completely rewritten, with the metadata > model that was published to this list by Zsolt a few weeks ago. We > believe most comments we've received so far are addressed in this > revision. > 2) Section 4 "model and schema for LFB classes" is rewritten, with > formal XML schema specified at the end of the section. > 3) Section 5 "FE Attributes and Capabilities" now is=20 > completed with also > formal XML schema specification, that was also published to the list a > few weeks ago by Joel. > 4) The old section 6 in v01 was a place holder for LFB=20 > topology and now > gone because the content of LFB topology is merged into "FE attributes > and Capabilities" in Section 5. The comments we received are also > incorporated into this new revision. > 5) Section 6 "LFB Class Library" (old section 7 in v01) is=20 > also revised > significantly with now 18 LFB classes that include the most commonly > found functions for IP processing, forwarding and QoS. > 6) Section 7 "satisfying the requirements" (old section 8 in v01) is > also revised considerably. >=20 > With this revision, the major pieces that make up the FE model are now > in place, with the exception of a few minor features here and there > (e.g., class inheritance is not fully flushed out in the LFB=20 > schema). We > hope this revision would provide timely input into the protocol > development. In the meantime, we hope the WG and especially=20 > the protocol > designers would take time to review and provide feedback on the FE > model, so that we can refine it to the satisfaction of the WG in the > next few months. >=20 >=20 > Thank you all, >=20 > Lily >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 17, 2004 7:32 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: I-D ACTION:draft-ietf-forces-model-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Forwarding and Control Element > Separation Working Group of the IETF. >=20 > Title : ForCES Forwarding Element Functional Model > Author(s) : L. Yang > Filename : draft-ietf-forces-model-02.txt > Pages : 101 > Date : 2004-2-17 >=20 > This document defines the forwarding element (FE) model used in the > Forwarding and Control Plane Separation (ForCES) protocol. The > model represents the capabilities, state and configuration of > forwarding elements within the context of the ForCES protocol, so > that control elements (CEs) can control the FEs accordingly. More > specifically, the model describes the logical functions that are > present in an FE, what capabilities these functions support, and > how these functions are or can be interconnected. This FE model is > intended to satisfy the model requirements specified in the ForCES > requirements draft [1]. A list of the basic logical functional > blocks (LFBs) is also defined in the LFB class library to aid the > effort in defining individual LFBs. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-forces-model-02.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-forces-model-02.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need=20 > "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have=20 > been split > up into multiple messages), so check your local=20 > documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20