From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 10 10:24:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10475 for ; Thu, 10 Jun 2004 10:24:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYQTk-0006sx-2D for forces-archive@ietf.org; Thu, 10 Jun 2004 10:24:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYQRr-0005zK-00 for forces-archive@ietf.org; Thu, 10 Jun 2004 10:22:32 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYQQx-0005U5-00 for forces-archive@IETF.ORG; Thu, 10 Jun 2004 10:21: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.00DDBAA2@cherry.ease.lsoft.com>; Thu, 10 Jun 2004 10:21:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20802226 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Jun 2004 10:21:24 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jun 2004 10:20:17 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5AEJqXv018408 for ; Thu, 10 Jun 2004 14:19:52 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AEL0Eg025094 for ; Thu, 10 Jun 2004 14:21:22 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061007201216268 for ; Thu, 10 Jun 2004 07:20:12 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 07:20:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: ForCES Protocol process update Thread-Index: AcRO9gp5NWLdWBshQmqi5G8oysMyfA== X-OriginalArrivalTime: 10 Jun 2004 14:20:12.0771 (UTC) FILETIME=[0B0F9B30:01C44EF6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Thu, 10 Jun 2004 07:20:11 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Protocol process update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, The Forces protocol design team has missed the June 2 milestone for distributing an early draft of their proposal. However, the team has informed me that they=20 will have the a draft sent to the IETF for WG review by=20 June 15th. The design team has been making good progress so I believe that this date will be met. I have also been informed that the author of the original FACT proposal, Alex Audu, will be submitting a separate proposal based on FACT. In order to make timely progress I will be asking the working group to review the proposals and, if appropriate, accept one as the official working group proposal by the=20 meeting in San Diego in early August. Cheers, David Putzolu From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 10 11:07:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12734 for ; Thu, 10 Jun 2004 11:07:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYR9R-00032N-Jk for forces-archive@ietf.org; Thu, 10 Jun 2004 11:07:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYR8E-0002b0-00 for forces-archive@ietf.org; Thu, 10 Jun 2004 11:06:19 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYR7R-00029A-00 for forces-archive@IETF.ORG; Thu, 10 Jun 2004 11:05: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 <15.00DDBC43@cherry.ease.lsoft.com>; Thu, 10 Jun 2004 11:05:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20808343 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Jun 2004 11:05:28 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jun 2004 11:04:54 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004061008041679:16617 ; Thu, 10 Jun 2004 08:04:16 -0700 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2004 08:04:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2004 08:04:19 AM, Serialize complete at 06/10/2004 08:04:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1086879890.1024.72.camel@jzny.localdomain> Date: Thu, 10 Jun 2004 11:04:50 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: ForCES Protocol process update Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-06-10 at 10:20, Putzolu, David wrote: > I have also been informed that the author of the original > FACT proposal, Alex Audu, will be submitting a separate > proposal based on FACT. I sincerely hope that Hormuzd and Ram will ensure their names are not on that draft. Otherwise, we should stop the protocol merger discussion now. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 10 13:03:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19578 for ; Thu, 10 Jun 2004 13:03:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSxW-0002qV-11 for forces-archive@ietf.org; Thu, 10 Jun 2004 13:03:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSwo-0002O0-00 for forces-archive@ietf.org; Thu, 10 Jun 2004 13:02:39 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYSvD-0001V4-00 for forces-archive@IETF.ORG; Thu, 10 Jun 2004 13:00: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 <14.00DDBDC9@cherry.ease.lsoft.com>; Thu, 10 Jun 2004 13:00:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20822438 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Jun 2004 13:00:57 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jun 2004 12:59:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5AH1DmX010661; Thu, 10 Jun 2004 17:01:19 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5AGtaEW025619; Thu, 10 Jun 2004 16:55:45 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061009543507422 ; Thu, 10 Jun 2004 09:54:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 09:54:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: [FORCES] ForCES Protocol process update Thread-Index: AcRO/Gz/shEUJeMuTge1PtmCHWxR7AADvwjA X-OriginalArrivalTime: 10 Jun 2004 16:54:35.0478 (UTC) FILETIME=[9C108760:01C44F0B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E015D39DB@orsmsx408> Date: Thu, 10 Jun 2004 09:54:34 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Protocol process update Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Jamal, I am not even aware of this effort, I don't think Ram is either regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Thursday, June 10, 2004 8:05 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Protocol process update On Thu, 2004-06-10 at 10:20, Putzolu, David wrote: > I have also been informed that the author of the original > FACT proposal, Alex Audu, will be submitting a separate > proposal based on FACT. I sincerely hope that Hormuzd and Ram will ensure their names are not on that draft. Otherwise, we should stop the protocol merger discussion now. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 11 04:34:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06956 for ; Fri, 11 Jun 2004 04:34:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYhUE-0000Z2-UG for forces-archive@ietf.org; Fri, 11 Jun 2004 04:34:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYhTI-00008I-00 for forces-archive@ietf.org; Fri, 11 Jun 2004 04:33:09 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYhSm-0007UG-00 for forces-archive@IETF.ORG; Fri, 11 Jun 2004 04:32: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 <18.00DDD122@cherry.ease.lsoft.com>; Fri, 11 Jun 2004 4:32:38 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 20926155 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Jun 2004 04:32:37 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jun 2004 04:27:28 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5B8RRlg087676 for ; Fri, 11 Jun 2004 08:27:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5B8RQJa278802 for ; Fri, 11 Jun 2004 10:27:26 +0200 Received: from zurich.ibm.com (dhcp69-53.zurich.ibm.com [9.4.69.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA58814 for ; Fri, 11 Jun 2004 10:27:26 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i5B8RRlg087676 Message-ID: <40C96CED.1050209@zurich.ibm.com> Date: Fri, 11 Jun 2004 10:27:25 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Meaning of FEStatus and roles in the model To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, I'd like to understand more precisely the meaning of FEStatus as=20 specified in http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt 5.2.2.1. FEStatus=20 =20 This attribute carries the overall state of the FE. For now, it is=20 restricted to the strings AdminDisable, OperDisable and OperEnable.=20 Is FEStatus meant to be an attribute that can be set from the CE in=20 order to activate/deactivate the datapath processing of the FE ? What is the distinction between Admin(istrator) and Oper(ator) ? Is a=20 role-based authentication expected ? Thanks, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 11 11:08:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09993 for ; Fri, 11 Jun 2004 11:08:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYneK-0000ya-U4 for forces-archive@ietf.org; Fri, 11 Jun 2004 11:08:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYncr-0000LW-00 for forces-archive@ietf.org; Fri, 11 Jun 2004 11:07:26 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYnat-0007GM-00 for forces-archive@IETF.ORG; Fri, 11 Jun 2004 11: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 <1.00DDDBA8@cherry.ease.lsoft.com>; Fri, 11 Jun 2004 11:05:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21011195 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Jun 2004 11:05:20 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jun 2004 09:53:22 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7057747 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Jun 2004 09:53:21 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <5.1.0.14.0.20040611094820.024825c0@localhost> Date: Fri, 11 Jun 2004 09:53:00 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Meaning of FEStatus and roles in the model To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <40C96CED.1050209@zurich.ibm.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The distinction between Admin and Oper status comes out of other network=20 management work. sorry I was not more clear. AdminDisable means that network management (maybe the CE via Forces if we=20 choose to allow it, but more usually CLI or SNMP or ...) has disabled the=20 device so it will not perform its function. It is still active, and so may= =20 be discovered by a CE and might participate in ForCES. OperDisable means that the FE thinks it ought to be operating, but has run= =20 into an operational difficulty that has caused it to cease performing its=20 function. For a single-ported FE, this might mean a port failure. It=20 might mean that some critical part internally has been detected to have=20 failed. It might just mean that the device is restarting and is not=20 currently in a state to perform its functions. OperEnable is the normal operational status. This is not intended to be a comprehensive management diagnostic, but just= =20 enough information that the CE can know whether the FE is useable. I added= =20 it because I did not want "ForCES reachable" to be assumed equal to=20 "operationally available" since in reality the two are not always=20 interchangeable. Yours, Joel At 10:27 AM 6/11/2004 +0200, Robert Haas wrote: >Hi, >I'd like to understand more precisely the meaning of FEStatus as specified= in > >http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt > >5.2.2.1. FEStatus > This attribute carries the overall state of the FE. For now, it=20 > is restricted to the strings AdminDisable, OperDisable and OperEnable. >Is FEStatus meant to be an attribute that can be set from the CE in order= =20 >to activate/deactivate the datapath processing of the FE ? > >What is the distinction between Admin(istrator) and Oper(ator) ? Is a=20 >role-based authentication expected ? > >Thanks, > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 11 11:34:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11611 for ; Fri, 11 Jun 2004 11:34:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYo3K-00070e-VG for forces-archive@ietf.org; Fri, 11 Jun 2004 11:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYo2P-0006SL-00 for forces-archive@ietf.org; Fri, 11 Jun 2004 11:33:50 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYo1N-0005Pf-00 for forces-archive@IETF.ORG; Fri, 11 Jun 2004 11:32: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 <2.00DDDC5A@cherry.ease.lsoft.com>; Fri, 11 Jun 2004 11:32:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21013134 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Jun 2004 11:32:44 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jun 2004 11:18:28 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5BFIRlg090656; Fri, 11 Jun 2004 15:18:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5BFIQB1165472; Fri, 11 Jun 2004 17:18:27 +0200 Received: from zurich.ibm.com (dhcp69-53.zurich.ibm.com [9.4.69.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA60980; Fri, 11 Jun 2004 17:18:26 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040611094820.024825c0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i5BFIRlg090656 Message-ID: <40C9CD42.5060608@zurich.ibm.com> Date: Fri, 11 Jun 2004 17:18:26 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: Meaning of FEStatus and roles in the model Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040611094820.024825c0@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Thanks for the clarification. Is the FEStatus attribute read-only, or=20 read-write ? I.e., can I activate the FE by setting its FEstatus to=20 OperEnable, and deactivate it by setting it to AdminDisable ? NB, by=20 activate/deactivate, I mean enable/disable the processing of data=20 packets through the FE, i.e., enable/disable operation of all LFBs. Or=20 is there another attribute for this ? Regards, -Robert Joel M. Halpern wrote: > The distinction between Admin and Oper status comes out of other=20 > network management work. sorry I was not more clear. > AdminDisable means that network management (maybe the CE via Forces if=20 > we choose to allow it, but more usually CLI or SNMP or ...) has=20 > disabled the device so it will not perform its function. It is still=20 > active, and so may be discovered by a CE and might participate in ForCE= S. > OperDisable means that the FE thinks it ought to be operating, but has=20 > run into an operational difficulty that has caused it to cease=20 > performing its function. For a single-ported FE, this might mean a=20 > port failure. It might mean that some critical part internally has=20 > been detected to have failed. It might just mean that the device is=20 > restarting and is not currently in a state to perform its functions. > OperEnable is the normal operational status. > > This is not intended to be a comprehensive management diagnostic, but=20 > just enough information that the CE can know whether the FE is=20 > useable. I added it because I did not want "ForCES reachable" to be=20 > assumed equal to "operationally available" since in reality the two=20 > are not always interchangeable. > > Yours, > Joel > > At 10:27 AM 6/11/2004 +0200, Robert Haas wrote: > >> Hi, >> I'd like to understand more precisely the meaning of FEStatus as=20 >> specified in >> >> http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt >> >> 5.2.2.1. FEStatus >> This attribute carries the overall state of the FE. For now, it=20 >> is restricted to the strings AdminDisable, OperDisable and=20 >> OperEnable. >> Is FEStatus meant to be an attribute that can be set from the CE in=20 >> order to activate/deactivate the datapath processing of the FE ? >> >> What is the distinction between Admin(istrator) and Oper(ator) ? Is=20 >> a role-based authentication expected ? >> >> Thanks, >> >> --=20 >> Robert Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~r= ha > > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 11 14:22:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22834 for ; Fri, 11 Jun 2004 14:22:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYqfU-0003hA-Bb for forces-archive@ietf.org; Fri, 11 Jun 2004 14:22:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYqeU-00038r-00 for forces-archive@ietf.org; Fri, 11 Jun 2004 14:21:19 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BYqdI-0002Ad-00 for forces-archive@IETF.ORG; Fri, 11 Jun 2004 14:20:04 -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.00DDDDB9@cherry.ease.lsoft.com>; Fri, 11 Jun 2004 14:20:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21030598 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Jun 2004 14:20:01 -0400 Approved-By: alex.audu@ALCATEL.COM Received: from 143.209.238.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jun 2004 14:02:44 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i5BI2dRn009096; Fri, 11 Jun 2004 13:02:43 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <5.1.0.14.0.20040611094820.024825c0@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auds953.usa.alcatel.com id i5BI2dRn009096 Message-ID: <40C9F3BD.2A30D639@alcatel.com> Date: Fri, 11 Jun 2004 13:02:37 -0500 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: Meaning of FEStatus and roles in the model Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Simply put, an FE in AdminDisable status means the FE was removed by a ma= nagement entity (or manually by the craft person). OperDisable'd FE is an FE tha= t was removed automatically by the fault-isolation program in the system. In the latte= r case, the system will try to recover by for example, removing the FE, testing it, and then= if OK, restoring it back to service. Else, it is kept out of service. In the AdminDisabl= e (manual) case, the FE just stays out of service, and it shouldn't particiapte actively i= n handling packets. Cheers, Alex. "Joel M. Halpern" wrote: > The distinction between Admin and Oper status comes out of other networ= k > management work. sorry I was not more clear. > AdminDisable means that network management (maybe the CE via Forces if = we > choose to allow it, but more usually CLI or SNMP or ...) has disabled t= he > device so it will not perform its function. It is still active, and so= may > be discovered by a CE and might participate in ForCES. > OperDisable means that the FE thinks it ought to be operating, but has = run > into an operational difficulty that has caused it to cease performing i= ts > function. For a single-ported FE, this might mean a port failure. It > might mean that some critical part internally has been detected to have > failed. It might just mean that the device is restarting and is not > currently in a state to perform its functions. > OperEnable is the normal operational status. > > This is not intended to be a comprehensive management diagnostic, but j= ust > enough information that the CE can know whether the FE is useable. I a= dded > it because I did not want "ForCES reachable" to be assumed equal to > "operationally available" since in reality the two are not always > interchangeable. > > Yours, > Joel > > At 10:27 AM 6/11/2004 +0200, Robert Haas wrote: > >Hi, > >I'd like to understand more precisely the meaning of FEStatus as speci= fied in > > > >http://www.ietf.org/internet-drafts/draft-ietf-forces-model-02.txt > > > >5.2.2.1. FEStatus > > This attribute carries the overall state of the FE. For now, it > > is restricted to the strings AdminDisable, OperDisable and OperEna= ble. > >Is FEStatus meant to be an attribute that can be set from the CE in or= der > >to activate/deactivate the datapath processing of the FE ? > > > >What is the distinction between Admin(istrator) and Oper(ator) ? Is a > >role-based authentication expected ? > > > >Thanks, > > > >-- > >Robert Haas > >IBM Zurich Research Laboratory > >S=E4umerstrasse 4 > >CH-8803 R=FCschlikon/Switzerland > >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~r= ha From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 16 12:19:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16299 for ; Wed, 16 Jun 2004 12:19:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bad8V-0002YU-8v for forces-archive@ietf.org; Wed, 16 Jun 2004 12:19:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bacmx-0006gn-00 for forces-archive@ietf.org; Wed, 16 Jun 2004 11:57:24 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BacMC-000213-00 for forces-archive@IETF.ORG; Wed, 16 Jun 2004 11:29:44 -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.00DE6BED@cherry.ease.lsoft.com>; Wed, 16 Jun 2004 11:29:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21771453 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Jun 2004 11:29:45 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jun 2004 08:59:10 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5G5wadr032021 for ; Wed, 16 Jun 2004 05:59:11 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5GCrumG022981 for ; Wed, 16 Jun 2004 12:54:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004061605583015615 for ; Wed, 16 Jun 2004 05:58:30 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jun 2004 05:58:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Update on ForCES Protocol Design Team Activities Thread-Index: AcRToZ7UYJCTYG+CR1GfApJqYhNhvA== X-OriginalArrivalTime: 16 Jun 2004 12:58:30.0733 (UTC) FILETIME=[9FB277D0:01C453A1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Wed, 16 Jun 2004 05:58:29 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Update on ForCES Protocol Design Team Activities To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, The ForCES protocol design team was scheduled to post a=20 draft of their proposed merged protocol on June 15th. The team has the draft nearly ready and is in the process of reviewing it. I expect that it should be posted for to the IETF for WG review by the end of=20 the week. Cheers, David From nv33134@yahoo.com Sat Jun 19 02:56:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06395 for ; Sat, 19 Jun 2004 02:56:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbZm3-00075l-O5 for forces-archive@ietf.org; Sat, 19 Jun 2004 02:56:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbZkv-0006dX-00 for forces-archive@ietf.org; Sat, 19 Jun 2004 02:55:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BbZjx-0006EB-00; Sat, 19 Jun 2004 02:54:13 -0400 Received: from [211.162.137.251] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BbZcK-0007uA-4b; Sat, 19 Jun 2004 02:46:37 -0400 From: "Apelo a João Paulo II:" To: ftpext-archive@ietf.org Subject: Livrai o Brasil da ação maléfica da esquerda católica! . jcz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 19 Jun 2004 02:46:37 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.0 required=5.0 tests=AWL,FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, LINES_OF_YELLING,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * -0.0 AWL AWL: Auto-whitelist adjustment c0406tfpjpbrres2

(ref.: elo) Está permitida a reprodução total ou parcial desta notícia; não é necessário citar a fonte: Atualidade Brasileira

A João Paulo II: "Livrai o Brasil da ação maléfica da esquerda católica!"

Filial apelo do Brasil pacífico e laborioso, angustiado pelo eclodir de conflitos que poderão levar o País a uma sangrenta guerra social

CIDADE DO VATICANO (AB) - É com preocupação que nosso povo, pacífico, laborioso e religioso, assiste ao eclodir de conflitos que poderão levá-lo a uma sangrenta guerra social. Muitos desses conflitos crescem pela agitação de sacerdotes e leigos da "esquerda católica", que apoiam soluções violentas para os problemas sociais e que contam com a omissão, quando não com o apoio ostensivo, de Prelados dos mais altos na Hierarquia eclesiástica brasileira.

É o que afirma, em extensa mensagem que acaba de chegar a S.S. João Paulo II, a Associação dos Fundadores da TFP - Tradição, Família e Propriedade (para receber gratuitamente, por e-mail, o texto completo, de 12 páginas, da carta a S.S. João Paulo II, clique no link: CartaJoaoPauloII:TextoCompletoGratuito).

Sob a égide da "esquerda católica", com a colaboração da Comissão Pastoral da Terra (CPT) e do Conselho Indigenista Missionário (CIMI) - órgãos da Conferencia Nacional dos Bispos Católicos (CNBB) - se articulam os tentáculos da ação subversiva, para encaminhar o País pelas sendas da miséria e da fome, acrescenta a carta. O próximo passo poderá ser uma guerrilha rural que leve ao Brasil a uma situação similar à da Colômbia. O quadro se vê agravado pela presença da "esquerda católica" no atual governo, cujos membros ocupam postos-chave a partir dos quais desenvolvem uma ação em prol da luta de classes.

A missiva faz referência a livros do Prof. Plinio Corrêa de Oliveira nos quais o autor denunciou a esquerda eclesiástica encastoada na CNBB, como sendo a força capaz de contaminar a opinião pública brasileira, pacata e conservadora, com as febricitações da demagogia revolucionária (Prof.Plinio:EnviarMaisInfo).

E conclui com um apelo: Santo Padre, não permitais que, em nome da Igreja, leigos, religiosos e até altos eclesiásticos conduzam nossa Pátria, que nasceu sob o signo da Cruz, para uma fratricida guerra social, tão avessa ao espírito cristão e à índole bondosa de nosso povo! Ouvi, Santo Padre, o apelo filial e angustiado que Vos dirigimos: "Salvai o Brasil da ação maléfica da esquerda católica!"

040611AB - Atualidade Brasileira

LINKS:

CartaJoaoPauloII:MinhaAdesão (ao clicar neste link, favor acrescentar nome completo, cidade e RG ou CIC; seu e-mail será impresso e enviado a Roma, junto com as demais adesões recebidas; pode incluir nomes e dados de familiares, amigos e colegas de trabalho, com o prévio consentimento destes)

CartaJoaoPauloII:Concordo ---- Discordo ---- EmTermos (em qualquer das três opções, escreva, de preferência, nome, cidade e RG ou CIC)

CartaJoaoPauloII:TextoCompletoGratuitoPorE-Mail

TELEFONES DE CONTATO:

Associação dos Fundadores da TFP - Tradição Família Propriedade

Tels.: (011) 3822-3241 (011) 3661-8545

Rua Avaré, 359 - 01243-030 - Bairro Pacaembu - São Paulo (SP)

POSTDATA 1:

Está no prelo o livreto "Pastoral da Terra e MST incendeiam o Brasil" (20 capítulos breves, 56 pp.). Para receber gratuitamente, por e-mail, o Índice e a Introdução, clique em:

Livro:DesejoReceberIntroGratuitamentePorE-Mail

Para adquirir a edição impressa, clique no seguinte link, incluindo nome, endereço postal e telefone de contato, e receberá as instruções de pagamento (valor do exemplar, correio incluído: R$ 10,00)

Livro:DesejoAdquirirPorCorreio

POSTDATA 2:

Para conhecer detalhes inéditos das atuais estratégias da "esquerda católica" no Brasil e em outros países, sugerimos a leitura de 5 e-Books a respeito do Fórum Social Mundial de Porto Alegre (2001-2002-2003), do Fórum Social Brasileiro de Belo Horizonte (2003) e do Fórum Social Mundial de Bombay (2004). Receba via e-mail, links para fazer download gratuito dos 5 e-Books, clicando em:

ForumSocial:e-BooksGratuitos

LINK DE REMOÇÃO:

Retirar Caso já tiver efetuado anteriormente, sem sucesso, o pedido de remoção, lhe solicitamos o enorme favor de copiar e nos enviar na íntegra o denominado "Código Fonte da Mensagem", para nossos técnicos poderem verificar a qual e-mail, exatamente, lhe escrevemos, e assim tirá-lo imediatamente do Address Book. Clique acima da mensagem com o botão direito do "mouse", depois em "Propriedades", "Detalhes" e "Código Fonte". Solicitamos desculpas pelos inconvenientes ocasionados.

A difusão desta mensagem e seu conteúdo são de exclusiva responsabilidade da agência Atualidade Brasileira.

 From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 21 12:52:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02384 for ; Mon, 21 Jun 2004 12:52:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcS2F-0002FS-OW for forces-archive@ietf.org; Mon, 21 Jun 2004 12:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcRPf-00058H-00 for forces-archive@ietf.org; Mon, 21 Jun 2004 12:12:52 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BcQqm-0005yY-00 for forces-archive@IETF.ORG; Mon, 21 Jun 2004 11:36: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 <4.00DEF89E@cherry.ease.lsoft.com>; Mon, 21 Jun 2004 11:36:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22368038 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 21 Jun 2004 11:36:46 -0400 Approved-By: alex.audu@ALCATEL.COM Received: from 143.209.238.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 21 Jun 2004 11:23:51 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i5LFNm0J022845; Mon, 21 Jun 2004 10:23:49 -0500 (CDT) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40D6FD84.89ECE7DB@alcatel.com> Date: Mon, 21 Jun 2004 10:23:48 -0500 Reply-To: alex.audu@alcatel.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Lucent proposes Soft Router concept. Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Lucent tables proposal to separate forwading from routing at the NGN. They call the idea the Soft Router concept. Follow this link for further details. ..................................................................................................................................... The Softrouter Concept and the Proposal for the Study of Separation of Forwarding and Routing in the Next Generation Network http://www.itu.int/ITU-T/ngn/fgngn/docs/FGNGN-004-June04.doc ...................................................................................................................................... Regards, Alex. From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 23 03:40:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27042 for ; Wed, 23 Jun 2004 03:40:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2NJ-0004e0-5d for forces-archive@ietf.org; Wed, 23 Jun 2004 03:40:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd1bU-0003UN-00 for forces-archive@ietf.org; Wed, 23 Jun 2004 02:51:29 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BczY4-0002E0-00 for forces-archive@IETF.ORG; Wed, 23 Jun 2004 00:39: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 <9.00DF2D85@cherry.ease.lsoft.com>; Wed, 23 Jun 2004 0:39:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22644782 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 23 Jun 2004 00:39:48 -0400 Approved-By: avri@PSG.COM Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jun 2004 00:26:42 -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 i5N4Iveq010250 for ; Wed, 23 Jun 2004 06:19:57 +0200 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-135933427" X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.618) Message-ID: <857B62D6-C4CD-11D8-9D04-000393CC2112@psg.com> Date: Wed, 23 Jun 2004 00:26:39 -0400 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 --Apple-Mail-7-135933427 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, I have just sent our first draft of a "ForCES Protocol Specification" to the Internet Drafts editor. In the meantime, it can be found at: http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt a. For the ForCES protocol design team: Ligang Dong Avri Doria Ram Gopal Robert Haas Jamal Hadi Salim Hormuzd M Khosravi Weiming Wang --Apple-Mail-7-135933427 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFA2QZ/zUL36xoPd70RAtP1AKCRPVtBC3AlLXSWeOxiFKry6RHUXQCeP7c1 Cfdea+cWHe/Zs1JVosNoBC4= =zM7H -----END PGP SIGNATURE----- --Apple-Mail-7-135933427-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 24 11:19:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20908 for ; Thu, 24 Jun 2004 11:19:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdW0s-0005R0-LS for forces-archive@ietf.org; Thu, 24 Jun 2004 11:19:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdVzw-00054M-00 for forces-archive@ietf.org; Thu, 24 Jun 2004 11:18:45 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdVz9-0004hF-00 for forces-archive@IETF.ORG; Thu, 24 Jun 2004 11:17:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00DF5744@cherry.ease.lsoft.com>; Thu, 24 Jun 2004 11:16:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22895586 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 11:16:49 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jun 2004 11:15:39 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7105856 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 11:15:38 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040624110501.0228bce0@localhost> Date: Thu, 24 Jun 2004 11:15:17 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Minor coping of applicability question To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <857B62D6-C4CD-11D8-9D04-000393CC2112@psg.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In reading the protocol proposal (my thanks to the design team for all their effort) I was struck by an minor terminology question. We define an NE as a single point of management which contains one or more CEs and one or more FEs. We do not define the span of control of a CE. That is, we do not declare that all of the FEs in an NE must work with the same CE (with others as standby). Nor do we define that all the FEs a CE controls must be within the NE. I do not think we intended that the CE span of control always exactly equals the NE. We may (or may not) have intended that the CE span of control is a subset of the NE. If people think that by NE we have always meant "the span of control of the CE" then we need to get that written down, and readers can ignore the rest of this note where I try to explain why I think that is what we should mean. But for most (maybe even all) ForCES protocol purposes, the only interesting scope is the scope of control of is the scope over which a CE has control. For example, the protocol document provides a very nice description of some atomicity, transaction commitment, and rollback issues (ACID). The text then says that the transaction start and transaction end bits (probably with a transaction abort message) are sufficient to provide FE level and NE level ACID properties. However, the ForCES protocol as far as I can tell does not actually work at the NE level. It works at the "CE span of control" level. In terms of the ForCES protocol, the bits can only provide ACID at that level. Fortunately, that is what I think we need, as transaction consistency across CEs is clearly outside of our scope. So, my only point is that the document use "across the NE" because that is the span we have tended to talk about. I think we usually mean "across of span of control of the CE". One possibility is to explicitly make the NE equal to the span of control of the CE. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 24 11:57:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23301 for ; Thu, 24 Jun 2004 11:57:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdWbs-0004da-5B for forces-archive@ietf.org; Thu, 24 Jun 2004 11:57:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdWb8-0004FR-00 for forces-archive@ietf.org; Thu, 24 Jun 2004 11:57:11 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdWaU-0003pQ-00 for forces-archive@IETF.ORG; Thu, 24 Jun 2004 11:56: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 <16.00DF58C8@cherry.ease.lsoft.com>; Thu, 24 Jun 2004 11:56:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22900566 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 11:56:29 -0400 Approved-By: alistair.munro@U4EATECH.COM Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jun 2004 11:53:16 -0400 Received: from ncs.bris.ac.uk ([137.222.10.36]) by dirg.bris.ac.uk with esmtp (Exim 4.34) id 1BdWXJ-0004le-Th for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 16:53:15 +0100 Received: from s182-4.nomadic.bris.ac.uk ([137.222.182.4] helo=EEN9174.een.bris.ac.uk) by ncs.bris.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BdWXJ-0005xe-Do for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 16:53:13 +0100 References: <5.1.0.14.0.20040624110501.0228bce0@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 Message-ID: <98854274.1088095989@[192.168.1.132]> Date: Thu, 24 Jun 2004 16:53:10 +0100 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Minor coping of applicability question To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040624110501.0228bce0@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Joel, You are speaking on a topic close to my heart. I think the scope of administration of FEs by a CE is a policy issue. The protocol will provide a language in which any CE will be able to speak to any FE in competition with other CEs. The protocol must provide the mechanisms to deny access to ineligible CEs (according to local security and policy regimes) and ensure ACID properties for concurrent access by eligible CEs. What the messages actually say is for administrators to decide and the language should be expressive enough (e.g by referring to other status as established by RADIUS (an example, not a mandate)) to discriminate administrative rights and priorities in resolving conflicts. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 24 16:01:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22947 for ; Thu, 24 Jun 2004 16:01:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdaPb-0003b2-Ce for forces-archive@ietf.org; Thu, 24 Jun 2004 16:01:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZrZ-0004rj-00 for forces-archive@ietf.org; Thu, 24 Jun 2004 15:26:23 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdZPu-0007Al-00 for forces-archive@IETF.ORG; Thu, 24 Jun 2004 14:57:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00DF5BDE@cherry.ease.lsoft.com>; Thu, 24 Jun 2004 14:57:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22920710 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 14:57:45 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jun 2004 14:56:04 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062411551461:66787 ; Thu, 24 Jun 2004 11:55:14 -0700 References: <5.1.0.14.0.20040624110501.0228bce0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2004 11:55:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2004 11:55:18 AM, Serialize complete at 06/24/2004 11:55:18 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1088103358.1039.91.camel@jzny.localdomain> Date: Thu, 24 Jun 2004 14:55:59 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Minor coping of applicability question Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040624110501.0228bce0@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 11:15, Joel M. Halpern wrote: > In reading the protocol proposal (my thanks to the design team for all > their effort) I was struck by an minor terminology question. > > We define an NE as a single point of management which contains one or more > CEs and one or more FEs. > Thats the general feeling. > We do not define the span of control of a CE. That is, we do not declare > that all of the FEs in an NE must work with the same CE (with others as > standby). Nor do we define that all the FEs a CE controls must be within > the NE. I do not think we intended that the CE span of control always > exactly equals the NE. We may (or may not) have intended that the CE span > of control is a subset of the NE. If i understood you correctly, there are two intersecting scopes: 1) Control of a NE (Forces scope) by a CE(s). Such a NE may spun multi boxes, racks or geographical locations etc 2) Control of network or set of related NEs (maybe within an administrative domain); #2 is the superset. Of course this applies as well to things like VRs within same physical box/chasis. There should be no problem having the physical CE(s) doing #2 also doing #1 - call it a super-CE for being knowledgeable about multiple NEs. And there should be no issues with CE(s) controlling multiple NEs and residing on the same physical hardware coordinating their activities in policy making (hence achieveing a single point of management). The bigger question is whether Forces is the protocol to use for #2 or whether some other "management"/ "provisioning" protocol (netconf or SNMP for example) is more appropriate... Forces fits and can be used in both but it is cleaner to separate the two scopes. > If people think that by NE we have always meant "the span of control of the > CE" then we need to get that written down, and readers can ignore the rest > of this note where I try to explain why I think that is what we should mean. Your other text is valid, but i think we should limit the NE to be within the "the span of control of the CE" (for now at least). If it needs to be added we should (should probably have happened on the Framework doc). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 24 16:59:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09711 for ; Thu, 24 Jun 2004 16:59:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdbJe-0006KA-5e for forces-archive@ietf.org; Thu, 24 Jun 2004 16:59:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdafF-0006jb-00 for forces-archive@ietf.org; Thu, 24 Jun 2004 16:17:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bda5r-00007D-00 for forces-archive@IETF.ORG; Thu, 24 Jun 2004 15:41: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 <23.00DF5CEF@cherry.ease.lsoft.com>; Thu, 24 Jun 2004 15:41:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22925405 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 15:41:06 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jun 2004 15:34:15 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7107092 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 15:34:13 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040624121631.0247b640@localhost> Date: Thu, 24 Jun 2004 15:33:51 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <857B62D6-C4CD-11D8-9D04-000393CC2112@psg.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Some minor comments on the document. 1) The common header defines a version number field. It further splits that version number field into two subfields (major and minor). I presume this is intended for some form of negotiation / compatibility. I further presume that the absence of a description is due to a lack of time. However, if you are going to be this specific about the structure, some text about the reason for the distinction and what might be affected by the internal structure would be very helpful. 2) The document frequently says ~the body of message foo consists of one TLV which looks like~ and then proceeds to give the format and description of the TLV. It would seem a good practice if each TLV were given a name (even if that name is the same as the type in some cases) so I could refer to the "heart beat interval TLV" or the "result code tlv" (which should only be the name if that tlv can appear in multiple different messages as the result. Otherwise it should be named "association result TLV".) 3) In the definition of the "heartbeat interval" it would be a good idea if this description said either ~the interval at which the sender expects to generate heartbeat messages~ or ~the interval at which the sender requests the receiver to generate heartbeat messages~. Either is useful. Simply "heartbeat interval" is unclear. 4) It seems wrong to say "the ACK flag in the header is always ignored" in various message description. We ought to specify how the flag should be set. 4') We ought to define the meaning of the ack bit. Choices I can think of: 4'a) The receiver is expected to send a "ack" message when this is received. With this meaning, messages with mandatory response messages would set the bit to one. 4'b) The receiver is expected to send the message-type-specific response message when this message is received. For messages with mandatory responses, the bit would be set to 1. For messages with optional responses, the bit would be set according to the intent of the message sender. 5) I think that trying to mix LFB selection with the FE / CE identification in the last part of bullet G of section 5 is a mistake. This level of addressing ought to indicate which FEs I want to talk about. If I need to be able to indicate a specific subset of LFBs on FE 1 and a distinct subset of FE2 while sending both FEs the same message, then we should add mechanisms to create LFB groupings, and put that group identifier in an LFB group TLV. Thank you, Joel At 12:26 AM 6/23/2004 -0400, avri@PSG.COM wrote: >I have just sent our first draft of a "ForCES Protocol Specification" >to the Internet Drafts editor. > >In the meantime, it can be found at: > >http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 24 20:07:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05749 for ; Thu, 24 Jun 2004 20:06:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bde30-0005xe-M0 for forces-archive@ietf.org; Thu, 24 Jun 2004 19:54:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bddvv-0003oB-00 for forces-archive@ietf.org; Thu, 24 Jun 2004 19:47:08 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BddqX-00029W-00 for forces-archive@IETF.ORG; Thu, 24 Jun 2004 19:41:33 -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.00DF601F@cherry.ease.lsoft.com>; Thu, 24 Jun 2004 19:41:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 22949562 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Jun 2004 19:41:32 -0400 Approved-By: sridhar@FUTSOFT.COM Received: from 203.197.138.196 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jun 2004 19:39:12 -0400 Received: from sanjose.futsoft.com (unverified [203.197.138.202]) by fcsmail.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Fri, 25 Jun 2004 05:10:29 +0530 Received: (qmail 10389 invoked by uid 505); 25 Jun 2004 05:08:00 +0530 Received: from sridhar@futsoft.com by sanjose by uid 89 with qmail-scanner-1.16 (clamscan: 0.60. spamassassin: 2.60. Clear:. Processed in 1.007002 secs) ; 24 Jun 2004 23:38:00 -0000 Received: from unknown (HELO SonyVaioR505) (66.122.42.230) by 0 (qmail 1.03 + ejcp v14) with SMTP; 25 Jun 2004 05:07:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Date: Thu, 24 Jun 2004 16:38:54 -0700 Reply-To: sridhar@futsoft.com Sender: Forwarding and Control Element Separation From: "T. Sridhar" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040624121631.0247b640@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, Here's my set of comments (mostly minor): 1. Section 3.1.1, near the last line - parameterization is spelt incorrectly. 2. Section 3.2.2.1 - suggest "More details are provided in the section on protocol scenarios". 3. Section 3.3.1 - second paragraph - it is not clear whether message batch reassembly needs to take place before exectution. How does this work? Also, the concept of batch is introduced only in Section 3.3.3, hence the text is a little difficult to understand in this section. 4. Section 6.2 - the bullet items under "FE (coarse layer) information". The second bullet states "Inter-FE topology, that is, LFB topology" - shouldn't that be "Intra-FE topology"? 5. Section 6.5 - A nit - since Packet Redirect messages also involve CE-FE messages (which is not really a redirect) , should we look at calling it something else, e.g. Packet Transfer message? Thanks, Sridhar At 12:26 AM 6/23/2004 -0400, avri@PSG.COM wrote: >I have just sent our first draft of a "ForCES Protocol Specification" >to the Internet Drafts editor. > >In the meantime, it can be found at: > >http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt *************************************************************************** This message is proprietary to FutureSoft and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FutureSoft accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 25 17:00:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13137 for ; Fri, 25 Jun 2004 17:00:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdxoG-0006Nt-J9 for forces-archive@ietf.org; Fri, 25 Jun 2004 17:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdxnH-000653-00 for forces-archive@ietf.org; Fri, 25 Jun 2004 16:59:32 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdxmJ-0005mM-00 for forces-archive@IETF.ORG; Fri, 25 Jun 2004 16:58:31 -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.00DF7A8F@cherry.ease.lsoft.com>; Fri, 25 Jun 2004 16:58:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23088998 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Jun 2004 16:58:30 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jun 2004 16:57:30 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5PKgpDA005383 for ; Fri, 25 Jun 2004 20:57:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5PFb6QY024487 for ; Fri, 25 Jun 2004 15:37:34 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062508360711069 for ; Fri, 25 Jun 2004 08:36:07 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 08:36:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: Please review protocol proposal (was: First draft of ForCES protocol from the protocol design team) thread-index: AcRY3CJy299nnrHlQ5Kb+ShcsvApgABOoGxA X-Priority: 1 Priority: Urgent Importance: high X-Message-Flag: Follow up X-OriginalArrivalTime: 25 Jun 2004 15:36:07.0794 (UTC) FILETIME=[22433520:01C45ACA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Fri, 25 Jun 2004 08:36:06 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Please review protocol proposal (was: First draft of ForCES protocol from the protocol design team) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, After much hard work, the ForCES protocol design=20 team has posted a draft protocol specification.=20 Thank you for your efforts! The draft should be in the IETF draft repository shortly,=20 and in the meanwhile it is available at the URL below: http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt The next step is for the working group to review=20 draft-fpteam-forces-protocol-00.txt and post=20 comments to this mailing list by August 2 addressing the following topics: 1 Is the draft comprehensible and clear? What clarifications are needed? 2 Is the proposed protocol a good solution? Are any changes necessary? 3 Is the draft ready to be accepted as a working group=20 document as is? with changes?=20 Thanks, David and Patrick =20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of avri@PSG.COM Sent: Tuesday, June 22, 2004 9:27 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] First draft of ForCES protocol from the protocol design team Hi, I have just sent our first draft of a "ForCES Protocol Specification"=20 to the Internet Drafts editor. In the meantime, it can be found at: http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt a. For the ForCES protocol design team: Ligang Dong Avri Doria Ram Gopal Robert Haas Jamal Hadi Salim Hormuzd M Khosravi Weiming Wang From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 25 17:49:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15898 for ; Fri, 25 Jun 2004 17:49:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdyZf-0004tf-90 for forces-archive@ietf.org; Fri, 25 Jun 2004 17:49:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdyYi-0004d8-00 for forces-archive@ietf.org; Fri, 25 Jun 2004 17:48:33 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdyXr-0004MA-00 for forces-archive@IETF.ORG; Fri, 25 Jun 2004 17:47: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 <0.00DF7C5A@cherry.ease.lsoft.com>; Fri, 25 Jun 2004 17:47:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23092833 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Jun 2004 17:47:38 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jun 2004 17:08:24 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7112087 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Jun 2004 17:08:23 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040625170457.024b8458@localhost> Date: Fri, 25 Jun 2004 17:07:56 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Please review protocol proposal To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In my opinion, the draft is comprehensible and clear. While there are many open issues, they are identified in the document. The proposal appears to be a good starting point for the protocol. I believe it can easily do what we need. There are some interesting questions that will need to be elaborated, such as the representation of attribute references and attribute values in the Query and Configure messages. But these can be addressed. Given that I consider this a good basis for work, I would be happy to see it made a working group document. My thanks to the protocol design team for getting us to this point. Yours, Joel M. Halpern At 08:36 AM 6/25/2004 -0700, Putzolu, David wrote: >All, > >After much hard work, the ForCES protocol design >team has posted a draft protocol specification. >Thank you for your efforts! > >The draft should be in the IETF draft repository shortly, >and in the meanwhile it is available at the URL below: > >http://psg.com/~avri/forces/draft-fpteam-forces-protocol-00.txt > >The next step is for the working group to review >draft-fpteam-forces-protocol-00.txt and post >comments to this mailing list by August 2 addressing >the following topics: > >1 Is the draft comprehensible and clear? What clarifications > are needed? > >2 Is the proposed protocol a good solution? Are any > changes necessary? > >3 Is the draft ready to be accepted as a working group > document as is? with changes? > >Thanks, >David and Patrick > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 25 18:52:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19340 for ; Fri, 25 Jun 2004 18:52:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdzYf-0006AY-Bv for forces-archive@ietf.org; Fri, 25 Jun 2004 18:52:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdzXl-0005ub-00 for forces-archive@ietf.org; Fri, 25 Jun 2004 18:51:38 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BdzXA-0005eg-00 for forces-archive@IETF.ORG; Fri, 25 Jun 2004 18:51:00 -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.00DF7C3B@cherry.ease.lsoft.com>; Fri, 25 Jun 2004 18:51:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23098516 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Jun 2004 18:50:59 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jun 2004 18:50:07 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5PMno3Y021338; Fri, 25 Jun 2004 22:49:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5PMpGQQ027682; Fri, 25 Jun 2004 22:51:25 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062515495509825 ; Fri, 25 Jun 2004 15:49:55 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 15:49:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: [FORCES] First draft of ForCES protocol from the protocol design team Thread-Index: AcRaRM4w7AGAuWZnTMKSLOYEr7k/hgAvunkg X-OriginalArrivalTime: 25 Jun 2004 22:49:56.0099 (UTC) FILETIME=[BC575D30:01C45B06] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E018FD7CB@orsmsx408> Date: Fri, 25 Jun 2004 15:49:55 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: sridhar@futsoft.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Sridhar, Thanks a lot for your comments. I am fine with most of your suggestions, comments below. We (protocol team) will discuss and incorporate these changes accordingly, in the next rev of the draft. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of T. Sridhar Sent: Thursday, June 24, 2004 4:39 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] First draft of ForCES protocol from the protocol design team Hi, Here's my set of comments (mostly minor): 1. Section 3.1.1, near the last line - parameterization is spelt incorrectly. 2. Section 3.2.2.1 - suggest "More details are provided in the section on protocol scenarios". 3. Section 3.3.1 - second paragraph - it is not clear whether message batch reassembly needs to take place before exectution. How does this work? Also, the concept of batch is introduced only in Section 3.3.3, hence the text is a little difficult to understand in this section. 4. Section 6.2 - the bullet items under "FE (coarse layer) information". The second bullet states "Inter-FE topology, that is, LFB topology" - shouldn't that be "Intra-FE topology"? 5. Section 6.5 - A nit - since Packet Redirect messages also involve CE-FE messages (which is not really a redirect) , should we look at calling it something else, e.g. Packet Transfer message? Thanks, Sridhar From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 26 02:41:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25428 for ; Sat, 26 Jun 2004 02:41:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Be6sm-00069c-Rc for forces-archive@ietf.org; Sat, 26 Jun 2004 02:41:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be6rv-0005uV-00 for forces-archive@ietf.org; Sat, 26 Jun 2004 02:40:56 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Be6rU-0005eh-00 for forces-archive@IETF.ORG; Sat, 26 Jun 2004 02:40:28 -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.00DF85E2@cherry.ease.lsoft.com>; Sat, 26 Jun 2004 2:40:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23152461 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Jun 2004 02:40:28 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.59 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jun 2004 21:10:34 -0400 Received: from WwmLapSamsung (unverified [220.192.126.217]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 26 Jun 2004 09:24:25 +0800 References: <468F3FDA28AA87429AD807992E22D07E018FD7CB@orsmsx408> 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <002001c45b19$f3064180$d97ec0dc@WwmLapSamsung> Date: Sat, 26 Jun 2004 09:07:21 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 SGkgU3JpZGhhciwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxlZCByZXZp ZXcgb2YgdGhlIGRyYWZ0LiBQbHMgc2VlIHNvbWUgcmVwbGllcyBpbmxpbmUuDQoNClRoYW5rcyBh Z2Fpbi4NCg0KQmVzdCByZWdhcmRzLA0KV2VpbWluZw0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uDQpb bWFpbHRvOkZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTV0gT24gQmVoYWxmIE9mIFQuIFNyaWRo YXINClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI0LCAyMDA0IDQ6MzkgUE0NClRvOiBGT1JDRVNAUEVB Q0guRUFTRS5MU09GVC5DT00NClN1YmplY3Q6IFJlOiBbRk9SQ0VTXSBGaXJzdCBkcmFmdCBvZiBG b3JDRVMgcHJvdG9jb2wgZnJvbSB0aGUgcHJvdG9jb2wNCmRlc2lnbiB0ZWFtDQoNCkhpLA0KDQpI ZXJlJ3MgbXkgc2V0IG9mIGNvbW1lbnRzIChtb3N0bHkgbWlub3IpOg0KDQoxLiBTZWN0aW9uIDMu MS4xLCBuZWFyIHRoZSBsYXN0IGxpbmUgLSBwYXJhbWV0ZXJpemF0aW9uIGlzIHNwZWx0DQppbmNv cnJlY3RseS4NCg0KMi4gU2VjdGlvbiAzLjIuMi4xIC0gc3VnZ2VzdCAiTW9yZSBkZXRhaWxzIGFy ZSBwcm92aWRlZCBpbiB0aGUgc2VjdGlvbg0Kb24NCnByb3RvY29sIHNjZW5hcmlvcyIuDQoNCjMu IFNlY3Rpb24gMy4zLjEgLSBzZWNvbmQgcGFyYWdyYXBoIC0gaXQgaXMgbm90IGNsZWFyIHdoZXRo ZXIgbWVzc2FnZWJhdGNoDQpyZWFzc2VtYmx5IG5lZWRzIHRvIHRha2UgcGxhY2UgYmVmb3JlIGV4 ZWN0dXRpb24uIEhvdyBkb2VzIHRoaXMgd29yaz9BbHNvLA0KdGhlIGNvbmNlcHQgb2YgYmF0Y2gg aXMgaW50cm9kdWNlZCBvbmx5IGluIFNlY3Rpb24gMy4zLjMsIGhlbmNlIHRoZSB0ZXh0aXMNCmEg bGl0dGxlIGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIGluIHRoaXMgc2VjdGlvbi4NCg0KNC4gU2Vj dGlvbiA2LjIgLSB0aGUgYnVsbGV0IGl0ZW1zIHVuZGVyICJGRSAoY29hcnNlIGxheWVyKSBpbmZv cm1hdGlvbiIuIFRoZQ0Kc2Vjb25kIGJ1bGxldCBzdGF0ZXMgIkludGVyLUZFIHRvcG9sb2d5LCB0 aGF0IGlzLCBMRkIgdG9wb2xvZ3kiIC1zaG91bGRuJ3QNCnRoYXQgYmUgIkludHJhLUZFIHRvcG9s b2d5Ij8NCg0KW1dlaW1pbmddIFdlIGFsc28gaGFkIHNvbWUgZG91YnQgb24gdGhpcyBhdCBmaXJz dC4gIEJ1dCBsYXRlciB3ZSBqdXN0IHJlYWxpemVkIHRoYXQgaXQgbWF5IGJlIG1vcmUgcmVhc29u YWJsZSB0byB0aGUgTEZCIHRvcG9sb2d5IGFzIEZFIGNvYXJzZSBsYXllciBpbmZvIGJlY2F1c2Ug aXQgaXMgYWN0dWFsbHkgdGhlIHByb3BlcnR5IG9mIHRoZSB3aG9sZSBGRSByYXRoZXIgdGhhbiBp bmRpdmlkdWFsIExGQnMsIGkuZS4sIGF0dHJpYnV0ZXMoY2FwYWJpbGl0eSkgb2YgaW5kaXZpZHVh bCBMRkJzIG1heSBub3QgYmUgYWJsZSB0byB0b3VnaCB0aGUgd2hvbGUgTEZCIHRvcG9sb2d5IGV4 Y2VwdCB0byBrbm93IHRoZSB0b3BvbG9neSBvZiBpdHNlbGYgdG8gb3RoZXJzLiANCg0KSW50cmEt RkUgdG9wb2xvZ3kgaXMgc3VyZSBiZWxvbmdzIHRvIHRoZSBGRSAoY29hcnNlIGxheWVyKSBpbmZv cm1hdGlvbiwgYW5kIGl0IGhhcyBiZWVuIGxpc3RlZCBpbi4NClsvV2VpbWluZ10NCg0KNS4gU2Vj dGlvbiA2LjUgLSBBIG5pdCAtIHNpbmNlIFBhY2tldCBSZWRpcmVjdCBtZXNzYWdlcyBhbHNvIGlu dm9sdmUgQ0UtRkUNCm1lc3NhZ2VzICh3aGljaCBpcyBub3QgcmVhbGx5IGEgcmVkaXJlY3QpICwg c2hvdWxkIHdlIGxvb2sgYXQgY2FsbGluZyBpdA0Kc29tZXRoaW5nIGVsc2UsIGUuZy4gUGFja2V0 IFRyYW5zZmVyIG1lc3NhZ2U/DQpbV2VpbWluZ10gSSBhZ3JlZSBpdCBpcyBtb3JlIGxpa2UgYSB0 cmFuc2ZlciB0aGFuIGEgcmVkaXJlY3Qgb3BlcmF0aW9uLCBidXQgdG8gdW5pZm9ybWx5IGdpdmUg YSByZWRpcmVjdCBuYW1lIG1heSBncmVhdGx5IGVhc3kgdGhlIGNvbnN0cnVjdGlvbiBhbmQgdXNl IG9mIHRoZSBtZXNzYWdlcywgaS5lLiwgd2l0aCBvbmx5IG9uZSB0eXBlIG9mIG1lc3NhZ2UuIEFu ZCBhbHNvIHRoZSByZWRpcmVjdCBvcCBmb3IgQ0UtRkUgYW5kIEZFLUNFIGlzIHF1aXRlIHN5bW1l dHJpY2FsLg0KWy9XZWltaW5nXQ0KDQpUaGFua3MsDQpTcmlkaGFyDQo= From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 26 08:28:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05881 for ; Sat, 26 Jun 2004 08:28:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeCHq-0007dV-8J for forces-archive@ietf.org; Sat, 26 Jun 2004 08:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeCGq-0007Od-00 for forces-archive@ietf.org; Sat, 26 Jun 2004 08:27:01 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BeCFx-000720-00 for forces-archive@IETF.ORG; Sat, 26 Jun 2004 08:26: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 <4.00DF8BE1@cherry.ease.lsoft.com>; Sat, 26 Jun 2004 8:26:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23204624 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Jun 2004 08:25:51 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 26 Jun 2004 07:14:07 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062604115938:69354 ; Sat, 26 Jun 2004 04:11:59 -0700 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/26/2004 04:12:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/26/2004 04:13:20 AM, Serialize complete at 06/26/2004 04:13:20 AM Content-Type: multipart/mixed; boundary="=-68vwsDLIOxMuSilMHtq/" Message-ID: <1088248364.1039.46.camel@jzny.localdomain> Date: Sat, 26 Jun 2004 07:12:45 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: sridhar@futsoft.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-68vwsDLIOxMuSilMHtq/ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 19:38, T. Sridhar wrote: > Hi, > > Here's my set of comments (mostly minor): > > 1. Section 3.1.1, near the last line - parameterization is spelt > incorrectly. > > 2. Section 3.2.2.1 - suggest "More details are provided in the section on > protocol scenarios". Noted. > 3. Section 3.3.1 - second paragraph - it is not clear whether message batch > reassembly needs to take place before exectution. Suggest some wording. The atomic unit is _always_ a transaction. A transaction may consist of several operations in a serial order. A transaction reassembly will be needed if these operations are split across multiple packets. The ordering/serialization of the operations is more important. > How does this work? Consider the transaction: "route-add A B,C:route-del X"; the FE must execute the 4 operations in the order specified. Theres actually a start of transaction indicator, followed by the operations (add/del) and terminated by a end of transaction indicator. Scenarios are: 1) the operations + start and end could be sent in one message in such a case no reassembly needed. 2) The operations + start in first packet and commit in the second. No reassembly needed. 3) The start + first operation, followed by the 3 operations and the end are all in separate packets. A reassembly is needed. Note depending on the TML, the middle operations could arrive out of order; the reassembly would ensure the ordering. Attached is some text that is missing from the draft that now that you ask it makes sense to put into section 3.3.3.1 The diagrams dont show more than one one config operation since the focus is on the 2pc. If you think it would help to show multiple config operations let us know. > Also, > the concept of batch is introduced only in Section 3.3.3, hence the text is > a little difficult to understand in this section. > Unfortunately batching applies to both concurency and as a scheme for unit-izing(if such a word exists) transactions. Maybe we should move the concurency section 3.3.3 to be 3.3.1 and shift the others down? cheers, jamal --=-68vwsDLIOxMuSilMHtq/ Content-Disposition: attachment; filename=2-Phase-Comit.txt Content-Type: text/plain; name=2-Phase-Comit.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X.1 2-Phase commit operation For certain type of configuration like RSVP signaling or VPN provisioning etc, CE may need send configuration messages to one or more FE's and those FE's may resides in separate blade. Based on the configuration response from each FEs, CE may need to perform additional steps to complete the single provisioning request. To incorporate such provisioning, ForCES PL should support 2-phase transaction oriented messaging. To illustrate this for consider an FE-1 belonging to say line card 1 and FE-2 belonging to line card 2 respectively. When an RSVP signaling is received via FE-1 ingress port, FE-1 forwards those packets to RSVP entity in CE. CE makes decision based on policies, appropriately sends RSVP reservation commands to both ingress port of FE-1 and egress port of FE-2 (say the packet leaves to the next-hop via FE-2) as two independent commands one destined for FE-1 and another for FE-2. Then CE waits for command response each of the FEs and may result in one of the outcome - both FEs are able to incorporate the RSVP request - one of them is able to accommodate this request - None of FEs were able to accommodate the request. Note: To perform the 2-Phase transaction, FE's and LFB should have capability to remember the earlier configuration in order to perform rollback operation. x.1.1 2-Phase commit scenario is described as follows: 2-Phase commit message sequence is described as follows, for illustrative purpose say CE is sending commands to FE-1 and FE-2 and asking FEs to configure one or more LFBs. 1. CE sends a configuration command to FE-1 requesting an LFB to add instance (like QoS reservation for a particular flow, note this may involve more than one LFB type). 2. CE sends a configuration command to FE-2 requesting an LFB to add instance (like QoS reservation for a particular flow, note this may involve more than one LFB type) 3. FE-1 after receiving the configuration request, programs the LFB successfully, and generate response message to CE as Success. 4. FE-2 after receiving the configuration request, programs the LFB successfully, and generate response message to CE as Success. 5. If all the FEs are able to accommodate the request, then CE sends a commit request to FE-1 with Seq.No =A which was used in 2-Phase Configure message 1. 6. CE sends a commit request to FE-2 with Seq.No =B which was used in 2-Phase Configure message 2. 7. FE-1 may send optionally Comit-Status with Seq.No=A to CE to completion the 2-phase transaction. 8. FE-2 may send optionally Comit-Status with Seq.No=B to CE to completion the 2-phase transaction. FE-1 CE FE-2 | | | | 1:Configure | | |<--------------------+ | | (LFB,Seq.No=A) | | | | 2:Configure | | +----------------------->| | | (LFB,Seq.No=B) | | 3:Status | | +-------------------->| | | (Success) | 4:Status | | |<-----------------------+ | | (Success) | | 5: Commit | | |<--------------------+ | | (Seq.No=A) | 6: Commit | | +----------------------->| | | (Seq.No=B) | | | | | 7:Comit-Status | | +-------------------->| | | (Seq.No=A) | 8:Comit-Status | | |<-----------------------+ | | (Seq.No=B) | x.1.1 2-Phase Roll-back conversion is described as follows: 2-Phase Roll-back message sequence is described as follows, for illustrative purpose we have take that CE is sending command to FE-1 and FE-2 and asking FEs to configure one or more LFBs. Roll-back is performed when one or more FEs fail to accommodate the CE configuration request. 1. CE sends a configuration command to FE-1 requesting an LFB to add instance (like QoS reservation for a particular flow, note this may involve more than one LFB type). 2. CE sends a configuration command to FE-2 requesting an LFB to add instance (like QoS reservation for a particular flow, note this may involve more than one LFB type) 3. FE-1 after receiving the configuration request, programs the LFB successfully, and generate response message to CE as Failure. 4. FE-2 after receiving the configuration request, programs the LFB successfully, and generate response message to CE as Success. 5. As one of the FEs (FE-1) has failed to accommodate the CE provisioning request, the CE sends a Roll-back message to the FEs which has accommodated the configuration request. That is CE sends Roll-back to FE-2. 6. FE-2 may send optionally Comit-Status with Seq.No=B to CE to completion the 2-phase transaction. FE-1 CE FE-2 | | | | 1:Configure | | |<--------------------+ | | (LFB,Seq.No=A) | | | | 2:Configure | | +----------------------->| | | (LFB,Seq.No=B) | | 3:Status | | +-------------------->| | | (Failure) | 4:Status | | |<-----------------------+ | | (Success) | | | | | | | | | 5:Roll-back | | +----------------------->| | | (Seq.No=B) | | | | | | | | | 6:Rollback-Status | | |<-----------------------+ | | (Seq.No=B) | --=-68vwsDLIOxMuSilMHtq/-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 26 13:12:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19150 for ; Sat, 26 Jun 2004 13:12:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeGit-0007Bp-5w for forces-archive@ietf.org; Sat, 26 Jun 2004 13:12:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeGhy-0006yd-00 for forces-archive@ietf.org; Sat, 26 Jun 2004 13:11:19 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BeGhR-0006l5-00 for forces-archive@IETF.ORG; Sat, 26 Jun 2004 13:10: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 <23.00DF8ECC@cherry.ease.lsoft.com>; Sat, 26 Jun 2004 13:10:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23222570 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Jun 2004 13:10:24 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 26 Jun 2004 13:09:27 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7115067 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Jun 2004 13:09:27 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040626130413.02385220@localhost> Date: Sat, 26 Jun 2004 13:09:24 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1088248364.1039.46.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Conceptually, I can understand wanting two phase commit. It looks like it should fit naturally in the protocol. It would seem that we should have a bit more motivation in the example. Normally, two phase commit is used in a situation where having half the state would be harmful. With RSVP, it is not clear that there is any damage done by having only part of the state estalbished (RSVP is designed to be quite resilient in the face of state loss.) Also, two-phase commit is particularly relevant when it is difficult to roll-back the activity after completion. Typically, such problems occur due to interaction with outside observers using the result of the action before it can be unwound. That does not appear to be an issue in the RSVP example. I expect that transaction support over more than a single message, with explicit commit / abort indications, is probably a good idea. But it would be easier to tell if we had a better example. Yours, Joel M. Halpern At 07:12 AM 6/26/2004 -0400, Jamal Hadi Salim wrote: >Attached is some text that is missing from the draft that now that you >ask it makes sense to put into section 3.3.3.1 >The diagrams dont show more than one one config operation since the >focus is on the 2pc. If you think it would help to show multiple config >operations let us know. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 11:12:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22395 for ; Sun, 27 Jun 2004 11:12:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BebKF-00047T-EI for forces-archive@ietf.org; Sun, 27 Jun 2004 11:12:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BebJK-0003wt-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 11:11:14 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BebIv-0003m6-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 11:10:49 -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.00DFA0B0@cherry.ease.lsoft.com>; 27 Jun 2004 11:10:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23353264 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 11:10:47 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 11:09:56 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062708090104:70347 ; Sun, 27 Jun 2004 08:09:01 -0700 References: <5.1.0.14.0.20040626130413.02385220@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 08:09:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 08:09:08 AM, Serialize complete at 06/27/2004 08:09:08 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1088348986.1040.80.camel@jzny.localdomain> Date: Sun, 27 Jun 2004 11:09:47 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040626130413.02385220@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Sat, 2004-06-26 at 13:09, Joel M. Halpern wrote: [..] > I expect that transaction support over more than a single message, with > explicit commit / abort indications, is probably a good idea. But it would > be easier to tell if we had a better example. > Joel, The mention of QoS and RSVP weakens that text and may even be a little misleading. Would the following scenario help as a good example? Consider a V4 forwarding decision that happens on ingress of FE1 for a packet coming into port A (of FE1). The lookup decision is to egress on FE2 port B. This is a very common setup (with FEs interconnected via some swithc fabric). Each FEx keeps a local V4 forwarding + nexthop details. In such a case both FE1 and FE2 need to sync i.e have identical details on where the nexthop is - which is achieved by having an atomic update of their respective LFB tables. In other words, should FE1 be pointing to anything else other than FE2 port B for the egress port (as shown in above example), then chaos would ensue. I could draw a diagram to illustrate it if the example doesnt make sense. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 11:43:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23851 for ; Sun, 27 Jun 2004 11:43:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeboI-0002JQ-1g for forces-archive@ietf.org; Sun, 27 Jun 2004 11:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BebnN-00028g-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 11:42:17 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bebn0-0001xX-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 11:41:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00DFA14F@cherry.ease.lsoft.com>; 27 Jun 2004 11:41:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23354794 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 11:41:52 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 11:41:23 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7117748; Sun, 27 Jun 2004 11:41:22 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040626130413.02385220@localhost> <5.1.0.14.0.20040626130413.02385220@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040627112606.023b3360@localhost> Date: Sun, 27 Jun 2004 11:41:09 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1088348986.1040.80.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 It might be possible to elaborate the forwarding table case. The difficulty is that even here, one can easily see a way around the ACID requirement. Suppose that the example were elaborated: Suppose that the CE wishes to install a new forwarding path for destination D through FE2. Given that FE1 has a working forwarding path for destination D, the CE wants to ensure that the new path is not used by FE1 unless the install is successful in FE2 as well. However, the reader may realize that this could have been solved without ACID, just by establishing the FE2 state before the FE1 state. ACID tends to apply when there are interactions with other activities. Either with other control activiites, or effects on the data path that can not be cleanly applied in order. The most common cases I have seen are situations where dtwo objects have to be created / updated together because they refer to each other. Let me try another example. Suppose one were modifying some traffic treatment using a non-work conserving scheduler. You start by creating a new queue, and by creating a new classify entry, which still points to the existing treatment. Then one goes to create the non-work conserving handling. As soon as the CE creates the scheduling entry, there is an effect on other traffic behavior even if there is nothing in the queue feeding this new entry. At the same time, as soon as the CE adjusts the port selection of the classifier, traffic will be diverted to the queue. If either action occurs without the other, undesired results occur. Thus, one wants ACID at least with a transaction on an FE. And of course the two pieces could have been in different FEs. I believe this is what was behind the selection of QoS / RSVP as an example. But we need the elaboration to explain why it matters. (Admittedly, non-work-conserving schedulers are not common. But they do occur. And the real point is to show the potential for interaction that can not be safely serialized.) Yours, Joel At 11:09 AM 6/27/2004 -0400, Jamal Hadi Salim wrote: >On Sat, 2004-06-26 at 13:09, Joel M. Halpern wrote: >[..] > > I expect that transaction support over more than a single message, with > > explicit commit / abort indications, is probably a good idea. But it would > > be easier to tell if we had a better example. > > > >Joel, > >The mention of QoS and RSVP weakens that text and may even >be a little misleading. > >Would the following scenario help as a good example? > >Consider a V4 forwarding decision that happens on ingress of FE1 for a >packet coming into port A (of FE1). The lookup decision is to egress on >FE2 port B. This is a very common setup (with FEs interconnected via >some swithc fabric). > >Each FEx keeps a local V4 forwarding + nexthop details. In such a case >both FE1 and FE2 need to sync i.e have identical details on >where the nexthop is - which is achieved by having an atomic update of >their respective LFB tables. In other words, should FE1 be pointing to >anything else other than FE2 port B for the egress port (as shown in >above example), then chaos would ensue. > >I could draw a diagram to illustrate it if the example doesnt make >sense. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 15:08:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01886 for ; Sun, 27 Jun 2004 15:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bef0l-0002D0-E2 for forces-archive@ietf.org; Sun, 27 Jun 2004 15:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Beezn-00021f-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 15:07:20 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Beeyq-0001qo-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 15:06: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 <2.00DFA388@cherry.ease.lsoft.com>; 27 Jun 2004 15:06:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23365943 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 15:06:13 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 15:05:29 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062712044013:70494 ; Sun, 27 Jun 2004 12:04:40 -0700 References: <5.1.0.14.0.20040626130413.02385220@localhost> <5.1.0.14.0.20040626130413.02385220@localhost> <5.1.0.14.0.20040627112606.023b3360@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 12:04:40 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 12:04:42 PM, Serialize complete at 06/27/2004 12:04:42 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1088363126.12662.61.camel@jzny.localdomain> Date: Sun, 27 Jun 2004 15:05:26 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040627112606.023b3360@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On Sun, 2004-06-27 at 11:41, Joel M. Halpern wrote: > It might be possible to elaborate the forwarding table case. > The difficulty is that even here, one can easily see a way around the ACID > requirement. > > Suppose that the example were elaborated: > Suppose that the CE wishes to install a new forwarding path for destination > D through FE2. Given that FE1 has a working forwarding path for > destination D, the CE wants to ensure that the new path is not used by FE1 > unless the install is successful in FE2 as well. > > However, the reader may realize that this could have been solved without > ACID, just by establishing the FE2 state before the FE1 state. Assuming the path to destination D on packets coming into FE1 was pointing to say FE20 port E - there is a possibility of an ambiguity. I.e you have a window of time where packets coming in via FE1 will continue going through FE20 port E while packets coming into FE2 to destination D now go through the (new) correct path. Unless such races are tolerable - which is a tradeoff if the ambiguities exist in limited timescales or a CE policy intent. > ACID tends to apply when there are interactions with other activities. > Either with other control activiites, or effects on the data path that > can not be cleanly applied in order. nod. > The most common cases I have seen are situations where dtwo objects have to > be created / updated together because they refer to each other. Refer to each other or would the case of one refer to other also be a sufficient condition? > Let me try another example. > Suppose one were modifying some traffic treatment using a non-work > conserving scheduler. > > You start by creating a new queue, and by creating a new classify entry, > which still points to the existing treatment. > Then one goes to create the non-work conserving handling. As soon as the > CE creates the scheduling entry, there is an effect on other traffic > behavior even if there is nothing in the queue feeding this new entry. Good example. You picked an example that requires a resource to be reserved/preallocated --> implication is that such a resource is denied to other queues once reserved. At least thats what i think you are getting to. The first phase of the 2pc is infact a check for availability of a resource. It asks the question whether a transaction can be achieved. Show stoppers to a transaction could be lack of resources, conflicts, etc. At the end of a the first phase, no resource is preallocated/reserved AFAIK; of course how long such a guarantee is kept without reservation is probably implementation specific. Typically, assuming an intelligent CE, there would be no other transaction requesting for the same resource from the CE until either the transaction is aborted or timed out. Back to the forwarding example: Could you say that adjusting tables infact falls under the same category? > At the same time, as soon as the CE adjusts the port selection of the > classifier, traffic will be diverted to the queue. > If either action occurs without the other, undesired results occur. > Thus, one wants ACID at least with a transaction on an FE. > And of course the two pieces could have been in different FEs. True. > I believe this is what was behind the selection of QoS / RSVP as an > example. But we need the elaboration to explain why it matters. > (Admittedly, non-work-conserving schedulers are not common. But they do > occur. And the real point is to show the potential for interaction that > can not be safely serialized.) By definition a transaction (which could be a series of operations) is atomic. I believe anything that is affecting state of the NEs distributed computation needs to be a single transaction (and by definition atomic) across the NE. Thats why i brought the forwarding example because the next hop selection may happen on one FE and the L2 header rewrite may happen on the other. Same concept applies to things that affect a state within a FE such as the work conserving example you gave. So maybe a good way is to fit what goes together is by describing transaction which could be made of a series of operations (refer to header semantics and the config message). Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 20:33:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14826 for ; Sun, 27 Jun 2004 20:33:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bek5X-00066n-8U for forces-archive@ietf.org; Sun, 27 Jun 2004 20:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bek4e-0005wn-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 20:32:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bek3y-0005mT-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 20:31: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 <16.00DFA742@cherry.ease.lsoft.com>; 27 Jun 2004 20:31:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23382843 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 20:31:57 -0400 Approved-By: Aaudu2000@AOL.COM Received: from 205.188.144.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 20:18:11 -0400 Received: from Aaudu2000@aol.com by imo-d21.mx.aol.com (mail_out_v37_r2.6.) id a.1c9.1b20551a (18251) for ; Sun, 27 Jun 2004 20:18:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1088381884" X-Mailer: 9.0 for Windows sub 5032 Message-ID: <1c9.1b20551a.2e10bdbc@aol.com> Date: Sun, 27 Jun 2004 20:18:04 EDT Reply-To: Aaudu2000@AOL.COM Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 -------------------------------1088381884 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi All, I was able to get to the draft-fpteam-forces-protocol-00.txt draft this past weekend. However, I am only half way through. These are my comments: 1) General comments: I like the preambles in the early sections. However, I am not sure if it is necessary to draft real-estate discussing how the design team was created in section 1. Introduction. I think we can remove the following text from the document: .............................................................................. ........................................... The team was created by the WG chairs of the ForCES group in consultation with the Routing Area ADs after the authors of the various qualifying drafts, i.e. drafts submitted by the deadline which met the essential requirements outline in [RFC3654], reached consensus on being able to develop a common protocol proposal. While this draft has rough consensus within the design team, there are still issues that need to be resolved. These issues will continue to be discussed within the protocol design team and hopefully, on the general ForCES WG email list. The protocol design team was defined by the WG chairs to be composed of seven participants includes two representatives from each of the 3 protocol proposals and 1 participant who had not contributed to the proposed protocols. .............................................................................. ............................................. 2) Section 3.3.2 FE Protocol Object It is not clear to me what the use or intent of the protocol object concept. It borders a lot on implementation detail at least in my mind. 3) Section 3.3.3 Scaling by Concurrency The concept advocated here seems to be a complex one. How about relying on a simple request/response/ACK based system? This basically adapts to the underlining network's speed adaptively. "The sooner I get an ack/response to my previous request, the sonner I can make another request",..and the quicker the job will be done. I believe this is the essence of flow-control. 4) Section 4. TML Requirements: I believe the TML should be as transparent to the CE and FE as much as possible. As such I am not in agreement with the following as stated in the draft: .............................................................................. .................. 2. Security TML provides security services to the ForCES PL. TML layer should support following security services and describe how they are achieved. * Endpoint authentication of FE and CE. * Message Authentication * Confidentiality service .............................................................................. ............................. Security is an end-to-end problem. Having to go through an intermediary will necessitate that entity to have a security handshake with both endpoints trying to to cumminicated. This essentially doubles the handshaking that needs to take place. For example A <-------->B<-------------->C requires B to make two handshakes (one each with A and C, before A and C can communicate. But if we have A<-------------->C, with B being transparent, then only one handshake is needed, and the authtentication process becomes much quicker. Also, keeping TML transparent as much as possible makes TML much simpler. Else, it has to be made a stateful entity, when it really doesn't need to be. In short, TML should be viewed as a transport medium. It should get involved in stateful matters only when absolutely necessary (for example when providing reliability over a non-reliable medium). 5) Section 5. Common Header The following seems to suggest that CEs and FEs are exposed to the internals of the addressing scheme. I thought the TML was supposed to abstract this from the end users,..no? .............................................................................. ............. C. Special IDs are reserved for FE broadcast, CE broadcast, and NE broadcast. D. Subgroups of FEs belonging, for instance, to the same VPN, may be assigned a multicast ID. Likewise, subgroups of CEs that act, for instance, in a back-up mode may be assigned a multicast ID. These FEs and CE multicast IDs are chosen in a distinct portion of the ID address space. Such a multicast ID may comprise FEs, CEs, or a mix of both. .............................................................................. .................................... In the same section, we find the folloing: .............................................................................. .................................... Flags(32 bits): Identified so far: o ACK indicator(2 bit) The description for using the two bits is: 'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'ACKAll' (11) o Priority (3 bits) unknown/undecided. o Throttle flag? o batch (2 bits) o Atomicity (1 or 2 bits) .............................................................................. ....................................... To me this makes message handling way too complex. It is just nightmarish to think of all those flags to be set/tracked for all messages. Utter wast of CPU cycles. This will lead to an inefficient and sluggish protocol in my view. 6) Section 6.1.3 Association Teardown Message I cringed when I read the following in the draft: .............................................................................. ... Message Header: The Message Type in the header is set MessageType= 'Asso. Teardown'(TBD?). The ACK flag in the header is always ignored, because the teardown message will never expect to get any response from the message receiver. .............................................................................. ..................... Now, a protocol designed this way will NEVER work. The ACK is very much needed when tearing down an association. Consider the following scenario: +------------------FE1 CE ------------| +------------------FE2 CE is the contol active control element with FE1 the active FE and FE2 the standby unit. 1) FE1 is now sent a command to go down (by craft person via management interface). 2) FE1 sends association-teardown request to CE. 3) CE gets this important information and quickly activates FE2 to assume FE1's responsibilities. 4) FE2 acknowledges this activation to CE. 5) CE can then acknowledge FE1's request to leave or go down. 6) FE1 leaves, and FE2 assumes FE1's traffic duties. Hurray!,.. NO TRAFFIC OUTAGE. Now, if we take away steps 3,4, and 5, then FE1 can just leave at will, and the result WILL BE AN OUTAGE. At least until an alternative FE becomes the active one. This is not a 5-9's reliability compliant protocol. That is how far I have read,..and I'll post more later. Regards, Alex. -------------------------------1088381884 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I was able to get to the draft-fpteam-forces-protocol-00.txt draft this= past weekend. However,
I am only half way through. These are my comments:
 
1) General comments:  I like the preambles in the early sections.=20= However, I am not sure
    if it is necessary to draft real-estate discussing h= ow the design team was created in
    section 1. Introduction. I think we can remove the f= ollowing text from the document:
 
.......................................................................= ..................................................
   The team was created by the WG chairs of the ForCES g= roup in
   consultation with the Routing Area ADs after the aut= hors of the
   various qualifying drafts, i.e.  drafts sub= mitted by the deadline
   which met the essential requirements=20= outline in [RFC3654], reached
   consensus on being able to dev= elop a common protocol proposal.
 
   While this draft has rough consensus within the design tea= m, there
   are still issues that need to be resolved.  Th= ese issues will
   continue to be discussed within the protocol= design team and
   hopefully, on the general ForCES WG email l= ist.
 
   The protocol design team was defined by the WG chairs to b= e composed
   of seven participants includes two representative= s from each of the 3
   protocol proposals and 1 participant wh= o had not contributed to the
   proposed protocols.
........= ............................................................................= .......................................
 
2) Section 3.3.2 FE Protocol Object
  It is not clear to me what the use or intent of the protocol obj= ect concept.  It borders
  a lot on implementation detail at least in my mind. 
 
