From owner-forces@PEACH.EASE.LSOFT.COM Mon May 2 08:51:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13115 for ; Mon, 2 May 2005 08:51:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSaby-0002xd-5V for forces-archive@IETF.ORG; Mon, 02 May 2005 09:05:23 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0102FB65@cherry.ease.lsoft.com>; Mon, 2 May 2005 8:51:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68948212 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 08:51:06 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 2 May 2005 08:50:10 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050205504590:36153 ; Mon, 2 May 2005 05:50:45 -0700 References: <9D277E44D6EF0942B928C6F0DE99BB31B97192@lan-ex-01.panasonic.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2005 05:50:46 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2005 05:50:48 AM, Serialize complete at 05/02/2005 05:50:48 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115038206.8929.271.camel@localhost.localdomain> Date: Mon, 2 May 2005 08:50:06 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Question on scope Comments: To: Jose Rey To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B97192@lan-ex-01.panasonic.de> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Jose, Apologies that noone had responded to you so far. On Fri, 2005-29-04 at 10:13 +0200, Jose Rey wrote: > I went through the charter and over some of the drafts and I don't know yet > if I get it right. I understand that the aim is to separate control and transport, > that much is clear. Additionally, some QoS functionality is implemented in the forwarding > entities. But, is it also planned to include more advanced functionalities > like transcoding, metering, intelligent packet dropping (e.g., only P frames) in those FEs?? > Related to that: the > charter talks about per-packet processing but does this processing stop at layer 4 ? The end goal is to provide generic enough functionality in the protocol and the modeling "language" such that you should be able to model and then configure any forwarding path element in existence in variety of future and existing FEs. Although some basic LFBs that are mentioned in the charter will be described - they merely exist to validate that the protocol and the modelling "language". As an example, at the moment i am using the LFB model to describe IPSEC FEs and configuring them using Forces (it is not listed in the charter but the model and protocol are sufficient for it). Hopefully this answers your questions. If theres any objection to my response to you from other people you should hear from them. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon May 2 10:41:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22583 for ; Mon, 2 May 2005 10:41:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DScKm-000589-6s for forces-archive@IETF.ORG; Mon, 02 May 2005 10:55:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0102FC94@cherry.ease.lsoft.com>; Mon, 2 May 2005 10:41:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68972985 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 10:41:21 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 2 May 2005 10:40:26 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050207410234:36239 ; Mon, 2 May 2005 07:41:02 -0700 References: <9D277E44D6EF0942B928C6F0DE99BB31B972AE@lan-ex-01.panasonic.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2005 07:41:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2005 07:41:03 AM, Serialize complete at 05/02/2005 07:41:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115044822.22245.15.camel@localhost.localdomain> Date: Mon, 2 May 2005 10:40:22 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Question on scope Comments: To: Jose Rey To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B972AE@lan-ex-01.panasonic.de> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Joes, On Mon, 2005-02-05 at 16:07 +0200, Jose Rey wrote: > Thanks for you answers. Actually Joel answered. I paste the offline traffic below. > > Summarising the thread below, it seems that you target at making the task of > policy-routing much easier and as far as possible automated (challenging!). It depends on what you mean by policy routing. If it is what Jpel describes in his email as "arranging the LFB instance graph and classifier tables" then yes. If by routing you mean L3, then thats a small subset of the larger picture. Forces also is constrained within the scope of an NE. > This controlled entities (FEs) would include things as interesting as transcoders, > packet droppers and so on, thus not limited to L4 functionality. Indeed. Essentially, intelligence on the CE decides what LFB building blocks to use and then instantiates them interconnected via a graph. The graph edges may be constrained by the limits of what the LFB block can connect to (as discovered during capability exchange). So if the blocks constitute of L2 processing, G711 RTP vocoding, IPSEC etc, shouldnt matter. What matters is you can formally describe these blocks - i should say formally describe their parametrization - using the LFB "language" as defined by the model; if you can do that then the protocol can configure them. Does that make sense? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon May 2 11:38:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26646 for ; Mon, 2 May 2005 11:38:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdEH-0006Cf-Cp for forces-archive@IETF.ORG; Mon, 02 May 2005 11:53:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0102FE79@cherry.ease.lsoft.com>; Mon, 2 May 2005 11:38:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68982107 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 11:38:53 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 194.173.20.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 2 May 2005 10:52:39 -0400 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 48a4_bdbb351a_bb23_11d9_9443_003048253456; Mon, 02 May 2005 18:03:35 +0200 (CEST) Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005050216521587-12423 ; Mon, 2 May 2005 16:52:15 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de; Mon, 2 May 2005 16:53:27 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on scope Thread-Index: AcVPJNXk6Ync3wGXQu2A6VrGYjbixAAAGfjg Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B972C5@lan-ex-01.panasonic.de> Date: Mon, 2 May 2005 16:51:05 +0200 Reply-To: Jose Rey Sender: Forwarding and Control Element Separation From: Jose Rey Subject: Re: Question on scope Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Jamal, > Joes, >=20 > On Mon, 2005-02-05 at 16:07 +0200, Jose Rey wrote: >=20 > > Thanks for you answers. Actually Joel answered. I paste=20 > the offline traffic below. > >=20 > > Summarising the thread below, it seems that you target at=20 > making the=20 > > task of policy-routing much easier and as far as possible=20 > automated (challenging!). >=20 > It depends on what you mean by policy routing. If it is what=20 > Jpel describes in his email as "arranging the LFB instance=20 > graph and classifier tables" then yes. If by routing you mean=20 > L3, then thats a small subset of the larger picture. > Forces also is constrained within the scope of an NE.=20 >=20 With routing, yes, I meant basically L3 routing.=20 > > This controlled entities (FEs) would include things as=20 > interesting as=20 > > transcoders, packet droppers and so on, thus not limited=20 > to L4 functionality. >=20 > Indeed.=20 > Essentially, intelligence on the CE decides what LFB building=20 > blocks to use and then instantiates them interconnected via a graph. > The graph edges may be constrained by the limits of what the=20 > LFB block can connect to (as discovered during capability=20 > exchange). So if the blocks constitute of L2 processing, G711=20 > RTP vocoding, IPSEC etc, shouldnt matter. What matters is you=20 > can formally describe these blocks > - i should say formally describe their parametrization -=20 > using the LFB "language" as defined by the model; if you can=20 > do that then the protocol can configure them. Does that make sense? It does to me (although my knowledge of the drafts is limited :) Cheers, Jos=E9 From owner-forces@PEACH.EASE.LSOFT.COM Mon May 2 11:38:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26664 for ; Mon, 2 May 2005 11:38:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdEI-0006Cf-AO for forces-archive@IETF.ORG; Mon, 02 May 2005 11:53:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0102FC9C@cherry.ease.lsoft.com>; Mon, 2 May 2005 11:38:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68982106 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 2 May 2005 11:38:51 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 194.173.20.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 2 May 2005 10:08:26 -0400 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 489f_91a63fb6_bb1d_11d9_8bdb_003048253456; Mon, 02 May 2005 17:19:29 +0200 (CEST) Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005050216075784-11294 ; Mon, 2 May 2005 16:07:57 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de; Mon, 2 May 2005 16:09:11 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on scope Thread-Index: AcVPFW6h6Iw044TSRdOp8JrNrNFOtgACO5GA Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B972AE@lan-ex-01.panasonic.de> Date: Mon, 2 May 2005 16:07:25 +0200 Reply-To: Jose Rey Sender: Forwarding and Control Element Separation From: Jose Rey Subject: Re: Question on scope Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable =20 Hi Jamal, Thanks for you answers. Actually Joel answered. I paste the offline = traffic below. Summarising the thread below, it seems that you target at making the = task of policy-routing much easier and as far as possible automated = (challenging!). This controlled entities (FEs) would include things as = interesting as transcoders, packet droppers and so on, thus not limited = to L4 functionality. Cheers, Jos=E9=20 >=20 > Hi Jose, > Apologies that noone had responded to you so far. >=20 > On Fri, 2005-29-04 at 10:13 +0200, Jose Rey wrote: >=20 > > I went through the charter and over some of the drafts and I don't=20 > > know yet if I get it right. I understand that the aim is=20 > to separate=20 > > control and transport, that much is clear. Additionally, some QoS=20 > > functionality is implemented in the forwarding entities. =20 > But, is it=20 > > also planned to include more advanced functionalities like=20 > transcoding, metering, intelligent packet dropping (e.g.,=20 > only P frames) in those FEs?? > > Related to that: the > > charter talks about per-packet processing but does this=20 > processing stop at layer 4 ? >=20 > The end goal is to provide generic enough functionality in=20 > the protocol and the modeling "language" such that you should=20 > be able to model and then configure any forwarding path=20 > element in existence in variety of future and existing FEs. >=20 > Although some basic LFBs that are mentioned in the charter=20 > will be described - they merely exist to validate that the=20 > protocol and the modelling "language". As an example, at the=20 > moment i am using the LFB model to describe IPSEC FEs and=20 > configuring them using Forces (it is not listed in the=20 > charter but the model and protocol are sufficient for it). >=20 > Hopefully this answers your questions. If theres any=20 > objection to my response to you from other people you should=20 > hear from them. >=20 > cheers, > jamal > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, April 29, 2005 3:21 PM > To: Jose Rey > Subject: RE: Question on scope >=20 > That is the idea. > If you have a ForCES FE with classifiers, QoS capabilities,=20 > IPSec, etc, then your CE can apply any available capabilities=20 > to subscribers traffic by arranging the LFB instance graph=20 > and classifier tables. >=20 > Now, there are lots of caveats. The big one is that=20 > determining how a specific kind of FE really can be used to=20 > deliver a specific service probably requires a human being to=20 > do the analysis, and then inform the CE of what constructs to=20 > build. This is because there is such a range in the way FEs=20 > can instantiate LFB classes and LFB instances. (Some FEs=20 > will have LFBs with tables of entries. Others will have=20 > individual LFBs for different cases. Some FEs will have=20 > static LFB instance topology, while others will allow almost=20 > any topology to be built.) We have attempted to build in=20 > enough information that a CE who can work with several=20 > different techniques can at least determine what tools it has=20 > available from the FE. >=20 > Jamal is working right now on an IPSec LFB class definition=20 > to see whether the LFB definition approach and details we=20 > have will work for that case. > We need to define quite a few LFB classes just to have a=20 > minimally useful set. >=20 > Yours, > Joel M. Halpern >=20 > At 07:54 AM 4/29/2005, you wrote: > >[I haven't fwd'ed to the list since you also didn't] > > > >Joel, > > > >Thanks a lot for your answers. I think this helps. Let me=20 > ask you one=20 > >more thing to be sure we don't talk past each other: in other words,=20 > >Forces will allow me to define routing paths (L3, IP=20 > addresses or other > >locators) that use specific resources (L4, L5 and above: txcoder,=20 > >meter) and in a strict order without having to resort to less=20 > >Internet-friendly things like SIP 3rd party call control ? > > > >This seems to be a perfect platform for services that require=20 > >policy-based routing ? No? or am I way out here? > > > >Thanks again, > > > >Jos=E9 > > > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: Friday, April 29, 2005 1:03 PM > > > To: Jose Rey > > > Subject: Re: Question on scope > > > > > > That is a reasonable question. > > > My view of the answer has two parts. > > > Firstly, the ForCES protocol design has to allow for arbitrary=20 > > > capabilities being handled by the FE on behalf of the CE.=20 > This can=20 > > > include all of the examples you listed, IPSec, and many more. > > > Secondly, the initial ForCES specification has to come out with a=20 > > > library of LFBs that is sufficient to be useful, but not so large=20 > > > that we don't get the task done. Therefore, most of=20 > those examples=20 > > > will not be addressed explicitly by the first LFB library=20 > > > specification. It is anticipated that additional LFB library=20 > > > documents will be written later. > > > > > > I hope that helps, > > > Yours, > > > Joel M. Halpern > > > > > > At 04:13 AM 4/29/2005, you wrote: > > > >Hi all, > > > > > > > >I am a newbie to the list. I apologize in advance if anything=20 > > > >inappropriate or repeated is asked. > > > > > > > >I went through the charter and over some of the drafts and I > > > don't know > > > >yet if I get it right. I understand that the aim is to separate=20 > > > >control and transport, that much is clear. =20 > Additionally, some QoS=20 > > > >functionality is implemented in the forwarding entities.=20 > But, is=20 > > > >it also planned to include more advanced functionalities like > > > transcoding, > > > >metering, intelligent packet dropping (e.g., only P frames) in=20 > > > >those FEs?? Related to that: the charter talks about per-packet=20 > > > >processing but does this processing stop at layer 4 ? > > > > > > > >Thanks, > > > > > > > >Jos=E9 > > > > > > > > =20 From owner-forces@PEACH.EASE.LSOFT.COM Tue May 3 08:29:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11576 for ; Tue, 3 May 2005 08:29:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSwkb-0007rz-Tb for forces-archive@IETF.ORG; Tue, 03 May 2005 08:43:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010315E0@cherry.ease.lsoft.com>; Tue, 3 May 2005 8:29:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69100315 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 08:29:23 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 3 May 2005 08:29:22 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050305295720:37391 ; Tue, 3 May 2005 05:29:57 -0700 References: <9D277E44D6EF0942B928C6F0DE99BB31B97308@lan-ex-01.panasonic.de> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2005 05:29:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2005 05:29:59 AM, Serialize complete at 05/03/2005 05:29:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115123357.26614.31.camel@localhost.localdomain> Date: Tue, 3 May 2005 08:29:17 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Question on scope Comments: To: Jose Rey To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31B97308@lan-ex-01.panasonic.de> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Joes, On Tue, 2005-03-05 at 10:07 +0200, Jose Rey wrote: > As I understand, basically you got a 'processing graph' which eventually (after applying > the 'logic') gives you a 'processing path' and then you need the L3 route anyway, no? > > > I guess that for the "LFB arrangement" you don't use L3 routing but you do for the > inter-NE connections. Depends if the NE is doing L3. If it is, the rule of thumb imposed is " thous shalt not decrement ttl more than once". So a packet coming in on a port on FE1 to be L3 forwarded on a port on FE2 shall have its ttl only decremented once. As an example of "LFB arrangement", if you take the model draft example from figure 10: +-----------------------------------------------------+ | +---------+ +------------+ +---------+ | input| | | | | | output | ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ | | port | |Decompressor| |Forwarder| FE | | | +---------+ +------------+ +---------+ #1 | | +-----------------------------------------------------+ V | +-----------------------<-----------------------------+ | | +----------------------------------------+ V | +------------+ +----------+ | | input | | | | output | +->--+->|Header |-->| Egress |---------+--> | |Compressor | | port | FE | | +------------+ +----------+ #2 | +----------------------------------------+ Another graph may have FE1: --input--> Ingressport --> IPV4 forwarder --backplane--> FE2:egress port --out--> And therefore totaly missing out the Header compression/decompression blocks in the graph. In such a case the L3 lookup is done in the ingress on FE1 and the nexhop is on the egress on FE2s some port. This is assuming the FEs are capable of this. > > - i should say formally describe their parametrization - > > using the LFB "language" as defined by the model; if you can > > do that then the protocol can configure them. Does that make sense? > > Something more: > > a) I hope this whole thing is end-to-end (!), no? Well, the scope is NE-level. I am not sure what you mean by end-2-end? > b) S. 4.7.2 is the base for defining complex packet header masks that > enable conditional processing? The inputs and outputs are needed for describing graphs. i.e they are logical more than for packet processing. The packet processing is done within the blocks. When you define your LFB you define the inputs using various criteria as mentioned in the draft. > c) how fast would this be? Are we talking core network routers here? > Or is it planned for access network' bitrate magnitude? I mean if usually > processing Options takes packets out of the fast path, what would be the > penalty in terms of delay,e.g., for a FE? (I realise it may be too soon > to make a statement on this, but maybe you already have some results?? > Hope these questions are not 'uncomfortable' :) > Every vendor building a distributed box has something like Forces thats proprietary. This effort is to standardize such approaches. As far as speed is concerned, I dont suspect this will be any different than something Juniper or CISCO or nortel etc does thats proprietary. The goal is to be able to process as fast as possible - its part of the requirements. If you see anything working against that goal, let us know. So in other words, forces should be usable at both core and access devices. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue May 3 11:26:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00214 for ; Tue, 3 May 2005 11:26:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSzVu-00047O-8Z for forces-archive@IETF.ORG; Tue, 03 May 2005 11:40:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010318FB@cherry.ease.lsoft.com>; Tue, 3 May 2005 11:26:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69129236 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 11:26:20 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 194.173.20.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 3 May 2005 04:08:28 -0400 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 0c50_73b087fe_bbb4_11d9_942a_003048253456; Tue, 03 May 2005 11:19:29 +0200 (CEST) Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005050310080203-27973 ; Tue, 3 May 2005 10:08:02 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de; Tue, 3 May 2005 10:09:11 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on scope Thread-Index: AcVPJNXk6Ync3wGXQu2A6VrGYjbixAADDAPg Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B97308@lan-ex-01.panasonic.de> Date: Tue, 3 May 2005 10:07:26 +0200 Reply-To: Jose Rey Sender: Forwarding and Control Element Separation From: Jose Rey Subject: Re: Question on scope Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Hi Jamal,=20 >=20 > Joes, >=20 > On Mon, 2005-02-05 at 16:07 +0200, Jose Rey wrote: >=20 > > Thanks for you answers. Actually Joel answered. I paste=20 > the offline traffic below. > >=20 > > Summarising the thread below, it seems that you target at=20 > making the=20 > > task of policy-routing much easier and as far as possible=20 > automated (challenging!). >=20 > It depends on what you mean by policy routing. If it is what=20 > Jpel describes in his email as "arranging the LFB instance=20 > graph and classifier tables" then yes. If by routing you mean=20 > L3, then thats a small subset of the larger picture. > Forces also is constrained within the scope of an NE.=20 As I understand, basically you got a 'processing graph' which eventually = (after applying the 'logic') gives you a 'processing path' and then you = need the L3 route anyway, no? =20 I guess that for the "LFB arrangement" you don't use L3 routing but you = do for the inter-NE connections. >=20 > > This controlled entities (FEs) would include things as=20 > interesting as=20 > > transcoders, packet droppers and so on, thus not limited=20 > to L4 functionality. >=20 > Indeed.=20 > Essentially, intelligence on the CE decides what LFB building=20 > blocks to use and then instantiates them interconnected via a graph. > The graph edges may be constrained by the limits of what the=20 > LFB block can connect to (as discovered during capability=20 > exchange). So if the blocks constitute of L2 processing, G711=20 > RTP vocoding, IPSEC etc, shouldnt matter. What matters is you=20 > can formally describe these blocks > - i should say formally describe their parametrization -=20 > using the LFB "language" as defined by the model; if you can=20 > do that then the protocol can configure them. Does that make sense? Something more: a) I hope this whole thing is end-to-end (!), no?=20 b) S. 4.7.2 is the base for defining complex packet header masks that = enable conditional processing? c) how fast would this be? Are we talking core network routers here? Or = is it planned for access network' bitrate magnitude? I mean if usually = processing Options takes packets out of the fast path, what would be the = penalty in terms of delay,e.g., for a FE? (I realise it may be too soon = to make a statement on this, but maybe you already have some results?? = Hope these questions are not 'uncomfortable' :) Cheers, Jos=E9 >=20 > cheers, > jamal >=20 >=20 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 13:59:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07949 for ; Wed, 4 May 2005 13:59:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTONS-0006hY-PB for forces-archive@IETF.ORG; Wed, 04 May 2005 14:13:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01033924@cherry.ease.lsoft.com>; Wed, 4 May 2005 13:58:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69291660 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 13:58:58 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 13:58:58 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10212332 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 04 May 2005 13:58:21 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050504135729.02ef6d40@localhost> Date: Wed, 4 May 2005 13:58:18 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f I sent the message below to the list more than a month ago. There are a series of specific questions that I would really like feedback on. Yours, Joel -------------------------------------------------------- As suggested on the list before the meeting, and discussed at the meeting, I think it may make sense to provide explicit mechanisms in the model and protocol for referencing the properties of any element of any LFB. The basic approach would be to include in the core library a data definition for the scalar for access (none, read-only, write-only, and read-write is what I would start with.) Then, we would define a structure to be returned for a properties reference to any element in the model. A property reference would be indicated by setting a bit in the path flags that reference the element. At the moment, I can see two structure definitions. One for most elements which only contains the access permissions, and one for arrays which contains other array properties. I have included the XML declarations for all of this at the end of this message. There are a number of open questions: 1) What should we use for the properties of a structure? We could just return the permissions, which would relate to the structure as a whole. We could try to return a complex structure with the permissions for the struct and the permissions for every element within the structure. I am inclined to keep this simple, but the result is that if one needs the element properties one has to GET a number of pieces of information. 2) What should we use for the properties of an LFB? (This would be reference by a path with the properties flag set and 0 identifiers in the path ids.) Should it reference just the LFB? Should it try to return the properties for every top level element in the LFB? 3) What about Aliases? All the other properties are read only. It is very tempting to put the Alias target information into the alias properties structure (much as the array information is in the array properties structure.) The one aspect that gives me pause in doing that is that we would have to allow SET operations against Alias properties to make this work. Is that a good idea? 4) As a minor aspect, if we have nested path-data TLVs how should the property flag be set and interpreted? My inclination is to say that the flag only applies to paths which do not have nested path-data. For completeness, the XML: elementAccessScalar scalar of access permission values uchar no-access no access is permitted read-only read access is permitted write-only write access is permitted read-write read and write access is permitted BasicElementProperties the structure for most element properties 1 access-permissions what access is permitted to the referenced element elementAccessScalar ArrayElementProperties the additional properties for an array element BasicElementProperties 2 first-used-index index of the first used array element uint32 3 first-unused-index index of the first available array element uint32 4 last-used-index index of the last used array element uint32 5 used-entry-count number of entries used in the array element uint32 Yours, Joel M. Halpern PS: I have moved derived-from and element-ID to nested elements instead of attributes because that seems the most consistent with the advice I could get from the application folks. I still should talk to Scott Hollenbeck to really understand this. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 18:04:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16281 for ; Wed, 4 May 2005 18:04:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSD5-0001XQ-F5 for forces-archive@IETF.ORG; Wed, 04 May 2005 18:19:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.01033D33@cherry.ease.lsoft.com>; Wed, 4 May 2005 18:04:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69313034 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 18:04:33 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 18:04:08 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050415044217:39781 ; Wed, 4 May 2005 15:04:42 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2005 03:04:42 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2005 03:04:44 PM, Serialize complete at 05/04/2005 03:04:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115244245.7906.95.camel@localhost.localdomain> Date: Wed, 4 May 2005 18:04:05 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050504135729.02ef6d40@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hi Joel, On Wed, 2005-04-05 at 13:58 -0400, Joel M. Halpern wrote: > I sent the message below to the list more than a month ago. > There are a series of specific questions that I would really like feedback on. Apologies, I meant to respond (after reading it of course ;->). Comments below: > -------------------------------------------------------- > > As suggested on the list before the meeting, and discussed at the meeting, > I think it may make sense to provide explicit mechanisms in the model and > protocol for referencing the properties of any element of any LFB. > > The basic approach would be to include in the core library a data > definition for the scalar for access (none, read-only, write-only, and > read-write is what I would start with.) > Then, we would define a structure to be returned for a properties reference > to any element in the model. A property reference would be indicated by > setting a bit in the path flags that reference the element. > Sounds sensible. > At the moment, I can see two structure definitions. One for most elements > which only contains the access permissions, and one for arrays which > contains other array properties. I have included the XML declarations for > all of this at the end of this message. > Access controls for elements and the array properties are the only associated metadata i can think of at the moment; it doesnt seem that you object to any other properties being added in the future, right? > There are a number of open questions: > > 1) What should we use for the properties of a structure? We could just > return the permissions, which would relate to the structure as a whole. We > could try to return a complex structure with the permissions for the struct > and the permissions for every element within the structure. I am inclined > to keep this simple, but the result is that if one needs the element > properties one has to GET a number of pieces of information. > The more fine grained the better, but its a lot of detail. I think that hierachies (example a struct X access control vs a X.element1 access control with the former defining the default for the struct and the later overriding the default. Too complex) > 2) What should we use for the properties of an LFB? (This would be > reference by a path with the properties flag set and 0 identifiers in the > path ids.) Should it reference just the LFB? Should it try to return the > properties for every top level element in the LFB? > So example properties of an LFB would be its ID, where its derived from etc? It sounds to me like what you describe is sufficient for the path at least. I think anything under LFBClassDefs is target-able via a path - so is it would be simpler to access those properties just by pointing at them appropriately, no? > 3) What about Aliases? All the other properties are read only. It is very > tempting to put the Alias target information into the alias properties > structure (much as the array information is in the array properties > structure.) The one aspect that gives me pause in doing that is that we > would have to allow SET operations against Alias properties to make this > work. Is that a good idea? > Shouldnt all properties be SETable anyways? In otherwise, shouldnt i (CE) be able to change an attribute from read-only to read-write at runtime? It depends on the attribute of course - some dont make sense to do so. > 4) As a minor aspect, if we have nested path-data TLVs how should the > property flag be set and interpreted? My inclination is to say that the > flag only applies to paths which do not have nested path-data. > Why this restriction? I would think that if i can formulate a GET to some target with the properties bit set, theres a clear meaning as to what i am trying to GET, no? > > > BasicElementProperties > the structure for most element properties > > > 1 Did you just go back to the old format of defining IDs? Otherwise, the xml looks clear enough to me. > Yours, > Joel M. Halpern > > PS: I have moved derived-from and element-ID to nested elements instead of > attributes because that seems the most consistent with the advice I could > get from the application folks. I still should talk to Scott Hollenbeck to > really understand this. Duh, ok - this answers my question then. Are you going to change the general grammar to match this? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 20:03:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28452 for ; Wed, 4 May 2005 20:03:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTU3s-0006Qi-K8 for forces-archive@IETF.ORG; Wed, 04 May 2005 20:17:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.01033F99@cherry.ease.lsoft.com>; Wed, 4 May 2005 20:03:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69321381 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 20:03:07 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 20:02:15 -0400 Received: from [68.80.129.152] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10216030 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 04 May 2005 20:02:02 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050504200032.02d6c120@localhost> Date: Wed, 4 May 2005 20:02:02 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element IDs (and derived-from) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115244245.7906.95.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I did not edit the message to reflect what I learned since about attributes and elements. I have been going back and forth on what things should be attributes, and what should be nested elements. If I have understood the XML experts properly, the best answer is that IDs should be attributes, but "derived-from" should be an element. Thanks for looking at all of this. Joel At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: >Did you just go back to the old format of defining IDs? > > >Otherwise, the xml looks clear enough to me. > > > Yours, > > Joel M. Halpern > > > > PS: I have moved derived-from and element-ID to nested elements instead of > > attributes because that seems the most consistent with the advice I could > > get from the application folks. I still should talk to Scott > Hollenbeck to > > really understand this. > >Duh, ok - this answers my question then. Are you going to change the >general grammar to match this? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 20:03:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28516 for ; Wed, 4 May 2005 20:03:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTU4L-0006RL-Rh for forces-archive@IETF.ORG; Wed, 04 May 2005 20:18:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.01033F9B@cherry.ease.lsoft.com>; Wed, 4 May 2005 20:03:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69321504 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 20:03:40 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 20:03:35 -0400 Received: from [68.80.129.152] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10216121 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 04 May 2005 20:03:33 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050504200213.02d6c3b0@localhost> Date: Wed, 4 May 2005 20:03:33 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115244245.7906.95.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I had assumed that if an FE said that an element was read-only, that was because the FE was not prepared to let the CE write to that element. If the FE is prepared to let the CE write the element, then it would be read-write. So I could not come up with a case where the CE would write the properties, except for the alias situation. Thanks, Joel At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > 3) What about Aliases? All the other properties are read only. It is > very > > tempting to put the Alias target information into the alias properties > > structure (much as the array information is in the array properties > > structure.) The one aspect that gives me pause in doing that is that we > > would have to allow SET operations against Alias properties to make this > > work. Is that a good idea? > > > >Shouldnt all properties be SETable anyways? In otherwise, shouldnt i >(CE) be able to change an attribute from read-only to read-write at >runtime? It depends on the attribute of course - some dont make sense to >do so. From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 20:11:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29291 for ; Wed, 4 May 2005 20:11:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTUBy-0006n7-7s for forces-archive@IETF.ORG; Wed, 04 May 2005 20:26:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01033E9E@cherry.ease.lsoft.com>; Wed, 4 May 2005 20:11:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69322737 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 20:11:25 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 20:11:25 -0400 Received: from [68.80.129.152] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10216150 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 04 May 2005 20:11:22 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050504200611.02d6c640@localhost> Date: Wed, 4 May 2005 20:11:22 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115244245.7906.95.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Let me be more explicit about the case I thought was confusing: Path-Data: Flag(a) = properties, path = 1.2 nested-path-data-1 Flag(b) = 0, path = 3 nested-path-data-2 Flag(c) =properties, path=4 (nested-path-1 and nested-path-2 are both nested in the main path-data, and are siblings to each other.) Clearly, something about 1.2.3 and 1.2.4 is to be returned. If we ignore flag a, then we return the data from 1.2.3, and the properties about 1.2.4. If flag-a matters, then the only conclusion I can reach is that we are to return the properties information about 1.2.3 and 1.2.4, and the flags b and c don't matter. My suggestion is that flag-a should be ignored. Yours, Joel At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > property flag be set and interpreted? My inclination is to say that the > > flag only applies to paths which do not have nested path-data. > > > >Why this restriction? I would think that if i can formulate a GET to >some target with the properties bit set, theres a clear meaning as to >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Wed May 4 20:12:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29356 for ; Wed, 4 May 2005 20:12:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTUCs-0006o3-Qx for forces-archive@IETF.ORG; Wed, 04 May 2005 20:27:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01034090@cherry.ease.lsoft.com>; Wed, 4 May 2005 20:12:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69322817 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 20:12:29 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 20:12:29 -0400 Received: from [68.80.129.152] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10216161 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 04 May 2005 20:12:23 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050504201139.02d6c8d0@localhost> Date: Wed, 4 May 2005 20:12:24 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115244245.7906.95.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 That's what I thought too. If we come up with more, we add it (this rev or a future rev). Joel At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > At the moment, I can see two structure definitions. One for most elements > > which only contains the access permissions, and one for arrays which > > contains other array properties. I have included the XML declarations for > > all of this at the end of this message. > > > >Access controls for elements and the array properties are the only >associated metadata i can think of at the moment; it doesnt seem that >you object to any other properties being added in the future, right? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 13:44:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23106 for ; Thu, 5 May 2005 13:43:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTkcc-0006WE-7L for forces-archive@IETF.ORG; Thu, 05 May 2005 13:58:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.01035CAA@cherry.ease.lsoft.com>; Thu, 5 May 2005 13:43:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69442174 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 13:43:58 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 13:43:58 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45HhvCa028690; Thu, 5 May 2005 17:43:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45HhGdQ006975; Thu, 5 May 2005 17:43:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050510435729600 ; Thu, 05 May 2005 10:43:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 10:43:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Element Properties Thread-Index: AcVQ9VGmzW0xfT4hQVGRnWhSSv2wqgApE1Eg X-OriginalArrivalTime: 05 May 2005 17:43:57.0410 (UTC) FILETIME=[036B3C20:01C5519A] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E052C29DF@orsmsx408> Date: Thu, 5 May 2005 10:44:17 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Element Properties Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable I have a few comments below: Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, May 04, 2005 3:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Element Properties Hi Joel, On Wed, 2005-04-05 at 13:58 -0400, Joel M. Halpern wrote: > I sent the message below to the list more than a month ago. > There are a series of specific questions that I would really like feedback on. Apologies, I meant to respond (after reading it of course ;->). Comments below: > -------------------------------------------------------- >=20 > As suggested on the list before the meeting, and discussed at the meeting,=20 > I think it may make sense to provide explicit mechanisms in the model and=20 > protocol for referencing the properties of any element of any LFB. >=20 > The basic approach would be to include in the core library a data=20 > definition for the scalar for access (none, read-only, write-only, and > read-write is what I would start with.) > Then, we would define a structure to be returned for a properties reference=20 > to any element in the model. A property reference would be indicated by=20 > setting a bit in the path flags that reference the element. >=20 Sounds sensible. > At the moment, I can see two structure definitions. One for most elements=20 > which only contains the access permissions, and one for arrays which=20 > contains other array properties. I have included the XML declarations for=20 > all of this at the end of this message. >=20 Access controls for elements and the array properties are the only associated metadata i can think of at the moment; it doesnt seem that you object to any other properties being added in the future, right? > There are a number of open questions: >=20 > 1) What should we use for the properties of a structure? We could just=20 > return the permissions, which would relate to the structure as a whole. We=20 > could try to return a complex structure with the permissions for the struct=20 > and the permissions for every element within the structure. I am inclined=20 > to keep this simple, but the result is that if one needs the element=20 > properties one has to GET a number of pieces of information. >=20 The more fine grained the better, but its a lot of detail.=20 I think that hierachies (example a struct X access control vs a X.element1 access control with the former defining the default for the struct and the later overriding the default. Too complex) <> > 2) What should we use for the properties of an LFB? (This would be=20 > reference by a path with the properties flag set and 0 identifiers in the=20 > path ids.) Should it reference just the LFB? Should it try to return the=20 > properties for every top level element in the LFB? >=20 So example properties of an LFB would be its ID, where its derived from etc?=20 It sounds to me like what you describe is sufficient for the path at least. I think anything under LFBClassDefs is target-able via a path - so is it would be simpler to access those properties just by pointing at them appropriately, no? > 3) What about Aliases? All the other properties are read only. It is very=20 > tempting to put the Alias target information into the alias properties > structure (much as the array information is in the array properties=20 > structure.) The one aspect that gives me pause in doing that is that we=20 > would have to allow SET operations against Alias properties to make this=20 > work. Is that a good idea? >=20 Shouldnt all properties be SETable anyways? In otherwise, shouldnt i (CE) be able to change an attribute from read-only to read-write at runtime? It depends on the attribute of course - some dont make sense to do so.=20 <> > 4) As a minor aspect, if we have nested path-data TLVs how should the=20 > property flag be set and interpreted? My inclination is to say that the=20 > flag only applies to paths which do not have nested path-data. >=20 Why this restriction? I would think that if i can formulate a GET to some target with the properties bit set, theres a clear meaning as to what i am trying to GET, no? >=20 > > BasicElementProperties > the structure for most element properties > > > 1 Did you just go back to the old format of defining IDs? Otherwise, the xml looks clear enough to me. > Yours, > Joel M. Halpern >=20 > PS: I have moved derived-from and element-ID to nested elements instead of=20 > attributes because that seems the most consistent with the advice I could=20 > get from the application folks. I still should talk to Scott Hollenbeck to=20 > really understand this. Duh, ok - this answers my question then. Are you going to change the general grammar to match this? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:43:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23035 for ; Thu, 5 May 2005 17:43:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToMZ-0003Hi-Kt for forces-archive@IETF.ORG; Thu, 05 May 2005 17:58:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010363D6@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:43:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69464833 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:43:34 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:43:33 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050514440698:41074 ; Thu, 5 May 2005 14:44:06 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200213.02d6c3b0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:44:07 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:44:09 PM, Serialize complete at 05/05/2005 02:44:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115329410.8006.83.camel@localhost.localdomain> Date: Thu, 5 May 2005 17:43:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050504200213.02d6c3b0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Wed, 2005-04-05 at 20:03 -0400, Joel M. Halpern wrote: > I had assumed that if an FE said that an element was read-only, that was > because the FE was not prepared to let the CE write to that element. If > the FE is prepared to let the CE write the element, then it would be > read-write. > So I could not come up with a case where the CE would write the properties, > except for the alias situation. Hopefully this will address Ellen's comment as well and lets pick access control as an example. Who is it that decides that an elememt is read-only? 1) Clearly one scheme is to make that call at LFB definition time. And everybody knows. 2) The FE makes that call. It does make sense; there are cases where somethings (as an example something residing in ROM such as a serial number) are read only. However if we know #1, #2 is a noop. 3) The CE makes the call. This is the scenario i was referring to. Ok, granted it doesnt make sense for the CE to overwrite something that is truly read-only at the FE, but assume the CE is smart enough to know the difference. Actually let me backtrack a little .. the model i had in mind for access control was to infact to allow for for true ACLs and different entities to access an FE's LFB. Some of them may have read-only permission while some may have read-write ability. This will fall under #3 where the CE sets these permissions - I realize i am pushing the envelope a little here but do we wanna disallow that? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:46:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23331 for ; Thu, 5 May 2005 17:46:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToPY-0003Qw-OC for forces-archive@IETF.ORG; Thu, 05 May 2005 18:01:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010363DF@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:46:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69465010 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:46:43 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:46:42 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050514471522:41079 ; Thu, 5 May 2005 14:47:15 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200611.02d6c640@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:47:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:47:17 PM, Serialize complete at 05/05/2005 02:47:17 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115329598.8006.86.camel@localhost.localdomain> Date: Thu, 5 May 2005 17:46:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050504200611.02d6c640@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Joel, Yes, I can see the ambiguity in this case. Can you please capture the text in your description in the draft as well (maybe some appendix section)?. I am leaving the thread in its entirety below so people understand whats being said. cheers, jamal On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > Let me be more explicit about the case I thought was confusing: > > Path-Data: > Flag(a) = properties, path = 1.2 > nested-path-data-1 > Flag(b) = 0, path = 3 > nested-path-data-2 > Flag(c) =properties, path=4 > > (nested-path-1 and nested-path-2 are both nested in the main path-data, and > are siblings to each other.) > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > If we ignore flag a, then we return the data from 1.2.3, and the properties > about 1.2.4. > If flag-a matters, then the only conclusion I can reach is that we are to > return the properties information about 1.2.3 and 1.2.4, and the flags b > and c don't matter. > > My suggestion is that flag-a should be ignored. > > Yours, > Joel > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > property flag be set and interpreted? My inclination is to say that the > > > flag only applies to paths which do not have nested path-data. > > > > > > >Why this restriction? I would think that if i can formulate a GET to > >some target with the properties bit set, theres a clear meaning as to > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:50:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23653 for ; Thu, 5 May 2005 17:50:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToTJ-0003aS-MU for forces-archive@IETF.ORG; Thu, 05 May 2005 18:05:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.01036370@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:50:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69465633 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:50:29 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:50:28 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050514510175:41083 ; Thu, 5 May 2005 14:51:01 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200611.02d6c640@localhost> <1115329598.8006.86.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:51:02 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 02:51:03 PM, Serialize complete at 05/05/2005 02:51:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115329825.8006.88.camel@localhost.localdomain> Date: Thu, 5 May 2005 17:50:25 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115329598.8006.86.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Actualluy one way to resolve this ambiguity is not to use flags but rather a new command like GET-PROPERTIES cheers, jamal On Thu, 2005-05-05 at 17:46 -0400, Jamal Hadi Salim wrote: > Joel, > > Yes, I can see the ambiguity in this case. > Can you please capture the text in your description in the draft as well > (maybe some appendix section)?. I am leaving the thread in its entirety > below so people understand whats being said. > > > cheers, > jamal > > On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > > Let me be more explicit about the case I thought was confusing: > > > > Path-Data: > > Flag(a) = properties, path = 1.2 > > nested-path-data-1 > > Flag(b) = 0, path = 3 > > nested-path-data-2 > > Flag(c) =properties, path=4 > > > > (nested-path-1 and nested-path-2 are both nested in the main path-data, and > > are siblings to each other.) > > > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > > If we ignore flag a, then we return the data from 1.2.3, and the properties > > about 1.2.4. > > If flag-a matters, then the only conclusion I can reach is that we are to > > return the properties information about 1.2.3 and 1.2.4, and the flags b > > and c don't matter. > > > > My suggestion is that flag-a should be ignored. > > > > Yours, > > Joel > > > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > > property flag be set and interpreted? My inclination is to say that the > > > > flag only applies to paths which do not have nested path-data. > > > > > > > > > >Why this restriction? I would think that if i can formulate a GET to > > >some target with the properties bit set, theres a clear meaning as to > > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:54:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23812 for ; Thu, 5 May 2005 17:54:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToWo-0003iQ-9u for forces-archive@IETF.ORG; Thu, 05 May 2005 18:09:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01036353@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:54:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69465735 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:54:13 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:54:13 -0400 Received: from [141.158.22.195] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10232325 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 05 May 2005 17:53:54 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200213.02d6c3b0@localhost> <1115329410.8006.83.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050505175107.02d5c030@localhost> Date: Thu, 5 May 2005 17:53:55 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115329410.8006.83.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 This seems to be about multiple entities having access to some FE attribute: Clearly, the CE can not tell the FE not to write something it needs to write. The access permissions information is about CE access. SO, we must be talking about multiple CE. 1) That is something way out of scope, with lots of complications. 2) Having one CE say "no CE may write this" seems odd, since equivalently, some other CE can say "This is writeable", so I can not see why having a CE change the permissions, if it were possible, would be helpful. It seems like life is much simpler if the permissions are about what the FE will permit the CE to do. If we want later to enhance the properties structure with some other information for interlock control or something, that would come later. I would hate to mask the basic "this is what the FE will permit the CE to do" property. Yours, Joel At 05:43 PM 5/5/2005, Jamal Hadi Salim wrote: >3) The CE makes the call. This is the scenario i was referring to. >Ok, granted it doesnt make sense for the CE to overwrite something >that is truly read-only at the FE, but assume the CE is smart enough to >know the difference. > >Actually let me backtrack a little .. the model i had in mind for access >control was to infact to allow for for true ACLs and >different entities to access an FE's LFB. Some of them may have >read-only permission while some may have read-write ability. This will >fall under #3 where the CE sets these permissions - I realize i am >pushing the envelope a little here but do we wanna disallow that? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:55:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23917 for ; Thu, 5 May 2005 17:55:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToXi-0003jm-6j for forces-archive@IETF.ORG; Thu, 05 May 2005 18:10:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01036354@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:55:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69465783 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:55:09 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:55:05 -0400 Received: from [141.158.22.195] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10232357; Thu, 05 May 2005 17:54:58 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200611.02d6c640@localhost> <1115329598.8006.86.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050505175409.02d5c2c0@localhost> Date: Thu, 5 May 2005 17:54:58 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115329598.8006.86.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 I will be happy to capture the ambiguity in the text. But we need to pick the behavior. Is ignoring the outer flags acceptable? Does anyone other than Jamal and me understand this? Thanks, Joel At 05:46 PM 5/5/2005, Jamal Hadi Salim wrote: >Joel, > >Yes, I can see the ambiguity in this case. >Can you please capture the text in your description in the draft as well >(maybe some appendix section)?. I am leaving the thread in its entirety >below so people understand whats being said. > > >cheers, >jamal > >On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > > Let me be more explicit about the case I thought was confusing: > > > > Path-Data: > > Flag(a) = properties, path = 1.2 > > nested-path-data-1 > > Flag(b) = 0, path = 3 > > nested-path-data-2 > > Flag(c) =properties, path=4 > > > > (nested-path-1 and nested-path-2 are both nested in the main path-data, > and > > are siblings to each other.) > > > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > > If we ignore flag a, then we return the data from 1.2.3, and the > properties > > about 1.2.4. > > If flag-a matters, then the only conclusion I can reach is that we are to > > return the properties information about 1.2.3 and 1.2.4, and the flags b > > and c don't matter. > > > > My suggestion is that flag-a should be ignored. > > > > Yours, > > Joel > > > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > > property flag be set and interpreted? My inclination is to say > that the > > > > flag only applies to paths which do not have nested path-data. > > > > > > > > > >Why this restriction? I would think that if i can formulate a GET to > > >some target with the properties bit set, theres a clear meaning as to > > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 17:56:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24008 for ; Thu, 5 May 2005 17:56:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToYo-0003pr-Pr for forces-archive@IETF.ORG; Thu, 05 May 2005 18:11:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01036360@cherry.ease.lsoft.com>; Thu, 5 May 2005 17:56:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69465823 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 17:56:15 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 17:56:15 -0400 Received: from [141.158.22.195] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10232368; Thu, 05 May 2005 17:56:11 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200611.02d6c640@localhost> <1115329598.8006.86.camel@localhost.localdomain> <1115329825.8006.88.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050505175546.02d5c7e0@localhost> Date: Thu, 5 May 2005 17:56:12 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Element Properties Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1115329825.8006.88.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 That is particularly attractive if we do not want writeable properties. Yours, Joel At 05:50 PM 5/5/2005, Jamal Hadi Salim wrote: >Actualluy one way to resolve this ambiguity is not to use flags but >rather a new command like GET-PROPERTIES > >cheers, >jamal > >On Thu, 2005-05-05 at 17:46 -0400, Jamal Hadi Salim wrote: > > Joel, > > > > Yes, I can see the ambiguity in this case. > > Can you please capture the text in your description in the draft as well > > (maybe some appendix section)?. I am leaving the thread in its entirety > > below so people understand whats being said. > > > > > > cheers, > > jamal > > > > On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > > > Let me be more explicit about the case I thought was confusing: > > > > > > Path-Data: > > > Flag(a) = properties, path = 1.2 > > > nested-path-data-1 > > > Flag(b) = 0, path = 3 > > > nested-path-data-2 > > > Flag(c) =properties, path=4 > > > > > > (nested-path-1 and nested-path-2 are both nested in the main > path-data, and > > > are siblings to each other.) > > > > > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > > > If we ignore flag a, then we return the data from 1.2.3, and the > properties > > > about 1.2.4. > > > If flag-a matters, then the only conclusion I can reach is that we > are to > > > return the properties information about 1.2.3 and 1.2.4, and the flags b > > > and c don't matter. > > > > > > My suggestion is that flag-a should be ignored. > > > > > > Yours, > > > Joel > > > > > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > > > property flag be set and interpreted? My inclination is to say > that the > > > > > flag only applies to paths which do not have nested path-data. > > > > > > > > > > > > >Why this restriction? I would think that if i can formulate a GET to > > > >some target with the properties bit set, theres a clear meaning as to > > > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 18:12:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25755 for ; Thu, 5 May 2005 18:12:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTooB-0004U3-6K for forces-archive@IETF.ORG; Thu, 05 May 2005 18:27:03 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01036378@cherry.ease.lsoft.com>; Thu, 5 May 2005 18:12:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69467385 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 18:12:09 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 18:12:09 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050515124284:41110 ; Thu, 5 May 2005 15:12:42 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200213.02d6c3b0@localhost> <1115329410.8006.83.camel@localhost.localdomain> <6.2.1.2.0.20050505175107.02d5c030@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 03:12:43 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 03:12:44 PM, Serialize complete at 05/05/2005 03:12:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115331126.8006.107.camel@localhost.localdomain> Date: Thu, 5 May 2005 18:12:06 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050505175107.02d5c030@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Thu, 2005-05-05 at 17:53 -0400, Joel M. Halpern wrote: > This seems to be about multiple entities having access to some FE attribute: > > Clearly, the CE can not tell the FE not to write something it needs to write. > The access permissions information is about CE access. > SO, we must be talking about multiple CE. I am not sure whether i would go as far as calling them "CEs" but they are say processes in the CE. A process may "own" one LFB (qoS) while another may " own" configuration of another(forwarding). We seem to have allowed a description of this in some of the earlier drafts. > > 1) That is something way out of scope, with lots of complications. I wouldnt disagree. > 2) Having one CE say "no CE may write this" seems odd, since equivalently, > some other CE can say "This is writeable", so I can not see why having a CE > change the permissions, if it were possible, would be helpful. > Not if you think of them as processes in the CE. We did allow such descriptions (cant remember what draft) - and this has already caused questions in regards to the xID a while back from people like Robert. > It seems like life is much simpler if the permissions are about what the FE > will permit the CE to do. Agree. > If we want later to enhance the properties structure with some other > information for interlock control or something, that would come later. I > would hate to mask the basic "this is what the FE will permit the CE to do" > property. > Well as in any ACL you will maintain some list of possible entities and their permissions. Note, I am not disagreeing on the complexity of this and i am not sure i want it even ;-> I just brought AC as a way to show a different perspective. My intent was to show that element properties other than aliases may need to be writeable - maybe not the ones we have identified right now. I dont want to be totaly future-proof but if the cost of adding it is low today, i would have no issues. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 18:25:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27210 for ; Thu, 5 May 2005 18:25:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTp0e-000501-0f for forces-archive@IETF.ORG; Thu, 05 May 2005 18:39:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.01036268@cherry.ease.lsoft.com>; Thu, 5 May 2005 18:25:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69468173 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 18:25:01 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 18:25:01 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005050515253475:41128 ; Thu, 5 May 2005 15:25:34 -0700 References: <6.2.1.2.0.20050504135729.02ef6d40@localhost> <1115244245.7906.95.camel@localhost.localdomain> <6.2.1.2.0.20050504200611.02d6c640@localhost> <1115329598.8006.86.camel@localhost.localdomain> <1115329825.8006.88.camel@localhost.localdomain> <6.2.1.2.0.20050505175546.02d5c7e0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 03:25:35 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2005 03:25:36 PM, Serialize complete at 05/05/2005 03:25:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1115331898.8006.115.camel@localhost.localdomain> Date: Thu, 5 May 2005 18:24:58 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050505175546.02d5c7e0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Thu, 2005-05-05 at 17:56 -0400, Joel M. Halpern wrote: > That is particularly attractive if we do not want writeable properties. > > At 05:50 PM 5/5/2005, Jamal Hadi Salim wrote: > >Actualluy one way to resolve this ambiguity is not to use flags but > >rather a new command like GET-PROPERTIES > > Or you could have a SET-PROPERTIES in addition if writable proved useful. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 18:26:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27392 for ; Thu, 5 May 2005 18:26:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTp2W-00056R-0v for forces-archive@IETF.ORG; Thu, 05 May 2005 18:41:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010364A1@cherry.ease.lsoft.com>; Thu, 5 May 2005 18:26:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69468227 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 18:26:53 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 18:26:53 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j45MQqiQ004537; Thu, 5 May 2005 22:26:52 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j45MQNCn009366; Thu, 5 May 2005 22:26:52 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050515265226810 ; Thu, 05 May 2005 15:26:52 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 15:26:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Element Properties Thread-Index: AcVRu3/UTYJl4ncPQ/K9BMMG8FiCBgABKqjQ X-OriginalArrivalTime: 05 May 2005 22:26:52.0577 (UTC) FILETIME=[89682910:01C551C1] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E052C31A5@orsmsx408> Date: Thu, 5 May 2005 15:27:11 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Element Properties Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable I would prefer to only have to deal with cases #1 and #2. (I also think these are different). Since FEs can have different capabilities, case #1 may be too limiting. For one FE, an attribute may only be readable, where in another FE, the CE may be able to write the attribute. I think the third case where the CE can decide to change the permissions seems complicated. I assume that if within the CE, some processes have limited permissions, the CE could manage this without requiring support from the model. By the same token in the case where you have multiple CEs controlling a single FE, they would need to coordinate and this too would be outside of the model. I guess I don't see the value and it would at least require some extra error notification in case the CE tries to change a permission that is not allowed on the FE. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Thursday, May 05, 2005 2:43 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Element Properties On Wed, 2005-04-05 at 20:03 -0400, Joel M. Halpern wrote: > I had assumed that if an FE said that an element was read-only, that was=20 > because the FE was not prepared to let the CE write to that element. If=20 > the FE is prepared to let the CE write the element, then it would be=20 > read-write. > So I could not come up with a case where the CE would write the properties,=20 > except for the alias situation. Hopefully this will address Ellen's comment as well and lets pick access control as an example. Who is it that decides that an elememt is read-only? 1) Clearly one scheme is to make that call at LFB definition time. And everybody knows.=20 2) The FE makes that call. It does make sense; there are cases where somethings (as an example something residing in ROM such as a serial number) are read only. However if we know #1, #2 is a noop. 3) The CE makes the call. This is the scenario i was referring to.=20 Ok, granted it doesnt make sense for the CE to overwrite something that is truly read-only at the FE, but assume the CE is smart enough to know the difference. Actually let me backtrack a little .. the model i had in mind for access control was to infact to allow for for true ACLs and different entities to access an FE's LFB. Some of them may have read-only permission while some may have read-write ability. This will fall under #3 where the CE sets these permissions - I realize i am pushing the envelope a little here but do we wanna disallow that? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu May 5 20:28:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11426 for ; Thu, 5 May 2005 20:28:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTqwT-00055q-Pp for forces-archive@IETF.ORG; Thu, 05 May 2005 20:43:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010364C7@cherry.ease.lsoft.com>; Thu, 5 May 2005 20:28:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69477244 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 5 May 2005 20:28:51 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 5 May 2005 20:28:50 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j460Sl8J027472; Fri, 6 May 2005 00:28:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j460SdCh012790; Fri, 6 May 2005 00:28:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005050517284714755 ; Thu, 05 May 2005 17:28:47 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 17:28:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Element Properties Thread-Index: AcVRvSLV33kolpv6TvaiJBhm3bBFqwAE9FJA X-OriginalArrivalTime: 06 May 2005 00:28:47.0232 (UTC) FILETIME=[9147F000:01C551D2] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E052FD805@orsmsx408> Date: Thu, 5 May 2005 17:29:05 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Element Properties Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable It took me awhile, but I think I get what you are trying to say in the example. Since flag "a" specifies a property, but one of the inner flags (flag "b") specifies data, there is an inconsistency. Thus, it is not possible to satisfy the conditions of both flags. (Is this right?) If this is the case, I agree with you that the outer flag should be ignored (flag "a"). It seems to make more sense to report the information as specified in the nested flags. It seems inefficient otherwise. If you don't ignore the outer flag and you really want the information as specified by the inner flags in a structure, you would have to perform multiple individual GETs to get the information you really wanted. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, May 05, 2005 2:55 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Element Properties I will be happy to capture the ambiguity in the text. But we need to pick the behavior. Is ignoring the outer flags acceptable? Does anyone other than Jamal and me understand this? Thanks, Joel At 05:46 PM 5/5/2005, Jamal Hadi Salim wrote: >Joel, > >Yes, I can see the ambiguity in this case. >Can you please capture the text in your description in the draft as well >(maybe some appendix section)?. I am leaving the thread in its entirety >below so people understand whats being said. > > >cheers, >jamal > >On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > > Let me be more explicit about the case I thought was confusing: > > > > Path-Data: > > Flag(a) =3D properties, path =3D 1.2 > > nested-path-data-1 > > Flag(b) =3D 0, path =3D 3 > > nested-path-data-2 > > Flag(c) =3Dproperties, path=3D4 > > > > (nested-path-1 and nested-path-2 are both nested in the main path-data,=20 > and > > are siblings to each other.) > > > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > > If we ignore flag a, then we return the data from 1.2.3, and the=20 > properties > > about 1.2.4. > > If flag-a matters, then the only conclusion I can reach is that we are to > > return the properties information about 1.2.3 and 1.2.4, and the flags b > > and c don't matter. > > > > My suggestion is that flag-a should be ignored. > > > > Yours, > > Joel > > > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > > property flag be set and interpreted? My inclination is to say=20 > that the > > > > flag only applies to paths which do not have nested path-data. > > > > > > > > > >Why this restriction? I would think that if i can formulate a GET to > > >some target with the properties bit set, theres a clear meaning as to > > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Fri May 6 15:16:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26109 for ; Fri, 6 May 2005 15:16:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU8YL-0002ri-A3 for forces-archive@IETF.ORG; Fri, 06 May 2005 15:32:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010381D7@cherry.ease.lsoft.com>; Fri, 6 May 2005 15:16:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69597974 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 6 May 2005 15:16:56 -0400 Received: from 194.173.20.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 6 May 2005 15:16:56 -0400 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 2c8a_fbe992d6_be6c_11d9_8f24_003048253456; Fri, 06 May 2005 22:25:31 +0200 (CEST) Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005050621130116-89180 ; Fri, 6 May 2005 21:13:01 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de; Fri, 6 May 2005 21:14:14 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on scope Thread-Index: AcVP27OXsp9WI9G9TLayoNt+HkGV4wCkjiow Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jose Rey Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B974B2@lan-ex-01.panasonic.de> Date: Fri, 6 May 2005 21:12:23 +0200 Reply-To: Jose Rey Sender: Forwarding and Control Element Separation From: Jose Rey Subject: Re: Question on scope Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Hi, > Joes, > > On Tue, 2005-03-05 at 10:07 +0200, Jose Rey wrote: > > > As I understand, basically you got a 'processing graph' which > > eventually (after applying the 'logic') gives you a > 'processing path' and then you need the L3 route anyway, no=3F > > > > > > I guess that for the "LFB arrangement" you don't use L3 > routing but you do for the > > inter-NE connections. > > Depends if the NE is doing L3. If it is, the rule of thumb > imposed is " > thous shalt not decrement ttl more than once". So a packet > coming in on > a port on FE1 to be L3 forwarded on a port on FE2 shall have its ttl > only decremented once. > As an example of "LFB arrangement", if you take the model > draft example > from figure 10: > > > +-----------------------------------------------------+ > | +---------+ +------------+ +---------+ | > input| | | | | | output | > ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ > | | port | |Decompressor| |Forwarder| FE | | > | +---------+ +------------+ +---------+ #1 | | > +-----------------------------------------------------+ V > | > +-----------------------<-----------------------------+ > | > | +----------------------------------------+ > V | +------------+ +----------+ | > | input | | | | output | > +->--+->|Header |-->| Egress |---------+--> > | |Compressor | | port | FE | > | +------------+ +----------+ #2 | > +----------------------------------------+ > > Another graph may have FE1: --input--> Ingressport --> > IPV4 forwarder --backplane--> FE2:egress port --out--> > > And therefore totaly missing out the Header compression/decompression > blocks in the graph. In such a case the L3 lookup is done in > the ingress > on FE1 and the nexhop is on the egress on FE2s some port. This is > assuming the FEs are capable of this. > OK > > > > > - i should say formally describe their parametrization - > > > using the LFB "language" as defined by the model; if you can > > > do that then the protocol can configure them. Does that > make sense=3F > > > > Something more: > > > > a) I hope this whole thing is end-to-end (!), no=3F > > Well, the scope is NE-level. I am not sure what you mean by end-2-end=3F What I mean is traditional concept of e2e: that the IP header is not modifie= d except for normal router operations (ttl touching and checksum) . (I think your comment below implicitly answers with "yes" to this) > > > b) S. 4.7.2 is the base for defining complex packet header > masks that > > enable conditional processing=3F > > The inputs and outputs are needed for describing graphs. i.e they are > logical more than for packet processing. The packet processing is done > within the blocks. When you define your LFB you define the > inputs using > various criteria as mentioned in the draft. > OK > > c) how fast would this be=3F Are we talking core network > routers here=3F > > Or is it planned for access network' bitrate magnitude=3F I > mean if usually > > processing Options takes packets out of the fast path, what > would be the > > penalty in terms of delay,e.g., for a FE=3F (I realise it may > be too soon > > to make a statement on this, but maybe you already have > some results=3F=3F > > Hope these questions are not 'uncomfortable' :) > > > > > Every vendor building a distributed box has something like Forces > thats proprietary. This effort is to standardize such approaches. > As far as speed is concerned, I dont suspect this will be any > different > than something Juniper or CISCO or nortel etc does thats proprietary. > The goal is to be able to process as fast as possible - its > part of the > requirements. If you see anything working against that goal, let us > know. So in other words, forces should be usable at both core > and access > devices. > Good. Cheers, Jos=E9 ............................................................................= .. Confidentiality Notice The information contained in this Email, and any attachments, is intended fo= r the named recipients only. It may contain confidential and/or legally priv= ileged information. If you are not the intended recipient, you must not copy= , store, distribute or take any action in reliance on it. Any views expresse= d do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the = reply facility in your Email software and then delete it. ............................................................................= . From owner-forces@PEACH.EASE.LSOFT.COM Thu May 12 19:36:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20544 for ; Thu, 12 May 2005 19:36:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWNUC-0001AI-LF for forces-archive@IETF.ORG; Thu, 12 May 2005 19:53:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.01043A8A@cherry.ease.lsoft.com>; Thu, 12 May 2005 19:36:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 70431942 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 12 May 2005 19:36:27 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 12 May 2005 19:36:27 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j4CNaQJf025925 for ; Thu, 12 May 2005 23:36:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j4CNaOIh003270 for ; Thu, 12 May 2005 23:36:26 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005051216362618713 for ; Thu, 12 May 2005 16:36:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 May 2005 16:36:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Element Properties Thread-Index: AcVRvSLV33kolpv6TvaiJBhm3bBFqwAE9FJAAV6bxZA= X-OriginalArrivalTime: 12 May 2005 23:36:26.0069 (UTC) FILETIME=[69E4C050:01C5574B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0545CE86@orsmsx408> Date: Thu, 12 May 2005 16:36:49 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: Element Properties To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Anybody else have an opinion on this topic??? (Is this list still working?) Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M Sent: Thursday, May 05, 2005 5:29 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Element Properties It took me awhile, but I think I get what you are trying to say in the example. Since flag "a" specifies a property, but one of the inner flags (flag "b") specifies data, there is an inconsistency. Thus, it is not possible to satisfy the conditions of both flags. (Is this right?) If this is the case, I agree with you that the outer flag should be ignored (flag "a"). It seems to make more sense to report the information as specified in the nested flags. It seems inefficient otherwise. If you don't ignore the outer flag and you really want the information as specified by the inner flags in a structure, you would have to perform multiple individual GETs to get the information you really wanted. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, May 05, 2005 2:55 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Element Properties I will be happy to capture the ambiguity in the text. But we need to pick the behavior. Is ignoring the outer flags acceptable? Does anyone other than Jamal and me understand this? Thanks, Joel At 05:46 PM 5/5/2005, Jamal Hadi Salim wrote: >Joel, > >Yes, I can see the ambiguity in this case. >Can you please capture the text in your description in the draft as well >(maybe some appendix section)?. I am leaving the thread in its entirety >below so people understand whats being said. > > >cheers, >jamal > >On Wed, 2005-04-05 at 20:11 -0400, Joel M. Halpern wrote: > > Let me be more explicit about the case I thought was confusing: > > > > Path-Data: > > Flag(a) =3D properties, path =3D 1.2 > > nested-path-data-1 > > Flag(b) =3D 0, path =3D 3 > > nested-path-data-2 > > Flag(c) =3Dproperties, path=3D4 > > > > (nested-path-1 and nested-path-2 are both nested in the main path-data,=20 > and > > are siblings to each other.) > > > > Clearly, something about 1.2.3 and 1.2.4 is to be returned. > > If we ignore flag a, then we return the data from 1.2.3, and the=20 > properties > > about 1.2.4. > > If flag-a matters, then the only conclusion I can reach is that we are to > > return the properties information about 1.2.3 and 1.2.4, and the flags b > > and c don't matter. > > > > My suggestion is that flag-a should be ignored. > > > > Yours, > > Joel > > > > At 06:04 PM 5/4/2005, Jamal Hadi Salim wrote: > > > > 4) As a minor aspect, if we have nested path-data TLVs how should the > > > > property flag be set and interpreted? My inclination is to say=20 > that the > > > > flag only applies to paths which do not have nested path-data. > > > > > > > > > >Why this restriction? I would think that if i can formulate a GET to > > >some target with the properties bit set, theres a clear meaning as to > > >what i am trying to GET, no? From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 10:20:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19944 for ; Sun, 22 May 2005 10:20:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZrbD-0001ip-VR for forces-archive@IETF.ORG; Sun, 22 May 2005 10:38:40 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01054C66@cherry.ease.lsoft.com>; 22 May 2005 10:20:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72065047 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 10:20:12 -0400 Received: from 81.228.9.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 10:20:12 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 16892386C1 for ; Sun, 22 May 2005 16:20:13 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZrJL-0006y0-HG for forces@peach.ease.lsoft.com; Sun, 22 May 2005 16:20:12 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116771610.3.0.348509681991.issue21@mip4.org> Date: Sun, 22 May 2005 14:20:10 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue21] TML Timeliness - Obsoleteing messages To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : In Section 4 TML Requirements Timeliness Editorial Note: Does the TML allow for obsoleting msgs? If yes, it needs to define how. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 38 nosy: avri priority: Must fix status: No discussion title: TML Timeliness - Obsoleteing messages ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 10:24:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20241 for ; Sun, 22 May 2005 10:24:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZrf9-0002BC-Ji for forces-archive@IETF.ORG; Sun, 22 May 2005 10:42:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.01054D05@cherry.ease.lsoft.com>; 22 May 2005 10:24:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72065417 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 10:24:17 -0400 Received: from 81.228.8.93 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 10:24:17 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0892D38A71 for ; Sun, 22 May 2005 16:24:17 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZrNI-0006zX-Ro for forces@peach.ease.lsoft.com; Sun, 22 May 2005 16:24:17 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116771856.81.0.164506825537.issue22@mip4.org> Date: Sun, 22 May 2005 14:24:16 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue22] Overview - Response Formatting To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 3=2E3.1.2 Response formating Editorial Note: This is still under discussion and ties into the RESULT TLV discussed in Section 6.1. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 39 nosy: avri priority: Must fix status: No discussion title: Overview - Response Formatting ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 10:28:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20467 for ; Sun, 22 May 2005 10:28:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZrjb-0002jZ-Hp for forces-archive@IETF.ORG; Sun, 22 May 2005 10:47:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01054E4E@cherry.ease.lsoft.com>; 22 May 2005 10:28:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72065678 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 10:28:52 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 10:28:52 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2EC5238712 for ; Sun, 22 May 2005 16:28:53 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZrRk-00075U-1x for forces@peach.ease.lsoft.com; Sun, 22 May 2005 16:28:52 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116772132.01.0.297627234334.issue23@mip4.org> Date: Sun, 22 May 2005 14:28:52 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue23] Common Header - Open Issues To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : Editorial Note: There are several open issues, listed below, in the header which still need to be settled: 1. Parallelization of PL Windowing/subsequence Someone to look into ISCSI 2. events and replies and relation to peer to peer vs master slave 3. We need to discuss whether some of the Flags such as those for Atomicity, Batching are needed in the common header or only belong to the PATH flags. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 40 nosy: avri priority: Must fix status: No discussion title: Common Header - Open Issues ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:15:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09928 for ; Sun, 22 May 2005 14:15:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvH3-0001qo-Hd for forces-archive@IETF.ORG; Sun, 22 May 2005 14:34:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01055466@cherry.ease.lsoft.com>; 22 May 2005 14:15:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090241 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:15:38 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:15:38 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 630DC3876D for ; Sun, 22 May 2005 20:15:37 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZuzA-0002sS-75 for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:15:37 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116785732.32.0.257639622536.issue24@mip4.org> Date: Sun, 22 May 2005 18:15:32 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue24] CE-LFB To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : section 6.2.1 Editorial Note: The CE LFB is under discussion still and may end up being removed. So does the CE LFB stay or go? ---------- category: Technical draft: draft-ietf-forces-protocol messages: 41 nosy: avri priority: Must fix status: No discussion title: CE-LFB ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:17:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10049 for ; Sun, 22 May 2005 14:17:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvIv-0001wy-6l for forces-archive@IETF.ORG; Sun, 22 May 2005 14:36:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010555B2@cherry.ease.lsoft.com>; 22 May 2005 14:17:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090451 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:17:32 -0400 Received: from 81.228.8.93 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:17:32 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8B78F38AAD for ; Sun, 22 May 2005 20:17:31 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZv10-0005T9-LQ for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:17:31 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116785850.6.0.095573243262.issue25@mip4.org> Date: Sun, 22 May 2005 18:17:30 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue25] Association - exceptions to procedure To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E4.1 Association Setup Editorial Note: In certain situations (such as use of multicast IDs), it might not be possible to make use of the procedure described above for the FE to dynamically obtain an ID from the CE. Such situations need to be identified. this message will still require some small discussion; for now goal is to convert to something using the two core FE LFBs. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 42 nosy: avri priority: Must fix status: No discussion title: Association - exceptions to procedure ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:19:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10186 for ; Sun, 22 May 2005 14:19:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvKP-000232-On for forces-archive@IETF.ORG; Sun, 22 May 2005 14:37:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010553C5@cherry.ease.lsoft.com>; 22 May 2005 14:19:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090514 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:19:07 -0400 Received: from 81.228.9.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:19:06 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 2B55438756 for ; Sun, 22 May 2005 20:19:06 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZv2X-0005U6-1W for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:19:05 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116785945.0.0.399691556709.issue26@mip4.org> Date: Sun, 22 May 2005 18:19:05 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue26] Teardown - Reason To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : Editorial Note: Details of how Reason will be carried in the Teardown message are still unclear. There is no such attribute at the FE Object at the moment. There is also no operation by the name of FEReason. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 43 nosy: avri priority: Must fix status: No discussion title: Teardown - Reason ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:20:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10379 for ; Sun, 22 May 2005 14:20:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvM9-00025V-6y for forces-archive@IETF.ORG; Sun, 22 May 2005 14:39:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.01055528@cherry.ease.lsoft.com>; 22 May 2005 14:20:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090596 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:20:53 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:20:53 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 07BE038788 for ; Sun, 22 May 2005 20:20:53 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZv4F-0005a5-Ok for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:20:52 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786051.72.0.875236756736.issue27@mip4.org> Date: Sun, 22 May 2005 18:20:51 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue27] Config Repsonse - Result To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E5.2 Editorial Note: The operation result etc is still under discussion and will depend on verbosity levels in the main message headers ---------- category: Technical draft: draft-ietf-forces-protocol messages: 44 nosy: avri priority: Must fix status: No discussion title: Config Repsonse - Result ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:23:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10618 for ; Sun, 22 May 2005 14:23:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvP0-00029f-S3 for forces-archive@IETF.ORG; Sun, 22 May 2005 14:42:20 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0105557F@cherry.ease.lsoft.com>; 22 May 2005 14:23:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090798 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:23:50 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:23:50 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id EEF3038787 for ; Sun, 22 May 2005 20:23:49 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZv76-0005bP-Qs for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:23:49 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786228.77.0.081196188951.issue28@mip4.org> Date: Sun, 22 May 2005 18:23:48 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue28] Query and Query Response - LFB Instance addessing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E6 Editorial Note: 1. Under discussion is whether there is a need for explicit multiple LFB insatance addressing here. One way to realize it is to define a specific Instance select TLV to substitute above 'LFB Instance ID' field. The TLV may have following format: INSselectTLV :=3D Type Length Value Type :=3D INSselect Value :=3D InstanceID (RangeMark | Instance ID)+ 2. An applicable RangeMark is '0xffffffff', the value of which is the same as Instance broadcast ID. Because there will be no broadcast address applied in this place, there will be no worry of ambiguity here. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 45 nosy: avri priority: Must fix status: No discussion title: Query and Query Response - LFB Instance addessing ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:26:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10843 for ; Sun, 22 May 2005 14:26:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvRh-0002E6-2W for forces-archive@IETF.ORG; Sun, 22 May 2005 14:45:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01055445@cherry.ease.lsoft.com>; 22 May 2005 14:26:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72090939 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:26:37 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:26:37 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id D724B38789 for ; Sun, 22 May 2005 20:26:36 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZv9l-0005hF-Tq for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:26:36 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786393.88.0.285808544152.issue29@mip4.org> Date: Sun, 22 May 2005 18:26:33 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue29] Path attribute ID To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E6.1 Path(or Attribute ID?): [Under discussion and TBD] Editorial Note: There is a debate on whether we should use a 'Path' or simply an 'Attribute ID' or a 'Table ID' here at the protocol layer. A Path is used for data indexing for a table, while an 'Attribute ID' or a 'Table ID' only specify which attribute or table to use, leaving table index to be included in followed data. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 46 nosy: avri priority: Must fix status: No discussion title: Path attribute ID ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11137 for ; Sun, 22 May 2005 14:29:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvUV-0002Jz-MO for forces-archive@IETF.ORG; Sun, 22 May 2005 14:47:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010554DD@cherry.ease.lsoft.com>; 22 May 2005 14:29:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72091295 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:29:32 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:29:32 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6007838046 for ; Sun, 22 May 2005 20:29:31 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvCc-0005he-Hb for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:29:30 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786570.5.0.359923710414.issue30@mip4.org> Date: Sun, 22 May 2005 18:29:30 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue30] Event subscription To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E7 Editorial Note: There is an argument that it is preferable to have all events subscribable. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 47 nosy: avri priority: Must fix status: No discussion title: Event subscription ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:31:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11373 for ; Sun, 22 May 2005 14:31:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvWX-0002Mo-Rn for forces-archive@IETF.ORG; Sun, 22 May 2005 14:50:07 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01055457@cherry.ease.lsoft.com>; 22 May 2005 14:31:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72091539 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:31:32 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:31:32 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id EDC7E38046 for ; Sun, 22 May 2005 20:31:31 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvEY-0005nX-JA for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:31:31 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786689.89.0.733606930711.issue31@mip4.org> Date: Sun, 22 May 2005 18:31:29 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue31] Necessity of Notification Response Message To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E7.2 Editorial Note: There is a debate on whether the Event Notification Response Message is necessary or not. The pro for it is some event notification senders may be interested in knowing if receivers have had success/unsuccess receptions of the events or not. An alternative to generate such response is for the protocol to define a universal ACK message so that it can act as responses for any types of messages as well as the event notification messages, when the message senders are interested in knowing whether the messages have been successfully received or not (different from the responses for the message processing results). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 48 nosy: avri priority: Must fix status: No discussion title: Necessity of Notification Response Message ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:35:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11666 for ; Sun, 22 May 2005 14:35:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvZv-0002Rt-BC for forces-archive@IETF.ORG; Sun, 22 May 2005 14:53:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01055605@cherry.ease.lsoft.com>; 22 May 2005 14:35:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72091819 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:35:08 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:35:07 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 1EA273873A for ; Sun, 22 May 2005 20:35:07 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvI1-0005qH-Cr for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:35:06 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116786905.33.0.544707347688.issue32@mip4.org> Date: Sun, 22 May 2005 18:35:05 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E8 Editorial Note: There are also discussions on how LFBs in FE model that are related to packet redirect operations should be defined. Although it is out of the scope of forces protocol, how to define the LFBs affect the Packet Redirect Message described here. Because currently it is still in progress in FE model on how to define such LFBs, we try to post some thoughts on this here for discussion. They will be removed later along with the progress of the FE model work. Thought 1: To define LFBs called 'RedirectSink' and 'RedirectTap' for packet redirect. An LFB in FE called 'RedirectSink' is responsible to collect data packets that need to be redirected to CE. From the perspective of the FE LFB topology, the 'RedirectSink' LFB is an LFB with only one input port and without any output port, and the input port can then be connected to any other LFB in FE model by means of a datapath in the forwarding plane. From the perspective of the ForCES protocol layer, the 'RedirectSink' LFB will generate the Packet Redirect Messages when it receives data packets from forwarding plane. An LFB in FE called 'RedirectTap' is responsible to receive data packets that are redirected from CE. From the perspective of the FE LFB topology, the 'RedirectTap' LFB is an LFB with only one output port and without any input port, and the output port can then be connected to any other LFB in FE model by means of a datapath in the forwarding plane. From the perspective of ForCES protocol layer, the 'RedirectTap' LFB can receive the Packet Redirect Messages from CE, and un-encapsulate the data packets from the message and put them to datapaths in the forwarding plane. Actually the 'RecirectTap' LFB acts more like a transcoder that transfers the ForCES protocol messages to normal data packets in IP forwarding plane. As a result, if we need to have redirected packets connected to some LFB (say a Scheduler) in FE model, we only need to connect the 'RedirectTap LFB to the Scheduler LFB directly via a datapath as follows: +-----------------+ +-----------+ | RedirectTap LFB |------>| | +-----------------+ | | | Scheduler | From other LFB ---->| LFB | | | +-----------+ Figure 27 By use of several 'RedirectSink' LFBs and several 'RedirectTap' LFBs that connect to several different datapaths in FE forwarding plane, multiple packet redirect paths between CE and FE can be constructed. Thought 2: There might be another way a packet could be redirected: directly by a forwarding path, e.g., by FPGA/ASIC/NP microcode. In such a case we do not need to put in a lot of smartness. Probably a link layer or even network level header is enough. The receiver demuxes it only based on some protocol type in the link layer or network transport layer. The pros for this appraoch is it may provide a fast and cost-effective path for packet redirect. The cons for this is it may more or less confuses the Fp reference point definition in ForCES framework. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 49 nosy: avri priority: Must fix status: No discussion title: Packet Redirect ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:38:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12012 for ; Sun, 22 May 2005 14:38:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvdB-0002YH-97 for forces-archive@IETF.ORG; Sun, 22 May 2005 14:56:58 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01055561@cherry.ease.lsoft.com>; 22 May 2005 14:38:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092011 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:38:30 -0400 Received: from 81.228.8.93 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:38:30 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 73F5238AC6 for ; Sun, 22 May 2005 20:38:29 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvLI-0005u6-Ei for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:38:28 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787108.41.0.84296161049.issue33@mip4.org> Date: Sun, 22 May 2005 18:38:28 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue33] TBD - Command Pipelining To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 3=2E3.3.2 Command Pipelining TBD ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 50 nosy: avri priority: Must fix status: No discussion title: TBD - Command Pipelining ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:41:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12435 for ; Sun, 22 May 2005 14:41:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvgO-0002fY-Nc for forces-archive@IETF.ORG; Sun, 22 May 2005 15:00:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0105561D@cherry.ease.lsoft.com>; 22 May 2005 14:41:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092147 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:41:49 -0400 Received: from 81.228.9.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:41:49 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0ECE038760 for ; Sun, 22 May 2005 20:41:49 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvOW-00060I-Bm for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:41:48 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787308.32.0.300157080318.issue34@mip4.org> Date: Sun, 22 May 2005 18:41:48 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue34] TBD - Flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : Flags(32 bits): Identified so far: - ACK indicator(2 bit) The description for using the two bits is: 'NoACK' (00) 'SuccessACK'(01) 'UnsuccessACK'(10) 'ACKAll' (11) - Priority (3 bits) TBD - Throttle flag - Batch (2 bits) - Atomicity (1 or more bits. TBD) ---------- category: Technical draft: draft-ietf-forces-protocol messages: 51 nosy: avri priority: Must fix status: No discussion title: TBD - Flags ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:45:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13035 for ; Sun, 22 May 2005 14:45:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvkJ-0002o2-Fo for forces-archive@IETF.ORG; Sun, 22 May 2005 15:04:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0105548C@cherry.ease.lsoft.com>; 22 May 2005 14:45:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092279 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:45:52 -0400 Received: from 81.228.8.93 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:45:52 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7330A37E5A for ; Sun, 22 May 2005 20:45:51 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvSQ-00066U-LV for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:45:51 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787550.62.0.0926747895574.issue35@mip4.org> Date: Sun, 22 May 2005 18:45:50 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue35] TBD - FE TML Events To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E2.1=20 The FE Protocol LFB consists of the following elements: o FE Protocol events that can be subscribed/unsubscribed: * FE heartbeat * FE TML events (TBD) ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 53 nosy: avri priority: Must fix status: No discussion title: TBD - FE TML Events ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:48:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13547 for ; Sun, 22 May 2005 14:48:30 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvmq-0002uG-8I for forces-archive@IETF.ORG; Sun, 22 May 2005 15:06:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010554F6@cherry.ease.lsoft.com>; 22 May 2005 14:48:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092505 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:48:29 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:48:29 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6413D3874D for ; Sun, 22 May 2005 20:48:28 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvUx-00067a-Hf for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:48:28 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787707.07.0.962364733422.issue36@mip4.org> Date: Sun, 22 May 2005 18:48:27 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue36] Note: - FE and CE Failover To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol Doria (co-editor) Expires April 4, 2005 [Page 31] Internet-Draft ForCES October 2004 6=2E2.1 * Current version of the FE model * FE unicast ID * FE multicast ID(s) (list) * Association Expiry Timer * Heartbeat Interval * Primary CE * FE failover and restart policy * CE failover and restart policy Note: Is there a difference between the CE and FE failover policies? ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 54 nosy: avri priority: Must fix status: No discussion title: Note: - FE and CE Failover ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:50:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13689 for ; Sun, 22 May 2005 14:50:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvoc-0002wi-BA for forces-archive@IETF.ORG; Sun, 22 May 2005 15:08:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010555F3@cherry.ease.lsoft.com>; 22 May 2005 14:50:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092757 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:50:12 -0400 Received: from 81.228.9.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:50:12 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 50F73381F2 for ; Sun, 22 May 2005 20:50:11 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvWc-0006Co-2z for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:50:10 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787810.01.0.19338144736.issue37@mip4.org> Date: Sun, 22 May 2005 18:50:10 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E2.1 o FE Protocol attributes (can be read and set): * Current version of the ForCES protocol Doria (co-editor) Expires April 4, 2005 [Page 31] Internet-Draft ForCES October 2004 * Current version of the FE model * FE unicast ID * FE multicast ID(s) (list) * Association Expiry Timer * Heartbeat Interval * Primary CE * FE failover and restart policy * CE failover and restart policy =20 TBD: Define default values for each attribute where applicable. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 55 nosy: avri priority: Must fix status: No discussion title: TBD - FE Protocol Attributes ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:52:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13858 for ; Sun, 22 May 2005 14:52:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvqd-000306-LX for forces-archive@IETF.ORG; Sun, 22 May 2005 15:10:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010555A0@cherry.ease.lsoft.com>; 22 May 2005 14:52:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72092862 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:52:24 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:52:24 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 9FF8F387A0 for ; Sun, 22 May 2005 20:52:23 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvYk-0006E1-JY for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:52:23 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116787942.56.0.299479266216.issue38@mip4.org> Date: Sun, 22 May 2005 18:52:22 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue38] TBD - config path + data To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E5.1 Config path + Data (variable length): This will carry LFB specific data (, presentation preliminary found in this doc but still TBD. ). The config data might itself be of the form of a TLV. Should be noted only a CREATE, REPLACE will have data while the rest will only carry path information of what to DELete or GET. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 56 nosy: avri priority: Must fix status: No discussion title: TBD - config path + data ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 14:58:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14374 for ; Sun, 22 May 2005 14:58:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvw4-0003CV-F0 for forces-archive@IETF.ORG; Sun, 22 May 2005 15:16:29 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010555C2@cherry.ease.lsoft.com>; 22 May 2005 14:58:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72093311 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 14:58:00 -0400 Received: from 81.228.8.92 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 14:58:00 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 76E34387A4 for ; Sun, 22 May 2005 20:57:59 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZveA-0006L1-Gx for forces@peach.ease.lsoft.com; Sun, 22 May 2005 20:57:59 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116788278.48.0.143990081604.issue39@mip4.org> Date: Sun, 22 May 2005 18:57:58 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue39] Protocol LFB - Heart Beat Dead Interval To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : C=2E3.2 HBDI This attribute carries the Heartbeat Dead Interval in millisecs. TBD: C=2E3.2 The original goal for HBDI was for HA purposes - to discover if the CE is still around by sending a heartbeat message to the CE with an ACK flag in the mainheader to request for a response. This hasnt been discussed in details yet; however, the general view at the time was for the FE to associate (failover) to another CE after that deadinterval period of not hearing from the CE - as defined by policy which resides in that same LFB definition. Two such failover methodologies are mentiooned briefly infact in the protocol draft but since the current attributes are unknown, the details are missing from the xml. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 57 nosy: avri priority: Must fix status: No discussion title: Protocol LFB - Heart Beat Dead Interval ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 15:00:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14706 for ; Sun, 22 May 2005 15:00:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvys-0003QT-Kd for forces-archive@IETF.ORG; Sun, 22 May 2005 15:19:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.01055627@cherry.ease.lsoft.com>; 22 May 2005 15:00:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72093443 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 15:00:55 -0400 Received: from 81.228.9.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 15:00:55 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6202537ED9 for ; Sun, 22 May 2005 21:00:54 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvgz-0006R7-7K for forces@peach.ease.lsoft.com; Sun, 22 May 2005 21:00:53 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, UPPERCASE_25_50,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116788453.17.0.150373334311.issue40@mip4.org> Date: Sun, 22 May 2005 19:00:53 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue40] BLKINFO To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : * NOTE! NOTE! There is a selector known as BLKINFO that is left out of this doc for now that will be revisted later. BLKINFO is defined as: * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=3D [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A PathData can only have one selector either a KEYINFO TLV or a BLKINFO TLV (i.e not both). Revisit before PS or after? ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 58 nosy: avri priority: May fix status: No discussion title: BLKINFO ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 15:03:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14996 for ; Sun, 22 May 2005 15:03:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZw13-0003Z2-7u for forces-archive@IETF.ORG; Sun, 22 May 2005 15:21:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010554D2@cherry.ease.lsoft.com>; 22 May 2005 15:03:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72093652 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 15:03:09 -0400 Received: from 81.228.9.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 15:03:09 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E6E3638757 for ; Sun, 22 May 2005 21:03:06 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvj7-0006SE-7v for forces@peach.ease.lsoft.com; Sun, 22 May 2005 21:03:05 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116788585.2.0.571007627991.issue41@mip4.org> Date: Sun, 22 May 2005 19:03:05 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue41] CE LFB Events - explicit subsction To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : 6=2E2.3 CE Events: * CEAllEvents: subscribing to this corresponds to subscribing to all events listed below. Note: Do we want to allow an FE to explicitly subscribe to CE events? * CEStatusChange: events that signal CE Up/Down/Active/Inactive/Failover. Note: Such events do not necessarily need to be subscribed to, they can fire even without subscription and be sent to the FE ---------- category: Technical draft: draft-ietf-forces-protocol messages: 59 nosy: avri priority: Must fix status: No discussion title: CE LFB Events - explicit subsction ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun May 22 15:10:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15926 for ; Sun, 22 May 2005 15:10:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZw83-00040g-4u for forces-archive@IETF.ORG; Sun, 22 May 2005 15:28:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010554E6@cherry.ease.lsoft.com>; 22 May 2005 15:10:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72094060 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 15:10:23 -0400 Received: from 81.228.8.93 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 22 May 2005 15:10:23 -0400 Received: from shiraz.levkowetz.com (213-64-173-70-o871.telia.com [213.64.173.70]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id DAA1738AAD for ; Sun, 22 May 2005 21:10:22 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=213-64-173-70-o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DZvqA-0006vw-0p for forces@peach.ease.lsoft.com; Sun, 22 May 2005 21:10:22 +0200 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO 213-64-173-70-o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Avri Doria Message-ID: <1116789018.06.0.201458914209.issue42@mip4.org> Date: Sun, 22 May 2005 19:10:18 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Avri Doria Subject: [issue42] IANA Section To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable New submission from Avri Doria : there isn't one and should be. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 60 nosy: avri priority: Must fix status: No discussion title: IANA Section ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 02:07:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07470 for ; Mon, 23 May 2005 02:07:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da6Nf-0002Lf-8a for forces-archive@IETF.ORG; Mon, 23 May 2005 02:25:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010562CE@cherry.ease.lsoft.com>; Mon, 23 May 2005 2:07:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72129406 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 02:07:04 -0400 Received: from 72.254.0.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 02:07:04 -0400 Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.0.0.59) with SMTP id M2005052223070430591 for ; Sun, 22 May 2005 23:07:04 -0700 Received: from JMHLap3.stevecrocker.com ([10.5.95.181]) by s-utl01-sjpop.stsn.net for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 23:07:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116771610.3.0.348509681991.issue21@mip4.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050523020321.02c9d7b8@localhost> Date: Mon, 23 May 2005 02:07:04 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue21] TML Timeliness - Obsoleteing messages To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1116771610.3.0.348509681991.issue21@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 While obsoleting messages is attractive, I think the TML should not have this. The first thing that occurred to me was that maybe we could have an optional obsoleting mechanism? We could, but it seems to me the complexity of putting optional capabilities in the TML is a bad trade. The other issue is that if we want to be able to use a stock or nearly stock TCP as a TML, it can not obsolete messages. At the same time, I am doubtful about the overall value of obsoleting messages. Any situation in which one side or the other might want to obsolete messages, it would still have to deal with "too late, its gone out already." SO obsoleting messages is always going to introduce more code complexity. There are some interesting questions that need some thought about what the PL / TML can or should do if the FE-CE link does get seriously congested. Yours, Joel At 10:20 AM 5/22/2005, Avri Doria wrote: >New submission from Avri Doria : > >In Section 4 TML Requirements > >Timeliness > > Editorial Note: Does the TML allow for obsoleting msgs? If yes, > it needs to define how. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 38 >nosy: avri >priority: Must fix >status: No discussion >title: TML Timeliness - Obsoleteing messages > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 02:08:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09119 for ; Mon, 23 May 2005 02:08:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da6PF-0002RY-4Z for forces-archive@IETF.ORG; Mon, 23 May 2005 02:27:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01056255@cherry.ease.lsoft.com>; Mon, 23 May 2005 2:08:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72129479 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 02:08:42 -0400 Received: from 72.254.0.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 02:08:42 -0400 Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.0.0.59) with SMTP id M2005052223084230604 for ; Sun, 22 May 2005 23:08:42 -0700 Received: from JMHLap3.stevecrocker.com ([10.5.95.181]) by s-utl01-sjpop.stsn.net for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 23:08:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116785732.32.0.257639622536.issue24@mip4.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050523020713.02e1e938@localhost> Date: Mon, 23 May 2005 02:08:42 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue24] CE-LFB To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1116785732.32.0.257639622536.issue24@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 this is one where I personally find the symettry is not valuable, but I do understand the reasoning that leads to the idea. If there are a number of different things that the FE needs to be able to ask the CE about, at times of the FE's choosing, then this starts to make more sense. So far, I simply have not seen sufficient driver. Yours, Joel At 02:15 PM 5/22/2005, Avri Doria wrote: >New submission from Avri Doria : > >section 6.2.1 > >Editorial Note: The CE LFB is under discussion still and may end up > being removed. > >So does the CE LFB stay or go? > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 41 >nosy: avri >priority: Must fix >status: No discussion >title: CE-LFB > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 02:11:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12083 for ; Mon, 23 May 2005 02:11:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da6S5-0002Yq-60 for forces-archive@IETF.ORG; Mon, 23 May 2005 02:30:13 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010563C1@cherry.ease.lsoft.com>; Mon, 23 May 2005 2:11:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72129563 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 02:11:38 -0400 Received: from 72.254.0.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 02:11:38 -0400 Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.0.0.59) with SMTP id M2005052223113830624 for ; Sun, 22 May 2005 23:11:38 -0700 Received: from JMHLap3.stevecrocker.com ([10.5.95.181]) by s-utl01-sjpop.stsn.net for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 23:11:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786393.88.0.285808544152.issue29@mip4.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050523020846.02e1df80@localhost> Date: Mon, 23 May 2005 02:11:37 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue29] Path attribute ID To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1116786393.88.0.285808544152.issue29@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I am not sure I understand the question as phrased. The current model plan is that targetting of operations (get, set, delete, ...) will use an LFB Class ID, an LFB Instance ID, and then one or more paths (with sub-paths). A path consists of a sequence of identifiers so that one can refer to an entire array within the LFB, an entry in an array, or even a field in a structucture which is an element of an array within a structure in the LFB. (Many LFBs will have shallow structure. Some will have more complex structure. And a few will get VERY messy. I would hate to try to assign IDs from a single flat space to everything that might be referenced. (Yes, the ID space is big enough. But structure is our friend in making this implementable, robust, and debuggable.) Yours, Joel At 02:26 PM 5/22/2005, Avri Doria wrote: >New submission from Avri Doria : > >6.6.1 > > Path(or Attribute ID?): > [Under discussion and TBD] > > Editorial Note: There is a debate on whether we should use a > 'Path' or simply an 'Attribute ID' or a 'Table > ID' here at the protocol layer. A Path is used > for data indexing for a table, while an > 'Attribute ID' or a 'Table ID' only specify > which attribute or table to use, leaving table > index to be included in followed data. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 46 >nosy: avri >priority: Must fix >status: No discussion >title: Path attribute ID > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 02:15:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15649 for ; Mon, 23 May 2005 02:15:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da6Vd-0002cX-DI for forces-archive@IETF.ORG; Mon, 23 May 2005 02:33:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.01056273@cherry.ease.lsoft.com>; Mon, 23 May 2005 2:15:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72129713 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 02:15:18 -0400 Received: from 72.254.0.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 02:15:17 -0400 Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.0.0.59) with SMTP id M2005052223151830640 for ; Sun, 22 May 2005 23:15:18 -0700 Received: from JMHLap3.stevecrocker.com ([10.5.95.181]) by s-utl01-sjpop.stsn.net for FORCES@PEACH.EASE.LSOFT.COM; Sun, 22 May 2005 23:15:17 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786905.33.0.544707347688.issue32@mip4.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050523021143.02e29df8@localhost> Date: Mon, 23 May 2005 02:15:17 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1116786905.33.0.544707347688.issue32@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f My own thinking has leaned towards something along the lines of Thought 1. Primarily, this is so that there is a place to put an TML parameters (and represent any TML processing logic) required for handling redirect packets. Making encapsulation or other behaviors "implicit" in some aspect of the forwarding path seems a bad idea. In passing, I note that I think one needs only one Sink and one Tap. The Sink LFB should be able to get enough information from the packet and meta-data to do the job of redirecting the packet to the CE. And any LFB can have a link to the one sink LFB. SImilarly, there ought to be only one tap, since redirect packets from the CE have to be processed in one place, analyzed, and sent into the LFB topology. If there is branching / conditions (OSPF packets go one place, ICMP goes somewhere else, ...) I think that can and should be handled by a classifier, rather than by multiple Tap LFBs. Yours, Joel At 02:35 PM 5/22/2005, Avri Doria wrote: >New submission from Avri Doria : > >6.8 > > Editorial Note: There are also discussions on how LFBs in FE model > that are related to packet redirect operations > should be defined. Although it is out of the scope > of forces protocol, how to define the LFBs affect > the Packet Redirect Message described here. Because > currently it is still in progress in FE model on how > to define such LFBs, we try to post some thoughts on > this here for discussion. They will be removed > later along with the progress of the FE model work. > Thought 1: To define LFBs called 'RedirectSink' and > 'RedirectTap' for packet redirect. > An LFB in FE called 'RedirectSink' is responsible to > collect data packets that need to be redirected to > CE. From the perspective of the FE LFB topology, > the 'RedirectSink' LFB is an LFB with only one input > port and without any output port, and the input port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of the ForCES protocol layer, > the 'RedirectSink' LFB will generate the Packet > Redirect Messages when it receives data packets from > forwarding plane. > > An LFB in FE called 'RedirectTap' is responsible to > receive data packets that are redirected from CE. > From the perspective of the FE LFB topology, the > 'RedirectTap' LFB is an LFB with only one output > port and without any input port, and the output port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of ForCES protocol layer, the > 'RedirectTap' LFB can receive the Packet Redirect > Messages from CE, and un-encapsulate the data > packets from the message and put them to datapaths > in the forwarding plane. Actually the 'RecirectTap' > LFB acts more like a transcoder that transfers the > ForCES protocol messages to normal data packets in > IP forwarding plane. As a result, if we need to > have redirected packets connected to some LFB (say a > Scheduler) in FE model, we only need to connect the > 'RedirectTap LFB to the Scheduler LFB directly via a > datapath as follows: > > > +-----------------+ +-----------+ > | RedirectTap LFB |------>| | > +-----------------+ | | > | Scheduler | > From other LFB ---->| LFB | > | | > +-----------+ > > Figure 27 > > By use of several 'RedirectSink' LFBs and several > 'RedirectTap' LFBs that connect to several different > datapaths in FE forwarding plane, multiple packet > redirect paths between CE and FE can be constructed. > > Thought 2: There might be another way a packet could be > redirected: directly by a forwarding path, e.g., by > FPGA/ASIC/NP microcode. In such a case we do not > need to put in a lot of smartness. Probably a link > layer or even network level header is enough. The > receiver demuxes it only based on some protocol type > in the link layer or network transport layer. The > pros for this appraoch is it may provide a fast and > cost-effective path for packet redirect. The cons > for this is it may more or less confuses the Fp > reference point definition in ForCES framework. > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 49 >nosy: avri >priority: Must fix >status: No discussion >title: Packet Redirect > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 07:18:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14364 for ; Mon, 23 May 2005 07:18:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBEY-00088g-Oa for forces-archive@IETF.ORG; Mon, 23 May 2005 07:36:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010564B7@cherry.ease.lsoft.com>; Mon, 23 May 2005 7:17:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72171033 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 07:17:58 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 07:17:57 -0400 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 j4NBIem0011070 for ; Mon, 23 May 2005 13:18:40 +0200 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.622) Approved-By: avri@PSG.COM Message-ID: <6b8f46afcdc52f65c83abf4c1fdf87db@psg.com> Date: Mon, 23 May 2005 13:17:41 +0200 Reply-To: avri@psg.com Sender: Forwarding and Control Element Separation From: avri@psg.com Subject: Tracker replies To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Hi, Since all entries made in the tracker go to the mailing list, but all email replies don't go into the tracker, it would help if people used the tracker to make specific replies. though maybe cc'ing tracker-forces@mip4.org will help. or adding this address to the subscription list. not something i can do. thanks a. From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 10:21:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28574 for ; Mon, 23 May 2005 10:21:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaE5x-0005FK-IJ for forces-archive@IETF.ORG; Mon, 23 May 2005 10:39:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.01056842@cherry.ease.lsoft.com>; Mon, 23 May 2005 10:21:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72206461 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 10:21:09 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 10:21:08 -0400 Received: from [58.100.169.127] by 202.96.99.56 with StormMail ESMTP id 74778.1307239863; Mon, 23 May 2005 22:50:33 +0800 (CST) References: <1116771610.3.0.348509681991.issue21@mip4.org> <6.2.1.2.0.20050523020321.02c9d7b8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <006b01c55c7d$f2bdce80$020aa8c0@wwm1> Date: Thu, 19 May 2005 22:20:32 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue21] TML Timeliness - Obsoleteing messages Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 3.4 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: base64 U28gbWFueSBpc3N1ZXMgbGlzdGVkLiBJIGhhdmUgdG8gYmUgbW9yZSB0byB0aGUgcG9pbnQuDQoN CkFncmVlIHRoYXQgb2Jzb2xldGluZyBtZXNzYWdlcyBieSBQTCBpcyBub3QgYSBnb29kIGVub3Vn aCBjaG9pY2UgZm9yIHRpbWVsaW5lc3Mgb2YgbWVzc2FnZSB0cmFuc3BvcnQuICBNZXNzYWdlIHBy aW9yaXRpZXMgbWF5IGhlbHAgdGltZWxpbmVzcyBtb3JlIG9yIGxlc3MuICAgDQoNClRoYW5rcywN CldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0u IEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpTdWJqZWN0OiBSZTogW2lzc3VlMjFd IFRNTCBUaW1lbGluZXNzIC0gT2Jzb2xldGVpbmcgbWVzc2FnZXMNCg0KDQo+IFdoaWxlIG9ic29s ZXRpbmcgbWVzc2FnZXMgaXMgYXR0cmFjdGl2ZSwgSSB0aGluayB0aGUgVE1MIHNob3VsZCBub3Qg aGF2ZSB0aGlzLg0KPiANCj4gVGhlIGZpcnN0IHRoaW5nIHRoYXQgb2NjdXJyZWQgdG8gbWUgd2Fz IHRoYXQgbWF5YmUgd2UgY291bGQgaGF2ZSBhbiANCj4gb3B0aW9uYWwgb2Jzb2xldGluZyBtZWNo YW5pc20/ICBXZSBjb3VsZCwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoZSBjb21wbGV4aXR5IA0KPiBv ZiBwdXR0aW5nIG9wdGlvbmFsIGNhcGFiaWxpdGllcyBpbiB0aGUgVE1MIGlzIGEgYmFkIHRyYWRl Lg0KPiANCj4gVGhlIG90aGVyIGlzc3VlIGlzIHRoYXQgaWYgd2Ugd2FudCB0byBiZSBhYmxlIHRv IHVzZSBhIHN0b2NrIG9yIG5lYXJseSANCj4gc3RvY2sgVENQIGFzIGEgVE1MLCBpdCBjYW4gbm90 IG9ic29sZXRlIG1lc3NhZ2VzLg0KPiANCj4gQXQgdGhlIHNhbWUgdGltZSwgSSBhbSBkb3VidGZ1 bCBhYm91dCB0aGUgb3ZlcmFsbCB2YWx1ZSBvZiBvYnNvbGV0aW5nIA0KPiBtZXNzYWdlcy4gIEFu eSBzaXR1YXRpb24gaW4gd2hpY2ggb25lIHNpZGUgb3IgdGhlIG90aGVyIG1pZ2h0IHdhbnQgdG8g DQo+IG9ic29sZXRlIG1lc3NhZ2VzLCBpdCB3b3VsZCBzdGlsbCBoYXZlIHRvIGRlYWwgd2l0aCAi dG9vIGxhdGUsIGl0cyBnb25lIG91dCANCj4gYWxyZWFkeS4iICBTTyBvYnNvbGV0aW5nIG1lc3Nh Z2VzIGlzIGFsd2F5cyBnb2luZyB0byBpbnRyb2R1Y2UgbW9yZSBjb2RlIA0KPiBjb21wbGV4aXR5 Lg0KPiANCj4gVGhlcmUgYXJlIHNvbWUgaW50ZXJlc3RpbmcgcXVlc3Rpb25zIHRoYXQgbmVlZCBz b21lIHRob3VnaHQgYWJvdXQgd2hhdCB0aGUgDQo+IFBMIC8gVE1MIGNhbiBvciBzaG91bGQgZG8g aWYgdGhlIEZFLUNFIGxpbmsgZG9lcyBnZXQgc2VyaW91c2x5IGNvbmdlc3RlZC4NCj4gDQo+IFlv dXJzLA0KPiBKb2VsDQo+IA0KPiBBdCAxMDoyMCBBTSA1LzIyLzIwMDUsIEF2cmkgRG9yaWEgd3Jv dGU6DQo+ID5OZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPGF2cmlAYWNtLm9yZz46DQo+ ID4NCj4gPkluIFNlY3Rpb24gNCBUTUwgUmVxdWlyZW1lbnRzDQo+ID4NCj4gPlRpbWVsaW5lc3MN Cj4gPg0KPiA+ICAgICAgICBFZGl0b3JpYWwgTm90ZTogIERvZXMgdGhlIFRNTCBhbGxvdyBmb3Ig b2Jzb2xldGluZyBtc2dzPyBJZiB5ZXMsDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgaXQg bmVlZHMgdG8gZGVmaW5lIGhvdy4NCj4gPg0KPiA+LS0tLS0tLS0tLQ0KPiA+Y2F0ZWdvcnk6IFRl Y2huaWNhbA0KPiA+ZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLXByb3RvY29sDQo+ID5tZXNzYWdl czogMzgNCj4gPm5vc3k6IGF2cmkNCj4gPnByaW9yaXR5OiBNdXN0IGZpeA0KPiA+c3RhdHVzOiBO byBkaXNjdXNzaW9uDQo+ID50aXRsZTogVE1MIFRpbWVsaW5lc3MgLSBPYnNvbGV0ZWluZyBtZXNz YWdlcw0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9y Zz4NCj4gPjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFja2VyL2ZvcmNlcy9pc3N1ZTIx Pg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 10:40:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00061 for ; Mon, 23 May 2005 10:40:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEO6-0005zz-M5 for forces-archive@IETF.ORG; Mon, 23 May 2005 10:58:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.01056891@cherry.ease.lsoft.com>; Mon, 23 May 2005 10:40:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72208237 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 10:39:58 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 10:39:58 -0400 Received: from [58.100.169.127] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 23 May 2005 23:09:22 +0800 (CST) References: <1116785732.32.0.257639622536.issue24@mip4.org> <6.2.1.2.0.20050523020713.02e1e938@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <009701c55c80$934e2af0$020aa8c0@wwm1> Date: Thu, 19 May 2005 22:39:26 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue24] CE-LFB To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 3.4 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: base64 SSBmaW5kIHRoZSBDRS1MRkIgaXNzdWUgaXMgcmVsYXRlZCB0byBUTUwgZGVmaW5pdGlvbiBpbiBz b21lIHdheS4gIElmIHdlIGFsbG93IGEgbm90aW9uIGxpa2UgYSBDRS1UTUwsIGhhdmluZyBhIENF LUxGQiBtYXkgZWFzZSB0aGUgQ0UtVE1MIGRlZmluaXRpb24sIHN1Y2ggYXMgdGhlIHNlcnZpY2Ug cHJpbWl0aXZlcyBmb3IgaXQuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tl ci5jb20+DQpTdWJqZWN0OiBSZTogW2lzc3VlMjRdIENFLUxGQg0KDQoNCj4gdGhpcyBpcyBvbmUg d2hlcmUgSSBwZXJzb25hbGx5IGZpbmQgdGhlIHN5bWV0dHJ5IGlzIG5vdCB2YWx1YWJsZSwgYnV0 IEkgZG8gDQo+IHVuZGVyc3RhbmQgdGhlIHJlYXNvbmluZyB0aGF0IGxlYWRzIHRvIHRoZSBpZGVh Lg0KPiBJZiB0aGVyZSBhcmUgYSBudW1iZXIgb2YgZGlmZmVyZW50IHRoaW5ncyB0aGF0IHRoZSBG RSBuZWVkcyB0byBiZSBhYmxlIHRvIA0KPiBhc2sgdGhlIENFIGFib3V0LCBhdCB0aW1lcyBvZiB0 aGUgRkUncyBjaG9vc2luZywgdGhlbiB0aGlzIHN0YXJ0cyB0byBtYWtlIA0KPiBtb3JlIHNlbnNl LiAgU28gZmFyLCBJIHNpbXBseSBoYXZlIG5vdCBzZWVuIHN1ZmZpY2llbnQgZHJpdmVyLg0KPiAN Cj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IEF0IDAyOjE1IFBNIDUvMjIvMjAwNSwgQXZyaSBEb3Jp YSB3cm90ZToNCj4gPk5ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3JpYSA8YXZyaUBhY20ub3Jn PjoNCj4gPg0KPiA+c2VjdGlvbiA2LjIuMQ0KPiA+DQo+ID5FZGl0b3JpYWwgTm90ZTogIFRoZSBD RSBMRkIgaXMgdW5kZXIgZGlzY3Vzc2lvbiBzdGlsbCBhbmQgbWF5IGVuZCB1cA0KPiA+ICAgICAg ICAgICAgICAgICAgICAgYmVpbmcgcmVtb3ZlZC4NCj4gPg0KPiA+U28gZG9lcyB0aGUgQ0UgTEZC IHN0YXkgb3IgZ28/DQo+ID4NCj4gPi0tLS0tLS0tLS0NCj4gPmNhdGVnb3J5OiBUZWNobmljYWwN Cj4gPmRyYWZ0OiBkcmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbA0KPiA+bWVzc2FnZXM6IDQxDQo+ ID5ub3N5OiBhdnJpDQo+ID5wcmlvcml0eTogTXVzdCBmaXgNCj4gPnN0YXR1czogTm8gZGlzY3Vz c2lvbg0KPiA+dGl0bGU6IENFLUxGQg0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj4gPjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFj a2VyL2ZvcmNlcy9pc3N1ZTI0Pg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 10:55:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03127 for ; Mon, 23 May 2005 10:55:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEdF-0006rJ-O9 for forces-archive@IETF.ORG; Mon, 23 May 2005 11:14:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0105689C@cherry.ease.lsoft.com>; Mon, 23 May 2005 10:55:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72209787 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 10:55:39 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 10:55:39 -0400 Received: from [60.191.11.53] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 23 May 2005 23:25:05 +0800 (CST) References: <1116786393.88.0.285808544152.issue29@mip4.org> <6.2.1.2.0.20050523020846.02e1df80@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <00a601c55c82$c54b08a0$020aa8c0@wwm1> Date: Thu, 19 May 2005 22:46:24 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue29] Path attribute ID To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: base64 QXZyaSwNCg0KSSdtIG5vdCBzdXJlIGlmIHlvdSd2IHVzZWQgdGhlIGxhdGVzdCAwMiB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBmb3IgdGhlIGlzc3VlIHRyYWNrZXJzLiBJIHRoaW5rIHRoaXMgZWR0b3Jp YWwgbm90ZSBoYXMgYWxyZWFkeSBiZWVuIHJlbW92ZWQgYW5kIG5vdCBleGlzdGVkIGluIHRoZSAw MiB2ZXJzaW9uLiBUaGUgaXNzdWUgaGFzIGFscmVhZHkgYmVlbiBzb2x2ZWQuDQoNCllvdXJzLA0K V2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4g SGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClN1YmplY3Q6IFJlOiBbaXNzdWUyOV0g UGF0aCBhdHRyaWJ1dGUgSUQNCg0KDQo+IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBx dWVzdGlvbiBhcyBwaHJhc2VkLg0KPiANCj4gVGhlIGN1cnJlbnQgbW9kZWwgcGxhbiBpcyB0aGF0 IHRhcmdldHRpbmcgb2Ygb3BlcmF0aW9ucyAoZ2V0LCBzZXQsIGRlbGV0ZSwgDQo+IC4uLikgd2ls bCB1c2UgYW4gTEZCIENsYXNzIElELCBhbiBMRkIgSW5zdGFuY2UgSUQsIGFuZCB0aGVuIG9uZSBv ciBtb3JlIA0KPiBwYXRocyAod2l0aCBzdWItcGF0aHMpLiAgQSBwYXRoIGNvbnNpc3RzIG9mIGEg c2VxdWVuY2Ugb2YgaWRlbnRpZmllcnMgc28gDQo+IHRoYXQgb25lIGNhbiByZWZlciB0byBhbiBl bnRpcmUgYXJyYXkgd2l0aGluIHRoZSBMRkIsIGFuIGVudHJ5IGluIGFuIGFycmF5LCANCj4gb3Ig ZXZlbiBhIGZpZWxkIGluIGEgc3RydWN0dWN0dXJlIHdoaWNoIGlzIGFuIGVsZW1lbnQgb2YgYW4g YXJyYXkgd2l0aGluIGEgDQo+IHN0cnVjdHVyZSBpbiB0aGUgTEZCLiAgKE1hbnkgTEZCcyB3aWxs IGhhdmUgc2hhbGxvdyBzdHJ1Y3R1cmUuICBTb21lIHdpbGwgDQo+IGhhdmUgbW9yZSBjb21wbGV4 IHN0cnVjdHVyZS4gIEFuZCBhIGZldyB3aWxsIGdldCBWRVJZIG1lc3N5LiAgSSB3b3VsZCBoYXRl IA0KPiB0byB0cnkgdG8gYXNzaWduIElEcyBmcm9tIGEgc2luZ2xlIGZsYXQgc3BhY2UgdG8gZXZl cnl0aGluZyB0aGF0IG1pZ2h0IGJlIA0KPiByZWZlcmVuY2VkLiAgKFllcywgdGhlIElEIHNwYWNl IGlzIGJpZyBlbm91Z2guICBCdXQgc3RydWN0dXJlIGlzIG91ciBmcmllbmQgDQo+IGluIG1ha2lu ZyB0aGlzIGltcGxlbWVudGFibGUsIHJvYnVzdCwgYW5kIGRlYnVnZ2FibGUuKQ0KPiANCj4gWW91 cnMsDQo+IEpvZWwNCj4gDQo+IEF0IDAyOjI2IFBNIDUvMjIvMjAwNSwgQXZyaSBEb3JpYSB3cm90 ZToNCj4gPk5ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3JpYSA8YXZyaUBhY20ub3JnPjoNCj4g Pg0KPiA+Ni42LjENCj4gPg0KPiA+ICAgIFBhdGgob3IgQXR0cmlidXRlIElEPyk6DQo+ID4gICAg ICAgIFtVbmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQo+ID4NCj4gPiAgICAgICAgRWRpdG9yaWFs IE5vdGU6ICBUaGVyZSBpcyBhIGRlYmF0ZSBvbiB3aGV0aGVyIHdlIHNob3VsZCB1c2UgYQ0KPiA+ ICAgICAgICAgICAgICAgICAgICAgICAgICdQYXRoJyBvciBzaW1wbHkgYW4gJ0F0dHJpYnV0ZSBJ RCcgb3IgYSAnVGFibGUNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBJRCcgaGVyZSBhdCB0 aGUgcHJvdG9jb2wgbGF5ZXIuICBBIFBhdGggaXMgdXNlZA0KPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgIGZvciBkYXRhIGluZGV4aW5nIGZvciBhIHRhYmxlLCB3aGlsZSBhbg0KPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICdBdHRyaWJ1dGUgSUQnIG9yIGEgJ1RhYmxlIElEJyBvbmx5IHNw ZWNpZnkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBhdHRyaWJ1dGUgb3IgdGFi bGUgdG8gdXNlLCBsZWF2aW5nIHRhYmxlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgaW5k ZXggdG8gYmUgaW5jbHVkZWQgaW4gZm9sbG93ZWQgZGF0YS4NCj4gPg0KPiA+LS0tLS0tLS0tLQ0K PiA+Y2F0ZWdvcnk6IFRlY2huaWNhbA0KPiA+ZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLXByb3Rv Y29sDQo+ID5tZXNzYWdlczogNDYNCj4gPm5vc3k6IGF2cmkNCj4gPnByaW9yaXR5OiBNdXN0IGZp eA0KPiA+c3RhdHVzOiBObyBkaXNjdXNzaW9uDQo+ID50aXRsZTogUGF0aCBhdHRyaWJ1dGUgSUQN Cj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID5Gb3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo+ ID48aHR0cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUyOT4NCj4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA= From owner-forces@PEACH.EASE.LSOFT.COM Mon May 23 11:13:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04472 for ; Mon, 23 May 2005 11:13:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEuJ-0007eF-Rk for forces-archive@IETF.ORG; Mon, 23 May 2005 11:31:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.01056821@cherry.ease.lsoft.com>; Mon, 23 May 2005 11:13:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72211681 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 May 2005 11:13:17 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 23 May 2005 11:13:16 -0400 Received: from [60.191.11.53] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 23 May 2005 23:42:41 +0800 (CST) References: <1116786905.33.0.544707347688.issue32@mip4.org> <6.2.1.2.0.20050523021143.02e29df8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Approved-By: Weiming Wang Message-ID: <00b301c55c85$3aba49a0$020aa8c0@wwm1> Date: Thu, 19 May 2005 23:12:53 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: base64 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDxq b2VsQHN0ZXZlY3JvY2tlci5jb20+DQpTdWJqZWN0OiBSZTogW2lzc3VlMzJdIFBhY2tldCBSZWRp cmVjdA0KDQoNCj4gTXkgb3duIHRoaW5raW5nIGhhcyBsZWFuZWQgdG93YXJkcyBzb21ldGhpbmcg YWxvbmcgdGhlIGxpbmVzIG9mIFRob3VnaHQgMS4NCj4gUHJpbWFyaWx5LCB0aGlzIGlzIHNvIHRo YXQgdGhlcmUgaXMgYSBwbGFjZSB0byBwdXQgYW4gVE1MIHBhcmFtZXRlcnMgKGFuZCANCj4gcmVw cmVzZW50IGFueSBUTUwgcHJvY2Vzc2luZyBsb2dpYykgcmVxdWlyZWQgZm9yIGhhbmRsaW5nIHJl ZGlyZWN0IA0KPiBwYWNrZXRzLiAgTWFraW5nIGVuY2Fwc3VsYXRpb24gb3Igb3RoZXIgYmVoYXZp b3JzICJpbXBsaWNpdCIgaW4gc29tZSBhc3BlY3QgDQo+IG9mIHRoZSBmb3J3YXJkaW5nIHBhdGgg c2VlbXMgYSBiYWQgaWRlYS4NCg0KQWdyZWVkIHdlbGwuDQoNCj4gDQo+IEluIHBhc3NpbmcsIEkg bm90ZSB0aGF0IEkgdGhpbmsgb25lIG5lZWRzIG9ubHkgb25lIFNpbmsgYW5kIG9uZSBUYXAuICBU aGUgDQo+IFNpbmsgTEZCIHNob3VsZCBiZSBhYmxlIHRvIGdldCBlbm91Z2ggaW5mb3JtYXRpb24g ZnJvbSB0aGUgcGFja2V0IGFuZCANCj4gbWV0YS1kYXRhIHRvIGRvIHRoZSBqb2Igb2YgcmVkaXJl Y3RpbmcgdGhlIHBhY2tldCB0byB0aGUgQ0UuICBBbmQgYW55IExGQiANCj4gY2FuIGhhdmUgYSBs aW5rIHRvIHRoZSBvbmUgc2luayBMRkIuICBTSW1pbGFybHksIHRoZXJlIG91Z2h0IHRvIGJlIG9u bHkgb25lIA0KPiB0YXAsIHNpbmNlIHJlZGlyZWN0IHBhY2tldHMgZnJvbSB0aGUgQ0UgaGF2ZSB0 byBiZSBwcm9jZXNzZWQgaW4gb25lIHBsYWNlLCANCj4gYW5hbHl6ZWQsIGFuZCBzZW50IGludG8g dGhlIExGQiB0b3BvbG9neS4gIElmIHRoZXJlIGlzIGJyYW5jaGluZyAvIA0KPiBjb25kaXRpb25z IChPU1BGIHBhY2tldHMgZ28gb25lIHBsYWNlLCBJQ01QIGdvZXMgc29tZXdoZXJlIGVsc2UsIC4u LikgSSANCj4gdGhpbmsgdGhhdCBjYW4gYW5kIHNob3VsZCBiZSBoYW5kbGVkIGJ5IGEgY2xhc3Np ZmllciwgcmF0aGVyIHRoYW4gYnkgDQo+IG11bHRpcGxlIFRhcCBMRkJzLg0KDQpKb2VsLCBJIHRo aW5rIHRoaXMgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiB0aGUgd29yayBvZiBGRS1MRkIgYW5kIHNv bWUgbW9yZSBMRkIgKGxpa2UgYSBjbGFzc2lmaWVyKS4gTm90ZSB0aGF0IGluIG91ciBjdXJyZW50 IHNjaGVtZSBvZiByZWRpcmVjdCBtZXNzYWdlIGZvcm1hdCwgd2UgYWxsb3cgYW4gTEZCIElELiBU byBiZSB3aXRoIG1vcmUgVGFwcyBhY3R1YWxseSBncmVhdGx5IGV4cG9pbnQgdGhlIHVzZSBvZiBM RkIgSUQgaGVyZS4gRS5nLCB3ZSBtYXkganVzdCBuZWVkIHRvIHNheSAicHV0IHRoZSBPU1BGIHJl ZGlyZWN0IG1lc3NhZ2UgdG8gIExGQiBJRDEgKFRhcDEpIiBhbmQgIiBwdXQgIHRoZSBJQ01QIHJl ZGlyZWN0IG1lc3NhZ2UgdG8gTEZCIElEMihUYXAyKSIuICBJZiB1c2luZyBvbmx5IG9uZSBUYXAg Zm9sbG93ZWQgYnkgYSBjbGFzc2lmaWVyLCB3ZSB0aGVuIG5lZWQgdG8gZGVmaW5lIHRoZSBjbGFz c2lmZXIgY2FscmVmdWxseSBhbmQgdGhlIHJ1bGUgZm9yIHRoZSBjbGFzc2lmaWVyIG1heSBub3Qg YmUgc2ltcGxlIGFsc28uICBJJ20gYWxzbyBub3Qgc3VyZSBpZiBhbGwgc3VjaCByZWRpcmVjdCBk aXN0cmlidXRpb24gY2FuIGJlIGRvbmUgYnkgY2xhc3NpZmllciBwdXJlbHksIGRvdWJ0aW5nIGlm IHRoZXJlIGFsd2F5cyBleGlzdCBlbm91Z2ggZGlmZmVyZW5jZXMgdG8gY2xhc3NpZnkuIA0KDQpU aGFuayB5b3UuDQpXZWltaW5nDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gQXQgMDI6MzUg UE0gNS8yMi8yMDA1LCBBdnJpIERvcmlhIHdyb3RlOg0KPiA+TmV3IHN1Ym1pc3Npb24gZnJvbSBB dnJpIERvcmlhIDxhdnJpQGFjbS5vcmc+Og0KPiA+DQo+ID42LjgNCj4gPg0KPiA+ICBFZGl0b3Jp YWwgTm90ZTogIFRoZXJlIGFyZSBhbHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1v ZGVsDQo+ID4gICAgICAgICAgICAgICAgICAgICB0aGF0IGFyZSByZWxhdGVkIHRvIHBhY2tldCBy ZWRpcmVjdCBvcGVyYXRpb25zDQo+ID4gICAgICAgICAgICAgICAgICAgICBzaG91bGQgYmUgZGVm aW5lZC4gIEFsdGhvdWdoIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUNCj4gPiAgICAgICAgICAgICAg ICAgICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRvIGRlZmluZSB0aGUgTEZCcyBhZmZlY3QN Cj4gPiAgICAgICAgICAgICAgICAgICAgIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNj cmliZWQgaGVyZS4gIEJlY2F1c2UNCj4gPiAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRseSBp dCBpcyBzdGlsbCBpbiBwcm9ncmVzcyBpbiBGRSBtb2RlbCBvbiBob3cNCj4gPiAgICAgICAgICAg ICAgICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3N0IHNvbWUgdGhvdWdo dHMgb24NCj4gPiAgICAgICAgICAgICAgICAgICAgIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4g IFRoZXkgd2lsbCBiZSByZW1vdmVkDQo+ID4gICAgICAgICAgICAgICAgICAgICBsYXRlciBhbG9u ZyB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGUgRkUgbW9kZWwgd29yay4NCj4gPiAgICAgICAgIFRo b3VnaHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBhbmQNCj4gPiAg ICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcmVjdC4NCj4g PiAgICAgICAgICAgICAgICAgICAgIEFuIExGQiBpbiBGRSBjYWxsZWQgJ1JlZGlyZWN0U2luaycg aXMgcmVzcG9uc2libGUgdG8NCj4gPiAgICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBw YWNrZXRzIHRoYXQgbmVlZCB0byBiZSByZWRpcmVjdGVkIHRvDQo+ID4gICAgICAgICAgICAgICAg ICAgICBDRS4gIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksDQo+ ID4gICAgICAgICAgICAgICAgICAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIGlzIGFuIExGQiB3 aXRoIG9ubHkgb25lIGlucHV0DQo+ID4gICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRo b3V0IGFueSBvdXRwdXQgcG9ydCwgYW5kIHRoZSBpbnB1dCBwb3J0DQo+ID4gICAgICAgICAgICAg ICAgICAgICBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8gYW55IG90aGVyIExGQiBpbiBGRSBtb2Rl bA0KPiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUg Zm9yd2FyZGluZyBwbGFuZS4NCj4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsDQo+ID4gICAgICAgICAgICAgICAg ICAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIHdpbGwgZ2VuZXJhdGUgdGhlIFBhY2tldA0KPiA+ ICAgICAgICAgICAgICAgICAgICAgUmVkaXJlY3QgTWVzc2FnZXMgd2hlbiBpdCByZWNlaXZlcyBk YXRhIHBhY2tldHMgZnJvbQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgZm9yd2FyZGluZyBwbGFu ZS4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVk aXJlY3RUYXAnIGlzIHJlc3BvbnNpYmxlIHRvDQo+ID4gICAgICAgICAgICAgICAgICAgICByZWNl aXZlIGRhdGEgcGFja2V0cyB0aGF0IGFyZSByZWRpcmVjdGVkIGZyb20gQ0UuDQo+ID4gICAgICAg ICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5 LCB0aGUNCj4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCIGlzIGFuIExG QiB3aXRoIG9ubHkgb25lIG91dHB1dA0KPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydCBhbmQg d2l0aG91dCBhbnkgaW5wdXQgcG9ydCwgYW5kIHRoZSBvdXRwdXQgcG9ydA0KPiA+ICAgICAgICAg ICAgICAgICAgICAgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUg bW9kZWwNCj4gPiAgICAgICAgICAgICAgICAgICAgIGJ5IG1lYW5zIG9mIGEgZGF0YXBhdGggaW4g dGhlIGZvcndhcmRpbmcgcGxhbmUuDQo+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBw ZXJzcGVjdGl2ZSBvZiBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsIHRoZQ0KPiA+ICAgICAgICAgICAg ICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIFBhY2tldCBSZWRpcmVj dA0KPiA+ICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZXMgZnJvbSBDRSwgYW5kIHVuLWVuY2Fw c3VsYXRlIHRoZSBkYXRhDQo+ID4gICAgICAgICAgICAgICAgICAgICBwYWNrZXRzIGZyb20gdGhl IG1lc3NhZ2UgYW5kIHB1dCB0aGVtIHRvIGRhdGFwYXRocw0KPiA+ICAgICAgICAgICAgICAgICAg ICAgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aGUgJ1JlY2lyZWN0VGFwJw0K PiA+ICAgICAgICAgICAgICAgICAgICAgTEZCIGFjdHMgbW9yZSBsaWtlIGEgdHJhbnNjb2RlciB0 aGF0IHRyYW5zZmVycyB0aGUNCj4gPiAgICAgICAgICAgICAgICAgICAgIEZvckNFUyBwcm90b2Nv bCBtZXNzYWdlcyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIGluDQo+ID4gICAgICAgICAgICAgICAg ICAgICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQXMgYSByZXN1bHQsIGlmIHdlIG5lZWQgdG8NCj4g PiAgICAgICAgICAgICAgICAgICAgIGhhdmUgcmVkaXJlY3RlZCBwYWNrZXRzIGNvbm5lY3RlZCB0 byBzb21lIExGQiAoc2F5IGENCj4gPiAgICAgICAgICAgICAgICAgICAgIFNjaGVkdWxlcikgaW4g RkUgbW9kZWwsIHdlIG9ubHkgbmVlZCB0byBjb25uZWN0IHRoZQ0KPiA+ICAgICAgICAgICAgICAg ICAgICAgJ1JlZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiBkaXJlY3RseSB2aWEg YQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgZGF0YXBhdGggYXMgZm9sbG93czoNCj4gPg0KPiA+ DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAg ICAgICstLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVk aXJlY3RUYXAgTEZCIHwtLS0tLS0+fCAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8DQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg U2NoZWR1bGVyIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGcm9tIG90 aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQo+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLSsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjcN Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgQnkgdXNlIG9mIHNldmVyYWwgJ1JlZGlyZWN0 U2luaycgTEZCcyBhbmQgc2V2ZXJhbA0KPiA+ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0 VGFwJyBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIGRpZmZlcmVudA0KPiA+ICAgICAgICAg ICAgICAgICAgICAgZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBh Y2tldA0KPiA+ICAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3QgcGF0aHMgYmV0d2VlbiBDRSBh bmQgRkUgY2FuIGJlIGNvbnN0cnVjdGVkLg0KPiA+DQo+ID4gICAgICAgICBUaG91Z2h0IDI6ICBU aGVyZSBtaWdodCBiZSBhbm90aGVyIHdheSBhIHBhY2tldCBjb3VsZCBiZQ0KPiA+ICAgICAgICAg ICAgICAgICAgICAgcmVkaXJlY3RlZDogZGlyZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgsIGUu Zy4sIGJ5DQo+ID4gICAgICAgICAgICAgICAgICAgICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAg SW4gc3VjaCBhIGNhc2Ugd2UgZG8gbm90DQo+ID4gICAgICAgICAgICAgICAgICAgICBuZWVkIHRv IHB1dCBpbiBhIGxvdCBvZiBzbWFydG5lc3MuICBQcm9iYWJseSBhIGxpbmsNCj4gPiAgICAgICAg ICAgICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbCBoZWFkZXIgaXMgZW5vdWdo LiAgVGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlciBkZW11eGVzIGl0IG9ubHkg YmFzZWQgb24gc29tZSBwcm90b2NvbCB0eXBlDQo+ID4gICAgICAgICAgICAgICAgICAgICBpbiB0 aGUgbGluayBsYXllciBvciBuZXR3b3JrIHRyYW5zcG9ydCBsYXllci4gIFRoZQ0KPiA+ICAgICAg ICAgICAgICAgICAgICAgcHJvcyBmb3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgcHJvdmlkZSBh IGZhc3QgYW5kDQo+ID4gICAgICAgICAgICAgICAgICAgICBjb3N0LWVmZmVjdGl2ZSBwYXRoIGZv ciBwYWNrZXQgcmVkaXJlY3QuICBUaGUgY29ucw0KPiA+ICAgICAgICAgICAgICAgICAgICAgZm9y IHRoaXMgaXMgaXQgbWF5IG1vcmUgb3IgbGVzcyBjb25mdXNlcyB0aGUgRnANCj4gPiAgICAgICAg ICAgICAgICAgICAgIHJlZmVyZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdv cmsuDQo+ID4NCj4gPi0tLS0tLS0tLS0NCj4gPmNhdGVnb3J5OiBFZGl0b3JpYWwNCj4gPmRyYWZ0 OiBkcmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbA0KPiA+bWVzc2FnZXM6IDQ5DQo+ID5ub3N5OiBh dnJpDQo+ID5wcmlvcml0eTogTXVzdCBmaXgNCj4gPnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KPiA+ dGl0bGU6IFBhY2tldCBSZWRpcmVjdA0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj4gPjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFj a2VyL2ZvcmNlcy9pc3N1ZTMyPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IA== From qinqinwang1@o2.pl Thu May 26 06:42:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18082 for ; Thu, 26 May 2005 06:42:25 -0400 (EDT) Received: from [195.39.80.229] (helo=mail.freeaccess.cz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbG7P-0005X5-8c for forces-archive@ietf.org; Thu, 26 May 2005 07:01:40 -0400 Received: by mail.freeaccess.cz (Postfix, from userid 99) id AFA545AE4D; Thu, 26 May 2005 12:40:22 +0200 (CEST) Received: from 62-177-189-40.dyn.bbeyond.nl (62-177-189-40.dyn.bbeyond.nl [62.177.189.40]) by webmail.freeaccess.cz (IMP) with HTTP for ; Thu, 26 May 2005 12:40:10 +0200 Message-ID: <1117104010.4295a78a1ca2a@webmail.freeaccess.cz> Date: Thu, 26 May 2005 12:40:10 +0200 From: Qin Reply-To: qinqinwang1@o2.pl Subject: From Qin Wang MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Sender: free|access webmail To: undisclosed-recipients:; Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: quoted-printable From Qin Wang Lloyds TSB Pacific Limited=20 Hong Kong Branch Fax: +852-301-66259 =20 Thank you for giving me your time. Please be patient and read my email = to you. I am a staff of Lloyds TSB Group attached in Private Banking Services. I = am contacting you=20 concerning a customer and, an investment placed under our banks managemen= t 3 years ago, I=20 contacted you independently of our investigation and no one is informed o= f this communication=20 and I Would like to intimate you with certain facts that I believe would = be of interest to you. In 2000, the subject matter; ref: bb/tsb/bank/73 came to our bank to enga= ge in business=20 discussions with our Private Banking Services Department. He informed us = that he had a=20 financial portfolio of 8.35 million United States Dollars, which he wishe= d to have us turn=20 over on his behalf. I was the officer assigned to his case; I made numero= us suggestions in=20 line with my duties as the de-facto chief operations officer of the Priva= te Banking Services=20 Department, especially given the volume of funds he wished to put into ou= r bank. We met on=20 numerous occasions prior to any investments being placed. I encouraged hi= m to consider various=20 growth funds with prime ratings. The favored route in my advice to custom= ers is to start by=20 assessing data on 600 traditional stocks and bond managers and alternativ= e investments. Based=20 on my advice, we spun the money around various opportunities and made att= ractive margins for=20 our first months of operation, the accrued profit and interest stood at t= his point at over 10=20 million United States Dollars, this margin was not the full potential of = the fund but he=20 desired low risk guaranteed returns on investments. In mid 2001, he asked= that the money be=20 liquidated because he needed to make an urgent investment requiring cash = payments in Europe.=20 He directed that I liquidate the funds and had it deposited with a firm i= n Europe. I informed=20 him that our bank would have to make special arrangements to have this do= ne and in order not=20 to circumvent due process, the bank would have to make a 9.5 % deduction = from the funds to=20 cater for banking and statutory charges. He complained about the charges = but later came around=20 when I explained to him the complexities of the task he was asking of us.= Cash movement across=20 borders has become especially strict since the incidents of 9/11.=20 I contacted my affiliate in Europe and had the funds available in main la= nd Europe. I=20 undertook all the processes and made sure I followed his precise instruct= ions to the letter=20 and had the funds deposited in a security consultancy firm, the firm is a= specialist private=20 firm that accepts deposits from high net worth individuals and blue chip = corporations that=20 handle valuable products or undertake transactions that need immediate ac= cess to cash. This=20 small and highly private organization is familiar especially to the highl= y placed and Well- connected organizations. In line with instructions, the money was deposit= ed. He told me he=20 wanted the money there in anticipation of his arrival from Norway later t= hat week. This was=20 the last communication we had, this transpired around 20th June 2002. In= June last year, we=20 got a call from the security firm informing us of the inactivity of that = particular portfolio.=20 This was an astounding position as far as I was concerned, given the fact= that I managed the=20 private banking sector I was the only one who knew about the deposit, and= I could not=20 understand why he had not come forward to claim his deposit. I made futile efforts to locate him I immediately passed the task of loc= ating him to the=20 internal investigations department of our bank. Four days later, informat= ion started to=20 trickle in, that he was apparently dead. A person who suited his descript= ion was declared dead=20 of a heart attack in Cannes, South of France. We were soon enough able to= identify the body=20 and cause of death was confirmed. The bank immediately launched an invest= igation into possible=20 surviving next of kin to alert about the situation and also to come forwa= rd to claim his=20 estate. If you are familiar with private banking affairs, those who patro= nize our services=20 usually prefer anonymity, but also some levels of detachment from convent= ional processes. In=20 his bio-data form, he listed no next of kin. In the field of private bank= ing, opening an=20 account with us means no one will know of its existence, accounts are rar= ely held under a name=20 depositors use numbers and codes to make the accounts anonymous. This ban= k also gives the=20 choice to depositors of having their mail sent to them or held at the ban= k itself, ensuring=20 that there are no traces of the account and as I said, rarely do they nom= inate next of kin.=20 Private banking clients apart from not nominating next of kin also usuall= y in most cases leave=20 wills in our care, in this case; he died in testate. What I wish to relate to you will smack of unethical practice but I want = you to understand=20 something. It is only an outsider to the banking world who finds the inte= rnal politics of the=20 banking world aberrational. The world of private banking especially is fr= aught with huge=20 rewards for those who occupy certain offices and oversee certain portfoli= os. You should have=20 begun by now to put together the general direction of what I propose. The= re is US$=20 8,370,000.00 deposited, I alone have the deposit details and they will re= lease the deposit to=20 no one unless I instruct them to do so. I alone know of the existence of = this deposit for as=20 far as the finance firm, the transaction with our deceased customer concl= uded when I sent the=20 funds to the firm, all outstanding interactions in relation to the file a= re just customer=20 services and due process. The finance firm has no single idea of what's t= he history or nature=20 of the deposit. They are simply awaiting instructions to release the depo= sit to any party that=20 comes forward. This is the situation. This bank has spent great amounts o= f money trying to=20 track this man's family; they have investigated for months and have found= no family. The=20 investigation has come to an end. My proposal , you share similar details to the late fellow I am prepar= ed to place you in a=20 position to instruct the finance firm to release the deposit to you as th= e closest surviving=20 relation. Upon receipt of the deposit, I am prepared to share the money w= ith you in half and=20 no more. That is: I will simply nominate you as the next of kin and have = them release the=20 deposit to you. We share the proceeds 50/50. I would have gone ahead to a= sk the funds be=20 released to me, but that would have drawn a straight line to me and my in= volvement in claiming=20 the deposit. But on the other hand, you with a similar name as the origin= al depositor would=20 easily pass as the beneficiary with the rights to claim. I assure you tha= t I could have the=20 deposit released to you in a few days. I will simply inform our bank of t= he final closing of=20 the file relating to the customer. I will then officially communicate wit= h the finance company=20 and instruct them to release the deposit to you. With these two things: a= ll is done. The alternative would be for us to have the firm direct the funds to anot= her bank with you as=20 accountholder. This way there will be no need for you to think of receivi= ng the money from the=20 firm. We can fine-tune this based on our interactions. I am aware of the = consequences of this=20 proposal. I ask that if you find no interest in this project that you sho= uld discard this=20 mail. I ask that you do not be vindictive or destructive. If my offer is = of no appeal to you,=20 delete this message and forget I ever contacted you. Do not destroy my ca= reer because you do=20 not approve of my proposal. You may not know this but people like myself = who have made tidy=20 sums out of comparable situations run the whole private banking sector. I= am not a criminal=20 and what I do, I do not find against good conscience, this may be hard fo= r you to understand,=20 but the dynamics of my industry dictates that I make this move. Such oppo= rtunities only come=20 ones' way once in a lifetime. I cannot let this chance pass me by I hope you understand because for once I found myself in total control an= d face to face with=20 my destiny. These chances won't pass me by. I ask that you do not destroy= my chance, if you=20 will not work with me let me know and let me move on with my life but do = not destroy me. I am=20 a family man and this is an opportunity to provide them with new opportun= ities. There is a=20 reward for this project and it is a task well worth undertaking. I have e= valuated the risks=20 and the only risk I have here is from you refusing to work with me and al= erting my bank. I am=20 the only one who knows of this situation, good fortune has blessed you wi= th a name that has=20 planted you into the center of relevance in my life. Let's share the bles= sing. If you give me positive signals, I will initiate this process towards a c= onclusion. I wish to=20 inform you that should you contact me via official channels; I will deny = knowing you and about=20 this project. I repeat, I do not want you contacting me through my offici= al phone lines nor do=20 I want you contacting me through my official email account. Contact me on= ly through this email=20 address (qin_wang1@o2.pl) I do not want any direct link between you and me. My official lines are n= ot secure lines as=20 they are periodically monitored to assess our level of customer care in l= ine with our Total=20 Quality Management Policy. Please observe this instruction religiously. Please, again, note I am a f= amily man; I happily=20 married with two kids. I send you this mail not without a measure of fear= as to what the=20 consequences might be, but I know within me that nothing ventured is noth= ing gained and that=20 success and riches never come easy or on a platter of gold. This is the o= ne truth I have=20 learned from my private banking clients. Do not betray my confidence. If = we can be of one=20 accord, we should plan a meeting, soon. I await your response. Sincerely, Qin Wang -------------------------------------------------------------------------= ------------- free|access - pripojeni k internetu zdarma na kterem vydelas Pripoj se k internetu zdarma pres free|access a ziskej vyhody, ktere jind= e nedostanes! www.freeaccess.cz From owner-forces@PEACH.EASE.LSOFT.COM Tue May 31 04:55:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18771 for ; Tue, 31 May 2005 04:55:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd2qz-0005Tl-Fb for forces-archive@IETF.ORG; Tue, 31 May 2005 05:16:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0106953E@cherry.ease.lsoft.com>; Tue, 31 May 2005 4:55:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73446355 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 31 May 2005 04:55:45 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 31 May 2005 04:55:45 -0400 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 j4V8tIHC001714 for ; Tue, 31 May 2005 10:55:18 +0200 Mime-Version: 1.0 (Apple Message framework v622) References: <1116786393.88.0.285808544152.issue29@mip4.org> <6.2.1.2.0.20050523020846.02e1df80@localhost> <00a601c55c82$c54b08a0$020aa8c0@wwm1> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.622) Approved-By: avri@PSG.COM Message-ID: Date: Tue, 31 May 2005 10:55:22 +0200 Reply-To: avri@psg.com Sender: Forwarding and Control Element Separation From: avri@psg.com Subject: Re: [issue29] Path attribute ID To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00a601c55c82$c54b08a0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi, You are right. I accidentally used a 'pre-released' version of -02 i had in my directory. I will close this one. I have also gone through a diff of the file i used and the latest -02 and while I didn't find any other issues that were already closed, i did find a few other issues that need to be added, which I will do shortly. Thanks for the catch. a. ps. this is the hardest list to send to. i always need several tries before i get it from the right address and then remember to verify that i really wanted to send. also, i am still working my way through the doc removing all the notes. I intended to get a new version submitted last week, but am still working on it. On 19 maj 2005, at 16.46, Weiming Wang wrote: > Avri, > > I'm not sure if you'v used the latest 02 version of the draft for the > issue trackers. I think this edtorial note has already been removed > and not existed in the 02 version. The issue has already been solved. > > Yours, > Weiming >