From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 2 11:58:08 2003 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 LAA18104 for ; Wed, 2 Apr 2003 11:58:08 -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 <15.0095DB31@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 12:00:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39154538 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Apr 2003 12:00:34 -0500 Received: from 192.55.52.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 12:00:34 -0500 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h32Grej05153 for ; Wed, 2 Apr 2003 16:53:41 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h32H1fx22651 for ; Wed, 2 Apr 2003 17:01:41 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040209003606963 ; Wed, 02 Apr 2003 09:00:37 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 09:00:23 -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: Wed, 2 Apr 2003 09:00:18 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Proceedings, ForCES meeting @ IETF 56 Comments: To: "proceedings@ietf.org" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list The following URLs are the proceedings of the ForCES meeting held at IETF 56 on Tuesday, March 18, 2003. Agenda http://www.sstanamera.com/~forces/Ietf56/Agenda.ppt Forwarding and Control Element Protocol (FACT) Presentation http://www.sstanamera.com/~forces/Ietf56/FACT-IETF56-Ver00b.ppt Netlink2 as ForCES protocol Presentation http://www.sstanamera.com/~forces/Ietf56/netlink2.pdf ForCES Forwarding Element Functional Model Presentation http://www.sstanamera.com/~forces/Ietf56/IETF56-ForCES-model-ver02b.ppt Telecom Inter Process Communication (TIPC) Presentation http://www.sstanamera.com/~forces/Ietf56/TIPC-FACT-2003-03-18.ppt Cheers, David Putzolu co-chair, ForCES From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 2 14:50:05 2003 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 OAA25444 for ; Wed, 2 Apr 2003 14:50:03 -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 <11.0095DFE8@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 14:52:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39172096 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Apr 2003 14:52:27 -0500 Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 14:52:27 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h32JltK00211 for ; Wed, 2 Apr 2003 19:47:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h32JR1e05108 for ; Wed, 2 Apr 2003 19:27:01 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040212005616153 ; Wed, 02 Apr 2003 12:00:56 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <2FF7V1JN>; Wed, 2 Apr 2003 11:52:26 -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: Wed, 2 Apr 2003 11:52:24 -0800 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: AD/Routing Directorate Feedback, ForCES Framework Draft Comments: To: "Yang, Lily L" , "ram.dantu@utdallas.edu" , "Anderson, Todd A" Comments: cc: "Patrick Droz (dro@zurich.ibm.com)" , Alex Zinin To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list All, The ADs and the routing directorate have reviewed the ForCES framework. They had the following feedback on the draft. Once the authors and the working group address the issues listed below a new rev will need to be uploaded, after which it can be re-submitted to the IESG for review and publication as an RFC. I will be adding these to the issues list on the ForCES supplemental web page at http://www.sstanamera.com/~forces and these issues will be tracked via that page & the WG so that we can resolve them promptly. 1) FE Virtualization A single physical FE might be partitioned into multiple virtual FEs. I think the requirements talks abut this but the framework doesn't explicitly call out how this is handled. I believe the approach being taken is one where each FE (where FE is defined as the slave endpoint of an Fp connection) is a single logical entity, and partitioning of a physical FE into multiple such entities is beyond the scope of Fp and is instead a pre-association phase issue. The framework should explicitly call this out and may also want to include a reference to the new informational RFC that just issued on requirements for accomplishing this from the GSMP wg. RFC-Editor has not yet gotten around to it, so here is the URL for the draft: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt 2) Multiple FEMgrs The framework seems to say that there is one FE manager. It is possible that in some architectures each FE may have associated with it a FEMgr, thus necessitating selection of a single FEMgr among many. The rtg-dir questioned where such an interaction fits in the framework. Initial impression was that this would be a Fi interaction (if the FEMgrs are collocated with the FEs). Is this the right place, and if so, it should be documented. 3) DoS attacks 4.2.4 should explicitly call out that Fp could be a vector used by adversaries for DoS attacks on the NE. As such, it should explicitly be said that the combination of packet filterings on FEs, plus prioritization of specific packets being sent across Fp, helps to combat such attacks. Also - probably add a SHOULD that FEs should support the ability to do rate limiting of packets to CE. This is necessary to prevent flooding of the CE w/packets from FE. 4) OSPF Offload The ADs and the rtg-dir where both concerned that features such as OSPF offload, while useful, are probably so new that standardizing support for them is not practical in the first rev of forces. They suggested that support for that be removed from sections 5, 5.2, and 5.6. 5) Non-stop forwarding/Graceful restart Section 4.3 talks a bit about features needed for graceful restart, and requirements section 5 item 7 discusses this topic. The framework should explicitly spell out the need to support this and name it appropriately ("graceful restart") in its own section. In that section the framework should indicate the specific capabilities that FEs are expected to provide to enable graceful restart, i.e. "In order to enable graceful restart, FEs MAY choose to cash forwarding and QoS state across CE restarts. If they do so, they MUST include timers that eventually cause such cached state to expire. Those timers SHOULD be settable by CEs." (Note: this is just an example, need to be more specific about this. Include justifications & refs to appropriate RFCs, WGs, and drafts). 6) Terminology issue: route vs. forward Section 4.2.3 shows a "route to this port instead" message going from CE to FE. Would be more accurate to indicate that the CE is downloading a new FIB to the FE here. 7) Vagueness of CE action in response to FE loss/reestablishment Section 4.3 says a CE would "note" the event of FE loss or reestablishment. Would be more informative to say that the CE would inform routing protocols of such an event, most likely prompting a reachability and SPF recalculation and associated downloading of new FIB and other calculations. 8) Security handshakes as part of association establishment and re-establishment Sections 4.2.2 and 4.2.4 should explicitly call out the fact that FEs and CEs will perform a security handshake as part of the association establishment/re-establishment interaction. Need to make sure that the association is the intended one. Authentication mechanism (IPSec? TLS? other?) to be used to accomplish this should be identified. 9) Cached state in re-establishment The end of section 4.3 mentions the possibility that a FE may reuse cached state to save Fp interactions during a connection re-establishment. While it is ok for the framework to call out such a possibility, it should also make it clear that whether such a feature is actually part of Fp will depend on protocol selection/definition. Also, a checksum is a poor choice as it is rather unreliable. FIBs are very important and as such a more reliable mechanism (e.g. CRC-32) should be used. 10) Security Considerations This is where the IESG expects the security analysis of the framework and outlining the actual security mechanisms that should be present in the architecture. The document should provide vulnerability analysis of the framework, and how identified vulnerabilities should be covered. 11) Editorial changes Security considerations belongs before references. There are 8 bit characters in the draft that need to be excised. Cheers, David Putzolu (co-chair, ForCES) From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 10 15:00:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01065 for ; Thu, 10 Apr 2003 15:00:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193h1e-0003al-00 for forces-archive@IETF.ORG; Thu, 10 Apr 2003 14:43:54 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 193h1e-0003ac-00 for forces-archive@IETF.ORG; Thu, 10 Apr 2003 14:43:54 -0400 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.009705EC@cherry.ease.lsoft.com>; Thu, 10 Apr 2003 15:03:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39810446 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Apr 2003 15:03:04 -0400 Received: from 143.183.121.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Apr 2003 15:03:04 -0500 Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by caduceus.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h3AJ1wG10311 for ; Thu, 10 Apr 2003 19:01:58 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h3AHqVZ03746 for ; Thu, 10 Apr 2003 17:52:31 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041011004403681 for ; Thu, 10 Apr 2003 11:00:44 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Apr 2003 10:57:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Approved-By: "Putzolu, David" Message-ID: Date: Thu, 10 Apr 2003 10:57:11 -0700 Reply-To: Forwarding and Control Element Separation Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: Document Action: Netlink as an IP Services Protocol to Inform ational To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list Forwarded - will add IESG secretary to list of authorized non-subscriber senders. > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, April 09, 2003 8:18 AM > Cc: RFC Editor; Internet Architecture Board; > forces@PEACH.EASE.LSOFT.COM > Subject: Document Action: Netlink as an IP Services Protocol > to Informational > > The IESG has approved the Internet-Draft 'Netlink as an IP Services > Protocol' as an Informational RFC. > This document is the product of the Forwarding and Control Element > Separation Working Group. The IESG contact persons are Bill Fenner > and Alex Zinin. > > Rfc-ed note: > ------------- > > Change Title > OLD: > Netlink as an IP Services Protocol > NEW: > Linux Netlink as an IP Services Protocol > > Change Abstract > OLD: > 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.). > NEW: > 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. The focus of this document is to describe Netlink's > functionality as a protocol between a Forwarding Engine Component > and a Control Plane Component , the two components that define an IP > service. As a result of this focus, this document ignores other > uses of Netlink, including its use as an intra-kernel messaging > system, as an inter-process communication scheme (IPC), or as a > configuration tool for non-networking or non-IP network services > (such as DecNet, etc.). > > This document is intended as informational in the > context of prior art for the ForCES IETF working group. > > Change Section 1, para 1, line 1 > OLD: > The concept of IP Service control-forwarding separation was first > introduced in the early 1980s by the BSD 4.4 routing sockets [9]. > NEW: > The concept of IP Service control-forwarding separation was first > introduced in the early 1990s by the BSD 4.4 routing sockets [9]. >