3) Section 3.3.3 Scaling by Concurrency
  The concept advocated here seems to be a complex one.  How=20= about relying on a
  simple  request/response/ACK based system? This basically a= dapts to the underlining
   network's speed adaptively. "The sooner I get an= ack/response to my previous request,
   the sonner I can make another request",..and the quicker t= he job will be done. I believe
   this is the essence of flow-control.
 
4) Section 4. TML Requirements:
  I believe the TML should be as transparent to the CE and FE as m= uch as possible.
  As such I am not in agreement with the following as st= ated in the draft:
.......................................................................= .........................
     2.  Security
     =   TML provides security services to the ForCES PL.  TML layer
&= nbsp;      should support following security servic= es and describe how they
       are achieve= d.
       *  Endpoint authentication o= f FE and CE.
       *  Message Authent= ication
       *  Confidentiality serv= ice
.......................................................................= ....................................
    
Security is an end-to-end problem.  Having to go through an interm= ediary will necessitate
that entity to have a security handshake with both endpoints trying to=20= to cumminicated.
This essentially doubles the handshaking that needs to take place.
For example A <-------->B<-------------->C   requ= ires B to make two handshakes (one each
with A and C, before A and C can communicate.  But if  we hav= e  A<-------------->C, with
B being transparent, then only one handshake is needed, and the authten= tication process
becomes much quicker.
 
Also, keeping TML transparent as much as possible makes TML much simple= r.  Else,
it has to be made a stateful entity, when it really doesn't need to be.= In short, TML should
be viewed as a transport medium. It should get involved in stateful mat= ters only when
absolutely necessary (for example when providing reliability over a non= -reliable medium).
 
 
5) Section 5. Common Header
The following seems to suggest that CEs and FEs are exposed to the inte= rnals of the
 addressing scheme.  I thought the TML was supposed to abstra= ct this from the end
 users,..no?
