From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 1 12:42:13 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11667 for ; Sun, 1 Dec 2002 12:42:12 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00808F31@cherry.ease.lsoft.com>; 1 Dec 2002 12:44:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32729343 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 1 Dec 2002 12:44:59 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 1 Dec 2002 12:44:59 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gB1HeH523317 for ; Sun, 1 Dec 2002 17:40:17 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gB1HecX02605 for ; Sun, 1 Dec 2002 17:40:38 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120109431711731 for ; Sun, 01 Dec 2002 09:43:17 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Dec 2002 09:44:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Putzolu, David" Message-ID: Date: Sun, 1 Dec 2002 09:44:56 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: clarifications needed on FACT To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11667 Bounced email due to unrecognized source address. Forwarded to list by maintainer. -----Original Message----- From: Aaudu2000@aol.com [mailto:Aaudu2000@aol.com] Sent: Friday, November 22, 2002 10:47 AM To: rha@zurich.ibm.com Cc: FORCES@PEACH.EASE.LSOFT.COM; chaopingwu@attbi.com; lrgpal@yahoo.com Subject: Re: clarifications needed on FACT ------------------ Hi Robert, A CE-SET seems to me to be a way to represent a logical network element (NE), which is a group of CEs and FEs cooperating together to provide the functionalities of a router. And FE belongs to a CE-SET after it has succefully joined that set. In short, this number is used to track the CE/FE grouping and all interractions between CEs and FEs in a group. As such, an FE-SET doesn't seem to carry much importance. On the message type question, I don't think there was a conscious effort to link message type and message flow direction. Such linking would be co-incidental. The draft is still evolving, and updates to address SETUP message inclusion will be made in the next update. FE-CE associations are made to provide the required level of redudancy, as set by configuration. So, it could be one-to-one or one-to-many, or many-to-many. Regards, Al. > >-------- Original Message -------- >Subject: clarifications needed on FACT >Date: Tue, 19 Nov 2002 20:10:34 +0100 >From: Robert Haas >Reply-To: Forwarding and Control Element Separation > >Organization: IBM Research Lab >To: FORCES@PEACH.EASE.LSOFT.COM > >Hi, >In my attempt to understand the FACT proposal, I would appreciate a few >clarifications from the authors: > >1) how are CE-sets meant to be used, and why is there no FE-set >equivalent ? >2) why rely on the message type to infer in which direction the message >is going (FE-to-CE or CE-to-FE) ? >3) why is the association SETUP message not described in the draft ? >4) are FE-CE associations (or logical connections) always made of one >FE and one CE only ? > >With many thanks, > >-- >Robert Haas >IBM Zurich Research Laboratory >Säumerstrasse 4 >CH-8803 Rüschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 >http://www.zurich.ibm.com/~rha > From owner-forces@PEACH.EASE.LSOFT.COM Sat Dec 7 22:42:28 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13921 for ; Sat, 7 Dec 2002 22:42:27 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008203CE@cherry.ease.lsoft.com>; Sat, 7 Dec 2002 22:45:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33225527 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 7 Dec 2002 22:45:18 -0500 Received: from 143.182.124.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 7 Dec 2002 22:45:17 -0500 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gB83kJl12013 for ; Sun, 8 Dec 2002 03:46:20 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002120719432411160 for ; Sat, 07 Dec 2002 19:43:24 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Dec 2002 19:45:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Sat, 7 Dec 2002 19:45:13 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Draft ForCES Meeting Minutes, IETF 55 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, Please find below the draft minutes for the ForCES meeting at IETF 55. Please send any corrections or comments to the list or to myself or Patrick by Thursday, Dec 12. Cheers, David --- cut here --- Forwarding and Control Element Separation (forces) Monday, November 18 at 0900-1130 ================================== CHAIRS: Patrick Droz David Putzolu Scribe: George Jones Agenda bashing: nothing changed Completed Last Calls draft-ietf-forces-framework-03.txt draft-ietf-forces-requirements-07.txt draft-ietf-forces-netlink-03.txt Discussion of draft-ietf-yang-model-01 - authors, history presented - motivation FE == Forwarding Element CE == Control Element * FE tells CE capabilities * FE tells CE current config * CE tells FE desired state - what is in the model * FE block (abstract base class) * Block library (Forwarding, QoS, filters, etc.) * Example FE Blocks * FE stage and directed graph * Two approaches in graph modeling * Topological (DiffServ) + No info carried forward * Topological (DiffServ) vs. Encoded State (QDDIM model) + Explicit info (preamble) carried forward to subsequent stages - open issues * Data modeling language: representation + SMI/SPPI/ASN.1/XML/UML ? * Topological vs. Encoded State approach * Modeling of actual functions + identify minimal categories/set of functions + model for each one - next steps * WG document * Data modeling language * define small set of functions Q: Is your intent to specify the way that the FE and CE communicate ? If so, it's very important to get right. A: yes. Q: (statement) Topological model is easier to reason about. A: We can take it on a case-by case basis. Q: (statement) We need to be aware that we don't just want to encode the a snapshot of the current state of the world A: We need help from the chairs to avoid this. Chair: show of hands, who's read ? Answer: not enough. Need more discussion to accept as a WG model. Abstract, not easy to discuss. Chair: We'd like people to start submitting actual protocol drafts. Easier to actually talk about/discuss. Action: model will not be WG document yet. Status of other drafts Closing: Do protocol submissions. End of meeting. From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 11 17:10:40 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23170 for ; Wed, 11 Dec 2002 17:10:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0082E032@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 17:13:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33535283 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 11 Dec 2002 17:13:32 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 17:13:32 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 6B0B71F0066; Wed, 11 Dec 2002 17:13:32 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id 2A55C1F005C; Wed, 11 Dec 2002 17:13:22 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3DF7B881.5001925E@idt.com> Date: Wed, 11 Dec 2002 17:13:21 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Comments on draft-yang-forces-model-01.txt Comments: cc: lily.l.yang@intel.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I was unable to attend IETF Atlanta, so I thought I'd post my comments on the list (and it's been pretty quiet lately). Page 6: "... CE's might even be allowed to download a given functionality onto FE's at run time. ... this is still considered a research area, and is not being considered here". That depends on what the "given functionality" is. One example is IDS, or firewall applications. There is a requirement to download new "rules" for classification, but it's not clear where the "rule" becomes "functionality". e.g. New firewall rules don't appear to add new "functionality", as they're usually for existing, and well-known protocols. But it's not a large step forward to download new protocols to a firewall for filtering/metering. The firewall doesn't have to *pass* the traffic, but it would be useful to allow it to *account* such traffic. I may be nitpicking here. My main concern is that the programming of programmable devices shouldn't be described as "downloading new functionality", and rejected out of hand. There are network applications in the market today which permit some amount of downloading. It would be useful to address this (or the limits thereof) in the model document. Page 6, Section 4. "FE Model" Very nice. I have no comments here, other than to say it's clear, descriptive, and well written. Page 11, Section 4.2.5 "Forwarding functions" The other sections appear to describe inputs/outputs/modifications of the FE blocks (as described in 4.2). Similar text appears to be missing here. I have more comments on IPv4 forwarding, and it's unification of classification/packet-modification, but they should probably be addressed to a document describing the IPv4 FE block in more detail. Page 13, Section 4.3.2 "Topological versus Encoded State Approaches" The discussion of the two different approaches is good, but I believe that some combination of the two will be a requirement. e.g. Some chips have 1 physical input, with 2 physical outputs, each of which can have metadata (encoded state) information attached. If we choose one approach over the other, then there are some systems which can't be mapped to the model. The documents implicit approach of "smaller pictures are better" is a reasonable one. Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 11 18:48:02 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25809 for ; Wed, 11 Dec 2002 18:48:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0082E3CD@cherry.ease.lsoft.com>; Wed, 11 Dec 2002 18:50:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33544411 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 11 Dec 2002 18:50:54 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 11 Dec 2002 18:50:53 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gBBNk1119922 for ; Wed, 11 Dec 2002 23:46:01 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gBBNkPH07098 for ; Wed, 11 Dec 2002 23:46:25 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002121115490530526 ; Wed, 11 Dec 2002 15:49:05 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Dec 2002 15:50:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Yang, Lily L" Message-ID: Date: Wed, 11 Dec 2002 15:50:49 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on draft-yang-forces-model-01.txt Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Alan -- Thanks. See my reply in line. Lily > -----Original Message----- > From: Alan DeKok [mailto:alan.dekok@idt.com] > Sent: Wednesday, December 11, 2002 2:13 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Cc: lily.l.yang@intel.com > Subject: Comments on draft-yang-forces-model-01.txt > > > I was unable to attend IETF Atlanta, so I thought I'd post > my comments > on the list (and it's been pretty quiet lately). > > > Page 6: "... CE's might even be allowed to download a given > functionality onto FE's at run time. ... this is still considered a > research area, and is not being considered here". > > That depends on what the "given functionality" is. One example is > IDS, or firewall applications. There is a requirement to download new > "rules" for classification, but it's not clear where the > "rule" becomes > "functionality". > > e.g. New firewall rules don't appear to add new "functionality", as > they're usually for existing, and well-known protocols. But > it's not a > large step forward to download new protocols to a firewall for > filtering/metering. The firewall doesn't have to *pass* the traffic, > but it would be useful to allow it to *account* such traffic. > > I may be nitpicking here. My main concern is that the > programming of > programmable devices shouldn't be described as "downloading new > functionality", and rejected out of hand. There are network > applications in the market today which permit some amount of > downloading. It would be useful to address this (or the > limits thereof) > in the model document. By "downloading new functionality" I meant (or more precisely, imagined) things like CE telling an FE to add a firewall block in the FE graph even though the FE has no firewall block pre-installed -- so the CE has to download the firewall code onto the FE on the fly. So downloading new filtering rules definetely does not count toward this while downloading new protocols to a frewall probably does. I consider the two quite distinctively diffrent and by the IETF spirit of "walk before you run", I personally thought it appropriate to draw a line here. But of course, this is up to the list for debate. > > > Page 6, Section 4. "FE Model" > > Very nice. I have no comments here, other than to say it's clear, > descriptive, and well written. Thanks. It is nice to know someone actually read the draft. Even nicer to hear this kind of comments :-) > > > Page 11, Section 4.2.5 "Forwarding functions" > > The other sections appear to describe > inputs/outputs/modifications of > the FE blocks (as described in 4.2). Similar text appears to > be missing > here. > > I have more comments on IPv4 forwarding, and it's unification of > classification/packet-modification, but they should probably be > addressed to a document describing the IPv4 FE block in more detail. While this draft does not intend to provide detailed specification for each function, but it should provide enough informational modeling guideline. So if you can contribute more comments/content for IP forwarding, for example, we will be VERY grateful! > > > Page 13, Section 4.3.2 "Topological versus Encoded State Approaches" > > The discussion of the two different approaches is good, but > I believe > that some combination of the two will be a requirement. > > e.g. Some chips have 1 physical input, with 2 physical outputs, each > of which can have metadata (encoded state) information attached. > > If we choose one approach over the other, then there are > some systems > which can't be mapped to the model. The documents implicit > approach of > "smaller pictures are better" is a reasonable one. This particular section needs more work that is for sure. Personally I am not very satisfied with it either. We will keep your comments in mind when we revise this part. > > > Alan DeKok. > From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 17 07:09:33 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12228 for ; Tue, 17 Dec 2002 07:09:32 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0083BAEC@cherry.ease.lsoft.com>; Tue, 17 Dec 2002 7:12:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33901219 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 17 Dec 2002 07:12:30 -0500 Received: from 194.196.100.234 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 17 Dec 2002 07:12:30 -0500 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gBHCCRV0212308 for ; Tue, 17 Dec 2002 13:12:27 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gBHCCQOa081104 for ; Tue, 17 Dec 2002 13:12:27 +0100 Received: from dhcp70-37.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32182 from ; Tue, 17 Dec 2002 13:12:26 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Mime-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Patrick Droz Message-ID: <3DFF14AA.5040003@zurich.ibm.com> Date: Tue, 17 Dec 2002 13:12:26 +0100 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Re: Draft ForCES Meeting Minutes, IETF 55 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit David, sorry I was on vacation and did not have e-mail access. Thanks for doing this. Regards, Patrick Putzolu, David wrote: > All, > > Please find below the draft minutes for the ForCES > meeting at IETF 55. Please send any corrections or > comments to the list or to myself or Patrick by > Thursday, Dec 12. > > Cheers, > David > > --- cut here --- > > Forwarding and Control Element Separation (forces) > > Monday, November 18 at 0900-1130 > ================================== > > CHAIRS: Patrick Droz > David Putzolu > > Scribe: George Jones > > Agenda bashing: nothing changed > > Completed Last Calls > > draft-ietf-forces-framework-03.txt > draft-ietf-forces-requirements-07.txt > draft-ietf-forces-netlink-03.txt > > Discussion of draft-ietf-yang-model-01 > > - authors, history presented > - motivation > FE == Forwarding Element > CE == Control Element > * FE tells CE capabilities > * FE tells CE current config > * CE tells FE desired state > - what is in the model > * FE block (abstract base class) > * Block library (Forwarding, QoS, filters, etc.) > * Example FE Blocks > * FE stage and directed graph > * Two approaches in graph modeling > * Topological (DiffServ) > + No info carried forward > * Topological (DiffServ) vs. Encoded State (QDDIM model) > + Explicit info (preamble) carried forward to subsequent > stages > - open issues > * Data modeling language: representation > + SMI/SPPI/ASN.1/XML/UML ? > * Topological vs. Encoded State approach > * Modeling of actual functions > + identify minimal categories/set of functions > + model for each one > - next steps > * WG document > * Data modeling language > * define small set of functions > > > Q: Is your intent to specify the way that the FE and CE > communicate ? If so, it's very important to get right. > A: yes. > > Q: (statement) Topological model is easier to reason about. > A: We can take it on a case-by case basis. > > Q: (statement) We need to be aware that we don't just want to > encode the a snapshot of the current state of the world > A: We need help from the chairs to avoid this. > > Chair: show of hands, who's read ? > Answer: not enough. Need more discussion to accept as a WG model. > Abstract, not easy to discuss. > > Chair: We'd like people to start submitting actual protocol drafts. > Easier to actually talk about/discuss. > > Action: model will not be WG document yet. > > Status of other drafts > > Closing: > Do protocol submissions. > > End of meeting. > > -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 18 08:12:23 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05097 for ; Wed, 18 Dec 2002 08:12:22 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0084257B@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 8:15:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34001176 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 18 Dec 2002 08:15:20 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 18 Dec 2002 08:05:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04134; Wed, 18 Dec 2002 08:02:18 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200212181302.IAA04134@ietf.org> Date: Wed, 18 Dec 2002 08:02:18 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-applicability-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Applicability Statement Author(s) : A. Crouch, M. Handley Filename : draft-ietf-forces-applicability-01.txt Pages : 9 Date : 2002-12-16 The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Engines in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-applicability-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-applicability-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-applicability-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-16123318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-applicability-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-applicability-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123318.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 18 08:12:29 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05111 for ; Wed, 18 Dec 2002 08:12:28 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008424AF@cherry.ease.lsoft.com>; Wed, 18 Dec 2002 8:15:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34001177 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 18 Dec 2002 08:15:25 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 18 Dec 2002 08:05:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04153; Wed, 18 Dec 2002 08:02:24 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200212181302.IAA04153@ietf.org> Date: Wed, 18 Dec 2002 08:02:23 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-forces-netlink-04.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Netlink as an IP Services Protocol Author(s) : J. Salim et al. Filename : draft-ietf-forces-netlink-04.txt Pages : 32 Date : 2002-12-16 This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. This document is intended as informational in the context of prior art for the ForCES IETF working group. The focus of this document is to describe Netlink from a perspective of a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. The document ignores the ability of Netlink as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-netlink-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-forces-netlink-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-forces-netlink-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-16123329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-forces-netlink-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-forces-netlink-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123329.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Dec 19 16:47:00 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27818 for ; Thu, 19 Dec 2002 16:46:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00845EAB@cherry.ease.lsoft.com>; Thu, 19 Dec 2002 16:49:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34127226 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 19 Dec 2002 16:49:49 -0500 Received: from 207.35.224.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 19 Dec 2002 16:49:49 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.ott.idt.com (Postfix) with SMTP id 288641F007D; Thu, 19 Dec 2002 16:49:49 -0500 (EST) Received: from idt.com (akula.ott.idt.com [192.168.102.200]) by post.ott.idt.com (Postfix) with ESMTP id A95BA1F0075; Thu, 19 Dec 2002 16:49:43 -0500 (EST) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-2mdk i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: alan.dekok@IDT.COM Message-ID: <3E023EF7.96D3C6E5@idt.com> Date: Thu, 19 Dec 2002 16:49:43 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Alan DeKok Organization: IDT Canada, Inc. Subject: Re: Comments on draft-yang-forces-model-01.txt Comments: To: "Yang, Lily L" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Yang, Lily L" wrote: > > By "downloading new functionality" I meant (or more precisely, imagined) > things like CE telling an FE to add a firewall block in the FE graph even > though the FE has no firewall block pre-installed -- so the CE has to > download the firewall code onto the FE on the fly. So downloading new > filtering rules definetely does not count toward this while downloading new > protocols to a frewall probably does. My concern is that most people use the terms "protocol" and "packet description" interchangably. They're *very* different. Packet descriptions are static, involving defining a layout of bits on the wire. Protocols use packet descriptions to drive state changes in a system. These state changes are driven by received packets, and cause other packets to be emitted in turn. e.g. Downloading packet descriptions for new protocols to a firewall. The firewall can filter and count these packets, even if it doesn't do anything else with the packets. e.g. Firewalls which strictly filter TCP packets with unknown flags. When a new variant of TCP is released, you would like to treat these packets as "known, but unsupported", until you upgrade your firewall. These packets then fall into a different logical class than "nmap packets with weird flags". The reason I'm concerned about this issue is two-fold. One, clear and consistent terminology helps communication. Two, there are systems today (IDS, firewall, virus detectors), which allow new packet descriptions to be downloaded on the fly. Forces should allow these systems to be configured and controlled, and should not treat these capabilities as "new functionality". Alan DeKok. From owner-forces@PEACH.EASE.LSOFT.COM Thu Dec 19 21:42:00 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04793 for ; Thu, 19 Dec 2002 21:42:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00846947@cherry.ease.lsoft.com>; Thu, 19 Dec 2002 21:45:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34145987 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 19 Dec 2002 21:44:59 -0500 Received: from 208.2.156.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 19 Dec 2002 21:44:59 -0500 Received: from localhost (hadi@localhost) by znyx.com (8.9.3/8.9.3) with ESMTP id SAA22672; Thu, 19 Dec 2002 18:57:02 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Jamal Hadi Message-ID: Date: Thu, 19 Dec 2002 18:57:02 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: Jamal Hadi Subject: Announce: netlink2 draft Comments: cc: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list This should probably have shown up here sooner given we were going to present in Atlanta. Submitted to drafts editor - find a copy at: http://openarchitect.znyx.com/jamal/draft-jhsrha-forces-netlink2-00.txt Please send your comments to Robert and myself and if possible cc the list. Enjoy. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 23 08:05:12 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28796 for ; Mon, 23 Dec 2002 08:05:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0084DB34@cherry.ease.lsoft.com>; Mon, 23 Dec 2002 8:08:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34327231 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 Dec 2002 08:08:12 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 23 Dec 2002 07:58:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27545; Mon, 23 Dec 2002 07:55:05 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Approved-By: nsyracus@CNRI.RESTON.VA.US Message-ID: <200212231255.HAA27545@ietf.org> Date: Mon, 23 Dec 2002 07:55:04 -0500 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jhsrha-forces-netlink2-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Netlink2 as ForCES protocol Author(s) : J. Salim, R. Haas Filename : draft-jhsrha-forces-netlink2-00.txt Pages : 28 Date : 2002-12-20 This document describes Netlink2, which is an extension of Linux Netlink [Netlink]. This document is intended as a proposal for the ForCES IETF working group protocol. ForCES attempts to define a clear separation between the two enti- ties of the NE in order to have them evolve separetely as opposed to the current monolithic evolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jhsrha-forces-netlink2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jhsrha-forces-netlink2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jhsrha-forces-netlink2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20125948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jhsrha-forces-netlink2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jhsrha-forces-netlink2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20125948.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 23 19:51:04 2002 Received: from cherry.ease.lsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18406 for ; Mon, 23 Dec 2002 19:51:04 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0084F6A6@cherry.ease.lsoft.com>; Mon, 23 Dec 2002 19:54:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34350583 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 23 Dec 2002 19:54:06 -0500 Received: from 192.55.52.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 23 Dec 2002 19:54:06 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gBO0pm108542 for ; Tue, 24 Dec 2002 00:51:48 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gBO0nTt09450 for ; Tue, 24 Dec 2002 00:49:29 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002122316551902623 ; Mon, 23 Dec 2002 16:55:19 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Dec 2002 16:54:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Approved-By: "Yang, Lily L" Message-ID: Date: Mon, 23 Dec 2002 16:54:04 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Comments on draft-yang-forces-model-01.txt Comments: To: Alan DeKok To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Alan -- Thanks for the detailed description. I understand your concern and agree with your conclusion that "Forces should allow these systems to be configured and controlled, and should not treat these capabilities as new functionality". So it doesn't appear to me that we have any fundamental disagreement on the issue. It might just be terminology that causes he confusion. I will check the draft to make sure it is clear of such confusion. If you see any specific text/wording that is causing your concern, please be so kind to point out to me. Thanks, and Happy Holiday to you and everyone on the list who is still working or listening :-) Lily > -----Original Message----- > From: Alan DeKok [mailto:alan.dekok@idt.com] > Sent: Thursday, December 19, 2002 1:50 PM > To: Forwarding and Control Element Separation; Yang, Lily L > Subject: Re: Comments on draft-yang-forces-model-01.txt > > > "Yang, Lily L" wrote: > > > > By "downloading new functionality" I meant (or more > precisely, imagined) > > things like CE telling an FE to add a firewall block in the > FE graph even > > though the FE has no firewall block pre-installed -- so the > CE has to > > download the firewall code onto the FE on the fly. So > downloading new > > filtering rules definetely does not count toward this while > downloading new > > protocols to a frewall probably does. > > My concern is that most people use the terms "protocol" and "packet > description" interchangably. They're *very* different. Packet > descriptions are static, involving defining a layout of bits on the > wire. Protocols use packet descriptions to drive state changes in a > system. These state changes are driven by received packets, > and cause > other packets to be emitted in turn. > > e.g. Downloading packet descriptions for new protocols to a > firewall. > The firewall can filter and count these packets, even if it doesn't do > anything else with the packets. > > e.g. Firewalls which strictly filter TCP packets with > unknown flags. > When a new variant of TCP is released, you would like to treat these > packets as "known, but unsupported", until you upgrade your firewall. > These packets then fall into a different logical class than "nmap > packets with weird flags". > > > The reason I'm concerned about this issue is two-fold. > One, clear and > consistent terminology helps communication. Two, there are systems > today (IDS, firewall, virus detectors), which allow new packet > descriptions to be downloaded on the fly. Forces should allow these > systems to be configured and controlled, and should not treat these > capabilities as "new functionality". > > Alan DeKok. >