.......................................................................= ....................
 
      C.  Special IDs are reserved for FE= broadcast, CE broadcast, and
       &= nbsp;  NE broadcast.
      D.  Subgrou= ps of FEs belonging, for instance, to the same VPN, may
   = ;       be assigned a multicast ID.  Like= wise, subgroups of CEs that
       &nb= sp;  act, for instance, in a back-up mode may be assigned a
 &n= bsp;        multicast ID.  These FEs= and CE multicast IDs are chosen in a
      = ;    distinct portion of the ID address space.  Such a m= ulticast ID
          may co= mprise FEs, CEs, or a mix of both.
......................................= ............................................................................=
 
In the same section, we find the folloing:
 
.......................................................................= ...........................................
   Flags(32 bits):
   Identified so far:
&nbs= p;  o  ACK indicator(2 bit)
      The=20= description for using the two bits is:
      'No= ACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'ACKAll'
  =     (11)
   o  Priority (3 bits)
 &= nbsp;    unknown/undecided.
   o  Throttle=20= flag?
   o  batch (2 bits)
   o  Atomici= ty (1 or 2 bits)
........................................................= .............................................................
To me this makes message handling way too complex. It is just nightmari= sh to think
of all those flags to be set/tracked for all messages. Utter wast of CP= U cycles. This
will lead to an inefficient and sluggish protocol in my view.
 
 
6) Section 6.1.3 Association Teardown Message
 
I cringed when I read the following in the draft:
.......................................................................= ..........
   Message Header:
   The Message Type in the he= ader is set MessageType=3D 'Asso.
   Teardown'(TBD?).  The= ACK flag in the header is always ignored,
   because the teard= own message will never expect to get any response
   from the m= essage receiver.
........................................................= ...........................................
Now, a protocol designed this way will NEVER work.  The ACK i= s very much needed when
tearing down an association.  Consider the following scenario= :
 
            = ;            &nb= sp;        +------------------FE1
            = ;    CE ------------|
            = ;            &nb= sp;        +------------------FE2
 
CE is the contol active control element with FE1 the active FE and = ;FE2 the standby unit.
 
    1) FE1 is now sent a command to go down (b= y craft person via management interface).
    2) FE1 sends association-teardown request to CE= .
    3) CE gets this important information and quick= ly activates FE2 to assume FE1's
         responsibilities.=
    4) FE2 acknowledges this activation to CE.
    5) CE can then acknowledge FE1's request to leave or= go down.
    6) FE1 leaves, and FE2 assumes FE1's traffic duties.=   Hurray!,.. NO TRAFFIC OUTAGE.
 
Now, if we take away steps 3,4, and 5, then FE1 can just leave at will,= and the result WILL
BE AN OUTAGE. At least until an alternative FE becomes t= he active one.  This is not
a 5-9's reliability compliant protocol.
 
That is how far I have read,..and I'll post more later.
 
 
Regards,
Alex.
 
 
-------------------------------1088381884-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 20:56:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15768 for ; Sun, 27 Jun 2004 20:56:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BekRp-0002eB-20 for forces-archive@ietf.org; Sun, 27 Jun 2004 20:56:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BekQr-0002TW-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 20:55:38 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BekPu-0002Ik-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 20:54:38 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00DFA661@cherry.ease.lsoft.com>; 27 Jun 2004 20:54:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23384096 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 20:54:36 -0400 Approved-By: Aaudu2000@AOL.COM Received: from 205.188.157.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 20:31:02 -0400 Received: from Aaudu2000@aol.com by imo-d04.mx.aol.com (mail_out_v37_r2.6.) id a.1e2.241a2d11 (18251) for ; Sun, 27 Jun 2004 20:30:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1088382658" X-Mailer: 9.0 for Windows sub 5032 Message-ID: <1e2.241a2d11.2e10c0c2@aol.com> Date: Sun, 27 Jun 2004 20:30:58 EDT Reply-To: Aaudu2000@AOL.COM Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES Protocol process update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 -------------------------------1088382658 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi All, I have sent out the draft-audu-forces-pl-00.txt document to the IETF internet draft editor. In the interrim, please get a copy from http://briefcase.yahoo.com/lexy50002002 Then click on "drafts" then click on draft-audu-forces-pl-00.txt for a copy. Enjoy, Alex. In a message dated 6/10/2004 9:21:46 AM Central Standard Time, david.putzolu@INTEL.COM writes: I have also been informed that the author of the original FACT proposal, Alex Audu, will be submitting a separate proposal based on FACT. In order to make timely progress I will be asking the working group to review the proposals and, if appropriate, accept one as the official working group proposal by the meeting in San Diego in early August. Cheers, David Putzolu -------------------------------1088382658 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I have sent out the draft-audu-forces-pl-00.txt  document to the I= ETF internet draft
editor.  In the interrim, please get a copy from
 
Then click on "drafts"  then click on draft-audu-forces-pl-00.txt&= nbsp; for a copy.
 
Enjoy,
Alex.
 
In a message dated 6/10/2004 9:21:46 AM Central Standard Time, david.pu= tzolu@INTEL.COM writes:
I have also been informed that the author of t= he original
FACT proposal, Alex Audu, will be submitting a separate
pr= oposal based on FACT.

In order to make timely progress I will be aski= ng the
working group to review the proposals and, if appropriate,
acce= pt one as the official working group proposal by the
meeting in San Dieg= o in early August.

Cheers,
David Putzolu
-------------------------------1088382658-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 27 23:46:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21650 for ; Sun, 27 Jun 2004 23:46:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ben6f-0001UR-6h for forces-archive@ietf.org; Sun, 27 Jun 2004 23:46:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ben5j-0001IE-00 for forces-archive@ietf.org; Sun, 27 Jun 2004 23:46:00 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Ben53-00016I-00 for forces-archive@IETF.ORG; Sun, 27 Jun 2004 23:45:17 -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.00DFAB15@cherry.ease.lsoft.com>; 27 Jun 2004 23:45:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23394711 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Jun 2004 23:45:14 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jun 2004 23:43:46 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062720425632:70859 ; Sun, 27 Jun 2004 20:42:56 -0700 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 08:42:57 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/27/2004 08:42:58 PM, Serialize complete at 06/27/2004 08:42:58 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1088394223.12878.104.camel@jzny.localdomain> Date: Sun, 27 Jun 2004 23:43:43 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: [Fwd: Re: First draft of ForCES protocol from the protocol design team] Comments: cc: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit After some discussion with Joel we have reached the follwoing conclusion which needs to be captured. 1) By virtue of the way Forces protocol is going, the CE will be aware of all resources and would/should not issue configs which it believes will fail because of lack of resources. As an example it will not issue a route add when theres no space in the table. This is equivalent to having pieces of the the 2pc actually done on the CE itself. 2) The value of a 2pc is still there in situations where two objects have to be created / updated together because they refer to each other. The example provided by Joel on the non-work conserving scheduler (which by virtue of stealing say bandwidth would deny other classes of said bandwidth) serves here. I think we probably need an even stronger example; i cant think of one at the moment. 3) multi-manager issue which was discussed in the thread on the CE scope needs the mechanism. But if my undertsanding is right we are saying thats out of scope. Did i miss something Joel? cheers, jamal -----Forwarded Message----- From: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: First draft of ForCES protocol from the protocol design team Date: 27 Jun 2004 15:05:26 -0400 On Sun, 2004-06-27 at 11:41, Joel M. Halpern wrote: > It might be possible to elaborate the forwarding table case. > The difficulty is that even here, one can easily see a way around the ACID > requirement. > > Suppose that the example were elaborated: > Suppose that the CE wishes to install a new forwarding path for destination > D through FE2. Given that FE1 has a working forwarding path for > destination D, the CE wants to ensure that the new path is not used by FE1 > unless the install is successful in FE2 as well. > > However, the reader may realize that this could have been solved without > ACID, just by establishing the FE2 state before the FE1 state. Assuming the path to destination D on packets coming into FE1 was pointing to say FE20 port E - there is a possibility of an ambiguity. I.e you have a window of time where packets coming in via FE1 will continue going through FE20 port E while packets coming into FE2 to destination D now go through the (new) correct path. Unless such races are tolerable - which is a tradeoff if the ambiguities exist in limited timescales or a CE policy intent. > ACID tends to apply when there are interactions with other activities. > Either with other control activiites, or effects on the data path that > can not be cleanly applied in order. nod. > The most common cases I have seen are situations where dtwo objects have to > be created / updated together because they refer to each other. Refer to each other or would the case of one refer to other also be a sufficient condition? > Let me try another example. > Suppose one were modifying some traffic treatment using a non-work > conserving scheduler. > > You start by creating a new queue, and by creating a new classify entry, > which still points to the existing treatment. > Then one goes to create the non-work conserving handling. As soon as the > CE creates the scheduling entry, there is an effect on other traffic > behavior even if there is nothing in the queue feeding this new entry. Good example. You picked an example that requires a resource to be reserved/preallocated --> implication is that such a resource is denied to other queues once reserved. At least thats what i think you are getting to. The first phase of the 2pc is infact a check for availability of a resource. It asks the question whether a transaction can be achieved. Show stoppers to a transaction could be lack of resources, conflicts, etc. At the end of a the first phase, no resource is preallocated/reserved AFAIK; of course how long such a guarantee is kept without reservation is probably implementation specific. Typically, assuming an intelligent CE, there would be no other transaction requesting for the same resource from the CE until either the transaction is aborted or timed out. Back to the forwarding example: Could you say that adjusting tables infact falls under the same category? > At the same time, as soon as the CE adjusts the port selection of the > classifier, traffic will be diverted to the queue. > If either action occurs without the other, undesired results occur. > Thus, one wants ACID at least with a transaction on an FE. > And of course the two pieces could have been in different FEs. True. > I believe this is what was behind the selection of QoS / RSVP as an > example. But we need the elaboration to explain why it matters. > (Admittedly, non-work-conserving schedulers are not common. But they do > occur. And the real point is to show the potential for interaction that > can not be safely serialized.) By definition a transaction (which could be a series of operations) is atomic. I believe anything that is affecting state of the NEs distributed computation needs to be a single transaction (and by definition atomic) across the NE. Thats why i brought the forwarding example because the next hop selection may happen on one FE and the L2 header rewrite may happen on the other. Same concept applies to things that affect a state within a FE such as the work conserving example you gave. So maybe a good way is to fit what goes together is by describing transaction which could be made of a series of operations (refer to header semantics and the config message). Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 10:29:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07977 for ; Mon, 28 Jun 2004 10:29:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bex8A-0006ks-9n for forces-archive@ietf.org; Mon, 28 Jun 2004 10:29:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bex7B-0006Vi-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 10:28:10 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bex67-00061s-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 10: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 <9.00DFB671@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 10:27:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23510730 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 10:27:02 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 10:26:20 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7121070 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 10:26:19 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.0.20040628102122.023c56e8@localhost> Date: Mon, 28 Jun 2004 10:26:08 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [Fwd: Re: First draft of ForCES protocol from the protocol design team] To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1088394223.12878.104.camel@jzny.localdomain> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I might rephrase this slightly, although I think the point is correct. It is not that the CE knows how much resource there is. It might not know. But it does know what requests it has outstanding, and what things it might decide to roll back. Basically, if the interaction between multiple requests are all from the same CE, and if partial establishment does not affect traffic, then the CE can maange the states itslef, including any interaction between multiple requests it chooses to issue simultaneously. However, I do believe that there are cases, like the example of non-work conserving queues (which I removed for brevity) which can have effects and therefore motivate inclusion of ACID capabilities / logic. Yours, Joel At 11:43 PM 6/27/2004 -0400, Jamal Hadi Salim wrote: >1) By virtue of the way Forces protocol is going, the CE >will be aware of all resources and would/should not issue >configs which it believes will fail because of lack of resources. >As an example it will not issue a route add when theres no space in >the table. >This is equivalent to having pieces of the the 2pc actually done on the >CE itself. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 10:56:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09482 for ; Mon, 28 Jun 2004 10:56:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BexYK-0005tZ-NH for forces-archive@ietf.org; Mon, 28 Jun 2004 10:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BexXW-0005cw-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 10:55:24 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BexWE-00059y-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 10:54: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.00DFB888@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 10:53:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23516307 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 10:53:55 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 10:49:31 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5SEnTGP097588; Mon, 28 Jun 2004 14:49:29 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5SEnSoI176184; Mon, 28 Jun 2004 16:49:29 +0200 Received: from zurich.ibm.com (dhcp69-53.zurich.ibm.com [9.4.69.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA50914; Mon, 28 Jun 2004 16:49:28 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1c9.1b20551a.2e10bdbc@aol.com> Content-Type: multipart/alternative; boundary="------------030100030106060901040403" Message-ID: <40E02FF7.3040401@zurich.ibm.com> Date: Mon, 28 Jun 2004 16:49:27 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: Aaudu2000@AOL.COM To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1c9.1b20551a.2e10bdbc@aol.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030100030106060901040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id i5SEnTGP097588 Content-Transfer-Encoding: quoted-printable Alex, I assume that you have now finished reading the draft. Do you still have=20 issues with the FE Protocol Object or did it get clearer in the meantime = ? Regarding your question 5) on the transparency of the TML wrt broadcast=20 and multicast IDs: the TML takes care of mapping those IDs to the right=20 IP addresses, connections, etc. So the transparency is maintained at the=20 PL layer. This is similar to sets as previously proposed in FACT. Regards, -Robert Alex Audu wrote: > Hi All, > =20 > I was able to get to the draft-fpteam-forces-protocol-00.txt draft=20 > this past weekend. However, > I am only half way through. These are my comments: > =20 > 1) General comments: I like the preambles in the early sections.=20 > However, I am not sure > if it is necessary to draft real-estate discussing how the design=20 > team was created in > section 1. Introduction. I think we can remove the following text=20 > from the document: > =20 > .......................................................................= .................................................. > The team was created by the WG chairs of the ForCES group in > consultation with the Routing Area ADs after the authors of the > various qualifying drafts, i.e. drafts submitted by the deadline > which met the essential requirements outline in [RFC3654], reached > consensus on being able to develop a common protocol proposal. > =20 > While this draft has rough consensus within the design team, there > are still issues that need to be resolved. These issues will > continue to be discussed within the protocol design team and > hopefully, on the general ForCES WG email list. > =20 > The protocol design team was defined by the WG chairs to be composed > of seven participants includes two representatives from each of the = 3 > protocol proposals and 1 participant who had not contributed to the > proposed protocols. > .......................................................................= .................................................... > =20 > 2) Section 3.3.2 FE Protocol Object > It is not clear to me what the use or intent of the protocol object=20 > concept. It borders > a lot on implementation detail at least in my mind.=20 > =20 > 3) Section 3.3.3 Scaling by Concurrency > The concept advocated here seems to be a complex one. How about=20 > relying on a > simple request/response/ACK based system? This basically adapts to=20 > the underlining > network's speed adaptively. "The sooner I get an ack/response to my=20 > previous request, > the sonner I can make another request",..and the quicker the job=20 > will be done. I believe > this is the essence of flow-control. > =20 > 4) Section 4. TML Requirements: > I believe the TML should be as transparent to the CE and FE as much=20 > as possible. > As such I am not in agreement with the following as stated in the dra= ft: > .......................................................................= ......................... > 2. Security > TML provides security services to the ForCES PL. TML layer > should support following security services and describe how they > are achieved. > * Endpoint authentication of FE and CE. > * Message Authentication > * Confidentiality service > .......................................................................= .................................... > =20 > Security is an end-to-end problem. Having to go through an=20 > intermediary will necessitate > that entity to have a security handshake with both endpoints trying to=20 > to cumminicated. > This essentially doubles the handshaking that needs to take place. > For example A <-------->B<-------------->C requires B to make two=20 > handshakes (one each > with A and C, before A and C can communicate. But if we have =20 > A<-------------->C, with > B being transparent, then only one handshake is needed, and the=20 > authtentication process > becomes much quicker. > =20 > Also, keeping TML transparent as much as possible makes TML much=20 > simpler. Else, > it has to be made a stateful entity, when it really doesn't need to=20 > be. In short, TML should > be viewed as a transport medium. It should get involved in stateful=20 > matters only when > absolutely necessary (for example when providing reliability over a=20 > non-reliable medium). > =20 > =20 > 5) Section 5. Common Header > The following seems to suggest that CEs and FEs are exposed to the=20 > internals of the > addressing scheme. I thought the TML was supposed to abstract this=20 > from the end > users,..no? > .......................................................................= .................... > =20 > C. Special IDs are reserved for FE broadcast, CE broadcast, and > NE broadcast. > D. Subgroups of FEs belonging, for instance, to the same VPN, ma= y > be assigned a multicast ID. Likewise, subgroups of CEs that > act, for instance, in a back-up mode may be assigned a > multicast ID. These FEs and CE multicast IDs are chosen in a > distinct portion of the ID address space. Such a multicast I= D > may comprise FEs, CEs, or a mix of both. > .......................................................................= ........................................... > =20 > In the same section, we find the folloing: > =20 > .......................................................................= ........................................... > Flags(32 bits): > Identified so far: > o ACK indicator(2 bit) > The description for using the two bits is: > 'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'ACKAll' > (11) > o Priority (3 bits) > unknown/undecided. > o Throttle flag? > o batch (2 bits) > o Atomicity (1 or 2 bits) > .......................................................................= .............................................. > To me this makes message handling way too complex. It is just=20 > nightmarish to think > of all those flags to be set/tracked for all messages. Utter wast of=20 > CPU cycles. This > will lead to an inefficient and sluggish protocol in my view. > =20 > =20 > 6) Section 6.1.3 Association Teardown Message > =20 > I cringed when I read the following in the draft: > .......................................................................= .......... > Message Header: > The Message Type in the header is set MessageType=3D 'Asso. > Teardown'(TBD?). The ACK flag in the header is always ignored, > because the teardown message will never expect to get any response > from the message receiver. > .......................................................................= ............................ > Now, a protocol designed this way will NEVER work. The ACK is very=20 > much needed when > tearing down an association. Consider the following scenario: > =20 > +------------------FE1 > CE ------------| > +------------------FE2 > =20 > CE is the contol active control element with FE1 the active FE and FE2=20 > the standby unit. > =20 > 1) FE1 is now sent a command to go down (by craft person via=20 > management interface). > 2) FE1 sends association-teardown request to CE. > 3) CE gets this important information and quickly activates FE2 to=20 > assume FE1's > responsibilities. > 4) FE2 acknowledges this activation to CE. > 5) CE can then acknowledge FE1's request to leave or go down. > 6) FE1 leaves, and FE2 assumes FE1's traffic duties. Hurray!,..=20 > NO TRAFFIC OUTAGE. > =20 > Now, if we take away steps 3,4, and 5, then FE1 can just leave at=20 > will, and the result WILL > BE AN OUTAGE. At least until an alternative FE becomes the active one.=20 > This is not > a 5-9's reliability compliant protocol. > =20 > That is how far I have read,..and I'll post more later. > =20 > =20 > Regards, > Alex. > =20 > =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------030100030106060901040403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex,
I assume that you have now finished reading the draft. Do you still have issues with the FE Protocol Object or did it get clearer in the meantime ?
Regarding your question 5) on the transparency of the TML wrt broadcast and multicast IDs: the TML takes care of mapping those IDs to the right IP addresses, connections, etc. So the transparency is maintained at the PL layer. This is similar to sets as previously proposed in FACT.

Regards,
-Robert

Alex Audu wrote:
Hi All,
 
I was able to get to the draft-fpteam-forces-protocol-00.txt draft this past weekend. However,
I am only half way through. These are my comments:
 
1) General comments:  I like the preambles in the early sections. However, I am not sure
    if it is necessary to draft real-estate discussing how the design team was created in
    section 1. Introduction. I think we can remove the following text from the document:
 
.........................................................................................................................
   The team was created by the WG chairs of the ForCES group in
   consultation with the Routing Area ADs after the authors of the
   various qualifying drafts, i.e.  drafts submitted by the deadline
   which met the essential requirements outline in [RFC3654], reached
   consensus on being able to develop a common protocol proposal.
 
   While this draft has rough consensus within the design team, there
   are still issues that need to be resolved.  These issues will
   continue to be discussed within the protocol design team and
   hopefully, on the general ForCES WG email list.
 
   The protocol design team was defined by the WG chairs to be composed
   of seven participants includes two representatives from each of the 3
   protocol proposals and 1 participant who had not contributed to the
   proposed protocols.
...........................................................................................................................
 
2) Section 3.3.2 FE Protocol Object
  It is not clear to me what the use or intent of the protocol object concept.  It borders
  a lot on implementation detail at least in my mind. 
 
3) Section 3.3.3 Scaling by Concurrency
  The concept advocated here seems to be a complex one.  How about relying on a
  simple  request/response/ACK based system? This basically adapts to the underlining
   network's speed adaptively. "The sooner I get an ack/response to my previous request,
   the sonner I can make another request",..and the quicker the job will be done. I believe
   this is the essence of flow-control.
 
4) Section 4. TML Requirements:
  I believe the TML should be as transparent to the CE and FE as much as possible.
  As such I am not in agreement with the following as stated in the draft:
................................................................................................
     2.  Security
       TML provides security services to the ForCES PL.  TML layer
       should support following security services and describe how they
       are achieved.
       *  Endpoint authentication of FE and CE.
       *  Message Authentication
       *  Confidentiality service
...........................................................................................................
    
Security is an end-to-end problem.  Having to go through an intermediary will necessitate
that entity to have a security handshake with both endpoints trying to to cumminicated.
This essentially doubles the handshaking that needs to take place.
For example A <-------->B<-------------->C   requires B to make two handshakes (one each
with A and C, before A and C can communicate.  But if  we have  A<-------------->C, with
B being transparent, then only one handshake is needed, and the authtentication process
becomes much quicker.
 
Also, keeping TML transparent as much as possible makes TML much simpler.  Else,
it has to be made a stateful entity, when it really doesn't need to be. In short, TML should
be viewed as a transport medium. It should get involved in stateful matters only when
absolutely necessary (for example when providing reliability over a non-reliable medium).
 
 
5) Section 5. Common Header
The following seems to suggest that CEs and FEs are exposed to the internals of the
 addressing scheme.  I thought the TML was supposed to abstract this from the end
 users,..no?
...........................................................................................
 
      C.  Special IDs are reserved for FE broadcast, CE broadcast, and
          NE broadcast.
      D.  Subgroups of FEs belonging, for instance, to the same VPN, may
          be assigned a multicast ID.  Likewise, subgroups of CEs that
          act, for instance, in a back-up mode may be assigned a
          multicast ID.  These FEs and CE multicast IDs are chosen in a
          distinct portion of the ID address space.  Such a multicast ID
          may comprise FEs, CEs, or a mix of both.
..................................................................................................................
 
In the same section, we find the folloing:
 
..................................................................................................................
   Flags(32 bits):
   Identified so far:
   o  ACK indicator(2 bit)
      The description for using the two bits is:
      'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'ACKAll'
      (11)
   o  Priority (3 bits)
      unknown/undecided.
   o  Throttle flag?
   o  batch (2 bits)
   o  Atomicity (1 or 2 bits)
.....................................................................................................................
To me this makes message handling way too complex. It is just nightmarish to think
of all those flags to be set/tracked for all messages. Utter wast of CPU cycles. This
will lead to an inefficient and sluggish protocol in my view.
 
 
6) Section 6.1.3 Association Teardown Message
 
I cringed when I read the following in the draft:
.................................................................................
   Message Header:
   The Message Type in the header is set MessageType= 'Asso.
   Teardown'(TBD?).  The ACK flag in the header is always ignored,
   because the teardown message will never expect to get any response
   from the message receiver.
...................................................................................................
Now, a protocol designed this way will NEVER work.  The ACK is very much needed when
tearing down an association.  Consider the following scenario:
 
                                 +------------------FE1
                CE ------------|
                                 +------------------FE2
 
CE is the contol active control element with FE1 the active FE and FE2 the standby unit.
 
    1) FE1 is now sent a command to go down (by craft person via management interface).
    2) FE1 sends association-teardown request to CE.
    3) CE gets this important information and quickly activates FE2 to assume FE1's
         responsibilities.
    4) FE2 acknowledges this activation to CE.
    5) CE can then acknowledge FE1's request to leave or go down.
    6) FE1 leaves, and FE2 assumes FE1's traffic duties.  Hurray!,.. NO TRAFFIC OUTAGE.
 
Now, if we take away steps 3,4, and 5, then FE1 can just leave at will, and the result WILL
BE AN OUTAGE. At least until an alternative FE becomes the active one.  This is not
a 5-9's reliability compliant protocol.
 
That is how far I have read,..and I'll post more later.
 
 
Regards,
Alex.
 
 

--
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
--------------030100030106060901040403-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 11:23:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11172 for ; Mon, 28 Jun 2004 11:23:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bexyh-0005FG-Ut for forces-archive@ietf.org; Mon, 28 Jun 2004 11:23:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bexxx-0004zC-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 11:22:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bexx3-0004iF-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 11:21:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00DFB869@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 11:21:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23519211 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 11:21:43 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 11:11:18 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5SFBIFA111470; Mon, 28 Jun 2004 15:11:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5SFBHoI286762; Mon, 28 Jun 2004 17:11:17 +0200 Received: from zurich.ibm.com (dhcp69-53.zurich.ibm.com [9.4.69.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA52608; Mon, 28 Jun 2004 17:11:17 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040624121631.0247b640@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i5SFBIFA111470 Message-ID: <40E03514.4050307@zurich.ibm.com> Date: Mon, 28 Jun 2004 17:11:16 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040624121631.0247b640@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Joel, Thanks for your comments. See some answers below. Joel M. Halpern wrote: > Some minor comments on the document. > [snip] > > 5) I think that trying to mix LFB selection with the FE / CE=20 > identification > in the last part of bullet G of section 5 is a mistake. This level of > addressing ought to indicate which FEs I want to talk about. If I=20 > need to > be able to indicate a specific subset of LFBs on FE 1 and a distinct=20 > subset > of FE2 while sending both FEs the same message, then we should add > mechanisms to create LFB groupings, and put that group identifier in=20 > an LFB > group TLV. I copied the text of the draft you were refering to below: It is desirable to address multicast and/or broadcast messages to some LFB instances of a given class. For instance, assume FEs FEa and FEb: - FEa has LFBs LFBaX1 and LFBaX2 of class X - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of class X. A broadcast message should be addressable to only LFBs LFBaX1 and LFBbX1 (this can be the case for instance if these two LFBs belong to the same VPN). To achieve this, a VPN ID (3 octets OUI and 4 octets VPN Index) as defined in RFC 2685 should be used within the ForCES message body as a TLV. As an alternative, a particular multicast ID MAY be associated to a given VPN ID through some configuration means. Messages delivered to such a multicast ID MUST only be applied to LFBs belonging to that VPN ID. What you call "LFB grouping TLV" is what is proposed here as the VPN ID=20 TLV. A simple mechanism would be to use the broadcast FE ID and add the VPN=20 ID TLV in the message so that only those FEs that belong to the VPN=20 process the message. Some people might then suggest that the message should be delivered only=20 to those FEs that will process it (to save network bandwidth and CPU=20 cycles, for instance), therefore the proposal to use a multicast ID=20 instead. Note that the VPN ID TLV could remain in the message, if this=20 is what you suggest ? Regards, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 11:36:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12057 for ; Mon, 28 Jun 2004 11:36:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeyBT-00010V-IA for forces-archive@ietf.org; Mon, 28 Jun 2004 11:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeyAX-0000jJ-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 11:35:42 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bey9j-0000QZ-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 11:34:51 -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 <0.00DFBA1F@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 11:34:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23520514 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 11:34:46 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 11:24:28 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7121331 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 11:24:27 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040624121631.0247b640@localhost> <5.1.0.14.0.20040624121631.0247b640@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <5.1.0.14.0.20040628111653.024bec50@localhost> Date: Mon, 28 Jun 2004 11:24:17 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <40E03514.4050307@zurich.ibm.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Thanks Robert. I think my problem is only in the english usage that tried= =20 to treat the multi-target TLV as part of the "message=20 addressing". Mentally, I do not think of the multicast as "addressed" to=20 those selective LFBs, but rather as the multicast is addressed to the=20 relevant FEs, and the FEs apply the message to the right set of LFBs. Given that the information is in a TLV and appears to be in a reasonable=20 plac ein the message, I don't think we are disagreeing about the structure. I also just have a mental problem thinking of it as a VPN. If we need this, could we call it an "LFB Group" instead? (I do see the=20 mental parallels that tempt one to call it a VPN, but I think it is=20 actually not a good model.) Yours, Joel PS: It is going to take extra mechanisms to manage these LFB Group IDs. I= =20 suppose that the Group_ID -> LFB instance list mapping would be an FE=20 Protocol attribute, and the CE would manage the table so that every FE=20 knows which of its LFBs are selected. (I think this belongs in the FE=20 Protocol Object rather than in the FE Object.) At 05:11 PM 6/28/2004 +0200, Robert Haas wrote: >Joel, >Thanks for your comments. See some answers below. > >Joel M. Halpern wrote: > >>Some minor comments on the document. >>[snip] >> >>5) I think that trying to mix LFB selection with the FE / CE= identification >>in the last part of bullet G of section 5 is a mistake. This level of >>addressing ought to indicate which FEs I want to talk about. If I need to >>be able to indicate a specific subset of LFBs on FE 1 and a distinct= subset >>of FE2 while sending both FEs the same message, then we should add >>mechanisms to create LFB groupings, and put that group identifier in an= LFB >>group TLV. > >I copied the text of the draft you were refering to below: > > It is desirable to address multicast and/or broadcast > messages to some LFB instances of a given class. For > instance, assume FEs FEa and FEb: > - FEa has LFBs LFBaX1 and LFBaX2 of class X > - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of > class X. > A broadcast message should be addressable to only LFBs > LFBaX1 and LFBbX1 (this can be the case for instance if > these two LFBs belong to the same VPN). To achieve this, > a VPN ID (3 octets OUI and 4 octets VPN Index) as defined > in RFC 2685 should be used within the ForCES message body > as a TLV. > > As an alternative, a particular multicast ID MAY be > associated to a given VPN ID through some configuration > means. Messages delivered to such a multicast ID MUST > only be applied to LFBs belonging to that VPN ID. > > >What you call "LFB grouping TLV" is what is proposed here as the VPN ID= TLV. >A simple mechanism would be to use the broadcast FE ID and add the VPN ID= =20 >TLV in the message so that only those FEs that belong to the VPN process=20 >the message. >Some people might then suggest that the message should be delivered only=20 >to those FEs that will process it (to save network bandwidth and CPU=20 >cycles, for instance), therefore the proposal to use a multicast ID=20 >instead. Note that the VPN ID TLV could remain in the message, if this is= =20 >what you suggest ? > >Regards, > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 13:07:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16559 for ; Mon, 28 Jun 2004 13:07:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezbH-00016r-7r for forces-archive@ietf.org; Mon, 28 Jun 2004 13:07:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BezaL-0000s4-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 13:06:26 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BezZS-0000cn-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 13: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 <9.00DFB95A@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 13:05:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23529900 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 13:05:24 -0400 Approved-By: avri@PSG.COM Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 12:55:36 -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 i5SGm3ep022046 for ; Mon, 28 Jun 2004 18:48:04 +0200 Mime-Version: 1.0 (Apple Message framework v618) References: <1c9.1b20551a.2e10bdbc@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.618) Message-ID: Date: Mon, 28 Jun 2004 12:55:33 -0400 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1c9.1b20551a.2e10bdbc@aol.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On 27 jun 2004, at 20.18, Alex Audu wrote: > 1) General comments:=A0 I like the preambles in the early sections.=20 > However, I am not sure > =A0=A0=A0 if it is necessary to draft real-estate discussing how the = design=20 > team was created in > =A0=A0=A0 section 1. Introduction. This section was put in for this draft only to give the background on=20 this first version of the draft. It seems very reasonable to remove it=20= before the next revision, especially if this is the draft chosen for WG=20= draft status. a. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 28 20:38:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27222 for ; Mon, 28 Jun 2004 20:38:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf6du-0001Ut-Sr for forces-archive@ietf.org; Mon, 28 Jun 2004 20:38:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf6cv-0001Df-00 for forces-archive@ietf.org; Mon, 28 Jun 2004 20:37:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bf6br-0000kl-00 for forces-archive@IETF.ORG; Mon, 28 Jun 2004 20:36:27 -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.00DFC345@cherry.ease.lsoft.com>; Mon, 28 Jun 2004 20:36:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23569827 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Jun 2004 20:36:26 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Jun 2004 20:13:34 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5SHDDKB017721; Mon, 28 Jun 2004 17:13:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5T06JO2025880; Tue, 29 Jun 2004 00:07:31 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062817104031964 ; Mon, 28 Jun 2004 17:10:42 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 17:10:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45D6D.746B3FFC" Thread-Topic: [FORCES] First draft of ForCES protocol from the protocol design team Thread-Index: AcRcp1U03++LIBc2TgicI5H32P8sbAAxRgbQ X-OriginalArrivalTime: 29 Jun 2004 00:10:16.0583 (UTC) FILETIME=[74D01970:01C45D6D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E01967D83@orsmsx408> Date: Mon, 28 Jun 2004 17:10:15 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: Aaudu2000@AOL.COM To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C45D6D.746B3FFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, =20 Thanks for your comments. Pls see my reply below. ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu =20 6) Section 6.1.3 Association Teardown Message =20 I cringed when I read the following in the draft: ........................................................................ ......... Message Header: The Message Type in the header is set MessageType=3D 'Asso. Teardown'(TBD?). The ACK flag in the header is always ignored, because the teardown message will never expect to get any response from the message receiver. ........................................................................ ........................... Now, a protocol designed this way will NEVER work. The ACK is very much needed when tearing down an association. Consider the following scenario: =20 +------------------FE1 CE ------------| +------------------FE2 =20 CE is the contol active control element with FE1 the active FE and FE2 the standby unit. =20 1) FE1 is now sent a command to go down (by craft person via management interface). 2) FE1 sends association-teardown request to CE. 3) CE gets this important information and quickly activates FE2 to assume FE1's=20 responsibilities. 4) FE2 acknowledges this activation to CE. 5) CE can then acknowledge FE1's request to leave or go down. 6) FE1 leaves, and FE2 assumes FE1's traffic duties. Hurray!,.. NO TRAFFIC OUTAGE. =20 Now, if we take away steps 3,4, and 5, then FE1 can just leave at will, and the result WILL BE AN OUTAGE. At least until an alternative FE becomes the active one. This is not=20 a 5-9's reliability compliant protocol. =20 [HK] You are assuming here that the FE sending the Teardown message is actually in a state where it can wait for an acknowledgment from the CE before going down. This is not always the case, the more common case would be that the FE or CE crashes and the error handling code in the FE/CE will send a Teardown message to the other entity (CE in your eg). In this case, the acknowledgment is useless. Also, a lot of FE redundancy mechanisms are built into actual hardware using FE-FE communication mechanisms to provide 5-9's reliability. =20 Anyways, you have made an interesting point here and we will definitely give it due consideration in our team discussions. =20 regards Hormuzd ------_=_NextPart_001_01C45D6D.746B3FFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Alex,
 
Thanks=20 for your comments. Pls see my reply below.
From: Forwarding and Control Element = Separation=20 [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex=20 Audu
 
6) Section 6.1.3 Association Teardown Message
 
I cringed when I read the following in the draft:
....................................................................= .............
   Message Header:
   The Message Type in = the header=20 is set MessageType=3D 'Asso.
   Teardown'(TBD?).  The = ACK flag=20 in the header is always ignored,
   because the teardown = message=20 will never expect to get any response
   from the message=20 receiver.
............................................................= .......................................
Now, a protocol designed this way will NEVER work.  The = ACK is=20 very much needed when
tearing down an association.  Consider the following=20 scenario:
 
           &n= bsp;           &nb= sp;        =20 +------------------FE1
           &n= bsp;    CE=20 ------------|
           &n= bsp;           &nb= sp;        =20 +------------------FE2
 
CE is the contol active control element with FE1 the active FE = and FE2=20 the standby unit.
 
    1) FE1 is now sent a command to go = down (by=20 craft person via management interface).
    2) FE1 sends association-teardown request = to=20 CE.
    3) CE gets this important information and = quickly=20 activates FE2 to assume FE1's
         responsibiliti= es.
    4) FE2 acknowledges this activation to CE.
    5) CE can then acknowledge FE1's request to = leave or go=20 down.
    6) FE1 leaves, and FE2 assumes FE1's traffic=20 duties.  Hurray!,.. NO TRAFFIC OUTAGE.
 
Now, if we take away steps 3,4, and 5, then FE1 can just leave at = will, and=20 the result WILL
BE AN OUTAGE. At least until an alternative = FE becomes the=20 active one.  This is not
a 5-9's reliability compliant protocol.
 
[HK] You are assuming here that = the FE=20 sending the Teardown message is actually in a state where it can wait = for an=20 acknowledgment from the CE before going down. This is not always the = case, the=20 more common case would be that the FE or CE crashes and the error = handling code=20 in the FE/CE will send a Teardown message to the other entity (CE = in your=20 eg). In this case, the acknowledgment is useless. Also, a lot of FE = redundancy=20 mechanisms are built into actual hardware using FE-FE communication = mechanisms=20 to provide 5-9's reliability.
 
Anyways, you have made an = interesting point=20 here and we will definitely give it due consideration in our team=20 discussions.
 
regards
Hormuzd
------_=_NextPart_001_01C45D6D.746B3FFC-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 12:46:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01241 for ; Tue, 29 Jun 2004 12:46:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfLkj-0007fP-7g for forces-archive@ietf.org; Tue, 29 Jun 2004 12:46:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfLjz-0007HW-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 12:45:51 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfLip-0006sF-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 12:44: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 <19.00DFD43F@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 12:44:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23697184 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 12:44:30 -0400 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 12:43:56 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5TGhno5028426 for ; Tue, 29 Jun 2004 16:43:49 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5TGaxuL029613 for ; Tue, 29 Jun 2004 16:38:42 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062909435323996 for ; Tue, 29 Jun 2004 09:43:53 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 09:43:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: ForCES Draft Selection Process thread-index: AcRd+EMf46kaP+LHSX2hhTaT1cJdpA== X-OriginalArrivalTime: 29 Jun 2004 16:43:53.0231 (UTC) FILETIME=[431AA9F0:01C45DF8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: Date: Tue, 29 Jun 2004 09:43:53 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Draft Selection Process To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable All, A brief clarification on the draft selection process to be followed over the next several weeks: Two drafts have been submitted - a draft written by a design team consisting of authors of three previous submissions (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t xt) and a draft written by one of the authors of a previous submission (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt). The ForCES participants (via this list) now need to evaluate the two documents and comment on them. The comment period is open until IETF 60. Once the comment period is complete, the chairs will evaluate and announce what the rough consensus is for=20 selecting one of the two drafts as an official working=20 group document. Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 17:38:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25463 for ; Tue, 29 Jun 2004 17:38:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQJV-0005Q2-Me for forces-archive@ietf.org; Tue, 29 Jun 2004 17:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQ0f-0001Y2-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 17:19:22 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfPdq-0004te-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 16:55: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.00DFDB60@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 16:55:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23726139 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 16:55:45 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 16:50:23 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004062913505451:746 ; Tue, 29 Jun 2004 13:50:54 -0700 References: Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2004 01:50:54 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2004 01:50:57 PM, Serialize complete at 06/29/2004 01:50:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1088542220.1157.38.camel@jzny.localdomain> Date: Tue, 29 Jun 2004 16:50:20 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: ForCES Draft Selection Process Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The way i see it is we should even bother evaluating Alexs reincarnation of FACT. He did agree for the merger - the least he could have done because he agreed to the merger is wait until the draft was out then criticize it constructively. I dont think it is fair to go through anotehr phase of a reevaluation that previously led to a merger. You have to drawn the line somewhere. cheers, jamal On Tue, 2004-06-29 at 12:43, Putzolu, David wrote: > All, > > A brief clarification on the draft selection process > to be followed over the next several weeks: > > Two drafts have been submitted - a draft written by a > design team consisting of authors of three previous submissions > (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t > xt) > and a draft written by one of the authors of a previous submission > (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt). > > The ForCES participants (via this list) now need to > evaluate the two documents and comment on them. The > comment period is open until IETF 60. > > Once the comment period is complete, the chairs will > evaluate and announce what the rough consensus is for > selecting one of the two drafts as an official working > group document. > > Cheers, > David From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 18:02:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29318 for ; Tue, 29 Jun 2004 18:02:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfQg6-0002fo-7z for forces-archive@ietf.org; Tue, 29 Jun 2004 18:02:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfQX2-0000RH-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 17:52:49 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfQGS-0004r5-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 17:35: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 <5.00DFDCD0@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 17:35:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23730402 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 17:35:39 -0400 Approved-By: avri@PSG.COM Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 17:16:54 -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 i5TL9Bep025137 for ; Tue, 29 Jun 2004 23:09:12 +0200 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.618) Message-ID: Date: Tue, 29 Jun 2004 17:16:51 -0400 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: Fwd: I-D ACTION:draft-doria-forces-protocol-00.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, Below is the announcement for the ForCES Protocol Team submission. You will notice that the name of the draft has changed from draft-fpteam-forces-protocol-00.txt to draft-doria-forces-protocol-00.txt This change was made because of internet-draft naming rules, i.e. they did not accept the draft under the original draft. This is _not_ an indicator of authorship as the draft is and remains the product of the entire team. The draft is essentially the same as the version I made available on my web site, though some formatting has been cleaned up (as the formatter I was in the process of getting ready for a next revision). It does not include any changes based on any of the comments thus far received (except for one minor replacement of xEM with 'FEM or CEM' based on a private comment I received). thanks a. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 29 juni 2004 15.27.46 GMT-04:00 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-doria-forces-protocol-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ForCES Protocol Specification > Author(s) : A. Doria, et al. > Filename : draft-doria-forces-protocol-00.txt > Pages : 56 > Date : 2004-6-29 > > This is the first draft of the ForCES protocol specification > produced > by the protocol design team. It is presented to the WG for > consideration as a WG work item. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-doria-forces-protocol-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-doria-forces-protocol-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-doria-forces-protocol-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. > Content-Type: text/plain > Content-ID: <2004-6-29150022.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 20:02:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08847 for ; Tue, 29 Jun 2004 20:02:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfSYc-0001He-Lx for forces-archive@ietf.org; Tue, 29 Jun 2004 20:02:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfSXd-0000qp-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 20:01:34 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfSWd-0000QL-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 20:00:31 -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.00DFDF1B@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 20:00:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23740999 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 20:00:22 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 19:59:43 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5TGxBrn032536; Tue, 29 Jun 2004 16:59:35 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5TNrUtT019179; Tue, 29 Jun 2004 23:53:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062916585102086 ; Tue, 29 Jun 2004 16:58:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 16:58:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45E35.0639952B" Thread-Topic: First draft of ForCES protocol from the protocol design team Thread-Index: AcReMumfQ9r0Xk7wR7mSVSD9Gk7P2wAAeTAg X-OriginalArrivalTime: 29 Jun 2004 23:58:50.0989 (UTC) FILETIME=[069481D0:01C45E35] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E019AD8A3@orsmsx408> Date: Tue, 29 Jun 2004 16:58:49 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: Aaudu2000@aol.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C45E35.0639952B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex, =20 Yes, I received your email twice. As I said, we will definitely discuss this in our team meetings. =20 Thanks for your input, Hormuzd ________________________________ From: Aaudu2000@aol.com [mailto:Aaudu2000@aol.com]=20 Sent: Tuesday, June 29, 2004 4:44 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: Re: First draft of ForCES protocol from the protocol design team Hi Hormuzd, =20 I replied to this e-mail earlier, but for some reasons I didn't get an echo on the list. So, I'll try again. =20 It is not true that CEs and FEs crashing will be "the more common case" of association teardown. Crashes are an exception condition, and should occure very rearly. The more common scenario resulting in association teardown will be management/craft related activities (e.g. software/hardware upgrades, testings, and other general maintenance). =20 Even for a catastrophic event like a crash, the protocol should be designed to prevent=20 minimize packet loss. We have such a mechanism in draft-audu-forces-pl-00.txt and also in FACT. =20 =20 Regards, Alex. =20 In a message dated 6/28/2004 7:59:42 PM Central Standard Time, hormuzd.m.khosravi@INTEL.COM writes: Alex, =20 Thanks for your comments. Pls see my reply below. =09 ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu =09 =20 6) Section 6.1.3 Association Teardown Message =20 I cringed when I read the following in the draft: =09 ........................................................................ ......... Message Header: The Message Type in the header is set MessageType=3D 'Asso. Teardown'(TBD?). The ACK flag in the header is always ignored, because the teardown message will never expect to get any response from the message receiver. =09 ........................................................................ ........................... Now, a protocol designed this way will NEVER work. The ACK is very much needed when tearing down an association. Consider the following scenario: =20 +------------------FE1 CE ------------| +------------------FE2 =20 CE is the contol active control element with FE1 the active FE and FE2 the standby unit. =20 1) FE1 is now sent a command to go down (by craft person via management interface). 2) FE1 sends association-teardown request to CE. 3) CE gets this important information and quickly activates FE2 to assume FE1's=20 responsibilities. 4) FE2 acknowledges this activation to CE. 5) CE can then acknowledge FE1's request to leave or go down. 6) FE1 leaves, and FE2 assumes FE1's traffic duties. Hurray!,.. NO TRAFFIC OUTAGE. =20 Now, if we take away steps 3,4, and 5, then FE1 can just leave at will, and the result WILL BE AN OUTAGE. At least until an alternative FE becomes the active one. This is not=20 a 5-9's reliability compliant protocol. =20 [HK] You are assuming here that the FE sending the Teardown message is actually in a state where it can wait for an acknowledgment from the CE before going down. This is not always the case, the more common case would be that the FE or CE crashes and the error handling code in the FE/CE will send a Teardown message to the other entity (CE in your eg). In this case, the acknowledgment is useless. Also, a lot of FE redundancy mechanisms are built into actual hardware using FE-FE communication mechanisms to provide 5-9's reliability. =20 Anyways, you have made an interesting point here and we will definitely give it due consideration in our team discussions. =20 regards Hormuzd ------_=_NextPart_001_01C45E35.0639952B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Alex,
 
Yes, I = received your=20 email twice. As I said, we will definitely discuss this in our team=20 meetings.
 
Thanks for = your=20 input,
Hormuzd
From: Aaudu2000@aol.com = [mailto:Aaudu2000@aol.com]=20
Sent: Tuesday, June 29, 2004 4:44 PM
To: Khosravi, = Hormuzd=20 M; FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: First draft of = ForCES=20 protocol from the protocol design team

Hi Hormuzd,
 
I replied to this e-mail earlier, but for some reasons I didn't get = an echo=20 on the list. So, I'll
try again.
 
It is not true that CEs and FEs crashing will be "the more common = case" of=20 association
teardown.  Crashes are an exception condition, and should = occure very=20 rearly.  The more
common scenario resulting in association teardown will be = management/craft=20 related
activities (e.g. software/hardware upgrades, testings, and other = general=20 maintenance).
 
Even for a catastrophic event like a crash, the protocol should be = designed=20 to prevent
minimize packet loss. We have such a mechanism in=20 draft-audu-forces-pl-00.txt and also
in FACT. 
 
Regards,
Alex.
 
In a message dated 6/28/2004 7:59:42 PM Central Standard Time,=20 hormuzd.m.khosravi@INTEL.COM writes:
Alex,
 
Thanks for your comments. Pls see my reply=20 below.
From: Forwarding and Control Element = Separation=20 [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex=20 Audu
 
6) Section 6.1.3 Association Teardown Message
 
I cringed when I read the following in the draft:
=
....................................................................= .............
   Message Header:
   The Message Type in = the=20 header is set MessageType=3D 'Asso.
   = Teardown'(TBD?).  The=20 ACK flag in the header is always ignored,
   because the = teardown=20 message will never expect to get any response
   from the = message=20 = receiver.
............................................................= .......................................
Now, a protocol designed this way will NEVER work.  The = ACK is=20 very much needed when
tearing down an association.  Consider the following=20 scenario:
 
=
           &n= bsp;           &nb= sp;        =20 +------------------FE1
=
           &n= bsp;    CE=20 ------------|
=
           &n= bsp;           &nb= sp;        =20 +------------------FE2
 
CE is the contol active control element with FE1 the active FE=20 and FE2 the standby unit.
 
    1) FE1 is now sent a command to go = down (by=20 craft person via management interface).
    2) FE1 sends association-teardown request = to=20 CE.
    3) CE gets this important information and = quickly=20 activates FE2 to assume FE1's
=
         responsibiliti= es.
    4) FE2 acknowledges this activation to = CE.
    5) CE can then acknowledge FE1's request to = leave or=20 go down.
    6) FE1 leaves, and FE2 assumes FE1's traffic=20 duties.  Hurray!,.. NO TRAFFIC OUTAGE.
 
Now, if we take away steps 3,4, and 5, then FE1 can just leave at = will,=20 and the result WILL
BE AN OUTAGE. At least until an alternative = FE becomes the=20 active one.  This is not
a 5-9's reliability compliant protocol.
 
[HK] You are assuming here that = the FE=20 sending the Teardown message is actually in a state where it can wait = for an=20 acknowledgment from the CE before going down. This is not always the = case, the=20 more common case would be that the FE or CE crashes and the error = handling=20 code in the FE/CE will send a Teardown message to the other entity (CE = in your eg). In this case, the acknowledgment is useless. Also, a = lot of=20 FE redundancy mechanisms are built into actual hardware using FE-FE=20 communication mechanisms to provide 5-9's reliability.
 
Anyways, you have made an = interesting=20 point here and we will definitely give it due consideration in our = team=20 discussions.
 
regards
Hormuzd
------_=_NextPart_001_01C45E35.0639952B-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 21:01:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12119 for ; Tue, 29 Jun 2004 21:01:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfTTn-00010b-QY for forces-archive@ietf.org; Tue, 29 Jun 2004 21:01:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfTSq-0000eN-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 21:00:41 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfTSU-0000IM-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 21:00: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 <16.00DFE0A2@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 21:00:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23746232 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 21:00:18 -0400 Approved-By: Aaudu2000@AOL.COM Received: from 64.12.137.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 19:55:39 -0400 Received: from Aaudu2000@aol.com by imo-m21.mx.aol.com (mail_out_v37_r2.6.) id l.c0.1058d0e6 (4246); Tue, 29 Jun 2004 19:55:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1088553324" X-Mailer: 9.0 for Windows sub 5032 Message-ID: Date: Tue, 29 Jun 2004 19:55:24 EDT Reply-To: Aaudu2000@AOL.COM Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: ForCES Draft Selection Process Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 -------------------------------1088553324 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Jamal, The issues I am raising are purely technical. And I have tried to give justification for them as much as possible. If you think my comments are baseless, then so state. The reason for merging is to produce a sound protocol. I don't think anyone sould sit idly by and not comment on potential problems with a proposal even if that proposal resulted from a merge process. We owe it to the IETF and the community at large to deliver a sound protocol. Regards, Alex. In a message dated 6/29/2004 4:17:58 PM Central Standard Time, hadi@ZNYX.COM writes: The way i see it is we should even bother evaluating Alexs reincarnation of FACT. He did agree for the merger - the least he could have done because he agreed to the merger is wait until the draft was out then criticize it constructively. I dont think it is fair to go through anotehr phase of a reevaluation that previously led to a merger. You have to drawn the line somewhere. cheers, jamal On Tue, 2004-06-29 at 12:43, Putzolu, David wrote: > All, > > A brief clarification on the draft selection process > to be followed over the next several weeks: > > Two drafts have been submitted - a draft written by a > design team consisting of authors of three previous submissions > (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t > xt) > and a draft written by one of the authors of a previous submission > (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt). > > The ForCES participants (via this list) now need to > evaluate the two documents and comment on them. The > comment period is open until IETF 60. > > Once the comment period is complete, the chairs will > evaluate and announce what the rough consensus is for > selecting one of the two drafts as an official working > group document. > > Cheers, > David -------------------------------1088553324 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Jamal,
 
The issues I am raising are purely technical.  And I have tried to= give justification for them
as much as possible.  If you think my comments are baseless, = then so state.
 
The reason for merging is to produce a sound protocol. =20= I don't think anyone sould sit
idly by and not comment on potential problems with a proposal even= if that proposal 
resulted from a merge process. We owe it to the IETF and the=20= community at large to
deliver a sound protocol.
 
Regards,
Alex.
In a message dated 6/29/2004 4:17:58 PM Central Standard Time, hadi@ZNY= X.COM writes:
The way i see it is we should even bother eval= uating Alexs
reincarnation of FACT.
He did agree for the merger - the=20= least he could have
done because he agreed to the merger is wait until th= e
draft was out then criticize it constructively.
I dont think it is f= air to go through anotehr phase of a
reevaluation that previously led to=20= a merger. You have to drawn
the line somewhere.

cheers,
jamal


On Tue, 2004-06-29 at 12:43, Putzolu, David wrote:
> All= ,
>
> A brief clarification on the draft selection process
&g= t; to be followed over the next several weeks:
>
> Two drafts ha= ve been submitted - a draft written by a
> design team consisting of a= uthors of three previous submissions
> (http://www.sstanamera.com/~for= ces/Old/draft-fpteam-forces-protocol-00.t
> xt)
> and a draft wr= itten by one of the authors of a previous submission
> (http://www.sst= anamera.com/~forces/Old/draft-audu-forces-pl-00.txt).
>
> The Fo= rCES participants (via this list) now need to
> evaluate the two docum= ents and comment on them. The
> comment period is open until IETF 60.<= BR>>
> Once the comment period is complete, the chairs will
>= evaluate and announce what the rough consensus is for
> selecting one= of the two drafts as an official working
> group document.
>> Cheers,
> David
-------------------------------1088553324-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 21:03:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12200 for ; Tue, 29 Jun 2004 21:03:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfTVs-0001lI-4X for forces-archive@ietf.org; Tue, 29 Jun 2004 21:03:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfTUr-0001Nz-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 21:02:46 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfTUE-00011O-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 21:02: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 <23.00DFE099@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 21:02:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23746342 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 21:02:04 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 20:27:03 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5U0Qvo5019671; Wed, 30 Jun 2004 00:26:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5U0LgtP003171; Wed, 30 Jun 2004 00:21:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062917265510095 ; Tue, 29 Jun 2004 17:26:55 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 17:26:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: [FORCES] ForCES Draft Selection Process Thread-Index: AcReG3hFfpTDC73+Sni6MmzXui4kiAAGak6g X-OriginalArrivalTime: 30 Jun 2004 00:26:42.0747 (UTC) FILETIME=[EB0688B0:01C45E38] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E019AD902@orsmsx408> Date: Tue, 29 Jun 2004 17:26:41 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Draft Selection Process Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I have to agree on this. I don't quite understand what process we are following, or see any point to this draft. Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, June 29, 2004 1:50 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Draft Selection Process The way i see it is we should even bother evaluating Alexs reincarnation of FACT. He did agree for the merger - the least he could have done because he agreed to the merger is wait until the draft was out then criticize it constructively. I dont think it is fair to go through anotehr phase of a reevaluation that previously led to a merger. You have to drawn the line somewhere. cheers, jamal On Tue, 2004-06-29 at 12:43, Putzolu, David wrote: > All, > > A brief clarification on the draft selection process > to be followed over the next several weeks: > > Two drafts have been submitted - a draft written by a > design team consisting of authors of three previous submissions > (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t > xt) > and a draft written by one of the authors of a previous submission > (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt). > > The ForCES participants (via this list) now need to > evaluate the two documents and comment on them. The > comment period is open until IETF 60. > > Once the comment period is complete, the chairs will > evaluate and announce what the rough consensus is for > selecting one of the two drafts as an official working > group document. > > Cheers, > David From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 29 21:11:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12595 for ; Tue, 29 Jun 2004 21:11:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfTda-0004s2-8F for forces-archive@ietf.org; Tue, 29 Jun 2004 21:11:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfTcq-0004UB-00 for forces-archive@ietf.org; Tue, 29 Jun 2004 21:11:01 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfTc6-00045u-00 for forces-archive@IETF.ORG; Tue, 29 Jun 2004 21:10: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 <7.00DFE0ED@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 21:10:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23746706 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 21:10:00 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 21:09:22 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i5U18xo5015758; Wed, 30 Jun 2004 01:08:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i5U13ItX027117; Wed, 30 Jun 2004 01:03:46 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004062918073107849 ; Tue, 29 Jun 2004 18:07:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 18:07:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45E3E.9C900CAE" Thread-Topic: [FORCES] ForCES Draft Selection Process Thread-Index: AcRePaJC/Qvj1a0JRQqlQ6tAq0m6SQAAGBkg X-OriginalArrivalTime: 30 Jun 2004 01:07:28.0767 (UTC) FILETIME=[9CF790F0:01C45E3E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E019AD94D@orsmsx408> Date: Tue, 29 Jun 2004 18:07:27 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: ForCES Draft Selection Process Comments: To: Aaudu2000@AOL.COM To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C45E3E.9C900CAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, =20 I think we all agree to follow process in terms of reviewing the merged proposal, etc. Many members of the WG, including yourself, have been doing that already. But I don't quite understand what is the point of resubmitting the FACT draft, after we agreed on having a single proposal going forward. I don't think this is the=20 best way of contributing towards the merged proposal, if that is your intent. =20 regards Hormuzd ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: Tuesday, June 29, 2004 4:55 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] ForCES Draft Selection Process Hi Jamal, =20 The issues I am raising are purely technical. And I have tried to give justification for them as much as possible. If you think my comments are baseless, then so state. =20 The reason for merging is to produce a sound protocol. I don't think anyone sould sit idly by and not comment on potential problems with a proposal even if that proposal=20 resulted from a merge process. We owe it to the IETF and the community at large to=20 deliver a sound protocol. =20 Regards, Alex. In a message dated 6/29/2004 4:17:58 PM Central Standard Time, hadi@ZNYX.COM writes: The way i see it is we should even bother evaluating Alexs reincarnation of FACT. He did agree for the merger - the least he could have done because he agreed to the merger is wait until the draft was out then criticize it constructively. I dont think it is fair to go through anotehr phase of a reevaluation that previously led to a merger. You have to drawn the line somewhere. =09 cheers, jamal =09 =09 =09 On Tue, 2004-06-29 at 12:43, Putzolu, David wrote: > All, > > A brief clarification on the draft selection process > to be followed over the next several weeks: > > Two drafts have been submitted - a draft written by a > design team consisting of authors of three previous submissions > (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t > xt) > and a draft written by one of the authors of a previous submission > (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt). > > The ForCES participants (via this list) now need to > evaluate the two documents and comment on them. The > comment period is open until IETF 60. > > Once the comment period is complete, the chairs will > evaluate and announce what the rough consensus is for > selecting one of the two drafts as an official working > group document. > > Cheers, > David ------_=_NextPart_001_01C45E3E.9C900CAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Alex,
 
I think we = all agree to=20 follow process in terms of reviewing the merged proposal, = etc.
Many = members of the WG,=20 including yourself, have been doing that already.
But I don't = quite=20 understand what is the point of resubmitting the FACT = draft,
after we = agreed on having=20 a single proposal going forward. I don't think this is the
best way of = contributing=20 towards the merged proposal, if that is your intent.
 
regards
Hormuzd
From: Forwarding and Control Element = Separation=20 [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex=20 Audu
Sent: Tuesday, June 29, 2004 4:55 PM
To:=20 FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] ForCES Draft = Selection Process

Hi Jamal,
 
The issues I am raising are purely technical.  And I have = tried to=20 give justification for them
as much as possible.  If you think my comments are = baseless, =20 then so state.
 
The reason for merging is to produce = a sound protocol. =20 I don't think anyone sould sit
idly by and not comment on potential problems with a proposal = even if=20 that proposal 
resulted from a merge process. We owe it to the IETF and = the=20 community at large to
deliver a sound protocol.
 
Regards,
Alex.
In a message dated 6/29/2004 4:17:58 PM Central Standard Time,=20 hadi@ZNYX.COM writes:
The way i see it is we should even bother evaluating=20 Alexs
reincarnation of FACT.
He did agree for the merger - the = least he=20 could have
done because he agreed to the merger is wait until = the
draft=20 was out then criticize it constructively.
I dont think it is fair = to go=20 through anotehr phase of a
reevaluation that previously led to a = merger.=20 You have to drawn
the line=20 somewhere.

cheers,
jamal



On Tue, 2004-06-29 = at 12:43,=20 Putzolu, David wrote:
> All,
>
> A brief = clarification on=20 the draft selection process
> to be followed over the next = several=20 weeks:
>
> Two drafts have been submitted - a draft = written by=20 a
> design team consisting of authors of three previous=20 submissions
>=20 = (http://www.sstanamera.com/~forces/Old/draft-fpteam-forces-protocol-00.t<= BR>>=20 xt)
> and a draft written by one of the authors of a previous=20 submission
>=20 = (http://www.sstanamera.com/~forces/Old/draft-audu-forces-pl-00.txt).
&= gt;
>=20 The ForCES participants (via this list) now need to
> evaluate = the two=20 documents and comment on them. The
> comment period is open = until IETF=20 60.
>
> Once the comment period is complete, the chairs=20 will
> evaluate and announce what the rough consensus is = for
>=20 selecting one of the two drafts as an official working
> group=20 document.
>
> Cheers,
> = David
------_=_NextPart_001_01C45E3E.9C900CAE-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 30 05:21:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03946 for ; Wed, 30 Jun 2004 05:21:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfbH4-0001Qo-Dx for forces-archive@ietf.org; Wed, 30 Jun 2004 05:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfbG6-00012j-00 for forces-archive@ietf.org; Wed, 30 Jun 2004 05:20:03 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1BfbFW-0000fv-00 for forces-archive@IETF.ORG; Wed, 30 Jun 2004 05:19:26 -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.00DFEA02@cherry.ease.lsoft.com>; Wed, 30 Jun 2004 5:19:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23782171 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 30 Jun 2004 05:19:26 -0400 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jun 2004 04:46:02 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i5U8k1GP113026; Wed, 30 Jun 2004 08:46:01 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5U8jo72283962; Wed, 30 Jun 2004 10:45:50 +0200 Received: from zurich.ibm.com (dhcp69-53.zurich.ibm.com [9.4.69.53]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA21922; Wed, 30 Jun 2004 10:45:50 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.0.20040624121631.0247b640@localhost> <5.1.0.14.0.20040624121631.0247b640@localhost> <5.1.0.14.0.20040628111653.024bec50@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id i5U8k1GP113026 Message-ID: <40E27DBD.5020109@zurich.ibm.com> Date: Wed, 30 Jun 2004 10:45:49 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Organization: IBM Research Lab Subject: Re: First draft of ForCES protocol from the protocol design team Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.0.20040628111653.024bec50@localhost> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Joel, Joel M. Halpern wrote: > Thanks Robert. I think my problem is only in the english usage that=20 > tried to treat the multi-target TLV as part of the "message=20 > addressing". Mentally, I do not think of the multicast as "addressed"=20 > to those selective LFBs, but rather as the multicast is addressed to=20 > the relevant FEs, and the FEs apply the message to the right set of LFB= s. > Given that the information is in a TLV and appears to be in a=20 > reasonable plac ein the message, I don't think we are disagreeing=20 > about the structure. > > I also just have a mental problem thinking of it as a VPN. > If we need this, could we call it an "LFB Group" instead? (I do see=20 > the mental parallels that tempt one to call it a VPN, but I think it=20 > is actually not a good model.)=20 I reused the already defined IETF VPN ID, as the main motivation was to=20 have the NE support multiple VPNs, each corresponding to an LFB group. What is the context that you envision for such LFB groups ? > > PS: It is going to take extra mechanisms to manage these LFB Group=20 > IDs. I suppose that the Group_ID -> LFB instance list mapping would=20 > be an FE Protocol attribute, and the CE would manage the table so that=20 > every FE knows which of its LFBs are selected. (I think this belongs=20 > in the FE Protocol Object rather than in the FE Object.)=20 Good point: although it is not mentioned in the draft yet, as you say,=20 we can use an 2-dimensional-array attribute in the FE Protocol Object to=20 list: - the groups to which an FE belongs to, and - the corresponding LFBs in each of those groups. The mechanisms to manipulate this atrribute will be the Config/Query=20 primitives already defined. Or do you see sth missing ? Regards, -Robert > > > > At 05:11 PM 6/28/2004 +0200, Robert Haas wrote: > >> Joel, >> Thanks for your comments. See some answers below. >> >> Joel M. Halpern wrote: >> >>> Some minor comments on the document. >>> [snip] >>> >>> 5) I think that trying to mix LFB selection with the FE / CE=20 >>> identification >>> in the last part of bullet G of section 5 is a mistake. This level o= f >>> addressing ought to indicate which FEs I want to talk about. If I=20 >>> need to >>> be able to indicate a specific subset of LFBs on FE 1 and a distinct=20 >>> subset >>> of FE2 while sending both FEs the same message, then we should add >>> mechanisms to create LFB groupings, and put that group identifier in=20 >>> an LFB >>> group TLV. >> >> >> I copied the text of the draft you were refering to below: >> >> It is desirable to address multicast and/or broadcast >> messages to some LFB instances of a given class. For >> instance, assume FEs FEa and FEb: >> - FEa has LFBs LFBaX1 and LFBaX2 of class X >> - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of >> class X. >> A broadcast message should be addressable to only LFBs >> LFBaX1 and LFBbX1 (this can be the case for instance if >> these two LFBs belong to the same VPN). To achieve this= , >> a VPN ID (3 octets OUI and 4 octets VPN Index) as define= d >> in RFC 2685 should be used within the ForCES message bod= y >> as a TLV. >> >> As an alternative, a particular multicast ID MAY be >> associated to a given VPN ID through some configuration >> means. Messages delivered to such a multicast ID MUST >> only be applied to LFBs belonging to that VPN ID. >> >> >> What you call "LFB grouping TLV" is what is proposed here as the VPN=20 >> ID TLV. >> A simple mechanism would be to use the broadcast FE ID and add the=20 >> VPN ID TLV in the message so that only those FEs that belong to the=20 >> VPN process the message. >> Some people might then suggest that the message should be delivered=20 >> only to those FEs that will process it (to save network bandwidth and=20 >> CPU cycles, for instance), therefore the proposal to use a multicast=20 >> ID instead. Note that the VPN ID TLV could remain in the message, if=20 >> this is what you suggest ? >> >> Regards, >> >> --=20 >> Robert Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~r= ha >> > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 30 13:23:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00076 for ; Wed, 30 Jun 2004 13:23:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfinp-0002c2-AI for forces-archive@ietf.org; Wed, 30 Jun 2004 13:23:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfimq-0002Eq-00 for forces-archive@ietf.org; Wed, 30 Jun 2004 13:22:21 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bfilu-0001rR-00 for forces-archive@IETF.ORG; Wed, 30 Jun 2004 13:21: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 <12.00DFF461@cherry.ease.lsoft.com>; Wed, 30 Jun 2004 13:21:20 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23860014 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 30 Jun 2004 13:21:16 -0400 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jun 2004 12:31:21 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 7130663 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 30 Jun 2004 12:31:19 -0400 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.0.20040628111653.024bec50@localhost> <5.1.0.14.0.20040624121631.0247b640@localhost> <5.1.0.14.0.20040624121631.0247b640@localhost> <5.1.0.14.0.20040628111653.024bec50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <5.1.0.14.0.20040630122632.02510410@localhost> Date: Wed, 30 Jun 2004 12:31:03 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <40E27DBD.5020109@zurich.ibm.com> Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable The VPN ID space was designed to have IDs from multiple allocators used in= =20 the same (internet) space. I think in this case we have only one assigner= =20 (the CE) within the operational space. So a simple CE assigned 32 bit=20 quantity seems sufficient. And in general I just have trouble seeing the=20 parallel to VPNs. I agree that the FE table you describe does what is needed. I was then=20 asking whether that belonged in the FE Protocol Object or the FE Attributes= =20 Object. Yours, Joel At 10:45 AM 6/30/2004 +0200, Robert Haas wrote: >Joel, > >Joel M. Halpern wrote: > >>Thanks Robert. I think my problem is only in the english usage that=20 >>tried to treat the multi-target TLV as part of the "message=20 >>addressing". Mentally, I do not think of the multicast as "addressed" to= =20 >>those selective LFBs, but rather as the multicast is addressed to the=20 >>relevant FEs, and the FEs apply the message to the right set of LFBs. >>Given that the information is in a TLV and appears to be in a reasonable= =20 >>plac ein the message, I don't think we are disagreeing about the= structure. >> >>I also just have a mental problem thinking of it as a VPN. >>If we need this, could we call it an "LFB Group" instead? (I do see the= =20 >>mental parallels that tempt one to call it a VPN, but I think it is=20 >>actually not a good model.) > >I reused the already defined IETF VPN ID, as the main motivation was to=20 >have the NE support multiple VPNs, each corresponding to an LFB group. > >What is the context that you envision for such LFB groups ? > >> >>PS: It is going to take extra mechanisms to manage these LFB Group=20 >>IDs. I suppose that the Group_ID -> LFB instance list mapping would be=20 >>an FE Protocol attribute, and the CE would manage the table so that every= =20 >>FE knows which of its LFBs are selected. (I think this belongs in the FE= =20 >>Protocol Object rather than in the FE Object.) > >Good point: although it is not mentioned in the draft yet, as you say, we= =20 >can use an 2-dimensional-array attribute in the FE Protocol Object to list: >- the groups to which an FE belongs to, and >- the corresponding LFBs in each of those groups. > >The mechanisms to manipulate this atrribute will be the Config/Query=20 >primitives already defined. Or do you see sth missing ? > >Regards, >-Robert > >> >> >> >>At 05:11 PM 6/28/2004 +0200, Robert Haas wrote: >> >>>Joel, >>>Thanks for your comments. See some answers below. >>> >>>Joel M. Halpern wrote: >>> >>>>Some minor comments on the document. >>>>[snip] >>>> >>>>5) I think that trying to mix LFB selection with the FE / CE= identification >>>>in the last part of bullet G of section 5 is a mistake. This level of >>>>addressing ought to indicate which FEs I want to talk about. If I need= to >>>>be able to indicate a specific subset of LFBs on FE 1 and a distinct= subset >>>>of FE2 while sending both FEs the same message, then we should add >>>>mechanisms to create LFB groupings, and put that group identifier in an= LFB >>>>group TLV. >>> >>> >>>I copied the text of the draft you were refering to below: >>> >>> It is desirable to address multicast and/or broadcast >>> messages to some LFB instances of a given class. For >>> instance, assume FEs FEa and FEb: >>> - FEa has LFBs LFBaX1 and LFBaX2 of class X >>> - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of >>> class X. >>> A broadcast message should be addressable to only LFBs >>> LFBaX1 and LFBbX1 (this can be the case for instance if >>> these two LFBs belong to the same VPN). To achieve this, >>> a VPN ID (3 octets OUI and 4 octets VPN Index) as defined >>> in RFC 2685 should be used within the ForCES message body >>> as a TLV. >>> >>> As an alternative, a particular multicast ID MAY be >>> associated to a given VPN ID through some configuration >>> means. Messages delivered to such a multicast ID MUST >>> only be applied to LFBs belonging to that VPN ID. >>> >>> >>>What you call "LFB grouping TLV" is what is proposed here as the VPN ID= TLV. >>>A simple mechanism would be to use the broadcast FE ID and add the VPN=20 >>>ID TLV in the message so that only those FEs that belong to the VPN=20 >>>process the message. >>>Some people might then suggest that the message should be delivered only= =20 >>>to those FEs that will process it (to save network bandwidth and CPU=20 >>>cycles, for instance), therefore the proposal to use a multicast ID=20 >>>instead. Note that the VPN ID TLV could remain in the message, if this=20 >>>is what you suggest ? >>> >>>Regards, >>> >>>-- >>>Robert Haas >>>IBM Zurich Research Laboratory >>>S=E4umerstrasse 4 >>>CH-8803 R=FCschlikon/Switzerland >>>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha >> > >-- >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 30 20:47:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03990 for ; Wed, 30 Jun 2004 20:47:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfpjS-0007nr-RL for forces-archive@ietf.org; Wed, 30 Jun 2004 20:47:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfpia-0007Le-00 for forces-archive@ietf.org; Wed, 30 Jun 2004 20:46:25 -0400 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx with esmtp (Exim 4.12) id 1Bfph9-0006oQ-00 for forces-archive@IETF.ORG; Wed, 30 Jun 2004 20:44:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00DFFD37@cherry.ease.lsoft.com>; Thu, 1 Jul 2004 20:44:55 +2000 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23898679 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 30 Jun 2004 20:44:54 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.59 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jun 2004 20:40:20 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 1 Jul 2004 08:54:18 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <024f01c45f03$c5574cf0$845c21d2@Necom.hzic.edu.cn> Date: Thu, 1 Jul 2004 08:38:47 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Fw: [FORCES] First draft of ForCES protocol from the protocol design team To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 From: "Wang,Weiming" > Hi Sridhar, > > Yes, it is an editorial error made by my carelessness. It should be > . Inter FE topology > . Intra FE topology, i.e., LFB topology. > I'm sorry for the carelessness, and will correct it. > > Thank you so much. > Weiming > > ----- Original Message ----- > From: "T. Sridhar" > To: "Khosravi, Hormuzd M" ; "Wang,Weiming" > > Sent: Tuesday, June 29, 2004 2:22 PM > Subject: RE: [FORCES] First draft of ForCES protocol from the protocol design > team > > > > Yes, Hormuzd & Weimang, they are primarily editorial. > > > > I thought that the Intra FE Topology is really the LFB topology, so it > > looks like an editorial problem. Same with Packet Redirect - my nit is that > > CE to FE traffic for packets to be sent out of the NE are not really > > redirects. However, it is a nit and I am OK if it stays the same. > > > > Thanks, > > Sridhar > > > > > > -----Original Message----- > > From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > > Sent: Monday, June 28, 2004 9:27 PM > > To: Wang,Weiming; sridhar@futsoft.com > > Subject: RE: [FORCES] First draft of ForCES protocol from the protocol > > design team > > > > > > Weiming, > > > > I think these are just editorial comments or typos. It seems like you > > are reading a bit more into these. Sridhar, could you pls clarify ? > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > > > 4. Section 6.2 - the bullet items under "FE (coarse layer) information". > > The > > second bullet states "Inter-FE topology, that is, LFB topology" > > -shouldn't > > that be "Intra-FE topology"? > > > > [Weiming] We also had some doubt on this at first. But later we just > > realized that it may be more reasonable to the LFB topology as FE coarse > > layer info because it is actually the property of the whole FE rather > > than individual LFBs, i.e., attributes(capability) of individual LFBs > > may not be able to tough the whole LFB topology except to know the > > topology of itself to others. > > > > Intra-FE topology is sure belongs to the FE (coarse layer) information, > > and it has been listed in. > > [/Weiming] > > > > 5. Section 6.5 - A nit - since Packet Redirect messages also involve > > CE-FE > > messages (which is not really a redirect) , should we look at calling it > > something else, e.g. Packet Transfer message? > > [Weiming] I agree it is more like a transfer than a redirect operation, > > but to uniformly give a redirect name may greatly easy the construction > > and use of the messages, i.e., with only one type of message. And also > > the redirect op for CE-FE and FE-CE is quite symmetrical. > > [/Weiming] > > > > > > > > > > > > *************************************************************************** > > This message is proprietary to FutureSoft and is intended solely for the use > of the individual to whom it is addressed. It may contain privileged or > confidential information and should not be circulated or used for any purpose > other than for what it is intended. > > > > If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, > > you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. > > FutureSoft accepts no responsibility for loss or damage arising from > > the use of the information transmitted by this email including > > damage from virus. > > *************************************************************************** > > > >