From exim@www1.ietf.org Fri Apr 2 04:11:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00204 for ; Fri, 2 Apr 2004 04:11:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GHH-00012K-MP for forces-protocol-archive@odin.ietf.org; Thu, 01 Apr 2004 23:27:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324RZT7003976 for forces-protocol-archive@odin.ietf.org; Thu, 1 Apr 2004 23:27:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DRR-0008Qy-PX for forces-protocol-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:25:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18420 for ; Thu, 1 Apr 2004 20:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9DRP-0002Me-00 for forces-protocol-web-archive@ietf.org; Thu, 01 Apr 2004 20:25:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9DQc-0002B8-00 for forces-protocol-web-archive@ietf.org; Thu, 01 Apr 2004 20:25:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DPg-000217-00 for forces-protocol-web-archive@ietf.org; Thu, 01 Apr 2004 20:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AC0-0007fS-FR; Thu, 01 Apr 2004 16:57:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9676-0008Oy-8g for forces-protocol@optimus.ietf.org; Thu, 01 Apr 2004 12:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23236 for ; Thu, 1 Apr 2004 12:36:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B966u-0004z7-00 for forces-protocol@ietf.org; Thu, 01 Apr 2004 12:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B965y-0004sJ-00 for forces-protocol@ietf.org; Thu, 01 Apr 2004 12:35:14 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B9653-0004gJ-00 for forces-protocol@ietf.org; Thu, 01 Apr 2004 12:34:17 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i31Ha1nS026071 for ; Thu, 1 Apr 2004 17:36:02 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 i31HQ40G026398 for ; Thu, 1 Apr 2004 17:26:09 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 M2004040109331325158 for ; Thu, 01 Apr 2004 09:33:13 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Apr 2004 09:33:13 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: ForCES Protocol Design Team first task - timeline! Thread-Index: AcQYD2hBmHxRAIBfSl2g5R3YLl2f1A== From: "Putzolu, David" To: X-OriginalArrivalTime: 01 Apr 2004 17:33:13.0830 (UTC) FILETIME=[68FE7860:01C4180F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 1 Apr 2004 09:33:13 -0800 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 Content-Transfer-Encoding: quoted-printable Hi all. Welcome to the ForCES protocol design team. Patrick & I have constituted this team to create a proposed ForCES protocol draft. Please note that: * This document will be an individual contribution until the WG has a chance to review and accept it. * The draft presented to the WG does not need to=20 be complete, but it does need to have enough content to allow the WG to say, "we (disagree|agree) with the fundamental direction and approach taken in this draft." * All work by the design team should be visible to the ForCES mailing list and the design team mailing=20 list archive is publicly accessible. * Non-members of the design team may (and hopefully will!) provide input and contribute to the work of the design team.=20 * The design team has been made a small group in order to allow for rapid progress & effective communication. As such, if you are working with people outside the design team, please ensure=20 that their contributions are up to date with current design team thinking & consensus. I'm sure more will come to mind. :) The first task of the team is to come up with=20 proposed dates for a first draft to be presented to the working group, along with any intermediate milestones (outline done etc.). =20 Thanks! -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 18:52:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14491 for ; Fri, 2 Apr 2004 18:52:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YRo-0007mE-GJ for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 18:52:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32NpUYf029834 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 18:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YRe-0007kf-7A for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 18:51:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14456 for ; Fri, 2 Apr 2004 18:51:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9YRW-0005HY-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 18:51:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9YQt-00059w-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 18:50:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9YQ6-000501-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 18:49:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YPy-0007Uo-T5; Fri, 02 Apr 2004 18:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YLu-0006yN-QZ for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 18:45:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14221 for ; Fri, 2 Apr 2004 18:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9YLr-0004Hs-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 18:45:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9YKr-00048d-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 18:44:30 -0500 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B9YKM-0003yq-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 18:43:59 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i32Njv2Q006917 for ; Fri, 2 Apr 2004 23:45:57 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 i32NjFZX013846 for ; Fri, 2 Apr 2004 23:45:46 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 M2004040215432619802 for ; Fri, 02 Apr 2004 15:43:26 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 15:43:26 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQYD2hBmHxRAIBfSl2g5R3YLl2f1AA+kE9A From: "Khosravi, Hormuzd M" To: "Putzolu, David" , X-OriginalArrivalTime: 02 Apr 2004 23:43:26.0737 (UTC) FILETIME=[4B54D810:01C4190C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Apr 2004 15:43:26 -0800 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 Content-Transfer-Encoding: quoted-printable Hi All IETF 60th meeting starts Aug 1st... Working backwards, we should have our 00 draft submitted by July 1st atleast. Considering it would need to be reviewed atleast once before submission I would go for distributing the draft on the mailing list for review by June 15th. That gives us about 2.5 months to get the draft done. Some intermediate milestones could be... 1. Outline, 2. Complete discussion of major issues, 3. Complete writing of major sections, 4. Send to mailing list for external review, 5. Submission to IETF Here are some suggested dates. 1. Outline done - April' 9th 2. Complete discussion of major issues - April' 30th 2.b. Discussion on mailing list of any contentious issues - ? 3.a. Complete writing of major sections - May' 20th 3.b. Distribute sections for internal review - May'21st 3.c. Incorporate comments from protocol team - June 1st 4. Send to ForCES mailing list for external review - June 2nd 5. Submission to IETF - June 15th If we can hit these dates, we will be well ahead of schedule :-) Let me know what you guys think. Jamal, I'll start by responding to your text on HA over the weekend. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David The first task of the team is to come up with=20 proposed dates for a first draft to be presented to the working group, along with any intermediate milestones (outline done etc.). =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 19:32:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15322 for ; Fri, 2 Apr 2004 19:32:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z59-0004FV-Cp for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 19:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i330WJBh016334 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 19:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z59-0004FN-7i for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 19:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15314 for ; Fri, 2 Apr 2004 19:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z57-0002Wl-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 19:32:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Z4E-0002Pt-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 19:31:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z3r-0002If-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 19:30:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z3s-0003Oz-MR; Fri, 02 Apr 2004 19:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Z3C-0003CG-8T for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 19:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15281 for ; Fri, 2 Apr 2004 19:30:17 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Z3A-0002HS-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 19:30:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Z2D-0002Av-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 19:29:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9Z20-00024M-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 19:29:04 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9Z21-000AbP-7f for forces-protocol@ietf.org; Sat, 03 Apr 2004 00:29:05 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 Apr 2004 09:29:01 +0900 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 Content-Transfer-Encoding: 7bit Seems like a reasonable schedule to me. I think we should also select an editor to be responsible for keeping the draft in shape as we move along. We can all contribute text and agree on content, but there should be one person, agreeable to the entire group, who actually takes care of the doc. a. On 3 apr 2004, at 08.43, Khosravi, Hormuzd M wrote: > Hi All > > IETF 60th meeting starts Aug 1st... > Working backwards, we should have our 00 draft submitted by July 1st > atleast. > Considering it would need to be reviewed atleast once before submission > I would go for distributing the draft on the mailing list for review by > June 15th. > That gives us about 2.5 months to get the draft done. > > Some intermediate milestones could be... > 1. Outline, 2. Complete discussion of major issues, 3. Complete writing > of major sections, 4. Send to mailing list for external review, 5. > Submission to IETF > > Here are some suggested dates. > 1. Outline done - April' 9th > 2. Complete discussion of major issues - April' 30th > 2.b. Discussion on mailing list of any contentious issues - ? > 3.a. Complete writing of major sections - May' 20th > 3.b. Distribute sections for internal review - May'21st > 3.c. Incorporate comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th > > If we can hit these dates, we will be well ahead of schedule :-) > > Let me know what you guys think. > Jamal, I'll start by responding to your text on HA over the weekend. > > Thanks > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David > > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 20:38:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17533 for ; Fri, 2 Apr 2004 20:38:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9a74-0003m3-MK for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 20:38:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i331cMiU014505 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 20:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9a74-0003ls-Hz for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 20:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17522 for ; Fri, 2 Apr 2004 20:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9a72-0003Rd-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 20:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9a67-0003Kp-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 20:37:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9a5i-0003Do-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 20:36:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9a5k-0003Zh-4A; Fri, 02 Apr 2004 20:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9a57-000334-2M for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 20:36:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17491 for ; Fri, 2 Apr 2004 20:36:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9a54-0003CT-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:36:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9a4A-000357-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:35:22 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1B9a3V-0002qG-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:34:41 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i331cYmo006230; Sat, 3 Apr 2004 01:38:34 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 i331aOZN013711; Sat, 3 Apr 2004 01:36:29 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 M2004040217340924643 ; Fri, 02 Apr 2004 17:34:09 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Apr 2004 17:34:09 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF63E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQZEvUBkvJUGItWR1W1GgJwbsiI7gACISfQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 03 Apr 2004 01:34:09.0092 (UTC) FILETIME=[C27BC840:01C4191B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 2 Apr 2004 17:34:08 -0800 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 Content-Transfer-Encoding: quoted-printable I am not sure if we need a single editor at this time. This might be something we eventually need but for now we can move along with individual contributions, My 2 cents, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Friday, April 02, 2004 4:29 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Seems like a reasonable schedule to me. I think we should also select an editor to be responsible for keeping=20 the draft in shape as we move along. We can all contribute text and=20 agree on content, but there should be one person, agreeable to the=20 entire group, who actually takes care of the doc. a. On 3 apr 2004, at 08.43, Khosravi, Hormuzd M wrote: > Hi All > > IETF 60th meeting starts Aug 1st... > Working backwards, we should have our 00 draft submitted by July 1st > atleast. > Considering it would need to be reviewed atleast once before submission > I would go for distributing the draft on the mailing list for review by > June 15th. > That gives us about 2.5 months to get the draft done. > > Some intermediate milestones could be... > 1. Outline, 2. Complete discussion of major issues, 3. Complete writing > of major sections, 4. Send to mailing list for external review, 5. > Submission to IETF > > Here are some suggested dates. > 1. Outline done - April' 9th > 2. Complete discussion of major issues - April' 30th > 2.b. Discussion on mailing list of any contentious issues - ? > 3.a. Complete writing of major sections - May' 20th > 3.b. Distribute sections for internal review - May'21st > 3.c. Incorporate comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th > > If we can hit these dates, we will be well ahead of schedule :-) > > Let me know what you guys think. > Jamal, I'll start by responding to your text on HA over the weekend. > > Thanks > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David > > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 21:02:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18286 for ; Fri, 2 Apr 2004 21:02:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9aTg-00048y-2K for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 21:01:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3321i8p015928 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 21:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9aTf-00048p-RQ for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 21:01:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18213 for ; Fri, 2 Apr 2004 21:01:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9aTd-0006V3-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:01:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9aSh-0006Gw-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:00:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9aRl-00066w-01 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 20:59:45 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9aIL-0004zd-SV for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 20:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9aIL-0000NF-Ia; Fri, 02 Apr 2004 20:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9aHj-0000E9-HR for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 20:49:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17942 for ; Fri, 2 Apr 2004 20:49:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9aHh-0004xy-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:49:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9aGg-0004rV-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:48:18 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B9aFe-0004el-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 20:47:14 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040217492759:27159 ; Fri, 2 Apr 2004 17:49:27 -0800 Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1080956831.1036.5.camel@jzny.localdomain> 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 04/02/2004 05:49:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/02/2004 05:49:29 PM, Serialize complete at 04/02/2004 05:49:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Apr 2004 20:47:11 -0500 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-02 at 19:29, avri@acm.org wrote: > Seems like a reasonable schedule to me. > > I think we should also select an editor to be responsible for keeping > the draft in shape as we move along. We can all contribute text and > agree on content, but there should be one person, agreeable to the > entire group, who actually takes care of the doc. I actually very strongly disagree on this given past experiences. There should be no editor of any sort. I sent an email over 8 hours ago but for some reason it didnt make it in. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 21:31:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19239 for ; Fri, 2 Apr 2004 21:31:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9awS-00070G-U9 for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 21:31:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i332VST8026920 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 21:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9awS-000707-QE for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 21:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19213 for ; Fri, 2 Apr 2004 21:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9awQ-0002gd-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9avT-0002Xv-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:30:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9av1-0002QJ-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9av3-0006dp-H0; Fri, 02 Apr 2004 21:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9auR-0006WV-16 for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 21:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19122 for ; Fri, 2 Apr 2004 21:29:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9auO-0002ON-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:29:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9atP-0002GC-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:28:20 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B9asU-00028i-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:27:22 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040218293651:27190 ; Fri, 2 Apr 2004 18:29:36 -0800 Subject: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1080959240.1036.13.camel@jzny.localdomain> 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 04/02/2004 06:29:37 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/02/2004 06:29:37 PM, Serialize complete at 04/02/2004 06:29:37 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Apr 2004 21:27:20 -0500 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 Content-Transfer-Encoding: 7bit Heres an email i sent earlier that for some odd reason didnt make it. Hormuzds has made similar comments and may give more reason to why the editing should be distributed. cheers, jamal -----Forwarded Message----- From: Jamal Hadi Salim To: "Putzolu, David" Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Date: 02 Apr 2004 11:59:01 -0500 David, This is the old list, no? For a move forward i would suggest that we complete the issues list from earlier and then go into details of each. I would like to suggest that the above get done by the 3rd of may (gives us a month) and also time to pass things onto the mailing list for review before san diego. I would also like to suggest a method where everyone is contributing to the text as opposed to having a single editor. This maybe what the model people did, not sure. It worked very well for us in the netlink2 draft; i also didnt like the way the requirements draft went with a single editor - so i am hoping to avoid a repeat of any issues that came up then (at least from me) in order to focus the energies on the issues. For the documentation scheme, my suggestion is to use the XML variant although i am not sure how you could show any updates using XML. The advantage with that is some of us dont own any MS products but need to be able to update the doc. cheers, jamal On Thu, 2004-04-01 at 12:33, Putzolu, David wrote: > Hi all. > > Welcome to the ForCES protocol design team. > > Patrick & I have constituted this team to create a > proposed ForCES protocol draft. Please note that: > > * This document will be an individual contribution > until the WG has a chance to review and accept it. > > * The draft presented to the WG does not need to > be complete, but it does need to have enough > content to allow the WG to say, "we (disagree|agree) > with the fundamental direction and approach taken > in this draft." > > * All work by the design team should be visible to > the ForCES mailing list and the design team mailing > list archive is publicly accessible. > > * Non-members of the design team may (and hopefully > will!) provide input and contribute to the work > of the design team. > > * The design team has been made a small group in > order to allow for rapid progress & effective > communication. As such, if you are working with > people outside the design team, please ensure > that their contributions are up to date with > current design team thinking & consensus. > > I'm sure more will come to mind. :) > > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). > > Thanks! > -David > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 21:41:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19614 for ; Fri, 2 Apr 2004 21:41:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9b63-0002bD-NQ for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 21:41:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i332fNfm009989 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 21:41:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9b63-0002b2-JI for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 21:41:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19594 for ; Fri, 2 Apr 2004 21:41:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9b60-00042B-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9b55-0003vB-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:40:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9b4g-0003oO-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:39:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9b4j-00024h-0Z; Fri, 02 Apr 2004 21:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9b46-0001xw-Lo for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 21:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19532 for ; Fri, 2 Apr 2004 21:39:19 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9b43-0003nO-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:39:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9b39-0003gk-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:38:24 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9b2n-0003a6-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:38:01 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9b2n-000Fky-DZ for forces-protocol@ietf.org; Sat, 03 Apr 2004 02:38:01 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1080959240.1036.13.camel@jzny.localdomain> References: <1080959240.1036.13.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 Apr 2004 11:37:58 +0900 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 Content-Transfer-Encoding: 7bit i definitely support using XML. If we are going to have multiple authors all contributing to the draft, I suggest we set up some sort of source control. a. On 3 apr 2004, at 11.27, Jamal Hadi Salim wrote: > For the documentation scheme, my suggestion is to use the XML variant > although i am not sure how you could show any updates using XML. > The advantage with that is some of us dont own any MS products but need > to be able to update the doc. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 21:48:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19897 for ; Fri, 2 Apr 2004 21:48:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bCt-0005Ei-0Y for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 21:48:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i332mQ87020124 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 21:48:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bCs-0005EV-RD for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 21:48:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19888 for ; Fri, 2 Apr 2004 21:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bCp-0004wJ-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:48:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bC5-0004op-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:47:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bBS-0004hV-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bBV-0004f9-9r; Fri, 02 Apr 2004 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bB2-0004Z3-Az for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 21:46:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19835 for ; Fri, 2 Apr 2004 21:46:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bAz-0004gp-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:46:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bA3-0004Ys-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:45:31 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B9b9Y-0004Qw-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:45:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040218471536:27202 ; Fri, 2 Apr 2004 18:47:15 -0800 Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <1080959240.1036.13.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1080960299.1036.27.camel@jzny.localdomain> 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 04/02/2004 06:47:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/02/2004 06:47:16 PM, Serialize complete at 04/02/2004 06:47:16 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Apr 2004 21:44:59 -0500 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-02 at 21:37, avri@acm.org wrote: > i definitely support using XML. > > If we are going to have multiple authors all contributing to the draft, > I suggest we set up some sort of source control. Good idea. Since XML is text based, i think CVS should do. Would it be painful for some people? I use it all the time but dont wanna force it on people. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 21:57:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20222 for ; Fri, 2 Apr 2004 21:57:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bLe-0008AV-R4 for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 21:57:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i332vUkQ031395 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 21:57:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bLe-0008AI-KB for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 21:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20217 for ; Fri, 2 Apr 2004 21:57:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bLb-00062f-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:57:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bKg-0005w0-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:56:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bKA-0005oy-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 21:55:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bKD-0007T7-4F; Fri, 02 Apr 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bJb-0007O0-Ev for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 21:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20138 for ; Fri, 2 Apr 2004 21:55:20 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bJY-0005me-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:55:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bIi-0005g3-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:54:28 -0500 Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx with esmtp (Exim 4.12) id 1B9bIF-0005YT-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 21:53:59 -0500 Received: from [129.254.191.55] (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8H2TYZ1; Sat, 3 Apr 2004 11:55:32 +0900 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1080960299.1036.27.camel@jzny.localdomain> References: <1080959240.1036.13.camel@jzny.localdomain> <1080960299.1036.27.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10391E6F-851A-11D8-9DCF-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: setting up the draft Re: [Fwd: Re: [Forces-protocol] ... - timeline!] To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 Apr 2004 11:53:19 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am fine with CVS, though I am rusty so could whoever set it up send out some brief and basic instructions for CVS net use. In terms of the XML, it is relatively easy to set it up to include separate files. Once we have the outline, I can set up the base xml files and include files for the subsections - already have stubs I use so it should be easy. a. On 3 apr 2004, at 11.44, Jamal Hadi Salim wrote: > On Fri, 2004-04-02 at 21:37, avri@acm.org wrote: >> i definitely support using XML. >> >> If we are going to have multiple authors all contributing to the >> draft, >> I suggest we set up some sort of source control. > > Good idea. > Since XML is text based, i think CVS should do. Would it be painful for > some people? I use it all the time but dont wanna force it on people. > > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 22:13:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20635 for ; Fri, 2 Apr 2004 22:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bb2-0005LV-Lh for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 22:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i333DOSY020545 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 22:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bb2-0005LI-Hu for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 22:13:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20608 for ; Fri, 2 Apr 2004 22:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9baz-0000Ho-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:13:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9ba2-0000As-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:12:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bZe-00004H-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bZh-00055Z-1w; Fri, 02 Apr 2004 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bZ9-00051H-3M for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 22:11:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20572 for ; Fri, 2 Apr 2004 22:11:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bZ6-00002C-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:11:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bYA-0007fz-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:10:27 -0500 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1B9bXc-0007Yz-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:09:52 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040219120633:27218 ; Fri, 2 Apr 2004 19:12:06 -0800 Subject: Re: setting up the draft Re: [Fwd: Re: [Forces-protocol] ... - timeline!] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <10391E6F-851A-11D8-9DCF-000393CC2112@acm.org> References: <1080959240.1036.13.camel@jzny.localdomain> <1080960299.1036.27.camel@jzny.localdomain> <10391E6F-851A-11D8-9DCF-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1080961790.1042.38.camel@jzny.localdomain> 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 04/02/2004 07:12:06 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/02/2004 07:12:08 PM, Serialize complete at 04/02/2004 07:12:08 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 Apr 2004 22:09:50 -0500 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-02 at 21:53, avri@acm.org wrote: > I am fine with CVS, though I am rusty so could whoever set it up send > out some brief and basic instructions for CVS net use. > > In terms of the XML, it is relatively easy to set it up to include > separate files. Once we have the outline, I can set up the base xml > files and include files for the subsections - already have stubs I use > so it should be easy. If you can do include files, the need for CVS may die since manageability of versioning is reduced to smaller files. Do you use the M Rose XML2rfc package? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 2 22:21:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20881 for ; Fri, 2 Apr 2004 22:21:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bip-0007xT-Cr for forces-protocol-archive@odin.ietf.org; Fri, 02 Apr 2004 22:21:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i333LR0U030583 for forces-protocol-archive@odin.ietf.org; Fri, 2 Apr 2004 22:21:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bip-0007wz-9B for forces-protocol-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 22:21:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20857 for ; Fri, 2 Apr 2004 22:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bim-0001Kl-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:21:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bht-0001D0-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:20:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9bhP-00015X-00 for forces-protocol-web-archive@ietf.org; Fri, 02 Apr 2004 22:19:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bhR-0007Sz-Lm; Fri, 02 Apr 2004 22:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9bgs-0007Nj-Ja for forces-protocol@optimus.ietf.org; Fri, 02 Apr 2004 22:19:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20781 for ; Fri, 2 Apr 2004 22:19:23 -0500 (EST) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9bgp-00013o-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9bft-0000w1-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:18:25 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B9bez-0000om-00 for forces-protocol@ietf.org; Fri, 02 Apr 2004 22:17:29 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B9bf0-000BQK-AH for forces-protocol@ietf.org; Sat, 03 Apr 2004 03:17:30 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1080961790.1042.38.camel@jzny.localdomain> References: <1080959240.1036.13.camel@jzny.localdomain> <1080960299.1036.27.camel@jzny.localdomain> <10391E6F-851A-11D8-9DCF-000393CC2112@acm.org> <1080961790.1042.38.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6EB5C66F-851D-11D8-9DCF-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: setting up the draft Re: [Fwd: Re: [Forces-protocol] ... - timeline!] To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 3 Apr 2004 12:17:26 +0900 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 Content-Transfer-Encoding: 7bit On 3 apr 2004, at 12.09, Jamal Hadi Salim wrote: > On Fri, 2004-04-02 at 21:53, avri@acm.org wrote: >> I am fine with CVS, though I am rusty so could whoever set it up send >> out some brief and basic instructions for CVS net use. >> >> In terms of the XML, it is relatively easy to set it up to include >> separate files. Once we have the outline, I can set up the base xml >> files and include files for the subsections - already have stubs I use >> so it should be easy. > > If you can do include files, the need for CVS may die since > manageability of versioning is reduced to smaller files. > Do you use the M Rose XML2rfc package? > > Yes, though I do sometime used a hacked up version that includes some numbering improvements and some equation support - which I don't think we will need for this effort. the basic xml2rfc package includes the include support. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 07:13:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25821 for ; Sun, 4 Apr 2004 07:13:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA5YX-0000xJ-AG for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 07:13:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34BCdop003564 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 07:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA5YM-0000uW-TA for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 07:12:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25795 for ; Sun, 4 Apr 2004 07:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA5YH-0001Le-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:12:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA5XK-0001GO-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:11:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA5XB-0001BC-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:11:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA5X3-0000Vf-0A; Sun, 04 Apr 2004 07:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA5WR-0000Po-15 for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 07:10:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25721 for ; Sun, 4 Apr 2004 07:10:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA5WM-0001AV-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:10:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA5VZ-00014w-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:09:46 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BA5Uy-0000xx-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:09:09 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 4 Apr 2004 19:20:58 +0800 Message-ID: <002401c41a34$d88baaf0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 19:06:14 +0800 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 autolearn=no version=2.60 Hi Hormuzd, That's a workable plan I think, only with the first outline date - 9th may seem a little hurry. I suggest it be 20th, leaving only one month for individual writing. I suppose it's enough to make it in a month. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All IETF 60th meeting starts Aug 1st... Working backwards, we should have our 00 draft submitted by July 1st atleast. Considering it would need to be reviewed atleast once before submission I would go for distributing the draft on the mailing list for review by June 15th. That gives us about 2.5 months to get the draft done. Some intermediate milestones could be... 1. Outline, 2. Complete discussion of major issues, 3. Complete writing of major sections, 4. Send to mailing list for external review, 5. Submission to IETF Here are some suggested dates. 1. Outline done - April' 9th 2. Complete discussion of major issues - April' 30th 2.b. Discussion on mailing list of any contentious issues - ? 3.a. Complete writing of major sections - May' 20th 3.b. Distribute sections for internal review - May'21st 3.c. Incorporate comments from protocol team - June 1st 4. Send to ForCES mailing list for external review - June 2nd 5. Submission to IETF - June 15th If we can hit these dates, we will be well ahead of schedule :-) Let me know what you guys think. Jamal, I'll start by responding to your text on HA over the weekend. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David The first task of the team is to come up with proposed dates for a first draft to be presented to the working group, along with any intermediate milestones (outline done etc.). _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 07:45:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26826 for ; Sun, 4 Apr 2004 07:45:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA63a-0000fc-AA for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 07:45:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34BiiGV002488 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 07:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA63P-0000d0-M4 for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 07:44:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26806 for ; Sun, 4 Apr 2004 07:44:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA63H-0004zI-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:44:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA62W-0004u4-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:43:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA61q-0004nT-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 07:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA61g-0000MO-LQ; Sun, 04 Apr 2004 07:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA5vY-0007mz-Rp for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 07:36:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26633 for ; Sun, 4 Apr 2004 07:36:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA5vY-000436-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:36:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA5ua-0003x6-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:35:37 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BA5tm-0003kj-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 07:34:46 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 4 Apr 2004 19:46:29 +0800 Message-ID: <004201c41a38$68bd1750$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> <002401c41a34$d88baaf0$845c21d2@Necom.hzic.edu.cn> Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 19:31:44 +0800 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 autolearn=no version=2.60 And moreover, I suggest the pahse 2 and 2.b for issue discussions may be divided into two sub-phases, one is for issues related to the draft outline work, the other is for more specific issues. The first sub-phase discussions should end before 20th when the outline comes, the second may continue along with the draft writing. I also think we need to distribute the writing tasks among the individuals immediately after the outline is reached so as to speed the writing. Jamal, because the TML is separeated from the current PL work, do you think we need to go through the issues again, or to come with a new list which is more relavent to current PL work, or just continue with the remained issue list? Thank you. Weiming ----- Original Message ----- From: "Wang,Weiming" To: > Hi Hormuzd, > > That's a workable plan I think, only with the first outline date - 9th may seem > a little hurry. I suggest it be 20th, leaving only one month for individual > writing. I suppose it's enough to make it in a month. > > Thank you. > Weiming > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Hi All > > IETF 60th meeting starts Aug 1st... > Working backwards, we should have our 00 draft submitted by July 1st > atleast. > Considering it would need to be reviewed atleast once before submission > I would go for distributing the draft on the mailing list for review by > June 15th. > That gives us about 2.5 months to get the draft done. > > Some intermediate milestones could be... > 1. Outline, 2. Complete discussion of major issues, 3. Complete writing > of major sections, 4. Send to mailing list for external review, 5. > Submission to IETF > > Here are some suggested dates. > 1. Outline done - April' 9th > 2. Complete discussion of major issues - April' 30th > 2.b. Discussion on mailing list of any contentious issues - ? > 3.a. Complete writing of major sections - May' 20th > 3.b. Distribute sections for internal review - May'21st > 3.c. Incorporate comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th > > If we can hit these dates, we will be well ahead of schedule :-) > > Let me know what you guys think. > Jamal, I'll start by responding to your text on HA over the weekend. > > Thanks > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David > > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 09:39:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29046 for ; Sun, 4 Apr 2004 09:39:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA7pf-0001dX-11 for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 09:38:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34DcdHI006292 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 09:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA7pe-0001dP-RX for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 09:38:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29042 for ; Sun, 4 Apr 2004 09:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA7pd-0000uq-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 09:38:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA7og-0000pl-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 09:37:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA7o3-0000kf-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 09:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA7o4-0001P5-Iz; Sun, 04 Apr 2004 09:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA7nj-0001Iy-3x for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 09:36:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29018 for ; Sun, 4 Apr 2004 09:36:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA7nh-0000k5-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 09:36:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA7mk-0000et-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 09:35:39 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BA7m5-0000TD-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 09:34:57 -0400 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 4 Apr 2004 21:46:09 +0800 Message-ID: <007f01c41a49$3253bd20$6f01a8c0@dlg> From: "Ligang Dong" To: References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> <002401c41a34$d88baaf0$845c21d2@Necom.hzic.edu.cn> <004201c41a38$68bd1750$845c21d2@Necom.hzic.edu.cn> Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 21:31:54 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksIA0KDQpCYXNlZCBvbiB0aGUgb3BpbmlvbiBvZiBIb3JtdXpkIGFuZCBXZWltaW5nLCB0aGUg dXBkYXRlZCBkYXRlcyBhcmUgYXMgZm9sbG93cy4NCg0KMS5CZWZvcmUgQXByaWwgOXRoLA0KICBh LiBBIGluaXRpYWwgb3V0bGluZSBkb25lDQogIGIuIGRlY2lkZSB3aGV0aGVyIGFuZCBob3cgd2Ug dXNlIFhNTCBhbmQvb3IgQ1ZTDQoyLkJlZm9yZSBBcHJpbCAzMHRoLA0KICBhLiBXb3JrIG91dCBh IGZpbmFsIGFuZCBkZXRhaWxlZCBvdXRsaW5lLCBhbmQgY29tcGxldGUgZGlzY3Vzc2lvbiBvZiBt YWpvciBpc3N1ZXMNCiAgYi4gRGlzdHJpYnV0ZSBzZWN0aW9ucyBmb3IgaW5kaXZpZHVhbCB3cml0 aW5nDQogICAgIChEdXJpbmcgdGhlIHdyaXRpbmcsIGRpc2N1c3Npb24gb24gbWFpbGluZyBsaXN0 IG9mIGFueSBjb250ZW50aW91cyBpc3N1ZXMgY29udGludWVzKQ0KMy5hLiBDb21wbGV0ZSB3cml0 aW5nIG9mIGVhY2ggc2VjdGlvbnMgLSBNYXknIDIwdGgNCiAgYi4gRGlzdHJpYnV0ZSBzZWN0aW9u cyBmb3IgaW50ZXJuYWwgcmV2aWV3IC0gTWF5JzIxc3QNCiAgYy4gSW5jb3Jwb3JhdGUgc2VjdGlv bnMgYW5kIGNvbW1lbnRzIGZyb20gcHJvdG9jb2wgdGVhbSAtIEp1bmUgMXN0DQo0LiBTZW5kIHRv IEZvckNFUyBtYWlsaW5nIGxpc3QgZm9yIGV4dGVybmFsIHJldmlldyAtIEp1bmUgMm5kDQo1LiBT dWJtaXNzaW9uIHRvIElFVEYgLSBKdW5lIDE1dGgNCg0KYW55IGNvbW1lbnRzPw0KTGlnYW5nDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJXYW5nLFdlaW1pbmciIDx3 bXdhbmdAbWFpbC5oemljLmVkdS5jbj4NClRvOiA8Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPg0K U2VudDogU3VuZGF5LCBBcHJpbCAwNCwgMjAwNCA3OjMxIFBNDQpTdWJqZWN0OiBSZTogW0ZvcmNl cy1wcm90b2NvbF0gRm9yQ0VTIFByb3RvY29sIERlc2lnbiBUZWFtIGZpcnN0IHRhc2sgLSB0aW1l bGluZSENCg0KDQo+IEFuZCBtb3Jlb3ZlciwgSSBzdWdnZXN0IHRoZSBwYWhzZSAyIGFuZCAyLmIg Zm9yIGlzc3VlIGRpc2N1c3Npb25zIG1heSBiZSBkaXZpZGVkDQo+IGludG8gdHdvIHN1Yi1waGFz ZXMsIG9uZSBpcyBmb3IgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0IG91dGxpbmUgd29yaywg dGhlDQo+IG90aGVyIGlzIGZvciBtb3JlIHNwZWNpZmljIGlzc3Vlcy4gVGhlIGZpcnN0IHN1Yi1w aGFzZSBkaXNjdXNzaW9ucyBzaG91bGQgZW5kDQo+IGJlZm9yZSAyMHRoIHdoZW4gdGhlIG91dGxp bmUgY29tZXMsIHRoZSBzZWNvbmQgbWF5IGNvbnRpbnVlIGFsb25nIHdpdGggdGhlIGRyYWZ0DQo+ IHdyaXRpbmcuIEkgYWxzbyB0aGluayB3ZSBuZWVkIHRvIGRpc3RyaWJ1dGUgdGhlIHdyaXRpbmcg dGFza3MgYW1vbmcgdGhlDQo+IGluZGl2aWR1YWxzIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBvdXRs aW5lIGlzIHJlYWNoZWQgc28gYXMgdG8gc3BlZWQgdGhlIHdyaXRpbmcuDQo+IA0KPiBKYW1hbCwN Cj4gYmVjYXVzZSB0aGUgVE1MIGlzIHNlcGFyZWF0ZWQgZnJvbSB0aGUgY3VycmVudCBQTCB3b3Jr LCBkbyB5b3UgdGhpbmsgd2UgbmVlZCB0bw0KPiBnbyB0aHJvdWdoIHRoZSBpc3N1ZXMgYWdhaW4s ICBvciB0byBjb21lIHdpdGggYSBuZXcgbGlzdCAgd2hpY2ggaXMgbW9yZSByZWxhdmVudA0KPiB0 byBjdXJyZW50IFBMIHdvcmssIG9yIGp1c3QgY29udGludWUgd2l0aCB0aGUgcmVtYWluZWQgaXNz dWUgbGlzdD8NCj4gDQo+IFRoYW5rIHlvdS4NCj4gV2VpbWluZw0KPiANCj4gLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiV2FuZyxXZWltaW5nIiA8d213YW5nQG1haWwuaHpp Yy5lZHUuY24+DQo+IFRvOiA8Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPg0KPiANCj4gPiBIaSBI b3JtdXpkLA0KPiA+DQo+ID4gVGhhdCdzIGEgd29ya2FibGUgcGxhbiBJIHRoaW5rLCBvbmx5IHdp dGggdGhlIGZpcnN0IG91dGxpbmUgZGF0ZSAtIDl0aCBtYXkNCj4gc2VlbQ0KPiA+IGEgbGl0dGxl IGh1cnJ5LiAgSSBzdWdnZXN0IGl0IGJlIDIwdGgsIGxlYXZpbmcgb25seSBvbmUgbW9udGggZm9y IGluZGl2aWR1YWwNCj4gPiB3cml0aW5nLiBJIHN1cHBvc2UgIGl0J3MgZW5vdWdoIHRvIG1ha2Ug aXQgaW4gYSBtb250aC4NCj4gPg0KPiA+IFRoYW5rIHlvdS4NCj4gPiBXZWltaW5nDQo+ID4NCj4g PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIktob3NyYXZpLCBIb3Jt dXpkIE0iIDxob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tPg0KPiA+DQo+ID4gSGkgQWxsDQo+ ID4NCj4gPiBJRVRGIDYwdGggbWVldGluZyBzdGFydHMgQXVnIDFzdC4uLg0KPiA+IFdvcmtpbmcg YmFja3dhcmRzLCB3ZSBzaG91bGQgaGF2ZSBvdXIgMDAgZHJhZnQgc3VibWl0dGVkIGJ5IEp1bHkg MXN0DQo+ID4gYXRsZWFzdC4NCj4gPiBDb25zaWRlcmluZyBpdCB3b3VsZCBuZWVkIHRvIGJlIHJl dmlld2VkIGF0bGVhc3Qgb25jZSBiZWZvcmUgc3VibWlzc2lvbg0KPiA+IEkgd291bGQgZ28gZm9y IGRpc3RyaWJ1dGluZyB0aGUgZHJhZnQgb24gdGhlIG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGJ5 DQo+ID4gSnVuZSAxNXRoLg0KPiA+IFRoYXQgZ2l2ZXMgdXMgYWJvdXQgMi41IG1vbnRocyB0byBn ZXQgdGhlIGRyYWZ0IGRvbmUuDQo+ID4NCj4gPiBTb21lIGludGVybWVkaWF0ZSBtaWxlc3RvbmVz IGNvdWxkIGJlLi4uDQo+ID4gMS4gT3V0bGluZSwgMi4gQ29tcGxldGUgZGlzY3Vzc2lvbiBvZiBt YWpvciBpc3N1ZXMsIDMuIENvbXBsZXRlIHdyaXRpbmcNCj4gPiBvZiBtYWpvciBzZWN0aW9ucywg NC4gU2VuZCB0byBtYWlsaW5nIGxpc3QgZm9yIGV4dGVybmFsIHJldmlldywgNS4NCj4gPiBTdWJt aXNzaW9uIHRvIElFVEYNCj4gPg0KPiA+IEhlcmUgYXJlIHNvbWUgc3VnZ2VzdGVkIGRhdGVzLg0K PiA+IDEuIE91dGxpbmUgZG9uZSAtIEFwcmlsJyA5dGgNCj4gPiAyLiBDb21wbGV0ZSBkaXNjdXNz aW9uIG9mIG1ham9yIGlzc3VlcyAtIEFwcmlsJyAzMHRoDQo+ID4gMi5iLiBEaXNjdXNzaW9uIG9u IG1haWxpbmcgbGlzdCBvZiBhbnkgY29udGVudGlvdXMgaXNzdWVzIC0gPw0KPiA+IDMuYS4gQ29t cGxldGUgd3JpdGluZyBvZiBtYWpvciBzZWN0aW9ucyAtIE1heScgMjB0aA0KPiA+IDMuYi4gRGlz dHJpYnV0ZSBzZWN0aW9ucyBmb3IgaW50ZXJuYWwgcmV2aWV3IC0gTWF5JzIxc3QNCj4gPiAzLmMu IEluY29ycG9yYXRlIGNvbW1lbnRzIGZyb20gcHJvdG9jb2wgdGVhbSAtIEp1bmUgMXN0DQo+ID4g NC4gU2VuZCB0byBGb3JDRVMgbWFpbGluZyBsaXN0IGZvciBleHRlcm5hbCByZXZpZXcgLSBKdW5l IDJuZA0KPiA+IDUuIFN1Ym1pc3Npb24gdG8gSUVURiAtIEp1bmUgMTV0aA0KPiA+DQo+ID4gSWYg d2UgY2FuIGhpdCB0aGVzZSBkYXRlcywgd2Ugd2lsbCBiZSB3ZWxsIGFoZWFkIG9mIHNjaGVkdWxl IDotKQ0KPiA+DQo+ID4gTGV0IG1lIGtub3cgd2hhdCB5b3UgZ3V5cyB0aGluay4NCj4gPiBKYW1h bCwgSSdsbCBzdGFydCBieSByZXNwb25kaW5nIHRvIHlvdXIgdGV4dCBvbiBIQSBvdmVyIHRoZSB3 ZWVrZW5kLg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4gSG9ybXV6ZA0KPiA+DQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBmb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0Zi5v cmcNCj4gPiBbbWFpbHRvOmZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFB1dHpvbHUsIERhdmlkDQo+ID4NCj4gPiBUaGUgZmlyc3QgdGFzayBvZiB0aGUgdGVhbSBp cyB0byBjb21lIHVwIHdpdGgNCj4gPiBwcm9wb3NlZCBkYXRlcyBmb3IgYSBmaXJzdCBkcmFmdCB0 byBiZSBwcmVzZW50ZWQNCj4gPiB0byB0aGUgd29ya2luZyBncm91cCwgYWxvbmcgd2l0aCBhbnkg aW50ZXJtZWRpYXRlDQo+ID4gbWlsZXN0b25lcyAob3V0bGluZSBkb25lIGV0Yy4pLg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBG b3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQo+ID4gRm9yY2VzLXByb3RvY29sQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3Rv Y29sDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQo+ID4gRm9y Y2VzLXByb3RvY29sQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZm9yY2VzLXByb3RvY29sDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZvcmNlcy1wcm90b2NvbCBtYWlsaW5n IGxpc3QNCj4gRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbA0KPiA= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 11:03:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02294 for ; Sun, 4 Apr 2004 11:03:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA996-0003WR-Fw for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 11:02:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34F2m08013540 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 11:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA996-0003WJ-6K for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 11:02:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02268 for ; Sun, 4 Apr 2004 11:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA993-0002DS-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:02:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA98I-00025Z-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:01:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA97K-0001vt-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA97M-0003Ea-RF; Sun, 04 Apr 2004 11:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA978-0003Dt-Vh for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 11:00:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02213 for ; Sun, 4 Apr 2004 11:00:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA976-0001tn-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 11:00:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA969-0001ny-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 10:59:46 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BA95x-0001iO-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 10:59:33 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040408013951:28161 ; Sun, 4 Apr 2004 08:01:39 -0700 Subject: Discussion direction WAS(IRe: [Forces-protocol] ForCES Protocol Design Team first task - timeline! From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <004201c41a38$68bd1750$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> <002401c41a34$d88baaf0$845c21d2@Necom.hzic.edu.cn> <004201c41a38$68bd1750$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1081090764.2023.85.camel@jzny.localdomain> 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 04/04/2004 08:01:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/04/2004 08:01:46 AM, Serialize complete at 04/04/2004 08:01:46 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Apr 2004 10:59:24 -0400 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 Content-Transfer-Encoding: 7bit On Sun, 2004-04-04 at 07:31, Wang,Weiming wrote: > Jamal, > because the TML is separeated from the current PL work, do you think we need to > go through the issues again, or to come with a new list which is more relavent > to current PL work, or just continue with the remained issue list? You make a good point on PL vs TML; I think we already went over a lot of the TML related ones though - its actually by going over those issues that we reached a conclusion a TML is needed ;-> We need to have good talking points to drive whatever dates we are trying to set. From this perspective, I think the list is a good starting point. Thoughts? Maybe a rewrite of that list to fit different categories would be appropriate? Heres a annotated rerun: 0) ID on the header. 1) Encoding Above are PL specific 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability Above are TML related 8) Capability exchange Above is PL specific 9) The FEM/CEM interface PL but more administrative than protocol. Would influence some things in PL. 10) Support for vendor functions PL 11) Cross check with model draft before it is published Administrative 12) Master Slave or peer-peer? PL - Very important in my opinion because will influence some PL decisions. I dont think above is exhaustive rather a good starting point like i pointed earlier. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 11:14:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02449 for ; Sun, 4 Apr 2004 11:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9Jm-0005LI-Sj for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 11:13:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34FDotB020534 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 11:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9Jm-0005L7-Me for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 11:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02438 for ; Sun, 4 Apr 2004 11:13:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA9Jl-0003E7-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:13:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA9Il-00038E-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:12:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA9Hz-00032o-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 11:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9I1-00053T-5L; Sun, 04 Apr 2004 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9Hq-00053E-6j for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 11:11:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02412 for ; Sun, 4 Apr 2004 11:11:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA9Hn-00032O-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 11:11:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA9Gj-0002xG-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 11:10:41 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BA9G9-0002sQ-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 11:10:05 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040408121787:28165 ; Sun, 4 Apr 2004 08:12:17 -0700 Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Ligang Dong Cc: forces-protocol@ietf.org In-Reply-To: <007f01c41a49$3253bd20$6f01a8c0@dlg> References: <468F3FDA28AA87429AD807992E22D07E6FF54C@orsmsx408.jf.intel.com> <002401c41a34$d88baaf0$845c21d2@Necom.hzic.edu.cn> <004201c41a38$68bd1750$845c21d2@Necom.hzic.edu.cn> <007f01c41a49$3253bd20$6f01a8c0@dlg> Organization: ZNYX Networks Message-Id: <1081091403.2030.97.camel@jzny.localdomain> 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 04/04/2004 08:12:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/04/2004 08:12:19 AM, Serialize complete at 04/04/2004 08:12:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 04 Apr 2004 11:10:03 -0400 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 Content-Transfer-Encoding: 7bit On Sun, 2004-04-04 at 09:31, Ligang Dong wrote: > hi, > > Based on the opinion of Hormuzd and Weiming, the updated dates are as follows. > > 1.Before April 9th, > a. A initial outline done I think we should finish the remaining issues discussion first quickly first before going into any outlines. > b. decide whether and how we use XML and/or CVS Hopefully it shouldnt take a few days to decide that. If we decide to go CVS i can create the environment and send instructions to people. > 2.Before April 30th, > a. Work out a final and detailed outline, and complete discussion of major issues > b. Distribute sections for individual writing > (During the writing, discussion on mailing list of any contentious issues continues) Reasonable > 3.a. Complete writing of each sections - May' 20th > b. Distribute sections for internal review - May'21st I would hope there will a continous feedback as opposed to someone dissapearing with a section and showing up later with contentious text. > c. Incorporate sections and comments from protocol team - June 1st This is where we may need a merger (not editor). > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th Looks good overall. I didnt see any difference from what Hormuzd posted originally though. I am optimistic we could beat most of these deadlines. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 4 19:07:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15139 for ; Sun, 4 Apr 2004 19:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAGhe-0007pK-Hl for forces-protocol-archive@odin.ietf.org; Sun, 04 Apr 2004 19:06:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i34N6wqP030087 for forces-protocol-archive@odin.ietf.org; Sun, 4 Apr 2004 19:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAGhe-0007pC-Cd for forces-protocol-web-archive@optimus.ietf.org; Sun, 04 Apr 2004 19:06:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15125 for ; Sun, 4 Apr 2004 19:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAGhZ-0000eJ-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 19:06:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAGgb-0000Yc-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 19:05:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAGfg-0000U7-00 for forces-protocol-web-archive@ietf.org; Sun, 04 Apr 2004 19:04:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAGfl-0007cr-FT; Sun, 04 Apr 2004 19:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAGfk-0007cL-Cy for forces-protocol@optimus.ietf.org; Sun, 04 Apr 2004 19:05:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15102 for ; Sun, 4 Apr 2004 19:04:53 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAGff-0000Tw-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 19:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAGej-0000PB-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 19:03:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BAGeC-0000K0-00 for forces-protocol@ietf.org; Sun, 04 Apr 2004 19:03:24 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i34N3F801536; Mon, 5 Apr 2004 02:03:15 +0300 (EET DST) X-Scanned: Mon, 5 Apr 2004 02:02:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i34N2tlI027810; Mon, 5 Apr 2004 02:02:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00tab7k9; Mon, 05 Apr 2004 02:02:54 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i34N2qs24341; Mon, 5 Apr 2004 02:02:52 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 4 Apr 2004 18:02:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Can you change my add my personal email address Thread-Index: AcQYD2hBmHxRAIBfSl2g5R3YLl2f1AA+kE9AAGO625A= To: , X-OriginalArrivalTime: 04 Apr 2004 23:02:51.0752 (UTC) FILETIME=[F4CB1E80:01C41A98] Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Can you change my add my personal email address Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 19:02:48 -0400 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello David, Can you add this email address to the list lrgpal@yahoo.com - somehow I'm missing many emails - I tend to get to know the discussion only from thread of emails....=20 I need to check the configuration of my personal spam filter - to see why this is happening. =20 Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org [mailto:forces-protocol- > admin@ietf.org] On Behalf Of ext Khosravi, Hormuzd M > Sent: Friday, April 02, 2004 6:43 PM > To: Putzolu, David; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - > timeline! >=20 > Hi All >=20 > IETF 60th meeting starts Aug 1st... > Working backwards, we should have our 00 draft submitted by July 1st > atleast. > Considering it would need to be reviewed atleast once before submission > I would go for distributing the draft on the mailing list for review by > June 15th. > That gives us about 2.5 months to get the draft done. >=20 > Some intermediate milestones could be... > 1. Outline, 2. Complete discussion of major issues, 3. Complete writing > of major sections, 4. Send to mailing list for external review, 5. > Submission to IETF >=20 > Here are some suggested dates. > 1. Outline done - April' 9th > 2. Complete discussion of major issues - April' 30th > 2.b. Discussion on mailing list of any contentious issues - ? > 3.a. Complete writing of major sections - May' 20th > 3.b. Distribute sections for internal review - May'21st > 3.c. Incorporate comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th >=20 > If we can hit these dates, we will be well ahead of schedule :-) >=20 > Let me know what you guys think. > Jamal, I'll start by responding to your text on HA over the weekend. >=20 > Thanks > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >=20 > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 02:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14112 for ; Mon, 5 Apr 2004 02:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1h-0005LX-Jl for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 02:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i356u9YD020540 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 02:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1g-0005LD-Dg for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 02:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14046 for ; Mon, 5 Apr 2004 02:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO1c-0003nD-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:56:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO0R-0003Ya-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:54:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BANz6-0003AL-02 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:53:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANz5-0004ex-C5; Mon, 05 Apr 2004 02:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANw1-0004Au-Qc for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 02:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13786 for ; Mon, 5 Apr 2004 02:50:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANvx-0002xD-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:50:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANv2-0002rW-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:49:16 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BANuG-0002fl-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:48:28 -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 i356qRqT028453; Mon, 5 Apr 2004 06:52:27 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 i356oFAm011426; Mon, 5 Apr 2004 06:50:20 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 M2004040423475509718 ; Sun, 04 Apr 2004 23:47:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Apr 2004 23:47:55 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task- timeline!] Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF754@orsmsx408.jf.intel.com> Thread-Topic: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task- timeline!] Thread-Index: AcQZI7lpTkGigAbuSp+0kJPGZWg65wBtdFZw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 05 Apr 2004 06:47:55.0910 (UTC) FILETIME=[ECF7BA60:01C41AD9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 23:47:55 -0700 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 Content-Transfer-Encoding: quoted-printable Hi All, I am a big fan of CVS, will be happy to use it for source control. I haven't used XML personally for writing drafts, but if it is not too much work and I can reuse code from Avri/Jamal, I'll be happy to use that. Thanks Hormuzd -----Forwarded Message----- From: Jamal Hadi Salim David, This is the old list, no? For a move forward i would suggest that we complete the issues list from earlier and then go into details of each. I would like to suggest that the above get done by the 3rd of may (gives us a month) and also time to pass things onto the mailing list for review before san diego. I would also like to suggest a method where everyone is contributing to the text as opposed to having a single editor. This maybe what the model people did, not sure. It worked very well for us in the netlink2 draft; i also didnt like the way the requirements draft went with a single editor - so i am hoping to avoid a repeat of any issues that came up then (at least from me) in order to focus the energies on the issues. For the documentation scheme, my suggestion is to use the XML variant although i am not sure how you could show any updates using XML.=20 The advantage with that is some of us dont own any MS products but need to be able to update the doc. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 02:57:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14257 for ; Mon, 5 Apr 2004 02:57:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO2j-0005Y0-4O for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 02:57:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i356vDQx021316 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 02:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO2i-0005Xj-TZ for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 02:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14211 for ; Mon, 5 Apr 2004 02:57:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO2f-00041F-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:57:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO1i-0003sE-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:56:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAO0X-0003Zi-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:54:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO0b-00054I-2G; Mon, 05 Apr 2004 02:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO02-0004w6-Dt for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 02:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13846 for ; Mon, 5 Apr 2004 02:54:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANzy-0003TI-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANys-0003G6-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:53:15 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BANy7-00033t-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:52:27 -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 i356sRUI009379; Mon, 5 Apr 2004 06:54:27 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 i356sBAs013697; Mon, 5 Apr 2004 06:54:17 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 M2004040423515410179 ; Sun, 04 Apr 2004 23:51:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Apr 2004 23:51:54 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Discussion direction WAS(IRe: [Forces-protocol] ForCES ProtocolDesign Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF759@orsmsx408.jf.intel.com> Thread-Topic: Discussion direction WAS(IRe: [Forces-protocol] ForCES ProtocolDesign Team first task - timeline! Thread-Index: AcQaVaVbWWdU3yXLS/STJ02FQ1RSIgAhG0Qg From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 05 Apr 2004 06:51:54.0521 (UTC) FILETIME=[7B30E090:01C41ADA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 23:51:54 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, Lets go with this list below which you have suggested for discussion. Also, I think HA is partially part of PL...I'll reply to your previous text in more detail. Regards=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim We need to have good talking points to drive whatever dates we are trying to set. From this perspective, I think the list is a good starting point. Thoughts? Maybe a rewrite of that list to fit different categories would be appropriate? Heres a annotated rerun: 0) ID on the header. 1) Encoding Above are PL specific 2) Multiple channels/connections 3) Transport: unicast/multicast/broadcast=20 { TCP, UDP, SCTP, DCCP, Direct over L2 or proprietary backplanes, TIPC} 4) Congestion control 5) Reliability 6) Security 7) High availability Above are TML related 8) Capability exchange Above is PL specific 9) The FEM/CEM interface PL but more administrative than protocol. Would influence some things in PL. 10) Support for vendor functions PL=20 11) Cross check with model draft before it is published Administrative 12) Master Slave or peer-peer? PL - Very important in my opinion because will influence some PL decisions. I dont think above is exhaustive rather a good starting point like i pointed earlier. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 03:45:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14113 for ; Mon, 5 Apr 2004 02:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1h-0005LY-Jq for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 02:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i356u9p7020547 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 02:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1h-0005LK-6t for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 02:56:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14049 for ; Mon, 5 Apr 2004 02:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO1d-0003nI-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:56:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO0S-0003Yi-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:54:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BANz6-0003AL-03 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 02:53:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANz3-0004dw-NI; Mon, 05 Apr 2004 02:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANqS-0003lp-8O for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 02:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13619 for ; Mon, 5 Apr 2004 02:44:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANqO-0002N5-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANpQ-0002GF-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:43:29 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BANov-000289-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 02:42:57 -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 i356kuqT024446; Mon, 5 Apr 2004 06:46:56 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 i356iWAs007312; Mon, 5 Apr 2004 06:44:49 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 M2004040423422608961 ; Sun, 04 Apr 2004 23:42:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Apr 2004 23:42:26 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: FW: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF752@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQYD2hBmHxRAIBfSl2g5R3YLl2f1AA+kE9AAGOvSkAAADEfQAAP8/kg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 Apr 2004 06:42:26.0732 (UTC) FILETIME=[28C326C0:01C41AD9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 4 Apr 2004 23:42:26 -0700 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 Content-Transfer-Encoding: quoted-printable Forwarding this email, since I didn't see it on the mailing list. -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Sunday, April 04, 2004 4:05 PM To: Khosravi, Hormuzd M; Putzolu, David Subject: FW: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Resending again. -----Original Message----- From: Gopal Ram (Nokia-NRC/Boston)=20 Sent: Sunday, April 04, 2004 7:00 PM To: 'ext Khosravi, Hormuzd M'; Putzolu, David; forces-protocol@ietf.org Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Hello Hormuzd, Timline seems ok - but everyone is going to work parallely may be we need to have regular meeting. Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org [mailto:forces-protocol- > admin@ietf.org] On Behalf Of ext Khosravi, Hormuzd M > Sent: Friday, April 02, 2004 6:43 PM > To: Putzolu, David; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - > timeline! >=20 > Hi All >=20 > IETF 60th meeting starts Aug 1st... > Working backwards, we should have our 00 draft submitted by July 1st > atleast. > Considering it would need to be reviewed atleast once before submission > I would go for distributing the draft on the mailing list for review by > June 15th. > That gives us about 2.5 months to get the draft done. >=20 > Some intermediate milestones could be... > 1. Outline, 2. Complete discussion of major issues, 3. Complete writing > of major sections, 4. Send to mailing list for external review, 5. > Submission to IETF >=20 > Here are some suggested dates. > 1. Outline done - April' 9th > 2. Complete discussion of major issues - April' 30th > 2.b. Discussion on mailing list of any contentious issues - ? > 3.a. Complete writing of major sections - May' 20th > 3.b. Distribute sections for internal review - May'21st > 3.c. Incorporate comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th >=20 > If we can hit these dates, we will be well ahead of schedule :-) >=20 > Let me know what you guys think. > Jamal, I'll start by responding to your text on HA over the weekend. >=20 > Thanks > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David >=20 > The first task of the team is to come up with > proposed dates for a first draft to be presented > to the working group, along with any intermediate > milestones (outline done etc.). >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 04:20:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16851 for ; Mon, 5 Apr 2004 04:20:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKg-0001Q9-Uw for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 04:19:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i358JonF005458 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 04:19:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPKg-0001Px-Eq for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 04:19:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16716 for ; Mon, 5 Apr 2004 04:19:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAPKd-0005AK-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 04:19:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAPJU-0004xw-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 04:18:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAPIM-0004fH-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 04:17:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAPI0-0000V6-1o; Mon, 05 Apr 2004 04:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO8g-0006JT-3u for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 03:03:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14429 for ; Mon, 5 Apr 2004 03:03:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO8c-0004g5-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 03:03:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO7l-0004a7-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 03:02:26 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAO74-0004RN-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 03:01:42 -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 i3573iUI015085; Mon, 5 Apr 2004 07:03:44 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 i3572wAw019273; Mon, 5 Apr 2004 07:03:34 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 M2004040500011016848 ; Mon, 05 Apr 2004 00:01:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 00:01:11 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E6FF75D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQaOlpqLLMF3Z2hRyO8trMsyFyjaAAoOaLA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 05 Apr 2004 07:01:11.0415 (UTC) FILETIME=[C7202870:01C41ADB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 00:01:11 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, I don't believe a rough outline or table of contents for the draft should take more than a week. I agree that it will evolve and might change as we get into more revisions and refinements. I'll send out a rough outline by tomorrow. Regards=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Sunday, April 04, 2004 4:32 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! And moreover, I suggest the pahse 2 and 2.b for issue discussions may be divided into two sub-phases, one is for issues related to the draft outline work, the other is for more specific issues. The first sub-phase discussions should end before 20th when the outline comes, the second may continue along with the draft writing. I also think we need to distribute the writing tasks among the individuals immediately after the outline is reached so as to speed the writing. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 08:01:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25784 for ; Mon, 5 Apr 2004 08:01:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASmI-00070B-5A for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 08:00:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35C0YV1026916 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 08:00:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASmI-000703-0a for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:00:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25773 for ; Mon, 5 Apr 2004 08:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASmH-0000t4-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 08:00:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASlb-0000mF-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 07:59:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BASkm-0000eG-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 07:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASkm-0006jJ-7g; Mon, 05 Apr 2004 07:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BASkG-0006bc-LB for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 07:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25643 for ; Mon, 5 Apr 2004 07:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BASkF-0000bI-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 07:58:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BASjL-0000T3-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 07:57:32 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BASiL-0000E1-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 07:56:34 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Mon, 5 Apr 2004 20:06:26 +0800 Message-ID: <012601c41b04$5b2ab080$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <1080959240.1036.13.camel@jzny.localdomain> Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 19:51:39 +0800 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 autolearn=no version=2.60 I'm fine with XML either. Talking about CVS or XML2RFC include, I suggest we check to see XML2rfc first. If it can meet all requirements for us, we then go with it, or else, I'm afraid we have to use CVS. Seems only the new version of xml2rfc contains the include? Weiming ----- Original Message ----- From: To: Sent: Saturday, April 03, 2004 10:37 AM Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] > i definitely support using XML. > > If we are going to have multiple authors all contributing to the draft, > I suggest we set up some sort of source control. > > a. > > On 3 apr 2004, at 11.27, Jamal Hadi Salim wrote: > > > For the documentation scheme, my suggestion is to use the XML variant > > although i am not sure how you could show any updates using XML. > > The advantage with that is some of us dont own any MS products but need > > to be able to update the doc. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 08:38:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27267 for ; Mon, 5 Apr 2004 08:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATMa-00064r-JZ for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 08:38:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35Cc4GG023357 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 08:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATMa-00064e-Et for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 08:38:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27247 for ; Mon, 5 Apr 2004 08:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATMZ-0005Ta-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 08:38:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATLk-0005I9-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 08:37:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BATKa-00053o-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 08:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATKb-0005eB-24; Mon, 05 Apr 2004 08:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATK9-0005b4-68 for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 08:35:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26975 for ; Mon, 5 Apr 2004 08:35:30 -0400 (EDT) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATK7-0004yj-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 08:35:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATIL-0004iU-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 08:33:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BATHQ-0004Z9-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 08:32:44 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BATHP-0003vc-D8 for forces-protocol@ietf.org; Mon, 05 Apr 2004 12:32:43 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <012601c41b04$5b2ab080$845c21d2@Necom.hzic.edu.cn> References: <1080959240.1036.13.camel@jzny.localdomain> <012601c41b04$5b2ab080$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55346674-86FD-11D8-9DCF-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 21:32:42 +0900 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 Content-Transfer-Encoding: 7bit On 5 apr 2004, at 20.51, Wang,Weiming wrote: > Seems only the new version of > xml2rfc contains the include? I have used it for at least the last 2 versions. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 09:26:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29568 for ; Mon, 5 Apr 2004 09:26:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAU6f-0006jB-SM for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 09:25:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35DPfWG025862 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 09:25:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAU6f-0006j3-N8 for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 09:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29487 for ; Mon, 5 Apr 2004 09:25:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAU6e-0004Qt-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 09:25:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAU5o-0004G0-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 09:24:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAU47-00040w-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 09:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAU45-0006Dz-3p; Mon, 05 Apr 2004 09:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAU3u-0006CH-Gy for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 09:22:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29365 for ; Mon, 5 Apr 2004 09:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAU3s-0003zP-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 09:22:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAU33-0003q7-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 09:21:58 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BAU2N-0003fi-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 09:21:15 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Mon, 5 Apr 2004 21:32:47 +0800 Message-ID: <01a401c41b10$6ad16130$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <1080959240.1036.13.camel@jzny.localdomain> Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task- timeline!] 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 21:17:54 +0800 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 autolearn=no version=2.60 Hi all, Talking about editor(s), I'd like to put some opinions as follows, 1) I'm afraid we need editor(s) anyway, sooner or later, provided we have a quite big team. In this case, as Avri mentioned, my opinion is also that we need to have it set before we begin the draft writing. I don't think it is very reasonable and acceptable to have it set after the draft is finished. To set editor(s) ASAP will definitely speed up the team work. 2) From the history of the former three candidate protocols and the experiences of the merge process discussions, I have a stron feeling that we should firstly try to have three editors/writers, one from each former candidate protocols, for the first 00 draft. This is the most efficient, the most reasonable, and probably most acceptable scheme for current work, I think. 3) In the case the 2) scheme can not work well or even can not be concensused, we then need to choose a neutral editor for the current work. I don't think in this case, a non neutral editor can work well provided 2) scheme can not work, (also given the past experiences of others), therefore it should be definitely precluded at any time. Anyway, let's decide it now in order to speed up the process. Yours, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Saturday, April 03, 2004 10:27 AM Subject: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task- timeline!] > Heres an email i sent earlier that for some odd reason didnt > make it. > Hormuzds has made similar comments and may give more reason to why > the editing should be distributed. > > cheers, > jamal > > -----Forwarded Message----- > > From: Jamal Hadi Salim > To: "Putzolu, David" > Cc: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline! > Date: 02 Apr 2004 11:59:01 -0500 > > David, > This is the old list, no? > For a move forward i would suggest that we complete the issues list > from earlier and then go into details of each. > I would like to suggest that the above get done by the 3rd of may > (gives us a month) and also time to pass things onto > the mailing list for review before san diego. > I would also like to suggest a method where everyone is contributing to > the text as opposed to having a single editor. This maybe what the model > people did, not sure. It worked very well for us in the netlink2 draft; > i also didnt like the way the requirements draft went with a single > editor - so i am hoping to avoid a repeat of any issues that came up > then (at least from me) in order to focus the energies on the issues. > > For the documentation scheme, my suggestion is to use the XML variant > although i am not sure how you could show any updates using XML. > The advantage with that is some of us dont own any MS products but need > to be able to update the doc. > > > cheers, > jamal > > On Thu, 2004-04-01 at 12:33, Putzolu, David wrote: > > Hi all. > > > > Welcome to the ForCES protocol design team. > > > > Patrick & I have constituted this team to create a > > proposed ForCES protocol draft. Please note that: > > > > * This document will be an individual contribution > > until the WG has a chance to review and accept it. > > > > * The draft presented to the WG does not need to > > be complete, but it does need to have enough > > content to allow the WG to say, "we (disagree|agree) > > with the fundamental direction and approach taken > > in this draft." > > > > * All work by the design team should be visible to > > the ForCES mailing list and the design team mailing > > list archive is publicly accessible. > > > > * Non-members of the design team may (and hopefully > > will!) provide input and contribute to the work > > of the design team. > > > > * The design team has been made a small group in > > order to allow for rapid progress & effective > > communication. As such, if you are working with > > people outside the design team, please ensure > > that their contributions are up to date with > > current design team thinking & consensus. > > > > I'm sure more will come to mind. :) > > > > The first task of the team is to come up with > > proposed dates for a first draft to be presented > > to the working group, along with any intermediate > > milestones (outline done etc.). > > > > Thanks! > > -David > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 5 20:02:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24931 for ; Mon, 5 Apr 2004 20:02:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAe2H-0005mx-IF for forces-protocol-archive@odin.ietf.org; Mon, 05 Apr 2004 20:01:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3601n6G022252 for forces-protocol-archive@odin.ietf.org; Mon, 5 Apr 2004 20:01:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAe2H-0005mp-7w for forces-protocol-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 20:01:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24887 for ; Mon, 5 Apr 2004 20:01:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAe2F-0001Ot-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 20:01:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAdk2-0006K9-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 19:43:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAdGz-0003Sl-00 for forces-protocol-web-archive@ietf.org; Mon, 05 Apr 2004 19:12:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdH0-0002Tl-Oj; Mon, 05 Apr 2004 19:12:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdGA-0002Kt-TG for forces-protocol@optimus.ietf.org; Mon, 05 Apr 2004 19:12:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20752 for ; Mon, 5 Apr 2004 19:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAdG9-0003Ie-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 19:12:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcx5-0000md-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 18:52:25 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAcVL-0005ZP-00 for forces-protocol@ietf.org; Mon, 05 Apr 2004 18:23:43 -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 i35MRLqT014739 for ; Mon, 5 Apr 2004 22:27:22 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 i35MP5Am013043 for ; Mon, 5 Apr 2004 22:25:12 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 M2004040515224710957 for ; Mon, 05 Apr 2004 15:22:47 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 15:22:47 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQaSeuenIAeFRwiTreDoqKPTwd3iwBElYIA From: "Putzolu, David" To: X-OriginalArrivalTime: 05 Apr 2004 22:22:47.0175 (UTC) FILETIME=[85F78970:01C41B5C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 15:22:46 -0700 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: base64 Content-Transfer-Encoding: base64 U28ganVzdCB0byBiZSBjbGVhciwgaXMgZXZlcnlib2R5IE9LIHdpdGggdGhlIGRhdGVzIGJlbG93 IHRoYXQNCkxpZ2FuZyBzZW50IG91dD8NCg0KSSdkIGxpa2UgdG8gcHVibGlzaCB0aGlzIChvciBh biB1cGRhdGVkIHZlcnNpb24gb2YgdGhlKSB0aW1lbGluZSANCmJlbG93IHRvIHRoZSBGb3JDRVMg bGlzdC4NCg0KUGxlYXNlIHNwZWFrIHVwIGJlZm9yZSBUdWVzZGF5IDNwbSBQU1QgaWYgeW91IG9i amVjdCAtIGhlYXJpbmcgDQpzaWxlbmNlLCBJIHdpbGwgcHVibGlzaCBpdCBhbmQgeW91IHdpbGwg YWxsIGJlIG9uIHRoZSBob29rIDopDQoNClNlbmQgbWUgYSBkaXJlY3QgZW1haWwgaWYgeW91IG9i amVjdCB0byBwdWJsaXNoaW5nIGl0IC0gdGhlIGxpc3Qgc2VlbXMNCnRvIGJlIG9wZXJhdGluZyBz bG93bHkuIEkndmUgc2VudCBhIG5vdGUgdG8gdGhlIEZvcmV0ZWMgZ3V5cyBhc2tpbmcgd2h5Lg0K DQotRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBmb3JjZXMt cHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmcgDQo+IFttYWlsdG86Zm9yY2VzLXByb3RvY29sLWFkbWlu QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGlnYW5nIERvbmcNCj4gU2VudDogU3VuZGF5LCBBcHJp bCAwNCwgMjAwNCA2OjMyIEFNDQo+IFRvOiBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIEZvckNFUyBQcm90b2NvbCBEZXNpZ24gVGVhbSAN Cj4gZmlyc3QgdGFzayAtIHRpbWVsaW5lIQ0KPiANCj4gaGksIA0KPiANCj4gQmFzZWQgb24gdGhl IG9waW5pb24gb2YgSG9ybXV6ZCBhbmQgV2VpbWluZywgdGhlIHVwZGF0ZWQgDQo+IGRhdGVzIGFy ZSBhcyBmb2xsb3dzLg0KPiANCj4gMS5CZWZvcmUgQXByaWwgOXRoLA0KPiAgIGEuIEEgaW5pdGlh bCBvdXRsaW5lIGRvbmUNCj4gICBiLiBkZWNpZGUgd2hldGhlciBhbmQgaG93IHdlIHVzZSBYTUwg YW5kL29yIENWUw0KPiAyLkJlZm9yZSBBcHJpbCAzMHRoLA0KPiAgIGEuIFdvcmsgb3V0IGEgZmlu YWwgYW5kIGRldGFpbGVkIG91dGxpbmUsIGFuZCBjb21wbGV0ZSANCj4gZGlzY3Vzc2lvbiBvZiBt YWpvciBpc3N1ZXMNCj4gICBiLiBEaXN0cmlidXRlIHNlY3Rpb25zIGZvciBpbmRpdmlkdWFsIHdy aXRpbmcNCj4gICAgICAoRHVyaW5nIHRoZSB3cml0aW5nLCBkaXNjdXNzaW9uIG9uIG1haWxpbmcg bGlzdCBvZiBhbnkgDQo+IGNvbnRlbnRpb3VzIGlzc3VlcyBjb250aW51ZXMpDQo+IDMuYS4gQ29t cGxldGUgd3JpdGluZyBvZiBlYWNoIHNlY3Rpb25zIC0gTWF5JyAyMHRoDQo+ICAgYi4gRGlzdHJp YnV0ZSBzZWN0aW9ucyBmb3IgaW50ZXJuYWwgcmV2aWV3IC0gTWF5JzIxc3QNCj4gICBjLiBJbmNv cnBvcmF0ZSBzZWN0aW9ucyBhbmQgY29tbWVudHMgZnJvbSBwcm90b2NvbCB0ZWFtIC0gSnVuZSAx c3QNCj4gNC4gU2VuZCB0byBGb3JDRVMgbWFpbGluZyBsaXN0IGZvciBleHRlcm5hbCByZXZpZXcg LSBKdW5lIDJuZA0KPiA1LiBTdWJtaXNzaW9uIHRvIElFVEYgLSBKdW5lIDE1dGgNCj4gDQo+IGFu eSBjb21tZW50cz8NCj4gTGlnYW5nDQo+IA0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCj4gRnJvbTogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPg0K PiBUbzogPGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZz4NCj4gU2VudDogU3VuZGF5LCBBcHJpbCAw NCwgMjAwNCA3OjMxIFBNDQo+IFN1YmplY3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSBGb3JDRVMg UHJvdG9jb2wgRGVzaWduIFRlYW0gDQo+IGZpcnN0IHRhc2sgLSB0aW1lbGluZSENCj4gDQo+IA0K PiA+IEFuZCBtb3Jlb3ZlciwgSSBzdWdnZXN0IHRoZSBwYWhzZSAyIGFuZCAyLmIgZm9yIGlzc3Vl IA0KPiBkaXNjdXNzaW9ucyBtYXkgYmUgZGl2aWRlZA0KPiA+IGludG8gdHdvIHN1Yi1waGFzZXMs IG9uZSBpcyBmb3IgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0IA0KPiBvdXRsaW5lIHdvcmss IHRoZQ0KPiA+IG90aGVyIGlzIGZvciBtb3JlIHNwZWNpZmljIGlzc3Vlcy4gVGhlIGZpcnN0IHN1 Yi1waGFzZSANCj4gZGlzY3Vzc2lvbnMgc2hvdWxkIGVuZA0KPiA+IGJlZm9yZSAyMHRoIHdoZW4g dGhlIG91dGxpbmUgY29tZXMsIHRoZSBzZWNvbmQgbWF5IGNvbnRpbnVlIA0KPiBhbG9uZyB3aXRo IHRoZSBkcmFmdA0KPiA+IHdyaXRpbmcuIEkgYWxzbyB0aGluayB3ZSBuZWVkIHRvIGRpc3RyaWJ1 dGUgdGhlIHdyaXRpbmcgDQo+IHRhc2tzIGFtb25nIHRoZQ0KPiA+IGluZGl2aWR1YWxzIGltbWVk aWF0ZWx5IGFmdGVyIHRoZSBvdXRsaW5lIGlzIHJlYWNoZWQgc28gYXMgDQo+IHRvIHNwZWVkIHRo ZSB3cml0aW5nLg0KPiA+IA0KPiA+IEphbWFsLA0KPiA+IGJlY2F1c2UgdGhlIFRNTCBpcyBzZXBh cmVhdGVkIGZyb20gdGhlIGN1cnJlbnQgUEwgd29yaywgZG8gDQo+IHlvdSB0aGluayB3ZSBuZWVk IHRvDQo+ID4gZ28gdGhyb3VnaCB0aGUgaXNzdWVzIGFnYWluLCAgb3IgdG8gY29tZSB3aXRoIGEg bmV3IGxpc3QgIA0KPiB3aGljaCBpcyBtb3JlIHJlbGF2ZW50DQo+ID4gdG8gY3VycmVudCBQTCB3 b3JrLCBvciBqdXN0IGNvbnRpbnVlIHdpdGggdGhlIHJlbWFpbmVkIGlzc3VlIGxpc3Q/DQo+ID4g DQo+ID4gVGhhbmsgeW91Lg0KPiA+IFdlaW1pbmcNCj4gPiANCj4gPiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0BtYWlsLmh6aWMu ZWR1LmNuPg0KPiA+IFRvOiA8Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPg0KPiA+IA0KPiA+ID4g SGkgSG9ybXV6ZCwNCj4gPiA+DQo+ID4gPiBUaGF0J3MgYSB3b3JrYWJsZSBwbGFuIEkgdGhpbmss IG9ubHkgd2l0aCB0aGUgZmlyc3QgDQo+IG91dGxpbmUgZGF0ZSAtIDl0aCBtYXkNCj4gPiBzZWVt DQo+ID4gPiBhIGxpdHRsZSBodXJyeS4gIEkgc3VnZ2VzdCBpdCBiZSAyMHRoLCBsZWF2aW5nIG9u bHkgb25lIA0KPiBtb250aCBmb3IgaW5kaXZpZHVhbA0KPiA+ID4gd3JpdGluZy4gSSBzdXBwb3Nl ICBpdCdzIGVub3VnaCB0byBtYWtlIGl0IGluIGEgbW9udGguDQo+ID4gPg0KPiA+ID4gVGhhbmsg eW91Lg0KPiA+ID4gV2VpbWluZw0KPiA+ID4NCj4gPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCj4gPiA+IEZyb206ICJLaG9zcmF2aSwgSG9ybXV6ZCBNIiA8aG9ybXV6ZC5tLmtob3Ny YXZpQGludGVsLmNvbT4NCj4gPiA+DQo+ID4gPiBIaSBBbGwNCj4gPiA+DQo+ID4gPiBJRVRGIDYw dGggbWVldGluZyBzdGFydHMgQXVnIDFzdC4uLg0KPiA+ID4gV29ya2luZyBiYWNrd2FyZHMsIHdl IHNob3VsZCBoYXZlIG91ciAwMCBkcmFmdCBzdWJtaXR0ZWQgDQo+IGJ5IEp1bHkgMXN0DQo+ID4g PiBhdGxlYXN0Lg0KPiA+ID4gQ29uc2lkZXJpbmcgaXQgd291bGQgbmVlZCB0byBiZSByZXZpZXdl ZCBhdGxlYXN0IG9uY2UgDQo+IGJlZm9yZSBzdWJtaXNzaW9uDQo+ID4gPiBJIHdvdWxkIGdvIGZv ciBkaXN0cmlidXRpbmcgdGhlIGRyYWZ0IG9uIHRoZSBtYWlsaW5nIGxpc3QgDQo+IGZvciByZXZp ZXcgYnkNCj4gPiA+IEp1bmUgMTV0aC4NCj4gPiA+IFRoYXQgZ2l2ZXMgdXMgYWJvdXQgMi41IG1v bnRocyB0byBnZXQgdGhlIGRyYWZ0IGRvbmUuDQo+ID4gPg0KPiA+ID4gU29tZSBpbnRlcm1lZGlh dGUgbWlsZXN0b25lcyBjb3VsZCBiZS4uLg0KPiA+ID4gMS4gT3V0bGluZSwgMi4gQ29tcGxldGUg ZGlzY3Vzc2lvbiBvZiBtYWpvciBpc3N1ZXMsIDMuIA0KPiBDb21wbGV0ZSB3cml0aW5nDQo+ID4g PiBvZiBtYWpvciBzZWN0aW9ucywgNC4gU2VuZCB0byBtYWlsaW5nIGxpc3QgZm9yIGV4dGVybmFs IHJldmlldywgNS4NCj4gPiA+IFN1Ym1pc3Npb24gdG8gSUVURg0KPiA+ID4NCj4gPiA+IEhlcmUg YXJlIHNvbWUgc3VnZ2VzdGVkIGRhdGVzLg0KPiA+ID4gMS4gT3V0bGluZSBkb25lIC0gQXByaWwn IDl0aA0KPiA+ID4gMi4gQ29tcGxldGUgZGlzY3Vzc2lvbiBvZiBtYWpvciBpc3N1ZXMgLSBBcHJp bCcgMzB0aA0KPiA+ID4gMi5iLiBEaXNjdXNzaW9uIG9uIG1haWxpbmcgbGlzdCBvZiBhbnkgY29u dGVudGlvdXMgaXNzdWVzIC0gPw0KPiA+ID4gMy5hLiBDb21wbGV0ZSB3cml0aW5nIG9mIG1ham9y IHNlY3Rpb25zIC0gTWF5JyAyMHRoDQo+ID4gPiAzLmIuIERpc3RyaWJ1dGUgc2VjdGlvbnMgZm9y IGludGVybmFsIHJldmlldyAtIE1heScyMXN0DQo+ID4gPiAzLmMuIEluY29ycG9yYXRlIGNvbW1l bnRzIGZyb20gcHJvdG9jb2wgdGVhbSAtIEp1bmUgMXN0DQo+ID4gPiA0LiBTZW5kIHRvIEZvckNF UyBtYWlsaW5nIGxpc3QgZm9yIGV4dGVybmFsIHJldmlldyAtIEp1bmUgMm5kDQo+ID4gPiA1LiBT dWJtaXNzaW9uIHRvIElFVEYgLSBKdW5lIDE1dGgNCj4gPiA+DQo+ID4gPiBJZiB3ZSBjYW4gaGl0 IHRoZXNlIGRhdGVzLCB3ZSB3aWxsIGJlIHdlbGwgYWhlYWQgb2Ygc2NoZWR1bGUgOi0pDQo+ID4g Pg0KPiA+ID4gTGV0IG1lIGtub3cgd2hhdCB5b3UgZ3V5cyB0aGluay4NCj4gPiA+IEphbWFsLCBJ J2xsIHN0YXJ0IGJ5IHJlc3BvbmRpbmcgdG8geW91ciB0ZXh0IG9uIEhBIG92ZXIgDQo+IHRoZSB3 ZWVrZW5kLg0KPiA+ID4NCj4gPiA+IFRoYW5rcw0KPiA+ID4gSG9ybXV6ZA0KPiA+ID4NCj4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBmb3JjZXMtcHJvdG9jb2wt YWRtaW5AaWV0Zi5vcmcNCj4gPiA+IFttYWlsdG86Zm9yY2VzLXByb3RvY29sLWFkbWluQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgDQo+IFB1dHpvbHUsIERhdmlkDQo+ID4gPg0KPiA+ID4gVGhlIGZp cnN0IHRhc2sgb2YgdGhlIHRlYW0gaXMgdG8gY29tZSB1cCB3aXRoDQo+ID4gPiBwcm9wb3NlZCBk YXRlcyBmb3IgYSBmaXJzdCBkcmFmdCB0byBiZSBwcmVzZW50ZWQNCj4gPiA+IHRvIHRoZSB3b3Jr aW5nIGdyb3VwLCBhbG9uZyB3aXRoIGFueSBpbnRlcm1lZGlhdGUNCj4gPiA+IG1pbGVzdG9uZXMg KG91dGxpbmUgZG9uZSBldGMuKS4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRm9yY2VzLXByb3RvY29sIG1haWxpbmcg bGlzdA0KPiA+ID4gRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wNCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQo+ID4gPiBGb3JjZXMtcHJv dG9jb2xAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ZvcmNlcy1wcm90b2NvbA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRm9yY2VzLXByb3RvY29sIG1h aWxpbmcgbGlzdA0KPiA+IEZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbA0KPiA+IBblpp/nm5vl hpZZ5aWo5L+L56KvceawmOWqn+Wih+ahqQjnqJXvo7UMPiA/fuWpoGbmnYXuoJ0/772X7oWA7p6G 4oiIDQo+IA0K _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 04:10:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17938 for ; Tue, 6 Apr 2004 04:10:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlef-0002Ta-3W for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 04:09:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3689vGr009519 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 04:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlee-0002TS-NA for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:09:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17818 for ; Tue, 6 Apr 2004 04:09:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAlec-0002TW-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 04:09:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAl9K-0007Jr-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:37:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAkxC-0005qA-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkxD-00018m-Pz; Tue, 06 Apr 2004 03:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkwW-0000y6-6b for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 03:24:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15659 for ; Tue, 6 Apr 2004 03:24:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkwT-0005in-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAkif-0003A1-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:10:02 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkAs-00000c-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 02:35:06 -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 i366d7j1029410; Tue, 6 Apr 2004 06:39:07 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 i366aPa9012853; Tue, 6 Apr 2004 06:36:55 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 M2004040523343000595 ; Mon, 05 Apr 2004 23:34:30 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 23:34:30 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] Message-ID: <468F3FDA28AA87429AD807992E22D07E786AE1@orsmsx408.jf.intel.com> Thread-Topic: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] Thread-Index: AcQbBZZJj9cGHIZoRvuPlB3jsqlsmQAm0gOg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 06 Apr 2004 06:34:30.0814 (UTC) FILETIME=[378193E0:01C41BA1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 23:34:30 -0700 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 Content-Transfer-Encoding: quoted-printable XML is for writing/formatting the draft, cvs is for version/source control. These are 2 separate functions, I believe. Avri, Jamal am I misunderstanding something ? -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Monday, April 05, 2004 4:52 AM To: forces-protocol@ietf.org Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] I'm fine with XML either. Talking about CVS or XML2RFC include, I suggest we check to see XML2rfc first. If it can meet all requirements for us, we then go with it, or else, I'm afraid we have to use CVS. Seems only the new version of xml2rfc contains the include? Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 04:10:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18003 for ; Tue, 6 Apr 2004 04:10:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlet-0002Yz-49 for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 04:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368AB2S009843 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 04:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAles-0002Yd-Qj for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:10:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17871 for ; Tue, 6 Apr 2004 04:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAleq-0002VW-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 04:10:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAl9n-0007MU-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:38:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAkxG-0005qJ-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkxF-00019H-65; Tue, 06 Apr 2004 03:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkww-00015R-Dm for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 03:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15702 for ; Tue, 6 Apr 2004 03:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkwt-0005mr-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:24:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAkjU-0003Jn-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:10:53 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkDb-0000Df-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 02:37:55 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i366ftj1031011 for ; Tue, 6 Apr 2004 06:41:55 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 i366Ts9n018797 for ; Tue, 6 Apr 2004 06:29:58 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 M2004040523372400633 for ; Mon, 05 Apr 2004 23:37:24 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 23:37:24 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Message-ID: <468F3FDA28AA87429AD807992E22D07E786AE2@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] ForCES Protocol Design Team first task - timeline! Thread-Index: AcQaSeuenIAeFRwiTreDoqKPTwd3iwBElYIAABFL40A= From: "Khosravi, Hormuzd M" To: "Putzolu, David" , X-OriginalArrivalTime: 06 Apr 2004 06:37:24.0581 (UTC) FILETIME=[9F145150:01C41BA1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 23:37:24 -0700 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 Content-Transfer-Encoding: quoted-printable David I am fine with the timeline below. Regards=20 Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Putzolu, David Sent: Monday, April 05, 2004 3:23 PM To: forces-protocol@ietf.org Subject: RE: [Forces-protocol] ForCES Protocol Design Team first task - timeline! So just to be clear, is everybody OK with the dates below that Ligang sent out? I'd like to publish this (or an updated version of the) timeline=20 below to the ForCES list. Please speak up before Tuesday 3pm PST if you object - hearing=20 silence, I will publish it and you will all be on the hook :) Send me a direct email if you object to publishing it - the list seems to be operating slowly. I've sent a note to the Foretec guys asking why. -David > -----Original Message----- > From: forces-protocol-admin@ietf.org=20 > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Ligang Dong > Sent: Sunday, April 04, 2004 6:32 AM > To: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] ForCES Protocol Design Team=20 > first task - timeline! >=20 > hi,=20 >=20 > Based on the opinion of Hormuzd and Weiming, the updated=20 > dates are as follows. >=20 > 1.Before April 9th, > a. A initial outline done > b. decide whether and how we use XML and/or CVS > 2.Before April 30th, > a. Work out a final and detailed outline, and complete=20 > discussion of major issues > b. Distribute sections for individual writing > (During the writing, discussion on mailing list of any=20 > contentious issues continues) > 3.a. Complete writing of each sections - May' 20th > b. Distribute sections for internal review - May'21st > c. Incorporate sections and comments from protocol team - June 1st > 4. Send to ForCES mailing list for external review - June 2nd > 5. Submission to IETF - June 15th >=20 > any comments? > Ligang >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 04:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19545 for ; Tue, 6 Apr 2004 04:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAllW-0005MA-9n for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 04:17:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368H2Dc020591 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 04:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAllV-0005Lr-WF for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19403 for ; Tue, 6 Apr 2004 04:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAllT-0003k4-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 04:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlQf-0000rO-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:55:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAkz6-0006Dj-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkz8-0001gW-6e; Tue, 06 Apr 2004 03:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkyB-0001TY-UI for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 03:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16104 for ; Tue, 6 Apr 2004 03:26:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAky9-00061Q-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:26:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAknq-00048M-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:15:23 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkPx-0001AN-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 02:50:41 -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 i366qX7e019029 for ; Tue, 6 Apr 2004 06:52:34 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 i366gX9l025384 for ; Tue, 6 Apr 2004 06:42:33 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 M2004040523495901811 for ; Mon, 05 Apr 2004 23:49:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 5 Apr 2004 23:49:59 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E786AE5@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQaOlpqLLMF3Z2hRyO8trMsyFyjaAAoOaLAADGnm5A= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 06 Apr 2004 06:49:59.0542 (UTC) FILETIME=[61123960:01C41BA3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Apr 2004 23:49:59 -0700 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 Content-Transfer-Encoding: quoted-printable Here is an initial outline for the draft Abstract 1. Introduction 2. Protocol Overview 3. Common Header 4. Protocol Messages 5. Example Scenarios 6. TML Requirements 7. Security Considerations 8. References 9. Acknowledgments Let me know what you guys think ? We can add more details as we move along. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 04:20:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20384 for ; Tue, 6 Apr 2004 04:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlog-0006uL-9V for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 04:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368KIHL026547 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 04:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAlof-0006tx-VK for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20273 for ; Tue, 6 Apr 2004 04:20:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAlod-0004KB-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 04:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlZc-0001YC-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 04:04:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAl05-0006NH-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 03:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl07-00021S-D0; Tue, 06 Apr 2004 03:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkzR-0001kr-Jm for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 03:27:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16255 for ; Tue, 6 Apr 2004 03:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkzP-0006GX-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:27:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAks2-0004wL-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:19:43 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkbU-00022k-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 03:02:36 -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 i3674W7e026764; Tue, 6 Apr 2004 07:04:32 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 i366sP9p031855; Tue, 6 Apr 2004 06:54:32 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 M2004040600015703063 ; Tue, 06 Apr 2004 00:01:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 00:01:57 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E786AEA@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 7: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgJ+K7Bw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 06 Apr 2004 07:01:57.0928 (UTC) FILETIME=[0D433A80:01C41BA5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 00:01:57 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, Sorry for the delay, see my comments below... -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim This text does not talk about state synchronization or restarts or rollovers. Those details are considered solvable if the discussion below is resolvable. Two levels of HA responsibilities that i see: 1) TML level: a) The TML controls logical connection availability and failover.=20 [HK] Agreed b) The TML also controls peer HA managements. [HK] Not sure what you mean here but any state synchronization needed should be part of the PL. 2) PL Level: Depending on the scheme implemented by the TML level, the PL level may have no role to play i.e HA being transparent to it. [HK] There might be a role for synchronization The TML layer ------------- To describe the detail, a good example would be to show multiple CEs trying to control an FE. [HK] The schemes below seem to be different ways of synchronizing state between CEs and FEs, correct me if I am wrong ? Some of this intelligence should be part of the PL rather than everything being part of TML. Do you agree ? For all three schemes, a heartbeat that terminates at the TML layer=20 is needed for meeting requirement 1). The are three schemes i can think of which i will list here: Scheme 1) Le brute force: The FE TML is aware of the multiple CEs i.e knows their logical connections.=20 It may receive commands from all the CEs but will process the one with=20 highest priority only in given time instances. Protocol requirement: To have priorities in the headers. We already do. Advantages: KISS.=20 Disadvatanges: too much traffic Scheme 2) the Tenor: The FE TML is aware of all CEs controlling it however responds to only one at any one point.=20 Something akin to HA as achieved by SCTP multihoming or some mobility protocols. i.e at some point the current known master is obsoleted for example because of some missing heartbeats or physical disconnect or by explicit instructions to migrate.=20 Protocol requirement:=20 A "move" command to instruct to a migration to a new CE being issued=20 to the FE.=20 Advantages: less traffic Disadvantages: slower in recovery compared to 1). Scheme 3) the soprano: The FE is NOT aware of the CEs unlike 1 and 2 above. The election of which CE is controlling an FE is done elsewhere at the CE level. At any point the controlling CE will use a logical address. This makes it transparent to the FE how many CEs are behind the control point. Very easily doable with a broadcast or multicast protocol. Example protocol which does this is VRRP. Protocol requirement: None, the TML is burdened with providing either multicast or broadcast. In terms of compute requirements on the FE a) > b) > c) In terms of bandwidth requirements on the wire a > b > c _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 16:11:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24180 for ; Tue, 6 Apr 2004 16:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwum-0000zG-KY for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 16:11:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36KBKA3003795 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 16:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwum-0000z7-D6 for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:11:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24035 for ; Tue, 6 Apr 2004 16:11:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwuk-0003b2-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 16:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwJL-0005Dl-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 15:32:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAvTz-0007lo-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 14:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvT4-0002Gy-DD; Tue, 06 Apr 2004 14:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAv4i-0000fa-H1 for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 14:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13498 for ; Tue, 6 Apr 2004 14:13:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAv4g-0003Nm-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 14:13:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAv1f-0002kd-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 14:10:20 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BAuxd-000245-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 14:06:09 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040611082092:30490 ; Tue, 6 Apr 2004 11:08:20 -0700 Subject: RE: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E786AEA@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E786AEA@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1081274762.8373.105.camel@jzny.localdomain> 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 04/06/2004 11:08:21 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/06/2004 11:08:22 AM, Serialize complete at 04/06/2004 11:08:22 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Apr 2004 14:06:02 -0400 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 Content-Transfer-Encoding: 7bit Hi Hormuzd, On Tue, 2004-04-06 at 03:01, Khosravi, Hormuzd M wrote: > Hi Jamal, > > Sorry for the delay, see my comments below... > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > > This text does not talk about state synchronization or restarts > or rollovers. Those details are considered solvable if the > discussion below is resolvable. > > Two levels of HA responsibilities that i see: > > 1) TML level: > > a) The TML controls logical connection availability and failover. > [HK] Agreed > > b) The TML also controls peer HA managements. > [HK] Not sure what you mean here but any state synchronization needed > should be part of the PL. In some of the schemes i mentioned this is true. > 2) PL Level: > > Depending on the scheme implemented by the TML level, the PL > level may have no role to play i.e HA being transparent to it. > [HK] There might be a role for synchronization Yes, this is true for some of the schemes but not all. More below. > The TML layer > ------------- > To describe the detail, a good example would be to show multiple > CEs trying to control an FE. > > [HK] The schemes below seem to be different ways of synchronizing state > between CEs and FEs, correct me if I am wrong ? Some of this > intelligence should be part of the PL rather than everything being part > of TML. Do you agree ? > Theres two things: 1) The management of the links/locgical links/channels etc. This clearly belongs in the TML. 2) If you assume #1 above then next thing is to ask if you can take advantage of that detail in synchronization - this is what the text below attempts to do. For example, the FE PL may be totaly unaware of the fact that there is another FE involved as its backup or that there is a HA a pair of CEs in HA mode controliing it (as in case 3 which i labeled soprano). I have listed the advantages and disadvantages below which i will leave in for clarity. But also refer to #1 and #2 above since they form the basis. > > For all three schemes, a heartbeat that terminates at the TML layer > is needed for meeting requirement 1). The are three schemes i can > think of which i will list here: > > Scheme 1) Le brute force: > The FE TML is aware of the multiple CEs i.e knows their logical > connections. > It may receive commands from all the CEs but will process the one with > highest priority only in given time instances. > > Protocol requirement: To have priorities in the headers. We already do. > > Advantages: KISS. > Disadvatanges: too much traffic > > Scheme 2) the Tenor: > The FE TML is aware of all CEs controlling it however responds to only > one at any one point. > Something akin to HA as achieved by SCTP multihoming or some > mobility protocols. i.e at some point the current known master is > obsoleted for example because of some missing heartbeats or physical > disconnect or by explicit instructions to migrate. > > Protocol requirement: > A "move" command to instruct to a migration to a new CE being issued > to the FE. > > Advantages: less traffic > Disadvantages: slower in recovery compared to 1). > > Scheme 3) the soprano: > The FE is NOT aware of the CEs unlike 1 and 2 above. > The election of which CE is controlling an FE is done elsewhere > at the CE level. > At any point the controlling CE will use a logical address. > This makes it transparent to the FE how many CEs are behind the control > point. Very easily doable with a broadcast or multicast protocol. > Example protocol which does this is VRRP. > > Protocol requirement: None, the TML is burdened with providing either > multicast or broadcast. > > In terms of compute requirements on the FE a) > b) > c) > In terms of bandwidth requirements on the wire a > b > c > cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 18:06:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04601 for ; Tue, 6 Apr 2004 18:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyhw-00049t-2F for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 18:06:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36M6CIF015986 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 18:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyhv-00049i-P4 for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04472 for ; Tue, 6 Apr 2004 18:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyht-0002JK-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:06:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy5O-0003Ri-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 17:26:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAx0S-0004gS-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 16:17:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAx0R-0002ld-Q6 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 16:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAx0Q-0003cb-ES; Tue, 06 Apr 2004 16:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwzv-0003Ph-Mx for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 16:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25496 for ; Tue, 6 Apr 2004 16:16:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwzt-0004a1-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 16:16:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwVJ-0006eJ-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 15:45:01 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BAvcG-0000ki-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 14:48:08 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040611501970:30548 ; Tue, 6 Apr 2004 11:50:19 -0700 Subject: Re: [Forces-protocol] Outline From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E786AE5@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E786AE5@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1081277281.8374.146.camel@jzny.localdomain> 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 04/06/2004 11:50:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/06/2004 11:50:21 AM, Serialize complete at 04/06/2004 11:50:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Apr 2004 14:48:01 -0400 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 Content-Transfer-Encoding: 7bit Hormuzd, Some comments: On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > Here is an initial outline for the draft > > Abstract > 1. Introduction > 2. Protocol Overview > 3. Common Header > 4. Protocol Messages Should we follow with protocol details after this? And should TML move to just below Protocol overview or were you thinking protocol overview contains overview of TML as well? > 5. Example Scenarios > 6. TML Requirements > 7. Security Considerations do security requirements belong to TML as well? > 8. References > 9. Acknowledgments > > Let me know what you guys think ? > We can add more details as we move along. I think its a good start and good idea to have this at this point. We probably shouldnt spend too much time on cosmetics right now because i think we can iron those out as we go on. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 19:46:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13309 for ; Tue, 6 Apr 2004 19:46:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0G4-0005ub-SM for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 19:45:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36NjWPQ022726 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 19:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0G4-0005uT-Jh for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 19:45:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13123 for ; Tue, 6 Apr 2004 19:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0G2-0005JU-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 19:45:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAzR8-0006bG-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:52:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAyQu-0007PV-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 17:48:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyOZ-0002sX-Hq; Tue, 06 Apr 2004 17:46:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyOA-0002d4-Ep for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 17:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01168 for ; Tue, 6 Apr 2004 17:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyO7-0006ul-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 17:45:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAxbB-0000LQ-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 16:55:11 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAwk9-0001Yz-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 16:00:21 -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 i36K4LX0001046; Tue, 6 Apr 2004 20:04:21 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 i36K17a1025207; Tue, 6 Apr 2004 20:02:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004040612594303677 ; Tue, 06 Apr 2004 12:59:43 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 12:59:44 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E78702F@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQcB7h3+T0NDZAcQRqqLMoJ0+LljQACYW7A From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 06 Apr 2004 19:59:44.0143 (UTC) FILETIME=[B47E89F0:01C41C11] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 12:59:43 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, Thanks for your comments. See my replies below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > Here is an initial outline for the draft >=20 > Abstract > 1. Introduction > 2. Protocol Overview > 3. Common Header > 4. Protocol Messages Should we follow with protocol details after this? [HK] Yes And should TML move to just below Protocol overview or were you thinking protocol overview contains overview of TML as well? [HK] I was thinking the latter, i.e. protocol overview will contain overview of TML as well. > 5. Example Scenarios > 6. TML Requirements > 7. Security Considerations do security requirements belong to TML as well? [HK] Yes, I am sure there will be security considerations in the TML doc as well. > 8. References > 9. Acknowledgments >=20 > Let me know what you guys think ? > We can add more details as we move along. I think its a good start and good idea to have this at this point. We probably shouldnt spend too much time on cosmetics right now because i think we can iron those out as we go on. [HK] Agree. So should we publish this as the initial Outline ? I will wait for comments from other folks. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 20:10:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16451 for ; Tue, 6 Apr 2004 20:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0dM-0004QT-Ab for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 20:09:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3709aOX017014 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 20:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0dM-0004QL-75 for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 20:09:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16307 for ; Tue, 6 Apr 2004 20:09:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0dK-0000z6-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 20:09:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAzzf-0002Rz-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 19:28:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAypT-00036N-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:13:59 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAypU-0001lN-Er for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAypV-0008UT-AC; Tue, 06 Apr 2004 18:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyp5-0008La-G4 for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 18:13:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05475 for ; Tue, 6 Apr 2004 18:13:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyp2-00033Q-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 18:13:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy9r-0004ES-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 17:31:00 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BAx8o-0005O0-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 16:25:50 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040613275384:30650 ; Tue, 6 Apr 2004 13:27:53 -0700 Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task- timeline!] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <01a401c41b10$6ad16130$845c21d2@Necom.hzic.edu.cn> References: <1080959240.1036.13.camel@jzny.localdomain> <01a401c41b10$6ad16130$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1081283139.8368.163.camel@jzny.localdomain> 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 04/06/2004 01:27:54 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/06/2004 01:28:03 PM, Serialize complete at 04/06/2004 01:28:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 06 Apr 2004 16:25:39 -0400 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 Content-Transfer-Encoding: 7bit Weiming, On Mon, 2004-04-05 at 09:17, Wang,Weiming wrote: > Hi all, > > Talking about editor(s), I'd like to put some opinions as follows, > > 1) I'm afraid we need editor(s) anyway, sooner or later, provided we have a > quite big team. In this case, as Avri mentioned, my opinion is also that we need > to have it set before we begin the draft writing. I don't think it is very > reasonable and acceptable to have it set after the draft is finished. To set > editor(s) ASAP will definitely speed up the team work. > > 2) From the history of the former three candidate protocols and the experiences > of the merge process discussions, I have a stron feeling that we should firstly > try to have three editors/writers, one from each former candidate protocols, for > the first 00 draft. This is the most efficient, the most reasonable, and > probably most acceptable scheme for current work, I think. Ok, if this is acceptable to others i will go along as well . I do hope we dont end into some deadlocks. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 6 21:04:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18208 for ; Tue, 6 Apr 2004 21:04:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1Tl-0004tt-Eo for forces-protocol-archive@odin.ietf.org; Tue, 06 Apr 2004 21:03:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3713jW3018837 for forces-protocol-archive@odin.ietf.org; Tue, 6 Apr 2004 21:03:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB1Tl-0004tk-0w for forces-protocol-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 21:03:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18135 for ; Tue, 6 Apr 2004 21:03:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB1Ti-0005Wd-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 21:03:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB0Kc-00065k-00 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 19:50:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAzXC-00079V-01 for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:59:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAzNd-0003bV-Rb for forces-protocol-web-archive@ietf.org; Tue, 06 Apr 2004 18:49:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzJa-00079K-AP; Tue, 06 Apr 2004 18:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzJJ-00076U-9b for forces-protocol@optimus.ietf.org; Tue, 06 Apr 2004 18:44:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06959 for ; Tue, 6 Apr 2004 18:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzJF-0005tL-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 18:44:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAyN4-0006ha-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 17:44:39 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BAxYP-0007nZ-00 for forces-protocol@ietf.org; Tue, 06 Apr 2004 16:52: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 i36KsBKL008098; Tue, 6 Apr 2004 20:54:11 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 i36KrwZd030187; Tue, 6 Apr 2004 20:53:58 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 M2004040613513111647 ; Tue, 06 Apr 2004 13:51:32 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 13:51:30 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E7870FA@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 7: HA Thread-Index: AcQcAdmeqrtoS0+iTVGrCONTRi0xGQAFH0Cw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 06 Apr 2004 20:51:30.0026 (UTC) FILETIME=[EFBEACA0:01C41C18] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 6 Apr 2004 13:51:29 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > 2) PL Level: >=20 > Depending on the scheme implemented by the TML level, the PL > level may have no role to play i.e HA being transparent to it. > [HK] There might be a role for synchronization Yes, this is true for some of the schemes but not all. More below. > The TML layer > ------------- > To describe the detail, a good example would be to show multiple > CEs trying to control an FE. >=20 > [HK] The schemes below seem to be different ways of synchronizing state > between CEs and FEs, correct me if I am wrong ? Some of this > intelligence should be part of the PL rather than everything being part > of TML. Do you agree ? >=20 Theres two things: 1) The management of the links/locgical links/channels etc. This clearly belongs in the TML. 2) If you assume #1 above then next thing is to ask if you can take advantage of that detail in synchronization - this is what the text below attempts to do. For example, the FE PL may be totaly unaware of the fact that there is another FE involved as its backup or that there is a HA a pair of CEs in HA mode controliing it (as in case 3 which i labeled soprano). [HK] I agree with #1, here what you mean is things like keep-alive need to be taken care of by the TML. I also agree with the example you have given for #2 that the FE PL doesn't need to be aware of the fact that there are 2 CEs in HA mode controlling it. However, don't you think the CE, CE PL should have some of this intelligence and instruct the CE TML how it should behave ? How would the TML figure this out ?=20 Let me know what you think. May be if we work through a complete use-case, this will be more clear. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 07:42:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13015 for ; Wed, 7 Apr 2004 07:42:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBRO-0003IJ-O7 for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 07:41:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BfwmW012664 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 07:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBRO-0003IB-IF for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12935 for ; Wed, 7 Apr 2004 07:41:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBRN-00011R-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 07:41:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAVn-0000xr-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 06:42:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB96M-0007Mu-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 05:12:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB96P-0008AN-1h for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 05:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB95P-0007qT-SB; Wed, 07 Apr 2004 05:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB95G-0007dj-3c for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 05:10:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29969 for ; Wed, 7 Apr 2004 05:10:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB95C-0007BF-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 05:10:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB89k-0006kZ-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 04:11:33 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BB6kT-0005V2-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 02:41:22 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 7 Apr 2004 14:53:06 +0800 Message-ID: <02e801c41c6a$e6f9d3e0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E786AE1@orsmsx408.jf.intel.com> Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 14:38:13 +0800 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 autolearn=no version=2.60 Hormuzd, You are right, but what we are thinking of is to use the 'include' function for source merge, I suppose. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" XML is for writing/formatting the draft, cvs is for version/source control. These are 2 separate functions, I believe. Avri, Jamal am I misunderstanding something ? -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Monday, April 05, 2004 4:52 AM To: forces-protocol@ietf.org Subject: Re: [Fwd: Re: [Forces-protocol] ForCES Protocol Design Team first task - timeline!] I'm fine with XML either. Talking about CVS or XML2RFC include, I suggest we check to see XML2rfc first. If it can meet all requirements for us, we then go with it, or else, I'm afraid we have to use CVS. Seems only the new version of xml2rfc contains the include? Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 07:43:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13187 for ; Wed, 7 Apr 2004 07:43:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBSC-0003gt-S3 for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 07:42:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37BgmGv014183 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 07:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBBSC-0003gc-LP for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 07:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13115 for ; Wed, 7 Apr 2004 07:42:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBBSB-00019N-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 07:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBAXZ-00017D-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 06:44:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BB97K-0007YD-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 05:13:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BB97M-0008EJ-GX for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 05:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB97I-0008Ls-MP; Wed, 07 Apr 2004 05:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB96g-0008F2-Nx for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 05:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00264 for ; Wed, 7 Apr 2004 05:12:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB96d-0007Po-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 05:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB8CS-00071l-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 04:14:21 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BB6m7-0005f6-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 02:43:04 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 7 Apr 2004 14:54:15 +0800 Message-ID: <030501c41c6b$107c3370$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E786AE5@orsmsx408.jf.intel.com> <1081277281.8374.146.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Outline 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 14:39:23 +0800 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 autolearn=no version=2.60 Hi Hormuzd, Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 08:49:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17458 for ; Wed, 7 Apr 2004 08:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCU8-0000nK-DX for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 08:48:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37CmqtM003051 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 08:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBCU8-0000n8-83 for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 08:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17384 for ; Wed, 7 Apr 2004 08:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBCU6-00000C-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 08:48:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBBOO-0000XD-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 07:38:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBAOX-0000NL-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 06:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAOb-0000Ts-4f; Wed, 07 Apr 2004 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBAOF-0000TQ-Ve for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 06:34:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05007 for ; Wed, 7 Apr 2004 06:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBAOB-0000LX-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 06:34:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BB953-0007Am-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 05:10:45 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BB89Z-0006hK-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 04:11:22 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 7 Apr 2004 16:23:10 +0800 Message-ID: <07ae01c41c77$7b99f5f0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: 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 Subject: [Forces-protocol] Test Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 16:08:16 +0800 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 autolearn=no version=2.60 seems dead again? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 13:39:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16314 for ; Wed, 7 Apr 2004 13:39:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH1M-0002No-JS for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 13:39:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37HdSOc009161 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 13:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGHO-0004qi-H0 for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 12:51:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09629 for ; Wed, 7 Apr 2004 12:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGDR-00036R-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 12:47:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBEkn-0000b8-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 11:14:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBDdv-0000J2-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 10:03:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBDdw-00060s-QI for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 10:03:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDdw-00047e-Fw; Wed, 07 Apr 2004 10:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDdS-0003ca-Bb for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 10:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23285 for ; Wed, 7 Apr 2004 10:02:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDdQ-0000Cu-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 10:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBCV6-00009y-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 08:49:53 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BBBRH-00010f-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 07:41:52 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040704440106:31344 ; Wed, 7 Apr 2004 04:44:01 -0700 Subject: RE: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E7870FA@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E7870FA@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1081338104.15893.64.camel@jzny.localdomain> 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 04/07/2004 04:44:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/07/2004 04:44:03 AM, Serialize complete at 04/07/2004 04:44:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Apr 2004 07:41:45 -0400 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 Content-Transfer-Encoding: 7bit Hormuzd, On Tue, 2004-04-06 at 16:51, Khosravi, Hormuzd M wrote: > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > Theres two things: 1) The management of the links/locgical > links/channels etc. This clearly belongs in the TML. > 2) If you assume #1 above then next thing is to ask if you can take > advantage of that detail in synchronization - this is what the text > below attempts to do. For example, the FE PL may be totaly unaware of > the fact that there is another FE involved as its backup or that there > is a HA a pair of CEs in HA mode controliing it (as in case 3 which i > labeled soprano). > > [HK] I agree with #1, here what you mean is things like keep-alive need > to be taken care of by the TML. Also the failover of those links. Of course keepalive is one scheme for detecting need for failover, but there could be notifications either from the PL (note the "move" example i gave) which could force such a connection failover. > I also agree with the example you have > given for #2 that the FE PL doesn't need to be aware of the fact that > there are 2 CEs in HA mode controlling it. However, don't you think the > CE, CE PL should have some of this intelligence and instruct the CE TML > how it should behave ? How would the TML figure this out ? Not sure i see the CE-PL involved (but not ruling it out); the TML, yes - perhaps via an admin interface like CEM. I think that CEs working together in HA mode to control an FE may need to have a CE-CE communication to decide which is the master for that FE. This is what i described in scheme #3 - i refered to it as an election process. There are several schemes that could use the result of the election at the CE: 1) The TML is NOT aware of the election results. An example of such a method is what VRRP uses and is described in scheme #3. In such a scenario, an IP or MAC address is taken over by a master CE. The master FE is unaware since at the TML layer it continues to receive from the same address. 2) The #2 scheme. After the election, all the participating CEs TMLs are told about the result via some "move" protocol instruction. I think from the CE side, this is probably the better approach. We should probably strive to make the FE side very simple and move any required complexity to the CE; so from that perspective, something like a move instruction at the CE which takes over all the logical and physical addressing may be a better approach. On the FE side, i would even go as far as saying to keep it simple, an FE being backed up should not be aware of its backup. > Let me know what you think. > May be if we work through a complete use-case, this will be more clear. Note, i presented the three schemes in the x-CEs to single FE in the first email. Is this sufficient for that case? What do you have in mind? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 13:40:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16357 for ; Wed, 7 Apr 2004 13:40:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBH1X-0002c2-Kj for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 13:39:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Hdd7L009991 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 13:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGTz-0006N7-Ek for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 13:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11214 for ; Wed, 7 Apr 2004 13:04:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGTs-0005Jj-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 13:04:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBF1E-0002nQ-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 11:31:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBDyc-0003X6-02 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 10:24:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBDtN-0007hJ-LX for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 10:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDtN-00050e-8V; Wed, 07 Apr 2004 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBDsU-0004dX-LZ for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 10:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27132 for ; Wed, 7 Apr 2004 10:18:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBDsS-0002ei-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 10:18:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBD39-00035j-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 09:25:04 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BBBbc-0002Wy-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 07:52:32 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040704543652:31358 ; Wed, 7 Apr 2004 04:54:36 -0700 Subject: Re: [Forces-protocol] Outline From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <030501c41c6b$107c3370$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E786AE5@orsmsx408.jf.intel.com> <1081277281.8374.146.camel@jzny.localdomain> <030501c41c6b$107c3370$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1081338737.15907.84.camel@jzny.localdomain> 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 04/07/2004 04:54:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/07/2004 04:54:44 AM, Serialize complete at 04/07/2004 04:54:44 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 07 Apr 2004 07:52:17 -0400 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 Content-Transfer-Encoding: 7bit Weiming, Hormuzd, On Wed, 2004-04-07 at 02:39, Wang,Weiming wrote: > Hi Hormuzd, Jamal, > > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > Hormuzd, > > Some comments: > > > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > > Here is an initial outline for the draft > > > > > > Abstract > > > 1. Introduction > > [Weiming] I suppose we add > 2. Definitions Makes sense. > > > 2. Protocol Overview I have a feeling that this being the only section that describes the protocol details then "overview" is insufficient? > > > 3. Common Header > [Weiming] The common header can be inside the overview. And also the overivew > will explain the layering model of PL and TML, therefore the TML requirements > can also be included in it. This i think should be a section on its own. Theres a lot of details to explain. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 16:31:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00476 for ; Wed, 7 Apr 2004 16:31:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJgu-00059V-9d for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 16:30:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37KUWWQ019806 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 16:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBJgu-00059N-55 for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 16:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00280 for ; Wed, 7 Apr 2004 16:30:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBJgs-0006AU-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 16:30:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBHbJ-00016O-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 14:16:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBGlQ-0000ZT-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 13:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGlS-000406-DH; Wed, 07 Apr 2004 13:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBGkj-0003d5-Kn for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 13:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14396 for ; Wed, 7 Apr 2004 13:22:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBGkh-0000Qx-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 13:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBFYH-0005xB-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 12:05:23 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BBEBu-00058t-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 10:38:10 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Wed, 7 Apr 2004 22:50:06 +0800 Message-ID: <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <1080137710.1023.7.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 7: HA 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 22:35:12 +0800 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 autolearn=no version=2.60 Hi Jamal, I have some ideas on the TML of its functions like HA, which I'm not sure if the same as what you think. Let's just discuss it: 1) The interaction mode between PL and TML Although I agree with you that TML itself controls the connections with their state, I think such control should be under the control of PL as well as pre-association protocol. On the whole, I think TML should work in a passive mode, with its intelligence limited to a perceivable scope by PL or PAP. As such, my idea is that the interaction between the PL and TML may proceed via two items: a) PL controls TML via some TML setup attributes, which may be from CE to FE via ForCES protocol or directly inside CE from PL to TML. b) TML may trigger some event reports to PL, which are at FE side as a kind of FE events. Then, what we need to discuss is just what attributes and events (actually apear as FE attributes and FE events at FE side) are needed and how they are defined in PL. This actually relates to the discussion of how much the TML should have the intelligence, and which is better, more or less. Coming back to the HA, I think we then can reduce our discussion on what kind of FE attributes and FE events are needed for HA, and among them, what are to be transmitted to TML(as you said, are transparent to PL) and what are needed to take functions within the PL. My some more comments are as inlines below. ----- Original Message ----- From: "Jamal Hadi Salim" > This text does not talk about state synchronization or restarts > or rollovers. Those details are considered solvable if the > discussion below is resolvable. > > Two levels of HA responsibilities that i see: > > 1) TML level: > > a) The TML controls logical connection availability and failover. > b) The TML also controls peer HA managements. [Weiming] I agree with such control. But seems we still have a depth selection for the control: (1)Control to only let TML able to detect the connection availability and failover for already setup connections, then trigger event report to PL. (2)Under some guidance from PL, the TML can reach the high availability as well as detect the state. (3)Can intelligently reach the HA without PL guidance. For all the three controls, we may have different TML HA attribute contents for the PL to setup it. > > 2) PL Level: > > Depending on the scheme implemented by the TML level, the PL > level may have no role to play i.e HA being transparent to it. > [Weiming]Yes, if we choose to let TML have enough intelligence. But I think when we designe the protocol, we may be better not to exclude the support for some TMLs that may not have enough intelligence. > The TML layer > ------------- > To describe the detail, a good example would be to show multiple > CEs trying to control an FE. > > For all three schemes, a heartbeat that terminates at the TML layer > is needed for meeting requirement 1). The are three schemes i can > think of which i will list here: > > Scheme 1) Le brute force: > The FE TML is aware of the multiple CEs i.e knows their logical > connections. > It may receive commands from all the CEs but will process the one with > highest priority only in given time instances. > > Protocol requirement: To have priorities in the headers. We already do. > > Advantages: KISS. > Disadvatanges: too much traffic > > Scheme 2) the Tenor: > The FE TML is aware of all CEs controlling it however responds to only > one at any one point. > Something akin to HA as achieved by SCTP multihoming or some > mobility protocols. i.e at some point the current known master is > obsoleted for example because of some missing heartbeats or physical > disconnect or by explicit instructions to migrate. > > Protocol requirement: > A "move" command to instruct to a migration to a new CE being issued > to the FE. > > Advantages: less traffic > Disadvantages: slower in recovery compared to 1). > > Scheme 3) the soprano: > The FE is NOT aware of the CEs unlike 1 and 2 above. > The election of which CE is controlling an FE is done elsewhere > at the CE level. > At any point the controlling CE will use a logical address. > This makes it transparent to the FE how many CEs are behind the control > point. Very easily doable with a broadcast or multicast protocol. > Example protocol which does this is VRRP. > > Protocol requirement: None, the TML is burdened with providing either > multicast or broadcast. > > In terms of compute requirements on the FE a) > b) > c) > In terms of bandwidth requirements on the wire a > b > c > [Weiming]When I checked the three schemes, I just have a feeling that it's the difference of control depth from PL(as I mentioned above), or from other point, the difference of the TML intelligence. that is, In terms of control depth from PL: ab>c Therefore, I just suppose what we need to discuss is how such control can be efficiently described in the protocol layer. From your above text, you mentioned the protocol priority may have something to do with it. I think we have much more. My idea as described at the head is we need to define some HA (more widely TML) attributes for such control policies. > The PL Layer > ------------ > The PL layer provides HA management of the LFBs and their availability. > > Scheme 1) > The PL heartbeats terminate at the TML layer. > The TML layer aggregates info on its PLs into its own heartbeats > to its peers. > The TML peer uses the knowledge to make calls on failover. Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 7 22:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08754 for ; Wed, 7 Apr 2004 22:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPIp-0002Rk-BP for forces-protocol-archive@odin.ietf.org; Wed, 07 Apr 2004 22:30:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i382U3Tj009404 for forces-protocol-archive@odin.ietf.org; Wed, 7 Apr 2004 22:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPIp-0002RZ-2K for forces-protocol-web-archive@optimus.ietf.org; Wed, 07 Apr 2004 22:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08626 for ; Wed, 7 Apr 2004 22:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPIl-0004Ek-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 22:29:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNpf-0006g1-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 20:55:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBLfS-0000Vg-00 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 18:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLfL-0004ZO-3M; Wed, 07 Apr 2004 18:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBLey-0004XO-Ic for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 18:36:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17978 for ; Wed, 7 Apr 2004 18:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBLev-0000TL-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 18:36:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBKG1-0003O0-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 17:06:50 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBIFS-000617-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 14:58:06 -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 i37J031R000913; Wed, 7 Apr 2004 19:00:03 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 i37Inlbl030681; Wed, 7 Apr 2004 18:49:52 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 M2004040711571815267 ; Wed, 07 Apr 2004 11:57:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Apr 2004 11:57:17 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E83440D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQcgIpfHd+zKsyqR/uNkWdfDqCh8wAUH2sA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 07 Apr 2004 18:57:17.0332 (UTC) FILETIME=[25A24D40:01C41CD2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 11:57:16 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, Thanks for your comments! I am fine with the Definitions section. I have to agree with Jamal on the Common Header, all other sections are present in most drafts/RFCs as you have mentioned. Based on your, Jamal's comments here is what I propose for the outline... Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. Example Scenarios 7. TML Requirements 8. Security Considerations 9. References 10. Acknowledgments I completely agree with you that we need to start discussing protocol overview/messages. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 03:09:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15251 for ; Thu, 8 Apr 2004 03:09:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTeg-00061d-VO for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 03:08:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3878sY1023161 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 03:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTeg-00061U-Lm for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 03:08:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15157 for ; Thu, 8 Apr 2004 03:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTec-0004Zz-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 03:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRnQ-00052V-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 01:09:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBPf1-0006Y5-04 for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 22:52:59 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBPKk-0007bU-Gj for forces-protocol-web-archive@ietf.org; Wed, 07 Apr 2004 22:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPKk-0005am-CV; Wed, 07 Apr 2004 22:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPKI-0002v4-Qu for forces-protocol@optimus.ietf.org; Wed, 07 Apr 2004 22:31:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08963 for ; Wed, 7 Apr 2004 22:31:30 -0400 (EDT) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPKF-0004Vc-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 22:31:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNtE-0007Jy-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 20:59:33 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBLop-0001cE-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 18:46:52 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBLop-000FEv-Li for forces-protocol@ietf.org; Wed, 07 Apr 2004 22:46:52 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E83440D@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E83440D@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7932AF3F-88E5-11D8-AC5B-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Outline To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 07:46:56 +0900 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 Content-Transfer-Encoding: 7bit I think the outline looks pretty good. If we have decided on it and on XML, I can build the stubs so they are ready. And it is no problem changing them should we need to. a. On 8 apr 2004, at 03.57, Khosravi, Hormuzd M wrote: > Weiming, > > Thanks for your comments! > I am fine with the Definitions section. I have to agree with Jamal on > the Common Header, all other sections are present in most drafts/RFCs > as > you have mentioned. Based on your, Jamal's comments here is what I > propose for the outline... > > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Common Header > 5. Protocol Messages > 6. Example Scenarios > 7. TML Requirements > 8. Security Considerations > 9. References > 10. Acknowledgments > > > I completely agree with you that we need to start discussing protocol > overview/messages. > > regards > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > >> Hormuzd, >> Some comments: >> >> On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: >>> Here is an initial outline for the draft >>> >>> Abstract >>> 1. Introduction > > [Weiming] I suppose we add > 2. Definitions > >>> 2. Protocol Overview >>> 3. Common Header > [Weiming] The common header can be inside the overview. And also the > overivew > will explain the layering model of PL and TML, therefore the TML > requirements > can also be included in it. > >>> 4. Protocol Messages >> >> Should we follow with protocol details after this? >> And should TML move to just below Protocol overview or were you > thinking >> protocol overview contains overview of TML as well? > > [Weiming] Agreed as above. >> >>> 5. Example Scenarios > > [Weiming] This section should be as an Appendix. > >>> 6. TML Requirements > > [Weiming]As mentioned above, this should be put early in the protocol > overview, > so that some protocol messages related to TML can be reasonably > understood. > >>> 7. Security Considerations >> >> do security requirements belong to TML as well? >> > [Weiming]This section is still normally needed even TML will be more > responsible > for protocol security issues. > >>> 8. References >>> 9. Acknowledgments >>> >>> Let me know what you guys think ? >>> We can add more details as we move along. >> >> I think its a good start and good idea to have this at this point. We >> probably shouldnt spend too much time on cosmetics right now because i >> think we can iron those out as we go on. >> >> cheers, >> jamal >> > > [Weiming] To summarise, I think we may only need to give the first > layer > outlines as follows, > > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Protocol Messages > > All others are just normal ones and the more we need to discuss > followed > is the > contents inside the overview and messages. As Jamal said, we can do it > along > with the issue discussions. > > Yours, > Weiming > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 05:23:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24232 for ; Thu, 8 Apr 2004 05:23:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBVkH-00006w-Jz for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 05:22:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i389Mn2P000426 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 05:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBVkH-00006n-GJ for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 05:22:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24142 for ; Thu, 8 Apr 2004 05:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBVkE-0002dd-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 05:22:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBTHT-0002IJ-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 02:44:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRcC-0002vY-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 00:58:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRcC-0000qG-BG for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 00:58:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRc5-0006wX-BT; Thu, 08 Apr 2004 00:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRbM-0006nk-7M for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 00:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17799 for ; Thu, 8 Apr 2004 00:57:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRbJ-0002kD-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 00:57:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBPHz-00049R-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 22:29:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBNpG-0006bQ-00 for Forces-protocol@ietf.org; Wed, 07 Apr 2004 20:55:26 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBNpH-0005e4-94 for Forces-protocol@ietf.org; Wed, 07 Apr 2004 20:55:27 -0400 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 8 Apr 2004 09:07:28 +0800 Message-ID: <000101c41d03$dc336680$6f01a8c0@dlg> From: "Ligang Dong" To: References: <1080959240.1036.13.camel@jzny.localdomain> <01a401c41b10$6ad16130$845c21d2@Necom.hzic.edu.cn> <1081283139.8368.163.camel@jzny.localdomain> Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 7 Apr 2004 20:44:44 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,DATE_IN_PAST_12_24, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksDQoNCkkgYWdyZWUgd2l0aCB3ZWltaW5nIGFuZCBqYW1hbC4gDQpJdCBpcyBuZWNlc3Nhcnkg dG8gaGF2ZSBvbmUgZWRpdG9yIGZyb20gZWFjaCBwcmV2aW91cyBjYW5kaWF0ZSBwcm90b2NvbC4g VGhlIHJlYXNvbiBpcyB0aGUgY29vcmRpbmF0aW9uIGJldHdlZW4gNyBhdXRob3JzIHNob3VsZCBi ZSBlYXNpZXIgYW5kIG1vcmUgZWZmaWNpZW50IHRoYW4gdGhlIGNvb3JkaW5hdGlvbiBiZXR3ZWVu IDMgZWRpdG9ycy4gQXMgYSByZXN1bHQsIG91ciBwcm9jZXNzIHdpbGwgYmUgZmFzdGVyLg0KDQpC ZXNpZGVzLCB0aGUgYXV0aG9ycyBpbiB0aGUgc2FtZSBjYW5kaWF0ZSBwcm90b2NvbCBhbG1vc3Qg aGF2ZSB0aGUgc2FtZSB2aWV3LiBUaGVyZWZvcmUsIGl0IGlzIGZlYXNpYmxlIHRvIHJlY29tbWVu ZCBvbmUgZnJvbSB0aGUgYXV0aG9ycyBmb3IgdGhlIHNhbWUgY2FuZGlhdGUgcHJvdG9jb2wuDQoN CmJlc3QgcmVnYXJkcw0KTGlnYW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpG cm9tOiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpUbzogIldhbmcsV2VpbWlu ZyIgPHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPg0KQ2M6IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmc+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA3LCAyMDA0IDQ6MjUgQU0NClN1YmplY3Q6IFJl OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gRm9yQ0VTIFByb3RvY29sIERlc2lnbiBUZWFtIGZpcnN0 IHRhc2stdGltZWxpbmUhXQ0KDQoNCj4gV2VpbWluZywNCj4gDQo+IE9uIE1vbiwgMjAwNC0wNC0w NSBhdCAwOToxNywgV2FuZyxXZWltaW5nIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPiANCj4gPiBU YWxraW5nIGFib3V0IGVkaXRvcihzKSwgSSdkIGxpa2UgdG8gcHV0IHNvbWUgb3BpbmlvbnMgYXMg Zm9sbG93cywNCj4gPiANCj4gPiAxKSBJJ20gYWZyYWlkIHdlIG5lZWQgZWRpdG9yKHMpIGFueXdh eSwgIHNvb25lciBvciBsYXRlciwgcHJvdmlkZWQgd2UgaGF2ZSBhDQo+ID4gcXVpdGUgYmlnIHRl YW0uIEluIHRoaXMgY2FzZSwgYXMgQXZyaSBtZW50aW9uZWQsIG15IG9waW5pb24gaXMgYWxzbyB0 aGF0IHdlIG5lZWQNCj4gPiB0byBoYXZlIGl0IHNldCBiZWZvcmUgd2UgYmVnaW4gdGhlIGRyYWZ0 IHdyaXRpbmcuIEkgZG9uJ3QgdGhpbmsgaXQgaXMgdmVyeQ0KPiA+IHJlYXNvbmFibGUgYW5kIGFj Y2VwdGFibGUgdG8gaGF2ZSBpdCBzZXQgYWZ0ZXIgdGhlIGRyYWZ0IGlzIGZpbmlzaGVkLiBUbyBz ZXQNCj4gPiBlZGl0b3IocykgQVNBUCB3aWxsIGRlZmluaXRlbHkgc3BlZWQgdXAgdGhlIHRlYW0g d29yay4NCj4gPiANCj4gPiAyKSBGcm9tIHRoZSBoaXN0b3J5IG9mIHRoZSBmb3JtZXIgdGhyZWUg Y2FuZGlkYXRlIHByb3RvY29scyBhbmQgdGhlIGV4cGVyaWVuY2VzDQo+ID4gb2YgdGhlIG1lcmdl IHByb2Nlc3MgZGlzY3Vzc2lvbnMsIEkgaGF2ZSBhIHN0cm9uIGZlZWxpbmcgdGhhdCB3ZSBzaG91 bGQgZmlyc3RseQ0KPiA+IHRyeSB0byBoYXZlIHRocmVlIGVkaXRvcnMvd3JpdGVycywgb25lIGZy b20gZWFjaCBmb3JtZXIgY2FuZGlkYXRlIHByb3RvY29scywgZm9yDQo+ID4gdGhlIGZpcnN0IDAw IGRyYWZ0LiBUaGlzIGlzIHRoZSBtb3N0IGVmZmljaWVudCwgdGhlIG1vc3QgcmVhc29uYWJsZSwg YW5kDQo+ID4gcHJvYmFibHkgbW9zdCBhY2NlcHRhYmxlIHNjaGVtZSBmb3IgY3VycmVudCB3b3Jr LCBJIHRoaW5rLg0KPiANCj4gT2ssIGlmIHRoaXMgaXMgYWNjZXB0YWJsZSB0byBvdGhlcnMgaSB3 aWxsIGdvIGFsb25nIGFzIHdlbGwgLiBJIGRvIGhvcGUNCj4gd2UgZG9udCBlbmQgaW50byBzb21l IGRlYWRsb2Nrcy4NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZvcmNlcy1w cm90b2NvbCBtYWlsaW5nIGxpc3QNCj4gRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbA0KPiA= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 06:49:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06667 for ; Thu, 8 Apr 2004 06:49:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBX5Y-0005J8-0g for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 06:48:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38Amp4u020403 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 06:48:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBX5X-0005Iv-Ru for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 06:48:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06450 for ; Thu, 8 Apr 2004 06:48:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBX5T-0000gs-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 06:48:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVbD-0001Ff-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 05:13:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBSzt-0000fZ-02 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 02:26:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBSme-0008TD-UZ for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 02:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSme-0006Mc-46; Thu, 08 Apr 2004 02:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBSmN-0006FZ-VI for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 02:12:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09865 for ; Thu, 8 Apr 2004 02:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBSmJ-00078B-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 02:12:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRTQ-0001F8-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 00:49:09 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BBOxJ-0001z3-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 22:07:50 -0400 Received: from dlg (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 8 Apr 2004 10:19:48 +0800 Message-ID: <002701c41d0d$f6c36f40$6f01a8c0@dlg> From: "Ligang Dong" To: References: <1080959240.1036.13.camel@jzny.localdomain> <01a401c41b10$6ad16130$845c21d2@Necom.hzic.edu.cn> <1081283139.8368.163.camel@jzny.localdomain> Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: base64 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:05:28 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksDQoNCkkgYWdyZWUgd2l0aCB3ZWltaW5nIGFuZCBqYW1hbC4gDQpJdCBpcyBuZWNlc3Nhcnkg dG8gaGF2ZSBvbmUgZWRpdG9yIGZyb20gZWFjaCBwcmV2aW91cyBjYW5kaWF0ZSBwcm90b2NvbC4g VGhlIHJlYXNvbiBpcyB0aGUgY29vcmRpbmF0aW9uIGJldHdlZW4gNyBhdXRob3JzIHNob3VsZCBi ZSBlYXNpZXIgYW5kIG1vcmUgZWZmaWNpZW50IHRoYW4gdGhlIGNvb3JkaW5hdGlvbiBiZXR3ZWVu IDMgZWRpdG9ycy4gQXMgYSByZXN1bHQsIG91ciBwcm9jZXNzIHdpbGwgYmUgZmFzdGVyLg0KDQpC ZXNpZGVzLCB0aGUgYXV0aG9ycyBpbiB0aGUgc2FtZSBjYW5kaWF0ZSBwcm90b2NvbCBhbG1vc3Qg aGF2ZSB0aGUgc2FtZSB2aWV3LiBUaGVyZWZvcmUsIGl0IGlzIGZlYXNpYmxlIHRvIHJlY29tbWVu ZCBvbmUgZnJvbSB0aGUgYXV0aG9ycyBmb3IgdGhlIHNhbWUgY2FuZGlhdGUgcHJvdG9jb2wuDQoN CmJlc3QgcmVnYXJkcw0KTGlnYW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpG cm9tOiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpUbzogIldhbmcsV2VpbWlu ZyIgPHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPg0KQ2M6IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmc+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA3LCAyMDA0IDQ6MjUgQU0NClN1YmplY3Q6IFJl OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gRm9yQ0VTIFByb3RvY29sIERlc2lnbiBUZWFtIGZpcnN0 IHRhc2stdGltZWxpbmUhXQ0KDQoNCj4gV2VpbWluZywNCj4gDQo+IE9uIE1vbiwgMjAwNC0wNC0w NSBhdCAwOToxNywgV2FuZyxXZWltaW5nIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPiANCj4gPiBU YWxraW5nIGFib3V0IGVkaXRvcihzKSwgSSdkIGxpa2UgdG8gcHV0IHNvbWUgb3BpbmlvbnMgYXMg Zm9sbG93cywNCj4gPiANCj4gPiAxKSBJJ20gYWZyYWlkIHdlIG5lZWQgZWRpdG9yKHMpIGFueXdh eSwgIHNvb25lciBvciBsYXRlciwgcHJvdmlkZWQgd2UgaGF2ZSBhDQo+ID4gcXVpdGUgYmlnIHRl YW0uIEluIHRoaXMgY2FzZSwgYXMgQXZyaSBtZW50aW9uZWQsIG15IG9waW5pb24gaXMgYWxzbyB0 aGF0IHdlIG5lZWQNCj4gPiB0byBoYXZlIGl0IHNldCBiZWZvcmUgd2UgYmVnaW4gdGhlIGRyYWZ0 IHdyaXRpbmcuIEkgZG9uJ3QgdGhpbmsgaXQgaXMgdmVyeQ0KPiA+IHJlYXNvbmFibGUgYW5kIGFj Y2VwdGFibGUgdG8gaGF2ZSBpdCBzZXQgYWZ0ZXIgdGhlIGRyYWZ0IGlzIGZpbmlzaGVkLiBUbyBz ZXQNCj4gPiBlZGl0b3IocykgQVNBUCB3aWxsIGRlZmluaXRlbHkgc3BlZWQgdXAgdGhlIHRlYW0g d29yay4NCj4gPiANCj4gPiAyKSBGcm9tIHRoZSBoaXN0b3J5IG9mIHRoZSBmb3JtZXIgdGhyZWUg Y2FuZGlkYXRlIHByb3RvY29scyBhbmQgdGhlIGV4cGVyaWVuY2VzDQo+ID4gb2YgdGhlIG1lcmdl IHByb2Nlc3MgZGlzY3Vzc2lvbnMsIEkgaGF2ZSBhIHN0cm9uIGZlZWxpbmcgdGhhdCB3ZSBzaG91 bGQgZmlyc3RseQ0KPiA+IHRyeSB0byBoYXZlIHRocmVlIGVkaXRvcnMvd3JpdGVycywgb25lIGZy b20gZWFjaCBmb3JtZXIgY2FuZGlkYXRlIHByb3RvY29scywgZm9yDQo+ID4gdGhlIGZpcnN0IDAw IGRyYWZ0LiBUaGlzIGlzIHRoZSBtb3N0IGVmZmljaWVudCwgdGhlIG1vc3QgcmVhc29uYWJsZSwg YW5kDQo+ID4gcHJvYmFibHkgbW9zdCBhY2NlcHRhYmxlIHNjaGVtZSBmb3IgY3VycmVudCB3b3Jr LCBJIHRoaW5rLg0KPiANCj4gT2ssIGlmIHRoaXMgaXMgYWNjZXB0YWJsZSB0byBvdGhlcnMgaSB3 aWxsIGdvIGFsb25nIGFzIHdlbGwgLiBJIGRvIGhvcGUNCj4gd2UgZG9udCBlbmQgaW50byBzb21l IGRlYWRsb2Nrcy4NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZvcmNlcy1w cm90b2NvbCBtYWlsaW5nIGxpc3QNCj4gRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbA0KPiA= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 06:53:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07365 for ; Thu, 8 Apr 2004 06:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBX9H-0006Uz-9m for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 06:52:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38AqhMe024976 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 06:52:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBX9H-0006UR-2W for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 06:52:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07350 for ; Thu, 8 Apr 2004 06:52:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBX97-0001Ih-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 06:52:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBVld-0002qy-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 05:24:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBTJS-0002YT-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 02:46:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTJV-0000rQ-NU; Thu, 08 Apr 2004 02:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBTJB-0000pu-DT for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 02:46:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14060 for ; Thu, 8 Apr 2004 02:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBTJ7-0002Un-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 02:46:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBRdA-00037G-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 00:59:13 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BBPLP-0004hY-00 for forces-protocol@ietf.org; Wed, 07 Apr 2004 22:32:44 -0400 Received: from WWM (unverified [61.175.198.84]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Thu, 8 Apr 2004 10:44:36 +0800 Message-ID: <088501c41d11$58b9aef0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E83440D@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Outline 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:29:40 +0800 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 autolearn=no version=2.60 If all ideas are incorparated, I suppose it may look like this: Abstract 1. Introduction 2. Definitions 3. Protocol Overview (or other more intensive word than overview) 4. Common Header 5. Protocol Messages 6. Security Considerations 7. References 8. Acknowledgments Appendix Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, Thanks for your comments! I am fine with the Definitions section. I have to agree with Jamal on the Common Header, all other sections are present in most drafts/RFCs as you have mentioned. Based on your, Jamal's comments here is what I propose for the outline... Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. Example Scenarios 7. TML Requirements 8. Security Considerations 9. References 10. Acknowledgments I completely agree with you that we need to start discussing protocol overview/messages. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 09:29:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13770 for ; Thu, 8 Apr 2004 09:29:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBZao-0000Oy-Hn for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 09:29:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38DTIha001545 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 09:29:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBZan-0000OW-Vh for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 09:29:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13638 for ; Thu, 8 Apr 2004 09:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBZam-0007Sb-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 09:29:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWsE-0006Z4-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 06:35:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBVKt-0006jJ-03 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 04:56:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBV6y-0008HY-7P for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 04:42:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV6o-0003zW-4g; Thu, 08 Apr 2004 04:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV66-0003sP-D1 for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 04:41:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20264 for ; Thu, 8 Apr 2004 04:41:15 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV63-0005GT-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 04:41:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSeF-00061b-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 02:04:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRKC-0007gj-03 for forces-protocol@ietf.org; Thu, 08 Apr 2004 00:39:36 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRCb-0006Ff-J7 for forces-protocol@ietf.org; Thu, 08 Apr 2004 00:31:45 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i384VSt26893; Thu, 8 Apr 2004 07:31:28 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 07:31:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i384VE6R007515; Thu, 8 Apr 2004 07:31:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00jq8cpa; Thu, 08 Apr 2004 07:31:12 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i384VAs28347; Thu, 8 Apr 2004 07:31:10 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Apr 2004 23:31:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Outline Message-ID: Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQcgIpfHd+zKsyqR/uNkWdfDqCh8wAUH2sAABQvBEA= To: , , X-OriginalArrivalTime: 08 Apr 2004 04:31:09.0306 (UTC) FILETIME=[50B095A0:01C41D22] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 00:31:08 -0400 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hormuzd, I think we should move TML requirements before the Example Scenarios. TML req. section will document all cases where it ForCES protocol can be used.=20 As we know that start-up and shutdown and configuration procedure for distributed envionrment we need to comeup with a different section heading to describe all these usecases. I'm not sure just example scenario may be misleading. =20 I agree to Jamal's comment that we can figure out and reorganize latter. But my take is that we have short time and if we can get more clarity that would be good. Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org [mailto:forces-protocol- > admin@ietf.org] On Behalf Of ext Khosravi, Hormuzd M > Sent: Wednesday, April 07, 2004 2:57 PM > To: Wang,Weiming; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Outline >=20 > Weiming, >=20 > Thanks for your comments! > I am fine with the Definitions section. I have to agree with Jamal on > the Common Header, all other sections are present in most drafts/RFCs as > you have mentioned. Based on your, Jamal's comments here is what I > propose for the outline... >=20 > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Common Header > 5. Protocol Messages > 6. Example Scenarios > 7. TML Requirements > 8. Security Considerations > 9. References > 10. Acknowledgments >=20 >=20 > I completely agree with you that we need to start discussing protocol > overview/messages. >=20 > regards > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming >=20 > > Hormuzd, > > Some comments: > > > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > > Here is an initial outline for the draft > > > > > > Abstract > > > 1. Introduction >=20 > [Weiming] I suppose we add > 2. Definitions >=20 > > > 2. Protocol Overview > > > 3. Common Header > [Weiming] The common header can be inside the overview. And also the > overivew > will explain the layering model of PL and TML, therefore the TML > requirements > can also be included in it. >=20 > > > 4. Protocol Messages > > > > Should we follow with protocol details after this? > > And should TML move to just below Protocol overview or were you > thinking > > protocol overview contains overview of TML as well? >=20 > [Weiming] Agreed as above. > > > > > 5. Example Scenarios >=20 > [Weiming] This section should be as an Appendix. >=20 > > > 6. TML Requirements >=20 > [Weiming]As mentioned above, this should be put early in the protocol > overview, > so that some protocol messages related to TML can be reasonably > understood. >=20 > > > 7. Security Considerations > > > > do security requirements belong to TML as well? > > > [Weiming]This section is still normally needed even TML will be more > responsible > for protocol security issues. >=20 > > > 8. References > > > 9. Acknowledgments > > > > > > Let me know what you guys think ? > > > We can add more details as we move along. > > > > I think its a good start and good idea to have this at this point. We > > probably shouldnt spend too much time on cosmetics right now because i > > think we can iron those out as we go on. > > > > cheers, > > jamal > > >=20 > [Weiming] To summarise, I think we may only need to give the first layer > outlines as follows, >=20 > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Protocol Messages >=20 > All others are just normal ones and the more we need to discuss followed > is the > contents inside the overview and messages. As Jamal said, we can do it > along > with the issue discussions. >=20 > Yours, > Weiming >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 19:12:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06427 for ; Thu, 8 Apr 2004 19:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBih9-0004EC-OL for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 19:12:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NCRdM016248 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 19:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBih9-0004Dz-Io for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06341 for ; Thu, 8 Apr 2004 19:12:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBih7-0002Jj-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiBD-0006iP-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 18:39:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgFp-00004W-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 16:36:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBgEx-0003DX-Pp for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 16:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgEn-0008H4-Gp; Thu, 08 Apr 2004 16:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgE8-0008FD-KP for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 16:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20262 for ; Thu, 8 Apr 2004 16:34:17 -0400 (EDT) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgE5-0007bG-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:34:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBdRV-00046a-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 13:35:58 -0400 Received: from [61.175.198.82] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BBbU0-0005Rt-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 11:30:25 -0400 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 8 Apr 2004 23:41:57 +0800 Received: from 219.82.178.97 ( [219.82.178.97]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Thu, 8 Apr 2004 23:41:56 +0800 Message-ID: <1081438916.407572e4a5e4d@mail.hzic.edu.cn> To: hadi@znyx.com, forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA References: <1080137710.1023.7.camel@jzny.localdomain> <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> <1081434965.1033.34.camel@jzny.localdomain> In-Reply-To: <1081434965.1033.34.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 23:41:56 +0800 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: 8bit Content-Transfer-Encoding: 8bit Hi Jamal, I'm glad we are basically with the same viewpoint. Pls see more comments inline. ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > The first portion of your email touches on generality of the TML<->PL > interface and the second (a response to my email) is on one specific > thing - HA. I am separating the two issues with two emails for clarity. > > Its good you brought this up at this point. > > On Wed, 2004-04-07 at 10:35, Wang,Weiming wrote: > > Hi Jamal, > > > > I have some ideas on the TML of its functions like HA, which I'm not sure if the > > same as what you think. Let's just discuss it: > > > > 1) The interaction mode between PL and TML > > Although I agree with you that TML itself controls the connections with their > > state, I think such control should be under the control of PL as well as > > pre-association protocol. On the whole, I think TML should work in a passive > > mode, with its intelligence limited to a perceivable scope by PL or PAP. As > > such, my idea is that the interaction between the PL and TML may proceed via two > > items: > > I am with you on this. > We definitely need to have an interface between PL and TML. I realize > this may be adding more complexity but it would be necessary if we have > to tell people to write TMLs. [Weiming]This maybe also that Hormuzd means for TML requirements, but I'm afraid they not just requirements, instead they are items that should be defined explicitly in the Protocol messages. > > a) PL controls TML via some TML setup attributes, which may be from CE to FE via > > ForCES protocol or directly inside CE from PL to TML. > > I think theres one more view. Each Local PL may instruct its local TML > on certain things. Basically, theres an API/protocol between the PL and > TML; with control being driven by the PL. For generality, a PL may need > to instruct a remote TML. Is this going overboard? [Weiming]Not overboard, I think. Actually by using attributes defined in the protocol, we have implied this control may be from remote, that is, may from CE to some FE. From your schemes presented last time on the priority for multi-CEs controlling a FE, I suppose you actually imply the TML control may be via metadata in the protocol messages for remote control. Talking about metadata, after I posted my last email, I have also noticed that we may need never able to exclude the control from PL to TML via a per packet metadata, because a broadcast/multicast ID actually acts like this kind of metadata. But what we need to discuss to find out is what attributes and metadata we on earch need. I have a basic thought that we may only use metadata when we are sure attributes are not feasible for a goal, for it seems attributes are more flexible, while some metadata may have to be defined in the protocol more strictly, but I'm still not sure of this. Do you have more ideas on how metadata may look like from protocol layer? > > > b) TML may trigger some event reports to PL, which are at FE side as a kind of > > FE events. > > Events from TML to PL are the other piece. > > > Then, what we need to discuss is just what attributes and events (actually apear > > as FE attributes and FE events at FE side) are needed and how they are defined > > in PL. This actually relates to the discussion of how much the TML should have > > the intelligence, and which is better, more or less. > > Theres another piece: Should interface between PL->TML be on a out of > band ctrl or metadata carried with packet? Example in the case of > reliability: I may want a specific message to be reliably delivered or i > may request all packets be delivered reliably. In the later case, it > makes sense to just send a attribute request to be reliable. In the > former case, i could attach metadata to the message if it is an > exception. > [Weiming] Agreed. We may need to find more examples on the need for the metadata like control of TML. > > Coming back to the HA, I think we then can reduce our discussion on what kind of > > FE attributes and FE events are needed for HA, and among them, what are to be > > transmitted to TML(as you said, are transparent to PL) and what are needed to > > take functions within the PL. > > Yes, HA is one item which applies to such interface - although it doesnt > have a per-packet semantics: others i can think of that will have per > packet semantics are: Reliability, Security and priority. > [Weiming]One more important example for per-packet control is broadcast/multicast support. Cheers, Weiming ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 19:14:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06741 for ; Thu, 8 Apr 2004 19:14:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiip-0004bj-8k for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 19:14:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NEB60017707 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 19:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiip-0004bW-4R for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:14:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06644 for ; Thu, 8 Apr 2004 19:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiim-0002c8-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:14:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiVP-0001Jp-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:00:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBgwL-00057h-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 17:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgwL-0007bM-Di; Thu, 08 Apr 2004 17:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBgvU-0007RE-5a for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 17:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24380 for ; Thu, 8 Apr 2004 17:19:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgvP-00050C-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 17:19:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBeKK-00027z-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 14:32:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbXl-0005hi-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 11:34:17 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBadm-0001KS-Qa for forces-protocol@ietf.org; Thu, 08 Apr 2004 10:36:26 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040807393057:395 ; Thu, 8 Apr 2004 07:39:30 -0700 Subject: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> References: <1080137710.1023.7.camel@jzny.localdomain> <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1081434965.1033.34.camel@jzny.localdomain> 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 04/08/2004 07:39:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/08/2004 07:39:43 AM, Serialize complete at 04/08/2004 07:39:43 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Apr 2004 10:36:06 -0400 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 Content-Transfer-Encoding: 7bit Weiming, The first portion of your email touches on generality of the TML<->PL interface and the second (a response to my email) is on one specific thing - HA. I am separating the two issues with two emails for clarity. Its good you brought this up at this point. On Wed, 2004-04-07 at 10:35, Wang,Weiming wrote: > Hi Jamal, > > I have some ideas on the TML of its functions like HA, which I'm not sure if the > same as what you think. Let's just discuss it: > > 1) The interaction mode between PL and TML > Although I agree with you that TML itself controls the connections with their > state, I think such control should be under the control of PL as well as > pre-association protocol. On the whole, I think TML should work in a passive > mode, with its intelligence limited to a perceivable scope by PL or PAP. As > such, my idea is that the interaction between the PL and TML may proceed via two > items: I am with you on this. We definitely need to have an interface between PL and TML. I realize this may be adding more complexity but it would be necessary if we have to tell people to write TMLs. > a) PL controls TML via some TML setup attributes, which may be from CE to FE via > ForCES protocol or directly inside CE from PL to TML. I think theres one more view. Each Local PL may instruct its local TML on certain things. Basically, theres an API/protocol between the PL and TML; with control being driven by the PL. For generality, a PL may need to instruct a remote TML. Is this going overboard? > b) TML may trigger some event reports to PL, which are at FE side as a kind of > FE events. Events from TML to PL are the other piece. > Then, what we need to discuss is just what attributes and events (actually apear > as FE attributes and FE events at FE side) are needed and how they are defined > in PL. This actually relates to the discussion of how much the TML should have > the intelligence, and which is better, more or less. Theres another piece: Should interface between PL->TML be on a out of band ctrl or metadata carried with packet? Example in the case of reliability: I may want a specific message to be reliably delivered or i may request all packets be delivered reliably. In the later case, it makes sense to just send a attribute request to be reliable. In the former case, i could attach metadata to the message if it is an exception. > Coming back to the HA, I think we then can reduce our discussion on what kind of > FE attributes and FE events are needed for HA, and among them, what are to be > transmitted to TML(as you said, are transparent to PL) and what are needed to > take functions within the PL. Yes, HA is one item which applies to such interface - although it doesnt have a per-packet semantics: others i can think of that will have per packet semantics are: Reliability, Security and priority. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 19:14:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06758 for ; Thu, 8 Apr 2004 19:14:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiiu-0004cE-HM for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 19:14:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38NEGOs017738 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 19:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiiu-0004c1-Cr for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 19:14:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06673 for ; Thu, 8 Apr 2004 19:14:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiis-0002dY-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:14:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiaU-0001do-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:05:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBh7w-0006X1-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 17:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBh7y-0000nw-EK; Thu, 08 Apr 2004 17:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBh7G-0000k3-1N for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 17:31:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26031 for ; Thu, 8 Apr 2004 17:31:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBh7D-0006QM-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 17:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBeZA-0003oZ-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 14:47:58 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbiq-0007l2-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 11:45:44 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040808485537:487 ; Thu, 8 Apr 2004 08:48:55 -0700 Subject: Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> References: <1080137710.1023.7.camel@jzny.localdomain> <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1081439134.1034.60.camel@jzny.localdomain> 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 04/08/2004 08:48:55 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/08/2004 08:49:03 AM, Serialize complete at 04/08/2004 08:49:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Apr 2004 11:45:34 -0400 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 Content-Transfer-Encoding: 7bit BTW, Is the mailing list still broken? I look at the time stamps and it is taking a looong time to get messages. On Wed, 2004-04-07 at 10:35, Wang,Weiming wrote: > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > This text does not talk about state synchronization or restarts > > or rollovers. Those details are considered solvable if the > > discussion below is resolvable. > > > > Two levels of HA responsibilities that i see: > > > > 1) TML level: > > > > a) The TML controls logical connection availability and failover. > > b) The TML also controls peer HA managements. > > [Weiming] I agree with such control. But seems we still have a depth selection > for the control: > (1)Control to only let TML able to detect the connection availability and > failover for already setup connections, then trigger event report to PL. > (2)Under some guidance from PL, the TML can reach the high availability as well > as detect the state. > (3)Can intelligently reach the HA without PL guidance. The way i see it above is the TML may be capable of all the three, but policy from PL may impose 3 for example. > For all the three controls, we may have different TML HA attribute contents for > the PL to setup it. > > > > > 2) PL Level: > > > > Depending on the scheme implemented by the TML level, the PL > > level may have no role to play i.e HA being transparent to it. > > > [Weiming]Yes, if we choose to let TML have enough intelligence. But I think when > we designe the protocol, we may be better not to exclude the support for some > TMLs that may not have enough intelligence. Agreed. Again, some TMLs may not be capable of all three possibilities. > > In terms of compute requirements on the FE a) > b) > c) > > In terms of bandwidth requirements on the wire a > b > c > > > [Weiming]When I checked the three schemes, I just have a feeling that it's the > difference of control depth from PL(as I mentioned above), or from other point, > the difference of the TML intelligence. that is, > > In terms of control depth from PL: a In terms of the TML intelligence: a>b>c Its both actually. If the TML is not capable of all three ways of control, then the workload is on the PL. I would say the TML will have some way of conveying such capability to PL and once the negotiation is complete, the decision on which HA scheme would be made. > Therefore, I just suppose what we need to discuss is how such control can be > efficiently described in the protocol layer. From your above text, you mentioned > the protocol priority may have something to do with it. I think we have much > more. My idea as described at the head is we need to define some HA (more widely > TML) attributes for such control policies. As i pointed out in the earlier email, i think theres two issues: first being the interface between TML to PL and other being the specifics on HA. To be honest when i posted the first text i was trying to exhaustively list all the possibilities so we could choose one or a hybrid ; this discussion leads me to believe we should be able to support all three. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 20:05:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13253 for ; Thu, 8 Apr 2004 20:05:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjVq-0000sA-BD for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 20:04:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3904ovU003350 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 20:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjVp-0000rx-RZ for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:04:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13220 for ; Thu, 8 Apr 2004 20:04:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjVn-0000f2-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:04:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBifv-00027U-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:11:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBi07-0005kx-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 18:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi08-0006II-9g; Thu, 08 Apr 2004 18:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhzI-0006FZ-Hy for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 18:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02315 for ; Thu, 8 Apr 2004 18:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhzD-0005cZ-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:27:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfwZ-0004TF-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:16:14 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBcsS-00007Q-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 12:59:44 -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 i38Gwfbj005874 for ; Thu, 8 Apr 2004 16:58:41 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 i38GvEhI006444 for ; Thu, 8 Apr 2004 16:58: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 M2004040809584609428 for ; Thu, 08 Apr 2004 09:58:46 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 09:58:46 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: Server delays Thread-Index: AcQdisDjPWUauELHSkenGC/qJLR8LQ== From: "Putzolu, David" To: X-OriginalArrivalTime: 08 Apr 2004 16:58:46.0549 (UTC) FILETIME=[C1B0AC50:01C41D8A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Server delays Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 09:58:46 -0700 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 Content-Transfer-Encoding: quoted-printable All, From the looks of it the forces-protocol@ietf.org server is fairly overloaded - emails are taking several hours to be exploded by it. I can't offer any solutions I'm afraid. I've contacted the adminstrators but things have not improved. If any of you have access to a better listserv or Mailman that could be used. It would be necessary for it to have a publicly accessible archive that the ForCES WG could access. -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 20:05:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13332 for ; Thu, 8 Apr 2004 20:05:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjWS-0000ug-5M for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 20:05:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3905Sij003506 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 20:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjWS-0000uT-1e for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13277 for ; Thu, 8 Apr 2004 20:05:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjWQ-0000k6-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:05:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBigW-0002DY-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:11:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBi7r-0006OE-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 18:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi7t-0006zn-TX; Thu, 08 Apr 2004 18:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi7U-0006xU-ER for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 18:35:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03079 for ; Thu, 8 Apr 2004 18:35:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBi7N-0006Le-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgAV-0006yr-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:30:39 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdIH-00037g-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 13:26:25 -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 i38HPYKk014036 for ; Thu, 8 Apr 2004 17:25:34 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 i38HPTh0027969 for ; Thu, 8 Apr 2004 17:25:37 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 M2004040810254515590 for ; Thu, 08 Apr 2004 10:25:45 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 10:25:45 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] Message-ID: <468F3FDA28AA87429AD807992E22D07E834D54@orsmsx408.jf.intel.com> Thread-Topic: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] Thread-Index: AcQdMI8L41ii61gaQyebhrhyjS2M3wAXbT4Q From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 08 Apr 2004 17:25:45.0117 (UTC) FILETIME=[866E8CD0:01C41D8E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:25:45 -0700 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 Content-Transfer-Encoding: quoted-printable I am fine with this, if everyone likes this direction. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Ligang Dong Sent: Wednesday, April 07, 2004 7:05 PM To: forces-protocol@ietf.org Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] hi, I agree with weiming and jamal.=20 It is necessary to have one editor from each previous candiate protocol. The reason is the coordination between 7 authors should be easier and more efficient than the coordination between 3 editors. As a result, our process will be faster. Besides, the authors in the same candiate protocol almost have the same view. Therefore, it is feasible to recommend one from the authors for the same candiate protocol. best regards Ligang ----- Original Message -----=20 From: "Jamal Hadi Salim" To: "Wang,Weiming" Cc: Sent: Wednesday, April 07, 2004 4:25 AM Subject: Re: Re: [Forces-protocol] ForCES Protocol Design Team first task-timeline!] > Weiming, >=20 > On Mon, 2004-04-05 at 09:17, Wang,Weiming wrote: > > Hi all, > >=20 > > Talking about editor(s), I'd like to put some opinions as follows, > >=20 > > 1) I'm afraid we need editor(s) anyway, sooner or later, provided we have a > > quite big team. In this case, as Avri mentioned, my opinion is also that we need > > to have it set before we begin the draft writing. I don't think it is very > > reasonable and acceptable to have it set after the draft is finished. To set > > editor(s) ASAP will definitely speed up the team work. > >=20 > > 2) From the history of the former three candidate protocols and the experiences > > of the merge process discussions, I have a stron feeling that we should firstly > > try to have three editors/writers, one from each former candidate protocols, for > > the first 00 draft. This is the most efficient, the most reasonable, and > > probably most acceptable scheme for current work, I think. >=20 > Ok, if this is acceptable to others i will go along as well . I do hope > we dont end into some deadlocks. >=20 > cheers, > jamal >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 20:06:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13532 for ; Thu, 8 Apr 2004 20:06:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXC-00011w-UF for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 20:06:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906EGC003956 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXC-00011j-Q7 for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13388 for ; Thu, 8 Apr 2004 20:06:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXA-0000qF-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihN-0002NQ-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiEe-00073o-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 18:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiEf-0008IO-AU; Thu, 08 Apr 2004 18:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiE0-0008Ba-OM for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 18:42:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03793 for ; Thu, 8 Apr 2004 18:42:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiDu-00070T-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:42:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgIU-0000Xn-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:38:55 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdX1-0004sS-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 13:41:39 -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 i38Henbj004299; Thu, 8 Apr 2004 17:40:49 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 i38HeChO005004; Thu, 8 Apr 2004 17:40:49 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 M2004040810405418420 ; Thu, 08 Apr 2004 10:40:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 10:40:53 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E834D83@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQdNU0EhomfNLO4S9iF1v05NgpRMQAWX2zA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 08 Apr 2004 17:40:53.0129 (UTC) FILETIME=[A3A62F90:01C41D90] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:40:52 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming You're right, I have not incorporated all your comments...I should have explained a bit more in my last email..sorry about that. I think Example Scenarios is an important section and should be part of the main protocol sections. I have seen it in most RFCs/drafts that I have read, it makes things easy to understand for the reader. Is there any particular reason why it should be moved to the appendix ? Also, I think TML Requirements should be a separate section. I agree that protocol layering and TML will be introduced in Protocol Overview but TML requirements is different from that, goes into more of the details and deserves a separate section. Based on latest comments from Ram, yourself, here is what I propose.. Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. TML Requirements 7. Example Scenarios 8. Security Considerations 9. References 10. Acknowledgments Appendix Note that I have added an appendix, we can decide what goes into it later. Most folks have agreed with this initial outline, I would say lets go with this for now, unless you have strong reasons not to. We can always make changes later, once we get into more details. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Wednesday, April 07, 2004 7:30 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Outline If all ideas are incorparated, I suppose it may look like this: Abstract 1. Introduction 2. Definitions 3. Protocol Overview (or other more intensive word than overview) 4. Common Header 5. Protocol Messages 6. Security Considerations 7. References 8. Acknowledgments Appendix Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, Thanks for your comments! I am fine with the Definitions section. I have to agree with Jamal on the Common Header, all other sections are present in most drafts/RFCs as you have mentioned. Based on your, Jamal's comments here is what I propose for the outline... Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. Example Scenarios 7. TML Requirements 8. Security Considerations 9. References 10. Acknowledgments I completely agree with you that we need to start discussing protocol overview/messages. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 20:06:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13611 for ; Thu, 8 Apr 2004 20:06:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXP-000134-M3 for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 20:06:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3906RtL004026 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 20:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjXP-00012r-9V for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:06:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13425 for ; Thu, 8 Apr 2004 20:06:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjXN-0000rx-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBihZ-0002Pj-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBiHY-0007IB-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 18:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiHa-0000B5-6I; Thu, 08 Apr 2004 18:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiH1-00005S-KB for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 18:45:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04187 for ; Thu, 8 Apr 2004 18:45:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiGx-0007Fc-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:45:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgLh-000131-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:42:10 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdZa-0005Bx-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 13:44:18 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i38HhQKk028455; Thu, 8 Apr 2004 17:43:27 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 i38HdQUE012126; Thu, 8 Apr 2004 17:43: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 M2004040810433728396 ; Thu, 08 Apr 2004 10:43:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 10:43:37 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E834D8E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQdEa0Uo+/yJ0xrSoSl9nDvQdPefQAfv/4w From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 08 Apr 2004 17:43:37.0532 (UTC) FILETIME=[05A417C0:01C41D91] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 10:43:37 -0700 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 Content-Transfer-Encoding: quoted-printable Avri, I have made some minor changes to incorporate latest comments. Unless there are any objections, you can go ahead and build the XML stubs. I hope you will give us more instructions or pointers in this regard, I am not an XML expert :-) regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org I think the outline looks pretty good. If we have decided on it and on XML, I can build the stubs so they are=20 ready. And it is no problem changing them should we need to. a. On 8 apr 2004, at 03.57, Khosravi, Hormuzd M wrote: > Weiming, > > Thanks for your comments! > I am fine with the Definitions section. I have to agree with Jamal on > the Common Header, all other sections are present in most drafts/RFCs=20 > as > you have mentioned. Based on your, Jamal's comments here is what I > propose for the outline... > > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Common Header > 5. Protocol Messages > 6. Example Scenarios > 7. TML Requirements > 8. Security Considerations > 9. References > 10. Acknowledgments > > > I completely agree with you that we need to start discussing protocol > overview/messages. > > regards > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 21:05:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18222 for ; Thu, 8 Apr 2004 21:05:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkRi-0001J4-Uj for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 21:04:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3914cYX005017 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 21:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkRi-0001Im-8j for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:04:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18085 for ; Thu, 8 Apr 2004 21:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkRf-0007gp-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:04:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkCj-0005DQ-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:49:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjpa-0002Xi-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:25:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjpa-0002iw-ES; Thu, 08 Apr 2004 20:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiu3-0005QN-QW for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 19:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08042 for ; Thu, 8 Apr 2004 19:25:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiu1-0004SC-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 19:25:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhn1-0003mn-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:14:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfoj-00031k-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:08:05 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBfZi-0006Zt-KU for forces-protocol@ietf.org; Thu, 08 Apr 2004 15:52:34 -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 i38Jphbj028858; Thu, 8 Apr 2004 19:51:43 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 i38Jp2SY030304; Thu, 8 Apr 2004 19:51:36 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 M2004040812515115360 ; Thu, 08 Apr 2004 12:51:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 12:51:51 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E834F2C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQcgIpfHd+zKsyqR/uNkWdfDqCh8wAUH2sAABQvBEAAIDYhkA== From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 08 Apr 2004 19:51:51.0698 (UTC) FILETIME=[EFB8A720:01C41DA2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 12:51:41 -0700 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 Content-Transfer-Encoding: quoted-printable Ram, I have incorporated your comment on TML Reqs. I agree that we should not spend many more cycles on this, lets move on to more important issues that need to be discussed. We can always come back and refine the Outline later. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of ram.gopal@nokia.com Sent: Wednesday, April 07, 2004 9:31 PM To: Khosravi, Hormuzd M; wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Outline Hello Hormuzd, I think we should move TML requirements before the Example Scenarios. TML req. section will document all cases where it ForCES protocol can be used.=20 As we know that start-up and shutdown and configuration procedure for distributed envionrment we need to comeup with a different section heading to describe all these usecases. I'm not sure just example scenario may be misleading. =20 I agree to Jamal's comment that we can figure out and reorganize latter. But my take is that we have short time and if we can get more clarity that would be good. Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org [mailto:forces-protocol- > admin@ietf.org] On Behalf Of ext Khosravi, Hormuzd M > Sent: Wednesday, April 07, 2004 2:57 PM > To: Wang,Weiming; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Outline >=20 > Weiming, >=20 > Thanks for your comments! > I am fine with the Definitions section. I have to agree with Jamal on > the Common Header, all other sections are present in most drafts/RFCs as > you have mentioned. Based on your, Jamal's comments here is what I > propose for the outline... >=20 > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Common Header > 5. Protocol Messages > 6. Example Scenarios > 7. TML Requirements > 8. Security Considerations > 9. References > 10. Acknowledgments >=20 >=20 > I completely agree with you that we need to start discussing protocol > overview/messages. >=20 > regards > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming >=20 > > Hormuzd, > > Some comments: > > > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > > Here is an initial outline for the draft > > > > > > Abstract > > > 1. Introduction >=20 > [Weiming] I suppose we add > 2. Definitions >=20 > > > 2. Protocol Overview > > > 3. Common Header > [Weiming] The common header can be inside the overview. And also the > overivew > will explain the layering model of PL and TML, therefore the TML > requirements > can also be included in it. >=20 > > > 4. Protocol Messages > > > > Should we follow with protocol details after this? > > And should TML move to just below Protocol overview or were you > thinking > > protocol overview contains overview of TML as well? >=20 > [Weiming] Agreed as above. > > > > > 5. Example Scenarios >=20 > [Weiming] This section should be as an Appendix. >=20 > > > 6. TML Requirements >=20 > [Weiming]As mentioned above, this should be put early in the protocol > overview, > so that some protocol messages related to TML can be reasonably > understood. >=20 > > > 7. Security Considerations > > > > do security requirements belong to TML as well? > > > [Weiming]This section is still normally needed even TML will be more > responsible > for protocol security issues. >=20 > > > 8. References > > > 9. Acknowledgments > > > > > > Let me know what you guys think ? > > > We can add more details as we move along. > > > > I think its a good start and good idea to have this at this point. We > > probably shouldnt spend too much time on cosmetics right now because i > > think we can iron those out as we go on. > > > > cheers, > > jamal > > >=20 > [Weiming] To summarise, I think we may only need to give the first layer > outlines as follows, >=20 > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. Protocol Messages >=20 > All others are just normal ones and the more we need to discuss followed > is the > contents inside the overview and messages. As Jamal said, we can do it > along > with the issue discussions. >=20 > Yours, > Weiming >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 21:05:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18350 for ; Thu, 8 Apr 2004 21:05:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSE-0001QN-HT for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 21:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3915AT3005471 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 21:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkSE-0001QA-Bz for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18240 for ; Thu, 8 Apr 2004 21:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkSB-0007jz-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:05:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkD6-0005Iy-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:49:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjpu-0002Zs-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:25:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjps-0002vN-77; Thu, 08 Apr 2004 20:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiyM-0005pw-OO for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 19:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08669 for ; Thu, 8 Apr 2004 19:30:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiyK-0004rW-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 19:30:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBhrD-0004OK-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:18:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBfqc-00039v-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:10:02 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBfHh-0003mV-Gv for forces-protocol@ietf.org; Thu, 08 Apr 2004 15:33:57 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040812365633:786 ; Thu, 8 Apr 2004 12:36:56 -0700 Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org, David , Greg Cunningham In-Reply-To: <1081438916.407572e4a5e4d@mail.hzic.edu.cn> References: <1080137710.1023.7.camel@jzny.localdomain> <082301c41cad$895c1610$845c21d2@Necom.hzic.edu.cn> <1081434965.1033.34.camel@jzny.localdomain> <1081438916.407572e4a5e4d@mail.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1081452807.1033.96.camel@jzny.localdomain> 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 04/08/2004 12:36:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/08/2004 12:37:14 PM, Serialize complete at 04/08/2004 12:37:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 Apr 2004 15:33:27 -0400 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 Content-Transfer-Encoding: 7bit Weiming, BTW, this mailing list latency is horrible; not to forget it has swallowed at least 2 of my messages that i havent sent in the past. This is not proper for a discussion. Maybe we should look for alternatives. Greg, can you confirm that you received this message and that the mailing list logs show it was received? On Thu, 2004-04-08 at 11:41, wmwang@mail.hzic.edu.cn wrote: > > I am with you on this. > > We definitely need to have an interface between PL and TML. I realize > > this may be adding more complexity but it would be necessary if we have > > to tell people to write TMLs. > [Weiming]This maybe also that Hormuzd means for TML requirements, but I'm > afraid they not just requirements, instead they are items that should be > defined explicitly in the Protocol messages. > Ok, so we may be approaching this from a different angle. I am thinking there may be some messages which are just local; eg via an API such as (invoked by PL): TML_ioctl(fd, USE_HA_MODE2) You are thinking that infact the PL constructs a message addressed to the TML which may be terminated localy. It could also be terminated at a remote TML. Did i understand you correctly? > > > a) PL controls TML via some TML setup attributes, which may be from CE to > FE via > > > ForCES protocol or directly inside CE from PL to TML. > > > > I think theres one more view. Each Local PL may instruct its local TML > > on certain things. Basically, theres an API/protocol between the PL and > > TML; with control being driven by the PL. For generality, a PL may need > > to instruct a remote TML. Is this going overboard? > > [Weiming]Not overboard, I think. Actually by using attributes defined in the > protocol, we have implied this control may be from remote, that is, may from CE > to some FE. From your schemes presented last time on the priority for multi-CEs > controlling a FE, Ok this validates my earlier point that you are looking at this from a purely messaging/protocol view. Which is fine with me but needs some clarity in regards to addressing. > I suppose you actually imply the TML control may be via > metadata in the protocol messages for remote control. > Talking about metadata, after I posted my last email, I have also noticed that > we may need never able to exclude the control from PL to TML via a per packet > metadata, because a broadcast/multicast ID actually acts like this kind of > metadata. But what we need to discuss to find out is what attributes and > metadata we on earch need. I have a basic thought that we may only use metadata > when we are sure attributes are not feasible for a goal, for it seems > attributes are more flexible, while some metadata may have to be defined in the > protocol more strictly, but I'm still not sure of this. Do you have more ideas > on how metadata may look like from protocol layer? I am just thinking actually the metadata is mostly to instruct the TML on how to deal with the message. Not to be passed to the PL layer. IOW, you could send a message to TML to be forwarded to one or more FEs but you want that message to be delivered reliably on some occasions but not on others. In such a situation you will have something attached to the message to instruct it to do so. I am thinking probably a TLV. [..] > [Weiming]One more important example for per-packet control is > broadcast/multicast support. This one may be tricky. Do you want the PL layer to know about details of how the message is transmitted? Shouldnt the addressing take care of it? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 21:07:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18685 for ; Thu, 8 Apr 2004 21:07:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkU7-0001jn-Tr for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 21:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39177vP006675 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 21:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkU7-0001ja-PH for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:07:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18635 for ; Thu, 8 Apr 2004 21:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkU4-00005a-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:07:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkEA-0005Yk-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:50:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjrO-0002nY-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:27:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjrP-0003v9-Ec; Thu, 08 Apr 2004 20:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjCI-0007gY-NY for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 19:44:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10489 for ; Thu, 8 Apr 2004 19:44:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjCG-0006Cp-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 19:44:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiBT-0006l1-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:39:45 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgG6-00002h-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:36:23 -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 i38KZZKk027007; Thu, 8 Apr 2004 20:35:35 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 i38KYahQ015619; Thu, 8 Apr 2004 20:35:39 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 M2004040813354614606 ; Thu, 08 Apr 2004 13:35:46 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 13:35:46 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E834FEE@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 7: HA Thread-Index: AcQcxP3xoZQOqqLxTi2MZa3oEm4gUAA4zJuQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 08 Apr 2004 20:35:46.0497 (UTC) FILETIME=[122F1310:01C41DA9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 13:35:43 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, I agree with most of your comments below.. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming I have some ideas on the TML of its functions like HA, which I'm not sure if the same as what you think. Let's just discuss it: 1) The interaction mode between PL and TML Although I agree with you that TML itself controls the connections with their state, I think such control should be under the control of PL as well as pre-association protocol. On the whole, I think TML should work in a passive mode, with its intelligence limited to a perceivable scope by PL or PAP. As such, my idea is that the interaction between the PL and TML may proceed via two items: a) PL controls TML via some TML setup attributes, which may be from CE to FE via ForCES protocol or directly inside CE from PL to TML. b) TML may trigger some event reports to PL, which are at FE side as a kind of FE events. Then, what we need to discuss is just what attributes and events (actually apear as FE attributes and FE events at FE side) are needed and how they are defined in PL. This actually relates to the discussion of how much the TML should have the intelligence, and which is better, more or less. Coming back to the HA, I think we then can reduce our discussion on what kind of FE attributes and FE events are needed for HA, and among them, what are to be transmitted to TML(as you said, are transparent to PL) and what are needed to take functions within the PL. [HK] Completely agree, I think this is a good time to start some discussion around protocol messages. We can then figure out what messages will be needed for HA. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 21:07:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18728 for ; Thu, 8 Apr 2004 21:07:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkUL-0001uN-N6 for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 21:07:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3917LTX007331 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 21:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkUL-0001u8-JS for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:07:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18663 for ; Thu, 8 Apr 2004 21:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkUI-00006c-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:07:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkEG-0005aH-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:50:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBjrS-0002o9-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 20:27:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjrT-00042b-D6; Thu, 08 Apr 2004 20:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjDV-0007kY-9g for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 19:45:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10665 for ; Thu, 8 Apr 2004 19:45:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjDS-0006KH-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 19:45:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBiDw-00070t-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 18:42:17 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBgIX-0000Sm-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 16:38:53 -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 i38KbOKk028246 for ; Thu, 8 Apr 2004 20:37:25 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 i38KaGhm016611 for ; Thu, 8 Apr 2004 20:37:27 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 M2004040813373414871 for ; Thu, 08 Apr 2004 13:37:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 13:37:34 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41DA9.4FEFD1C0" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E834FF4@orsmsx408.jf.intel.com> Thread-Topic: I am not seeing all emails on this list Thread-Index: AcQdqU0ZHhSQZeWpROmBlRGRu6lfuQ== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 08 Apr 2004 20:37:34.0780 (UTC) FILETIME=[52B9BFC0:01C41DA9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] I am not seeing all emails on this list Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 13:37:30 -0700 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,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41DA9.4FEFD1C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable testing... ------_=_NextPart_001_01C41DA9.4FEFD1C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
testing...
------_=_NextPart_001_01C41DA9.4FEFD1C0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 8 21:34:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20962 for ; Thu, 8 Apr 2004 21:34:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBktn-0004pY-B9 for forces-protocol-archive@odin.ietf.org; Thu, 08 Apr 2004 21:33:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391XdK0018564 for forces-protocol-archive@odin.ietf.org; Thu, 8 Apr 2004 21:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBktl-0004p5-19 for forces-protocol-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20941 for ; Thu, 8 Apr 2004 21:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkth-0002G0-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:33:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkkZ-0001Rq-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:24:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBkU1-00005G-00 for forces-protocol-web-archive@ietf.org; Thu, 08 Apr 2004 21:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkU1-0001gQ-NT; Thu, 08 Apr 2004 21:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkTA-0001cV-3c for forces-protocol@optimus.ietf.org; Thu, 08 Apr 2004 21:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18497 for ; Thu, 8 Apr 2004 21:06:03 -0400 (EDT) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkT5-00001S-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 21:06:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkDl-0005Sn-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 20:50:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BBjqk-0002iQ-00 for forces-protocol@ietf.org; Thu, 08 Apr 2004 20:26:27 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BBjqk-000NhU-Se for forces-protocol@ietf.org; Fri, 09 Apr 2004 00:26:27 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E834D8E@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E834D8E@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <86302B90-89BC-11D8-AC5B-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Outline To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 09:26:20 +0900 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 Content-Transfer-Encoding: 7bit Ok. I will get this done in the next few days. I will send some pointers on how to do the xml, it is a rather easy infix operator sort of language, though the basic intro in RFC2629 is rather good (with more info at xml.resource.org ). I am willing to function as a, not editor, but perhaps copy-editor, i.e. just take care of making sure the text and format etc comes out right. Not that I want to impose myself into any sort of role and am just as willing to have someone else do it. As for the 3 editors idea, I can go along with that as long as we don't believe that such a triad will get itself into deadlock situations. a. On 9 apr 2004, at 02.43, Khosravi, Hormuzd M wrote: > Avri, > > I have made some minor changes to incorporate latest comments. > Unless there are any objections, you can go ahead and build the XML > stubs. > I hope you will give us more instructions or pointers in this regard, > I am not an XML expert :-) > > regards > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > > I think the outline looks pretty good. > > If we have decided on it and on XML, I can build the stubs so they are > ready. > And it is no problem changing them should we need to. > > a. > > On 8 apr 2004, at 03.57, Khosravi, Hormuzd M wrote: > >> Weiming, >> >> Thanks for your comments! >> I am fine with the Definitions section. I have to agree with Jamal on >> the Common Header, all other sections are present in most drafts/RFCs >> as >> you have mentioned. Based on your, Jamal's comments here is what I >> propose for the outline... >> >> Abstract >> 1. Introduction >> 2. Definitions >> 3. Protocol Overview >> 4. Common Header >> 5. Protocol Messages >> 6. Example Scenarios >> 7. TML Requirements >> 8. Security Considerations >> 9. References >> 10. Acknowledgments >> >> >> I completely agree with you that we need to start discussing protocol >> overview/messages. >> >> regards >> Hormuzd >> > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 02:26:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13799 for ; Fri, 9 Apr 2004 02:26:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpSc-0005NB-SS for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 02:25:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i396Ps4Z020654 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 02:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpSc-0005N3-2t for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 02:25:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13784 for ; Fri, 9 Apr 2004 02:25:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBpSV-0005Pa-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 02:25:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBpQq-0005J3-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 02:24:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBpOq-0005Ax-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 02:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpOr-0004J5-0c; Fri, 09 Apr 2004 02:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBpOL-0004An-Aa for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 02:21:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13511 for ; Fri, 9 Apr 2004 02:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBpOE-000586-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 02:21:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBpMW-0004xK-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 02:19:37 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BBpKI-0004lt-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 02:17:18 -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 i396GQWQ014690; Fri, 9 Apr 2004 06:16:26 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 i396GHeP009758; Fri, 9 Apr 2004 06:16:17 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 M2004040823163424726 ; Thu, 08 Apr 2004 23:16:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Apr 2004 23:16:34 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E8B25F3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQdzvhyGa/yvIGVTDqVMCQZ8JK9BAAKhEAA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 09 Apr 2004 06:16:34.0094 (UTC) FILETIME=[34F864E0:01C41DFA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 8 Apr 2004 23:16:33 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Avri I appreciate your help with this draft and all along. I will be happy to propose you as a 4th editor if everyone else is fine with that and if you have the time. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Thursday, April 08, 2004 5:26 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Outline Ok. I will get this done in the next few days. I will send some pointers on how to do the xml, it is a rather easy=20 infix operator sort of language, though the basic intro in RFC2629 is=20 rather good (with more info at xml.resource.org ). I am willing to function as a, not editor, but perhaps copy-editor,=20 i.e. just take care of making sure the text and format etc comes out=20 right. Not that I want to impose myself into any sort of role and am=20 just as willing to have someone else do it. As for the 3 editors idea, I can go along with that as long as we don't=20 believe that such a triad will get itself into deadlock situations. a. On 9 apr 2004, at 02.43, Khosravi, Hormuzd M wrote: > Avri, > > I have made some minor changes to incorporate latest comments. > Unless there are any objections, you can go ahead and build the XML > stubs. > I hope you will give us more instructions or pointers in this regard, > I am not an XML expert :-) > > regards > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > > I think the outline looks pretty good. > > If we have decided on it and on XML, I can build the stubs so they are > ready. > And it is no problem changing them should we need to. > > a. > > On 8 apr 2004, at 03.57, Khosravi, Hormuzd M wrote: > >> Weiming, >> >> Thanks for your comments! >> I am fine with the Definitions section. I have to agree with Jamal on >> the Common Header, all other sections are present in most drafts/RFCs >> as >> you have mentioned. Based on your, Jamal's comments here is what I >> propose for the outline... >> >> Abstract >> 1. Introduction >> 2. Definitions >> 3. Protocol Overview >> 4. Common Header >> 5. Protocol Messages >> 6. Example Scenarios >> 7. TML Requirements >> 8. Security Considerations >> 9. References >> 10. Acknowledgments >> >> >> I completely agree with you that we need to start discussing protocol >> overview/messages. >> >> regards >> Hormuzd >> > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 11:52:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03623 for ; Fri, 9 Apr 2004 11:52:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByID-0006tv-2D for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 11:51:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39Fpjch026523 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 11:51:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByIC-0006ti-TJ for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 11:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03605 for ; Fri, 9 Apr 2004 11:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByIB-0001lT-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 11:51:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByGT-0001av-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 11:49:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BByFZ-0001TD-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 11:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByFY-0006cf-9u; Fri, 09 Apr 2004 11:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BByFM-0006bR-2X for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 11:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03429 for ; Fri, 9 Apr 2004 11:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BByFJ-0001Sd-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 11:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BByDz-0001JT-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 11:47:23 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BByCw-0001C2-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 11:46:18 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040908492720:1688 ; Fri, 9 Apr 2004 08:49:27 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1081525568.1040.167.camel@jzny.localdomain> 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 04/09/2004 08:49:27 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/09/2004 08:49:36 AM, Serialize complete at 04/09/2004 08:49:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] test testing mailing list Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Apr 2004 11:46:08 -0400 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 Content-Transfer-Encoding: 7bit did i pass? sent 11:45 eastern time cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 17:21:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23006 for ; Fri, 9 Apr 2004 17:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3Qu-0004ib-0e for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 17:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39LL3Y6018134 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC3Qs-0004iK-9B for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 17:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22940 for ; Fri, 9 Apr 2004 17:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC3Qp-0004V2-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 17:20:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC3DY-000345-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 17:07:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BC2xz-0001fk-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 16:51:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BC2wu-0002au-OS for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 16:50:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2wq-0000QX-KN; Fri, 09 Apr 2004 16:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2vt-00008Q-JR for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 16:49:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20470 for ; Fri, 9 Apr 2004 16:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC2vp-0001TW-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 16:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC2j9-0007bl-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 16:35:54 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BC2LD-0005jo-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 16:11: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 i39KAFWQ024383; Fri, 9 Apr 2004 20:10:15 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 i39KA3Fk030193; Fri, 9 Apr 2004 20:10:15 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 M2004040913102018242 ; Fri, 09 Apr 2004 13:10:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 13:10:19 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E8B2B2C@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQdyS9xxEmicNW2TsqOyVgUB+xdlQAmAeeg From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 09 Apr 2004 20:10:19.0708 (UTC) FILETIME=[AE8F4FC0:01C41E6E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 13:10:19 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, I have a couple of points on this topic... I don't believe we need to define APIs between PL and TML, it is true that we have separated the 2 layers but introducing and standardizing new interfaces will introduce unwanted complexity and delay in getting an interoperable protocol out. In any case, any protocol implementation will consists of both layers working together and cannot operate with just one. The interfaces between the layers is completely implementation dependent. What we need is to define specific requirements for the TML such as... For Control messages (or messages A-X) we need...1. strict Reliability, 2. Congestion Control, 3. Security For Data messages (or messages Y-Z) we need...1. Congestion Control, 2. Security, 3. Reliability is not needed or optional Another thing which is needed is Protocol Messages which will help interaction between PL and TML. This is what Weiming is talking about, I believe. I will send out some text on Protocol Messages which will hopefully get us started in that direction. Another point I would like to bring out is that we need to come up with one or max 2 HA schemes which will make most sense for our protocol. If we keep adding new schemes and features we will never get to a single interoperable solution. We need to decide which scheme will work best for our case. I will send out some specific text in this regard in a separate email. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Weiming, BTW, this mailing list latency is horrible; not to forget it has swallowed at least 2 of my messages that i havent sent in the past. This is not proper for a discussion. Maybe we should look for alternatives. Greg, can you confirm that you received this message and that the mailing list logs show it was received? On Thu, 2004-04-08 at 11:41, wmwang@mail.hzic.edu.cn wrote: > > I am with you on this. > > We definitely need to have an interface between PL and TML. I realize > > this may be adding more complexity but it would be necessary if we have > > to tell people to write TMLs. > [Weiming]This maybe also that Hormuzd means for TML requirements, but I'm=20 > afraid they not just requirements, instead they are items that should be=20 > defined explicitly in the Protocol messages.=20 >=20 Ok, so we may be approaching this from a different angle. I am thinking there may be some messages which are just local; eg via an API such as (invoked by PL): TML_ioctl(fd, USE_HA_MODE2) You are thinking that infact the PL constructs a message addressed to the TML which may be terminated localy. It could also be terminated at a remote TML. Did i understand you correctly? > > > a) PL controls TML via some TML setup attributes, which may be from CE to=20 > FE via > > > ForCES protocol or directly inside CE from PL to TML. > >=20 > > I think theres one more view. Each Local PL may instruct its local TML > > on certain things. Basically, theres an API/protocol between the PL and > > TML; with control being driven by the PL. For generality, a PL may need > > to instruct a remote TML. Is this going overboard? >=20 > [Weiming]Not overboard, I think. Actually by using attributes defined in the=20 > protocol, we have implied this control may be from remote, that is, may from CE=20 > to some FE. From your schemes presented last time on the priority for multi-CEs=20 > controlling a FE,=20 Ok this validates my earlier point that you are looking at this from a purely messaging/protocol view. Which is fine with me but needs some clarity in regards to addressing.=20 > I suppose you actually imply the TML control may be via=20 > metadata in the protocol messages for remote control.=20 > Talking about metadata, after I posted my last email, I have also noticed that=20 > we may need never able to exclude the control from PL to TML via a per packet=20 > metadata, because a broadcast/multicast ID actually acts like this kind of=20 > metadata. But what we need to discuss to find out is what attributes and=20 > metadata we on earch need. I have a basic thought that we may only use metadata=20 > when we are sure attributes are not feasible for a goal, for it seems=20 > attributes are more flexible, while some metadata may have to be defined in the=20 > protocol more strictly, but I'm still not sure of this. Do you have more ideas=20 > on how metadata may look like from protocol layer? I am just thinking actually the metadata is mostly to instruct the TML on how to deal with the message. Not to be passed to the PL layer. IOW, you could send a message to TML to be forwarded to one or more FEs but you want that message to be delivered reliably on some occasions but not on others. In such a situation you will have something attached to the message to instruct it to do so. I am thinking probably a TLV. [..] > [Weiming]One more important example for per-packet control is=20 > broadcast/multicast support. This one may be tricky. Do you want the PL layer to know about details of how the message is transmitted? Shouldnt the addressing take care of it? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 18:31:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28383 for ; Fri, 9 Apr 2004 18:31:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4WW-00039z-Hg for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 18:30:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39MUu75012148 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 18:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4WU-00039n-3h for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 18:30:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28349 for ; Fri, 9 Apr 2004 18:30:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4WQ-0001rz-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:30:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4Sk-0001Sb-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:27:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC4Mw-0000ze-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Mw-0001dV-4U; Fri, 09 Apr 2004 18:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4MS-0001bT-LR for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 18:20:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27818 for ; Fri, 9 Apr 2004 18:20:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4MP-0000um-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:20:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4F1-0000Gh-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:12:53 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BC43s-0007Hk-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:01:21 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040915043520:2009 ; Fri, 9 Apr 2004 15:04:35 -0700 Subject: RE: [Forces-protocol] Outline From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: avri@acm.org, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E8B25F3@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E8B25F3@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1081548075.1043.179.camel@jzny.localdomain> 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 04/09/2004 03:04:35 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/09/2004 03:04:39 PM, Serialize complete at 04/09/2004 03:04:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Apr 2004 18:01:15 -0400 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 Content-Transfer-Encoding: 7bit I would like to strongly second that Avri be on that list. I am actually getting a little worried about actually ironing out the details than deciding who does what or what goes on the the outline at this point. Not that i want to dimish the role of creating the outline, rather we may be spending too much time on this. As an example, the little discussion on HA brought forth the TML-PL interface (which although i had been thinking of in the background, i hadnt seen the need for it to be part of this until now). cheers, jamal On Fri, 2004-04-09 at 02:16, Khosravi, Hormuzd M wrote: > Hi Avri > > I appreciate your help with this draft and all along. I will be happy to > propose you as a 4th editor if everyone else is fine with that and if > you have the time. > > Regards > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > Sent: Thursday, April 08, 2004 5:26 PM > To: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Outline > > Ok. I will get this done in the next few days. > > I will send some pointers on how to do the xml, it is a rather easy > infix operator sort of language, though the basic intro in RFC2629 is > rather good (with more info at xml.resource.org ). > > I am willing to function as a, not editor, but perhaps copy-editor, > i.e. just take care of making sure the text and format etc comes out > right. Not that I want to impose myself into any sort of role and am > just as willing to have someone else do it. > > As for the 3 editors idea, I can go along with that as long as we don't > believe that such a triad will get itself into deadlock situations. > > a. > > On 9 apr 2004, at 02.43, Khosravi, Hormuzd M wrote: > > > Avri, > > > > I have made some minor changes to incorporate latest comments. > > Unless there are any objections, you can go ahead and build the XML > > stubs. > > I hope you will give us more instructions or pointers in this regard, > > I am not an XML expert :-) > > > > regards > > Hormuzd > > > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > > > > > I think the outline looks pretty good. > > > > If we have decided on it and on XML, I can build the stubs so they are > > ready. > > And it is no problem changing them should we need to. > > > > a. > > > > On 8 apr 2004, at 03.57, Khosravi, Hormuzd M wrote: > > > >> Weiming, > >> > >> Thanks for your comments! > >> I am fine with the Definitions section. I have to agree with Jamal on > >> the Common Header, all other sections are present in most drafts/RFCs > >> as > >> you have mentioned. Based on your, Jamal's comments here is what I > >> propose for the outline... > >> > >> Abstract > >> 1. Introduction > >> 2. Definitions > >> 3. Protocol Overview > >> 4. Common Header > >> 5. Protocol Messages > >> 6. Example Scenarios > >> 7. TML Requirements > >> 8. Security Considerations > >> 9. References > >> 10. Acknowledgments > >> > >> > >> I completely agree with you that we need to start discussing protocol > >> overview/messages. > >> > >> regards > >> Hormuzd > >> > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 18:38:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28792 for ; Fri, 9 Apr 2004 18:38:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4dL-0004M5-0Y for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 18:37:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39MbwQU016737 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 18:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4dJ-0004Lc-HF for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 18:37:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28782 for ; Fri, 9 Apr 2004 18:37:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4dF-0002Xz-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4a3-0002HQ-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:34:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC4WZ-0001sa-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:30:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4Wa-0003AX-Im; Fri, 09 Apr 2004 18:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4WR-00039M-95 for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 18:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28345 for ; Fri, 9 Apr 2004 18:30:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4WM-0001ra-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:30:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4Si-0001S1-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:27:01 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BC4Ms-0000ua-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:20:58 -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 i39MKIWQ015917 for ; Fri, 9 Apr 2004 22:20:18 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 i39MJRej001204 for ; Fri, 9 Apr 2004 22:20:06 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 M2004040915202508797 for ; Fri, 09 Apr 2004 15:20:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 15:20:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41E80.DAEF2067" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E8B2D6B@orsmsx408.jf.intel.com> Thread-Topic: Protocol Messages Thread-Index: AcQegNqTwH7PfCI/RaGNxEIPnd14wg== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 09 Apr 2004 22:20:25.0333 (UTC) FILETIME=[DB132A50:01C41E80] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] Protocol Messages Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 15:20:25 -0700 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,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41E80.DAEF2067 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is an initial list of protocol messages... (I have tried to merge messages from all 3 protocols without adding too many messages) =20 1.Association Setup Messages Join Request/Response Leave Req/Resp =20 2. Capability Control Messages Query Req/Resp (including FE, LFB Topology Query) Capability Req/Resp Configuration Req/Resp =20 3. Control Packet or Traffic Maintenance Messages CP Redirect to CE CP Forward to FE =20 4. Event Notification Messages Event Register/De-register Req/Resp Asynchronous FE Event (including DoS events) =20 5. Management Object or SNMP support Messages MO Get/Set MO Response =20 6. State Maintenance Messages (or HA related messages) PE Up/Down PE Active/InActive (equivalent to the "Move" command that Jamal described) HeartBeat or Keep-alive =20 7. Vendor Specific messages (Optional ?) VS Request VS Response =20 Let me know what you guys think. Some of the terminology might be different but the semantics are quite similar in all the protocols. =20 =20 Regards Hormuzd =20 =20 ------_=_NextPart_001_01C41E80.DAEF2067 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Here = is an=20 initial list of protocol messages...
(I = have tried=20 to merge messages from all 3 protocols without adding too many=20 messages)
 
1.Association=20 Setup Messages
Join=20 Request/Response
Leave=20 Req/Resp
 
2. = Capability=20 Control Messages
Query = Req/Resp=20 (including FE, LFB Topology Query)
Capability=20 Req/Resp
Configuration=20 Req/Resp
 
3.=20 Control Packet or Traffic = Maintenance Messages
CP = Redirect to=20 CE
CP = Forward to=20 FE
 
4. = Event=20 Notification Messages
Event = Register/De-register=20 Req/Resp
Asynchronous FE = Event=20 (including DoS events)
 
5. = Management Object=20 or SNMP support Messages
MO=20 Get/Set
MO=20 Response
 
6. = State Maintenance=20 Messages (or HA related messages)
PE=20 Up/Down
PE = Active/InActive=20 (equivalent to the "Move" command that Jamal = described)
HeartBeat or=20 Keep-alive
 
7. = Vendor Specific=20 messages (Optional ?)
VS=20 Request
VS=20 Response
 
Let me = know what you=20 guys think. Some of the terminology might be different but the semantics = are=20 quite similar in all the protocols.
 
 
Regards
Hormuzd
 
 
------_=_NextPart_001_01C41E80.DAEF2067-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 19:06:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00199 for ; Fri, 9 Apr 2004 19:06:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC54f-00066s-2F for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 19:06:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39N6Dhp023482 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 19:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC54e-00066f-Jz for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 19:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00177 for ; Fri, 9 Apr 2004 19:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC54b-0005o9-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:06:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC518-0005PM-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:02:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BC4z3-0004pM-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:00:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BC4mC-00062g-7k for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 18:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4m5-0004wC-7t; Fri, 09 Apr 2004 18:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC4lk-0004vb-3s for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 18:46:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29393 for ; Fri, 9 Apr 2004 18:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC4lf-0003NM-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:46:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC4id-00034j-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:43:27 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BC4gP-0002lS-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 18:41:09 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004040915442296:2040 ; Fri, 9 Apr 2004 15:44:22 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E8B2B2C@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E8B2B2C@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1081550464.1044.227.camel@jzny.localdomain> 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 04/09/2004 03:44:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/09/2004 03:44:28 PM, Serialize complete at 04/09/2004 03:44:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 09 Apr 2004 18:41:04 -0400 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 Content-Transfer-Encoding: 7bit Hi Hormuzd, On Fri, 2004-04-09 at 16:10, Khosravi, Hormuzd M wrote: > Hi Jamal, > > I have a couple of points on this topic... > > I don't believe we need to define APIs between PL and TML, it is true > that we have separated the 2 layers but introducing and standardizing > new interfaces will introduce unwanted complexity and delay in getting > an interoperable protocol out. In any case, any protocol implementation > will consists of both layers working together and cannot operate with > just one. True on introducing more complexities - not sure i agree on the "unwanted" part. Maybe this is something that we need to decide on first before moving forward. Do we wanna say it that Forces can work only on the spefic TMLs? > The interfaces between the layers is completely implementation > dependent. I think it may be beyond "implementation" specific now that we have decided to go TMLs, no? I still would like our customers to use their own TMLs as long as they provide "services" to the PL layer for the items you mention: reliability, congestion control, security, HA etc. Infact in their own private environment i would like to care less if they present those services to the PL layer or not. Seems to me like this would provide greater spread for Forces. I believe we need to decide on this issue before moving forward. [..] > Another thing which is needed is Protocol Messages which will help > interaction between PL and TML. This is what Weiming is talking about, I > believe. I will send out some text on Protocol Messages which will > hopefully get us started in that direction. Go ahead and do that although i dont think the fundamental difference between us at this point has to do with how to replace multiple TMLs. I believe that the TML is a provider of services centred around transport. As in any such layering there needs to be (hate to use that evil word) an API between the two. Whether that takes the form of a protocol is not the issue. > Another point I would like to bring out is that we need to come up with > one or max 2 HA schemes which will make most sense for our protocol. If > we keep adding new schemes and features we will never get to a single > interoperable solution. We need to decide which scheme will work best > for our case. I will send out some specific text in this regard in a > separate email. It seems to me like more than one scheme could be supported. But i do agree with you that if it turns out to be a swiss knife it will not be very useful. When you send those emails, please make sure you have the appropriate subject heading to allow for maximum feedback. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 19:27:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00959 for ; Fri, 9 Apr 2004 19:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5PD-0007uO-5q for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 19:27:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39NRRmX030396 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 19:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5PD-0007uB-1Q for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 19:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00929 for ; Fri, 9 Apr 2004 19:27:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC5PB-0000f3-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:27:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC5OE-0000WD-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:26:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC5Mq-0000Mj-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5Mq-0007nL-OM; Fri, 09 Apr 2004 19:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5Mf-0007n5-Cb for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 19:24:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00813 for ; Fri, 9 Apr 2004 19:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC5Mc-0000MG-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:24:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC5Ly-0000Ch-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:24:07 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BC5Kr-0007kf-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:22:57 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i39NMEJi024258; Fri, 9 Apr 2004 23:22:14 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 i39NLOeh002850; Fri, 9 Apr 2004 23:22:03 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 M2004040916222117702 ; Fri, 09 Apr 2004 16:22:21 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 16:22:22 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E8B2E43@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQeg8JoEK+Wnz3dQ7mSCqW1PjvbuwABCmnQ From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 09 Apr 2004 23:22:22.0575 (UTC) FILETIME=[82B947F0:01C41E89] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 16:22:22 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > I don't believe we need to define APIs between PL and TML, it is true > that we have separated the 2 layers but introducing and standardizing > new interfaces will introduce unwanted complexity and delay in getting > an interoperable protocol out. In any case, any protocol implementation > will consists of both layers working together and cannot operate with > just one.=20 True on introducing more complexities - not sure i agree on the "unwanted" part. Maybe this is something that we need to decide on first before moving forward. Do we wanna say it that Forces can work only on the spefic TMLs?=20 [HK] No we don't, but that doesn't mean we need to define and standardize an API. Look at GSMP for example, it doesn't define an API but can still function on multiple TMLs. Why cant we use a similar approach ? > The interfaces between the layers is completely implementation > dependent.=20 I think it may be beyond "implementation" specific now that we have decided to go TMLs, no? I still would like our customers to use their own TMLs as long as they provide "services" to the PL layer for the items you mention: reliability, congestion control, security, HA etc. Infact in their own private environment i would like to care less if they present those services to the PL layer or not. Seems to me like this would provide greater spread for Forces. I believe we need to decide on this issue before moving forward. [HK] Sure your customers can use their own TMLs, infact that is the idea. But as you said, what is important are the services or requirements for TMLs such as reliability, etc. > Another thing which is needed is Protocol Messages which will help > interaction between PL and TML. This is what Weiming is talking about, I > believe. I will send out some text on Protocol Messages which will > hopefully get us started in that direction. Go ahead and do that although i dont think the fundamental difference between us at this point has to do with how to replace multiple TMLs. I believe that the TML is a provider of services centred around transport. As in any such layering there needs to be (hate to use that evil word) an API between the two. Whether that takes the form of a protocol is not the issue. [HK] Sure the layering will need an API in some implementations, but we don't need to define those APIs. Lets leave this to the vendors who implement the protocol. In any case, do you really think we can standardize APIs in the IETF ? > Another point I would like to bring out is that we need to come up with > one or max 2 HA schemes which will make most sense for our protocol. If > we keep adding new schemes and features we will never get to a single > interoperable solution. We need to decide which scheme will work best > for our case. I will send out some specific text in this regard in a > separate email. It seems to me like more than one scheme could be supported. But i do agree with you that if it turns out to be a swiss knife it will not be very useful.=20 When you send those emails, please make sure you have the appropriate subject heading to allow for maximum feedback. [HK] I will do that. Thanks for your comments ! Seems like the list is finally working in reasonable time :-) Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 9 19:31:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01075 for ; Fri, 9 Apr 2004 19:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5So-00086l-M5 for forces-protocol-archive@odin.ietf.org; Fri, 09 Apr 2004 19:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39NVA6e031163 for forces-protocol-archive@odin.ietf.org; Fri, 9 Apr 2004 19:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5Sn-00086C-EG for forces-protocol-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 19:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01062 for ; Fri, 9 Apr 2004 19:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC5Sl-0001BW-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC5Ql-0000w2-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:29:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC5Pk-0000nP-00 for forces-protocol-web-archive@ietf.org; Fri, 09 Apr 2004 19:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5Pl-00080e-FS; Fri, 09 Apr 2004 19:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC5Oz-0007tz-BR for forces-protocol@optimus.ietf.org; Fri, 09 Apr 2004 19:27:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00922 for ; Fri, 9 Apr 2004 19:27:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC5Ox-0000e4-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC5O6-0000Vk-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:26:19 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BC5MZ-0000DT-00 for forces-protocol@ietf.org; Fri, 09 Apr 2004 19:24:43 -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 i39NO5WQ021198 for ; Fri, 9 Apr 2004 23:24:05 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 i39NNlFq016470 for ; Fri, 9 Apr 2004 23:24:05 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 M2004040916241112971 for ; Fri, 09 Apr 2004 16:24:11 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Apr 2004 16:24:11 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41E89.C3AE2DD9" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E8B2E4B@orsmsx408.jf.intel.com> Thread-Topic: traveling this weekend Thread-Index: AcQeicNCxQKocIIjQ8erpOJ0Fxjf/w== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 09 Apr 2004 23:24:11.0545 (UTC) FILETIME=[C3ACC890:01C41E89] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] traveling this weekend Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 9 Apr 2004 16:24:11 -0700 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,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41E89.C3AE2DD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys =20 Just wanted to let you all know that I will be traveling this weekend and will try to check email intermittently. In any case, I will definitely respond to emails on Monday. =20 Have a nice weekend, =20 Hormuzd :-) =20 ------_=_NextPart_001_01C41E89.C3AE2DD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Guys
 
Just = wanted to let=20 you all know that I will be traveling this weekend and will try to check = email=20 intermittently.
In any = case, I will=20 definitely respond to emails on Monday.
 
Have a = nice=20 weekend,
 
Hormuzd=20 :-)
 
------_=_NextPart_001_01C41E89.C3AE2DD9-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 12 18:38:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20645 for ; Mon, 12 Apr 2004 18:38:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDA3s-0002Qu-AP for forces-protocol-archive@odin.ietf.org; Mon, 12 Apr 2004 18:37:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CMbqPb009340 for forces-protocol-archive@odin.ietf.org; Mon, 12 Apr 2004 18:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDA3q-0002PV-1T for forces-protocol-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 18:37:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20606 for ; Mon, 12 Apr 2004 18:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDA3m-0000U7-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 18:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9Wu-0006Ec-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 18:03:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD90C-0004A5-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 17:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD90D-0005sA-6E; Mon, 12 Apr 2004 17:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD8zt-0005l9-QF for forces-protocol@optimus.ietf.org; Mon, 12 Apr 2004 17:29:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15982 for ; Mon, 12 Apr 2004 17:29:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD8zq-00046q-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 17:29:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8bY-0002BU-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 17:04:33 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BD89b-0000OB-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 16:35:39 -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 i3CKYXg8017212; Mon, 12 Apr 2004 20:34:33 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 i3CKXu7G024077; Mon, 12 Apr 2004 20:34:34 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 M2004041213343702996 ; Mon, 12 Apr 2004 13:34:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Apr 2004 13:34:37 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E93AF4A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Outline Thread-Index: AcQes/AN/YoGsbstRBaO+0hh3c+61QCGE1IQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 12 Apr 2004 20:34:37.0343 (UTC) FILETIME=[929E02F0:01C420CD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 13:34:36 -0700 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,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Weiming, Thanks for your email...see my comments below. -----Original Message----- From: Wang,Weiming [mailto:wmwang2001@hotmail.com]=20 Hi all, I also definitely support Avri as an editor. And moreover, if current scheme can not work well later (as Avri worried), I suggest WG to appoint Avri as the only neutral editor. Seems the 3+1 scheme can currently more widely be accepted, why not let's make a consensus on it and then move ahead quickly? [HK] I believe there is consensus on the 3+1 scheme already, lets go with this for now. ------------------ Hi Hormuzd, If we are now writing an Informational RFC, I think it's reasonable to take a specific first layer section for example descriptions, but if we are writing an standard RFC, I think we'd better not to do like this. From my viewpoint, it just looks a little ugly in a standard document, because we are mainly introducing the specifications of the standard instead to introduce examples. by saying this, I actully not object to take examples in the standard, but it is just for more clear understanding of readers. If you think the examples are very important, then they should not appear as examples. For instance, if you think the establish of association or CE failover scenarios are very important, they'd better to be included in a specific protocol description sections instead of as examples. =20 [HK] I agree with your comment, the better terminology here would be "Protocol Scenarios" rather than "Example Scenarios". One alternative way is to take a section as "Implementation Notes" for some important scenarios, while take some introductive examples to the Appendix. [HK] It would be a good idea to have some "Implementation Notes" as part of the appendix or may be even main sections. I have mostly seen it in Appendix so I will add it there for now. We can always change it later. Taking about TML requirements, my feeling is it may be better to be appeared in protocol overview somthing like 3. (Some section like protocol overview) ... 3. 1. The Protocol Layer (PL) and the Transportation Mapping Layer ( TML) 3. 2. TML Requirements (or some other word) ... My another feeling is if we should call it 'requirements', or we may use other word that is more relavent to describe TMP in PL. To put it in protocol overview may give us more time to have the the name decided after more discussions on TML issues. [HK] I am fine with this, we can make this change going forward if everyone agrees. For now, I will leave it as a separate section. Anyway, I agree with you that this (to decide the outline) is not very difficult thing after we have more discussions on important issues, my idea is just that currently we may not need to strictly decide it. [HK] Agreed, I'll send the rough/initial Outline to David again, we can make changes to it as we move along. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 12 18:46:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21500 for ; Mon, 12 Apr 2004 18:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDABh-0002lC-Vq for forces-protocol-archive@odin.ietf.org; Mon, 12 Apr 2004 18:45:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CMjvCd010606 for forces-protocol-archive@odin.ietf.org; Mon, 12 Apr 2004 18:45:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDABf-0002kt-P4 for forces-protocol-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 18:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21399 for ; Mon, 12 Apr 2004 18:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDABb-00013b-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 18:45:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD9er-0006ph-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 18:12:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD99w-0004qK-00 for forces-protocol-web-archive@ietf.org; Mon, 12 Apr 2004 17:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD99t-0007Qp-PD; Mon, 12 Apr 2004 17:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD99P-0007Oq-HB for forces-protocol@optimus.ietf.org; Mon, 12 Apr 2004 17:39:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16468 for ; Mon, 12 Apr 2004 17:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD99H-0004pJ-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 17:39:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8iz-0002ul-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 17:12:13 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BD8Im-00015X-00 for forces-protocol@ietf.org; Mon, 12 Apr 2004 16:45:09 -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 i3CKiLg8023245 for ; Mon, 12 Apr 2004 20:44:22 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 i3CKh8fS003188 for ; Mon, 12 Apr 2004 20:43:56 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 M2004041213442612253 for ; Mon, 12 Apr 2004 13:44:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Apr 2004 13:44:26 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Rough/Initial Outline Message-ID: <468F3FDA28AA87429AD807992E22D07E93AF6A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Rough/Initial Outline Thread-Index: AcQdNU0EhomfNLO4S9iF1v05NgpRMQAWX2zAAM/DJpA= From: "Khosravi, Hormuzd M" To: "Putzolu, David" , X-OriginalArrivalTime: 12 Apr 2004 20:44:26.0180 (UTC) FILETIME=[F1976840:01C420CE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 12 Apr 2004 13:44:25 -0700 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 Content-Transfer-Encoding: quoted-printable Hi David Here is the rough/initial Outline. I made some minor changes since my last email to incorporate Weiming's latest comments. This also signifies the completion to our 1st task according to the timeline. Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. TML Requirements 5. Common Header 6. Protocol Messages 7. Protocol Scenarios 8. Security Considerations 9. References 10. Acknowledgments Appendix A. Implementation Notes regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 13 18:21:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15124 for ; Tue, 13 Apr 2004 18:21:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDWB9-0002Ut-VJ for forces-protocol-archive@odin.ietf.org; Tue, 13 Apr 2004 18:14:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DMEp9f009594 for forces-protocol-archive@odin.ietf.org; Tue, 13 Apr 2004 18:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVwY-00036p-Qe for forces-protocol-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12370 for ; Tue, 13 Apr 2004 17:59:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDVwV-0000Da-00 for forces-protocol-web-archive@ietf.org; Tue, 13 Apr 2004 17:59:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDVkY-0006VK-00 for forces-protocol-web-archive@ietf.org; Tue, 13 Apr 2004 17:47:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDVXN-0005JT-00 for forces-protocol-web-archive@ietf.org; Tue, 13 Apr 2004 17:33:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDVUA-0003pN-2H for forces-protocol-web-archive@ietf.org; Tue, 13 Apr 2004 17:30:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVII-0006mv-9C; Tue, 13 Apr 2004 17:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUfk-0004s2-8v for forces-protocol@optimus.ietf.org; Tue, 13 Apr 2004 16:38:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06069 for ; Tue, 13 Apr 2004 16:38:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUfg-0007aL-00 for forces-protocol@ietf.org; Tue, 13 Apr 2004 16:38:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUXz-0006lY-00 for forces-protocol@ietf.org; Tue, 13 Apr 2004 16:30:20 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BDUT1-00061z-00 for forces-protocol@ietf.org; Tue, 13 Apr 2004 16:25:11 -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 i3DKOVgO006546 for ; Tue, 13 Apr 2004 20:24:32 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 i3DKNtIX016873 for ; Tue, 13 Apr 2004 20:23:58 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 M2004041313235623834 for ; Tue, 13 Apr 2004 13:23:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Apr 2004 13:23:56 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42195.3EED4399" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E93BA95@orsmsx408.jf.intel.com> Thread-Topic: testing-questions ? Thread-Index: AcQhlT46Kxg8DJZLRqO3WupQrgvm+g== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 13 Apr 2004 20:23:56.0572 (UTC) FILETIME=[3F19DDC0:01C42195] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] testing-questions ? Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 13 Apr 2004 13:23:56 -0700 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,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42195.3EED4399 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since the list has been very quite, I am testing to see if its again a problem with the server. =20 BTW, did you guys receive my emails with the Outline and Protocol Messages ?? Pls do let me know =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C42195.3EED4399 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Since = the list has=20 been very quite, I am testing to see if its again a problem with the=20 server.
 
BTW, = did you guys=20 receive my emails with the Outline and Protocol Messages = ??
Pls do = let me=20 know
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C42195.3EED4399-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 10:14:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27027 for ; Wed, 14 Apr 2004 10:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl83-0002sL-Bp for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:12:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EECdHv011052 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxN-0002Fq-3i for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:01:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25582 for ; Wed, 14 Apr 2004 10:01:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkxL-0001FH-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:01:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkwR-00012L-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:00:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDkuu-0000pK-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 09:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDksv-0008CO-JS; Wed, 14 Apr 2004 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkY8-0000Lr-4o for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 09:35:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23820 for ; Wed, 14 Apr 2004 09:35:29 -0400 (EDT) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkY6-0004XY-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 09:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkX7-0004PJ-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 09:34:30 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BDkW5-0004CC-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 09:33:25 -0400 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 14 Apr 2004 21:45:06 +0800 Received: from 219.82.179.244 ( [219.82.179.244]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Wed, 14 Apr 2004 21:45:05 +0800 Message-ID: <1081950305.407d406209961@mail.hzic.edu.cn> To: hormuzd.m.khosravi@intel.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Rough/Initial Outline MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 21:45:05 +0800 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,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Thank you for forwarding the post to me. Actually I'v seen all the posts via the list archive. The problem is just I can not post anything because my server was down for several days. The improved outline is better now. I agree we currently decide it and along with the progress, we are open to modifiy it. I'll make comments on your protocol messages proposals tomorrow. Thank you. BR Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" Sent: Wednesday, April 14, 2004 12:39 PM Subject: FW: [Forces-protocol] Rough/Initial Outline FYI, hope you have seen these emails on the list Quoting "Khosravi, Hormuzd M" : > Hi David > > Here is the rough/initial Outline. I made some minor changes since my > last email to incorporate Weiming's latest comments. This also signifies > the completion to our 1st task according to the timeline. > > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. TML Requirements > 5. Common Header > 6. Protocol Messages > 7. Protocol Scenarios > 8. Security Considerations > 9. References > 10. Acknowledgments > Appendix > A. Implementation Notes > > > regards > Hormuzd > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > ------------------------------------------------- This mail sent through HUCNIC Webmail system. Delete | Reply | Reply to All | Forward | Redirect | Message Source | Save as | Print Back to sent-mail ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 10:32:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28184 for ; Wed, 14 Apr 2004 10:32:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlKq-000884-MR for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEPqjN031240 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:25:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlFx-00073i-Bc for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:20:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27729 for ; Wed, 14 Apr 2004 10:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlFv-00041F-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:20:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlEq-0003tL-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:19:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDlEQ-0003mP-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:19:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8W-0003F3-Dv; Wed, 14 Apr 2004 10:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxd-0002Ue-Lh for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25623 for ; Wed, 14 Apr 2004 10:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkxb-0001Hi-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:01:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkwt-00019F-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:01:07 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkwA-0000yx-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:00:22 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041407033516:6315 ; Wed, 14 Apr 2004 07:03:35 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1081951216.1027.0.camel@jzny.localdomain> 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 04/14/2004 07:03:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 07:03:37 AM, Serialize complete at 04/14/2004 07:03:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] test Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:00:17 -0400 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 Content-Transfer-Encoding: 7bit testing .. Havent seen any activity lately cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 10:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29197 for ; Wed, 14 Apr 2004 10:56:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlkK-0004kX-JJ for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:52:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EEqCuB018250 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 10:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlf2-0003lV-VR for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 10:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28715 for ; Wed, 14 Apr 2004 10:46:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlf0-000751-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:46:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDleA-0006x8-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:45:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDldW-0006ol-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 10:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlYX-0002d6-BR; Wed, 14 Apr 2004 10:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlRM-0000oh-Nh for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28182 for ; Wed, 14 Apr 2004 10:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlRJ-0005Q1-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:32:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlQP-0005K3-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:31:37 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlPz-0005Dt-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:31:11 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041407342418:6341 ; Wed, 14 Apr 2004 07:34:24 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org In-Reply-To: <1081951216.1027.0.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081953068.1026.32.camel@jzny.localdomain> 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 04/14/2004 07:34:24 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 07:34:25 AM, Serialize complete at 04/14/2004 07:34:25 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:31:08 -0400 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 Content-Transfer-Encoding: 7bit Still testing: here are the headers. Theres no way the clock at optimus.ietf.org could be correct. Also note I sent at 07:03:35 -0700 and received an echo at 07:22:26 -0700 which is about 19 minutes. odin.ietf.org to optimus.ietf.org was 10 minutes. Lets see how long this is gonna take. cheers, jamal Received: from mailhub.znyx.com ([208.2.156.141]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041407222643:6329 ; Wed, 14 Apr 2004 07:22:26 -0700 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id i3EDU1BR066599 for ; Wed, 14 Apr 2004 06:30:02 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8W-0003F1-Ck; Wed, 14 Apr 2004 10:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxd-0002Ue-Lh for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25623 for ; Wed, 14 Apr 2004 10:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkxb-0001Hi-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:01:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkwt-00019F-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:01:07 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDkwA-0000yx-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:00:22 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041407033516:6315 ; Wed, 14 Apr 2004 07:03:35 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1081951216.1027.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 On Wed, 2004-04-14 at 10:00, Jamal Hadi Salim wrote: > testing .. > Havent seen any activity lately > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 11:43:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02525 for ; Wed, 14 Apr 2004 11:43:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmX9-0006aP-RD for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFgdkV025312 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmUz-0006Dh-Pz for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02188 for ; Wed, 14 Apr 2004 11:40:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmUy-0002al-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:40:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmTu-0002QH-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:39:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDmS8-0002DY-04 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2a-0000Go-FY; Wed, 14 Apr 2004 11:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlr8-0005tY-Qo for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:59:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29395 for ; Wed, 14 Apr 2004 10:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlr6-0000R8-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlqF-0000OO-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:58:20 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlpl-0000L4-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:49 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408010248:6375 ; Wed, 14 Apr 2004 08:01:02 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: hormuzd.m.khosravi@intel.com In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081954661.1026.68.camel@jzny.localdomain> 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 04/14/2004 08:01:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:01:04 AM, Serialize complete at 04/14/2004 08:01:04 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:57:41 -0400 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 Content-Transfer-Encoding: 7bit CC to Hormuzd On Wed, 2004-04-14 at 10:31, Jamal Hadi Salim wrote: > Still testing: > here are the headers. > Theres no way the clock at optimus.ietf.org could be correct. > Also note I sent at 07:03:35 -0700 and received an echo at 07:22:26 > -0700 which is about 19 minutes. odin.ietf.org to optimus.ietf.org was > 10 minutes. > > Lets see how long this is gonna take. > > cheers, > jamal > > Received: from mailhub.znyx.com ([208.2.156.141]) by lotus.znyx.com > (Lotus > Domino Release 5.0.11) with ESMTP id 2004041407222643:6329 ; > Wed, 14 Apr > 2004 07:22:26 -0700 > Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by > mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id i3EDU1BR066599 > for > ; Wed, 14 Apr 2004 06:30:02 -0700 (PDT) > Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8W-0003F1-Ck; > Wed, 14 Apr > 2004 10:13:08 -0400 > Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxd-0002Ue-Lh for > forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:01:53 > -0400 > Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org > (8.9.1a/8.9.1a) with ESMTP id KAA25623 for > ; Wed, > 14 Apr 2004 10:01:50 -0400 (EDT) > Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) > id > 1BDkxb-0001Hi-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:51 > -0400 > Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id > 1BDkwt-00019F-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:07 > -0400 > Received: from znx208-2-156-007.znyx.com ([208.2.156.7] > helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id > 1BDkwA-0000yx-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:00:22 -0400 > Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus > Domino > Release 5.0.11) with ESMTP id 2004041407033516:6315 ; Wed, 14 > Apr 2004 > 07:03:35 -0700 > From: Jamal Hadi Salim > Reply-To: hadi@znyx.com > To: forces-protocol@ietf.org > Organization: Znyx Networks > Message-Id: <1081951216.1027.0.camel@jzny.localdomain> > Mime-Version: 1.0 > X-Mailer: Ximian Evolution 1.2.2 > > > On Wed, 2004-04-14 at 10:00, Jamal Hadi Salim wrote: > > testing .. > > Havent seen any activity lately > > > > cheers, > > jamal > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 11:49:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02824 for ; Wed, 14 Apr 2004 11:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmX9-0006Zr-Dy for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFgd5m025278 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmUo-0006DZ-Dq for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:40:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02175 for ; Wed, 14 Apr 2004 11:40:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmUn-0002Yt-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:40:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmTr-0002Pf-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:39:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDmS8-0002DY-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2a-0000GX-34; Wed, 14 Apr 2004 11:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqz-0005rO-Re for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29367 for ; Wed, 14 Apr 2004 10:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlqx-0000Q7-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlpu-0000MB-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:59 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlp4-0000In-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:06 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408001823:6374 ; Wed, 14 Apr 2004 08:00:18 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081954622.1025.65.camel@jzny.localdomain> 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 04/14/2004 08:00:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:00:21 AM, Serialize complete at 04/14/2004 08:00:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:57:02 -0400 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 Content-Transfer-Encoding: 7bit Ok, much better this time - took about 14 minutes to get an echo. optimus-odin path is still the bottleneck with 9 minutes spent within those hosts I am gonna cc a few people and see if that affects anything. Start with Weiming, then Hormuzd and then both cheers, jamal On Wed, 2004-04-14 at 10:31, Jamal Hadi Salim wrote: > Still testing: > here are the headers. > Theres no way the clock at optimus.ietf.org could be correct. > Also note I sent at 07:03:35 -0700 and received an echo at 07:22:26 > -0700 which is about 19 minutes. odin.ietf.org to optimus.ietf.org was > 10 minutes. > > Lets see how long this is gonna take. > > cheers, > jamal > > Received: from mailhub.znyx.com ([208.2.156.141]) by lotus.znyx.com > (Lotus > Domino Release 5.0.11) with ESMTP id 2004041407222643:6329 ; > Wed, 14 Apr > 2004 07:22:26 -0700 > Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by > mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id i3EDU1BR066599 > for > ; Wed, 14 Apr 2004 06:30:02 -0700 (PDT) > Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8W-0003F1-Ck; > Wed, 14 Apr > 2004 10:13:08 -0400 > Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxd-0002Ue-Lh for > forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:01:53 > -0400 > Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org > (8.9.1a/8.9.1a) with ESMTP id KAA25623 for > ; Wed, > 14 Apr 2004 10:01:50 -0400 (EDT) > Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) > id > 1BDkxb-0001Hi-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:51 > -0400 > Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id > 1BDkwt-00019F-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:07 > -0400 > Received: from znx208-2-156-007.znyx.com ([208.2.156.7] > helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id > 1BDkwA-0000yx-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:00:22 -0400 > Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus > Domino > Release 5.0.11) with ESMTP id 2004041407033516:6315 ; Wed, 14 > Apr 2004 > 07:03:35 -0700 > From: Jamal Hadi Salim > Reply-To: hadi@znyx.com > To: forces-protocol@ietf.org > Organization: Znyx Networks > Message-Id: <1081951216.1027.0.camel@jzny.localdomain> > Mime-Version: 1.0 > X-Mailer: Ximian Evolution 1.2.2 > > > On Wed, 2004-04-14 at 10:00, Jamal Hadi Salim wrote: > > testing .. > > Havent seen any activity lately > > > > cheers, > > jamal > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 11:49:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02841 for ; Wed, 14 Apr 2004 11:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmX9-0006a8-Kb for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EFgdf6025295 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 11:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmUq-0006Dd-Mh for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 11:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02182 for ; Wed, 14 Apr 2004 11:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmUp-0002ZB-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:40:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmTs-0002Py-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:39:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDmS8-0002DY-02 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 11:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2b-0000H3-28; Wed, 14 Apr 2004 11:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlsr-00068b-BK for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 11:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29545 for ; Wed, 14 Apr 2004 11:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlso-0000X1-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlrs-0000Sr-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:00:01 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlr0-0000QL-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:06 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408021746:6379 ; Wed, 14 Apr 2004 08:02:17 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn, hormuzd.m.khosravi@intel.com In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081954731.1027.72.camel@jzny.localdomain> 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 04/14/2004 08:02:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:02:20 AM, Serialize complete at 04/14/2004 08:02:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:58:51 -0400 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 Content-Transfer-Encoding: 7bit ccing both Hormuzd and Weiming On Wed, 2004-04-14 at 10:31, Jamal Hadi Salim wrote: > Still testing: > here are the headers. > Theres no way the clock at optimus.ietf.org could be correct. > Also note I sent at 07:03:35 -0700 and received an echo at 07:22:26 > -0700 which is about 19 minutes. odin.ietf.org to optimus.ietf.org was > 10 minutes. > > Lets see how long this is gonna take. > > cheers, > jamal > > Received: from mailhub.znyx.com ([208.2.156.141]) by lotus.znyx.com > (Lotus > Domino Release 5.0.11) with ESMTP id 2004041407222643:6329 ; > Wed, 14 Apr > 2004 07:22:26 -0700 > Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by > mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id i3EDU1BR066599 > for > ; Wed, 14 Apr 2004 06:30:02 -0700 (PDT) > Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDl8W-0003F1-Ck; > Wed, 14 Apr > 2004 10:13:08 -0400 > Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by > optimus.ietf.org with esmtp (Exim 4.20) id 1BDkxd-0002Ue-Lh for > forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:01:53 > -0400 > Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org > (8.9.1a/8.9.1a) with ESMTP id KAA25623 for > ; Wed, > 14 Apr 2004 10:01:50 -0400 (EDT) > Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) > id > 1BDkxb-0001Hi-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:51 > -0400 > Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id > 1BDkwt-00019F-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 > 10:01:07 > -0400 > Received: from znx208-2-156-007.znyx.com ([208.2.156.7] > helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id > 1BDkwA-0000yx-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:00:22 -0400 > Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus > Domino > Release 5.0.11) with ESMTP id 2004041407033516:6315 ; Wed, 14 > Apr 2004 > 07:03:35 -0700 > From: Jamal Hadi Salim > Reply-To: hadi@znyx.com > To: forces-protocol@ietf.org > Organization: Znyx Networks > Message-Id: <1081951216.1027.0.camel@jzny.localdomain> > Mime-Version: 1.0 > X-Mailer: Ximian Evolution 1.2.2 > > > On Wed, 2004-04-14 at 10:00, Jamal Hadi Salim wrote: > > testing .. > > Havent seen any activity lately > > > > cheers, > > jamal > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 13:20:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08103 for ; Wed, 14 Apr 2004 13:20:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDntn-0007YK-Cc for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHA7Bg029027 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnPk-00005v-CR for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04917 for ; Wed, 14 Apr 2004 12:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnPi-0005au-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:39:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnOo-0005Vw-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:38:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnNu-0005Rt-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBX-00050k-NV; Wed, 14 Apr 2004 12:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmSh-0005NV-EG for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 11:38:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01841 for ; Wed, 14 Apr 2004 11:38:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmSg-0002JB-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:38:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmRe-00028Y-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:36:58 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmQj-00027d-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:36:01 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408391414:6439 ; Wed, 14 Apr 2004 08:39:14 -0700 Subject: should we move the list? Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn, hormuzd.m.khosravi@intel.com, Greg Cunningham In-Reply-To: <1081954731.1027.72.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> <1081954731.1027.72.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081956952.1024.118.camel@jzny.localdomain> 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 04/14/2004 08:39:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:39:15 AM, Serialize complete at 04/14/2004 08:39:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 11:35:52 -0400 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 Content-Transfer-Encoding: 7bit This took 25 minutes to see the echo. Clearly the path inside the IETF servers is overloaded, specifically: ---------------- Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2a-0000GV-1k; Wed, 14 Apr 2004 11:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqz-0005rO-Re for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29367 for ; Wed, 14 Apr 2004 10:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlqx-0000Q7-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:03 -0400 ---------------- Greg, apologies for forwarding to you in person - couldnt find the ietf list to send to. anything above 5 minutes in a heated discussion is unreasonable in my opinion. There are two approaches we could take: 1. We could move the list to a less loaded server which also archives. sourceforge and savanah come to mind - maybe even yahoo 2. Suggested by Hormuzd: We could cc everyone on the list - theres only 7 people and the cc the list. The pain is you may receive two emails the advantage is reduced delays. Thoughts? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 13:20:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08117 for ; Wed, 14 Apr 2004 13:20:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnuI-0007Zg-QJ for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:10:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHAciK029112 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:10:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnQC-00007y-TD for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04969 for ; Wed, 14 Apr 2004 12:39:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnQB-0005en-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:39:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnP6-0005Z7-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:38:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDnOU-0005UJ-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:37:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBZ-00051U-HL; Wed, 14 Apr 2004 12:24:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmUI-0005mc-OU for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 11:39:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02050 for ; Wed, 14 Apr 2004 11:39:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmUH-0002U2-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:39:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmSa-0002IJ-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:37:57 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmRQ-000283-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:36:44 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408395732:6440 ; Wed, 14 Apr 2004 08:39:57 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E8B2E43@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E8B2E43@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1081957000.1023.121.camel@jzny.localdomain> 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 04/14/2004 08:39:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:39:58 AM, Serialize complete at 04/14/2004 08:39:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 11:36:40 -0400 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-09 at 19:22, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > True on introducing more complexities - not sure i agree on the > "unwanted" part. Maybe this is something that we need to decide on first > before moving forward. Do we wanna say it that Forces can work only on > the spefic TMLs? > > [HK] No we don't, but that doesn't mean we need to define and > standardize an API. Look at GSMP for example, it doesn't define an API > but can still function on multiple TMLs. Why cant we use a similar > approach ? Any particular GSMP RFCs/drafts? Hopefully it will provide an alternative approach, otherwise i dont see how to escape the defining of such services that the TML exposes. > > The interfaces between the layers is completely implementation > > dependent. > > I think it may be beyond "implementation" specific now that we have > decided to go TMLs, no? I still would like our customers to use their > own TMLs as long as they provide "services" to the PL layer for the > items you mention: reliability, congestion control, security, HA etc. > Infact in their own private environment i would like to care less if > they present those services to the PL layer or not. Seems to me like > this would provide greater spread for Forces. > > I believe we need to decide on this issue before moving forward. > > [HK] Sure your customers can use their own TMLs, infact that is the > idea. But as you said, what is important are the services or > requirements for TMLs such as reliability, etc. > Right, but exposing the abilities of the TML to meet the desires of the the PL needs an interface defined. > > [HK] Sure the layering will need an API in some implementations, but we > don't need to define those APIs. Lets leave this to the vendors who > implement the protocol. In any case, do you really think we can > standardize APIs in the IETF ? > We need to define an interface that TMLs can attach to (or looked at from the other side PLs can attach to). Whether its a protocol between TML and PL(TCP would be fine to me) or an API is not as important - the important piece is an agreement that such an interface is needed to begin with. I dont think the IETF is adverse to standardizing on some sane APIs when it is sensible; example: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 13:24:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08370 for ; Wed, 14 Apr 2004 13:24:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo0b-00018N-Nq for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHH997004354 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDni6-0005WK-OV for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05827 for ; Wed, 14 Apr 2004 12:57:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDni5-00072H-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnfw-0006g7-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:55:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDnel-0006VE-04 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:54:35 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDnbx-0002jA-BP for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:51:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCI-0005J1-LY; Wed, 14 Apr 2004 12:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmso-0001VX-3N for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 12:05:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03345 for ; Wed, 14 Apr 2004 12:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmsm-0003f3-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 12:05:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDms2-0003e9-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 12:04:15 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmrg-0003bQ-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 12:03:52 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041409070429:6494 ; Wed, 14 Apr 2004 09:07:04 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org In-Reply-To: <1081959106.407d62c25de09@mail.hzic.edu.cn> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> <1081954622.1025.65.camel@jzny.localdomain> <1081959106.407d62c25de09@mail.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1081958617.1027.136.camel@jzny.localdomain> 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 04/14/2004 09:07:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 09:07:07 AM, Serialize complete at 04/14/2004 09:07:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 12:03:37 -0400 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,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Weiming, 13 minutes is still bad. What suprises me about the IETF path is the spamassasin machine is not the slowest node. Typically, spamfilters are supposed to be the highest concentration of delay. cheers, jamal On Wed, 2004-04-14 at 12:11, wmwang@mail.hzic.edu.cn wrote: > Hi Jamal, > > Thanks for the test. Following are two headers for my server to get the direct > one and the one via the list. You sent at 22:57+0800, and my server got direct > on it at 23:10+0800 (took about 13 minutes), got the via list one at 23:34+0800 > (took about 47 mintes). And seems the obtimus.ietf.org server consume the most. > > BR > Weiming > > ------------------------------ > Return-path: > Received: from optimus.ietf.org (unverified [132.151.6.22]) by ns1.hzic.net > (Rockliffe SMTPRA 4.5.6) with ESMTP id ; > Wed, 14 Apr 2004 23:34:27 +0800 > Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) > by optimus.ietf.org with esmtp (Exim 4.20) > id 1BDm2Z-0000GS-UF; Wed, 14 Apr 2004 11:11:03 -0400 > Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) > by optimus.ietf.org with esmtp (Exim 4.20) > id 1BDlqz-0005rO-Re > for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:59:05 -0400 > Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29367 > for ; Wed, 14 Apr 2004 10:59:01 -0400 (EDT) > Received: from ietf-mx ([132.151.6.1]) > by ietf-mx with esmtp (Exim 4.12) > id 1BDlqx-0000Q7-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:03 -0400 > Received: from exim by ietf-mx with spam-scanned (Exim 4.12) > id 1BDlpu-0000MB-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:59 -0400 > Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) > by ietf-mx with esmtp (Exim 4.12) > id 1BDlp4-0000In-00 > for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:06 -0400 > Received: from [10.0.0.21] ([208.2.156.2]) > by lotus.znyx.com (Lotus Domino Release 5.0.11) > with ESMTP id 2004041408001823:6374 ; > Wed, 14 Apr 2004 08:00:18 -0700 > Subject: Re: [Forces-protocol] test > From: Jamal Hadi Salim > Reply-To: hadi@znyx.com > To: forces-protocol@ietf.org > Cc: wmwang@mail.hzic.edu.cn > In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> > References: <1081951216.1027.0.camel@jzny.localdomain> > <1081953068.1026.32.camel@jzny.localdomain> > Organization: Znyx Networks > Message-Id: <1081954622.1025.65.camel@jzny.localdomain> > 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 04/14/2004 > 08:00:18 AM, > Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at > 04/14/2004 > 08:00:21 AM, > Serialize complete at 04/14/2004 08:00:21 AM > Content-Transfer-Encoding: 7bit > Content-Type: text/plain > 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 > Sender: forces-protocol-admin@ietf.org > Errors-To: forces-protocol-admin@ietf.org > X-BeenThere: forces-protocol@ietf.org > X-Mailman-Version: 2.0.12 > Precedence: bulk > List-Unsubscribe: , > > List-Id: forces-protocol > List-Post: > List-Help: > List-Subscribe: , > > List-Archive: protocol/> > Date: 14 Apr 2004 10:57:02 -0400 > > ----------------------- > > Return-path: > Received: from lotus.znyx.com (unverified [208.2.156.7]) by ns1.hzic.net > (Rockliffe SMTPRA 4.5.6) with ESMTP id for > ; > Wed, 14 Apr 2004 23:10:21 +0800 > Received: from [10.0.0.21] ([208.2.156.2]) > by lotus.znyx.com (Lotus Domino Release 5.0.11) > with ESMTP id 2004041408001823:6374 ; > Wed, 14 Apr 2004 08:00:18 -0700 > Subject: Re: [Forces-protocol] test > From: Jamal Hadi Salim > Reply-To: hadi@znyx.com > To: forces-protocol@ietf.org > Cc: wmwang@mail.hzic.edu.cn > In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> > References: <1081951216.1027.0.camel@jzny.localdomain> > <1081953068.1026.32.camel@jzny.localdomain> > Organization: Znyx Networks > Message-Id: <1081954622.1025.65.camel@jzny.localdomain> > Mime-Version: 1.0 > X-Mailer: Ximian Evolution 1.2.2 > Date: 14 Apr 2004 10:57:02 -0400 > X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, > 2002) at 04/14/2004 > 08:00:18 AM, > Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at > 04/14/2004 > 08:01:12 AM, > Serialize complete at 04/14/2004 08:01:12 AM > Content-Transfer-Encoding: 7bit > Content-Type: text/plain > > Quoting Jamal Hadi Salim : > > > > > Ok, much better this time - took about 14 minutes to get an echo. > > optimus-odin path is still the bottleneck with 9 minutes spent within > > those hosts > > > > I am gonna cc a few people and see if that affects anything. Start with > > Weiming, then Hormuzd and then both > > > > cheers, > > jamal > > > > ------------------------------------------------- > This mail sent through HUCNIC Webmail system. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 13:25:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08501 for ; Wed, 14 Apr 2004 13:25:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo0h-0001Bz-W1 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHHFea004579 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 13:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDniN-0005dG-Kh for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 12:58:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05898 for ; Wed, 14 Apr 2004 12:58:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDniL-00074w-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:58:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDngC-0006jK-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:56:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDneo-0006VE-04 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:54:38 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDnbd-0002iG-8W for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 12:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCF-0005Ha-UB; Wed, 14 Apr 2004 12:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmoz-0000ya-50 for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 12:01:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03212 for ; Wed, 14 Apr 2004 12:01:02 -0400 (EDT) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmox-0003VK-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 12:01:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmo3-0003Tc-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 12:00:08 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BDmnX-0003S2-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:59:36 -0400 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 15 Apr 2004 00:11:46 +0800 Received: from 219.82.179.244 ( [219.82.179.244]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Thu, 15 Apr 2004 00:11:46 +0800 Message-ID: <1081959106.407d62c25de09@mail.hzic.edu.cn> To: forces-protocol@ietf.org Cc: hadi@znyx.com Subject: Re: [Forces-protocol] test References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> <1081954622.1025.65.camel@jzny.localdomain> In-Reply-To: <1081954622.1025.65.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 00:11:46 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jamal, Thanks for the test. Following are two headers for my server to get the direct one and the one via the list. You sent at 22:57+0800, and my server got direct on it at 23:10+0800 (took about 13 minutes), got the via list one at 23:34+0800 (took about 47 mintes). And seems the obtimus.ietf.org server consume the most. BR Weiming ------------------------------ Return-path: Received: from optimus.ietf.org (unverified [132.151.6.22]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 14 Apr 2004 23:34:27 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDm2Z-0000GS-UF; Wed, 14 Apr 2004 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDlqz-0005rO-Re for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 10:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29367 for ; Wed, 14 Apr 2004 10:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDlqx-0000Q7-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:59:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlpu-0000MB-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:59 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BDlp4-0000In-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:57:06 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408001823:6374 ; Wed, 14 Apr 2004 08:00:18 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081954622.1025.65.camel@jzny.localdomain> 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 04/14/2004 08:00:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:00:21 AM, Serialize complete at 04/14/2004 08:00:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:57:02 -0400 ----------------------- Return-path: Received: from lotus.znyx.com (unverified [208.2.156.7]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 14 Apr 2004 23:10:21 +0800 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041408001823:6374 ; Wed, 14 Apr 2004 08:00:18 -0700 Subject: Re: [Forces-protocol] test From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn In-Reply-To: <1081953068.1026.32.camel@jzny.localdomain> References: <1081951216.1027.0.camel@jzny.localdomain> <1081953068.1026.32.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1081954622.1025.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Apr 2004 10:57:02 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:00:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 08:01:12 AM, Serialize complete at 04/14/2004 08:01:12 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Quoting Jamal Hadi Salim : > > Ok, much better this time - took about 14 minutes to get an echo. > optimus-odin path is still the bottleneck with 9 minutes spent within > those hosts > > I am gonna cc a few people and see if that affects anything. Start with > Weiming, then Hormuzd and then both > > cheers, > jamal ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 14:59:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14858 for ; Wed, 14 Apr 2004 14:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpVd-0006aI-Ut for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 14:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIrHXG025310 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 14:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpDG-00068y-1J for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 14:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13519 for ; Wed, 14 Apr 2004 14:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpDD-0006gg-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 14:34:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpCJ-0006ay-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 14:33:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDpBh-0006X4-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 14:32:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDozX-0002aU-Nd; Wed, 14 Apr 2004 14:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDop9-00084s-OJ for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 14:09:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12060 for ; Wed, 14 Apr 2004 14:09:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDop7-0005BP-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 14:09:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDooS-00055J-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 14:08:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDon3-0004xY-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 14:07:13 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDoaE-0004MD-KZ for forces-protocol@ietf.org; Wed, 14 Apr 2004 13:53:58 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041410570999:6662 ; Wed, 14 Apr 2004 10:57:09 -0700 Subject: Re: [Forces-protocol] Protocol Messages From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn In-Reply-To: <468F3FDA28AA87429AD807992E22D07E8B2D6B@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E8B2D6B@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1081965229.1026.250.camel@jzny.localdomain> 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 04/14/2004 10:57:10 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/14/2004 10:57:12 AM, Serialize complete at 04/14/2004 10:57:12 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 13:53:49 -0400 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-09 at 18:20, Khosravi, Hormuzd M wrote: > Here is an initial list of protocol messages... > (I have tried to merge messages from all 3 protocols without adding > too many messages) We need to distinguish which is issued by PL and which by TML. > 1.Association Setup Messages > Join Request/Response > Leave Req/Resp This is TML as i see it. i.e the PL never sees these messages. The TML MUST send events to the PL (to report the movement to a new peer etc) > 2. Capability Control Messages > Query Req/Resp (including FE, LFB Topology Query) Terminates at TML. > Capability Req/Resp Both TL and PML play a role. The way i would see this is PL-TML interface will have the PL register its capabalities, then TML will advertise the capability. It should also be able to issue these messages as > Configuration Req/Resp The real meat. TML "routes it" to the PL based on PID. > 3. Control Packet or Traffic Maintenance Messages > CP Redirect to CE > CP Forward to FE Would this be achieved by an LFB redirector at the FE->CE level? > 4. Event Notification Messages > Event Register/De-register Req/Resp > Asynchronous FE Event (including DoS events) We need to separate between events from TML->PL, and PL<->PL > 5. Management Object or SNMP support Messages > MO Get/Set > MO Response Not sure i see this. Why are we mixing SNMP here? > 6. State Maintenance Messages (or HA related messages) > PE Up/Down > PE Active/InActive (equivalent to the "Move" command that Jamal > described) Dont understand this part. Are these commands or events? > HeartBeat or Keep-alive Probably two/three types. One for PL<->PL heartbeats another TML<->TML heartbeats and maybe TML<->PL > 7. Vendor Specific messages (Optional ?) > VS Request > VS Response I think we can have some codes that are "private" - the problem is these values must be negotiated if we go that path. > Let me know what you guys think. Some of the terminology might be > different but the semantics are quite similar in all the protocols. Good start but theres a lot of details to be ironed out. I honestly wasnt thinking clearly after lunch while responding to these messages, so i did not scrutinize your categories for message breakdown. I will later on think about it and see if i can add more or generalize some of them. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 14 21:49:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10254 for ; Wed, 14 Apr 2004 21:49:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDvzq-0007IK-Cy for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 21:48:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F1msG7028035 for forces-protocol-archive@odin.ietf.org; Wed, 14 Apr 2004 21:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDvxs-0006cj-2u for forces-protocol-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 21:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10171 for ; Wed, 14 Apr 2004 21:46:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDvxp-0005HP-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 21:46:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDvwu-0005EG-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 21:45:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDvw0-0005B6-00 for forces-protocol-web-archive@ietf.org; Wed, 14 Apr 2004 21:44:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDvtB-0005Yu-UT; Wed, 14 Apr 2004 21:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDvs9-00058F-5R for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 21:40:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10033 for ; Wed, 14 Apr 2004 21:40:53 -0400 (EDT) From: avri@acm.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDvs6-0004xk-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 21:40:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDvrJ-0004uY-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 21:40:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BDvqh-0004qD-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 21:39:27 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BDvqg-0004vf-MS for forces-protocol@ietf.org; Thu, 15 Apr 2004 01:39:26 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E93AF6A@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E93AF6A@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Rough/Initial Outline To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 14 Apr 2004 21:39:25 -0400 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 Content-Transfer-Encoding: 7bit Other then adding an IANA considerations, and I am sure we will have them, I am fine with the basic outline. a. On 12 apr 2004, at 16.44, Khosravi, Hormuzd M wrote: > Hi David > > Here is the rough/initial Outline. I made some minor changes since my > last email to incorporate Weiming's latest comments. This also > signifies > the completion to our 1st task according to the timeline. > > Abstract > 1. Introduction > 2. Definitions > 3. Protocol Overview > 4. TML Requirements > 5. Common Header > 6. Protocol Messages > 7. Protocol Scenarios > 8. Security Considerations > 9. References > 10. Acknowledgments > Appendix > A. Implementation Notes > > > regards > Hormuzd > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 12:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02863 for ; Thu, 15 Apr 2004 12:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Rw-0006Os-5t for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:10:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGAmwD024598 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Hq-0003iH-81 for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:00:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01839 for ; Thu, 15 Apr 2004 12:00:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Hp-0001GH-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:00:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9Gz-0001Av-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 11:59:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9G9-00015K-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 11:58:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96r-00011R-8A; Thu, 15 Apr 2004 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8xJ-00067I-CV for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 11:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01113 for ; Thu, 15 Apr 2004 11:39:06 -0400 (EDT) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8xI-0007EU-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8wJ-00078I-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:38:08 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BE8vK-0006yz-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:37:08 -0400 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 15 Apr 2004 23:49:13 +0800 Received: from 219.82.167.195 ( [219.82.167.195]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Thu, 15 Apr 2004 23:49:12 +0800 Message-ID: <1082044152.407eaef9912e0@mail.hzic.edu.cn> To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn Subject: Re: [Forces-protocol] Protocol Messages MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 23:49:12 +0800 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: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Jamal, To be hornest, I think we have some different ideas on how protocol messages are arranged. The difference mainly lies in how detailedly we should categorize the messages. I more tend to categorize the messages in more details, seems Jamal likes less messages and Hormuzd is in the middle. Therefore, I kindly suggest that we all propose our original thoughts first, then we work together to summarize them. In this way, I think we may be not easy to leave behind something but easy to see if the final conclusion include everything. By discussion, we can also exclude things that we don't need. I'l first propose my idea (Hormuzd, pls believe I'm not pushing it, just for easy discussion) and then try to understand Hormuzd's proposal. My proposal is as: 1. FE (Couase Layer)Management Messages 1.1 FE Join Request Message 1.2 FE Leave Request Message 1.3 FE Capability Query / Response Message including (inter) FE topology, etc. 1.4 FE State Manipulate Message for FE Up, Down, Active, Inactive, etc. 1.5 FE Attribute Manipulate Message for FE attribute add, modify, delete, query / response. FE attributes include FE couase layer attributes defined by FE model, attributes for TML configurations, for DoS policies, graceful restart policies, etc. FE event subscirbe/unsubscibe can also be described as an FE attribute. 1.6 FE Event Report Message An FE heartbeat is treated as an FE event. 2. LFB Management Messages 2.1 LFB state Manipulate Message for LFB Up, Down, Active, Inactive, etc. 2.2 LFB Capability query / Response Message including LFB topology 2.3. LFB Attribute Manipulate Message including LFB attribute add, modify, delete, query/resp. , etc. 2.4 LFB event report message 2.5 LFB topology manipulate message for Datapath add, modify, delete, query/resp. , etc, including the operation on LFB topology. 3. CE Informing Messages 3.1 CE Query request / Response Message 3.2 CE Event Report Message (a CE heatbeat can be defined as a CE event) 4. Managed Object (MO) Management Messages MO Get/Set/Resp. Messages (as Jamal said in the reply to Hormuzd's, we need to discuss more on if this is needed. My original thought to propose this in GRMP is actually from the Requirement and the Framework, where it is required that an MO in the FE side is better operated by CE even though the SNMP command first arrives at the FE, that is, the FE should first redirect the SNMP command to CE then let CE to do the operation. If we do not like the messages, an alternative way is to define FE attribute for such operations, but I still have no idea how such attribute should be defined.) 5. Packet Redirection Messages Pls see more comments in the lines followed. Best regards, Weiming From: "Khosravi, Hormuzd M" Here is an initial list of protocol messages... (I have tried to merge messages from all 3 protocols without adding too many messages) 1.Association Setup Messages Join Request/Response Leave Req/Resp [Weiming] We need to discuss if a Join Response and a Leave Response Message here are necessary. The reasons are a. it means less, because a FE state maintaince message is still needed to be followed to let the FE change the state after the join/leave message; b. it may result in join/leave flooding attack. 2. Capability Control Messages Query Req/Resp (including FE, LFB Topology Query) Capability Req/Resp [Weiming] I don't see the difference between the two. Configuration Req/Resp [Weiming] I'm not sure the contents for the message. Can you show how an FE attribute can be operated via this message? And do you treat an FE attribute or a LFB attribute is also as capability? And moreover, we also need to discuss how a LFB attribute is described here. This issue is also related to which addressing format we are going to use. 3. Control Packet or Traffic Maintenance Messages CP Redirect to CE CP Forward to FE 4. Event Notification Messages Event Register/De-register Req/Resp [Weiming] We can use an FE attribute to describe such reg./de-reg. operation. [/Weiming] Asynchronous FE Event (including DoS events) 5. Management Object or SNMP support Messages MO Get/Set MO Response 6. State Maintenance Messages (or HA related messages) PE Up/Down PE Active/InActive (equivalent to the "Move" command that Jamal described) [Weiming] Seems PE includes FE and CE. I'm not sure if our protocol should take care of CE state or not? [/Weiming] HeartBeat or Keep-alive [Weiming] I strongly suggest not to explicitly define heartbeat as protocol messages, which may have a strong incline protocol users MUST use it. 7. Vendor Specific messages (Optional ?) VS Request VS Response [Weiming] We need to discuss more on how Vendor Support is implemented. ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 12:29:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02928 for ; Thu, 15 Apr 2004 12:29:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9hv-0003gi-AY for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGRJYR014151 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:27:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9Kf-00044J-Qg for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:03:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01953 for ; Thu, 15 Apr 2004 12:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Ke-0001W6-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9Jo-0001RO-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:02:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9JC-0001Ml-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE96t-00015A-Oz; Thu, 15 Apr 2004 11:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8zJ-0006fA-P9 for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 11:41:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01193 for ; Thu, 15 Apr 2004 11:41:10 -0400 (EDT) From: wmwang@mail.hzic.edu.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8zI-0007PE-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8yT-0007Lh-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:40:21 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BE8y3-0007H6-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 11:39:56 -0400 Received: from localhost (unverified [127.0.0.1]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 15 Apr 2004 23:52:04 +0800 Received: from 219.82.167.195 ( [219.82.167.195]) as user wmwang@localhost by mail.hzic.edu.cn with HTTP; Thu, 15 Apr 2004 23:52:04 +0800 Message-ID: <1082044324.407eafa55053c@mail.hzic.edu.cn> To: forces-protocol@ietf.org Cc: wmwang@mail.hzic.edu.cn Subject: Re: [Forces-protocol] Protocol Messages References: <468F3FDA28AA87429AD807992E22D07E8B2D6B@orsmsx408.jf.intel.com> <1081965229.1026.250.camel@jzny.localdomain> In-Reply-To: <1081965229.1026.250.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Content-Transfer-Encoding: 8bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 23:52:04 +0800 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: 8bit Content-Transfer-Encoding: 8bit Hi Hormuzd, Jamal, and all, When I finished reply on the protocol messages, I realized that we may not start from this firstly, instead, we should start with the protocol common header at first, because the ideas between us are highly related to what protocol common header should be, e.g., whether the header contains the LFB ID or not. Therefore, I suggest to discuss the header first or at the same time with the message discussion. BR Weiming Quoting Jamal Hadi Salim : > On Fri, 2004-04-09 at 18:20, Khosravi, Hormuzd M wrote: > > Here is an initial list of protocol messages... > > (I have tried to merge messages from all 3 protocols without adding > > too many messages) > > We need to distinguish which is issued by PL and which by TML. > > > 1.Association Setup Messages > > Join Request/Response > > Leave Req/Resp > > This is TML as i see it. i.e the PL never sees these messages. > The TML MUST send events to the PL (to report the movement to a new peer > etc) > > > 2. Capability Control Messages > > Query Req/Resp (including FE, LFB Topology Query) > > Terminates at TML. > > > Capability Req/Resp > > Both TL and PML play a role. > > The way i would see this is PL-TML interface will > have the PL register its capabalities, then TML will > advertise the capability. > It should also be able to issue these messages as > > > Configuration Req/Resp > > The real meat. > TML "routes it" to the PL based on PID. > > > 3. Control Packet or Traffic Maintenance Messages > > CP Redirect to CE > > CP Forward to FE > > Would this be achieved by an LFB redirector at the FE->CE level? > > > 4. Event Notification Messages > > Event Register/De-register Req/Resp > > Asynchronous FE Event (including DoS events) > > We need to separate between events from TML->PL, > and PL<->PL > > > 5. Management Object or SNMP support Messages > > MO Get/Set > > MO Response > > Not sure i see this. Why are we mixing SNMP here? > > > 6. State Maintenance Messages (or HA related messages) > > PE Up/Down > > PE Active/InActive (equivalent to the "Move" command that Jamal > > described) > > Dont understand this part. Are these commands or events? > > > HeartBeat or Keep-alive > > Probably two/three types. One for PL<->PL heartbeats another TML<->TML > heartbeats and maybe TML<->PL > > > 7. Vendor Specific messages (Optional ?) > > VS Request > > VS Response > > I think we can have some codes that are "private" - the problem is these > values must be negotiated if we go that path. > > > Let me know what you guys think. Some of the terminology might be > > different but the semantics are quite similar in all the protocols. > > Good start but theres a lot of details to be ironed out. > I honestly wasnt thinking clearly after lunch while responding to these > messages, so i did not scrutinize your categories for message breakdown. > I will later on think about it and see if i can add more or generalize > some of them. > > cheers, > jamal > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > ------------------------------------------------- This mail sent through HUCNIC Webmail system. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 12:59:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04588 for ; Thu, 15 Apr 2004 12:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA4c-0003vc-KE for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGok8r015096 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9yR-0001PG-KK for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:44:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03812 for ; Thu, 15 Apr 2004 12:44:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9yQ-0005bL-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:44:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9xT-0005T9-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:43:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9wb-0005MI-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:42:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9jc-0005bM-92; Thu, 15 Apr 2004 12:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9YF-0007zC-JN for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 12:17:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02424 for ; Thu, 15 Apr 2004 12:17:15 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9YD-0002gb-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:17:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9XM-0002bO-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:16:25 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BE9Ws-0002XM-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:15:54 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FGFSO07514; Thu, 15 Apr 2004 19:15:28 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 19:15:25 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3FGFPYa028508; Thu, 15 Apr 2004 19:15:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00AYJECA; Thu, 15 Apr 2004 19:15:24 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FGFLs20276; Thu, 15 Apr 2004 19:15:22 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:15:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Protocol Messages Message-ID: Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQiTxSWmJkoSJ7gRT+inXfuod8VbAAtLCrA To: , Cc: , X-OriginalArrivalTime: 15 Apr 2004 16:15:04.0521 (UTC) FILETIME=[CFBB3390:01C42304] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 12:15:04 -0400 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, Comments/clarification are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > Hadi Salim > Sent: Wednesday, April 14, 2004 1:54 PM > To: Khosravi, Hormuzd M > Cc: forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn > Subject: Re: [Forces-protocol] Protocol Messages >=20 >=20 > On Fri, 2004-04-09 at 18:20, Khosravi, Hormuzd M wrote: > > Here is an initial list of protocol messages... > > (I have tried to merge messages from all 3 protocols without adding > > too many messages) >=20 > We need to distinguish which is issued by PL and which by TML. >=20 > > 1.Association Setup Messages > > Join Request/Response > > Leave Req/Resp >=20 > This is TML as i see it. i.e the PL never sees these messages. > The TML MUST send events to the PL (to report the movement to=20 > a new peer > etc) Not exactly, if you really see only PL only tells the TML where to which = endpoint it has associate.=20 >=20 > > 2. Capability Control Messages > > Query Req/Resp (including FE, LFB Topology Query) >=20 > Terminates at TML Not sure - please elborate. =20 > > Capability Req/Resp >=20 > Both TL and PML play a role. >=20 > The way i would see this is PL-TML interface will > have the PL register its capabalities, then TML will > advertise the capability. > It should also be able to issue these messages as=20 >=20 > > Configuration Req/Resp >=20 > The real meat. > TML "routes it" to the PL based on PID. I think we may have to spell out clearly here. > =20 > > 3. Control Packet or Traffic Maintenance Messages > > CP Redirect to CE > > CP Forward to FE >=20 > Would this be achieved by an LFB redirector at the FE->CE level? >=20 This is different from that. It is between CE and FE endpoints. > > 4. Event Notification Messages > > Event Register/De-register Req/Resp > > Asynchronous FE Event (including DoS events) >=20 > We need to separate between events from TML->PL, > and PL<->PL Agree. > =20 > > 5. Management Object or SNMP support Messages > > MO Get/Set > > MO Response >=20 > Not sure i see this. Why are we mixing SNMP here? Same question?=20 >=20 > > 6. State Maintenance Messages (or HA related messages) > > PE Up/Down > > PE Active/InActive (equivalent to the "Move" command that Jamal > > described) >=20 > Dont understand this part. Are these commands or events? These are events. =20 > > HeartBeat or Keep-alive >=20 > Probably two/three types. One for PL<->PL heartbeats another TML<->TML > heartbeats and maybe TML<->PL But if you consider PL-PL Heartbeat that includes TML to TML also. Why = do we need seperate TML to TML. >=20 > > 7. Vendor Specific messages (Optional ?) > > VS Request > > VS Response >=20 > I think we can have some codes that are "private" - the=20 > problem is these > values must be negotiated if we go that path. Yes. This is a practice that's done in other protocols. =20 >=20 > > Let me know what you guys think. Some of the terminology might be > > different but the semantics are quite similar in all the protocols. Yes. >=20 > Good start but theres a lot of details to be ironed out. > I honestly wasnt thinking clearly after lunch while=20 > responding to these > messages, so i did not scrutinize your categories for message=20 > breakdown. To generalise almost all the messages are request and respone and some = may be synchornous. For events they are asynhorons messages. We need to add section how to = deal with different=20 errors and also the implication on the PL and TML layer. Regards Ramg > I will later on think about it and see if i can add more or generalize > some of them. >=20 > cheers, > jamal=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 13:46:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04590 for ; Thu, 15 Apr 2004 12:59:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA4f-0003xY-35 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGonoC015214 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 12:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9zL-0001xU-QD for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 12:45:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03885 for ; Thu, 15 Apr 2004 12:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9zK-0005jC-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:45:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9yX-0005cY-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:44:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE9xe-0005Un-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 12:43:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9je-0005fA-2i; Thu, 15 Apr 2004 12:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9bz-0000Eh-RG for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 12:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02588 for ; Thu, 15 Apr 2004 12:21:08 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9by-00034i-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:21:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9az-0002u8-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:20:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BE9a1-0002mP-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 12:19:09 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FGJ3k14132; Thu, 15 Apr 2004 19:19:03 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 19:19:00 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3FGJ0JE002479; Thu, 15 Apr 2004 19:19:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00DiSUqp; Thu, 15 Apr 2004 19:19:00 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3FG7Ds14199; Thu, 15 Apr 2004 19:07:13 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 11:07:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Protocol Messages Message-ID: Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQjAyuP1/70HU5nSpSPWoU9DRKomgAAC7og To: , X-OriginalArrivalTime: 15 Apr 2004 16:07:02.0535 (UTC) FILETIME=[B071F970:01C42303] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 12:07:01 -0400 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Weiming, IMHO, we need to know what are different types of information that are = going to be exchanged between FE and CE endpoints and depending upon = that it will become easiler to consolidate what goes in common header = and what goes next level headers. =20 Regards Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext > wmwang@mail.hzic.edu.cn > Sent: Thursday, April 15, 2004 11:52 AM > To: forces-protocol@ietf.org > Cc: wmwang@mail.hzic.edu.cn > Subject: Re: [Forces-protocol] Protocol Messages >=20 >=20 > Hi Hormuzd, Jamal, and all, >=20 > When I finished reply on the protocol messages, I realized=20 > that we may not=20 > start from this firstly, instead, we should start with the=20 > protocol common=20 > header at first, because the ideas between us are highly=20 > related to what=20 > protocol common header should be, e.g., whether the header=20 > contains the LFB ID=20 > or not. >=20 > Therefore, I suggest to discuss the header first or at the=20 > same time with the=20 > message discussion.=20 >=20 > BR > Weiming >=20 > Quoting Jamal Hadi Salim : >=20 > > On Fri, 2004-04-09 at 18:20, Khosravi, Hormuzd M wrote: > > > Here is an initial list of protocol messages... > > > (I have tried to merge messages from all 3 protocols=20 > without adding > > > too many messages) > >=20 > > We need to distinguish which is issued by PL and which by TML. > >=20 > > > 1.Association Setup Messages > > > Join Request/Response > > > Leave Req/Resp > >=20 > > This is TML as i see it. i.e the PL never sees these messages. > > The TML MUST send events to the PL (to report the movement=20 > to a new peer > > etc) > >=20 > > > 2. Capability Control Messages > > > Query Req/Resp (including FE, LFB Topology Query) > >=20 > > Terminates at TML. > >=20 > > > Capability Req/Resp > >=20 > > Both TL and PML play a role. > >=20 > > The way i would see this is PL-TML interface will > > have the PL register its capabalities, then TML will > > advertise the capability. > > It should also be able to issue these messages as=20 > >=20 > > > Configuration Req/Resp > >=20 > > The real meat. > > TML "routes it" to the PL based on PID. > > =20 > > > 3. Control Packet or Traffic Maintenance Messages > > > CP Redirect to CE > > > CP Forward to FE > >=20 > > Would this be achieved by an LFB redirector at the FE->CE level? > >=20 > > > 4. Event Notification Messages > > > Event Register/De-register Req/Resp > > > Asynchronous FE Event (including DoS events) > >=20 > > We need to separate between events from TML->PL, > > and PL<->PL > > =20 > > > 5. Management Object or SNMP support Messages > > > MO Get/Set > > > MO Response > >=20 > > Not sure i see this. Why are we mixing SNMP here? > >=20 > > > 6. State Maintenance Messages (or HA related messages) > > > PE Up/Down > > > PE Active/InActive (equivalent to the "Move" command that Jamal > > > described) > >=20 > > Dont understand this part. Are these commands or events? > >=20 > > > HeartBeat or Keep-alive > >=20 > > Probably two/three types. One for PL<->PL heartbeats=20 > another TML<->TML > > heartbeats and maybe TML<->PL > >=20 > > > 7. Vendor Specific messages (Optional ?) > > > VS Request > > > VS Response > >=20 > > I think we can have some codes that are "private" - the=20 > problem is these > > values must be negotiated if we go that path. > >=20 > > > Let me know what you guys think. Some of the terminology might be > > > different but the semantics are quite similar in all the=20 > protocols. > >=20 > > Good start but theres a lot of details to be ironed out. > > I honestly wasnt thinking clearly after lunch while=20 > responding to these > > messages, so i did not scrutinize your categories for=20 > message breakdown. > > I will later on think about it and see if i can add more or=20 > generalize > > some of them. > >=20 > > cheers, > > jamal=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------- > This mail sent through HUCNIC Webmail system. >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 19:42:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10458 for ; Thu, 15 Apr 2004 19:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGTK-0008JO-Ss for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 19:40:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNegd0031946 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 19:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGJk-00064R-2p for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 19:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09825 for ; Thu, 15 Apr 2004 19:30: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 1BEGJi-0006Te-Cx for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 19:30:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEGIe-0006Px-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 19:29:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEGIB-0006Nw-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 19:29:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEG5S-0002Gb-1o; Thu, 15 Apr 2004 19:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFxJ-0008El-87 for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 19:07:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08202 for ; Thu, 15 Apr 2004 19:07: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 1BEFxF-0004ow-Qp for forces-protocol@ietf.org; Thu, 15 Apr 2004 19:07:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFwH-0004kA-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 19:06:34 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEFvK-0004dk-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 19:05:35 -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 i3FN4pXv012633 for ; Thu, 15 Apr 2004 23:04:52 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 i3FN3ElV022196 for ; Thu, 15 Apr 2004 23:04:12 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 M2004041516045227977 for ; Thu, 15 Apr 2004 16:04:52 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 16:04:52 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: FW: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EA37F24@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQiNlAxXHv2c1i9TuihnmcAA3BlTAA3g2ZgAApqSOA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 Apr 2004 23:04:52.0885 (UTC) FILETIME=[0F89CC50:01C4233E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 16:04:51 -0700 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 Content-Transfer-Encoding: quoted-printable Resending since I received an error. -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Thursday, April 15, 2004 11:20 AM To: 'hadi@znyx.com' Cc: 'wmwang@mail.hzic.edu.cn'; 'forces-protocol@ietf.org' Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Jamal, Thanks for your comments...my replies below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > True on introducing more complexities - not sure i agree on the > "unwanted" part. Maybe this is something that we need to decide on first > before moving forward. Do we wanna say it that Forces can work only on > the spefic TMLs?=20 >=20 > [HK] No we don't, but that doesn't mean we need to define and > standardize an API. Look at GSMP for example, it doesn't define an API > but can still function on multiple TMLs. Why cant we use a similar > approach ? Any particular GSMP RFCs/drafts?=20 [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is the TML approach, i.e. encapsulations defined for different interconnects. Do you see TMLs as something more than a layer to abstract interconnect details and provides certain services to the PL above ? > > The interfaces between the layers is completely implementation > > dependent.=20 >=20 > I think it may be beyond "implementation" specific now that we have > decided to go TMLs, no? I still would like our customers to use their > own TMLs as long as they provide "services" to the PL layer for the > items you mention: reliability, congestion control, security, HA etc. > Infact in their own private environment i would like to care less if > they present those services to the PL layer or not. Seems to me like > this would provide greater spread for Forces. >=20 > I believe we need to decide on this issue before moving forward. >=20 > [HK] Sure your customers can use their own TMLs, infact that is the > idea. But as you said, what is important are the services or > requirements for TMLs such as reliability, etc. >=20 Right, but exposing the abilities of the TML to meet the desires of the the PL needs an interface defined. [HK] In some cases, yes you need and interface...but there can be implementations which don't have a clean interface. I am not opposed to APIs or interfaces, infact we have them in our implementation...but I don't see the value of standardizing them or this team defining them. The reason for separating the PL and TML was 2 fold, 1. to allow fast progress on both in parallel, 2. to allow defining multiple TMLs for different interconnects. If we start defining interfaces, my fear is that we defeat the 1st reason. Also, unless you think that separate vendors will be implementing TMLs and PLs, there is no need to standardize the interface. Am I missing something here ? >=20 > [HK] Sure the layering will need an API in some implementations, but we > don't need to define those APIs. Lets leave this to the vendors who > implement the protocol. In any case, do you really think we can > standardize APIs in the IETF ? >=20 We need to define an interface that TMLs can attach to (or looked at from the other side PLs can attach to).=20 Whether its a protocol between TML and PL(TCP would be fine to me) or an API is not as important - the important piece is an agreement that such an interface is needed to begin with. I dont think the IETF is adverse to standardizing on some sane APIs when it is sensible; example: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt [HK] Sure, it makes sense in case of SCTP sockets...I really don't think its needed in our case....What do others think on this issue ?? I think its important to resolve this issue to move forward. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 22:03:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18981 for ; Thu, 15 Apr 2004 22:03:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIfT-00072y-EW for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 22:01:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G21N2p027083 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 22:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIe0-0006dj-3W for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 21:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18758 for ; Thu, 15 Apr 2004 21:59: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 1BEIdx-0000Mv-4K for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 21:59:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEIcw-0000Hr-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 21:58:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEIbx-0000CS-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 21:57:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIaH-0005k8-0x; Thu, 15 Apr 2004 21:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIZE-0005Lg-Rm for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 21:54:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18520 for ; Thu, 15 Apr 2004 21:54: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 1BEIZB-00000U-PK for forces-protocol@ietf.org; Thu, 15 Apr 2004 21:54:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEIYP-0007kW-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 21:54:06 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEIXm-0007bP-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 21:53:26 -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 i3G1XOl8004189; Fri, 16 Apr 2004 01:52:56 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 i3FIIA4P006220; Thu, 15 Apr 2004 18:19:40 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 M2004041511193923562 ; Thu, 15 Apr 2004 11:19:39 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 11:19:39 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07E9C089B@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQiNlAxXHv2c1i9TuihnmcAA3BlTAA3g2Zg From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 15 Apr 2004 18:19:39.0334 (UTC) FILETIME=[37112660:01C42316] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 11:19:38 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, Thanks for your comments...my replies below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > True on introducing more complexities - not sure i agree on the > "unwanted" part. Maybe this is something that we need to decide on first > before moving forward. Do we wanna say it that Forces can work only on > the spefic TMLs?=20 >=20 > [HK] No we don't, but that doesn't mean we need to define and > standardize an API. Look at GSMP for example, it doesn't define an API > but can still function on multiple TMLs. Why cant we use a similar > approach ? Any particular GSMP RFCs/drafts?=20 [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is the TML approach, i.e. encapsulations defined for different interconnects. Do you see TMLs as something more than a layer to abstract interconnect details and provides certain services to the PL above ? > > The interfaces between the layers is completely implementation > > dependent.=20 >=20 > I think it may be beyond "implementation" specific now that we have > decided to go TMLs, no? I still would like our customers to use their > own TMLs as long as they provide "services" to the PL layer for the > items you mention: reliability, congestion control, security, HA etc. > Infact in their own private environment i would like to care less if > they present those services to the PL layer or not. Seems to me like > this would provide greater spread for Forces. >=20 > I believe we need to decide on this issue before moving forward. >=20 > [HK] Sure your customers can use their own TMLs, infact that is the > idea. But as you said, what is important are the services or > requirements for TMLs such as reliability, etc. >=20 Right, but exposing the abilities of the TML to meet the desires of the the PL needs an interface defined. [HK] In some cases, yes you need and interface...but there can be implementations which don't have a clean interface. I am not opposed to APIs or interfaces, infact we have them in our implementation...but I don't see the value of standardizing them or this team defining them. The reason for separating the PL and TML was 2 fold, 1. to allow fast progress on both in parallel, 2. to allow defining multiple TMLs for different interconnects. If we start defining interfaces, my fear is that we defeat the 1st reason. Also, unless you think that separate vendors will be implementing TMLs and PLs, there is no need to standardize the interface. Am I missing something here ? >=20 > [HK] Sure the layering will need an API in some implementations, but we > don't need to define those APIs. Lets leave this to the vendors who > implement the protocol. In any case, do you really think we can > standardize APIs in the IETF ? >=20 We need to define an interface that TMLs can attach to (or looked at from the other side PLs can attach to).=20 Whether its a protocol between TML and PL(TCP would be fine to me) or an API is not as important - the important piece is an agreement that such an interface is needed to begin with. I dont think the IETF is adverse to standardizing on some sane APIs when it is sensible; example: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt [HK] Sure, it makes sense in case of SCTP sockets...I really don't think its needed in our case....What do others think on this issue ?? I think its important to resolve this issue to move forward. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 15 22:33:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20548 for ; Thu, 15 Apr 2004 22:33:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJ7I-0004sL-2i for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 22:30:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G2U8S9018736 for forces-protocol-archive@odin.ietf.org; Thu, 15 Apr 2004 22:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJ3S-0003zg-4r for forces-protocol-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 22:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20077 for ; Thu, 15 Apr 2004 22:26: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 1BEJ3O-0002Fb-U3 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 22:26:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJ2F-00027P-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 22:24:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEJ1P-00022r-00 for forces-protocol-web-archive@ietf.org; Thu, 15 Apr 2004 22:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIsg-0001YB-75; Thu, 15 Apr 2004 22:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEIoa-0000kK-Il for forces-protocol@optimus.ietf.org; Thu, 15 Apr 2004 22:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19334 for ; Thu, 15 Apr 2004 22:10: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 1BEIoX-0001Ae-B8 for forces-protocol@ietf.org; Thu, 15 Apr 2004 22:10:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEIng-000188-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 22:09:52 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEIn2-000140-00 for forces-protocol@ietf.org; Thu, 15 Apr 2004 22:09:12 -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 i3G28dXv006476; Fri, 16 Apr 2004 02:08:39 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 i3G28g3F021791; Fri, 16 Apr 2004 02:08:42 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 M2004041519084028745 ; Thu, 15 Apr 2004 19:08:40 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 19:08:40 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages Message-ID: <468F3FDA28AA87429AD807992E22D07EA38062@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQjAvmG/H9Bsq0XQXG1Mp9Wh7SziQAVIC1w From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 16 Apr 2004 02:08:40.0589 (UTC) FILETIME=[BC8FE3D0:01C42357] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 15 Apr 2004 19:08:40 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, I am fine with having discussion on common header in parallel with protocol messages. I think we resolved most of it except the LFB Type ID. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn Hi Hormuzd, Jamal, and all, When I finished reply on the protocol messages, I realized that we may not=20 start from this firstly, instead, we should start with the protocol common=20 header at first, because the ideas between us are highly related to what protocol common header should be, e.g., whether the header contains the LFB ID=20 or not. Therefore, I suggest to discuss the header first or at the same time with the=20 message discussion.=20 BR Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 03:51:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20709 for ; Fri, 16 Apr 2004 03:51:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEO2a-0006cS-EO for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 03:45:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G7ja70025440 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 03:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENtJ-000303-A0 for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19737 for ; Fri, 16 Apr 2004 03:35:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENtH-0004uK-1U for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 03:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENsK-0004pF-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 03:35:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENrs-0004kJ-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 03:34:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENke-00013z-IA; Fri, 16 Apr 2004 03:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENg1-0008Pe-Rf for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 03:22:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18811 for ; Fri, 16 Apr 2004 03:22:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENfz-0003KU-BQ for forces-protocol@ietf.org; Fri, 16 Apr 2004 03:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENfC-0003DT-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 03:21:26 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BENeJ-00032A-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 03:20:31 -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 i3G7JxmZ018970; Fri, 16 Apr 2004 07:19:59 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 i3G7Jxk4020064; Fri, 16 Apr 2004 07:20:02 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 M2004041600200003039 ; Fri, 16 Apr 2004 00:20:00 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 00:20:00 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages Message-ID: <468F3FDA28AA87429AD807992E22D07EA380D4@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQjAox7eROtol/fT0aVr1zyYxR6cAAfc2wg From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 16 Apr 2004 07:20:00.0234 (UTC) FILETIME=[3A7F84A0:01C42383] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 00:19:59 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of wmwang@mail.hzic.edu.cn To be hornest, I think we have some different ideas on how protocol messages=20 are arranged. The difference mainly lies in how detailedly we should categorize=20 the messages. I more tend to categorize the messages in more details, seems=20 Jamal likes less messages and Hormuzd is in the middle. Therefore, I kindly=20 suggest that we all propose our original thoughts first, then we work together=20 to summarize them. In this way, I think we may be not easy to leave behind=20 something but easy to see if the final conclusion include everything. By discussion, we can also exclude things that we don't need.=20 I'l first propose my idea (Hormuzd, pls believe I'm not pushing it, just for=20 easy discussion) and then try to understand Hormuzd's proposal.=20 [HK] I don't really care at this point how the messages are categorized, that's just a detail to me. What really intrigues me is some of your comments below regarding the messages that I proposed. Most of the messages are the same that you have proposed below, with slightly different names. So I am a bit confused about your intent. Anyways, as regards your proposal, I do think there might be too many messages as you have stated. I personally prefer the middle ground and I think that's prudent design for a base protocol. Having said that, I will send another email, rearranging the categories as you like them and may be adding some text to make it clear to you that we are essentially talking about the same thing/message. Regards=20 Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 05:30:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25620 for ; Fri, 16 Apr 2004 05:30:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPc6-0008Fd-VY for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 05:26:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G9QMcd031711 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 05:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPXs-0007bz-VD for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 05:22:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25412 for ; Fri, 16 Apr 2004 05:21:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPXp-0000V1-Nh for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 05:21:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPWu-0000PC-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 05:21:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEPWG-0000K8-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 05:20:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPRB-0006RM-2D; Fri, 16 Apr 2004 05:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPOB-0005le-Ju for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 05:11:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24932 for ; Fri, 16 Apr 2004 05:11:56 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPO8-0007DO-5Y for forces-protocol@ietf.org; Fri, 16 Apr 2004 05:11:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPNH-00077s-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 05:11:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BEPMP-00071U-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 05:10:09 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G9A3k07907; Fri, 16 Apr 2004 12:10:03 +0300 (EET DST) X-Scanned: Fri, 16 Apr 2004 12:09:45 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3G99jbO014769; Fri, 16 Apr 2004 12:09:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00j1iSyA; Fri, 16 Apr 2004 12:09:34 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3G990s02000; Fri, 16 Apr 2004 12:09:05 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Apr 2004 04:08:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQiNlAxXHv2c1i9TuihnmcAA3BlTAA3g2ZgAApqSOAAE89bIA== To: , , X-OriginalArrivalTime: 16 Apr 2004 09:08:53.0984 (UTC) FILETIME=[70EAA600:01C42392] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 05:08:50 -0400 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Thursday, April 15, 2004 7:05 PM > To: forces-protocol@ietf.org > Subject: FW: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA >=20 >=20 > Resending since I received an error. >=20 > -----Original Message----- > From: Khosravi, Hormuzd M=20 > Sent: Thursday, April 15, 2004 11:20 AM > To: 'hadi@znyx.com' > Cc: 'wmwang@mail.hzic.edu.cn'; 'forces-protocol@ietf.org' > Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA >=20 >=20 > Jamal, >=20 > Thanks for your comments...my replies below. > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > > True on introducing more complexities - not sure i agree on the > > "unwanted" part. Maybe this is something that we need to decide on > first > > before moving forward. Do we wanna say it that Forces can=20 > work only on > > the spefic TMLs?=20 > >=20 > > [HK] No we don't, but that doesn't mean we need to define and > > standardize an API. Look at GSMP for example, it doesn't=20 > define an API > > but can still function on multiple TMLs. Why cant we use a similar > > approach ? >=20 > Any particular GSMP RFCs/drafts?=20 > [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is > the TML approach, i.e. encapsulations defined for different > interconnects. Do you see TMLs as something more than a layer to > abstract interconnect details and provides certain services to the PL > above ? Sounds like a good approach to me. We can reuse those mechanism in = specifying the=20 TML requrirements. =20 >=20 > > > The interfaces between the layers is completely implementation > > > dependent.=20 > >=20 > > I think it may be beyond "implementation" specific now that we have > > decided to go TMLs, no? I still would like our customers to=20 > use their > > own TMLs as long as they provide "services" to the PL layer for the > > items you mention: reliability, congestion control,=20 > security, HA etc. > > Infact in their own private environment i would like to care less if > > they present those services to the PL layer or not. Seems to me like > > this would provide greater spread for Forces. > >=20 > > I believe we need to decide on this issue before moving forward. > >=20 > > [HK] Sure your customers can use their own TMLs, infact that is the > > idea. But as you said, what is important are the services or > > requirements for TMLs such as reliability, etc. > >=20 =20 > Right, but exposing the abilities of the TML to meet the=20 > desires of the > the PL needs an interface defined. >=20 > [HK] In some cases, yes you need and interface...but there can be > implementations which don't have a clean interface. I am not=20 > opposed to > APIs or interfaces, infact we have them in our implementation...but I > don't see the value of standardizing them or this team defining them. > The reason for separating the PL and TML was 2 fold, 1. to allow fast > progress on both in parallel, 2. to allow defining multiple TMLs for > different interconnects. If we start defining interfaces, my fear is > that we defeat the 1st reason. Also, unless you think that separate > vendors will be implementing TMLs and PLs, there is no need to > standardize the interface. Am I missing something here ? >=20 Instead of defining the TML layer API if we specify the required = functioanlity what is expected=20 from PL that's a good starting point. Defining API's may make sense if = more there are many potential applciations going to use the TML directly, current ForCES PL is the one = which has this requiements. One clarification ... because its confsuing from the emails... =20 If we are going to define the API for TML layer(top half), then ForCES = message structure what we have=20 been discussing becomes the part of the TML layer (bottom half). Then = ForceS PL layer (bottom half)becomes implementation specific all it has to do is invoke those TML (top half) API's. Then it = becomes the repsonsibility of the TML bottom half to transform those API data strcuture into the ForCES message format... = =20 =20 > >=20 > > [HK] Sure the layering will need an API in some implementations, but > we > > don't need to define those APIs. Lets leave this to the vendors who > > implement the protocol. In any case, do you really think we can > > standardize APIs in the IETF ? > >=20 This if just background information not required for this discussion - = we have socket API's draft from IETF and If I remember correctly IETF = has specified API's as part or along with FTP protocol other than that i = don't know any thing out of=20 my memory. But socket API is different when compared to TML and PL interface. For = TCP and SCTP mutiple types of applications needs=20 to interact. Where as in our case for TML only PL is the current = application. =20 =20 May be in the appendix or some other document we can provide examples of = common adaptation case. =20 > We need to define an interface that TMLs can attach to (or looked at > from the other side PLs can attach to).=20 > Whether its a protocol between TML and PL(TCP would be fine=20 > to me) or an > API is not as important - the important piece is an agreement=20 > that such > an interface is needed to begin with. > I dont think the IETF is adverse to standardizing on some sane APIs > when it is sensible; example: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt >=20 > [HK] Sure, it makes sense in case of SCTP sockets...I really=20 > don't think > its needed in our case....What do others think on this issue ?? >=20 > I think its important to resolve this issue to move forward. As mentioned earlier.. SCTP and TCP has wide application usage, there is clealy companies = involved in providing stack and companies involved in developing applications.=20 Where as in TML and PL case, the requirements are ForCES specifics, no = applications other than ForCES have=20 such requirements. IMHO, if we specify only the requirements and leave = the adaptation (implemenation open) will be a good idea.=20 Let us take a simple example of IP itself it can run over "Foo" , The = foo can be any layer but it is the responsiblity of the Foo to define = the adaptaion of IP and it is not in the scope of IP. =20 If this is ok, to move forward we can first define the TML requirments. = If there is a strong emphasis then we should consider for API. But IMHO = the API may not be needed. Regards Ramg >=20 > Regards > Hormuzd >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 11:20:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15649 for ; Fri, 16 Apr 2004 11:20:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUzd-0003sT-JE for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 11:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFB1hf014898 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 11:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUw2-0002f3-6c for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 11:07:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14734 for ; Fri, 16 Apr 2004 11:07:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEUvz-0003f5-Fa for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:07:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUv5-0003cU-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:06:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEUuN-0003Z1-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:05:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUm9-0006bN-ES; Fri, 16 Apr 2004 10:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUeW-00043l-Pf for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 10:49:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13629 for ; Fri, 16 Apr 2004 10:49: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 1BEUeU-0002Ru-AN for forces-protocol@ietf.org; Fri, 16 Apr 2004 10:49:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUdZ-0002Po-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 10:48:14 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BEUd3-0002NT-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 10:47:42 -0400 Received: from wwm1 (unverified [219.82.162.151]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 16 Apr 2004 22:59:51 +0800 Message-ID: <008e01c423c1$43181ad0$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07EA380D4@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Protocol Messages X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 22:44:01 +0800 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 Hi Hormuzd, [HK] I don't really care at this point how the messages are categorized, that's just a detail to me. What really intrigues me is some of your comments below regarding the messages that I proposed. Most of the messages are the same that you have proposed below, with slightly different names. So I am a bit confused about your intent. [Weiming] I don't think we only have differences in the names for many messages. My comments on your proposal actually have pointed out the differences between us and also the points where I can not quite understand. Maybe your followed clarification on some of the messages can help much. The intent for my comments is just to try to better understand what you said and to point out the difference between us. I'm not sure if there is any misunderstanding on it. Please believe that I also agree your proposal is a good start for the work, but as Jamal said we just need to iron out more. [/Weiming] Anyways, as regards your proposal, I do think there might be too many messages as you have stated. I personally prefer the middle ground and I think that's prudent design for a base protocol. [Weiming] It's a very interesting issue to arrange more or less message types. To have more message types is actually to let the 'Message Type' in the header function more and let TLV simpler. On contrary, to use less message types is actually to let tags in TLV do the subcategory work. I prefer to use more messages because I think it may be better to make full use of the message type field in the header and to have clear protocol messages for users. [/Weiming] Having said that, I will send another email, rearranging the categories as you like them and may be adding some text to make it clear to you that we are essentially talking about the same thing/message. [Weiming] That will be helpful for us to get more muture understanding. Actually I also suggest, if convenient, Jamal also presents a list of messages with some explanations. In this way, I think we can understand each other more on what the protocol should basically deal with. It will also be helpful for other issue discussions such as on how we deal with PL<->TML and HA. I'm sure after specification of TML is separated from the PL, our main work is on the protocol messages, and the discussion results will be reflected via the protocol messages in the end . BR Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 11:51:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17240 for ; Fri, 16 Apr 2004 11:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVTU-0002r2-Dc for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 11:41:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFfqoF010967 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 11:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVK6-0000I9-IS for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 11:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16388 for ; Fri, 16 Apr 2004 11:32: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 1BEVK5-0005H3-JT for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:32:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVJA-0005DI-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:31:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEVIG-0005AH-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 11:30:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVAH-0006o8-Fb; Fri, 16 Apr 2004 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEV0p-0004Ck-TD for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 11:12:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14981 for ; Fri, 16 Apr 2004 11:12:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEV0p-0003yp-1e for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:12:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUzt-0003uC-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:11:17 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BEUzB-0003qv-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:10:33 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041608140176:624 ; Fri, 16 Apr 2004 08:14:01 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, ram.gopal@nokia.com In-Reply-To: <468F3FDA28AA87429AD807992E22D07E9C089B@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E9C089B@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1082128218.1026.26.camel@jzny.localdomain> 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 04/16/2004 08:14:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/16/2004 08:14:05 AM, Serialize complete at 04/16/2004 08:14:05 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Apr 2004 11:10:18 -0400 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 Content-Transfer-Encoding: 7bit On Thu, 2004-04-15 at 14:19, Khosravi, Hormuzd M wrote: > Jamal, > > Thanks for your comments...my replies below. > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > True on introducing more complexities - not sure i agree on the > > "unwanted" part. Maybe this is something that we need to decide on > first > > before moving forward. Do we wanna say it that Forces can work only on > > the spefic TMLs? > > > > [HK] No we don't, but that doesn't mean we need to define and > > standardize an API. Look at GSMP for example, it doesn't define an API > > but can still function on multiple TMLs. Why cant we use a similar > > approach ? > > Any particular GSMP RFCs/drafts? > [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is > the TML approach, i.e. encapsulations defined for different > interconnects. Thanks; i just printed them to study them later. > Do you see TMLs as something more than a layer to > abstract interconnect details and provides certain services to the PL > above ? The hard part is the "services" aspect. Transport services includes but not specific to: - reliability vs no reliability - priority - congestion control - encoding of messages - security - Link mngmnt, HA - peripheral things like "obsolete msg x if you are still trying to retransmit it" Somehow the PL should be able to tell the TML on how to conduct certain behaviors. > [HK] In some cases, yes you need and interface...but there can be > implementations which don't have a clean interface. I am not opposed to > APIs or interfaces, infact we have them in our implementation...but I > don't see the value of standardizing them or this team defining them. Think of just simple things like: open(), close(), read(), write(), event(), ioctl(); maybe we are taking them for granted for sockets because they are already well known. Somehow if you replace that socket with a TML layer, it doesnt mean they dissapear. I am not insisting on a API; this could be a very simple protocol that runs over TCP which provides those interfaces. The advantage with a protocol is that you can have the PL running on a different machine (and proxies become easy to do). > The reason for separating the PL and TML was 2 fold, 1. to allow fast > progress on both in parallel, 2. to allow defining multiple TMLs for > different interconnects. If we start defining interfaces, my fear is > that we defeat the 1st reason. Also, unless you think that separate > vendors will be implementing TMLs and PLs, there is no need to > standardize the interface. Am I missing something here ? I think theres possibilities that there will be other people who will write only the TML (TIPC being an example). If TIPC adhered to some interface then i should be able to "plug" into my implementation using a binary from Jon. I do understand defining such an API/protocol is making things more complex, i just dont want to look the other way just because of such a reason. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 12:26:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19388 for ; Fri, 16 Apr 2004 12:26:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEW7Q-0005oX-H0 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 12:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGN88L022340 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 12:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVnI-00088a-2T for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 12:02:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17985 for ; Fri, 16 Apr 2004 12:02:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEVnG-0007LW-QF for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 12:02:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVmK-0007Hm-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 12:01:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEVm7-0007Et-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 12:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVdJ-0005Nk-Vb; Fri, 16 Apr 2004 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVU2-00034H-Eq for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 11:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16819 for ; Fri, 16 Apr 2004 11:42:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEVU1-0005yM-Be for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:42:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVSz-0005ux-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:41:21 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BEVSW-0005rM-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 11:40:52 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041608442024:660 ; Fri, 16 Apr 2004 08:44:20 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: hormuzd.m.khosravi@intel.com, forces-protocol@ietf.org, Weiming Wang In-Reply-To: References: Organization: Znyx Networks Message-Id: <1082130045.1024.58.camel@jzny.localdomain> 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 04/16/2004 08:44:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/16/2004 08:44:24 AM, Serialize complete at 04/16/2004 08:44:24 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Apr 2004 11:40:45 -0400 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-16 at 05:08, ram.gopal@nokia.com wrote: > Instead of defining the TML layer API if we specify the required functioanlity what is expected > from PL that's a good starting point. Defining API's may make sense if more there are many potential > applciations going to use the TML directly, current ForCES PL is the one which has this requiements. Note, could be an API or protocol (Refer to my last email to Hormuzd on this). There could also be more than one PL using the same TML. I agree with you a good starting point is defining what services are to be provided by the TML to the PL. Clearly, the most important one is transport and all its aspects. Also clear that the PL should have a say in the degree on how those services are provided. Again, this is valuable if you are able to request at a per packet level. >From an API perspective (could easily be mapped to a simple protocol over TCP for example), i see: =>open(): connects a PL to a TML => close(): disengages PL from TML => read(): PL reading from TML => write(): PL writting to TML => event(): dont want to talk about poll/select() - TML notifying PL => ioctl(): PL controlling something within a TML (eg you could fit both a bind() and connect() like call here, also things like a "move" operation from PL->TML etc). > One clarification ... because its confsuing from the emails... > > If we are going to define the API for TML layer(top half), then ForCES message structure what we have > been discussing becomes the part of the TML layer (bottom half). Then ForceS PL layer (bottom half)becomes implementation > specific all it has to do is invoke those TML (top half) API's. Then it becomes the repsonsibility of the TML bottom half > to transform those API data strcuture into the ForCES message format... Yes, i think it becomes a blackbox how the TML does things. There may be some things where it may be more of grey than black box; example is what you mention above on encoding where the possibilities I see are: 1) raw mode: TML creates and fills all the headers 2) medium mode: PL creates the headers and partially fills some headers. TML adds the rest of the headers. 3) cooked mode: PL is responsible for headers [..] > > > As mentioned earlier.. > > SCTP and TCP has wide application usage, there is clealy companies > involved in providing stack and companies involved in > developing applications. > > Where as in TML and PL case, the requirements are ForCES specifics, no > applications other than ForCES have > such requirements. IMHO, if we specify only the requirements and leave > the adaptation (implemenation open) will be a good > idea. I think we need some minimal interface; however i havent looked at the GSMP RFCs maybe theres something clever there. True that this will add one more twist, but i am not sure how to avoid it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 17:06:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09974 for ; Fri, 16 Apr 2004 17:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaT3-0007vP-3Q for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL1jaO030452 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaQ6-0005k5-4R for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 16:58:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09123 for ; Fri, 16 Apr 2004 16:58:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaQ4-0000w3-0Z for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:58:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaP4-0000mK-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:57:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEaNV-0000ZA-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:56:01 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEaNW-00053k-H8 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaAz-00089T-7Y; Fri, 16 Apr 2004 16:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZeY-0000bT-Ui for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 16:09:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03577 for ; Fri, 16 Apr 2004 16:09: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 1BEZeX-0002ss-68 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:09:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZdU-0002id-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:08:29 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BEZc4-0002Up-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:07:00 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041613103023:1008 ; Fri, 16 Apr 2004 13:10:30 -0700 Subject: Re: [Forces-protocol] Protocol Messages From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org In-Reply-To: <008e01c423c1$43181ad0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EA380D4@orsmsx408.jf.intel.com> <008e01c423c1$43181ad0$020aa8c0@wwm1> Organization: Znyx Networks Message-Id: <1082146015.1024.131.camel@jzny.localdomain> 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 04/16/2004 01:10:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/16/2004 01:10:33 PM, Serialize complete at 04/16/2004 01:10:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Apr 2004 16:06:55 -0400 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 Content-Transfer-Encoding: 7bit Can we start with the header and where we left off? I am trying my best not to respond to any of the other messages because i think it is important to start with the header. Hormuzd or maybe it was Weiming i thought in the early days had capturd these details. If not i can compile. cheers, jamal On Fri, 2004-04-16 at 10:44, Weiming Wang wrote: > Hi Hormuzd, > > [HK] I don't really care at this point how the messages are categorized, > that's just a detail to me. What really intrigues me is some of your > comments below regarding the messages that I proposed. Most of the > messages are the same that you have proposed below, with slightly > different names. So I am a bit confused about your intent. > > [Weiming] I don't think we only have differences in the names for many > messages. My comments on your proposal actually have pointed out the differences > between us and also the points where I can not quite understand. Maybe your > followed clarification on some of the messages can help much. The intent for my > comments is just to try to better understand what you said and to point out the > difference between us. I'm not sure if there is any misunderstanding on it. > Please believe that I also agree your proposal is a good start for the work, but > as Jamal said we just need to iron out more. [/Weiming] > > Anyways, as regards your proposal, I do think there might be too many > messages as you have stated. I personally prefer the middle ground and I > think that's prudent design for a base protocol. > > [Weiming] It's a very interesting issue to arrange more or less message types. > To have more message types is actually to let the 'Message Type' in the header > function more and let TLV simpler. On contrary, to use less message types is > actually to let tags in TLV do the subcategory work. I prefer to use more > messages because I think it may be better to make full use of the message type > field in the header and to have clear protocol messages for users. [/Weiming] > > Having said that, I > will send another email, rearranging the categories as you like them and > may be adding some text to make it clear to you that we are essentially > talking about the same thing/message. > > [Weiming] That will be helpful for us to get more muture understanding. Actually > I also suggest, if convenient, Jamal also presents a list of messages with some > explanations. In this way, I think we can understand each other more on what > the protocol should basically deal with. It will also be helpful for other issue > discussions such as on how we deal with PL<->TML and HA. I'm sure after > specification of TML is separated from the PL, our main work is on the protocol > messages, and the discussion results will be reflected via the protocol messages > in the end . > > BR > Weiming > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 17:07:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10038 for ; Fri, 16 Apr 2004 17:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaT5-0007xG-Oa for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL1ldX030574 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaQp-0006Rf-8q for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 16:59:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09229 for ; Fri, 16 Apr 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 1BEaQn-00010i-5f for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:59:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaPn-0000td-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:58:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEaOn-0000j8-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:57:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BEaOo-000554-Aj for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:57:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaE3-0001CX-Lv; Fri, 16 Apr 2004 16:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZqW-0007Hn-Ly for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 16:21:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04955 for ; Fri, 16 Apr 2004 16:21: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 1BEZqU-0004SG-O9 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:21:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZpR-0004Im-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:20:49 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEZoa-000461-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:19:56 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3GKJGbr017424; Fri, 16 Apr 2004 20:19:16 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 i3GKIJ2a016363; Fri, 16 Apr 2004 20:18:26 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 M2004041613190922979 ; Fri, 16 Apr 2004 13:19:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 13:19:09 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages Message-ID: <468F3FDA28AA87429AD807992E22D07EA385AE@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQj7mOqSRCP+xN/QAegTYDoFq6m6AAANmpQ From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 16 Apr 2004 20:19:09.0743 (UTC) FILETIME=[13607BF0:01C423F0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 13:19:09 -0700 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 Content-Transfer-Encoding: quoted-printable Here is the header summary that we had published... Issue# 0 IDs in the header:- There was a lot of discussion on this topic regarding the naming, semantics, length of these IDs. The result was as follows... Naming: CE ID, FE ID Semantics: Used to address a single, group or all CEs/FEs respectively Length: 16-32 bits...TBD Another issue we reached agreement on was using LFB Type ID, LFB Instance ID in combination of FE ID for addressing LFBs on the FE. The LFB Instance ID will be part of the payload. The LFB Type ID location, whether it is part of header or payload is TBD. Issue# 1 Header/Encoding:- Here are the fields in the common header that there was consensus around IDs: as summarized in issue 0 Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length of Flags and Priority fields is TBD) LFB TypeID: TBD, no consensus on whether it is needed or not in the header ------------- As you can see, there were very few TBDs, the main one was regarding LFB Type ID. I believe most folks agreed that we don't need it in the common header, but there were different views as well so we can have a discussion on this. I will also continue the discussion on Protocol messages, I think that's also important and will help clarify our direction further. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Can we start with the header and where we left off? I am trying my best not to respond to any of the other messages because i think it is important to start with the header. Hormuzd or maybe it was Weiming i thought in the early days had capturd these details. If not i can compile. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 17:07:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10162 for ; Fri, 16 Apr 2004 17:07:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaT5-0007xU-Qv for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL1ldk030587 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaQr-0006Rr-VC for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 16:59:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09232 for ; Fri, 16 Apr 2004 16:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaQp-000115-S7 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaPw-0000ua-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:58:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEaP1-0000lo-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:57:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaE5-0001GE-Cr; Fri, 16 Apr 2004 16:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZqj-0007IU-Qp for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 16:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04996 for ; Fri, 16 Apr 2004 16:22:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZqi-0004UO-1D for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:22:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZpj-0004LM-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:21:07 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BEZoo-0004Cl-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:20:10 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041613234079:1031 ; Fri, 16 Apr 2004 13:23:40 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, ram.gopal@nokia.com In-Reply-To: <1082128218.1026.26.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E9C089B@orsmsx408.jf.intel.com> <1082128218.1026.26.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1082146806.1028.152.camel@jzny.localdomain> 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 04/16/2004 01:23:41 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/16/2004 01:23:42 PM, Serialize complete at 04/16/2004 01:23:42 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Apr 2004 16:20:06 -0400 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-16 at 11:10, Jamal Hadi Salim wrote: > > Any particular GSMP RFCs/drafts? > > [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is > > the TML approach, i.e. encapsulations defined for different > > interconnects. > > Thanks; i just printed them to study them later. Hormuzd, I just looked at RFC 3293 and briefly at 3292 i cant see the relation to a TML. All 3293 does is encapsulate; none of the transport "services" are really delivered to the GSMP layer. Should i continue reading or is this pretty much covering it? ;-> cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 17:14:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10716 for ; Fri, 16 Apr 2004 17:14:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaXE-0000gk-Qh for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:06:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL64uD002642 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaSh-0007nh-Nr for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:01:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09479 for ; Fri, 16 Apr 2004 17:01: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 1BEaSf-0001Dv-LC for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 17:01:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaRh-00016F-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 17:00:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEaQp-000116-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 16:59:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaEn-0001VG-Ed; Fri, 16 Apr 2004 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZvU-0000aM-Iy for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 16:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05546 for ; Fri, 16 Apr 2004 16:27: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 1BEZvS-000568-Kh for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZuV-0004z6-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:26:03 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEZtj-0004pC-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:25:15 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3GKOlbr021095; Fri, 16 Apr 2004 20:24:47 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 i3GKNl2c019104; Fri, 16 Apr 2004 20:24:01 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 M2004041613244423674 ; Fri, 16 Apr 2004 13:24:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 13:24:44 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EA385C3@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQjxPnBvWl0nAsGQiO5oQiPVfHV6QAK0kow From: "Khosravi, Hormuzd M" To: Cc: , , X-OriginalArrivalTime: 16 Apr 2004 20:24:44.0997 (UTC) FILETIME=[DB342F50:01C423F0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 13:24:44 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, Let me know after you have read the GSMP RFCs. I think we both have very similar goals in mind but slightly different approaches to achieve it. As I said, I am not opposed to APIs or interfaces, I just don't think it needs to be standardized...at most we can have them as Implementation Notes in the Appendix if that is something everyone thinks would be valuable. Anyways I have said enough on this topic, I would like to hear from Weiming, Avri and others about their views on this topic... ? Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > The reason for separating the PL and TML was 2 fold, 1. to allow fast > progress on both in parallel, 2. to allow defining multiple TMLs for > different interconnects. If we start defining interfaces, my fear is > that we defeat the 1st reason. Also, unless you think that separate > vendors will be implementing TMLs and PLs, there is no need to > standardize the interface. Am I missing something here ? I think theres possibilities that there will be other people who will write only the TML (TIPC being an example). If TIPC adhered to some interface then i should be able to "plug" into my implementation using a binary from Jon. I do understand defining such an API/protocol is making things more complex, i just dont want to look the other way just because of such a reason. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 17:15:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10770 for ; Fri, 16 Apr 2004 17:15:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaaj-0001gX-7P for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:09:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GL9fRL006473 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 17:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaTJ-00083l-5a for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 17:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09576 for ; Fri, 16 Apr 2004 17:01:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEaTH-0001JZ-5E for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 17:01:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEaSD-0001BY-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 17:00:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEaRV-00015B-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 17:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaFv-00027R-T9; Fri, 16 Apr 2004 16:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEa14-000339-Jj for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 16:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06111 for ; Fri, 16 Apr 2004 16:32:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEa12-0005sw-Dt for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:32:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZzY-0005aq-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:31:17 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BEZxu-0005Gu-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 16:29:34 -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 i3GKT1EA019855; Fri, 16 Apr 2004 20:29:02 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 i3GKQv3U020982; Fri, 16 Apr 2004 20:28:18 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 M2004041613290224236 ; Fri, 16 Apr 2004 13:29:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 13:29:02 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQj8Eg6RNvBeq1USnyKrayAPVAFpwAAMG9w From: "Khosravi, Hormuzd M" To: Cc: , , X-OriginalArrivalTime: 16 Apr 2004 20:29:02.0348 (UTC) FILETIME=[7498D4C0:01C423F1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 16 Apr 2004 13:29:01 -0700 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 Content-Transfer-Encoding: quoted-printable I think you should continue reading this and try to understand their approach. (For example, in case of IP, TCP is used to deliver the transport service) They achieve the same goal using encapsulation headers, its very similar to what the TMLs are trying to achieve, Let me know what you think regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, April 16, 2004 1:20 PM To: Khosravi, Hormuzd M Cc: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org; ram.gopal@nokia.com Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA On Fri, 2004-04-16 at 11:10, Jamal Hadi Salim wrote: > > Any particular GSMP RFCs/drafts?=20 > > [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is > > the TML approach, i.e. encapsulations defined for different > > interconnects.=20 >=20 > Thanks; i just printed them to study them later. Hormuzd, I just looked at RFC 3293 and briefly at 3292 i cant see the relation to a TML.=20 All 3293 does is encapsulate; none of the transport "services" are really delivered to the GSMP layer. Should i continue reading or is this pretty much covering it? ;-> cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 16 21:51:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26627 for ; Fri, 16 Apr 2004 21:51:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEevH-0007u8-L9 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 21:47:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H1lBIu030378 for forces-protocol-archive@odin.ietf.org; Fri, 16 Apr 2004 21:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEeuv-0007VI-Ln for forces-protocol-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 21:46:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26467 for ; Fri, 16 Apr 2004 21:46: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 1BEeus-0003XR-T4 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 21:46:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEetq-0003Sx-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 21:45:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEetU-0003OX-00 for forces-protocol-web-archive@ietf.org; Fri, 16 Apr 2004 21:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEesD-0006Su-Aj; Fri, 16 Apr 2004 21:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEemr-0004ta-SY for forces-protocol@optimus.ietf.org; Fri, 16 Apr 2004 21:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26127 for ; Fri, 16 Apr 2004 21:38:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEemo-00031n-Ts for forces-protocol@ietf.org; Fri, 16 Apr 2004 21:38:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEelq-0002us-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 21:37:27 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BEejI-0002k5-00 for forces-protocol@ietf.org; Fri, 16 Apr 2004 21:36:27 -0400 Received: from wwm1 (unverified [219.82.184.156]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 17 Apr 2004 09:47:00 +0800 Message-ID: <013801c4241b$a9edd6f0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EA385C3@orsmsx408.jf.intel.com> Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 17 Apr 2004 09:31:07 +0800 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 Hi Jamal, I agree APIs are very useful for customers with their ForCES system design, especially I think they are good for CE side design, but I also feel it may be not the very time to standardize it currently in the ForCES protocol document. Maybe it can be considered as a specific Informational document later, just like others do. For those TML requirements you listed currently, I think we can just define FE attributes for TML policies (like TML reliability policy, TML link mang. policy, TML security policy, etc) and some metadata (such as for priority) to meet them. I think it's better currently to treat the TML as a blackbox, though some of the grey part in the box always looks so attractive. I also agree to start with the header discussion first. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Cc: ; ; Sent: Saturday, April 17, 2004 4:24 AM Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Jamal, Let me know after you have read the GSMP RFCs. I think we both have very similar goals in mind but slightly different approaches to achieve it. As I said, I am not opposed to APIs or interfaces, I just don't think it needs to be standardized...at most we can have them as Implementation Notes in the Appendix if that is something everyone thinks would be valuable. Anyways I have said enough on this topic, I would like to hear from Weiming, Avri and others about their views on this topic... ? Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] > The reason for separating the PL and TML was 2 fold, 1. to allow fast > progress on both in parallel, 2. to allow defining multiple TMLs for > different interconnects. If we start defining interfaces, my fear is > that we defeat the 1st reason. Also, unless you think that separate > vendors will be implementing TMLs and PLs, there is no need to > standardize the interface. Am I missing something here ? I think theres possibilities that there will be other people who will write only the TML (TIPC being an example). If TIPC adhered to some interface then i should be able to "plug" into my implementation using a binary from Jon. I do understand defining such an API/protocol is making things more complex, i just dont want to look the other way just because of such a reason. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Apr 17 22:52:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11134 for ; Sat, 17 Apr 2004 22:52:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2Lh-0001HD-13 for forces-protocol-archive@odin.ietf.org; Sat, 17 Apr 2004 22:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I2m04C004882 for forces-protocol-archive@odin.ietf.org; Sat, 17 Apr 2004 22:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1ub-000856-94 for forces-protocol-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 22:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08574 for ; Sat, 17 Apr 2004 22:19:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF1uY-0007EI-3P for forces-protocol-web-archive@ietf.org; Sat, 17 Apr 2004 22:19:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF1te-0006zQ-00 for forces-protocol-web-archive@ietf.org; Sat, 17 Apr 2004 22:19:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF1sj-0006kq-00 for forces-protocol-web-archive@ietf.org; Sat, 17 Apr 2004 22:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1o3-0005ST-SR; Sat, 17 Apr 2004 22:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEu03-0007xv-7m for forces-protocol@optimus.ietf.org; Sat, 17 Apr 2004 13:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20678 for ; Sat, 17 Apr 2004 13:53:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEu00-0003ty-Vl for forces-protocol@ietf.org; Sat, 17 Apr 2004 13:53:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEtz2-0003mC-00 for forces-protocol@ietf.org; Sat, 17 Apr 2004 13:52:05 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BEty4-0003dx-00 for forces-protocol@ietf.org; Sat, 17 Apr 2004 13:51:04 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041710543381:1781 ; Sat, 17 Apr 2004 10:54:33 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, ram.gopal@nokia.com In-Reply-To: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1082224260.1039.59.camel@jzny.localdomain> 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 04/17/2004 10:54:34 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/17/2004 10:54:36 AM, Serialize complete at 04/17/2004 10:54:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 17 Apr 2004 13:51:00 -0400 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 Content-Transfer-Encoding: 7bit On Fri, 2004-04-16 at 16:29, Khosravi, Hormuzd M wrote: > I think you should continue reading this and try to understand their > approach. > (For example, in case of IP, TCP is used to deliver the transport > service) > > They achieve the same goal using encapsulation headers, its very similar > to what the TMLs are trying to achieve, > > Let me know what you think I have read enough i think and i dont see a good relation (in my thinking at least). In our case there may be for example more than one socket in a TML which may be used for different reasons. What GSMP transport level does is simple encapsulation first. The fact that reliability exists for example may is secondary. Lets say you even said "this TML provides both reliable and unreliable unicast transport" then dont you think the PL at least needs to know how to use either one when it chooses to? On Fri, 2004-04-16 at 21:31, Weiming Wang wrote: > > I agree APIs are very useful for customers with their ForCES system design, > especially I think they are good for CE side design, but I also feel it may be > not the very time to standardize it currently in the ForCES protocol document. > Maybe it can be considered as a specific Informational document later, just > like others do. I am finding it very hard to say we can do multiple TMLs and not say how a Forces PL can use them. > For those TML requirements you listed currently, I think we can just define FE > attributes for TML policies (like TML reliability policy, TML link mang. policy, > TML security policy, etc) and some metadata (such as for priority) to meet > them. I think it's better currently to treat the TML as a blackbox, though > some of the grey part in the box always looks so attractive. I think if we can define it from an API level, it should be easy to translate into a protocol message. The way i see it so far the major major difference between all proposals has been how transportation should be handled. We agreed to the TML. There has to be a way to hook up to the TML, no? In other words this seems to be a fundamental requirement. I realize the complexities involved of having not just PL-PL but also PL-TML interface definition, but so far i see nothing convincing to say we can only have one interface. The way i see it, even if you just had one CE and one FE, theres possibility of three implementors: 1) the TML implementor. I think the same TML has to run on both CE and FE. 2) the FE PL implementor 3) the CE Pl implementor. Of course this is a worst case scenario, the simplest is one implementor for all three. Note to both Hormuzd and Weiming: I dont want to go this path if i can avoid it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 01:26:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04121 for ; Mon, 19 Apr 2004 01:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRGM-0006xB-PN for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 01:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J5OArv026723 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 01:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRFx-0006mX-6J for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 01:23:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04055 for ; Mon, 19 Apr 2004 01:23:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFRFu-00079y-5m for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 01:23:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFREw-0006wp-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 01:22:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFREh-0006ju-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 01:22:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRDJ-0006Pn-9R; Mon, 19 Apr 2004 01:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRC7-00063m-TD for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 01:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03919 for ; Mon, 19 Apr 2004 01:19: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 1BFRC4-0006Gm-Oz for forces-protocol@ietf.org; Mon, 19 Apr 2004 01:19:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFRB6-000637-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 01:18:45 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BFRAm-0005pY-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 01:18:24 -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 i3J5Hs8L002587 for ; Mon, 19 Apr 2004 05:17:54 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 i3J5GkL8010438 for ; Mon, 19 Apr 2004 05:16:59 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 M2004041822175120702 for ; Sun, 18 Apr 2004 22:17:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Apr 2004 22:17:52 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C425CD.A9B7C73C" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EA38A93@orsmsx408.jf.intel.com> Thread-Topic: List of issues for discussion Thread-Index: AcQlzakztd+JcwN/QDagKGG6CU0KmQ== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 19 Apr 2004 05:17:52.0191 (UTC) FILETIME=[A9E224F0:01C425CD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] List of issues for discussion Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 18 Apr 2004 22:17:51 -0700 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,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C425CD.A9B7C73C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All =20 Weiming started a private discussion with Jamal and myself over the weekend regarding renewing of protocol drafts and it has turned into a useful discussion of how to make some quick progress on the protocol. Both Jamal and myself are concerned that we have Not made good progress so far on this team. =20 Here is a list of issues to be discussed as suggested by Jamal. =20 0. Expected architecture/use cases: I believe this is important to remove the major stumbling issue - the different views of implementations. =20 i) What each of (PL and TML) does; we could steal from Davids url. =20 ii) scenario layouts of processing.=20 ii-I) joining and leaving; CEM/FEM role etc ii-II) Lets pick one or two simple examples (maybe just IPV4 forwarding with OSPF). =20 1. TML #0 above should help ease this. a) roles of TML vs PL. b) services provided by TML to PL i) what are they?=20 ii) should the services be controllable by the PL? iii) if yes, to what degree 2. HA 3. Capability Exchange, FEM/CEM 4.a. Protocol Messages 4.b. Protocol Scenarios 4.c. Common Header 5. Support for Vendor functions 6. Master-Slave or Peer-to-Peer model =20 =20 Lets get the ball rolling...:-) =20 regards Hormuzd =20 ------_=_NextPart_001_01C425CD.A9B7C73C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All

 

Weiming started a private discussion with Jamal and = myself over the weekend regarding renewing of protocol drafts and it has turned into = a useful discussion of how to make some quick progress on the protocol. = Both Jamal and myself are concerned that we have Not made good progress so = far on this team.

 

Here is a list of issues to be discussed as suggested = by Jamal.

 

0. Expected = architecture/use cases:

I believe this is = important to remove the major stumbling issue -

the different views = of implementations.

 

i) What each of (PL = and TML) does; we could steal from Davids url.

 

ii) scenario = layouts of processing.

ii-I) joining and = leaving; CEM/FEM role etc

ii-II) Lets pick = one or two simple examples (maybe just IPV4 forwarding

with = OSPF).

 

1. = TML

#0 above should = help ease this.

a) roles of TML vs = PL.

b) services = provided by TML to PL

i) what are they? =

ii) should the = services be controllable by the PL?

iii) if yes, to = what degree

2. = HA

3. Capability = Exchange, FEM/CEM

4.a. Protocol = Messages

4.b. Protocol = Scenarios

4.c. Common = Header

5. Support for = Vendor functions

6. Master-Slave or Peer-to-Peer model

 

 

Lets get the ball rolling…J

 

regards

Hormuzd

 

------_=_NextPart_001_01C425CD.A9B7C73C-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 06:38:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02066 for ; Mon, 19 Apr 2004 06:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFW98-00049l-9m for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 06:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JAb28s015977 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 06:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFW84-0003u1-W9 for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 06:35:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01905 for ; Mon, 19 Apr 2004 06:35:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFW80-0006Ks-Rn for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 06:35:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFW76-00066U-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 06:34:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFW6A-0005sh-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 06:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFW2L-0002oX-31; Mon, 19 Apr 2004 06:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFVyN-0001ql-Jj for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 06:25:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01456 for ; Mon, 19 Apr 2004 06:25:51 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFVyJ-0004BU-Fp for forces-protocol@ietf.org; Mon, 19 Apr 2004 06:25:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFVxK-0003xl-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 06:24:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFVwP-0003jX-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 06:23:53 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFVwQ-000OTD-PW for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:23:54 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1082224260.1039.59.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> <1082224260.1039.59.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 06:23:54 -0400 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 Content-Transfer-Encoding: 7bit On 17 apr 2004, at 13.51, Jamal Hadi Salim wrote: > I am finding it very hard to say we can do multiple TMLs and not say > how > a Forces PL can use them. I am not in favor of trying to create an PL-TML api. I personally think how these things are connected is an implementation issue. That is why GSMP took the encapsulation route. What needed to be defined was what went out on the wire. How the GSMP messages got to the encapsulator and what if any communication existed between them was left to the implementer - I didn't expect that part of the system to ever be an open interface. And I don't expect it to be in the ForCES case either. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 08:06:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06427 for ; Mon, 19 Apr 2004 08:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXX3-0004eU-0J for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:05:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JC5muH017875 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXRQ-0003Xn-Q1 for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 08:00:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06183 for ; Mon, 19 Apr 2004 07:59:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFXRP-0001p4-UM for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:00:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXQW-0001cc-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 07:59:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFXQ2-0001PQ-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 07:58:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXMc-0002QU-2i; Mon, 19 Apr 2004 07:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXIc-0001k6-PB for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 07:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05788 for ; Mon, 19 Apr 2004 07:50: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 1BFXIb-0007eI-Tn for forces-protocol@ietf.org; Mon, 19 Apr 2004 07:50:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFXHd-0007Pv-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 07:49:53 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BFXGh-0007CO-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 07:48:55 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041904522339:2973 ; Mon, 19 Apr 2004 04:52:23 -0700 Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> <1082224260.1039.59.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1082375332.424.98.camel@jzny.localdomain> 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 04/19/2004 04:52:23 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/19/2004 04:52:25 AM, Serialize complete at 04/19/2004 04:52:25 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Apr 2004 07:48:52 -0400 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 Content-Transfer-Encoding: 7bit On Mon, 2004-04-19 at 06:23, avri@acm.org wrote: > On 17 apr 2004, at 13.51, Jamal Hadi Salim wrote: > > > I am finding it very hard to say we can do multiple TMLs and not say > > how > > a Forces PL can use them. > > I am not in favor of trying to create an PL-TML api. I personally > think how these things are connected is an implementation issue. > > That is why GSMP took the encapsulation route. What needed to be > defined was what went out on the wire. How the GSMP messages got to > the encapsulator and what if any communication existed between them was > left to the implementer - I didn't expect that part of the system to > ever be an open interface. And I don't expect it to be in the ForCES > case either. There are really two things as i see it. One is the media encapsulation service which you defined in that RFC. The second is the transport services (which is more contentious in Forces).In the GSMP case the simplicity was a result of choosing a single transport (example TCP over IP). In our case i may want to run both TCP and UDP and want to use different features of each transport protocol. How do i signal selectively to the TML what features to use? I really dont want the API either, but i am not seeing a way out. We could create classes templates for each TML, example "use transport x always when you want reliability" - but at the end that would be the same as creating APIs in terms of workload. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 08:45:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08111 for ; Mon, 19 Apr 2004 08:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY81-0004Ek-4F for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JCi0Xs016280 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY46-0003Qg-4U for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 08:39:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07785 for ; Mon, 19 Apr 2004 08:39: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 1BFY44-0002ry-Ra for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:39:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFY38-0002fe-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:38:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFY2V-0002TV-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:38:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXtU-00011D-M3; Mon, 19 Apr 2004 08:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCA72-0007lS-IM for forces-protocol@optimus.ietf.org; Sat, 10 Apr 2004 00:29:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08917 for ; Sat, 10 Apr 2004 00:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCA6z-0000YQ-00 for forces-protocol@ietf.org; Sat, 10 Apr 2004 00:28:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCA5q-0000Pl-00 for forces-protocol@ietf.org; Sat, 10 Apr 2004 00:27:47 -0400 Received: from bay13-dav60.bay13.hotmail.com ([64.4.31.234] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BCA4n-0000Az-00 for forces-protocol@ietf.org; Sat, 10 Apr 2004 00:26:41 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 Apr 2004 21:26:02 -0700 Received: from 220.192.126.178 by bay13-dav60.bay13.hotmail.com with DAV; Sat, 10 Apr 2004 04:26:02 +0000 X-Originating-IP: [220.192.126.178] X-Originating-Email: [wmwang2001@hotmail.com] X-Sender: wmwang2001@hotmail.com From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E834D83@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Outline 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: X-OriginalArrivalTime: 10 Apr 2004 04:26:02.0741 (UTC) FILETIME=[EEC9FA50:01C41EB3] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 10 Apr 2004 12:23:08 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 ----------------- Hi David, Pls help me to post this email. My mail server is currently down so I have to use this address. Thank you very much. ------------------ Hi all, I also definitely support Avri as an editor. And moreover, if current scheme can not work well later (as Avri worried), I suggest WG to appoint Avri as the only neutral editor. Seems the 3+1 scheme can currently more widely be accepted, why not let's make a consensus on it and then move ahead quickly? ------------------ Hi Hormuzd, Followed is the email I wrote yesterday, but could not send out because the failure of my mail server. I still want to post it for a reference. But anyway, I agree with you that we need to move forward more quickly. Because now I can not follow the forces-protocol list, I will reply to your and Jamal's followed posts, maybe after monday. ------------------ Hormuzd, If we are now writing an Informational RFC, I think it's reasonable to take a specific first layer section for example descriptions, but if we are writing an standard RFC, I think we'd better not to do like this. From my viewpoint, it just looks a little ugly in a standard document, because we are mainly introducing the specifications of the standard instead to introduce examples. by saying this, I actully not object to take examples in the standard, but it is just for more clear understanding of readers. If you think the examples are very important, then they should not appear as examples. For instance, if you think the establish of association or CE failover scenarios are very important, they'd better to be included in a specific protocol description sections instead of as examples. You can go back to check the current RFCs for standards, it may be not as often used as you said. One alternative way is to take a section as "Implementation Notes" for some important scenarios, while take some introductive examples to the Appendix. Taking about TML requirements, my feeling is it may be better to be appeared in protocol overview somthing like 3. (Some section like protocol overview) ... 3. 1. The Protocol Layer (PL) and the Transportation Mapping Layer ( TML) 3. 2. TML Requirements (or some other word) ... My another feeling is if we should call it 'requirements', or we may use other word that is more relavent to describe TMP in PL. To put it in protocol overview may give us more time to have the the name decided after more discussions on TML issues. Anyway, I agree with you that this (to decide the outline) is not very difficult thing after we have more discussions on important issues, my idea is just that currently we may not need to strictly decide it. Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Sent: Friday, April 09, 2004 1:40 AM Subject: RE: [Forces-protocol] Outline Hi Weiming You're right, I have not incorporated all your comments...I should have explained a bit more in my last email..sorry about that. I think Example Scenarios is an important section and should be part of the main protocol sections. I have seen it in most RFCs/drafts that I have read, it makes things easy to understand for the reader. Is there any particular reason why it should be moved to the appendix ? Also, I think TML Requirements should be a separate section. I agree that protocol layering and TML will be introduced in Protocol Overview but TML requirements is different from that, goes into more of the details and deserves a separate section. Based on latest comments from Ram, yourself, here is what I propose.. Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. TML Requirements 7. Example Scenarios 8. Security Considerations 9. References 10. Acknowledgments Appendix Note that I have added an appendix, we can decide what goes into it later. Most folks have agreed with this initial outline, I would say lets go with this for now, unless you have strong reasons not to. We can always make changes later, once we get into more details. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Wednesday, April 07, 2004 7:30 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Outline If all ideas are incorparated, I suppose it may look like this: Abstract 1. Introduction 2. Definitions 3. Protocol Overview (or other more intensive word than overview) 4. Common Header 5. Protocol Messages 6. Security Considerations 7. References 8. Acknowledgments Appendix Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, Thanks for your comments! I am fine with the Definitions section. I have to agree with Jamal on the Common Header, all other sections are present in most drafts/RFCs as you have mentioned. Based on your, Jamal's comments here is what I propose for the outline... Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. Example Scenarios 7. TML Requirements 8. Security Considerations 9. References 10. Acknowledgments I completely agree with you that we need to start discussing protocol overview/messages. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 08:46:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08167 for ; Mon, 19 Apr 2004 08:46:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY81-0004F1-6a for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JCi1cX016294 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 08:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY46-0003Qi-Ok for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 08:39:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07788 for ; Mon, 19 Apr 2004 08:39: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 1BFY45-0002s3-FC for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:39:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFY39-0002fm-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:38:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFY2c-0002TY-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 08:38:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFXtU-00011J-Un; Mon, 19 Apr 2004 08:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmLt-00049w-Lt for forces-protocol@optimus.ietf.org; Wed, 14 Apr 2004 11:31:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01588 for ; Wed, 14 Apr 2004 11:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmLs-0001y3-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:31:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmKy-0001wU-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:30:04 -0400 Received: from mx03.cybersurf.com ([209.197.145.106]) by ietf-mx with esmtp (Exim 4.12) id 1BDmKH-0001tQ-00 for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:29:21 -0400 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BDmK6-0006pa-Py for forces-protocol@ietf.org; Wed, 14 Apr 2004 11:29:10 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BDlAc-0005GO-G2 for forces-protocol@ietf.org; Wed, 14 Apr 2004 10:15:18 -0400 From: jamal Reply-To: hadi@cyberus.ca To: forces-protocol@ietf.org Content-Type: text/plain Organization: jamalopolis Message-Id: <1081952103.1027.7.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] test2 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 14 Apr 2004 10:15:04 -0400 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 Content-Transfer-Encoding: 7bit wonder if this will make it through; 30 minutes later havent received an echo of other email _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 09:20:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09706 for ; Mon, 19 Apr 2004 09:20:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYcH-0002Ck-L9 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 09:15:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JDFHkw008469 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 09:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYY6-0001YI-F7 for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:10:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09329 for ; Mon, 19 Apr 2004 09:10: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 1BFYY4-0002Ce-UO for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:10:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYX8-0001xX-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:09:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFYWB-0001iK-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYSN-0000Ae-Io; Mon, 19 Apr 2004 09:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYNU-0007TS-PX for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 09:00:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08827 for ; Mon, 19 Apr 2004 08:59:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYNT-0007Pl-81 for forces-protocol@ietf.org; Mon, 19 Apr 2004 08:59:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYMW-0007DE-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 08:59:01 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BFYLx-0006zt-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 08:58:25 -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 i3JCvrPk013408 for ; Mon, 19 Apr 2004 12:57:53 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 i3JCvr9Q100720 for ; Mon, 19 Apr 2004 14:57:53 +0200 Received: from zurich.ibm.com (sig-9-145-226-115.de.ibm.com [9.145.226.115]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA56490; Mon, 19 Apr 2004 14:57:51 +0200 Message-ID: <4083CCCF.6060601@zurich.ibm.com> From: Patrick Droz Organization: IBM Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: forces-protocol@ietf.org Subject: [Fwd: Re: [Forces-protocol] Outline] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090201090504080707030500" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 14:57:51 +0200 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 This is a cryptographically signed message in MIME format. --------------ms090201090504080707030500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I also definitely support Avri as an editor. And moreover, if current scheme can not work well later (as Avri worried), I suggest WG to appoint Avri as the only neutral editor. Seems the 3+1 scheme can currently more widely be accepted, why not let's make a consensus on it and then move ahead quickly? ------------------ Hi Hormuzd, Followed is the email I wrote yesterday, but could not send out because the failure of my mail server. I still want to post it for a reference. But anyway, I agree with you that we need to move forward more quickly. Because now I can not follow the forces-protocol list, I will reply to your and Jamal's followed posts, maybe after monday. ------------------ Hormuzd, If we are now writing an Informational RFC, I think it's reasonable to take a specific first layer section for example descriptions, but if we are writing an standard RFC, I think we'd better not to do like this. From my viewpoint, it just looks a little ugly in a standard document, because we are mainly introducing the specifications of the standard instead to introduce examples. by saying this, I actully not object to take examples in the standard, but it is just for more clear understanding of readers. If you think the examples are very important, then they should not appear as examples. For instance, if you think the establish of association or CE failover scenarios are very important, they'd better to be included in a specific protocol description sections instead of as examples. You can go back to check the current RFCs for standards, it may be not as often used as you said. One alternative way is to take a section as "Implementation Notes" for some important scenarios, while take some introductive examples to the Appendix. Taking about TML requirements, my feeling is it may be better to be appeared in protocol overview somthing like 3. (Some section like protocol overview) ... 3. 1. The Protocol Layer (PL) and the Transportation Mapping Layer ( TML) 3. 2. TML Requirements (or some other word) ... My another feeling is if we should call it 'requirements', or we may use other word that is more relavent to describe TMP in PL. To put it in protocol overview may give us more time to have the the name decided after more discussions on TML issues. Anyway, I agree with you that this (to decide the outline) is not very difficult thing after we have more discussions on important issues, my idea is just that currently we may not need to strictly decide it. Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Sent: Friday, April 09, 2004 1:40 AM Subject: RE: [Forces-protocol] Outline Hi Weiming You're right, I have not incorporated all your comments...I should have explained a bit more in my last email..sorry about that. I think Example Scenarios is an important section and should be part of the main protocol sections. I have seen it in most RFCs/drafts that I have read, it makes things easy to understand for the reader. Is there any particular reason why it should be moved to the appendix ? Also, I think TML Requirements should be a separate section. I agree that protocol layering and TML will be introduced in Protocol Overview but TML requirements is different from that, goes into more of the details and deserves a separate section. Based on latest comments from Ram, yourself, here is what I propose.. Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. TML Requirements 7. Example Scenarios 8. Security Considerations 9. References 10. Acknowledgments Appendix Note that I have added an appendix, we can decide what goes into it later. Most folks have agreed with this initial outline, I would say lets go with this for now, unless you have strong reasons not to. We can always make changes later, once we get into more details. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Wednesday, April 07, 2004 7:30 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Outline If all ideas are incorparated, I suppose it may look like this: Abstract 1. Introduction 2. Definitions 3. Protocol Overview (or other more intensive word than overview) 4. Common Header 5. Protocol Messages 6. Security Considerations 7. References 8. Acknowledgments Appendix Best Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, Thanks for your comments! I am fine with the Definitions section. I have to agree with Jamal on the Common Header, all other sections are present in most drafts/RFCs as you have mentioned. Based on your, Jamal's comments here is what I propose for the outline... Abstract 1. Introduction 2. Definitions 3. Protocol Overview 4. Common Header 5. Protocol Messages 6. Example Scenarios 7. TML Requirements 8. Security Considerations 9. References 10. Acknowledgments I completely agree with you that we need to start discussing protocol overview/messages. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > Hormuzd, > Some comments: > > On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote: > > Here is an initial outline for the draft > > > > Abstract > > 1. Introduction [Weiming] I suppose we add 2. Definitions > > 2. Protocol Overview > > 3. Common Header [Weiming] The common header can be inside the overview. And also the overivew will explain the layering model of PL and TML, therefore the TML requirements can also be included in it. > > 4. Protocol Messages > > Should we follow with protocol details after this? > And should TML move to just below Protocol overview or were you thinking > protocol overview contains overview of TML as well? [Weiming] Agreed as above. > > > 5. Example Scenarios [Weiming] This section should be as an Appendix. > > 6. TML Requirements [Weiming]As mentioned above, this should be put early in the protocol overview, so that some protocol messages related to TML can be reasonably understood. > > 7. Security Considerations > > do security requirements belong to TML as well? > [Weiming]This section is still normally needed even TML will be more responsible for protocol security issues. > > 8. References > > 9. Acknowledgments > > > > Let me know what you guys think ? > > We can add more details as we move along. > > I think its a good start and good idea to have this at this point. We > probably shouldnt spend too much time on cosmetics right now because i > think we can iron those out as we go on. > > cheers, > jamal > [Weiming] To summarise, I think we may only need to give the first layer outlines as follows, 1. Introduction 2. Definitions 3. Protocol Overview 4. Protocol Messages All others are just normal ones and the more we need to discuss followed is the contents inside the overview and messages. As Jamal said, we can do it along with the issue discussions. Yours, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms090201090504080707030500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAOrMMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDMwOTA4MTAyNDA1WhcNMDQwOTIxMTAyNDA1WjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC//9dBNAp+s4dqrdHl AwtpHqKFJpK7XHUSKlMc0uIg4Dvw4T6+dqFcMtjgaOPkbro0L73tU6Hti+9UigXsqr1YNayD CR425561G1fVw6AsWqiXVA1P6hoiqnPsMn+WLTzTGyjr8jBHaaD5g4y8bCs0yw4RE14KLBWw zfw9VlC/xwIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFPztxGVcnWvExWu3RaHBhAT4jxKcMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQBQxqFX/t0vhd9BH5658zvMF7Wis2tpfE9+5mG0zs3ry4jGfXaG6lYG3DGHgbdM f/xH1nXSyWUV+FutJS61jjzNjtajPg+eob/7Mqjagdngk335t2a9+K7g8oqueBhJa/azrsHf WSYHN6OtQYMP519wM9bIxbnztei2Pq3MKLZnCTCCAyQwggKNoAMCAQICAwDqzDANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTAzMDkwODEwMjQwNVoXDTA0MDkyMTEwMjQwNVowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv//XQTQKfrOHaq3R5QML aR6ihSaSu1x1EipTHNLiIOA78OE+vnahXDLY4Gjj5G66NC+97VOh7YvvVIoF7Kq9WDWsgwke NueetRtX1cOgLFqol1QNT+oaIqpz7DJ/li080xso6/IwR2mg+YOMvGwrNMsOERNeCiwVsM38 PVZQv8cCAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBT87cRlXJ1rxMVrt0WhwYQE+I8SnDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAUMahV/7dL4XfQR+eufM7zBe1orNraXxPfuZhtM7N68uIxn12hupWBtwxh4G3TH/8 R9Z10sllFfhbrSUutY48zY7Woz4PnqG/+zKo2oHZ4JN9+bdmvfiu4PKKrngYSWv2s67B31km BzejrUGDD+dfcDPWyMW587Xotj6tzCi2ZwkxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0MTkx MjU3NTFaMCMGCSqGSIb3DQEJBDEWBBQvo5QUWi/ca8hDz97Lb4ZOrvCWjTBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwDqzDCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwDqzDANBgkqhkiG9w0BAQEFAASBgEjy649TVY01ZWdF7TjSRfng8OX2d4h84CT3 dTkAbPb75frBTK4hGaMYeS1Vws+3LFVH4/t6b9LZq2g7iUVJRZqI0EibTes3RyWYuZuF1Z8a lDGxxAseIsqRWPOGMrH7YNycOkMVY22sdJmdq08j5T+9o/iIQjclU72qE3LNfKEcAAAAAAAA --------------ms090201090504080707030500-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 10:10:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12681 for ; Mon, 19 Apr 2004 10:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZOf-00074m-7o for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:05:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JE5HdK027193 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZIm-0003HX-EG for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11489 for ; Mon, 19 Apr 2004 09:59: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 1BFZIk-0005PN-B6 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZHp-0005Az-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:58:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZHH-0004wf-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 09:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZFh-0002WF-Nt; Mon, 19 Apr 2004 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZ4D-0008IP-RO for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 09:44:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10788 for ; Mon, 19 Apr 2004 09:44:07 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZ4B-0001zi-V1 for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZ3I-0001m4-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:43:13 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFZ2U-0001XV-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:42:22 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDfDO20897; Mon, 19 Apr 2004 16:41:13 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 16:40:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3JDepI7025260; Mon, 19 Apr 2004 16:40:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00wE7zcx; Mon, 19 Apr 2004 16:40:50 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDeis24473; Mon, 19 Apr 2004 16:40:45 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 08:40:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQjyW7Ef8iVsFLJRjyxYkasy4ZPcgCSeK/w To: Cc: , , X-OriginalArrivalTime: 19 Apr 2004 13:40:19.0290 (UTC) FILETIME=[DAF463A0:01C42613] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:40:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Jamal, All, Comments are inline. > -----Original Message----- > From: ext Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Friday, April 16, 2004 11:41 AM > To: Gopal Ram (Nokia-NRC/Boston) > Cc: hormuzd.m.khosravi@intel.com; forces-protocol@ietf.org;=20 > Weiming Wang > Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA >=20 >=20 >=20 >=20 > On Fri, 2004-04-16 at 05:08, ram.gopal@nokia.com wrote: >=20 > > Instead of defining the TML layer API if we specify the=20 > required functioanlity what is expected=20 > > from PL that's a good starting point. Defining API's may=20 > make sense if more there are many potential > > applciations going to use the TML directly, current ForCES=20 > PL is the one which has this requiements. >=20 > Note, could be an API or protocol (Refer to my last email to Hormuzd=20 > on this). There could also be more than one PL using the same TML. > I agree with you a good starting point is defining what services > are to be provided by the TML to the PL. > Clearly, the most important one is transport and all its aspects. > Also clear that the PL should have a say in the degree on how those > services are provided. Again, this is valuable if you are able to > request at a per packet level. > >From an API perspective (could easily be mapped to a simple protocol > over TCP for example), i see: >=20 > =3D>open(): connects a PL to a TML > =3D> close(): disengages PL from TML > =3D> read(): PL reading from TML > =3D> write(): PL writting to TML > =3D> event(): dont want to talk about poll/select() - TML notifying PL > =3D> ioctl(): PL controlling something within a TML (eg you=20 > could fit both > a bind() and connect() like call here, also things like a "move" > operation from PL->TML etc). >=20 >=20 > > One clarification ... because its confsuing from the emails... > > =20 > > If we are going to define the API for TML layer(top half),=20 > then ForCES message structure what we have=20 > > been discussing becomes the part of the TML layer (bottom=20 > half). Then ForceS PL layer (bottom half)becomes implementation > > specific all it has to do is invoke those TML (top half)=20 > API's. Then it becomes the repsonsibility of the TML bottom half > > to transform those API data strcuture into the ForCES=20 > message format... =20 >=20 > Yes, i think it becomes a blackbox how the TML does things. There may > be some things where it may be more of grey than black box; example is > what you mention above on encoding where the possibilities I see are: >=20 > 1) raw mode: TML creates and fills all the headers > 2) medium mode: PL creates the headers and partially fills=20 > some headers. > TML adds the rest of the headers.=20 > 3) cooked mode: PL is responsible for headers >=20 > [..] We already have several configuration options... unessary and extra = configuration may make the=20 protocol useless. If there is a strong requirement as you pointed out - my opinion is = that instead of having several=20 options between PL and TML as we were clarfiing here.... between TML and = PL . Let us make the TML and PL simpler with less to do configuration, may be have an at TML (top half)API = irrespective of the mode of operations and then TML layer (bottom half) handles the messages. This makes the definition and = configuration simpler and will work in any mode. Any opnion? Regards Ramg >=20 > > > >=20 > > As mentioned earlier.. > >=20 > > SCTP and TCP has wide application usage, there is clealy companies=20 > > involved in providing stack and companies involved in > > developing applications.=20 > >=20 > > Where as in TML and PL case, the requirements are ForCES=20 > specifics, no=20 > > applications other than ForCES have=20 > > such requirements. IMHO, if we specify only the=20 > requirements and leave=20 > > the adaptation (implemenation open) will be a good > > idea.=20 >=20 > I think we need some minimal interface; however i havent looked at the > GSMP RFCs maybe theres something clever there. > True that this will add one more twist, but i am not sure how to avoid > it. >=20 > cheers, > jamal >=20 >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 10:17:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13304 for ; Mon, 19 Apr 2004 10:17:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZUt-0001bR-Fz for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:11:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JEBh4E006157 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:11:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZQQ-0007x4-GB for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 10:07:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12309 for ; Mon, 19 Apr 2004 10:07:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZQO-0007OO-GM for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:07:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZPX-00077z-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:06:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZOb-0006rj-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZIb-0003EX-TY; Mon, 19 Apr 2004 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZFp-0002XY-86 for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 09:56:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11281 for ; Mon, 19 Apr 2004 09:56:06 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZFn-0004fp-6q for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:56:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZEv-0004RB-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:55:14 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFZDy-0004Cg-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 09:54:14 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDs0m11046; Mon, 19 Apr 2004 16:54:05 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 16:53:58 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3JDrwk0003800; Mon, 19 Apr 2004 16:53:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00iYR4wm; Mon, 19 Apr 2004 16:53:57 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JDrrs04721; Mon, 19 Apr 2004 16:53:54 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 08:52:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42615.839FEFD0" Subject: RE: [Forces-protocol] List of issues for discussion Message-ID: Thread-Topic: List of issues for discussion Thread-Index: AcQlzakztd+JcwN/QDagKGG6CU0KmQARu7zw To: , X-OriginalArrivalTime: 19 Apr 2004 13:52:13.0561 (UTC) FILETIME=[84B17E90:01C42615] Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 09:52:11 -0400 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_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42615.839FEFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, =20 Thanks for the update- the purpose of the mailing list is the have = people discuss the issues openly and not to have private conversation of = the decision. I have been having difficulties in reading emails and the = past few days only I was reading emails.=20 =20 In future, please discuss all the issues on the list. =20 regarding this work item - comments are inline. =20 Regards Ramg -----Original Message----- From: forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, = Hormuzd M Sent: Monday, April 19, 2004 1:18 AM To: forces-protocol@ietf.org Subject: [Forces-protocol] List of issues for discussion Hi All =20 Weiming started a private discussion with Jamal and myself over the = weekend regarding renewing of protocol drafts and it has turned into a = useful discussion of how to make some quick progress on the protocol. = Both Jamal and myself are concerned that we have Not made good progress = so far on this team. =20 Here is a list of issues to be discussed as suggested by Jamal. =20 0. Expected architecture/use cases: I believe this is important to remove the major stumbling issue - the different views of implementations. =20 i) What each of (PL and TML) does; we could steal from Davids url. =20 ii) scenario layouts of processing.=20 ii-I) joining and leaving; CEM/FEM role etc ii-II) Lets pick one or two simple examples (maybe just IPV4 forwarding with OSPF). =20 What's the reason for picking this two? =20 1. TML #0 above should help ease this. a) roles of TML vs PL. b) services provided by TML to PL i) what are they?=20 ii) should the services be controllable by the PL? iii) if yes, to what degree [] This needs to be discussed. 2. HA=20 [] Commonly used mechanism are CE-CE and its outside the scope. = But we need to make sure that the protocol can accomudate both FE-CE and also CE-CE (and not sure of FE-FE scenario's - = typically done in hardware). =20 3. Capability Exchange, FEM/CEM 4.a. Protocol Messages 4.b. Protocol Scenarios 4.c. Common Header [] May be reverse the order.=20 a. Message types and overview b. Common header c. Protocol MEssage structure d. Protocol scenarios ( operations) =20 Describe the HA specific operation, security operation, TML = specific opreation etc.. 5. Support for Vendor functions 6. Master-Slave or Peer-to-Peer model =20 Regards Ramg=20 =20 =20 Lets get the ball rolling...:-) =20 regards Hormuzd =20 ------_=_NextPart_001_01C42615.839FEFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 All,
 
Thanks=20 for the update- the purpose of the mailing list is the have people = discuss the=20 issues openly and not to have private conversation of the decision. I = have been=20 having difficulties in reading emails and the past few days only I was = reading=20 emails.
 
In=20 future, please discuss all the issues on the list.
 
regarding this work item - comments are = inline.
 
Regards
Ramg
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On=20 Behalf Of ext Khosravi, Hormuzd M
Sent: Monday, April = 19, 2004=20 1:18 AM
To: forces-protocol@ietf.org
Subject:=20 [Forces-protocol] List of issues for discussion

Hi All

 

Weiming started a = private=20 discussion with Jamal and myself over the weekend regarding renewing = of=20 protocol drafts and it has turned into a useful discussion of how to = make some=20 quick progress on the protocol. Both Jamal and myself are concerned = that we=20 have Not made good progress so far on this team.

 

Here is a list of issues = to be=20 discussed as suggested by Jamal.

 

0. Expected=20 architecture/use cases:

I believe this = is=20 important to remove the major stumbling issue -

the different = views of=20 implementations.

 

i) What each of = (PL and=20 TML) does; we could steal from Davids url.

 

ii) scenario = layouts of=20 processing.

ii-I) joining = and leaving;=20 CEM/FEM role etc

ii-II) Lets pick = one or=20 two simple examples (maybe just IPV4 forwarding

with=20 OSPF).

 

<RamG>

What's the reason for picking this=20 two?

<RamG>

 

1. = TML

#0 above should = help ease=20 this.

a) roles of TML = vs=20 PL.

b) services = provided by=20 TML to PL

i) what are = they?=20

ii) should the = services be=20 controllable by the PL?

iii) if yes, to = what=20 degree


[<Ramg>]  This needs to be=20 discussed.

 2. = HA 


[<Ramg>]  Commonly used mechanism are CE-CE = and its=20 outside the scope. But we need to make sure that the protocol=20 can

accomudate both FE-CE and also CE-CE (and not sure of = FE-FE=20 scenario's - typically done in hardware).

 

 3. = Capability=20 Exchange, FEM/CEM

4.a. Protocol=20 Messages

4.b. Protocol=20 Scenarios

4.c. Common=20 Header


[<Ramg>] =20 May be reverse the order.

a. Message types and overview

b. Common header

c. Protocol MEssage structure

d. Protocol scenarios ( operations)

 

<RamG> Describe the HA specific operation, = security=20 operation, TML specific opreation etc..

 5. Support for Vendor=20 functions

6. Master-Slave = or=20 Peer-to-Peer model

 

Regards

Ramg 

 

 

Lets get the ball=20 rolling…J

 

regards

Hormuzd

 

------_=_NextPart_001_01C42615.839FEFD0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 10:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13679 for ; Mon, 19 Apr 2004 10:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZd4-0005IH-Dv for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JEKAdA020335 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 10:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZc1-0004fV-K1 for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 10:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13529 for ; Mon, 19 Apr 2004 10:19: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 1BFZbz-0002Eu-80 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:19:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZbB-00021i-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:18:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFZaG-0001nq-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZVE-0001rD-7F; Mon, 19 Apr 2004 10:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFZQe-00084y-Am for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 10:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12381 for ; Mon, 19 Apr 2004 10:07:17 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFZQc-0007QB-4a for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:07:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFZPw-0007BK-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:06:37 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BFZOw-0006uT-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:05:34 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JE4x814409; Mon, 19 Apr 2004 17:04:59 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 17:04:37 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3JE4bWx019853; Mon, 19 Apr 2004 17:04:37 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 005NsYU7; Mon, 19 Apr 2004 17:04:35 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JE4Vs12871; Mon, 19 Apr 2004 17:04:31 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 09:04:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Protocol Messages Message-ID: Thread-Topic: [Forces-protocol] Protocol Messages Thread-Index: AcQj7mOqSRCP+xN/QAegTYDoFq6m6AAANmpQAImwE8A= To: , , Cc: X-OriginalArrivalTime: 19 Apr 2004 14:04:28.0595 (UTC) FILETIME=[3ACEC830:01C42617] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 10:04:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, Comments are inline. =20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Friday, April 16, 2004 4:19 PM > To: hadi@znyx.com; Weiming Wang > Cc: forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Protocol Messages >=20 >=20 > Here is the header summary that we had published... >=20 > Issue# 0 IDs in the header:- > There was a lot of discussion on this topic regarding the naming, > semantics, length of these IDs. > The result was as follows... > Naming: CE ID, FE ID > Semantics: Used to address a single, group or all CEs/FEs respectively > Length: 16-32 bits...TBD >=20 > Another issue we reached agreement on was using LFB Type ID, LFB > Instance ID in combination of FE ID for addressing LFBs on the FE. The > LFB Instance ID will be part of the payload. The LFB Type ID location, > whether it is part of header or payload is TBD. >=20 Sorry for raising questions - during this topic discussion - my email = system had problems. What is the reason for having the LFB ID being in the common header, if = we support command bundling there will be more than one LFB ID getting affecting by that = opreations. When a CE sends a message, the receipt FE will parse the sub-header (or next header) = depending upon the message type and act accordingly. =20 > Issue# 1 Header/Encoding:- > Here are the fields in the common header that there was=20 > consensus around > IDs: as summarized in issue 0 > Version/sub-ver: 4 bits > Sequence No. : 32 bits ok. > Length : 16 bits=20 Length in dword. > Command Type : 8 bits (semantics - TBD) We need to list the number of messages, classify them logically and then = split it. For example, startup messages, operational messages, configuration = messages, etc. These messages were discussed in earlier threads of emails. > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) Let us list out fields we require... - Priority=20 - Command Building=20 - Two phase commit -=20 Please add the information and then we can filter how to incorporate = these. > LFB TypeID: TBD, no consensus on whether it is needed or not in the > header See my above explanation. In some scnerio it may be ok but in general = we can move it to sub header. CE talks to FE endpoints and FE endpoint knows how to decoded the sub = header and pass it on to=20 LFB blocks. Regards Ramg > ------------- >=20 > As you can see, there were very few TBDs, the main one was=20 > regarding LFB > Type ID. > I believe most folks agreed that we don't need it in the=20 > common header, > but there were different views as well so we can have a discussion on > this. >=20 > I will also continue the discussion on Protocol messages, I=20 > think that's > also important and will help clarify our direction further. >=20 > Regards > Hormuzd >=20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 >=20 > Can we start with the header and where we left off? > I am trying my best not to respond to any of the other messages > because i think it is important to start with the header. > Hormuzd or maybe it was Weiming i thought in the early days=20 > had capturd > these details. If not i can compile. >=20 > cheers, > jamal >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 11:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15787 for ; Mon, 19 Apr 2004 11:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaH0-0005a9-IC for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 11:01:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JF1QbA021453 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 11:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaFn-0005Lj-IF for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 11:00:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15649 for ; Mon, 19 Apr 2004 11:00:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFaFk-0003tc-U0 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 11:00:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaEk-0003bm-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:59:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFaDM-0003C2-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 10:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFa4z-0003Gj-BV; Mon, 19 Apr 2004 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFa39-0002ro-Vk for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 10:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14798 for ; Mon, 19 Apr 2004 10:47:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFa37-0000mQ-7L for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFa27-0000ZH-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:46:04 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BFa1Q-0000MT-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 10:45:21 -0400 Received: from wwm1 (unverified [219.82.188.103]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 19 Apr 2004 22:57:30 +0800 Message-ID: <010c01c4261c$6a6f5f00$020aa8c0@wwm1> From: "Weiming Wang" To: , References: Subject: Re: [Forces-protocol] List of issues for discussion MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C4265F.77B27830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 22:41:34 +0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C4265F.77B27830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gUmFtLCBhbmQgYWxsLA0KDQpBY3R1YWxseSB3ZSBoYXZlIG5vdCB0cnkgdG8gZGVjaWRl IGFueXRoaW5nIHByaXZhdGVseS4gRmlyc3RseSBJIGp1c3Qgd2FudCBtZW50aW9uIEphbWFsIGlm IGhlIG5lZWRzIHRvIHVwZGF0ZSB0aGUgTmV0bGluazIgZHJhZnQsIGZvciBpdCBpcyB2ZXJ5IG5l YXIgdGhlIGV4cGlyZSBkYXRlLiBJIHByaXZhdGVseSB3cml0ZSB0byBKYW1hbCBvbiB0aGlzIGJl Y2F1c2UgaSB0aGluayBpdCBpcyBiZXlvbmQgdGhlIGN1cnJlbnQgdG9waWMgYW5kIEkgZG9uJ3Qg d2FudCBtYWtlIHNvbWUgbm9pc2Ugb24gdGhlIGxpc3QuIFdoZW4gd2UgcmVhbGl6ZWQgc29tZSB0 b3BpYyBoYXMgcmVsYXRlZCB0byBkZXNpZ24gdGVhbSB0b3BpYywgSSB0aGluayBIb3JtdXpkIGhh cyBpbW1lZGlhdGVseSB0cmFuc2ZlcmVkIGl0IHRvIHRoZSBsaXN0Lg0KDQpJJ20gc29ycnkgaWYg aXQgaXQgaGFzIG1hZGUgdGhlIGxpc3QgYSBsaXR0bGUgYml0IHVuaGFwcHkuDQoNCllvdXJzLA0K V2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiByYW0uZ29w YWxAbm9raWEuY29tIA0KICBUbzogaG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSA7IGZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZyANCiAgU2VudDogTW9uZGF5LCBBcHJpbCAxOSwgMjAwNCA5OjUy IFBNDQogIFN1YmplY3Q6IFJFOiBbRm9yY2VzLXByb3RvY29sXSBMaXN0IG9mIGlzc3VlcyBmb3Ig ZGlzY3Vzc2lvbg0KDQoNCiAgSGVsbG8gQWxsLA0KDQogIFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS0g dGhlIHB1cnBvc2Ugb2YgdGhlIG1haWxpbmcgbGlzdCBpcyB0aGUgaGF2ZSBwZW9wbGUgZGlzY3Vz cyB0aGUgaXNzdWVzIG9wZW5seSBhbmQgbm90IHRvIGhhdmUgcHJpdmF0ZSBjb252ZXJzYXRpb24g b2YgdGhlIGRlY2lzaW9uLiBJIGhhdmUgYmVlbiBoYXZpbmcgZGlmZmljdWx0aWVzIGluIHJlYWRp bmcgZW1haWxzIGFuZCB0aGUgcGFzdCBmZXcgZGF5cyBvbmx5IEkgd2FzIHJlYWRpbmcgZW1haWxz LiANCg0KICBJbiBmdXR1cmUsIHBsZWFzZSBkaXNjdXNzIGFsbCB0aGUgaXNzdWVzIG9uIHRoZSBs aXN0Lg0KDQogIHJlZ2FyZGluZyB0aGlzIHdvcmsgaXRlbSAtIGNvbW1lbnRzIGFyZSBpbmxpbmUu DQoNCiAgUmVnYXJkcw0KICBSYW1nDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAg ICBGcm9tOiBmb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpmb3JjZXMtcHJv dG9jb2wtYWRtaW5AaWV0Zi5vcmddT24gQmVoYWxmIE9mIGV4dCBLaG9zcmF2aSwgSG9ybXV6ZCBN DQogICAgU2VudDogTW9uZGF5LCBBcHJpbCAxOSwgMjAwNCAxOjE4IEFNDQogICAgVG86IGZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFtGb3JjZXMtcHJvdG9jb2xdIExpc3Qg b2YgaXNzdWVzIGZvciBkaXNjdXNzaW9uDQoNCg0KICAgIEhpIEFsbA0KDQoNCg0KICAgIFdlaW1p bmcgc3RhcnRlZCBhIHByaXZhdGUgZGlzY3Vzc2lvbiB3aXRoIEphbWFsIGFuZCBteXNlbGYgb3Zl ciB0aGUgd2Vla2VuZCByZWdhcmRpbmcgcmVuZXdpbmcgb2YgcHJvdG9jb2wgZHJhZnRzIGFuZCBp dCBoYXMgdHVybmVkIGludG8gYSB1c2VmdWwgZGlzY3Vzc2lvbiBvZiBob3cgdG8gbWFrZSBzb21l IHF1aWNrIHByb2dyZXNzIG9uIHRoZSBwcm90b2NvbC4gQm90aCBKYW1hbCBhbmQgbXlzZWxmIGFy ZSBjb25jZXJuZWQgdGhhdCB3ZSBoYXZlIE5vdCBtYWRlIGdvb2QgcHJvZ3Jlc3Mgc28gZmFyIG9u IHRoaXMgdGVhbS4NCg0KDQoNCiAgICBIZXJlIGlzIGEgbGlzdCBvZiBpc3N1ZXMgdG8gYmUgZGlz Y3Vzc2VkIGFzIHN1Z2dlc3RlZCBieSBKYW1hbC4NCg0KDQoNCiAgICAwLiBFeHBlY3RlZCBhcmNo aXRlY3R1cmUvdXNlIGNhc2VzOg0KDQogICAgSSBiZWxpZXZlIHRoaXMgaXMgaW1wb3J0YW50IHRv IHJlbW92ZSB0aGUgbWFqb3Igc3R1bWJsaW5nIGlzc3VlIC0NCg0KICAgIHRoZSBkaWZmZXJlbnQg dmlld3Mgb2YgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0KICAgIGkpIFdoYXQgZWFjaCBvZiAoUEwg YW5kIFRNTCkgZG9lczsgd2UgY291bGQgc3RlYWwgZnJvbSBEYXZpZHMgdXJsLg0KDQoNCg0KICAg IGlpKSBzY2VuYXJpbyBsYXlvdXRzIG9mIHByb2Nlc3NpbmcuIA0KDQogICAgaWktSSkgam9pbmlu ZyBhbmQgbGVhdmluZzsgQ0VNL0ZFTSByb2xlIGV0Yw0KDQogICAgaWktSUkpIExldHMgcGljayBv bmUgb3IgdHdvIHNpbXBsZSBleGFtcGxlcyAobWF5YmUganVzdCBJUFY0IGZvcndhcmRpbmcNCg0K ICAgIHdpdGggT1NQRikuDQoNCg0KDQogICAgPFJhbUc+DQoNCiAgICBXaGF0J3MgdGhlIHJlYXNv biBmb3IgcGlja2luZyB0aGlzIHR3bz8NCg0KICAgIDxSYW1HPg0KDQoNCg0KICAgIDEuIFRNTA0K DQogICAgIzAgYWJvdmUgc2hvdWxkIGhlbHAgZWFzZSB0aGlzLg0KDQogICAgYSkgcm9sZXMgb2Yg VE1MIHZzIFBMLg0KDQogICAgYikgc2VydmljZXMgcHJvdmlkZWQgYnkgVE1MIHRvIFBMDQoNCiAg ICBpKSB3aGF0IGFyZSB0aGV5PyANCg0KICAgIGlpKSBzaG91bGQgdGhlIHNlcnZpY2VzIGJlIGNv bnRyb2xsYWJsZSBieSB0aGUgUEw/DQoNCiAgICBpaWkpIGlmIHllcywgdG8gd2hhdCBkZWdyZWUN Cg0KDQogICAgWzxSYW1nPl0gIFRoaXMgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkLg0KDQogICAgIDIu IEhBIA0KDQoNCiAgICBbPFJhbWc+XSAgQ29tbW9ubHkgdXNlZCBtZWNoYW5pc20gYXJlIENFLUNF IGFuZCBpdHMgb3V0c2lkZSB0aGUgc2NvcGUuIEJ1dCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0 IHRoZSBwcm90b2NvbCBjYW4NCg0KICAgIGFjY29tdWRhdGUgYm90aCBGRS1DRSBhbmQgYWxzbyBD RS1DRSAoYW5kIG5vdCBzdXJlIG9mIEZFLUZFIHNjZW5hcmlvJ3MgLSB0eXBpY2FsbHkgZG9uZSBp biBoYXJkd2FyZSkuDQoNCg0KDQogICAgIDMuIENhcGFiaWxpdHkgRXhjaGFuZ2UsIEZFTS9DRU0N Cg0KICAgIDQuYS4gUHJvdG9jb2wgTWVzc2FnZXMNCg0KICAgIDQuYi4gUHJvdG9jb2wgU2NlbmFy aW9zDQoNCiAgICA0LmMuIENvbW1vbiBIZWFkZXINCg0KDQogICAgWzxSYW1nPl0gIE1heSBiZSBy ZXZlcnNlIHRoZSBvcmRlci4gDQoNCiAgICBhLiBNZXNzYWdlIHR5cGVzIGFuZCBvdmVydmlldw0K DQogICAgYi4gQ29tbW9uIGhlYWRlcg0KDQogICAgYy4gUHJvdG9jb2wgTUVzc2FnZSBzdHJ1Y3R1 cmUNCg0KICAgIGQuIFByb3RvY29sIHNjZW5hcmlvcyAoIG9wZXJhdGlvbnMpDQoNCg0KDQogICAg PFJhbUc+IERlc2NyaWJlIHRoZSBIQSBzcGVjaWZpYyBvcGVyYXRpb24sIHNlY3VyaXR5IG9wZXJh dGlvbiwgVE1MIHNwZWNpZmljIG9wcmVhdGlvbiBldGMuLg0KDQogICAgIDUuIFN1cHBvcnQgZm9y IFZlbmRvciBmdW5jdGlvbnMNCg0KICAgIDYuIE1hc3Rlci1TbGF2ZSBvciBQZWVyLXRvLVBlZXIg bW9kZWwNCg0KDQoNCg0KICAgIFJlZ2FyZHMNCg0KICAgIFJhbWcgDQoNCg0KDQoNCg0KICAgIExl dHMgZ2V0IHRoZSBiYWxsIHJvbGxpbmcuSg0KDQoNCg0KICAgIHJlZ2FyZHMNCg0KICAgIEhvcm11 emQNCg0KDQo= ------=_NextPart_000_0109_01C4265F.77B27830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTogV2luZ2RpbmdzOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDEx LjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7 DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRp bWVzIE5ldyBSb21hbiINCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJH SU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkRJVi5N c29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1G QU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhU LURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBi bHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtG b2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uRW1haWxTdHlsZTE3IHsNCglDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IEFy aWFsDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1wdXJwbGUgbGluaz1ibHVlIGJnQ29sb3I9I2Zm ZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IZWxsbyBSYW0s IGFuZCBhbGwsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAz MDc7IHNpemU9Mj5BY3R1YWxseSB3ZSBoYXZlIG5vdCB0cnkgdG8gZGVjaWRlIGFueXRoaW5nIA0K cHJpdmF0ZWx5LiZuYnNwO0ZpcnN0bHkgSSBqdXN0IHdhbnQmbmJzcDttZW50aW9uIEphbWFsIGlm IGhlIG5lZWRzIHRvIHVwZGF0ZSB0aGUgDQpOZXRsaW5rMiBkcmFmdCwgZm9yIGl0IGlzIHZlcnkg bmVhciB0aGUgZXhwaXJlIGRhdGUuIEkgcHJpdmF0ZWx5IHdyaXRlIHRvIEphbWFsIA0Kb24gdGhp cyBiZWNhdXNlIGkgdGhpbmsgaXQgaXMgYmV5b25kIHRoZSBjdXJyZW50IHRvcGljIGFuZCBJIGRv bid0IHdhbnQgbWFrZSANCnNvbWUgbm9pc2Ugb24gdGhlIGxpc3QuIFdoZW4gd2UgcmVhbGl6ZWQm bmJzcDtzb21lIHRvcGljIGhhcyByZWxhdGVkIHRvIGRlc2lnbiANCnRlYW0gdG9waWMsIEkgdGhp bmsgSG9ybXV6ZCBoYXMgaW1tZWRpYXRlbHkgdHJhbnNmZXJlZCBpdCB0byB0aGUgDQpsaXN0Ljwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ SSdtIHNvcnJ5IGlmIGl0IGl0IGhhcyBtYWRlIHRoZSBsaXN0IGEgbGl0dGxlIGJpdCANCnVuaGFw cHkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mj5Zb3Vycyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 OyBzaXplPTI+V2VpbWluZzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gPC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkct UklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1M RUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxl PSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cmFtLmdvcGFsQG5va2lhLmNv bSANCiAgaHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5j b208L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+ PEI+VG86PC9CPiA8QSB0aXRsZT1ob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIA0KICBocmVm PSJtYWlsdG86aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+aG9ybXV6ZC5tLmtob3NyYXZp QGludGVsLmNvbTwvQT4gOyANCiAgPEEgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0K ICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OyI+PEI+U2VudDo8L0I+IE1vbmRheSwgQXByaWwgMTksIDIwMDQgOTo1MiBQTTwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+ IFJFOiBbRm9yY2VzLXByb3RvY29sXSBMaXN0IG9mIGlzc3VlcyANCiAgZm9yIGRpc2N1c3Npb248 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NzEzMzY0NTEzLTE5 MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPkhlbGxvIEFs bCw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxMzM2NDUxMy0xOTA0 MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAwND48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5UaGFua3MgZm9yIHRoZSB1 cGRhdGUtIHRoZSBwdXJwb3NlIG9mIHRoZSBtYWlsaW5nIGxpc3QgaXMgdGhlIGhhdmUgDQogIHBl b3BsZSBkaXNjdXNzIHRoZSBpc3N1ZXMgb3Blbmx5IGFuZCBub3QgdG8gaGF2ZSBwcml2YXRlIGNv bnZlcnNhdGlvbiBvZiB0aGUgDQogIGRlY2lzaW9uLiBJIGhhdmUgYmVlbiBoYXZpbmcgZGlmZmlj dWx0aWVzIGluIHJlYWRpbmcgZW1haWxzIGFuZCB0aGUgcGFzdCBmZXcgDQogIGRheXMgb25seSBJ IHdhcyByZWFkaW5nIGVtYWlscy4gPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBj bGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K ICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03 MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5J biANCiAgZnV0dXJlLCBwbGVhc2UgZGlzY3VzcyBhbGwgdGhlIGlzc3VlcyBvbiB0aGUgbGlzdC48 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAw ND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAwND48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5yZWdhcmRpbmcgdGhpcyB3b3Jr IGl0ZW0gLSBjb21tZW50cyBhcmUgaW5saW5lLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+ PFNQQU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4g Y2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CiAgc2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNz PTcxMzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNp emU9Mj5SYW1nPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAg c3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDog IzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWIGNsYXNzPU91 dGxvb2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSAN CiAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IDxB IA0KICAgIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmciPmZvcmNl cy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZzwvQT4gDQogICAgW21haWx0bzpmb3JjZXMtcHJvdG9j b2wtYWRtaW5AaWV0Zi5vcmddPEI+T24gQmVoYWxmIE9mIDwvQj5leHQgS2hvc3JhdmksIA0KICAg IEhvcm11emQgTTxCUj48Qj5TZW50OjwvQj4gTW9uZGF5LCBBcHJpbCAxOSwgMjAwNCAxOjE4IEFN PEJSPjxCPlRvOjwvQj4gDQogICAgZm9yY2VzLXByb3RvY29sQGlldGYub3JnPEJSPjxCPlN1Ympl Y3Q6PC9CPiBbRm9yY2VzLXByb3RvY29sXSBMaXN0IG9mIGlzc3VlcyANCiAgICBmb3IgZGlzY3Vz c2lvbjxCUj48QlI+PC9GT05UPjwvRElWPg0KICAgIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgQWxsPC9TUEFOPjwv Rk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBBcmlhbCI+V2VpbWluZyBzdGFydGVkIGEgcHJpdmF0ZSANCiAgICBkaXNjdXNzaW9u IHdpdGggSmFtYWwgYW5kIG15c2VsZiBvdmVyIHRoZSB3ZWVrZW5kIHJlZ2FyZGluZyByZW5ld2lu ZyBvZiANCiAgICBwcm90b2NvbCBkcmFmdHMgYW5kIGl0IGhhcyB0dXJuZWQgaW50byBhIHVzZWZ1 bCBkaXNjdXNzaW9uIG9mIGhvdyB0byBtYWtlIA0KICAgIHNvbWUgcXVpY2sgcHJvZ3Jlc3Mgb24g dGhlIHByb3RvY29sLiBCb3RoIEphbWFsIGFuZCBteXNlbGYgYXJlIGNvbmNlcm5lZCANCiAgICB0 aGF0IHdlIGhhdmUgTm90IG1hZGUgZ29vZCBwcm9ncmVzcyBzbyBmYXIgb24gdGhpcyB0ZWFtLjwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog QXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogQXJpYWwiPkhlcmUgaXMgYSBsaXN0IG9mIGlzc3VlcyB0byBiZSANCiAg ICBkaXNjdXNzZWQgYXMgc3VnZ2VzdGVkIGJ5IEphbWFsLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiAnQ291cmllciBOZXcnIj4wLiBFeHBlY3RlZCANCiAgICBhcmNoaXRlY3R1cmUvdXNlIGNhc2Vz OjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5JIGJlbGlldmUgdGhpcyBpcyANCiAgICBpbXBvcnRh bnQgdG8gcmVtb3ZlIHRoZSBtYWpvciBzdHVtYmxpbmcgaXNzdWUgLTwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnIj50aGUgZGlmZmVyZW50IHZpZXdzIG9mIA0KICAgIGltcGxlbWVudGF0aW9ucy48L1NQ QU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogJ0NvdXJpZXIgTmV3JyI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPmkpIFdo YXQgZWFjaCBvZiAoUEwgYW5kIA0KICAgIFRNTCkgZG9lczsgd2UgY291bGQgc3RlYWwgZnJvbSBE YXZpZHMgdXJsLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48L1NQQU4+PC9GT05UPiZuYnNwOzwv UD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9 Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JyI+aWkpIHNjZW5hcmlvIGxheW91dHMgb2YgDQogICAgcHJvY2Vzc2luZy4gPC9TUEFO PjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyciPmlpLUkpIGpvaW5pbmcgYW5kIA0KICAgIGxlYXZpbmc7IENFTS9G RU0gcm9sZSBldGM8L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+aWktSUkpIExldHMgcGljayBvbmUg b3IgDQogICAgdHdvIHNpbXBsZSBleGFtcGxlcyAobWF5YmUganVzdCBJUFY0IGZvcndhcmRpbmc8 L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+d2l0aCANCiAgICBPU1BGKS48L1NQQU4+PC9GT05UPjwv UD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9 Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JyI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnIj48U1BBTiANCiAgICBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+Jmx0O1JhbUcmZ3Q7 PC9TUEFOPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiAN CiAgICBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+V2hhdCdzIHRoZSByZWFzb24gZm9yIHBpY2tp bmcgdGhpcyANCiAgICB0d28/PC9TUEFOPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnIj48U1BBTiANCiAgICBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+Jmx0O1JhbUcm Z3Q7PC9TUEFOPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BB TiANCiAgICBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+PC9TUEFOPjwvU1BBTj4mbmJzcDs8L1A+ DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+ PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyciPjEuIFRNTDwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4jMCBhYm92ZSBzaG91bGQgaGVs cCANCiAgICBlYXNlIHRoaXMuPC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPmEpIHJvbGVzIG9mIFRN TCB2cyANCiAgICBQTC48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+Yikgc2VydmljZXMgcHJvdmlk ZWQgYnkgDQogICAgVE1MIHRvIFBMPC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPmkpIHdoYXQgYXJl IHRoZXk/IA0KICAgIDwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5paSkgc2hvdWxkIHRoZSBzZXJ2 aWNlcyANCiAgICBiZSBjb250cm9sbGFibGUgYnkgdGhlIFBMPzwvU1BBTj48L0ZPTlQ+PC9QPg0K ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxT UEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnIj5paWkpIGlmIHllcywgdG8gd2hhdCANCiAgICBkZWdyZWU8L1NQQU4+PC9GT05UPjwvUD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 QlI+PFNQQU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogICAg Y29sb3I9IzAwMDBmZj5bJmx0O1JhbWcmZ3Q7XSZuYnNwOyBUaGlzIG5lZWRzIHRvIGJlIA0KICAg IGRpc2N1c3NlZC48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PiZuYnNwOzwvU1BBTj4yLiBIQTxTUEFOIA0KICAg IGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQogICAgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICAgIHNpemU9Mj48L0ZPTlQ+PEJSPjxTUEFOIGNsYXNzPTcxMzM2NDUxMy0xOTA0 MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+WyZsdDtSYW1nJmd0O10m bmJzcDsgQ29tbW9ubHkgdXNlZCBtZWNoYW5pc20gYXJlIENFLUNFIGFuZCBpdHMgDQogICAgb3V0 c2lkZSB0aGUgc2NvcGUuIEJ1dCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBwcm90b2Nv bCANCiAgICBjYW48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9 IzAwMDBmZj5hY2NvbXVkYXRlIGJvdGggRkUtQ0UgYW5kIGFsc28gQ0UtQ0UgKGFuZCBub3Qgc3Vy ZSBvZiBGRS1GRSANCiAgICBzY2VuYXJpbydzIC0gdHlwaWNhbGx5IGRvbmUgaW4gaGFyZHdhcmUp LjwvRk9OVD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBjbGFzcz03 MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PiZuYnNwOzwvU1BBTj4zLiBDYXBhYmlsaXR5IA0K ICAgIEV4Y2hhbmdlLCBGRU0vQ0VNPC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjQuYS4gUHJvdG9j b2wgDQogICAgTWVzc2FnZXM8L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+NC5iLiBQcm90b2NvbCAN CiAgICBTY2VuYXJpb3M8L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+NC5jLiBDb21tb24gDQogICAg SGVhZGVyPC9TUEFOPjwvRk9OVD48L1A+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4N CiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 L0ZPTlQ+PEJSPjxTUEFOIA0KICAgIGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmY+WyZsdDtSYW1nJmd0O10mbmJzcDsgDQogICAgTWF5IGJlIHJl dmVyc2UgdGhlIG9yZGVyLiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogICAg Y29sb3I9IzAwMDBmZj5hLiBNZXNzYWdlIHR5cGVzIGFuZCBvdmVydmlldzwvRk9OVD48L1NQQU4+ PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBjbGFzcz03MTMzNjQ1MTMtMTkwNDIw MDQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmPmIuIENvbW1vbiBoZWFkZXI8 L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9NzEz MzY0NTEzLTE5MDQyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogICAgY29sb3I9IzAwMDBmZj5jLiBQ cm90b2NvbCBNRXNzYWdlIHN0cnVjdHVyZTwvRk9OVD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1Bcmlh bCANCiAgICBjb2xvcj0jMDAwMGZmPmQuIFByb3RvY29sIHNjZW5hcmlvcyAoIG9wZXJhdGlvbnMp PC9GT05UPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNzPTcx MzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+PC9G T05UPjwvU1BBTj4mbmJzcDs8L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNz PTcxMzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+ Jmx0O1JhbUcmZ3Q7IERlc2NyaWJlIHRoZSBIQSZuYnNwO3NwZWNpZmljIG9wZXJhdGlvbiwgc2Vj dXJpdHkgDQogICAgb3BlcmF0aW9uLCBUTUwgc3BlY2lmaWMgb3ByZWF0aW9uIGV0Yy4uPC9GT05U PjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGNsYXNzPTcxMzM2NDUx My0xOTA0MjAwND48L1NQQU4+PFNQQU4gDQogICAgY2xhc3M9NzEzMzY0NTEzLTE5MDQyMDA0PiZu YnNwOzwvU1BBTj41LiBTdXBwb3J0IGZvciBWZW5kb3IgDQogICAgZnVuY3Rpb25zPC9TUEFOPjwv Rk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JyI+Ni4gTWFzdGVyLVNsYXZlIG9yIA0KICAgIFBlZXItdG8tUGVlciBtb2RlbDxCUj48 U1BBTiBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xv cj0jMDAwMGZmPjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogICAgY2xh c3M9NzEzMzY0NTEzLTE5MDQyMDA0PjwvU1BBTj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAg ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BB TiANCiAgICBjbGFzcz03MTMzNjQ1MTMtMTkwNDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBj b2xvcj0jMDAwMGZmPlJlZ2FyZHM8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxTUEFO IA0KICAgIGNsYXNzPTcxMzM2NDUxMy0xOTA0MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNv bG9yPSMwMDAwZmY+UmFtZzwvRk9OVD4mbmJzcDs8L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQog ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQ QU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyciPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkxldHMgZ2V0IHRoZSBiYWxsIA0KICAg IHJvbGxpbmeFPC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPVdpbmdkaW5ncyBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5ncyI+Sjwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog QXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogQXJpYWwiPnJlZ2FyZHM8L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Ib3JtdXpkPC9TUEFOPjwvRk9O VD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxT UEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_0109_01C4265F.77B27830-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 12:22:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21006 for ; Mon, 19 Apr 2004 12:22:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbU8-0006DH-KL for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 12:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JGJ4Ix023872 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 12:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbHc-0002JA-KH for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 12:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19218 for ; Mon, 19 Apr 2004 12:06:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbHb-0003kS-Be for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:06:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbGi-0003Xj-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:05:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFbFv-0003Kn-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:04:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbBl-00017x-UA; Mon, 19 Apr 2004 12:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFb5x-0008N7-6R for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 11:54:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18136 for ; Mon, 19 Apr 2004 11:54: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 1BFb5v-0000iY-Vc for forces-protocol@ietf.org; Mon, 19 Apr 2004 11:54:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFb4x-0000VT-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 11:53:04 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BFb41-0000CM-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 11:52:06 -0400 Received: from wwm1 (unverified [219.82.188.103]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 20 Apr 2004 00:04:20 +0800 Message-ID: <011701c42625$c03300f0$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> <1082224260.1039.59.camel@jzny.localdomain> <1082375332.424.98.camel@jzny.localdomain> Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 23:48:24 +0800 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 Hi Jamal, I'm trying to propose some more of my ideas on the TML-PL as below, hoping to find the difference between us. Actually now what confuse me the most is where in hell is the difference between our ideas. Pls excuse me that i just try to rush out something, which therefore is very very incomplete. I think the description for the TML model (take TML at FE side as an e.g. first) may include following items: 1. TML capability From the protocol layer, this item looks as an FE capability attribute, which can be queried by CE. TML capability may include elements like: . Connection ID . Connection Type, such as TCP, UDP, IP, TIPC, etc. . Connection Capability, such as bandwidth, etc. . Allowed/Supported Connection QoS policy (or Congestion Control Policy) . (more TBD) Note that, CEM and FEM act only at the TML capability layer, that is, what CEM and FEM do is only limited to setup enough capability for PL to use. For e.g., the Connection ID will be assigned by FEM, therefore PL will not pay any attention to things like connection physical addresses. The TML capability may change even after it has been setup first by CEM and FEM. The TML event described below will be responsible to report such changes. Also note that the TML capability at the FE side can surely be queried by CE, while for FE itself, we always suppose it surely know everything about the TML, therefoe PL in the FE will know all these capability without any information exchange between PL and TML in the FE. 2. TML attributes There are several TML attributes, by which CE and PL at the FE side can use the TML resources. 1) Attribute for TML usage policy This is actually an attribute to tell FE how to use the TML connections based on the TML capability. It may include information like: . Connection ID to use . Connection QoS policy . Connection fail policy . (more TBD) The attribute is to tell things like 'for message type xx(or just the response to this message), use connection xx with connection QoS policy xx'. 2) (more TBD) 3. TML event The TML event is usually used to report the TML capability change, which also include the failover of connections. Jamal, what I wrote above actually also tried to answer your questions in your reply below to Avri.I have been trying to understand your idea all the time. I'm not sure if we have a very basic different viewpoint on TML, that is, it seems you may more like TMLs both at CE and FE side be defined universally, while I (also Hormuzd, Avri, etc) may only pay attention to the TML at the FE side, because we may think that the definition of TML at CE side is out of the scope of ForCES protocol. Another difference may be that you seems like to have TML in FE also be able to be controlled by FE itself, while we consider TML control mainly based on master-slave mode, that is, TML at FE side is controlled by CE. Pls excuse me if i misunderstand your idea. If it is, I suppose we may need to discuss the architecture first instead of using API or not. Hence, I also suggest we may start your proposed "expected architecture' topic by defining a model for TML first, because when we try to model TML, we may have things become more clear. I'm now thinking about how the TML model would look like. Maybe several days later I can post something on it. Sincerely, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > On Mon, 2004-04-19 at 06:23, avri@acm.org wrote: > > On 17 apr 2004, at 13.51, Jamal Hadi Salim wrote: > > > > > I am finding it very hard to say we can do multiple TMLs and not say > > > how > > > a Forces PL can use them. > > > > I am not in favor of trying to create an PL-TML api. I personally > > think how these things are connected is an implementation issue. > > > > That is why GSMP took the encapsulation route. What needed to be > > defined was what went out on the wire. How the GSMP messages got to > > the encapsulator and what if any communication existed between them was > > left to the implementer - I didn't expect that part of the system to > > ever be an open interface. And I don't expect it to be in the ForCES > > case either. > > There are really two things as i see it. > > One is the media encapsulation service which you defined in that RFC. > > The second is the transport services (which is more contentious in > Forces).In the GSMP case the simplicity was a result of choosing a > single transport (example TCP over IP). > In our case i may want to run both TCP and UDP and want to use different > features of each transport protocol. How do i signal selectively to the > TML what features to use? > I really dont want the API either, but i am not seeing a way out. > We could create classes templates for each TML, example "use transport x > always when you want reliability" - but at the end that would be the > same as creating APIs in terms of workload. > cheers, > jamal > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 12:39:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22396 for ; Mon, 19 Apr 2004 12:39:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbff-00015I-Bc for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 12:30:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JGUxur004161 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 12:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbd2-0000Gp-1d for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 12:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21708 for ; Mon, 19 Apr 2004 12:28: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 1BFbd0-0001v4-HA for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:28:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbcE-0001gK-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:27:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFbbO-0001QB-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 12:26:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbW5-0006wW-6d; Mon, 19 Apr 2004 12:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbOY-0004cS-Jh for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 12:13:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20451 for ; Mon, 19 Apr 2004 12:13: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 1BFbOX-0005sP-6w for forces-protocol@ietf.org; Mon, 19 Apr 2004 12:13:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbNg-0005dT-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 12:12:24 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BFbMZ-0005HP-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 12:11:16 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041909144391:3215 ; Mon, 19 Apr 2004 09:14:43 -0700 Subject: RE: [Forces-protocol] List of issues for discussion From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: hormuzd.m.khosravi@intel.com, forces-protocol@ietf.org In-Reply-To: References: Organization: Znyx Networks Message-Id: <1082391072.1071.32.camel@jzny.localdomain> 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 04/19/2004 09:14:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/19/2004 09:14:46 AM, Serialize complete at 04/19/2004 09:14:46 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Apr 2004 12:11:13 -0400 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 Content-Transfer-Encoding: 7bit On Mon, 2004-04-19 at 09:52, ram.gopal@nokia.com wrote: > In future, please discuss all the issues on the list. The discussion had nothing to do with the list. The result was - thats why it was posted. > regarding this work item - comments are inline. > > Regards > Ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext > Khosravi, Hormuzd M > Sent: Monday, April 19, 2004 1:18 AM > To: forces-protocol@ietf.org > Subject: [Forces-protocol] List of issues for discussion > > > > Hi All > > > > Weiming started a private discussion with Jamal and myself > over the weekend regarding renewing of protocol drafts and it > has turned into a useful discussion of how to make some quick > progress on the protocol. Both Jamal and myself are concerned > that we have Not made good progress so far on this team. > > > > Here is a list of issues to be discussed as suggested by > Jamal. > > > > 0. Expected architecture/use cases: > > I believe this is important to remove the major stumbling > issue - > > the different views of implementations. > > > > i) What each of (PL and TML) does; we could steal from Davids > url. > > > > ii) scenario layouts of processing. > > ii-I) joining and leaving; CEM/FEM role etc > > ii-II) Lets pick one or two simple examples (maybe just IPV4 > forwarding > > with OSPF). > > > > > > What's the reason for picking this two? > > This seems to be the simplest one. You can pick something else. > > 1. TML > > #0 above should help ease this. > > a) roles of TML vs PL. > > b) services provided by TML to PL > > i) what are they? > > ii) should the services be controllable by the PL? > > iii) if yes, to what degree > > > [] This needs to be discussed. yes. The whole TML needs discussion. > 2. HA > > > [] Commonly used mechanism are CE-CE and its outside > the scope. But we need to make sure that the protocol can > accomudate both FE-CE and also CE-CE (and not sure of FE-FE > scenario's - typically done in hardware). > I posted a little text a while back with some details on several alternatives. In there i mention what i thought was a part the protocol plays. > > 3. Capability Exchange, FEM/CEM > > 4.a. Protocol Messages > > 4.b. Protocol Scenarios > > 4.c. Common Header > > > [] May be reverse the order. > > a. Message types and overview > > b. Common header > > c. Protocol MEssage structure > > d. Protocol scenarios ( operations) > > Sounds to me like b, c,a, d is the right sequence. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 13:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26891 for ; Mon, 19 Apr 2004 13:46:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFclO-0007qz-6C for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 13:40:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JHew43030185 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 13:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcez-0006SM-Rz for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 13:34:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26026 for ; Mon, 19 Apr 2004 13:34:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFcex-0002lW-Nq for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 13:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFcdy-0002W6-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 13:33:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFcdH-0002Hz-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 13:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcVz-00059A-OM; Mon, 19 Apr 2004 13:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcPW-0003fn-6i for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 13:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24709 for ; Mon, 19 Apr 2004 13:18:18 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFcPU-0006AB-5S for forces-protocol@ietf.org; Mon, 19 Apr 2004 13:18:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFcOX-0005wf-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 13:17:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BFcO9-0005ik-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 13:16:57 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JHGOm17980; Mon, 19 Apr 2004 20:16:24 +0300 (EET DST) X-Scanned: Mon, 19 Apr 2004 20:16:18 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3JHGIsF001745; Mon, 19 Apr 2004 20:16:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 004qWwib; Mon, 19 Apr 2004 20:15:56 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3JHErs03433; Mon, 19 Apr 2004 20:14:54 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Apr 2004 12:14:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] List of issues for discussion Message-ID: Thread-Topic: [Forces-protocol] List of issues for discussion Thread-Index: AcQmKiGhoC9vFINBQy29bM3+fjL41QAB1zPg To: Cc: , X-OriginalArrivalTime: 19 Apr 2004 17:14:10.0976 (UTC) FILETIME=[BB3C4A00:01C42631] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 13:14:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Jamal, all, > -----Original Message----- > From: ext Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Monday, April 19, 2004 12:11 PM > To: Gopal Ram (Nokia-NRC/Boston) > Cc: hormuzd.m.khosravi@intel.com; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] List of issues for discussion >=20 >=20 >=20 > On Mon, 2004-04-19 at 09:52, ram.gopal@nokia.com wrote: > =20 > > In future, please discuss all the issues on the list. >=20 > The discussion had nothing to do with the list.=20 > The result was - thats why it was posted. >=20 >=20 > > regarding this work item - comments are inline. > > =20 > > Regards > > Ramg > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext > > Khosravi, Hormuzd M > > Sent: Monday, April 19, 2004 1:18 AM > > To: forces-protocol@ietf.org > > Subject: [Forces-protocol] List of issues for discussion > > =20 > > =20 > > =20 > > Hi All > > =20 > > =20 > > =20 > > Weiming started a private discussion with Jamal and myself > > over the weekend regarding renewing of protocol=20 > drafts and it > > has turned into a useful discussion of how to make=20 > some quick > > progress on the protocol. Both Jamal and myself are=20 > concerned > > that we have Not made good progress so far on this team. > > =20 > > =20 > > =20 > > Here is a list of issues to be discussed as suggested by > > Jamal. > > =20 > > =20 > > =20 > > 0. Expected architecture/use cases: > > =20 > > I believe this is important to remove the major stumbling > > issue - > > =20 > > the different views of implementations. > > =20 > > =20 > > =20 > > i) What each of (PL and TML) does; we could steal=20 > from Davids > > url. > > =20 > > =20 > > =20 > > ii) scenario layouts of processing.=20 > > =20 > > ii-I) joining and leaving; CEM/FEM role etc > > =20 > > ii-II) Lets pick one or two simple examples (maybe just IPV4 > > forwarding > > =20 > > with OSPF). > > =20 > > =20 > > =20 > > > > =20 > > What's the reason for picking this two? > > =20 > > >=20 > This seems to be the simplest one. You can pick something else. >=20 > > =20 > > 1. TML > > =20 > > #0 above should help ease this. > > =20 > > a) roles of TML vs PL. > > =20 > > b) services provided by TML to PL > > =20 > > i) what are they?=20 > > =20 > > ii) should the services be controllable by the PL? > > =20 > > iii) if yes, to what degree > > =20 > > =20 > > [] This needs to be discussed. >=20 > yes. The whole TML needs discussion. >=20 > > 2. HA=20 > > =20 > > =20 > > [] Commonly used mechanism are CE-CE and its outside > > the scope. But we need to make sure that the protocol can > > accomudate both FE-CE and also CE-CE (and not sure of FE-FE > > scenario's - typically done in hardware). > > =20 >=20 > I posted a little text a while back with some details on several > alternatives. In there i mention what i thought was a part=20 > the protocol > plays. May be during this discussion - i had internal email problems - let me = go to archive and pull out. > =20 >=20 > > =20 > > 3. Capability Exchange, FEM/CEM > > =20 > > 4.a. Protocol Messages > > =20 > > 4.b. Protocol Scenarios > > =20 > > 4.c. Common Header > > =20 > > =20 > > [] May be reverse the order.=20 > > =20 > > a. Message types and overview > > =20 > > b. Common header > > =20 > > c. Protocol MEssage structure > > =20 > > d. Protocol scenarios ( operations) > > =20 > > =20 >=20 > Sounds to me like b, c,a, d is the right sequence. >=20 The section of a is a overview about types of message and its a head = start for the complete section and it has nothing going there... this is to give a flow of the = section. regards ramg > cheers, > jamal >=20 >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 16:57:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09685 for ; Mon, 19 Apr 2004 16:57:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfjP-0003Db-OF for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 16:51:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKp7Cc012366 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 16:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfZ6-0001gz-Jo for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08573 for ; Mon, 19 Apr 2004 16:40: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 1BFfZ4-0001Wx-Lb for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:40:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfYA-0001I5-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:39:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfXh-00013A-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfPx-0007j4-7C; Mon, 19 Apr 2004 16:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfJx-0006RY-7T for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 16:24:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07471 for ; Mon, 19 Apr 2004 16:24: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 1BFfJv-0005MS-9N for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:24:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfIh-00054u-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:23:32 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BFfHv-0004nD-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:22:43 -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 i3JKM98L026976; Mon, 19 Apr 2004 20:22:09 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 i3JKIinx031532; Mon, 19 Apr 2004 20:22:11 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 M2004041913220405032 ; Mon, 19 Apr 2004 13:22:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 13:22:04 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] List of issues for discussion Message-ID: <468F3FDA28AA87429AD807992E22D07EABCF04@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] List of issues for discussion Thread-Index: AcQmKPZqE+HcsNJ5ThKZsK03FiDQXwAIuJ3g From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 19 Apr 2004 20:22:04.0865 (UTC) FILETIME=[FAFF3B10:01C4264B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 13:22:03 -0700 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 Content-Transfer-Encoding: quoted-printable Ram, I agree with Jamal's comment below on the private emails. Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Monday, April 19, 2004 9:11 AM To: ram.gopal@nokia.com On Mon, 2004-04-19 at 09:52, ram.gopal@nokia.com wrote: =20 > In future, please discuss all the issues on the list. The discussion had nothing to do with the list.=20 The result was - thats why it was posted. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 19 17:12:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10484 for ; Mon, 19 Apr 2004 17:12:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfpG-0004gc-DP for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 16:57:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JKvAcF018009 for forces-protocol-archive@odin.ietf.org; Mon, 19 Apr 2004 16:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfmT-0003zD-UA for forces-protocol-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 16:54:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09479 for ; Mon, 19 Apr 2004 16:54: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 1BFfmR-00056Y-RV for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:54:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFflS-0004qb-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:53:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfkV-0004aZ-00 for forces-protocol-web-archive@ietf.org; Mon, 19 Apr 2004 16:52:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfaa-00022m-HB; Mon, 19 Apr 2004 16:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfSB-0008CM-Au for forces-protocol@optimus.ietf.org; Mon, 19 Apr 2004 16:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08058 for ; Mon, 19 Apr 2004 16:33:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFfS9-0007c6-9V for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfRD-0007NK-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:32:20 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BFfQG-00077X-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 16:31:20 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041913344359:3546 ; Mon, 19 Apr 2004 13:34:43 -0700 Subject: Re: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <011701c42625$c03300f0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EA385D5@orsmsx408.jf.intel.com> <1082224260.1039.59.camel@jzny.localdomain> <1082375332.424.98.camel@jzny.localdomain> <011701c42625$c03300f0$020aa8c0@wwm1> Organization: Znyx Networks Message-Id: <1082406672.9601.90.camel@jzny.localdomain> 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 04/19/2004 01:34:43 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/19/2004 01:34:50 PM, Serialize complete at 04/19/2004 01:34:50 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 19 Apr 2004 16:31:13 -0400 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 Content-Transfer-Encoding: 7bit Weiming, On Mon, 2004-04-19 at 11:48, Weiming Wang wrote: > Hi Jamal, > > I'm trying to propose some more of my ideas on the TML-PL as below, hoping to > find the difference between us. Actually now what confuse me the most is where > in hell is the difference between our ideas. Pls excuse me that i just try to > rush out something, which therefore is very very incomplete. Thanks for putting this effort. As long as we have somewhere to start, things can be refined. > I think the description for the TML model (take TML at FE side as an e.g. first) > may include following items: > > 1. TML capability > From the protocol layer, this item looks as an FE capability attribute, which > can be queried by CE. yes. > TML capability may include elements like: > . Connection ID Do you mean the PID? There could be multiple connections per TML. It would still be useful to have connection IDs but only for (TML)internal use to just track multiple connections whereas PID has a protocol level semantic. > . Connection Type, such as TCP, UDP, IP, TIPC, etc. > . Connection Capability, such as bandwidth, etc. > . Allowed/Supported Connection QoS policy (or Congestion Control Policy) > . (more TBD) Would you say that the above is valid for each connection as opposed for each TML? > Note that, CEM and FEM act only at the TML capability layer, that is, what CEM > and FEM do is only limited to setup enough capability for PL to use. For e.g., > the Connection ID will be assigned by FEM, therefore PL will not pay any > attention to things like connection physical addresses. The TML capability may > change even after it has been setup first by CEM and FEM. The TML event > described below will be responsible to report such changes. > Note that the simplest xEM is a config file read on startup. But i certainly agree that the scope of the xEM is the TML. Also note that to be precise, the config actually happens from CE(TML at CE?)->CEM->FEM->TML(at FE) Infact the first thing probably the config should do is say "use TML #3" > Also note that the TML capability at the FE side can surely be queried by CE, Sure. > while for FE itself, we always suppose it surely know everything about the TML, > therefoe PL in the FE will know all these capability without any information > exchange between PL and TML in the FE. Now you loose me. How will the PL in the FE know about all these details? Maybe you mean it wont care about these details? > 2. TML attributes > > There are several TML attributes, by which CE and PL at the FE side can use the > TML resources. > I can see CE using this; how does FE-PL use it? Unless you want to have the FE-PL be smart enough to make transport decisions? > 1) Attribute for TML usage policy > This is actually an attribute to tell FE how to use the TML connections based on > the TML capability. It may include information like: > . Connection ID to use > . Connection QoS policy > . Connection fail policy > . (more TBD) Same questions as in #1 > The attribute is to tell things like 'for message type xx(or just the response > to this message), use connection xx with connection QoS policy xx'. This is a hard one. It is best to not even exchange such details and have them hardcoded within the TML. I am assuming that if a TML has been defined we already know what to do when we want to reliably deliver a message (i.e TML has the knowledge embedded in it) > 2) (more TBD) > > 3. TML event > The TML event is usually used to report the TML capability change, which also > include the failover of connections. Event is needed, we can datafill that later. > Jamal, what I wrote above actually also tried to answer your questions in your > reply below to Avri.I have been trying to understand your idea all the time. I'm > not sure if we have a very basic different viewpoint on TML, that is, it seems > you may more like TMLs both at CE and FE side be defined universally, TMLs i dont see as being very different whether they reside at the CE or FE in terms of overall behavior. The PLs would behave differently for sure. > while I > (also Hormuzd, Avri, etc) may only pay attention to the TML at the FE side, > because we may think that the definition of TML at CE side is out of the scope > of ForCES protocol. what is out of scope is a CE-TML talking to another CE TML (or FE-FE). > Another difference may be that you seems like to have TML > in FE also be able to be controlled by FE itself, while we consider TML control > mainly based on master-slave mode, that is, TML at FE side is controlled by CE. Lets take an example of CE-PL sending a message that requires a reliable delivery; assume we have a UDP and TCP connection in the TML: I would like to send such a message from the PL level via the TML with some indication to the TML that this message needs to be delivered reliably (obviously via TCP in this example). Clearly it is cleaner for the PL to have no clue that the TPC connection is being used. 2-3 ways i could do it: 1) call a speacial function[1] which is translated by the CE-TML to mean send via TCP OR 2) call a generic function[1] with flags turned to say "reliability needed" and the TML translates this to mean send via TCP. OR 3) just send the Forces Messages with some of its flags turned on to mean reliability on and such a message is translated to mean send via TCP. #3 may be the API-avoidance scheme. > Pls excuse me if i misunderstand your idea. If it is, I suppose we may need to > discuss the architecture first instead of using API or not. Hence, I also > suggest we may start your proposed "expected architecture' topic by defining a > model for TML first, because when we try to model TML, we may have things become > more clear. I'm now thinking about how the TML model would look like. Maybe > several days later I can post something on it. Lets start with the above example i have and see if it is resolvable. cheers, jamal [1] could be a protocol message in the PL-TML interface _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 00:30:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05907 for ; Tue, 20 Apr 2004 00:30:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmps-0002Ah-NK for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 00:26:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K4QGmb008340 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 00:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmhf-0000Kd-DF for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 00:17:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05244 for ; Tue, 20 Apr 2004 00:17: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 1BFmhc-0000Ol-Vs for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:17:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmgh-00007h-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:16:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFmfk-0007fZ-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:15:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmWK-0005zs-Oe; Tue, 20 Apr 2004 00:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmS8-0004k3-E4 for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 00:01:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04565 for ; Tue, 20 Apr 2004 00:01: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 1BFmS6-0004An-1t for forces-protocol@ietf.org; Tue, 20 Apr 2004 00:01:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmRB-0003vA-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 00:00:46 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BFmQG-0003QC-00 for forces-protocol@ietf.org; Mon, 19 Apr 2004 23:59:48 -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 i3K3xD8L026290; Tue, 20 Apr 2004 03:59:13 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 i3K3vqL6031152; Tue, 20 Apr 2004 03:58:14 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 M2004041920590930421 ; Mon, 19 Apr 2004 20:59:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 20:59:09 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EABD38A@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA Thread-Index: AcQmBaMK5BsNOc/8Rbu+owWoBPYQRwAhF46w From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 20 Apr 2004 03:59:09.0814 (UTC) FILETIME=[D58A5960:01C4268B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 20:59:09 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, I see your point of view a little better now and I think I know where the confusion is :) Let me try and explain.... In case of ForCES, since we have said that we have different requirements for control and data or lets just say for different messages, you think we need to have some API to convey this information from the PL to the TML. This is true but the API is more of an implementation issue. The way I see this information being conveyed is simply using the ForCES Common Header. For example, if we decide that Messages A-X need Reliability and Messages Y-Z need unreliability, the header the MessageType field which will convey this info to the TML. Also, if you want to specify that this message has to be unicast to FE 1 the FE ID field in the header will have this information. Now whether we have an API between PL and TML of the form, EncapsulatePLMessage(message*) or Send(buffer), is implementation details. So what we need to do is define the requirements or services for different messages or message categories such as Data and Control and the TML designers will try to satisfy those requirements. Now, I don't expect that there will be multiple ways of providing the same service for a particular interconnect-specific TML...for example, the IP TML might decide to use TCP or SCTP to provide Reliable/CC aware service, but it will not use both. However, we don't need to get into this discussion, since we are not on that team :) I hope this helps...I think we are saying the same thing but in different ways. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim On Mon, 2004-04-19 at 06:23, avri@acm.org wrote: > On 17 apr 2004, at 13.51, Jamal Hadi Salim wrote: >=20 > > I am finding it very hard to say we can do multiple TMLs and not say > > how > > a Forces PL can use them. >=20 > I am not in favor of trying to create an PL-TML api. I personally=20 > think how these things are connected is an implementation issue. >=20 > That is why GSMP took the encapsulation route. What needed to be=20 > defined was what went out on the wire. How the GSMP messages got to=20 > the encapsulator and what if any communication existed between them was=20 > left to the implementer - I didn't expect that part of the system to=20 > ever be an open interface. And I don't expect it to be in the ForCES=20 > case either. There are really two things as i see it. One is the media encapsulation service which you defined in that RFC. The second is the transport services (which is more contentious in Forces).In the GSMP case the simplicity was a result of choosing a single transport (example TCP over IP). In our case i may want to run both TCP and UDP and want to use different features of each transport protocol. How do i signal selectively to the TML what features to use? I really dont want the API either, but i am not seeing a way out. We could create classes templates for each TML, example "use transport x always when you want reliability" - but at the end that would be the same as creating APIs in terms of workload. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 00:36:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06348 for ; Tue, 20 Apr 2004 00:36:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmuI-0003H6-1P for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 00:31:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3K4Uoxp012582 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 00:30:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmrN-0002OU-5E for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 00:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05808 for ; Tue, 20 Apr 2004 00:27:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFmrK-0002wB-L0 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmqM-0002gY-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:26:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFmph-0002RE-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 00:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmh0-00009V-Q2; Tue, 20 Apr 2004 00:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFmbu-00074a-Dc for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 00:11:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05032 for ; Tue, 20 Apr 2004 00: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 1BFmbr-0006he-PW for forces-protocol@ietf.org; Tue, 20 Apr 2004 00:11:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFmb2-0006SM-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 00:10:56 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BFmaQ-0006C7-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 00:10:18 -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 i3K49OTc031655; Tue, 20 Apr 2004 04:09:24 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 i3K488cQ003958; Tue, 20 Apr 2004 04:08:17 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 M2004041921091325491 ; Mon, 19 Apr 2004 21:09:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 21:09:13 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EABD391@orsmsx408.jf.intel.com> Thread-Topic: PL<-->TML:: topic 1 Thread-Index: AcQmUDZ2tTa0AvqpRmqVXhg17XTi+AAPGEew From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 20 Apr 2004 04:09:13.0130 (UTC) FILETIME=[3D2510A0:01C4268D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: PL<-->TML:: topic 1 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 19 Apr 2004 21:09:12 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Lets take an example of CE-PL sending a message that requires a reliable delivery; assume we have a UDP and TCP connection in the TML: I would like to send such a message from the PL level via the TML with some indication to the TML that this message needs to be delivered reliably (obviously via TCP in this example). Clearly it is cleaner for the PL to have no clue that the TPC connection is being used. 2-3 ways i could do it: 1) call a speacial function[1] which is translated by the CE-TML to mean send via TCP OR 2) call a generic function[1] with flags turned to say "reliability needed" and the TML translates this to mean send via TCP. OR 3) just send the Forces Messages with some of its flags turned on to mean reliability on and such a message is translated to mean send via TCP. #3 may be the API-avoidance scheme. [HK] Exactly, #3 is what I was explaining in my last email that I just sent out. (Use fields/flags in the Common Header to correspond to a transport service e.g. TCP connection in the TML).=20 I think we are on the same page now, Hopefully this issue is resolved :) Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 12:12:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00169 for ; Tue, 20 Apr 2004 12:12:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxcz-0007M6-F3 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 11:57:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KFvfpT028270 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 11:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwmL-000394-73 for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:04:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23860 for ; Tue, 20 Apr 2004 11:03:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwmI-00036j-I1 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:03:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwlK-0002oV-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:02:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFwkS-0002XJ-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:01:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwSj-0004Mf-4S; Tue, 20 Apr 2004 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwOw-0003Fr-MM for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 10:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22230 for ; Tue, 20 Apr 2004 10:39:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwOu-00048S-4f for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:39:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwNu-0003qT-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:38:03 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1BFwMt-0003Kh-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:36:59 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3KEZ3Wn125586; Tue, 20 Apr 2004 14:35:03 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 i3KEZ22F056830; Tue, 20 Apr 2004 16:35:02 +0200 Received: from zurich.ibm.com (dhcp69-40.zurich.ibm.com [9.4.69.40]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA27238; Tue, 20 Apr 2004 16:33:36 +0200 Message-ID: <408534BF.60009@zurich.ibm.com> From: Robert Haas Organization: IBM Research Lab 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 To: "Khosravi, Hormuzd M" CC: hadi@znyx.com, Weiming Wang , forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 References: <468F3FDA28AA87429AD807992E22D07EABD391@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07EABD391@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id i3KEZ3Wn125586 Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 16:33:35 +0200 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 Content-Transfer-Encoding: quoted-printable On the reliability example: remember that ForCES-level reliability is=20 somewhat orthogonal to transport-level reliability. At the ForCES level,=20 I want to get an ACK back from a FE to confirm that it could update a=20 firewall rule successfully, for instance. So if I tag my ForCES message with "reliability enabled", the TML COULD=20 choose to send it over TCP, but this is not mandatory, as using TCP=20 alone is not going to be sufficient to ensure reliable processing at the=20 FE. Actually, the TML could choose UDP, as potential retransmissions=20 anyay need to be taken care of at the PL level as well. Or do you have different views ? Please explain. Regards, -Robert Khosravi, Hormuzd M wrote: >Hi Jamal, > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > >Lets take an example of CE-PL sending a message that requires a reliable >delivery; assume we have a UDP and TCP connection in the TML: > >I would like to send such a message from the PL level via the TML with >some indication to the TML that this message needs to be delivered >reliably (obviously via TCP in this example). Clearly it is cleaner for >the PL to have no clue that the TPC connection is being used. >2-3 ways i could do it: >1) call a speacial function[1] which is translated by the CE-TML to mean >send via TCP >OR >2) call a generic function[1] with flags turned to say "reliability >needed" and the TML translates this to mean send via TCP. >OR >3) just send the Forces Messages with some of its flags turned on to >mean reliability on and such a message is translated to mean send via >TCP. > >#3 may be the API-avoidance scheme. > >[HK] Exactly, #3 is what I was explaining in my last email that I just >sent out. (Use fields/flags in the Common Header to correspond to a >transport service e.g. TCP connection in the TML).=20 > >I think we are on the same page now, Hopefully this issue is resolved :) > > >Regards >Hormuzd > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =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 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 12:35:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01599 for ; Tue, 20 Apr 2004 12:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxgj-0008D9-BW for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KG1Xav031559 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx5c-0001Cw-Mj for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:23:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25058 for ; Tue, 20 Apr 2004 11:23: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 1BFx5b-0000qq-O6 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:23:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx4c-0000ZH-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:22:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFx3h-0000I4-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:21:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlG-0002Sg-Sk; Tue, 20 Apr 2004 11:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwZd-0006gt-QV for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 10:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22957 for ; Tue, 20 Apr 2004 10:50: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 1BFwZb-0007Hj-E6 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwYa-00070h-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:49:05 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BFwXg-0006j9-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:48:08 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042007513535:4490 ; Tue, 20 Apr 2004 07:51:35 -0700 Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: avri@acm.org, forces-protocol@ietf.org, Jon Maloy In-Reply-To: <468F3FDA28AA87429AD807992E22D07EABD38A@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EABD38A@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1082472484.1088.25.camel@jzny.localdomain> 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 04/20/2004 07:51:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/20/2004 07:51:37 AM, Serialize complete at 04/20/2004 07:51:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 20 Apr 2004 10:48:05 -0400 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 Content-Transfer-Encoding: 7bit Hi Hormuzd, To reword #3 to provide context: JHS>3)(PL) to just send the Forces Messages with some of its flags turned on to JHS>mean reliability on and such a message is translated (by TML)to mean send via JHS> a reliable means. JHS> JHS#3 may be the API-avoidance scheme. > > [HK] Exactly, #3 is what I was explaining in my last email that I just > sent out. (Use fields/flags in the Common Header to correspond to a > transport service e.g. TCP connection in the TML). I have no issues i can think of right top of my head on this. I am CCing Jon Maloy since TIPC is being proposed as a TML to get his PoV. Jon please chip in here. So the above implies that the TML _infers_ what to do with the packet based on the Forces header or (no choice but to get into implementation details) theres an abstraction that takes a look at those headers and makes the correct TML calls. I would prefer to put the burden on the TMLs instead of implementing something that remaps to the TML. In other words this is shaping the requirements for the TML. [Of course the best method is for PL to explicitly tell TML what it wants - so this is second best. The pro for this is reduced complexity]. I think the moral to all this discussion is that we now must make sure that if we are going in the path of inference that the main header carries sufficient information to be usable by the TML. So it was not a total waster of time to go through this pain ;-> More below On Mon, 2004-04-19 at 23:59, Khosravi, Hormuzd M wrote: > Jamal, > > I see your point of view a little better now and I think I know where > the confusion is :) > > Let me try and explain.... > > In case of ForCES, since we have said that we have different > requirements for control and data or lets just say for different > messages, you think we need to have some API to convey this information > from the PL to the TML. This is true but the API is more of an > implementation issue. The way I see this information being conveyed is > simply using the ForCES Common Header. Lets call this technique inference-by-TML > For example, if we decide that Messages A-X need Reliability and > Messages Y-Z need unreliability, the header the MessageType field which > will convey this info to the TML. Also, if you want to specify that this > message has to be unicast to FE 1 the FE ID field in the header will > have this information. Now whether we have an API between PL and TML of > the form, > EncapsulatePLMessage(message*) or > Send(buffer), is implementation details. > This is fine with me. Lets say explicitly if we want to use inference-by-TML and we can move on. I would like to hear Weimings view. > So what we need to do is define the requirements or services for > different messages or message categories such as Data and Control and > the TML designers will try to satisfy those requirements. I think the standard protocol requirements we have should suffice. How they get signalled is the next step we should discuss. You seem to be saying by message type; i think the better way to do it is probably using flags > Now, I don't > expect that there will be multiple ways of providing the same service > for a particular interconnect-specific TML...for example, the IP TML > might decide to use TCP or SCTP to provide Reliable/CC aware service, > but it will not use both. However, we don't need to get into this > discussion, since we are not on that team :) Sure, we just treat the TML as a blackbox. The main header can signal what service we want out of the TML and the PL should be agnosric if that service is delivered over avio pigeons or ATCA data fabric. > I hope this helps...I think we are saying the same thing but in > different ways. I think we are getting close; from this we can derive more the requirements on the TML and what to go on the header. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 12:35:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01619 for ; Tue, 20 Apr 2004 12:35:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxgj-0008DW-OP for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KG1XYG031581 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 12:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFx5g-0001HX-Mr for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 11:24:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25069 for ; Tue, 20 Apr 2004 11:23:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFx5f-0000rO-QS for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFx4n-0000aP-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:22:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFx46-0000JW-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 11:21:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwlH-0002TA-Vp; Tue, 20 Apr 2004 11:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFwbX-0007On-Jd for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 10:53:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23096 for ; Tue, 20 Apr 2004 10:52:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFwbU-00001C-Vv for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:52:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFwab-0007YX-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:51:09 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BFwZe-0007I2-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 10:50:10 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042007533752:4493 ; Tue, 20 Apr 2004 07:53:37 -0700 Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas Cc: "Khosravi, Hormuzd M" , Weiming Wang , forces-protocol@ietf.org In-Reply-To: <408534BF.60009@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07EABD391@orsmsx408.jf.intel.com> <408534BF.60009@zurich.ibm.com> Organization: Znyx Networks Message-Id: <1082472607.1089.28.camel@jzny.localdomain> 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 04/20/2004 07:53:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/20/2004 07:53:39 AM, Serialize complete at 04/20/2004 07:53:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 20 Apr 2004 10:50:07 -0400 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 Content-Transfer-Encoding: 7bit On Tue, 2004-04-20 at 10:33, Robert Haas wrote: > On the reliability example: remember that ForCES-level reliability is > somewhat orthogonal to transport-level reliability. At the ForCES level, > I want to get an ACK back from a FE to confirm that it could update a > firewall rule successfully, for instance. > > So if I tag my ForCES message with "reliability enabled", the TML COULD > choose to send it over TCP, but this is not mandatory, as using TCP > alone is not going to be sufficient to ensure reliable processing at the > FE. Actually, the TML could choose UDP, as potential retransmissions > anyay need to be taken care of at the PL level as well. > Good point to consider again in terms of TML and header definition. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 13:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06504 for ; Tue, 20 Apr 2004 13:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyp5-0000hX-33 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHEFjP002687 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyU0-0007gk-T4 for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 12:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03520 for ; Tue, 20 Apr 2004 12:52: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 1BFyTz-0005WD-AO for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 12:52:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyT9-0005DO-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 12:51:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFySB-0004uR-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 12:50:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxqE-00051Q-1L; Tue, 20 Apr 2004 12:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxbW-00078u-9s for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 11:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28647 for ; Tue, 20 Apr 2004 11:56:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxbV-00048t-2t for forces-protocol@ietf.org; Tue, 20 Apr 2004 11:56:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxaT-0003nc-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 11:55:05 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BFxZQ-0003H2-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 11:54:01 -0400 Received: from wwm1 (unverified [219.82.168.238]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 20 Apr 2004 21:17:03 +0800 Message-ID: <001001c426d7$8b54a160$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EABD391@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 20:50:23 +0800 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 Hi Jamal, Hormuzd, Jamal, pls let me concentrate on your example first by replying this email firstly. ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi Jamal, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Lets take an example of CE-PL sending a message that requires a reliable delivery; assume we have a UDP and TCP connection in the TML: I would like to send such a message from the PL level via the TML with some indication to the TML that this message needs to be delivered reliably (obviously via TCP in this example). Clearly it is cleaner for the PL to have no clue that the TPC connection is being used. 2-3 ways i could do it: 1) call a speacial function[1] which is translated by the CE-TML to mean send via TCP OR 2) call a generic function[1] with flags turned to say "reliability needed" and the TML translates this to mean send via TCP. OR 3) just send the Forces Messages with some of its flags turned on to mean reliability on and such a message is translated to mean send via TCP. #3 may be the API-avoidance scheme. [HK] Exactly, #3 is what I was explaining in my last email that I just sent out. (Use fields/flags in the Common Header to correspond to a transport service e.g. TCP connection in the TML). I think we are on the same page now, Hopefully this issue is resolved :) [Weiming] Among the three schemes, I also more appreciate 3), but I just wonder if this is all for TML-PL, e.g., what then for congestion control, HA, etc? Basically, I think it is only a specific scheme for reliability. I think we now can only say that we have approved to use something like metadata/fields/flags for reliability control. Moreover, I think the scheme is also quite at the abstact level. We then may have to answer more questions as how we then define the 'reliability', how we can know the TML support such 'reliability', and what then if the TML can not supply enough capability for such 'reliability'? From these viepoints, I'm afraid we still need to use mechanisms like TML capability and TML attributes so as to properly configure the TML before we can actually use such metadata/fields in the protocol messages. I notice that Jamal seems to say such TML configuration is better to be left for CEM and FEM. If it is, then I think it may libarate our protocol team a lot. So, Hormuzd, what's your opinion? Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 13:30:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06598 for ; Tue, 20 Apr 2004 13:30:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFysA-00023P-RC for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:17:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHHQX3007890 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFybV-0002Og-9C for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 13:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04115 for ; Tue, 20 Apr 2004 13:00: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 1BFybT-00006j-Cj for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:00:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyaY-0007bo-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 12:59:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFyZi-0007L1-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 12:58:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyH5-0001Cm-6w; Tue, 20 Apr 2004 12:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxjS-0000wl-9G for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 12:04:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29380 for ; Tue, 20 Apr 2004 12:04: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 1BFxjR-0006nE-2z for forces-protocol@ietf.org; Tue, 20 Apr 2004 12:04:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxiT-0006So-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 12:03:22 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BFxh0-0005n9-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 12:01:51 -0400 Received: from wwm1 (unverified [219.82.168.238]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 21 Apr 2004 00:14:06 +0800 Message-ID: <014901c426f0$475b0350$020aa8c0@wwm1> From: "Weiming Wang" To: Cc: "Khosravi, Hormuzd M" , , References: <1082473916.1088.39.camel@jzny.localdomain> Subject: Re: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA] X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 23:58:08 +0800 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 Hi Jamal,Hormuzd, As said in my earlier mail, I'm ok with the scheme to use flags or inference of other fields in the protocol message to signal transmission requirements to TML layer, though I'm a little worry if this can meet all what we need, therefore I highly suggest we try to compose all possible flags and point out all that may be used for inference to see if it works well now (not later). We have actually said something on reliability (use a flag or use the message type as tip) and have already said somthing on multicast/broadcast, how about lets try to define or find out others then? Cheers, Weiming > From: Jamal Hadi Salim > Hi Hormuzd, > > To reword #3 to provide context: > > JHS>3)(PL) to just send the Forces Messages with some of its flags turned on to > JHS>mean reliability on and such a message is translated (by TML)to mean send via > JHS> a reliable means. > JHS> > JHS#3 may be the API-avoidance scheme. > > > > [HK] Exactly, #3 is what I was explaining in my last email that I just > > sent out. (Use fields/flags in the Common Header to correspond to a > > transport service e.g. TCP connection in the TML). > > I have no issues i can think of right top of my head on this. I am CCing Jon Maloy > since TIPC is being proposed as a TML to get his PoV. Jon please chip in here. > So the above implies that the TML _infers_ what to do with the packet based on > the Forces header or (no choice but to get into implementation details) theres > an abstraction that takes a look at those headers and makes the correct TML calls. > I would prefer to put the burden on the TMLs instead of implementing something that > remaps to the TML. In other words this is shaping the requirements for the TML. > > [Of course the best method is for PL to explicitly tell TML what it wants - so > this is second best. The pro for this is reduced complexity]. > > I think the moral to all this discussion is that we now must make sure that if we are > going in the path of inference that the main header carries sufficient information > to be usable by the TML. So it was not a total waster of time to go through this > pain ;-> > > More below > > On Mon, 2004-04-19 at 23:59, Khosravi, Hormuzd M wrote: > > Jamal, > > > > I see your point of view a little better now and I think I know where > > the confusion is :) > > > > Let me try and explain.... > > > > In case of ForCES, since we have said that we have different > > requirements for control and data or lets just say for different > > messages, you think we need to have some API to convey this information > > from the PL to the TML. This is true but the API is more of an > > implementation issue. The way I see this information being conveyed is > > simply using the ForCES Common Header. > > Lets call this technique inference-by-TML > > > For example, if we decide that Messages A-X need Reliability and > > Messages Y-Z need unreliability, the header the MessageType field which > > will convey this info to the TML. Also, if you want to specify that this > > message has to be unicast to FE 1 the FE ID field in the header will > > have this information. Now whether we have an API between PL and TML of > > the form, > > EncapsulatePLMessage(message*) or > > Send(buffer), is implementation details. > > > > This is fine with me. Lets say explicitly if we want to use > inference-by-TML and we can move on. I would like to hear Weimings view. > > > So what we need to do is define the requirements or services for > > different messages or message categories such as Data and Control and > > the TML designers will try to satisfy those requirements. > > I think the standard protocol requirements we have should suffice. > How they get signalled is the next step we should discuss. You seem to > be saying by message type; i think the better way to do it is probably > using flags > > > Now, I don't > > expect that there will be multiple ways of providing the same service > > for a particular interconnect-specific TML...for example, the IP TML > > might decide to use TCP or SCTP to provide Reliable/CC aware service, > > but it will not use both. However, we don't need to get into this > > discussion, since we are not on that team :) > > Sure, we just treat the TML as a blackbox. The main header can signal > what service we want out of the TML and the PL should be agnosric if > that service is delivered over avio pigeons or ATCA data fabric. > > > I hope this helps...I think we are saying the same thing but in > > different ways. > > I think we are getting close; from this we can derive more the > requirements on the TML and what to go on the header. > > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 14:02:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08802 for ; Tue, 20 Apr 2004 14:02:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzW4-0000nK-VB for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:58:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHweYm003049 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:58:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzK6-0004sp-Ea for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 13:46:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07780 for ; Tue, 20 Apr 2004 13:46:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFzK4-0003TX-8n for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:46:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFzJF-0003QW-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:45:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFzIo-0003My-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFz3S-00063P-2k; Tue, 20 Apr 2004 13:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyr4-0001bI-Te for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 13:16:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05322 for ; Tue, 20 Apr 2004 13:16:17 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyr2-0001O2-Vb for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyqC-0001KS-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:15:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BFypR-0001Gb-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:14:37 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KHEQk13315; Tue, 20 Apr 2004 20:14:26 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 20:14:15 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KHEF4S011464; Tue, 20 Apr 2004 20:14:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Jlb2cc; Tue, 20 Apr 2004 20:14:06 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KHDts07684; Tue, 20 Apr 2004 20:13:55 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 12:13:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: Thread-Topic: PL<-->TML:: topic 1 Thread-Index: AcQmUDZ2tTa0AvqpRmqVXhg17XTi+AAPGEewABtp3DA= To: , , Cc: X-OriginalArrivalTime: 20 Apr 2004 17:13:52.0376 (UTC) FILETIME=[DA8FE780:01C426FA] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 13:13:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, Why cannot the capabilities of TML being conveyed to the PL via FEM or = CEM. This will eliminate unnecessary flag operations for each messages.=20 Most of the services are valid for one full session. The flag approach = is ok, but it is going to complicate the protocol operation.=20 If you see midcom protocol semantics from IETF midcom WG. ForCES PL is = almost closer to that. They have defined the message structure and focused on what needs to be = communicated between endpoints.=20 How its being transported is independent and what services are required = to satisfy the protocol from the transport is outside. This way the protocol definition and usage becomes simpler. Regards Ramg =20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Tuesday, April 20, 2004 12:09 AM > To: hadi@znyx.com; Weiming Wang > Cc: forces-protocol@ietf.org > Subject: [Forces-protocol] RE: PL<-->TML:: topic 1 >=20 >=20 > Hi Jamal, >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim >=20 > Lets take an example of CE-PL sending a message that requires=20 > a reliable > delivery; assume we have a UDP and TCP connection in the TML: >=20 > I would like to send such a message from the PL level via the TML with > some indication to the TML that this message needs to be delivered > reliably (obviously via TCP in this example). Clearly it is=20 > cleaner for > the PL to have no clue that the TPC connection is being used. > 2-3 ways i could do it: > 1) call a speacial function[1] which is translated by the=20 > CE-TML to mean > send via TCP > OR > 2) call a generic function[1] with flags turned to say "reliability > needed" and the TML translates this to mean send via TCP. > OR > 3) just send the Forces Messages with some of its flags turned on to > mean reliability on and such a message is translated to mean send via > TCP. >=20 > #3 may be the API-avoidance scheme. >=20 > [HK] Exactly, #3 is what I was explaining in my last email that I just > sent out. (Use fields/flags in the Common Header to correspond to a > transport service e.g. TCP connection in the TML).=20 >=20 > I think we are on the same page now, Hopefully this issue is=20 > resolved :) >=20 >=20 > Regards > Hormuzd >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 14:02:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08848 for ; Tue, 20 Apr 2004 14:02:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzW5-0000o6-Re for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:58:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHwfTd003094 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 13:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFzKu-0005DI-LS for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 13:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07803 for ; Tue, 20 Apr 2004 13:47: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 1BFzKs-0003W3-Ee for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:47:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFzJu-0003SI-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:46:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFzIv-0003O5-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 13:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFz4L-0006dK-Qe; Tue, 20 Apr 2004 13:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyro-0001lb-UC for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 13:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05355 for ; Tue, 20 Apr 2004 13:17:03 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyrm-0001Ro-SY for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:17:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyqo-0001MG-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:16:03 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFyps-0001HT-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 13:15:05 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KHEtO14222; Tue, 20 Apr 2004 20:14:55 +0300 (EET DST) X-Scanned: Tue, 20 Apr 2004 20:14:28 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3KHEShH011961; Tue, 20 Apr 2004 20:14:28 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00AbK4T5; Tue, 20 Apr 2004 20:14:26 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3KHEJF11873; Tue, 20 Apr 2004 20:14:19 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Apr 2004 12:14:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA] Message-ID: Thread-Topic: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA] Thread-Index: AcQm+QqYEsHZECM+RmOLDQWh5ehthQAAdLiw To: , Cc: , , X-OriginalArrivalTime: 20 Apr 2004 17:14:17.0393 (UTC) FILETIME=[E9793210:01C426FA] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 13:14:16 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have communicated this in yesterday's email.=20 regards ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Weiming Wang > Sent: Tuesday, April 20, 2004 11:58 AM > To: hadi@znyx.com > Cc: Khosravi, Hormuzd M; avri@acm.org; forces-protocol@ietf.org > Subject: Re: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA] >=20 >=20 > Hi Jamal,Hormuzd, >=20 > As said in my earlier mail, I'm ok with the scheme to use=20 > flags or inference of > other fields in the protocol message to signal transmission=20 > requirements to TML > layer, though I'm a little worry if this can meet all what we=20 > need, therefore I > highly suggest we try to compose all possible flags and point=20 > out all that may > be used for inference to see if it works well now (not=20 > later). We have actually > said something on reliability (use a flag or use the message=20 > type as tip) and > have already said somthing on multicast/broadcast, how about=20 > lets try to define > or find out others then? >=20 > Cheers, > Weiming >=20 > > From: Jamal Hadi Salim > > Hi Hormuzd, > > > > To reword #3 to provide context: > > > > JHS>3)(PL) to just send the Forces Messages with some of=20 > its flags turned on > to > > JHS>mean reliability on and such a message is translated=20 > (by TML)to mean send > via > > JHS> a reliable means. > > JHS> > > JHS#3 may be the API-avoidance scheme. > > > > > > [HK] Exactly, #3 is what I was explaining in my last=20 > email that I just > > > sent out. (Use fields/flags in the Common Header to=20 > correspond to a > > > transport service e.g. TCP connection in the TML). > > > > I have no issues i can think of right top of my head on=20 > this. I am CCing Jon > Maloy > > since TIPC is being proposed as a TML to get his PoV. Jon=20 > please chip in here. > > So the above implies that the TML _infers_ what to do with=20 > the packet based on > > the Forces header or (no choice but to get into=20 > implementation details) theres > > an abstraction that takes a look at those headers and makes=20 > the correct TML > calls. > > I would prefer to put the burden on the TMLs instead of=20 > implementing something > that > > remaps to the TML. In other words this is shaping the=20 > requirements for the > TML. > > > > [Of course the best method is for PL to explicitly tell TML=20 > what it wants - so > > this is second best. The pro for this is reduced complexity]. > > > > I think the moral to all this discussion is that we now=20 > must make sure that if > we are > > going in the path of inference that the main header carries=20 > sufficient > information > > to be usable by the TML. So it was not a total waster of=20 > time to go through > this > > pain ;-> > > > > More below > > > > On Mon, 2004-04-19 at 23:59, Khosravi, Hormuzd M wrote: > > > Jamal, > > > > > > I see your point of view a little better now and I think=20 > I know where > > > the confusion is :) > > > > > > Let me try and explain.... > > > > > > In case of ForCES, since we have said that we have different > > > requirements for control and data or lets just say for different > > > messages, you think we need to have some API to convey=20 > this information > > > from the PL to the TML. This is true but the API is more of an > > > implementation issue. The way I see this information=20 > being conveyed is > > > simply using the ForCES Common Header. > > > > Lets call this technique inference-by-TML > > > > > For example, if we decide that Messages A-X need Reliability and > > > Messages Y-Z need unreliability, the header the=20 > MessageType field which > > > will convey this info to the TML. Also, if you want to=20 > specify that this > > > message has to be unicast to FE 1 the FE ID field in the=20 > header will > > > have this information. Now whether we have an API between=20 > PL and TML of > > > the form, > > > EncapsulatePLMessage(message*) or > > > Send(buffer), is implementation details. > > > > > > > This is fine with me. Lets say explicitly if we want to use > > inference-by-TML and we can move on. I would like to hear=20 > Weimings view. > > > > > So what we need to do is define the requirements or services for > > > different messages or message categories such as Data and=20 > Control and > > > the TML designers will try to satisfy those requirements. > > > > I think the standard protocol requirements we have should suffice. > > How they get signalled is the next step we should discuss.=20 > You seem to > > be saying by message type; i think the better way to do it=20 > is probably > > using flags > > > > > Now, I don't > > > expect that there will be multiple ways of providing the=20 > same service > > > for a particular interconnect-specific TML...for example,=20 > the IP TML > > > might decide to use TCP or SCTP to provide Reliable/CC=20 > aware service, > > > but it will not use both. However, we don't need to get into this > > > discussion, since we are not on that team :) > > > > Sure, we just treat the TML as a blackbox. The main header=20 > can signal > > what service we want out of the TML and the PL should be agnosric if > > that service is delivered over avio pigeons or ATCA data fabric. > > > > > I hope this helps...I think we are saying the same thing but in > > > different ways. > > > > I think we are getting close; from this we can derive more the > > requirements on the TML and what to go on the header. > > > > cheers, > > jamal > > > > >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 18:29:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03676 for ; Tue, 20 Apr 2004 18:29:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3ZE-0000C1-H7 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 18:18:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMICbA000733 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 18:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Qz-0007T3-9X for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 18:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01221 for ; Tue, 20 Apr 2004 18:09: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 1BG3Qw-0005S9-Du for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 18:09:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3Po-0005Lp-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 18:08:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3PV-0005H4-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 18:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG33p-0000Qp-Kz; Tue, 20 Apr 2004 17:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2Iz-0008JV-Kc for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 16:57:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24307 for ; Tue, 20 Apr 2004 16:57: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 1BG2Ix-00051i-BO for forces-protocol@ietf.org; Tue, 20 Apr 2004 16:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2IB-0004xe-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 16:56:32 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BG2HL-0004oh-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 16:55:39 -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 i3KKtAkA015952; Tue, 20 Apr 2004 20:55:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3KKscRK006081; Tue, 20 Apr 2004 20:55:04 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 M2004042013545405745 ; Tue, 20 Apr 2004 13:54:54 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 13:54:54 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: PL/TML Interface Thread-Index: AcQjyW7Ef8iVsFLJRjyxYkasy4ZPcgCSeK/wAECJV4A= From: "Putzolu, David" To: , Cc: "Khosravi, Hormuzd M" , , X-OriginalArrivalTime: 20 Apr 2004 20:54:54.0627 (UTC) FILETIME=[BB7ACF30:01C42719] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] PL/TML Interface Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 13:54:54 -0700 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 Content-Transfer-Encoding: quoted-printable Hi all. Still getting caught up on the discussions! The protocol design team could define a PL/TML API if desired. However, since APIs are not currently in the charter, we would have to make a case to the ADs for adding it. This might be tough, because an intra-endpoint API is a=20 different problem than the once ForCES protocol=20 tackles. ForCES protocol tackles FE/CE interoperability. A PL/TML API would be tackling intra-FE and intra-CE interop between an implementer of the ForCES PL and the implementer of the interconnect. This isn't a bad idea at all - but the challenge would be convincing the ADs that a standard API is needed here. I'm not ruling it out - just letting you know that we would need to make a good case for it to the ADs. Using a implicit/PL header flags approach is also feasible, although I'm a bit concerned in that I'm not familiar with prior examples of such an approach. Are there other cases where a protocol had header fields to signal the protocol implementation on the same endpoint, rather than to the other end of the connection? =20 Finally, there is the option of simply handwaving and saying that implementers will implement the system such that the TML is signaled appropriately. So for example: The TML abstract definition section of the doc might say: "A multicast, unreliable message-oriented service is provided. Each message delivered to this service includes an indication of which recipients should receive the message. The service does not guarantee reliable delivery but does guarantee messages will not be corrupted and will be delivered in order. This service is intended to be used for timely delivery of information."=20 The PL configuration section of the doc might say: =20 "when adding an IP route to multiple FEs, the=20 TML's multicast, unreliable message oriented service=20 is used to deliver the following message to each desired FE: ------------------------------ | (list if FEid/LFBid pairs) | ------------------------------ | new route | ------------------------------ Each FE scans the list of FEids and LFBid pairs to see which of its LFBs should be given the new route structure" And the Ethernet TML doc might say: "The multicast, unreliable message oriented service=20 is implemented using Ethernet broadcast as follows: the PL indicates the list of FEs and passes down a PDU...the TML uses Ethernet broadcast and the following header listing which FEs should parse the message and includes a CRC and message number for ensuring non-corruption and ordering: --------------------------------- | FEid, | | ... | | FEid | --------------------------------- | CRC-32 | --------------------------------- | Message # | --------------------------------- | Payload to deliver to each FE | --------------------------------- Finally, a PL implementer might implement it as a generic (but proprietary) API that they define and share with customers, e.g. "FooCorp's implementation of ForCES includes a TML abstraction API allowing customers to use any interconnect. The API that an interconnect must support for FooCorps' implementation to work for multicast unreliable connections is=20 void FooSendMulticast(addressee_type *addrAray,=20 messageType m)" (In this case m would correspond to the PL-defined PDU shown in the PL config section above). Sorry to jump in to the technical discussion -=20 my original intention was to just clarify that we would need to go to the ADs to define an API, and to ask if there was precedent for using protocol header bits to signal within an end point (as opposed to other endpoints). I just can't resist a good technical discussion :) -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 23:17:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18908 for ; Tue, 20 Apr 2004 23:17:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Ck-0006Mg-IJ for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:15:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3FIBx024462 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG877-0004ET-5s for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:09:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18342 for ; Tue, 20 Apr 2004 23:09: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 1BG872-0000Iw-7a for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:09:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG84s-000065-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:07:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG83Y-0007nn-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:05:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7xy-0007zf-Gi; Tue, 20 Apr 2004 23:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7os-0004FK-Vj for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 22:50:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17491 for ; Tue, 20 Apr 2004 22:50: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 1BG7op-0006SY-Gq for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:50:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7nr-0006ME-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:49:36 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BG7n9-0006Et-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:48:51 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3L2mTkA003456; Wed, 21 Apr 2004 02:48:29 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 i3L2lAcQ026364; Wed, 21 Apr 2004 02:47:20 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 M2004042019481800058 ; Tue, 20 Apr 2004 19:48:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 19:48:19 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EB2532F@orsmsx408.jf.intel.com> Thread-Topic: PL/TML Interface Thread-Index: AcQjyW7Ef8iVsFLJRjyxYkasy4ZPcgCSeK/wAECJV4AADUGVIA== From: "Khosravi, Hormuzd M" To: "Putzolu, David" , , Cc: , X-OriginalArrivalTime: 21 Apr 2004 02:48:19.0298 (UTC) FILETIME=[1A72D420:01C4274B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: PL/TML Interface Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 19:48:18 -0700 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 Content-Transfer-Encoding: quoted-printable Hi David, I am fine with the hand waving approach as well that you have described below. Actually, I wont call it hand waving since we will have text in the PL which will clearly state which service will be required for which messages. This approach will definitely help us make quick progress on the PL design. What do others think ? Thanks Hormuzd -----Original Message----- From: Putzolu, David=20 Finally, there is the option of simply handwaving and saying that implementers will implement the system such that the TML is signaled appropriately. So for example: The TML abstract definition section of the doc might say: "A multicast, unreliable message-oriented service is provided. Each message delivered to this service includes an indication of which recipients should receive the message. The service does not guarantee reliable delivery but does guarantee messages will not be corrupted and will be delivered in order. This service is intended to be used for timely delivery of information."=20 The PL configuration section of the doc might say: =20 "when adding an IP route to multiple FEs, the=20 TML's multicast, unreliable message oriented service=20 is used to deliver the following message to each desired FE: ------------------------------ | (list if FEid/LFBid pairs) | ------------------------------ | new route | ------------------------------ Each FE scans the list of FEids and LFBid pairs to see which of its LFBs should be given the new route structure" And the Ethernet TML doc might say: "The multicast, unreliable message oriented service=20 is implemented using Ethernet broadcast as follows: the PL indicates the list of FEs and passes down a PDU...the TML uses Ethernet broadcast and the following header listing which FEs should parse the message and includes a CRC and message number for ensuring non-corruption and ordering: --------------------------------- | FEid, | | ... | | FEid | --------------------------------- | CRC-32 | --------------------------------- | Message # | --------------------------------- | Payload to deliver to each FE | --------------------------------- Finally, a PL implementer might implement it as a generic (but proprietary) API that they define and share with customers, e.g. "FooCorp's implementation of ForCES includes a TML abstraction API allowing customers to use any interconnect. The API that an interconnect must support for FooCorps' implementation to work for multicast unreliable connections is=20 void FooSendMulticast(addressee_type *addrAray,=20 messageType m)" (In this case m would correspond to the PL-defined PDU shown in the PL config section above). _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 23:18:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18931 for ; Tue, 20 Apr 2004 23:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Co-0006OM-OM for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:16:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3FMWF024563 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:15:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG89D-0004tn-Aw for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:11:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18448 for ; Tue, 20 Apr 2004 23:11: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 1BG899-0000UA-JV for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:11:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG86Y-0000HT-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:08:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG84Z-00005A-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:06:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7zx-0000hI-D7; Tue, 20 Apr 2004 23:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7wv-0007Rp-5o for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 22:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17914 for ; Tue, 20 Apr 2004 22:58: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 1BG7wr-0007DB-NY for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:58:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7vi-00076e-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:57:43 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BG7um-0006wm-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 22:56:44 -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 i3L2uFTc013081; Wed, 21 Apr 2004 02:56:15 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 i3L2t7cM031289; Wed, 21 Apr 2004 02:55:12 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 M2004042019561100936 ; Tue, 20 Apr 2004 19:56:11 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 19:56:11 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EB25336@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQm96D6gIkQWKjkRzSJNyBe3jS5rgAU5ScQ From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 21 Apr 2004 02:56:11.0185 (UTC) FILETIME=[33B71210:01C4274C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 19:55:54 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, I used Reliability as an example below but that can be easily extended to other services. Let me give a more concrete example which we have already discussed in the past... For all control messages (message types A-X), the PL will require the following services from TML...Strict Reliability, Congestion Control, Security. (Not sure about HA at this point, we need to discuss that further) For all data messages (message types Y-Z), the PL will require the following services from TML... Congestion Control, Security.=20 As for TML capability, etc we can push that as part of pre-association phase (FEM, CEM) or even before that (compile, integration time). I don't think we should be concerned with that in the PL team. Hope this helps, Regards Hormuzd=20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang I would like to send such a message from the PL level via the TML with some indication to the TML that this message needs to be delivered reliably (obviously via TCP in this example). Clearly it is cleaner for the PL to have no clue that the TPC connection is being used. 2-3 ways i could do it: 1) call a speacial function[1] which is translated by the CE-TML to mean send via TCP OR 2) call a generic function[1] with flags turned to say "reliability needed" and the TML translates this to mean send via TCP. OR 3) just send the Forces Messages with some of its flags turned on to mean reliability on and such a message is translated to mean send via TCP. #3 may be the API-avoidance scheme. [HK] Exactly, #3 is what I was explaining in my last email that I just sent out. (Use fields/flags in the Common Header to correspond to a transport service e.g. TCP connection in the TML). I think we are on the same page now, Hopefully this issue is resolved :) [Weiming] Among the three schemes, I also more appreciate 3), but I just wonder if this is all for TML-PL, e.g., what then for congestion control, HA, etc? Basically, I think it is only a specific scheme for reliability. I think we now can only say that we have approved to use something like metadata/fields/flags for reliability control. Moreover, I think the scheme is also quite at the abstact level. We then may have to answer more questions as how we then define the 'reliability', how we can know the TML support such 'reliability', and what then if the TML can not supply enough capability for such 'reliability'? From these viepoints, I'm afraid we still need to use mechanisms like TML capability and TML attributes so as to properly configure the TML before we can actually use such metadata/fields in the protocol messages. I notice that Jamal seems to say such TML configuration is better to be left for CEM and FEM. If it is, then I think it may libarate our protocol team a lot. So, Hormuzd, what's your opinion? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 20 23:47:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20372 for ; Tue, 20 Apr 2004 23:47:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8fg-00019a-7H for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:45:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3jC0d004427 for forces-protocol-archive@odin.ietf.org; Tue, 20 Apr 2004 23:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8QZ-0003nt-5N for forces-protocol-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:29:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19622 for ; Tue, 20 Apr 2004 23:29: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 1BG8QX-0002H5-AM for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:29:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8Pa-0002BY-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:28:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8PH-00026T-00 for forces-protocol-web-archive@ietf.org; Tue, 20 Apr 2004 23:28:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8FP-0007me-8a; Tue, 20 Apr 2004 23:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8AN-0005Dr-AK for forces-protocol@optimus.ietf.org; Tue, 20 Apr 2004 23:12:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18634 for ; Tue, 20 Apr 2004 23:12: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 1BG8AL-0000fs-9U for forces-protocol@ietf.org; Tue, 20 Apr 2004 23:12:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG89T-0000Xf-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 23:11:57 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BG87K-0000Ic-00 for forces-protocol@ietf.org; Tue, 20 Apr 2004 23:09:43 -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 i3L398Tc020906; Wed, 21 Apr 2004 03:09:08 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 i3L37jcM005863; Wed, 21 Apr 2004 03:08:03 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 M2004042020090202212 ; Tue, 20 Apr 2004 20:09:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Apr 2004 20:09:02 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EB2533D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQm5QmOHTaJ51HxSOyJfqGSzDxLgwAZzj0w From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: , "Weiming Wang" , X-OriginalArrivalTime: 21 Apr 2004 03:09:02.0501 (UTC) FILETIME=[FF748D50:01C4274D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 20 Apr 2004 20:09:02 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Robert, -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 On the reliability example: remember that ForCES-level reliability is=20 somewhat orthogonal to transport-level reliability. At the ForCES level, I want to get an ACK back from a FE to confirm that it could update a=20 firewall rule successfully, for instance. [HK] Sure, ForCES level reliability will be defined using Message Types at the PL. For example, a Configuration Response message could be defined to provide an Ack at PL and also report the status of a Config Request message. So if I tag my ForCES message with "reliability enabled", the TML COULD=20 choose to send it over TCP, but this is not mandatory, as using TCP=20 alone is not going to be sufficient to ensure reliable processing at the FE. Actually, the TML could choose UDP, as potential retransmissions=20 anyay need to be taken care of at the PL level as well. Or do you have different views ? Please explain. [HK] I believe we will need Reliability at both the PL and the TML for certain messages. The PL will define explicit messages such as Responses/acks for providing PL level reliability. The TML will define its own way for providing reliability, CC, etc. For example, the IP TML may choose to use TCP or UDP to provide a certain service. The TIPC TML will use TIPC for providing certain service. In the PL Team, we don't need to be concerned about how the service is provided by the TML but rather define what service the PL needs/requires from the TML. Hope this provides some clarification, Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 21 18:28:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24054 for ; Wed, 21 Apr 2004 18:28:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPqx-0003aF-96 for forces-protocol-archive@odin.ietf.org; Wed, 21 Apr 2004 18:05:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM5xha013768 for forces-protocol-archive@odin.ietf.org; Wed, 21 Apr 2004 18:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGP3y-0000Ii-4j for forces-protocol-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14878 for ; Wed, 21 Apr 2004 17:15: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 1BGP3v-0007ax-NL for forces-protocol-web-archive@ietf.org; Wed, 21 Apr 2004 17:15:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP30-0007PN-00 for forces-protocol-web-archive@ietf.org; Wed, 21 Apr 2004 17:14:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP2R-0007Ds-00 for forces-protocol-web-archive@ietf.org; Wed, 21 Apr 2004 17:13:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOae-0003xC-Ju; Wed, 21 Apr 2004 16:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGMKJ-0000FB-Qm for forces-protocol@optimus.ietf.org; Wed, 21 Apr 2004 14:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05986 for ; Wed, 21 Apr 2004 14:20:00 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGMKH-00009Q-6r for forces-protocol@ietf.org; Wed, 21 Apr 2004 14:20:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGMJJ-0007nX-00 for forces-protocol@ietf.org; Wed, 21 Apr 2004 14:19:02 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BGMIZ-0007e4-00 for forces-protocol@ietf.org; Wed, 21 Apr 2004 14:18:15 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BGMIZ-0005WL-KW for forces-protocol@ietf.org; Wed, 21 Apr 2004 18:18:15 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07EB2532F@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EB2532F@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4333BC9E-93C0-11D8-9164-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: PL/TML Interface To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 21 Apr 2004 14:18:17 -0400 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 Content-Transfer-Encoding: 7bit that is the approach I recommend. a. On 20 apr 2004, at 22.48, Khosravi, Hormuzd M wrote: > Hi David, > > I am fine with the hand waving approach as well that you have described > below. > Actually, I wont call it hand waving since we will have text in the PL > which will clearly state which service will be required for which > messages. This approach will definitely help us make quick progress on > the PL design. > > What do others think ? > > Thanks > Hormuzd > > -----Original Message----- > From: Putzolu, David > > Finally, there is the option of simply handwaving > and saying that implementers will implement the > system such that the TML is signaled appropriately. > So for example: > > The TML abstract definition section of the doc might say: > "A multicast, unreliable message-oriented service > is provided. Each message delivered to this > service includes an indication of which recipients > should receive the message. The service does not > guarantee reliable delivery but does guarantee > messages will not be corrupted and will be delivered > in order. This service is intended to be used > for timely delivery of information." > > The PL configuration section of the doc might say: > "when adding an IP route to multiple FEs, the > TML's multicast, unreliable message oriented service > is used to deliver the following message to each > desired FE: > ------------------------------ > | (list if FEid/LFBid pairs) | > ------------------------------ > | new route | > ------------------------------ > Each FE scans the list of FEids and LFBid pairs > to see which of its LFBs should be given the > new route structure" > > And the Ethernet TML doc might say: > "The multicast, unreliable message oriented service > is implemented using Ethernet broadcast as follows: > the PL indicates the list of FEs and passes > down a PDU...the TML uses Ethernet broadcast > and the following header listing which FEs should > parse the message and includes a CRC and message > number for ensuring non-corruption and ordering: > --------------------------------- > | FEid, | > | ... | > | FEid | > --------------------------------- > | CRC-32 | > --------------------------------- > | Message # | > --------------------------------- > | Payload to deliver to each FE | > --------------------------------- > > Finally, a PL implementer might implement it as a > generic (but proprietary) API that they define and > share with customers, e.g. > "FooCorp's implementation of ForCES includes a > TML abstraction API allowing customers to use > any interconnect. The API that an interconnect > must support for FooCorps' implementation to work > for multicast unreliable connections is > void FooSendMulticast(addressee_type *addrAray, > messageType m)" > (In this case m would correspond to the PL-defined > PDU shown in the PL config section above). > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 22 02:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04477 for ; Thu, 22 Apr 2004 02:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXYn-0006CH-I2 for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 02:20:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M6Jj68023821 for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 02:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXSw-0001kk-L4 for forces-protocol-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 02:13:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03221 for ; Thu, 22 Apr 2004 02:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGXSt-0003El-29 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:13:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXRv-00032a-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:12:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGXRi-0002qh-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:12:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXJY-0002Fd-MR; Thu, 22 Apr 2004 02:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXFR-00061O-Bz for forces-protocol@optimus.ietf.org; Thu, 22 Apr 2004 01:59:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19991 for ; Thu, 22 Apr 2004 01:59: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 1BGXFL-0000Q5-Qr for forces-protocol@ietf.org; Thu, 22 Apr 2004 01:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXEK-0000EY-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 01:58:37 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BGXDf-00002f-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 01:57:56 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 22 Apr 2004 14:10:07 +0800 Message-ID: <007301c4282e$478742f0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Putzolu, David" , References: Subject: Re: [Forces-protocol] PL/TML Interface 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 13:54:27 +0800 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 It also seems to me a little abnormal to define a unit in PDU that is for local use. If we need to choose between explicit flags and implicit fields, implicit is also more aceeptable to me. Cheers, Weiming ----- Original Message ----- From: "Putzolu, David" To: ; Hi all. Still getting caught up on the discussions! The protocol design team could define a PL/TML API if desired. However, since APIs are not currently in the charter, we would have to make a case to the ADs for adding it. This might be tough, because an intra-endpoint API is a different problem than the once ForCES protocol tackles. ForCES protocol tackles FE/CE interoperability. A PL/TML API would be tackling intra-FE and intra-CE interop between an implementer of the ForCES PL and the implementer of the interconnect. This isn't a bad idea at all - but the challenge would be convincing the ADs that a standard API is needed here. I'm not ruling it out - just letting you know that we would need to make a good case for it to the ADs. Using a implicit/PL header flags approach is also feasible, although I'm a bit concerned in that I'm not familiar with prior examples of such an approach. Are there other cases where a protocol had header fields to signal the protocol implementation on the same endpoint, rather than to the other end of the connection? Finally, there is the option of simply handwaving and saying that implementers will implement the system such that the TML is signaled appropriately. So for example: The TML abstract definition section of the doc might say: "A multicast, unreliable message-oriented service is provided. Each message delivered to this service includes an indication of which recipients should receive the message. The service does not guarantee reliable delivery but does guarantee messages will not be corrupted and will be delivered in order. This service is intended to be used for timely delivery of information." The PL configuration section of the doc might say: "when adding an IP route to multiple FEs, the TML's multicast, unreliable message oriented service is used to deliver the following message to each desired FE: ------------------------------ | (list if FEid/LFBid pairs) | ------------------------------ | new route | ------------------------------ Each FE scans the list of FEids and LFBid pairs to see which of its LFBs should be given the new route structure" And the Ethernet TML doc might say: "The multicast, unreliable message oriented service is implemented using Ethernet broadcast as follows: the PL indicates the list of FEs and passes down a PDU...the TML uses Ethernet broadcast and the following header listing which FEs should parse the message and includes a CRC and message number for ensuring non-corruption and ordering: --------------------------------- | FEid, | | ... | | FEid | --------------------------------- | CRC-32 | --------------------------------- | Message # | --------------------------------- | Payload to deliver to each FE | --------------------------------- Finally, a PL implementer might implement it as a generic (but proprietary) API that they define and share with customers, e.g. "FooCorp's implementation of ForCES includes a TML abstraction API allowing customers to use any interconnect. The API that an interconnect must support for FooCorps' implementation to work for multicast unreliable connections is void FooSendMulticast(addressee_type *addrAray, messageType m)" (In this case m would correspond to the PL-defined PDU shown in the PL config section above). Sorry to jump in to the technical discussion - my original intention was to just clarify that we would need to go to the ADs to define an API, and to ask if there was precedent for using protocol header bits to signal within an end point (as opposed to other endpoints). I just can't resist a good technical discussion :) -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 22 02:47:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06092 for ; Thu, 22 Apr 2004 02:47:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXqZ-0007qq-St for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 02:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M6c7kT030181 for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 02:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXkI-00057w-9A for forces-protocol-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 02:31:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05314 for ; Thu, 22 Apr 2004 02:31: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 1BGXkE-0007LF-HT for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:31:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXjI-00077Q-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:30:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGXiQ-0006l6-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 02:29:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXgn-0003WT-DO; Thu, 22 Apr 2004 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXdf-0001Qx-OJ for forces-protocol@optimus.ietf.org; Thu, 22 Apr 2004 02:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04654 for ; Thu, 22 Apr 2004 02:24: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 1BGXdc-0005eU-18 for forces-protocol@ietf.org; Thu, 22 Apr 2004 02:24:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXcg-0005Ri-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 02:23:46 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BGXby-0005EU-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 02:23:22 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 22 Apr 2004 14:35:18 +0800 Message-ID: <008301c42831$cbee5800$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07EB25336@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 14:19:40 +0800 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 Hi Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi Weiming, I used Reliability as an example below but that can be easily extended to other services. Let me give a more concrete example which we have already discussed in the past... For all control messages (message types A-X), the PL will require the following services from TML...Strict Reliability, Congestion Control, Security. (Not sure about HA at this point, we need to discuss that further) For all data messages (message types Y-Z), the PL will require the following services from TML... Congestion Control, Security. [Weiming] We may need to consider more cases on this, e.g., even for the same message type, messages may have different TML requirements, e.g., for evnet messages, failure report event should be strictly reliably and timely transmitted, while things like heartbeat signals actually don't have the requirements. [/Weiming] As for TML capability, etc we can push that as part of pre-association phase (FEM, CEM) or even before that (compile, integration time). I don't think we should be concerned with that in the PL team. [Weiming] This is a long lasting question that I think we have not resolved very well, that is, if we need to go back to pre-association again when some TML change happens( link failure, CE failure, etc) during the post-assoc., and how we go back? Or we just let the protocop layer to deal with such change? Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 22 15:02:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18209 for ; Thu, 22 Apr 2004 15:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPS-00073D-8e for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 14:58:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MIwsxw027101 for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 14:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjIE-0004ut-5O for forces-protocol-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 14:51:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17434 for ; Thu, 22 Apr 2004 14:51:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjI9-0001fb-BL for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjHB-0001OJ-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:50:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjGl-00017S-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:49:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj8A-0002Gj-DB; Thu, 22 Apr 2004 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiw0-0007Fz-Mx for forces-protocol@optimus.ietf.org; Thu, 22 Apr 2004 14:28:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16248 for ; Thu, 22 Apr 2004 14:28: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 1BGivv-0003Ca-WD for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:28:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiv1-0002s7-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:27:28 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BGiu9-0002UD-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:26:34 -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 i3MIQ188016142; Thu, 22 Apr 2004 18:26:01 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 i3MIPgMY023147; Thu, 22 Apr 2004 18:25:50 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 M2004042211254010457 ; Thu, 22 Apr 2004 11:25:40 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 11:25:40 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EB8C9E4@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQoMzF738oks4LBQHiFQfcQKWDtuwAYsCAw From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 22 Apr 2004 18:25:40.0366 (UTC) FILETIME=[372682E0:01C42897] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 11:25:39 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, My comments inline below... -----Original Message----- I used Reliability as an example below but that can be easily extended to other services. Let me give a more concrete example which we have already discussed in the past... For all control messages (message types A-X), the PL will require the following services from TML...Strict Reliability, Congestion Control, Security. (Not sure about HA at this point, we need to discuss that further) For all data messages (message types Y-Z), the PL will require the following services from TML... Congestion Control, Security. [Weiming] We may need to consider more cases on this, e.g., even for the same message type, messages may have different TML requirements, e.g., for evnet messages, failure report event should be strictly reliably and timely transmitted, while things like heartbeat signals actually don't have the requirements. [/Weiming] [HK] Yes we could define separate requirements for HBs since they have been separated in the Requirements RFC as well. But I am not sure if that is a good idea, there were some email exchanges on the ForCES list between Joel Halpern and some folks, and Joel made some good points. If you get the chance to refer to those, they were good discussions. As for TML capability, etc we can push that as part of pre-association phase (FEM, CEM) or even before that (compile, integration time). I don't think we should be concerned with that in the PL team. [Weiming] This is a long lasting question that I think we have not resolved very well, that is, if we need to go back to pre-association again when some TML change happens( link failure, CE failure, etc) during the post-assoc., and how we go back? Or we just let the protocop layer to deal with such change? [HK] Events like Link Failure, CE failure will be delivered to the PL from the TML so I don't think this is an issue. May be I am missing something here, but seems like we are spending a lot more cycles on TML discussion than we should be on this team. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 22 15:23:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21021 for ; Thu, 22 Apr 2004 15:23:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjSD-0001Zt-Lk for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 15:01:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJ1jLt006059 for forces-protocol-archive@odin.ietf.org; Thu, 22 Apr 2004 15:01:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjMu-0006My-72 for forces-protocol-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 14:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17808 for ; Thu, 22 Apr 2004 14:56: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 1BGjMp-00035C-Cl for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:56:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjLx-0002pE-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:55:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjLR-0002Ys-00 for forces-protocol-web-archive@ietf.org; Thu, 22 Apr 2004 14:54:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj8F-0002Ib-6w; Thu, 22 Apr 2004 14:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGj0w-0008Ea-Kc for forces-protocol@optimus.ietf.org; Thu, 22 Apr 2004 14:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16555 for ; Thu, 22 Apr 2004 14:33: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 1BGj0r-0004aZ-Qm for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGizs-0004JK-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:32:29 -0400 Received: from petasus.ch.intel.com ([143.182.124.5]) by ietf-mx with esmtp (Exim 4.12) id 1BGiyx-0003sA-00 for forces-protocol@ietf.org; Thu, 22 Apr 2004 14:31:31 -0400 Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [143.182.252.54]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i3MITJ3p024887; Thu, 22 Apr 2004 18:30:59 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs040.ch.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042211305609366 ; Thu, 22 Apr 2004 11:30:56 -0700 Received: from rrsmsx401.amr.corp.intel.com ([10.14.9.74]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 11:30:56 -0700 Received: from orsmsx312.amr.corp.intel.com ([192.168.65.62]) by rrsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 12:30:55 -0600 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 11:30:53 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] PL/TML Interface Message-ID: <468F3FDA28AA87429AD807992E22D07EB8CA04@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] PL/TML Interface Thread-Index: AcQoMOFl8SKPHCfASXaJ/ftPBGQ9CQAZnqbQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , "Putzolu, David" , X-OriginalArrivalTime: 22 Apr 2004 18:30:53.0483 (UTC) FILETIME=[F1C85FB0:01C42897] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 22 Apr 2004 11:30:52 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, I am not sure I completely understood your comment below. Are you saying you prefer the implicit flag approach over all other approaches ? What do you think about the 'Handwaving' approach proposed by David ? I think this will enable us to make fastest progress on PL issues rather than getting diverted on TML details. What do you think ?=20 Jamal, any comments ? Thanks Hormuzd -----Original Message----- It also seems to me a little abnormal to define a unit in PDU that is for local use. If we need to choose between explicit flags and implicit fields, implicit is also more aceeptable to me. Cheers, Weiming ----- Original Message ----- From: "Putzolu, David" To: ; Hi all. Still getting caught up on the discussions! The protocol design team could define a PL/TML API if desired. However, since APIs are not currently in the charter, we would have to make a case to the ADs for adding it. This might be tough, because an intra-endpoint API is a different problem than the once ForCES protocol tackles. ForCES protocol tackles FE/CE interoperability. A PL/TML API would be tackling intra-FE and intra-CE interop between an implementer of the ForCES PL and the implementer of the interconnect. This isn't a bad idea at all - but the challenge would be convincing the ADs that a standard API is needed here. I'm not ruling it out - just letting you know that we would need to make a good case for it to the ADs. Using a implicit/PL header flags approach is also feasible, although I'm a bit concerned in that I'm not familiar with prior examples of such an approach. Are there other cases where a protocol had header fields to signal the protocol implementation on the same endpoint, rather than to the other end of the connection? Finally, there is the option of simply handwaving and saying that implementers will implement the system such that the TML is signaled appropriately. So for example: The TML abstract definition section of the doc might say: "A multicast, unreliable message-oriented service is provided. Each message delivered to this service includes an indication of which recipients should receive the message. The service does not guarantee reliable delivery but does guarantee messages will not be corrupted and will be delivered in order. This service is intended to be used for timely delivery of information." The PL configuration section of the doc might say: "when adding an IP route to multiple FEs, the TML's multicast, unreliable message oriented service is used to deliver the following message to each desired FE: ------------------------------ | (list if FEid/LFBid pairs) | ------------------------------ | new route | ------------------------------ Each FE scans the list of FEids and LFBid pairs to see which of its LFBs should be given the new route structure" And the Ethernet TML doc might say: "The multicast, unreliable message oriented service is implemented using Ethernet broadcast as follows: the PL indicates the list of FEs and passes down a PDU...the TML uses Ethernet broadcast and the following header listing which FEs should parse the message and includes a CRC and message number for ensuring non-corruption and ordering: --------------------------------- | FEid, | | ... | | FEid | --------------------------------- | CRC-32 | --------------------------------- | Message # | --------------------------------- | Payload to deliver to each FE | --------------------------------- Finally, a PL implementer might implement it as a generic (but proprietary) API that they define and share with customers, e.g. "FooCorp's implementation of ForCES includes a TML abstraction API allowing customers to use any interconnect. The API that an interconnect must support for FooCorps' implementation to work for multicast unreliable connections is void FooSendMulticast(addressee_type *addrAray, messageType m)" (In this case m would correspond to the PL-defined PDU shown in the PL config section above). Sorry to jump in to the technical discussion - my original intention was to just clarify that we would need to go to the ADs to define an API, and to ask if there was precedent for using protocol header bits to signal within an end point (as opposed to other endpoints). I just can't resist a good technical discussion :) -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 23 00:34:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27092 for ; Fri, 23 Apr 2004 00:34:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsIE-000774-Qw for forces-protocol-archive@odin.ietf.org; Fri, 23 Apr 2004 00:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N4S2fb027338 for forces-protocol-archive@odin.ietf.org; Fri, 23 Apr 2004 00:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGsH4-0006ac-7q for forces-protocol-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 00:26:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26728 for ; Fri, 23 Apr 2004 00:26: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 1BGsGz-0007hY-NH for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 00:26:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGsG8-0007Qi-00 for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 00:25:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGsFa-000799-00 for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 00:25:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrzv-0000Vs-Qw; Fri, 23 Apr 2004 00:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGrwg-000714-Bz for forces-protocol@optimus.ietf.org; Fri, 23 Apr 2004 00:05:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25728 for ; Fri, 23 Apr 2004 00:05:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGrwb-00021q-Tv for forces-protocol@ietf.org; Fri, 23 Apr 2004 00:05:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGrvf-0001lW-00 for forces-protocol@ietf.org; Fri, 23 Apr 2004 00:04:44 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BGrv0-0001Uh-00 for forces-protocol@ietf.org; Fri, 23 Apr 2004 00:04:03 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 23 Apr 2004 12:16:18 +0800 Message-ID: <011301c428e7$8a00ef50$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EB8CA04@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] PL/TML Interface 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 23 Apr 2004 12:00:38 +0800 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 Hormuzd, My understandind of handwaving approach David presented below using multicast add route as an example is that the FEid(s) and the message type is used as a waving signal to TML to implicitly ask for the defined service in the TML. This is opposite to the explicit approach in that the latter may use an explicit flag to indicate such service requirement. Do I misunderstand something here? Actually my another thought (as I posted before) is to let the protocol layer more flexible to use TML by allowing some configurations from Pl to TML based on the TML capabilities . The configuration may be some thing like "ple use #xx service template for message type xx when the message asks for multicast". This approach is actually consistent with the handwaving approach, only with more flexibility in that protocol customers may have more choices other than that defined by TML requirements. I think this is also useful for more flexible vendor supports. But I just don't want to push this too hard now because I agree with you that we now need to move forward much more quickly. Anyway, I have no doubt to use the handwaving approach. I'm also anxious to hear what Jamal thinks. Best regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, I am not sure I completely understood your comment below. Are you saying you prefer the implicit flag approach over all other approaches ? What do you think about the 'Handwaving' approach proposed by David ? I think this will enable us to make fastest progress on PL issues rather than getting diverted on TML details. What do you think ? Jamal, any comments ? Thanks Hormuzd -----Original Message----- It also seems to me a little abnormal to define a unit in PDU that is for local use. If we need to choose between explicit flags and implicit fields, implicit is also more aceeptable to me. Cheers, Weiming ----- Original Message ----- From: "Putzolu, David" To: ; Hi all. Still getting caught up on the discussions! The protocol design team could define a PL/TML API if desired. However, since APIs are not currently in the charter, we would have to make a case to the ADs for adding it. This might be tough, because an intra-endpoint API is a different problem than the once ForCES protocol tackles. ForCES protocol tackles FE/CE interoperability. A PL/TML API would be tackling intra-FE and intra-CE interop between an implementer of the ForCES PL and the implementer of the interconnect. This isn't a bad idea at all - but the challenge would be convincing the ADs that a standard API is needed here. I'm not ruling it out - just letting you know that we would need to make a good case for it to the ADs. Using a implicit/PL header flags approach is also feasible, although I'm a bit concerned in that I'm not familiar with prior examples of such an approach. Are there other cases where a protocol had header fields to signal the protocol implementation on the same endpoint, rather than to the other end of the connection? Finally, there is the option of simply handwaving and saying that implementers will implement the system such that the TML is signaled appropriately. So for example: The TML abstract definition section of the doc might say: "A multicast, unreliable message-oriented service is provided. Each message delivered to this service includes an indication of which recipients should receive the message. The service does not guarantee reliable delivery but does guarantee messages will not be corrupted and will be delivered in order. This service is intended to be used for timely delivery of information." The PL configuration section of the doc might say: "when adding an IP route to multiple FEs, the TML's multicast, unreliable message oriented service is used to deliver the following message to each desired FE: ------------------------------ | (list if FEid/LFBid pairs) | ------------------------------ | new route | ------------------------------ Each FE scans the list of FEids and LFBid pairs to see which of its LFBs should be given the new route structure" And the Ethernet TML doc might say: "The multicast, unreliable message oriented service is implemented using Ethernet broadcast as follows: the PL indicates the list of FEs and passes down a PDU...the TML uses Ethernet broadcast and the following header listing which FEs should parse the message and includes a CRC and message number for ensuring non-corruption and ordering: --------------------------------- | FEid, | | ... | | FEid | --------------------------------- | CRC-32 | --------------------------------- | Message # | --------------------------------- | Payload to deliver to each FE | --------------------------------- Finally, a PL implementer might implement it as a generic (but proprietary) API that they define and share with customers, e.g. "FooCorp's implementation of ForCES includes a TML abstraction API allowing customers to use any interconnect. The API that an interconnect must support for FooCorps' implementation to work for multicast unreliable connections is void FooSendMulticast(addressee_type *addrAray, messageType m)" (In this case m would correspond to the PL-defined PDU shown in the PL config section above). Sorry to jump in to the technical discussion - my original intention was to just clarify that we would need to go to the ADs to define an API, and to ask if there was precedent for using protocol header bits to signal within an end point (as opposed to other endpoints). I just can't resist a good technical discussion :) -David _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 23 09:12:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04881 for ; Fri, 23 Apr 2004 09:12:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0QR-0007bQ-AQ for forces-protocol-archive@odin.ietf.org; Fri, 23 Apr 2004 09:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ND938P029222 for forces-protocol-archive@odin.ietf.org; Fri, 23 Apr 2004 09:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0L4-0005np-6Z for forces-protocol-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04122 for ; Fri, 23 Apr 2004 09:03: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 1BH0L2-0006GT-GL for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 09:03:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0Hs-0005Ki-00 for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 09:00:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0Ej-0004QS-00 for forces-protocol-web-archive@ietf.org; Fri, 23 Apr 2004 08:56:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH05C-0001AV-Pz; Fri, 23 Apr 2004 08:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH035-0000ga-9W for forces-protocol@optimus.ietf.org; Fri, 23 Apr 2004 08:44:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01799 for ; Fri, 23 Apr 2004 08:44:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH033-0001Vh-Nh for forces-protocol@ietf.org; Fri, 23 Apr 2004 08:44:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH025-0001GA-00 for forces-protocol@ietf.org; Fri, 23 Apr 2004 08:43:54 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BH011-0000np-00 for forces-protocol@ietf.org; Fri, 23 Apr 2004 08:42:48 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042305460968:9052 ; Fri, 23 Apr 2004 05:46:09 -0700 Subject: Re: [Forces-protocol] PL/TML Interface From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, Hormuzd M In-Reply-To: <011301c428e7$8a00ef50$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EB8CA04@orsmsx408.jf.intel.com> <011301c428e7$8a00ef50$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1082724161.1058.74.camel@jzny.localdomain> 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 04/23/2004 05:46:10 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/23/2004 05:46:15 AM, Serialize complete at 04/23/2004 05:46:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 23 Apr 2004 08:42:41 -0400 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 Content-Transfer-Encoding: 7bit Weimig/Hormuzd, Apologies for disappearing - important customer fire. On Fri, 2004-04-23 at 00:00, Wang,Weiming wrote: > Hormuzd, > > My understandind of handwaving approach David presented below using multicast > add route as an example is that the FEid(s) and the message type is used as a > waving signal to TML to implicitly ask for the defined service in the TML. This > is opposite to the explicit approach in that the latter may use an explicit flag > to indicate such service requirement. Do I misunderstand something here? > I think it is implicit unless i misread it. I dont see the PL worrying about sending a list of FEids though. I think that should be the TMLs problem. PL sends a single address (CE/FEid), the TML may translate or rewrite it. To take an example of a PL sending a broad/multicast FEid: -if TML is capable of broad/multicast, the single message is sent. - if TML is not capable of broad/multicast, then it will take that FEid, do an internal lookup, come up with a list of unicast FEids and unicast-send to each. > Actually my another thought (as I posted before) is to let the protocol layer > more flexible to use TML by allowing some configurations from Pl to TML based on > the TML capabilities . The configuration may be some thing like "ple use #xx > service template for message type xx when the message asks for multicast". This I think that message type alone is insufficient. Since message type is a static item, we need flags to override default behaviors. To borrow an example from netlink2, we used the ACK flag to indicate that a message/transaction was to be reliably delivered. Even on an example of an ADD ROUTE, if i choose not to have a specific ADD ROUTE reliably delivered for whatever reason, i should be able to override the message type decision by NOT setting the ACK flag. Corrollary: In a message type where reliability is not needed, i should still be able to request for a specific message to be reliably delivered by setting a flag such as the ACK. TMLs should be defining something of the nature: 1) This TML is capable of both unicast and multicast 2) When a message has to be delivered reliably, operation is: send on multicast UDP, if no response send on TCP and wait for upto y seconds for a response. Notify PL on success if it asked for ACK. Notify PL on failure always. 3) etc > approach is actually consistent with the handwaving approach, only with more > flexibility in that protocol customers may have more choices other than that > defined by TML requirements. I think this is also useful for more flexible > vendor supports. But I just don't want to push this too hard now because I > agree with you that we now need to move forward much more quickly. > > Anyway, I have no doubt to use the handwaving approach. I'm also anxious to > hear what Jamal thinks. I agree we need to move past this IO stall but lets verify that the implicit approach will work. Heres an attempt at listing the requirements: 1) Reliability: A ACK flag on the header should be sufficient on the header. 2) Congestion control: I think this is a behavior of the TML that PL should have no control over, no? 3) HA: We may decide we want the PL to make decisions. Nothing in the protocol header is necessary; events from TML<->PL are necessary though 4) Security Like congestion control, PL has no say. 5) Uni/multi/broadcast addressing/delivery The FEid/CEid is all the PL cares about. The TML takes care of the rest. Somehow the PL needs to be notified of the semantics of the IDs. Or we could come up with a scheme like the one we started discussing much earlier on to have specific IDs allocated for different things. 6) Timeliness: Not sure how at this point. But one should be able to say "obsolete the message if it doesnt make it in 200ms". 7) Capability exchange I think this is again like CC and security the responsiblity of the TML?? 8)The FEM/CEM interface TML responsibility 9) Batching: Responsibility of PL and PL alone? 10) transactional operations (2pc etc) Responsibility of PL and PL alone? I may have missed others. Overall, it seems to me like the implicit approach should work. There are still some holes for example when i wanna ask for "just a little more from the TML" like #6 above. Another "just a little more" example would to say offload something like a LFB heartbeat from the PL and tell the TML: "I want you to send this msg unreliably, if you dont receive a response two times, i want you to attempt to deliver it reliably with two more retransmits and then tell me when that fails, otherwise i am not interested but i will ask you later for all failure stats" OK, that was long - but you get my message. Thoughts? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat Apr 24 23:47:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22500 for ; Sat, 24 Apr 2004 23:47:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHaVK-0004wW-Id for forces-protocol-archive@odin.ietf.org; Sat, 24 Apr 2004 23:40:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P3eU0h018995 for forces-protocol-archive@odin.ietf.org; Sat, 24 Apr 2004 23:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHaQa-0003Wr-E2 for forces-protocol-web-archive@optimus.ietf.org; Sat, 24 Apr 2004 23:35:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22055 for ; Sat, 24 Apr 2004 23:35:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHaQY-0006lq-EP for forces-protocol-web-archive@ietf.org; Sat, 24 Apr 2004 23:35:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHaPg-0006Y0-00 for forces-protocol-web-archive@ietf.org; Sat, 24 Apr 2004 23:34:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHaOr-0006KL-00 for forces-protocol-web-archive@ietf.org; Sat, 24 Apr 2004 23:33:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHaKC-0001Q8-Re; Sat, 24 Apr 2004 23:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHaFv-0007vN-VF for forces-protocol@optimus.ietf.org; Sat, 24 Apr 2004 23:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21580 for ; Sat, 24 Apr 2004 23:24:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHaFu-0004HD-0a for forces-protocol@ietf.org; Sat, 24 Apr 2004 23:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHaEw-000449-00 for forces-protocol@ietf.org; Sat, 24 Apr 2004 23:23:35 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BHaEV-0003qP-00 for forces-protocol@ietf.org; Sat, 24 Apr 2004 23:23: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 i3P3MfB3016058; Sun, 25 Apr 2004 03:22:41 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 i3P3MLIR024661; Sun, 25 Apr 2004 03:22:41 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 M2004042420222929275 ; Sat, 24 Apr 2004 20:22:29 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Apr 2004 20:22:29 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] PL/TML Interface Message-ID: <468F3FDA28AA87429AD807992E22D07EC02D40@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] PL/TML Interface Thread-Index: AcQpMHyYOJEzAmd+RAy/sBXrSEmQCgBQ2reA From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 25 Apr 2004 03:22:29.0307 (UTC) FILETIME=[8A0060B0:01C42A74] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 24 Apr 2004 20:22:28 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, Weiming Thanks for your replies. It seems like we have come to a consensus on the hand-waving or implicit approach, which is great. I'll post some text on the other topics. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, April 23, 2004 5:43 AM To: Wang,Weiming Cc: forces-protocol@ietf.org; Khosravi, Hormuzd M Subject: Re: [Forces-protocol] PL/TML Interface Weimig/Hormuzd, Apologies for disappearing - important customer fire. On Fri, 2004-04-23 at 00:00, Wang,Weiming wrote: > Hormuzd, >=20 > My understandind of handwaving approach David presented below using multicast > add route as an example is that the FEid(s) and the message type is used as a > waving signal to TML to implicitly ask for the defined service in the TML. This > is opposite to the explicit approach in that the latter may use an explicit flag > to indicate such service requirement. Do I misunderstand something here? >=20 I think it is implicit unless i misread it. I dont see the PL worrying about sending a list of FEids though. I think that should be the TMLs problem. PL sends a single address (CE/FEid), the TML may translate or rewrite it. To take an example of a PL sending a broad/multicast FEid: -if TML is capable of broad/multicast, the single message is sent. - if TML is not capable of broad/multicast, then it will take that FEid, do an internal lookup, come up with a list of unicast FEids and unicast-send to each.=20 > Actually my another thought (as I posted before) is to let the protocol layer > more flexible to use TML by allowing some configurations from Pl to TML based on > the TML capabilities . The configuration may be some thing like "ple use #xx > service template for message type xx when the message asks for multicast". This I think that message type alone is insufficient. Since message type is a static item, we need flags to override default behaviors.=20 To borrow an example from netlink2, we used the ACK flag to indicate that a message/transaction was to be reliably delivered. Even on an example of an ADD ROUTE, if i choose not to have a specific ADD ROUTE reliably delivered for whatever reason, i should be able to override the message type decision by NOT setting the ACK flag. Corrollary: In a message type where reliability is not needed, i should still be able to request for a specific message to be reliably delivered by setting a flag such as the ACK. TMLs should be defining something of the nature: 1) This TML is capable of both unicast and multicast 2) When a message has to be delivered reliably, operation is: send on multicast UDP, if no response send on TCP and wait for upto y seconds for a response. Notify PL on success if it asked for ACK. Notify PL on failure always. 3) etc > approach is actually consistent with the handwaving approach, only with more > flexibility in that protocol customers may have more choices other than that > defined by TML requirements. I think this is also useful for more flexible > vendor supports. But I just don't want to push this too hard now because I > agree with you that we now need to move forward much more quickly. >=20 > Anyway, I have no doubt to use the handwaving approach. I'm also anxious to > hear what Jamal thinks. I agree we need to move past this IO stall but lets verify that the implicit approach will work. Heres an attempt at listing the requirements: 1) Reliability: A ACK flag on the header should be sufficient on the header. 2) Congestion control: I think this is a behavior of the TML that PL should have no control over, no? 3) HA: We may decide we want the PL to make decisions. Nothing in the protocol header is necessary; events from TML<->PL are necessary though 4) Security Like congestion control, PL has no say. 5) Uni/multi/broadcast addressing/delivery The FEid/CEid is all the PL cares about. The TML takes care of the rest. Somehow the PL needs to be notified of the semantics of the IDs. Or we could come up with a scheme like the one we started discussing much earlier on to have specific IDs allocated for different things. 6) Timeliness: Not sure how at this point. But one should be able to say "obsolete the message if it doesnt make it in 200ms". 7) Capability exchange I think this is again like CC and security the responsiblity of the TML?? 8)The FEM/CEM interface TML responsibility 9) Batching: Responsibility of PL and PL alone? 10) transactional operations (2pc etc) Responsibility of PL and PL alone? I may have missed others. Overall, it seems to me like the implicit approach should work.=20 There are still some holes for example when i wanna ask for "just a little more from the TML" like #6 above. Another "just a little more" example would to say offload something like a LFB heartbeat from the PL and tell the TML: "I want you to send this msg unreliably, if you dont receive a response two times, i want you to attempt to deliver it reliably with two more retransmits and then tell me when that fails, otherwise i am not interested but i will ask you later for all failure stats" OK, that was long - but you get my message. Thoughts? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun Apr 25 02:27:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13061 for ; Sun, 25 Apr 2004 02:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHd5e-0007uk-5Z for forces-protocol-archive@odin.ietf.org; Sun, 25 Apr 2004 02:26:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3P6QA9I030423 for forces-protocol-archive@odin.ietf.org; Sun, 25 Apr 2004 02:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHd1Z-0005tt-7q for forces-protocol-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 02:21:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12747 for ; Sun, 25 Apr 2004 02:21: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 1BHd1V-0007jF-Ol for forces-protocol-web-archive@ietf.org; Sun, 25 Apr 2004 02:21:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHd0M-0007TZ-00 for forces-protocol-web-archive@ietf.org; Sun, 25 Apr 2004 02:20:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHczy-0007Fw-00 for forces-protocol-web-archive@ietf.org; Sun, 25 Apr 2004 02:20:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcuq-00025b-KK; Sun, 25 Apr 2004 02:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHcqh-0007w9-RF for forces-protocol@optimus.ietf.org; Sun, 25 Apr 2004 02:10:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09469 for ; Sun, 25 Apr 2004 02:10: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 1BHcqe-00052n-7g for forces-protocol@ietf.org; Sun, 25 Apr 2004 02:10:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHcpl-0004oV-00 for forces-protocol@ietf.org; Sun, 25 Apr 2004 02:09:46 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BHcp3-0004ag-00 for forces-protocol@ietf.org; Sun, 25 Apr 2004 02:09:02 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sun, 25 Apr 2004 14:21:21 +0800 Message-ID: <016f01c42a8b$5306ecc0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EB8CA04@orsmsx408.jf.intel.com> <011301c428e7$8a00ef50$845c21d2@Necom.hzic.edu.cn> <1082724161.1058.74.camel@jzny.localdomain> Subject: Re: [Forces-protocol] PL/TML Interface 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Apr 2004 14:05:31 +0800 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 Jamal, Hormuzd, ----- Original Message ----- From: "Jamal Hadi Salim" > Weimig/Hormuzd, > Apologies for disappearing - important customer fire. > > On Fri, 2004-04-23 at 00:00, Wang,Weiming wrote: > > Hormuzd, > > > > My understandind of handwaving approach David presented below using multicast > > add route as an example is that the FEid(s) and the message type is used as a > > waving signal to TML to implicitly ask for the defined service in the TML. This > > is opposite to the explicit approach in that the latter may use an explicit flag > > to indicate such service requirement. Do I misunderstand something here? > > > > I think it is implicit unless i misread it. I dont see the PL worrying > about sending a list of FEids though. I think that should be the TMLs > problem. PL sends a single address (CE/FEid), the TML may translate or > rewrite it. > To take an example of a PL sending a broad/multicast FEid: > -if TML is capable of broad/multicast, the single message is sent. > - if TML is not capable of broad/multicast, then it will take that FEid, > do an internal lookup, come up with a list of unicast FEids and > unicast-send to each. [Weiming] Agreed. The only remained question to me is how and when the multicast FEid/CEid is configured. We know it is not a problem to the broadcast FEid/CEid, which can be predefined by CEM/FEM as for the actual FEs/CEs address mapping table, but my original thought on FE multicast is it is a dynamical one, that is, the mapping to actual groups of CEs/FEs may be setup or deleted according to system need. If so, then I still can not catch how and when this can be done? Shall we say that the multicast can only be preset, just the same as for broadcast case? Or, shall we say the CEM/FEM will always be running all the time, even during the post-assiciation phase, so that the multicast mapping table can be set on the fly? [/Weiming] > > > Actually my another thought (as I posted before) is to let the protocol layer > > more flexible to use TML by allowing some configurations from Pl to TML based on > > the TML capabilities . The configuration may be some thing like "ple use #xx > > service template for message type xx when the message asks for multicast". This > > I think that message type alone is insufficient. Since message type is a > static item, we need flags to override default behaviors. [Weiming]Agreed. Actually I think we now have had three items considered as static implicit signals: the message type, the FEid/CEid, the priority flag(I suppose). > To borrow an example from netlink2, we used the ACK flag to indicate > that a message/transaction was to be reliably delivered. > Even on an example of an ADD ROUTE, if i choose not to have a specific > ADD ROUTE reliably delivered for whatever reason, i should be able to > override the message type decision by NOT setting the ACK flag. > Corrollary: In a message type where reliability is not needed, i should > still be able to request for a specific message to be reliably delivered > by setting a flag such as the ACK. [Weiming]Although I agree adding ACK with TML meaning is of help to more flexible TML use, I just a little worry if such will add complexity for customers, that is, they should be very familiar with and always remember the ACK TML meaning when they use the flag. I wonder if in the end they may tend to only remember original meaning of asking for ACK feadback. I also wonder if there is a scenario where they only want to have the ACK meaning for the flag. Anyway, we can have this in mind and move forward. [/Weiming] > TMLs should be defining something of the nature: > 1) This TML is capable of both unicast and multicast > 2) When a message has to be delivered reliably, operation is: > send on multicast UDP, if no response send on TCP and wait for upto y > seconds for a response. Notify PL on success if it asked for ACK. Notify > PL on failure always. > 3) etc [Weiming]Agreed to 1), and partially to 2). I think we may be able to define more than one service template like 2). When reading 2), I also think of another issue. That is, if we allow a service template to have parameters like the 'y' in your 2). This may add more flexibility but will eventally make some implicit waving approach unable to do so. > > > approach is actually consistent with the handwaving approach, only with more > > flexibility in that protocol customers may have more choices other than that > > defined by TML requirements. I think this is also useful for more flexible > > vendor supports. But I just don't want to push this too hard now because I > > agree with you that we now need to move forward much more quickly. > > > > Anyway, I have no doubt to use the handwaving approach. I'm also anxious to > > hear what Jamal thinks. > > I agree we need to move past this IO stall but lets verify that the > implicit approach will work. Heres an attempt at listing the > requirements: > > 1) Reliability: > A ACK flag on the header should be sufficient on the header. [Weiming]I also agree Hormuzd's idea that message type can surely show some reliability requirements to TML. > 2) Congestion control: > I think this is a behavior of the TML that PL should have no control > over, no? [Weiming]If CEM/FEM have the ability to setup some congestion control policies, I think this is ok for PL not to do more. > 3) HA: > We may decide we want the PL to make decisions. Nothing in the protocol > header is necessary; events from TML<->PL are necessary though > [Weiming]Shall PL takes some actions when it receives events from TML regarding HA? Or can we use a HA policy attribute to reconfigure the HA in TML based on the events? > 4) Security > Like congestion control, PL has no say. [Weiming]Agreed. > > 5) Uni/multi/broadcast addressing/delivery > The FEid/CEid is all the PL cares about. The TML takes care of the rest. > Somehow the PL needs to be notified of the semantics of the IDs. > Or we could come up with a scheme like the one we started discussing > much earlier on to have specific IDs allocated for different things. [Weiming]I more incline to the schem the FEid/CEID care about everything on the U/M/B in PL. If we can ask the CEM to notify CE, and FEM to FE, of the IDs semantics? > > 6) Timeliness: > Not sure how at this point. But one should be able to say > "obsolete the message if it doesnt make it in 200ms". [Weiming]If the TML policy scheme (as FE attribute that can be set by PL) can be used, I think this can be resolved. > > 7) Capability exchange > I think this is again like CC and security the responsiblity of the > TML?? [Weiming]The capability exchange between TMLs should not be seen by PL. But if you also mean capability change, I think PL should know something. > > 8)The FEM/CEM interface > TML responsibility > 9) Batching: > Responsibility of PL and PL alone? > 10) transactional operations (2pc etc) > Responsibility of PL and PL alone? > [Weiming]Agreed to above all. > I may have missed others. > > Overall, it seems to me like the implicit approach should work. > There are still some holes for example when i wanna ask for "just a > little more from the TML" like #6 above. Another "just a little more" > example would to say offload something like a LFB heartbeat from the PL > and tell the TML: > "I want you to send this msg unreliably, if you dont receive a response > two times, i want you to attempt to deliver it reliably with two more > retransmits and then tell me when that fails, otherwise i am not > interested but i will ask you later for all failure stats" > OK, that was long - but you get my message. [Weiming] as my comments on #6, if TML policy is used, may help in some way for this. > Thoughts? [Weiming]Seems we have made some progress. > > cheers, > jamal Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 01:26:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09340 for ; Mon, 26 Apr 2004 01:26:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHybm-0003Pf-03 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 01:24:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q5OjkY013115 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 01:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyal-000387-86 for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 01:23:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09230 for ; Mon, 26 Apr 2004 01:23: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 1BHyai-0004dj-7z for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:23:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHyZu-0004Rb-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:22:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHyZB-0004FO-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:22:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyWD-0001Yn-6P; Mon, 26 Apr 2004 01:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHySy-0000yz-Px for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 01:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08993 for ; Mon, 26 Apr 2004 01:15:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHySv-00034r-ML for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:15:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHyS3-0002tf-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:14:44 -0400 Received: from fmr99.intel.com ([192.55.52.32] helo=hermes-pilot.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BHyRR-0002fW-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:14:05 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.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 i3Q5Dj7r000832; Mon, 26 Apr 2004 05:13:45 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3Q5DY6H003473; Mon, 26 Apr 2004 05:13:37 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 M2004042522132519339 ; Sun, 25 Apr 2004 22:13:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 22:13:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] PL/TML Interface::topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC02DB8@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] PL/TML Interface::topic 1 Thread-Index: AcQpMHyYOJEzAmd+RAy/sBXrSEmQCgCGZhbg From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 26 Apr 2004 05:13:25.0646 (UTC) FILETIME=[33E6DAE0:01C42B4D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Apr 2004 22:13:25 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, Weiming, Just trying to summarize some of the requirements or services for TML, PL based on our discussions... TML Requirements/Services... 1. Reliability acc to Reqs (no data loss, data corruption 2. Security 3. Congestion Control 4. Uni/multi/broadcast addressing/delivery 5. Connection or Association State maintainance(helps with HA) Things that belong to PL... 1. PL level reliability using Acks/Responses 2. Timeliness, again using Acks 3. Batching 4. transactional operations (2pc etc) 5. Capability exchange (FE, LFB Caps) (BTW, not sure what Jamal means by this in context with TML?) 6. HA decisions Hope this is reasonably captures all the discussions. I was not sure about what you mean by FEM/CEM interface so I didn't mention that in this list. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 01:59:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10546 for ; Mon, 26 Apr 2004 01:59:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz7u-0003PG-6M for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 01:58:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q5vw1k013089 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 01:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz6g-00039G-Ke for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 01:56:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10428 for ; Mon, 26 Apr 2004 01:56:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHz6d-0003MP-Eb for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:56:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHz5c-00038u-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:55:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHz4h-0002xN-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:54:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz0E-0001WX-6G; Mon, 26 Apr 2004 01:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHyx2-0000f6-0i for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 01:46:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10198 for ; Mon, 26 Apr 2004 01:46: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 1BHywy-0001Tm-Mk for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:46:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHyw4-0001Hu-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:45:45 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BHyvV-00014V-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:45:09 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3Q5ijl9007700; Mon, 26 Apr 2004 05:44:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3Q5iM6Z023132; Mon, 26 Apr 2004 05:44:49 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 M2004042522443722178 ; Sun, 25 Apr 2004 22:44:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 22:44:37 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC02DBE@orsmsx408.jf.intel.com> Thread-Topic: topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtA From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , X-OriginalArrivalTime: 26 Apr 2004 05:44:37.0858 (UTC) FILETIME=[8FD3BC20:01C42B51] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] topic 2:: HA Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Apr 2004 22:44:37 -0700 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 Content-Transfer-Encoding: quoted-printable Hi All Here is my attempt to start some discussion on topic 2, we just have 1 week to complete All discussions so we need to move fast! Based on our discussions on TML and PL as well as the 3 schemes proposed by Jamal, here is my suggestion for HA scheme... At any time there is one Primary CE controlling the FE and there can be multiple secondary Ces. The FE PL is aware of the primary and secondary Ces. Only the primary CE is sending Control messages to the Fes. The FE may choose to send its events, redirection packets to all the Ces or only Primary CE (we need to decide one or keep this configurable ?). A CE-to-CE synchronization may be needed, however that is out of our current scope for ForCES PL. The association between the FE and primary CE may change based on the Connection State (triggered by TML) or an explicit message (such as Move, described by Jamal) from the primary CE. This scheme is similar to Scheme 2 proposed by Jamal with a few more details. Hope we can agree on this and move to the other topics. We can discuss more details around the Protocol Messages related to this scheme during topic:4.=20 Let me know what you guys think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 02:04:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15154 for ; Mon, 26 Apr 2004 02:04:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzBb-0005Hv-FT for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 02:01:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q61lUj020322 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 02:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz9Y-0003jX-GW for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 01:59:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10574 for ; Mon, 26 Apr 2004 01:59: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 1BHz9V-0003yX-5z for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:59:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHz8X-0003lu-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:58:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHz7d-0003a6-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 01:57:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz53-0002ho-Et; Mon, 26 Apr 2004 01:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHz1l-0001ih-EH for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 01:51:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10281 for ; Mon, 26 Apr 2004 01:51: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 1BHz1i-0002Pc-37 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:51:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHz0k-0002DF-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:50:35 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BHyzs-0001rP-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 01:49:40 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.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 i3Q5nFFT001186; Mon, 26 Apr 2004 05:49:15 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3Q5nL6F026282; Mon, 26 Apr 2004 05:49:21 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 M2004042522491022568 ; Sun, 25 Apr 2004 22:49:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Apr 2004 22:48:58 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42B52.2B393CE6" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC02DBF@orsmsx408.jf.intel.com> Thread-Topic: topic 3 clarification ? Thread-Index: AcQrUiri6AtxUor4QGCqxVGbbJu9lQ== From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 26 Apr 2004 05:48:58.0955 (UTC) FILETIME=[2B73F9B0:01C42B52] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] topic 3 clarification ? Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 25 Apr 2004 22:48:58 -0700 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,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42B52.2B393CE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jamal =20 Topic 3 is Capability Exchange, FEM/CEM. Could we discuss this in context with Topic 4: Protocol Messages, Scenarios, etc ? =20 Let me know what you think ? Its not clear to me what you meant by Capability Exchange, do you mean FE, LFB Capabilities or something else ? =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C42B52.2B393CE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Jamal
 
Topic = 3 is=20 Capability Exchange, FEM/CEM.
Could = we discuss=20 this in context with Topic 4: Protocol Messages, Scenarios, etc=20 ?
 
Let me = know what you=20 think ? Its not clear to me what you meant by Capability Exchange, do = you mean=20 FE, LFB Capabilities or something else ?
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C42B52.2B393CE6-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:25:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19152 for ; Mon, 26 Apr 2004 09:25:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5ze-0005Gs-Nl for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:17:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDHsTJ020262 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5t3-0003Pb-1x for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18411 for ; Mon, 26 Apr 2004 09:11: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 1BI5t1-0005eV-Ji for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:11:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5s7-0005bg-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:10:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5rj-0005YQ-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:09:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5nE-0000qy-Jb; Mon, 26 Apr 2004 09:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bP-0006wH-At for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 08:52:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16744 for ; Mon, 26 Apr 2004 08:52:48 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5bN-0003wb-I0 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:52:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5Zh-0003e3-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:51:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BI5XG-0003F1-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:48:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCmHB29501; Mon, 26 Apr 2004 15:48:17 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 15:47:49 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QClnSf000677; Mon, 26 Apr 2004 15:47:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LKV4Zi; Mon, 26 Apr 2004 15:47:47 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QClbJ04656; Mon, 26 Apr 2004 15:47:37 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 07:47:35 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] PL/TML Interface X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: PL/TML Interface Thread-Index: AcQjyW7Ef8iVsFLJRjyxYkasy4ZPcgCSeK/wAECJV4ABHTdG4A== To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 12:47:35.0029 (UTC) FILETIME=[A5CCBA50:01C42B8C] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:47:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello David, Comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Putzolu, David > Sent: Tuesday, April 20, 2004 4:55 PM > To: Gopal Ram (Nokia-NRC/Boston); hadi@znyx.com > Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org; > wmwang@mail.hzic.edu.cn > Subject: [Forces-protocol] PL/TML Interface >=20 >=20 > Hi all. >=20 > Still getting caught up on the discussions! >=20 > The protocol design team could define a PL/TML > API if desired. However, since APIs are not > currently in the charter, we would have to make > a case to the ADs for adding it. This might be > tough, because an intra-endpoint API is a=20 > different problem than the once ForCES protocol=20 > tackles. Agree, so far to my knowledge IETF has defined application level API's = only for FTP other than socket API's. As of now the forces has restricted usage (PL'layer). =20 =20 =20 > ForCES protocol tackles FE/CE interoperability. > A PL/TML API would be tackling intra-FE and intra-CE > interop between an implementer of the ForCES PL and > the implementer of the interconnect. This isn't a > bad idea at all - but the challenge would be convincing > the ADs that a standard API is needed here. > I'm not ruling it out - just letting you know that > we would need to make a good case for it to the ADs. >=20 >=20 > Using a implicit/PL header flags approach is also > feasible, although I'm a bit concerned in that I'm > not familiar with prior examples of such an approach. > Are there other cases where a protocol had header > fields to signal the protocol implementation on the > same endpoint, rather than to the other end of the > connection? =20 There are similar protocols like what we are dealing here, One that is = currently worked out is Midcom they define the message structure and payload = details and=20 left the transport mechanism as untouched. There focus is between on = midcom elements.=20 The draft states that this message structure is generic and can be = carried over=20 any transport prtocol.=20 Hormuzd also pointed out GSMP also seems taken the similar approach. IMHO, We cannot mandate TML layer requirements, they are there and we = need to use them as it is. Forces PL layer can work on IP, TCP or UDP or any layer-2 . As far as PL = is concerned TML layer can come and go, PL is the standardized interface = point.=20 My comments on your second part, another approach is that instead of = passing on thro' header fields TML=20 layer can be informed either via configuration or via some initial = message setup. This would be a nice=20 and cleaner approach. If you see any of the services like security, HA, = etc they are operated per session=20 basis and passing it on each message may not be cleaner approach. =20 =20 >=20 > Finally, there is the option of simply handwaving > and saying that implementers will implement the > system such that the TML is signaled appropriately. This is a good alternative. IMO it will be diffcult to mandate the TML layer with set of = requrirements. PL needs to live with it whatever the lower layer provides. IMHO this = will enable smooth integration (adoption) of Forces into existing interconnects rather than complete migration. =20 End of comments Regards Ramg > So for example: >=20 > The TML abstract definition section of the doc might say: > "A multicast, unreliable message-oriented service > is provided. Each message delivered to this > service includes an indication of which recipients > should receive the message. The service does not > guarantee reliable delivery but does guarantee > messages will not be corrupted and will be delivered > in order. This service is intended to be used > for timely delivery of information."=20 >=20 > The PL configuration section of the doc might say: =20 > "when adding an IP route to multiple FEs, the=20 > TML's multicast, unreliable message oriented service=20 > is used to deliver the following message to each > desired FE: > ------------------------------ > | (list if FEid/LFBid pairs) | > ------------------------------ > | new route | > ------------------------------ > Each FE scans the list of FEids and LFBid pairs > to see which of its LFBs should be given the > new route structure" >=20 > And the Ethernet TML doc might say: > "The multicast, unreliable message oriented service=20 > is implemented using Ethernet broadcast as follows: > the PL indicates the list of FEs and passes > down a PDU...the TML uses Ethernet broadcast > and the following header listing which FEs should > parse the message and includes a CRC and message > number for ensuring non-corruption and ordering: > --------------------------------- > | FEid, | > | ... | > | FEid | > --------------------------------- > | CRC-32 | > --------------------------------- > | Message # | > --------------------------------- > | Payload to deliver to each FE | > --------------------------------- >=20 > Finally, a PL implementer might implement it as a > generic (but proprietary) API that they define and > share with customers, e.g. > "FooCorp's implementation of ForCES includes a > TML abstraction API allowing customers to use > any interconnect. The API that an interconnect > must support for FooCorps' implementation to work > for multicast unreliable connections is=20 > void FooSendMulticast(addressee_type *addrAray,=20 > messageType m)" > (In this case m would correspond to the PL-defined > PDU shown in the PL config section above). >=20 > Sorry to jump in to the technical discussion -=20 > my original intention was to just clarify that we would > need to go to the ADs to define an API, and to ask if there > was precedent for using protocol header bits to signal > within an end point (as opposed to other endpoints). > I just can't resist a good technical discussion :) >=20 > -David >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:33:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19548 for ; Mon, 26 Apr 2004 09:33:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI69p-00084A-UU for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:28:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDSP6t031001 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI60V-0005P3-G3 for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:18:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18886 for ; Mon, 26 Apr 2004 09:18: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 1BI60T-0006Dz-Pq for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:18:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5zJ-00065l-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:17:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5yQ-0005wN-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:16:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5oM-0001Sa-Ma; Mon, 26 Apr 2004 09:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5gG-00087i-Kb for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 08:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17512 for ; Mon, 26 Apr 2004 08:57:49 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5gF-0004kC-6c for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:57:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5fS-0004fI-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:57:03 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI5e9-0004Q0-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:55:41 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCtU116386; Mon, 26 Apr 2004 15:55:30 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 15:54:21 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3QCsLMQ026824; Mon, 26 Apr 2004 15:54:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00tQ2BVw; Mon, 26 Apr 2004 15:54:19 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCsCF14021; Mon, 26 Apr 2004 15:54:12 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 07:53:57 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQm5QmOHTaJ51HxSOyJfqGSzDxLgwAZzj0wARA33DA= To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 12:53:57.0525 (UTC) FILETIME=[89C8FC50:01C42B8D] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:53:56 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Robert, Hormuzd, Comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Tuesday, April 20, 2004 11:09 PM > To: Robert Haas > Cc: hadi@znyx.com; Weiming Wang; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 >=20 >=20 > Hi Robert, >=20 > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com]=20 >=20 > On the reliability example: remember that ForCES-level reliability is=20 > somewhat orthogonal to transport-level reliability. At the=20 > ForCES level, >=20 > I want to get an ACK back from a FE to confirm that it could update a=20 > firewall rule successfully, for instance. >=20 > [HK] Sure, ForCES level reliability will be defined using=20 > Message Types > at the PL. > For example, a Configuration Response message could be defined to > provide an Ack at PL and also report the status of a Config Request > message. >=20 > So if I tag my ForCES message with "reliability enabled", the=20 > TML COULD=20 > choose to send it over TCP, but this is not mandatory, as using TCP=20 > alone is not going to be sufficient to ensure reliable=20 > processing at the >=20 > FE. Actually, the TML could choose UDP, as potential retransmissions=20 > anyay need to be taken care of at the PL level as well. >=20 > Or do you have different views ? Please explain. Hormuzd you are correct, We have two things one is reliable message = delivery (transport level acks) and reliable message execution at the = other endpoint( application (FE or CE endpoint) as acted on the request = and request has been serviced). Forces PL deals with second level, this also implies the first level of = relaiblity. Forces PL can leverage transport level reliablity if available from TML layer. Regards Ramg >=20 > [HK] I believe we will need Reliability at both the PL and the TML for > certain messages. The PL will define explicit messages such as > Responses/acks for providing PL level reliability. The TML will define > its own way for providing reliability, CC, etc. For example,=20 > the IP TML > may choose to use TCP or UDP to provide a certain service.=20 > The TIPC TML > will use TIPC for providing certain service. In the PL Team, we don't > need to be concerned about how the service is provided by the TML but > rather define what service the PL needs/requires from the TML. >=20 > Hope this provides some clarification, >=20 > Regards > Hormuzd >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:34:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19629 for ; Mon, 26 Apr 2004 09:34:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6CE-0000rz-Dh for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:30:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDUs1x003339 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI60n-0005R3-TU for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18931 for ; Mon, 26 Apr 2004 09:19: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 1BI60m-0006H2-0l for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:19:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5zx-0006A3-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:18:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5yy-000618-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:17:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5oO-0001Sw-Lg; Mon, 26 Apr 2004 09:06:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5jE-00006j-3z for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 09:00:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17642 for ; Mon, 26 Apr 2004 09:00:53 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5jC-0004tR-Lq for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:00:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5iM-0004rg-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:00:03 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI5i1-0004pn-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 08:59:41 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCxX121058; Mon, 26 Apr 2004 15:59:33 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 15:59:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QCxUqs018082; Mon, 26 Apr 2004 15:59:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00SVqWk4; Mon, 26 Apr 2004 15:59:29 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QCxKJ12096; Mon, 26 Apr 2004 15:59:20 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 07:58:43 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQoM9QmyU9XQcdrTnC3DTZ2m5LhaQDWf0dw To: , , X-OriginalArrivalTime: 26 Apr 2004 12:58:43.0005 (UTC) FILETIME=[33F1C6D0:01C42B8E] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 08:58:41 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Wang,Weiming > Sent: Thursday, April 22, 2004 2:20 AM > To: Khosravi, Hormuzd M; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 >=20 >=20 > Hi Hormuzd, >=20 > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > Hi Weiming, >=20 > I used Reliability as an example below but that can be easily extended > to other services. >=20 > Let me give a more concrete example which we have already discussed in > the past... >=20 > For all control messages (message types A-X), the PL will require the > following services from TML...Strict Reliability, Congestion Control, > Security. (Not sure about HA at this point, we need to discuss that > further) > For all data messages (message types Y-Z), the PL will require the > following services from TML... Congestion Control, Security. >=20 > [Weiming] We may need to consider more cases on this, e.g.,=20 > even for the same > message type, messages may have different TML requirements,=20 > e.g., for evnet > messages, failure report event should be strictly reliably and timely > transmitted, while things like heartbeat signals actually=20 > don't have the > requirements. > [/Weiming] We need to mandate for what messages relibality is must and for what = messages=20 it is not a must. For example certain services TML layer needs to = depend upon its lower layer for triggers etc. HA services. Those we cannot really = mandate thro' the=20 protocol operations to TML layer. \ >=20 > As for TML capability, etc we can push that as part of pre-association > phase (FEM, CEM) or even before that (compile, integration time). I > don't think we should be concerned with that in the PL team. >=20 > [Weiming] This is a long lasting question that I think we=20 > have not resolved very > well, that is, if we need to go back to pre-association again=20 > when some TML > change happens( link failure, CE failure, etc) during the=20 > post-assoc., and how > we go back? Or we just let the protocop layer to deal with=20 > such change? > Yes this is a better approach to push as part of CEM and FEM = configuration. =20 > Cheers, > Weiming >=20 >=20 >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:43:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19989 for ; Mon, 26 Apr 2004 09:43:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Fb-0002Ho-S4 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:34:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDYNkp008783 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6BU-0000QJ-AB for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19429 for ; Mon, 26 Apr 2004 09:30:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6BR-0006q5-PS for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:30:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6AZ-0006nZ-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:29:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6AA-0006jf-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:28:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI60j-0005QV-3H; Mon, 26 Apr 2004 09:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5tx-0003ds-H6 for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 09:12:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18458 for ; Mon, 26 Apr 2004 09:11:58 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5tw-0005hR-2M for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5t2-0005en-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:11:05 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BI5sA-0005bw-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:10:10 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDA2D03894; Mon, 26 Apr 2004 16:10:02 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 16:09:47 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3QD9l6X012732; Mon, 26 Apr 2004 16:09:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00kVdwCR; Mon, 26 Apr 2004 16:06:52 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QD6UF21672; Mon, 26 Apr 2004 16:06:30 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 08:06:27 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQoMzF738oks4LBQHiFQfcQKWDtuwAYsCAwAL4VErA= To: , , X-OriginalArrivalTime: 26 Apr 2004 13:06:27.0950 (UTC) FILETIME=[4912C0E0:01C42B8F] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:06:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello , Comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Thursday, April 22, 2004 2:26 PM > To: Wang,Weiming; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 >=20 >=20 > Hi Weiming, >=20 > My comments inline below... > -----Original Message----- >=20 > I used Reliability as an example below but that can be easily extended > to other services. >=20 > Let me give a more concrete example which we have already discussed in > the past... >=20 > For all control messages (message types A-X), the PL will require the > following services from TML...Strict Reliability, Congestion Control, > Security. (Not sure about HA at this point, we need to discuss that > further) > For all data messages (message types Y-Z), the PL will require the > following services from TML... Congestion Control, Security. >=20 > [Weiming] We may need to consider more cases on this, e.g.,=20 > even for the > same > message type, messages may have different TML requirements, e.g., for > evnet > messages, failure report event should be strictly reliably and timely > transmitted, while things like heartbeat signals actually=20 > don't have the > requirements. > [/Weiming] >=20 > [HK] Yes we could define separate requirements for HBs since they have > been separated in the Requirements RFC as well. But I am not sure if > that is a good idea, there were some email exchanges on the=20 > ForCES list > between Joel Halpern and some folks, and Joel made some good=20 > points. If > you get the chance to refer to those, they were good discussions. >=20 We need to generalize the requirements, if we develope a protocol = reqiurements for each messages then it will be complex. Since we have to address to some degree of HA and failure notification = of remote node etc. We need a detection mechanism and also a mechanism to report that to other = endpoints. Typically Heart Beat messages are request/response and are dealt at various levels.=20 I think this example is going out of track for me. > As for TML capability, etc we can push that as part of pre-association > phase (FEM, CEM) or even before that (compile, integration time). I > don't think we should be concerned with that in the PL team. >=20 > [Weiming] This is a long lasting question that I think we have not > resolved very > well, that is, if we need to go back to pre-association again=20 > when some > TML > change happens( link failure, CE failure, etc) during the post-assoc., > and how > we go back? Or we just let the protocop layer to deal with=20 > such change? >=20 > [HK] Events like Link Failure, CE failure will be delivered to the PL > from the TML so I don't think this is an issue. May be I am missing > something here, but seems like we are spending a lot more=20 > cycles on TML > discussion than we should be on this team. This depends upon what functionality goes inside the TML. Link failure = and dead peer detection requires both cooperation from TML and PL. HA functionality - = session switchover operation requires support from TML. Many of TML configuration are = session specific rather than message specific. =20 Regards Ramg _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:54:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20570 for ; Mon, 26 Apr 2004 09:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6R7-0005xb-8g for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDkHIH022905 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Iy-0003Ov-Ij for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:37:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19825 for ; Mon, 26 Apr 2004 09:37: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 1BI6Iw-0007EV-IW for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6ID-0007CJ-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:37:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6HT-0007A3-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6DU-0001c6-U0; Mon, 26 Apr 2004 09:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI61f-0005WE-Bw for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 09:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19012 for ; Mon, 26 Apr 2004 09:19:55 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI61d-0006KA-5z for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI60e-0006GA-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:18:57 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BI5zh-00067k-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:17:57 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDHes15031; Mon, 26 Apr 2004 16:17:40 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 16:17:06 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3QDH6Tx007228; Mon, 26 Apr 2004 16:17:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00t6fvOc; Mon, 26 Apr 2004 16:12:58 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDCoF26378; Mon, 26 Apr 2004 16:12:51 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 08:12:56 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] PL/TML Interface X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Forces-protocol] PL/TML Interface Thread-Index: AcQpMHyYOJEzAmd+RAy/sBXrSEmQCgBQ2reAAEbqxfA= To: , , Cc: X-OriginalArrivalTime: 26 Apr 2004 13:12:56.0028 (UTC) FILETIME=[3062C1C0:01C42B90] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:12:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Saturday, April 24, 2004 11:22 PM > To: hadi@znyx.com; Wang,Weiming > Cc: forces-protocol@ietf.org > Subject: RE: [Forces-protocol] PL/TML Interface >=20 >=20 > Hi Jamal, Weiming >=20 > Thanks for your replies. It seems like we have come to a consensus on > the hand-waving or implicit approach, which is great. I'll post some > text on the other topics. >=20 > Regards > Hormuzd >=20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > Sent: Friday, April 23, 2004 5:43 AM > To: Wang,Weiming > Cc: forces-protocol@ietf.org; Khosravi, Hormuzd M > Subject: Re: [Forces-protocol] PL/TML Interface >=20 > Weimig/Hormuzd, > Apologies for disappearing - important customer fire. >=20 > On Fri, 2004-04-23 at 00:00, Wang,Weiming wrote: > > Hormuzd, > >=20 > > My understandind of handwaving approach David presented below using > multicast > > add route as an example is that the FEid(s) and the message type is > used as a > > waving signal to TML to implicitly ask for the defined=20 > service in the > TML. This > > is opposite to the explicit approach in that the latter may use an > explicit flag > > to indicate such service requirement. Do I misunderstand something > here? > >=20 >=20 > I think it is implicit unless i misread it. I dont see the PL worrying > about sending a list of FEids though. I think that should be the TMLs > problem. PL sends a single address (CE/FEid), the TML may translate or > rewrite it. > To take an example of a PL sending a broad/multicast FEid: > -if TML is capable of broad/multicast, the single message is sent. > - if TML is not capable of broad/multicast, then it will take=20 > that FEid, > do an internal lookup, come up with a list of unicast FEids and > unicast-send to each.=20 >=20 > > Actually my another thought (as I posted before) is to let the > protocol layer > > more flexible to use TML by allowing some configurations from Pl to > TML based on > > the TML capabilities . The configuration may be some thing like "ple > use #xx > > service template for message type xx when the message asks for > multicast". This >=20 > I think that message type alone is insufficient. Since=20 > message type is a > static item, we need flags to override default behaviors.=20 > To borrow an example from netlink2, we used the ACK flag to indicate > that a message/transaction was to be reliably delivered. > Even on an example of an ADD ROUTE, if i choose not to have a specific > ADD ROUTE reliably delivered for whatever reason, i should be able to > override the message type decision by NOT setting the ACK flag. > Corrollary: In a message type where reliability is not=20 > needed, i should > still be able to request for a specific message to be=20 > reliably delivered > by setting a flag such as the ACK. >=20 > TMLs should be defining something of the nature: > 1) This TML is capable of both unicast and multicast > 2) When a message has to be delivered reliably, operation is: > send on multicast UDP, if no response send on TCP and wait for upto y > seconds for a response. Notify PL on success if it asked for=20 > ACK. Notify > PL on failure always. > 3) etc >=20 > > approach is actually consistent with the handwaving approach, only > with more > > flexibility in that protocol customers may have more choices other > than that > > defined by TML requirements. I think this is also useful for more > flexible > > vendor supports. But I just don't want to push this too hard now > because I > > agree with you that we now need to move forward much more quickly. > >=20 > > Anyway, I have no doubt to use the handwaving approach. I'm also > anxious to > > hear what Jamal thinks. >=20 > I agree we need to move past this IO stall but lets verify that the > implicit approach will work. Heres an attempt at listing the > requirements: >=20 > 1) Reliability: > A ACK flag on the header should be sufficient on the header. > 2) Congestion control: > I think this is a behavior of the TML that PL should have no control > over, no? > 3) HA: > We may decide we want the PL to make decisions. Nothing in=20 > the protocol > header is necessary; events from TML<->PL are necessary though TML needs to be informed how it needs to interact with CE and FE's.=20 FE and CE's may have specific configuration. Either that needs to be conveyed to TML eitehr during the startup or during the configuration. Switchover operations can be dynamic and requires dynamic reassocition = for HA, this reqiures updates from PL layer to TML otherwise TML will be = opearation on=20 stale configuration. >=20 > 4) Security > Like congestion control, PL has no say. >=20 > 5) Uni/multi/broadcast addressing/delivery > The FEid/CEid is all the PL cares about. The TML takes care=20 > of the rest. > Somehow the PL needs to be notified of the semantics of the IDs. > Or we could come up with a scheme like the one we started discussing > much earlier on to have specific IDs allocated for different things. >=20 > 6) Timeliness: > Not sure how at this point. But one should be able to say > "obsolete the message if it doesnt make it in 200ms". >=20 > 7) Capability exchange > I think this is again like CC and security the responsiblity of the > TML?? PL has a play in this. >=20 > 8)The FEM/CEM interface > TML responsibility >=20 > 9) Batching: > Responsibility of PL and PL alone? >=20 > 10) transactional operations (2pc etc) > Responsibility of PL and PL alone? >=20 > I may have missed others. >=20 > Overall, it seems to me like the implicit approach should work.=20 > There are still some holes for example when i wanna ask for "just a > little more from the TML" like #6 above. Another "just a little more" > example would to say offload something like a LFB heartbeat=20 > from the PL > and tell the TML: > "I want you to send this msg unreliably, if you dont receive=20 > a response > two times, i want you to attempt to deliver it reliably with two more > retransmits and then tell me when that fails, otherwise i am not > interested but i will ask you later for all failure stats" > OK, that was long - but you get my message. >=20 > Thoughts? >=20 > cheers, > jamal >=20 Regards Ramg >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 09:55:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20656 for ; Mon, 26 Apr 2004 09:55:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6R7-0005xz-QA for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDkH09022930 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 09:46:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6J2-0003PJ-01 for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:37:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19837 for ; Mon, 26 Apr 2004 09:37:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6Iz-0007Eq-Aq for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6IG-0007Cp-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:37:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6Hd-0007AB-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:36:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Dh-0001cc-Vr; Mon, 26 Apr 2004 09:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI63V-000631-VX for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 09:21:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19088 for ; Mon, 26 Apr 2004 09:21:50 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI63U-0006Ql-5e for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:21:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI62g-0006Om-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:21:03 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BI61n-0006Lb-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:20:21 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDJks18107; Mon, 26 Apr 2004 16:19:50 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 16:19:41 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3QDJfQL015173; Mon, 26 Apr 2004 16:19:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LVDbUC; Mon, 26 Apr 2004 16:19:40 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDJHJ25411; Mon, 26 Apr 2004 16:19:17 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 08:16:56 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] PL/TML Interface::topic 1 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Forces-protocol] PL/TML Interface::topic 1 Thread-Index: AcQpMHyYOJEzAmd+RAy/sBXrSEmQCgCGZhbgABGLB8A= To: , , Cc: X-OriginalArrivalTime: 26 Apr 2004 13:16:56.0670 (UTC) FILETIME=[BFD1CFE0:01C42B90] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:16:55 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hormuzd, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Monday, April 26, 2004 1:13 AM > To: hadi@znyx.com; Wang,Weiming > Cc: forces-protocol@ietf.org > Subject: [Forces-protocol] PL/TML Interface::topic 1 >=20 >=20 > Jamal, Weiming, >=20 > Just trying to summarize some of the requirements or services for TML, > PL based on our discussions... >=20 > TML Requirements/Services... >=20 > 1. Reliability acc to Reqs (no data loss, data corruption > 2. Security > 3. Congestion Control > 4. Uni/multi/broadcast addressing/delivery > 5. Connection or Association State maintainance(helps with HA) >=20 - Add to point 5 for HA services - TML (eg., link layer triggers to = report link failure) and connection reassociation and state maintenance. =20 > Things that belong to PL... >=20 > 1. PL level reliability using Acks/Responses > 2. Timeliness, again using Acks > 3. Batching > 4. transactional operations (2pc etc) > 5. Capability exchange (FE, LFB Caps) (BTW, not sure what=20 > Jamal means by > this in context with TML?) > 6. HA decisions=20 - Here for HA decision (dead peer detection and switch operations) - FE and CE's PL layer also needs to be part of intial capability = exchange.=20 >=20 >=20 > Hope this is reasonably captures all the discussions. I was not sure > about what you mean by FEM/CEM interface so I didn't mention that in > this list. >=20 > regards > Hormuzd >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 10:07:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21663 for ; Mon, 26 Apr 2004 10:07:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6eY-0001jH-Gc for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 10:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QE0AKb006642 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 10:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Wo-0007a4-MC for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:52:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20498 for ; Mon, 26 Apr 2004 09:52: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 1BI6Wl-0000H0-TR for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:52:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6Vw-0000Du-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:51:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI6VA-00009y-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 09:50:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6Qq-0005w6-OI; Mon, 26 Apr 2004 09:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6H5-0002mH-7Q for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 09:35:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19716 for ; Mon, 26 Apr 2004 09:35:51 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6H3-00077G-4I for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:35:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6GA-00074X-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:34:59 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BI6FF-000715-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 09:34:01 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDXkG02702; Mon, 26 Apr 2004 16:33:46 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 16:33:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3QDXJ72021928; Mon, 26 Apr 2004 16:33:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00hWpCrM; Mon, 26 Apr 2004 16:28:49 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QDSVF06033; Mon, 26 Apr 2004 16:28:31 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 08:26:52 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] topic 2:: HA X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtAABC4WsA= To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 13:26:52.0419 (UTC) FILETIME=[22E9E530:01C42B92] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:26:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, We have three cases. CE-to-CE(s) (common HA mechanism but outside the scope of charter) CE(s)-to-FE (currently within the scope) FE-to-FE (outside the scope). More comments are inline. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Monday, April 26, 2004 1:45 AM > To: forces-protocol@ietf.org > Cc: hadi@znyx.com; Wang,Weiming; avri@acm.org > Subject: [Forces-protocol] topic 2:: HA >=20 >=20 > Hi All >=20 > Here is my attempt to start some discussion on topic 2, we just have 1 > week to complete All discussions so we need to move fast! >=20 > Based on our discussions on TML and PL as well as the 3=20 > schemes proposed > by Jamal, here is my suggestion for HA scheme... >=20 > At any time there is one Primary CE controlling the FE and=20 > there can be > multiple secondary Ces. The FE PL is aware of the primary and=20 > secondary > Ces. Only the primary CE is sending Control messages to the=20 > Fes. The FE > may choose to send its events, redirection packets to all the Ces or > only Primary CE (we need to decide one or keep this configurable ?). A > CE-to-CE synchronization may be needed, however that is out of our > current scope for ForCES PL. The association between the FE=20 > and primary > CE may change based on the Connection State (triggered by TML) or an > explicit message (such as Move, described by Jamal) from the=20 > primary CE. As CE's are maste,we have two levels of issues. One is remote endpoint = is dead and another=20 is link failure(very rare to happen in single box scenarion, but = possible in multi hop situation). Consider a case CE1 & CE2 are master and slave respectively for FE-1. = FE-2 is an standby for FE-1. When CE-1 detects the link failure, it may will wake up alternative FE = (say FE-2). But FE-1 informs CE-2=20 that CE-1 has failed. But CE-1 and CE-2 are already in the loop. In this = scenario, CE(s) is the master and=20 CE-2 should inform the FE-1 to be pulled out. There are other such scenario's we can derive. Since CE is the = controlling authority and we are=20 assuming that there is CE to CE synchornization taking place, link layer = failure cases are different than the remote peer detection. I would request we should block set of ID's in CE and FE's space to have = smooth accomudatio of CE-to-CE protocol thro' our message strucuture also. >=20 > This scheme is similar to Scheme 2 proposed by Jamal with a few more > details. Hope we can agree on this and move to the other=20 > topics. We can > discuss more details around the Protocol Messages related to=20 > this scheme > during topic:4.=20 >=20 > Let me know what you guys think ? =20 Regards Ramg >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 11:53:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28671 for ; Mon, 26 Apr 2004 11:53:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8Ht-0006xH-Sl for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 11:44:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QFirKo026729 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 11:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8F6-0006Bm-5J for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 11:42:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28026 for ; Mon, 26 Apr 2004 11:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8F5-0007Qf-5w for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 11:41:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8EB-0007Ku-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 11:41:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI8DD-0007DV-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 11:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI84T-0002IJ-9L; Mon, 26 Apr 2004 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI7y0-0007Rs-7J for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 11:24:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26632 for ; Mon, 26 Apr 2004 11:24:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI7xz-0005xO-A8 for forces-protocol@ietf.org; Mon, 26 Apr 2004 11:24:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI7vd-0005qH-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 11:21:54 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BI7uV-0005g6-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 11:20:43 -0400 Received: from wwm1 (unverified [219.82.175.57]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Mon, 26 Apr 2004 23:32:35 +0800 Message-ID: <03a301c42ba1$717923f0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EC02DBE@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 2:: HA X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 23:16:23 +0800 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 Hi Hormuzd, Jamal, Ram, et al., ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All Here is my attempt to start some discussion on topic 2, we just have 1 week to complete All discussions so we need to move fast! Based on our discussions on TML and PL as well as the 3 schemes proposed by Jamal, here is my suggestion for HA scheme... At any time there is one Primary CE controlling the FE and there can be multiple secondary Ces. The FE PL is aware of the primary and secondary Ces. Only the primary CE is sending Control messages to the Fes. The FE may choose to send its events, redirection packets to all the Ces or only Primary CE (we need to decide one or keep this configurable ?). A [Weiming] Based on the fact that ForCES requirements and framework have explicitly defined CE-CE and FE-FE being out of scope of ForCES architecture (not only out of the ForCES protocol), and CE-CE syncronization should surely be supplied (by any means) by custumers when multi CEs are used, I suggest we limit FE to only be responsible for one CE at a time so as to simplify the case. Partial information like events, redirection packets in this case actually is of little use for the redundant CEs. CE-to-CE synchronization may be needed, however that is out of our current scope for ForCES PL. [Weiming] As I said above, this is even out of the scope of ForCES architecture, according to RFC3654. The association between the FE and primary CE may change based on the Connection State (triggered by TML) or an explicit message (such as Move, described by Jamal) from the primary CE. [Weiming] Regarding this, I strongly ask to let us answer the questions first "Is the TML only allowed to be statically configured, or can be configured dynamically by CEM/FEM?" If it is a static one, we then definitely need PL to have TML configuration ability (as I have posted for several times, and also Ram proposed), or else, if TML can be dynamically configured by CEM/FEM all the time during the protocol runtime, we then do not need to have the PL to do this. This rule also applies to CE change or failover, connection link failure, etc. From the TML-PL interface discussion and the HA discussion, I have a strong feeling that some TML configuration from PL layer based on, as Ram said, sessions are also in great demand as well as per message based implicit signaling. Hormuzd &Jamal, I hope you can give some comments on this. [/Weiming] Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 12:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02345 for ; Mon, 26 Apr 2004 12:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Bb-0000uW-LE for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 12:42:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGgRC0003496 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 12:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI95g-00075c-1W for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01162 for ; Mon, 26 Apr 2004 12:36:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI95e-0003mR-Dd for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:36:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI94b-0003g6-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:35:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI94A-0003cD-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:34:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8ui-00037K-Sf; Mon, 26 Apr 2004 12:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8ZW-00043m-74 for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:03:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29148 for ; Mon, 26 Apr 2004 12:03: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 1BI8ZU-0001Jz-I6 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:03:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8Yi-0001Fm-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:02:17 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI8Xi-00017r-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:01:15 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3QG0l09003688; Mon, 26 Apr 2004 16:00:47 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 i3QFumLV000559; Mon, 26 Apr 2004 15:59:09 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 M2004042609002820221 ; Mon, 26 Apr 2004 09:00:28 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 09:00:28 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC02F64@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQrpMFPp2FSlTKwSTOdOIr1u6jrhAAAahOA From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 26 Apr 2004 16:00:28.0862 (UTC) FILETIME=[98577DE0:01C42BA7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:00:24 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, Thanks for your comments. I am fine with your 1st 2 comments, I had a question on the 3rd. Why does TML configuration affect the association between the Primary CE and FE ? I must be missing something here. Pls do clarify this. BTW, to answer your question... "Is the TML only allowed to be statically configured, or can be configured dynamically by CEM/FEM?" I don't think we need to define this, the TML can be either statically configured or dynamically configure. BTW, what configuration are you referring to ? Also, I think we should have less dependence on CEM/FEM since this is not something in our scope either, otherwise it will be difficult to get a working implementation. So static configuration might be the best. Hope this helps, regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Here is my attempt to start some discussion on topic 2, we just have 1 week to complete All discussions so we need to move fast! Based on our discussions on TML and PL as well as the 3 schemes proposed by Jamal, here is my suggestion for HA scheme... At any time there is one Primary CE controlling the FE and there can be multiple secondary Ces. The FE PL is aware of the primary and secondary Ces. Only the primary CE is sending Control messages to the Fes. The FE may choose to send its events, redirection packets to all the Ces or only Primary CE (we need to decide one or keep this configurable ?). A [Weiming] Based on the fact that ForCES requirements and framework have explicitly defined CE-CE and FE-FE being out of scope of ForCES architecture (not only out of the ForCES protocol), and CE-CE syncronization should surely be supplied (by any means) by custumers when multi CEs are used, I suggest we limit FE to only be responsible for one CE at a time so as to simplify the case. Partial information like events, redirection packets in this case actually is of little use for the redundant CEs. [HK] Ok, I am fine with this CE-to-CE synchronization may be needed, however that is out of our current scope for ForCES PL. [Weiming] As I said above, this is even out of the scope of ForCES architecture, according to RFC3654. [HK] Agreed The association between the FE and primary CE may change based on the Connection State (triggered by TML) or an explicit message (such as Move, described by Jamal) from the primary CE. [Weiming] Regarding this, I strongly ask to let us answer the questions first "Is the TML only allowed to be statically configured, or can be configured dynamically by CEM/FEM?" If it is a static one, we then definitely need PL to have TML configuration ability (as I have posted for several times, and also Ram proposed), or else, if TML can be dynamically configured by CEM/FEM all the time during the protocol runtime, we then do not need to have the PL to do this. This rule also applies to CE change or failover, connection link failure, etc. From the TML-PL interface discussion and the HA discussion, I have a strong feeling that some TML configuration from PL layer based on, as Ram said, sessions are also in great demand as well as per message based implicit signaling. Hormuzd &Jamal, I hope you can give some comments on this. [/Weiming] Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:01:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02819 for ; Mon, 26 Apr 2004 13:01:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Oh-00055t-SE for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 12:56:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGtxNW019574 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 12:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Ak-0000lv-Ed for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:41:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01675 for ; Mon, 26 Apr 2004 12:41: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 1BI9Ai-0004Vj-SP for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:41:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9A4-0004Os-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:40:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI997-0004FY-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:39:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI91V-0005KN-8V; Mon, 26 Apr 2004 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8rp-0002AH-U8 for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:22:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00254 for ; Mon, 26 Apr 2004 12:21:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI8ro-0002jc-Co for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:22:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI8qv-0002gs-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:21:06 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI8q8-0002aU-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:20:16 -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 i3QGJh1m015225; Mon, 26 Apr 2004 16:19:43 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 i3QGI5KP014142; Mon, 26 Apr 2004 16:18:14 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 M2004042609193323695 ; Mon, 26 Apr 2004 09:19:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 09:19:34 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] PL/TML Interface::topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC02FC1@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] PL/TML Interface::topic 1 Thread-Index: AcQpMHyYOJEzAmd+RAy/sBXrSEmQCgCGZhbgABGLB8AABnhKQA== From: "Khosravi, Hormuzd M" To: , , Cc: X-OriginalArrivalTime: 26 Apr 2004 16:19:34.0011 (UTC) FILETIME=[42E75CB0:01C42BAA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:19:33 -0700 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 Content-Transfer-Encoding: quoted-printable Ram, Thanks for your comments. I am fine with your suggestions, I think they are mostly covered already. Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Monday, April 26, 2004 6:17 AM To: Khosravi, Hormuzd M; hadi@znyx.com; wmwang@mail.hzic.edu.cn Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] PL/TML Interface::topic 1 Hello Hormuzd, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Monday, April 26, 2004 1:13 AM > To: hadi@znyx.com; Wang,Weiming > Cc: forces-protocol@ietf.org > Subject: [Forces-protocol] PL/TML Interface::topic 1 >=20 >=20 > Jamal, Weiming, >=20 > Just trying to summarize some of the requirements or services for TML, > PL based on our discussions... >=20 > TML Requirements/Services... >=20 > 1. Reliability acc to Reqs (no data loss, data corruption > 2. Security > 3. Congestion Control > 4. Uni/multi/broadcast addressing/delivery > 5. Connection or Association State maintainance(helps with HA) >=20 - Add to point 5 for HA services - TML (eg., link layer triggers to report link failure) and connection reassociation and state maintenance. =20 > Things that belong to PL... >=20 > 1. PL level reliability using Acks/Responses > 2. Timeliness, again using Acks > 3. Batching > 4. transactional operations (2pc etc) > 5. Capability exchange (FE, LFB Caps) (BTW, not sure what=20 > Jamal means by > this in context with TML?) > 6. HA decisions=20 - Here for HA decision (dead peer detection and switch operations) - FE and CE's PL layer also needs to be part of intial capability exchange.=20 >=20 >=20 > Hope this is reasonably captures all the discussions. I was not sure > about what you mean by FEM/CEM interface so I didn't mention that in > this list. >=20 > regards > Hormuzd >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:11:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03440 for ; Mon, 26 Apr 2004 13:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9XJ-0008C0-H3 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:04:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QH4r90031483 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Os-00058h-CO for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02263 for ; Mon, 26 Apr 2004 12:56: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 1BI9Oq-0005ML-OJ for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:56:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Nr-0005Fn-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:55:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9My-0005Bz-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 12:54:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99K-0000Y7-IE; Mon, 26 Apr 2004 12:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI91Z-0005LP-5Q for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:32:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00933 for ; Mon, 26 Apr 2004 12:32: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 1BI91X-0003Sy-GP for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:32:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI90f-0003QQ-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:31:09 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI90I-0003My-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:30:47 -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 i3QGU81m022626; Mon, 26 Apr 2004 16:30:09 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 i3QGRHKr019873; Mon, 26 Apr 2004 16:28:40 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 M2004042609295925844 ; Mon, 26 Apr 2004 09:29:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 09:29:59 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC02FEA@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQoM9QmyU9XQcdrTnC3DTZ2m5LhaQDWf0dwAAcgicA= From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 26 Apr 2004 16:29:59.0437 (UTC) FILETIME=[B7AFCBD0:01C42BAB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:29:58 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, I think I understand what you mean now. I believe what you are asking is that, if there is a CE failure or TCP/UDP connection failure, how does the TML deal with this...right? I think the best approach will be to let the PL control this behavior. If the TML needs to be re-initialized and restarted after a failure, the PL can appropriately configure/control the TML...I don't think this belongs in the FEM, CEM. With the handwaving approach, this can be done without explicitly defining any procedures. However, we should add some text to the draft to explain this. Thanks for raising this point, regards Hormuzd >=20 > As for TML capability, etc we can push that as part of pre-association > phase (FEM, CEM) or even before that (compile, integration time). I > don't think we should be concerned with that in the PL team. >=20 > [Weiming] This is a long lasting question that I think we=20 > have not resolved very > well, that is, if we need to go back to pre-association again=20 > when some TML > change happens( link failure, CE failure, etc) during the=20 > post-assoc., and how > we go back? Or we just let the protocop layer to deal with=20 > such change? > Yes this is a better approach to push as part of CEM and FEM configuration. =20 > Cheers, > Weiming >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:18:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03945 for ; Mon, 26 Apr 2004 13:18:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9gg-0002c3-K7 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:14:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHEYbv010035 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9YW-00006V-4K for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:06:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03070 for ; Mon, 26 Apr 2004 13:06:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9YU-0006HV-94 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:06:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Xf-0006Dp-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:05:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9XF-0006A0-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:04:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Ok-00057i-3T; Mon, 26 Apr 2004 12:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9A5-0000k4-5r for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:40:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01568 for ; Mon, 26 Apr 2004 12:40: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 1BI9A3-0004OW-KZ for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:40:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI98v-0004FM-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:39:42 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BI986-00046j-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:38:50 -0400 Received: from wwm1 (unverified [219.82.175.57]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 27 Apr 2004 00:51:05 +0800 Message-ID: <03b101c42bac$6848b060$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EC02F64@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 2:: HA X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 00:34:54 +0800 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 Hi Hormuzd, Thank for your immediate reply. pls see more inline. BR, weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Why does TML configuration affect the association between the Primary CE and FE ? I must be missing something here. Pls do clarify this. [Weiming] My understanding of the re-association process of CE-FE is actually to re-configure the TML in some way. Of course, you may call it just a state change or a 'move' action, or whatever, which actually does not matter too much. What I actually mean is this process may then be able to be controlled by PL if we do not want CEM/FEM to do this (I'm actually still not clear if CEM/FEM may always be uprunning along with the protocol running, or just run for one time only when CE/FE starts). For e.g., we may setup some policies in advance to FE TML to let it know what to do when some CE fails. This is what I mean TML configuration here. My idea (I suppose also Ram's ) is such configuration may be necessary, not just for the HA policy. [/Weiming] BTW, to answer your question... "Is the TML only allowed to be statically configured, or can be configured dynamically by CEM/FEM?" I don't think we need to define this, the TML can be either statically configured or dynamically configure. BTW, what configuration are you referring to ? Also, I think we should have less dependence on CEM/FEM since this is not something in our scope either, otherwise it will be difficult to get a working implementation. So static configuration might be the best. Hope this helps, regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Here is my attempt to start some discussion on topic 2, we just have 1 week to complete All discussions so we need to move fast! Based on our discussions on TML and PL as well as the 3 schemes proposed by Jamal, here is my suggestion for HA scheme... At any time there is one Primary CE controlling the FE and there can be multiple secondary Ces. The FE PL is aware of the primary and secondary Ces. Only the primary CE is sending Control messages to the Fes. The FE may choose to send its events, redirection packets to all the Ces or only Primary CE (we need to decide one or keep this configurable ?). A [Weiming] Based on the fact that ForCES requirements and framework have explicitly defined CE-CE and FE-FE being out of scope of ForCES architecture (not only out of the ForCES protocol), and CE-CE syncronization should surely be supplied (by any means) by custumers when multi CEs are used, I suggest we limit FE to only be responsible for one CE at a time so as to simplify the case. Partial information like events, redirection packets in this case actually is of little use for the redundant CEs. [HK] Ok, I am fine with this CE-to-CE synchronization may be needed, however that is out of our current scope for ForCES PL. [Weiming] As I said above, this is even out of the scope of ForCES architecture, according to RFC3654. [HK] Agreed The association between the FE and primary CE may change based on the Connection State (triggered by TML) or an explicit message (such as Move, described by Jamal) from the primary CE. [Weiming] Regarding this, I strongly ask to let us answer the questions first "Is the TML only allowed to be statically configured, or can be configured dynamically by CEM/FEM?" If it is a static one, we then definitely need PL to have TML configuration ability (as I have posted for several times, and also Ram proposed), or else, if TML can be dynamically configured by CEM/FEM all the time during the protocol runtime, we then do not need to have the PL to do this. This rule also applies to CE change or failover, connection link failure, etc. From the TML-PL interface discussion and the HA discussion, I have a strong feeling that some TML configuration from PL layer based on, as Ram said, sessions are also in great demand as well as per message based implicit signaling. Hormuzd &Jamal, I hope you can give some comments on this. [/Weiming] Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:18:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03962 for ; Mon, 26 Apr 2004 13:18:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9gu-0002sF-U6 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:14:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHEmTq011041 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Zd-0000eP-3n for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:07:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03152 for ; Mon, 26 Apr 2004 13:07: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 1BI9Zb-0006Og-72 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:07:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Yk-0006JX-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:06:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9YI-0006Ed-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:05:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Rd-0005zX-A6; Mon, 26 Apr 2004 12:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9E9-0001qk-LP for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01826 for ; Mon, 26 Apr 2004 12:45: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 1BI9E7-0004iJ-Ux for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:45:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9D9-0004fi-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:44:04 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI9CW-0004aC-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:43:24 -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 i3QGgs1m031004; Mon, 26 Apr 2004 16:42:55 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 i3QGf5KZ028378; Mon, 26 Apr 2004 16:41:23 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 M2004042609424228175 ; Mon, 26 Apr 2004 09:42:42 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 09:42:39 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC03028@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtAABC4WsAABwpowA== From: "Khosravi, Hormuzd M" To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 16:42:39.0833 (UTC) FILETIME=[7CEB0490:01C42BAD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 09:42:38 -0700 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 Content-Transfer-Encoding: quoted-printable Ram, Thanks for your comments. My comments/questions inline below... -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 >=20 > Based on our discussions on TML and PL as well as the 3=20 > schemes proposed > by Jamal, here is my suggestion for HA scheme... >=20 > At any time there is one Primary CE controlling the FE and=20 > there can be > multiple secondary Ces. The FE PL is aware of the primary and=20 > secondary > Ces. Only the primary CE is sending Control messages to the=20 > Fes. The FE > may choose to send its events, redirection packets to all the Ces or > only Primary CE (we need to decide one or keep this configurable ?). A > CE-to-CE synchronization may be needed, however that is out of our > current scope for ForCES PL. The association between the FE=20 > and primary > CE may change based on the Connection State (triggered by TML) or an > explicit message (such as Move, described by Jamal) from the=20 > primary CE. As CE's are maste,we have two levels of issues. One is remote endpoint is dead and another=20 is link failure(very rare to happen in single box scenarion, but possible in multi hop situation). Consider a case CE1 & CE2 are master and slave respectively for FE-1. FE-2 is an standby for FE-1. When CE-1 detects the link failure, it may will wake up alternative FE (say FE-2). But FE-1 informs CE-2=20 that CE-1 has failed. But CE-1 and CE-2 are already in the loop. In this scenario, CE(s) is the master and=20 CE-2 should inform the FE-1 to be pulled out. There are other such scenario's we can derive. Since CE is the controlling authority and we are=20 assuming that there is CE to CE synchornization taking place, link layer failure cases are different than the remote peer detection. [HK] So what was your suggestion based on this scenario ? Would you like to see some change to the scheme that I described ? Sorry its not clear to me. I would request we should block set of ID's in CE and FE's space to have smooth accomudatio of CE-to-CE protocol thro' our message strucuture also. [HK] This is a good idea, what do others think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:26:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04356 for ; Mon, 26 Apr 2004 13:26:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9i1-0003GB-JN for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:15:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHFv1g012526 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9bb-0001Uq-Cd for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:09:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03288 for ; Mon, 26 Apr 2004 13:09: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 1BI9bZ-0006ce-Hi for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:09:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9al-0006WW-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:08:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9a2-0006QR-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Rg-00060Q-H0; Mon, 26 Apr 2004 12:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Iy-0003Az-Su for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02025 for ; Mon, 26 Apr 2004 12:50:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9Iw-000504-Vg for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9I4-0004xQ-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:49:08 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BI9HH-0004mL-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:48:20 -0400 Received: from wwm1 (unverified [219.82.175.57]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 27 Apr 2004 00:59:04 +0800 Message-ID: <03b501c42bad$8673a940$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EC02FEA@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 00:42:54 +0800 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 Hormuzd, I just stoped at replying your last email and jumped here. Pls see more replies inline. ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, I think I understand what you mean now. I believe what you are asking is that, if there is a CE failure or TCP/UDP connection failure, how does the TML deal with this...right? [Weiming] Exactly. I think the best approach will be to let the PL control this behavior. If the TML needs to be re-initialized and restarted after a failure, the PL can appropriately configure/control the TML... [Weiming] But how? I don't think this belongs in the FEM, CEM. With the handwaving approach, this can be done without explicitly defining any procedures. However, we should add some text to the draft to explain this. [Weiming] Do you have more clear idea how handwaving approach can handle this? If it can, I also prefer to choose handwaving approach firstly. Thanks for raising this point, [Weiming] Also thank you very much. Cheers, Weiming > > As for TML capability, etc we can push that as part of pre-association > phase (FEM, CEM) or even before that (compile, integration time). I > don't think we should be concerned with that in the PL team. > > [Weiming] This is a long lasting question that I think we > have not resolved very > well, that is, if we need to go back to pre-association again > when some TML > change happens( link failure, CE failure, etc) during the > post-assoc., and how > we go back? Or we just let the protocop layer to deal with > such change? > Yes this is a better approach to push as part of CEM and FEM configuration. > Cheers, > Weiming > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 13:26:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04422 for ; Mon, 26 Apr 2004 13:26:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9ji-00044c-Jj for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:17:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHHgPG015653 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9eS-00021T-Ck for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:12:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03528 for ; Mon, 26 Apr 2004 13:12: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 1BI9eQ-0006r1-Ea for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:12:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9dT-0006mp-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:11:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI9d7-0006iQ-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:10:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Sc-0006LD-7N; Mon, 26 Apr 2004 13:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9Nk-0004gq-9Y for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 12:55:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02143 for ; Mon, 26 Apr 2004 12:54:56 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9Ni-0005EM-GJ for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:54:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9Mm-0005B5-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:54:01 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BI9ME-00058t-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 12:53:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QGr5J00504; Mon, 26 Apr 2004 19:53:05 +0300 (EET DST) X-Scanned: Mon, 26 Apr 2004 19:52:59 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3QGqxJb018023; Mon, 26 Apr 2004 19:52:59 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 0056N9MC; Mon, 26 Apr 2004 19:52:59 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3QGqkF07693; Mon, 26 Apr 2004 19:52:47 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Apr 2004 11:52:29 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtAABC4WsAABwpowAAAVjaA To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 16:52:29.0082 (UTC) FILETIME=[DC2347A0:01C42BAE] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 12:52:27 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hormuzd, comments are inline. > -----Original Message----- > From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] > Sent: Monday, April 26, 2004 12:43 PM > To: Gopal Ram (Nokia-NRC/Boston); forces-protocol@ietf.org > Cc: hadi@znyx.com; wmwang@mail.hzic.edu.cn; avri@acm.org > Subject: RE: [Forces-protocol] topic 2:: HA >=20 >=20 > Ram, >=20 > Thanks for your comments. My comments/questions inline below... >=20 > -----Original Message----- > From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 > >=20 > > Based on our discussions on TML and PL as well as the 3=20 > > schemes proposed > > by Jamal, here is my suggestion for HA scheme... > >=20 > > At any time there is one Primary CE controlling the FE and=20 > > there can be > > multiple secondary Ces. The FE PL is aware of the primary and=20 > > secondary > > Ces. Only the primary CE is sending Control messages to the=20 > > Fes. The FE > > may choose to send its events, redirection packets to all the Ces or > > only Primary CE (we need to decide one or keep this=20 > configurable ?). A > > CE-to-CE synchronization may be needed, however that is out of our > > current scope for ForCES PL. The association between the FE=20 > > and primary > > CE may change based on the Connection State (triggered by TML) or an > > explicit message (such as Move, described by Jamal) from the=20 > > primary CE. >=20 >=20 > As CE's are maste,we have two levels of issues. One is remote endpoint > is dead and another=20 > is link failure(very rare to happen in single box scenarion, but > possible in multi hop situation). > Consider a case CE1 & CE2 are master and slave respectively for FE-1. > FE-2 is an standby for FE-1. > When CE-1 detects the link failure, it may will wake up alternative FE > (say FE-2). But FE-1 informs CE-2=20 > that CE-1 has failed. But CE-1 and CE-2 are already in the=20 > loop. In this > scenario, CE(s) is the master and=20 > CE-2 should inform the FE-1 to be pulled out. >=20 > There are other such scenario's we can derive. Since CE is the > controlling authority and we are=20 > assuming that there is CE to CE synchornization taking place,=20 > link layer > failure cases are different than the > remote peer detection. >=20 > [HK] So what was your suggestion based on this scenario ?=20 > Would you like > to see some change to the scheme that I described ? Sorry its=20 > not clear > to me. >=20 What i wrote is an extension (or additions )to your proposed text. For = example, where both primary=20 CE and FE informing the standby CE and standy CE should inform the FE to = take appropriate actions. As CE are=20 considered masters and have control over the services. > I would request we should block set of ID's in CE and FE's=20 > space to have > smooth accomudatio of CE-to-CE protocol > thro' our message strucuture also. >=20 > [HK] This is a good idea, what do others think ? >=20 > Regards > Hormuzd >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 14:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06228 for ; Mon, 26 Apr 2004 14:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAD9-0005At-TR for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHm7aZ019885 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 13:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIA88-0000yG-IW for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 13:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05067 for ; Mon, 26 Apr 2004 13:42: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 1BIA86-00017Y-GP for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:42:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIA7A-0000yX-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:41:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIA5u-0000nB-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:40:38 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BI9s6-0005om-8o for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:26:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9k1-00046B-C8; Mon, 26 Apr 2004 13:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9eK-00020s-Sq for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 13:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03494 for ; Mon, 26 Apr 2004 13:12:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9eI-0006q6-Sl for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:12:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9dL-0006la-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:11:07 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI9cT-0006eR-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:10:14 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.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 i3QH9qoR008673; Mon, 26 Apr 2004 17:09:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3QH9g08006605; Mon, 26 Apr 2004 17:09:49 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 M2004042610093802855 ; Mon, 26 Apr 2004 10:09:38 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 10:09:38 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC030B3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQrsJGyYUHilKpnSMejaIyflrM5IwAACbig From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 26 Apr 2004 17:09:38.0843 (UTC) FILETIME=[41EC56B0:01C42BB1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 10:09:36 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, ----- Original Message ----- Why does TML configuration affect the association between the Primary CE and FE ? I must be missing something here. Pls do clarify this. [Weiming] My understanding of the re-association process of CE-FE is actually to re-configure the TML in some way. Of course, you may call it just a state change or a 'move' action, or whatever, which actually does not matter too much. What I actually mean is this process may then be able to be controlled by PL if we do not want CEM/FEM to do this (I'm actually still not clear if CEM/FEM may always be uprunning along with the protocol running, or just run for one time only when CE/FE starts). For e.g., we may setup some policies in advance to FE TML to let it know what to do when some CE fails. This is what I mean TML configuration here. My idea (I suppose also Ram's ) is such configuration may be necessary, not just for the HA policy. [/Weiming] [HK] Yes I understand this now, I posted another email to this effect. Sorry I was confused before. I completely agree that this is something that the PL should control in the TML, such as re-starting, initializing the TML, etc. This does not belong to the CEM/FEM. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 14:31:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08403 for ; Mon, 26 Apr 2004 14:31:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAiK-0002XL-Eb for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 14:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIKKbU009719 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 14:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAhC-0001SW-TB for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:19:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06859 for ; Mon, 26 Apr 2004 14:19:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAhA-0003mw-7P for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:19:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAdh-0003Al-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:15:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAbk-0002sy-01 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:13:33 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIAUs-0006pe-W3 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:06:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAMj-0003r8-3y; Mon, 26 Apr 2004 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIABG-0001hb-3Q for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 13:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05406 for ; Mon, 26 Apr 2004 13:46:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIABD-0001Ob-TI for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:46:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAAI-0001KT-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:45:10 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIA9R-0001Cu-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:44:17 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3QHi109008132; Mon, 26 Apr 2004 17:44:01 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 i3QHfkKd001506; Mon, 26 Apr 2004 17:42:23 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 M2004042610434306870 ; Mon, 26 Apr 2004 10:43:43 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 10:43:43 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC03158@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtAABC4WsAABwpowAAAVjaAAAHN8vA= From: "Khosravi, Hormuzd M" To: , Cc: , , X-OriginalArrivalTime: 26 Apr 2004 17:43:43.0106 (UTC) FILETIME=[04661E20:01C42BB6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 10:43:42 -0700 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 Content-Transfer-Encoding: quoted-printable Ram, I see what your saying. It seems like you are talking about some cases which might not have been explicitly covered by the text. I will add some clarification to the text. The details will also be more clear once we start getting into the protocol messages. Thanks Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 >=20 > >=20 > > Based on our discussions on TML and PL as well as the 3=20 > > schemes proposed > > by Jamal, here is my suggestion for HA scheme... > >=20 > > At any time there is one Primary CE controlling the FE and=20 > > there can be > > multiple secondary Ces. The FE PL is aware of the primary and=20 > > secondary > > Ces. Only the primary CE is sending Control messages to the=20 > > Fes. The FE > > may choose to send its events, redirection packets to all the Ces or > > only Primary CE (we need to decide one or keep this=20 > configurable ?). A > > CE-to-CE synchronization may be needed, however that is out of our > > current scope for ForCES PL. The association between the FE=20 > > and primary > > CE may change based on the Connection State (triggered by TML) or an > > explicit message (such as Move, described by Jamal) from the=20 > > primary CE. >=20 >=20 > As CE's are maste,we have two levels of issues. One is remote endpoint > is dead and another=20 > is link failure(very rare to happen in single box scenarion, but > possible in multi hop situation). > Consider a case CE1 & CE2 are master and slave respectively for FE-1. > FE-2 is an standby for FE-1. > When CE-1 detects the link failure, it may will wake up alternative FE > (say FE-2). But FE-1 informs CE-2=20 > that CE-1 has failed. But CE-1 and CE-2 are already in the=20 > loop. In this > scenario, CE(s) is the master and=20 > CE-2 should inform the FE-1 to be pulled out. >=20 > There are other such scenario's we can derive. Since CE is the > controlling authority and we are=20 > assuming that there is CE to CE synchornization taking place,=20 > link layer > failure cases are different than the > remote peer detection. >=20 > [HK] So what was your suggestion based on this scenario ?=20 > Would you like > to see some change to the scheme that I described ? Sorry its=20 > not clear > to me. >=20 What i wrote is an extension (or additions )to your proposed text. For example, where both primary=20 CE and FE informing the standby CE and standy CE should inform the FE to take appropriate actions. As CE are=20 considered masters and have control over the services. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 14:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09055 for ; Mon, 26 Apr 2004 14:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAtM-0005tL-KE for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 14:31:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIViaX022642 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 14:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAio-0002xc-OQ for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07434 for ; Mon, 26 Apr 2004 14:20:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAim-00045r-BS for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:20:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAg7-0003Z0-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:18:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAcT-0002vw-01 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 14:14:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIA9K-0006Ee-Sk for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 13:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9wd-0008MK-JU; Mon, 26 Apr 2004 13:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9m5-0004kX-FK for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 13:20:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04092 for ; Mon, 26 Apr 2004 13:20: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 1BI9m3-0007Pd-GZ for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:20:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9lD-0007LU-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:19:16 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BI9kP-0007CF-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 13:18:25 -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 i3QHHu1m020787; Mon, 26 Apr 2004 17:17:56 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 i3QHGFKN017930; Mon, 26 Apr 2004 17:16:27 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 M2004042610174702118 ; Mon, 26 Apr 2004 10:17:47 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 10:17:47 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC030D4@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] RE: PL<-->TML:: topic 1 Thread-Index: AcQrsP2A+q8w5mqESgOUinwomzJibQAAE5Dg From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 26 Apr 2004 17:17:47.0315 (UTC) FILETIME=[65134030:01C42BB2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 10:17:46 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, We are on the same page now, which is great! See my reply below. -----Original Message----- I think I understand what you mean now. I believe what you are asking is that, if there is a CE failure or TCP/UDP connection failure, how does the TML deal with this...right? [Weiming] Exactly. I think the best approach will be to let the PL control this behavior. If the TML needs to be re-initialized and restarted after a failure, the PL can appropriately configure/control the TML... [Weiming] But how? I don't think this belongs in the FEM, CEM. With the handwaving approach, this can be done without explicitly defining any procedures. However, we should add some text to the draft to explain this. [Weiming] Do you have more clear idea how handwaving approach can handle this? If it can, I also prefer to choose handwaving approach firstly. [HK] The beauty of the handwaving approach is that we don't need to specify the details of how this is handled, just that we need to add some text to clarify that this should be handled. For example, the PL draft must specify that the TML may need to be reconfigured when there is a connection/association failure which may be caused by CE failure, FE failure or link failure. Also, if there are any Protocol Messages that we define to handle these scenarios, they should be explicitly specified. In the actual implementation, the PL may use some api to reconfigure the TML, however doesn't need to be explicitly defined in the PL draft. Hope this helps, Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 17:29:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25184 for ; Mon, 26 Apr 2004 17:29:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYF-0000fC-MB for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLM74X002545 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDK0-00053E-K4 for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22758 for ; Mon, 26 Apr 2004 17: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 1BIDJy-0003iH-9E for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:07:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDH9-0003EK-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:04:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDBR-0002BS-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 16:58:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID0L-0007Kc-GC; Mon, 26 Apr 2004 16:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICHy-0007ic-LG for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 16:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16226 for ; Mon, 26 Apr 2004 16:01:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BICHx-0003xd-2p for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:01:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICGx-0003oe-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:00:12 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BICFu-0003eR-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 15:59:06 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042613022835:12337 ; Mon, 26 Apr 2004 13:02:28 -0700 Subject: Re: [Forces-protocol] PL/TML Interface::topic 1 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Wang,Weiming" , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC02DB8@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC02DB8@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083009540.1042.21.camel@jzny.localdomain> 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 04/26/2004 01:02:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 01:02:31 PM, Serialize complete at 04/26/2004 01:02:31 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 15:59:01 -0400 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 Content-Transfer-Encoding: 7bit wow, look at all those emails. I am going to try and catchup in maybe about 3-4 emails. This is a good one to start with. On Mon, 2004-04-26 at 01:13, Khosravi, Hormuzd M wrote: > Jamal, Weiming, > > Just trying to summarize some of the requirements or services for TML, > PL based on our discussions... Hormuzd, i would recommend to put more maet if you compile things like this. Sending out bullet forms tends to reignite deiscussions already gone by (as i am noticing in some eamils from Ram). > TML Requirements/Services... > > 1. Reliability acc to Reqs (no data loss, data corruption whats acc? > 2. Security > 3. Congestion Control There may be value in the TML informing the PL about congestion events in the transport layer. This is not unlike ECN signals received from IP which get upwards propagated. I would like (not sure of the value) to suggest that the signaling should also be available from PL to TML; if the PL is congested, it could be probably easily detected if it is not pulling packets fast enough. Also one thing we didnt have in this list is prioritization. This is related to congestion. Example: under congestion, the TML may decide to drop lower priority packets from the PL. Likewise if the PL is congested, the TML may decide to drop low prio packets destined to it. > 4. Uni/multi/broadcast addressing/delivery > 5. Connection or Association State maintainance(helps with HA) > > Things that belong to PL... > > 1. PL level reliability using Acks/Responses > 2. Timeliness, again using Acks > 3. Batching > 4. transactional operations (2pc etc) > 5. Capability exchange (FE, LFB Caps) (BTW, not sure what Jamal means by > this in context with TML?) Capability also belongs to the TML layer. Example is the FE capability. > 6. HA decisions So the way i see it is: 1)Items that are the responsibility of the TML terminate at the TML. Example i dont see any decryption/encryption/authentication being done by the PL. OTOH, There may be information that needs to be propagated to the PL but i think we are saying that maybe implementation specific, no? Probably thet TML author will say "to get congestion notification you need to register for callback x". 2)Items/messages that are responsibility of PL get sent to the PL probably after some massaging by the PL (example authentication). > > Hope this is reasonably captures all the discussions. I was not sure > about what you mean by FEM/CEM interface so I didn't mention that in > this list. Let me move that to a different email, this is already overcrowded. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 17:42:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25774 for ; Mon, 26 Apr 2004 17:42:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDZF-0000zx-9j for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLN9XI003830 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMP-0005nZ-HF for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:09:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23124 for ; Mon, 26 Apr 2004 17:09: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 1BIDMN-00044p-CG for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:09:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDKW-0003pq-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:07:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDHw-0003Nd-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDA7-00015N-Ij; Mon, 26 Apr 2004 16:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BICw9-0005MP-1t for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 16:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17186 for ; Mon, 26 Apr 2004 16:42: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 1BICw7-000769-3E for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICkA-00053k-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:30:23 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BICMP-0004Kb-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:05:49 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042613091309:12350 ; Mon, 26 Apr 2004 13:09:13 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn, avri@acm.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC03158@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC03158@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083009946.1041.29.camel@jzny.localdomain> 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 04/26/2004 01:09:13 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 01:09:15 PM, Serialize complete at 04/26/2004 01:09:15 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] That dogma in the requirements Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 16:05:47 -0400 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 Content-Transfer-Encoding: 7bit Folks, I would like to make a small recommendation: Lets use anything that exists today in terms of charter, drafts (such as the model draft), RFCs such as the requirements as good guidelines not as the Word Of God (if you believe s/he/they exist). We need to develop a good protocol, thats what counts the most. None of the other drafts matter if the protocol is not usable. For example, i dont think we should rule out CE-CE extension if it makes sense and the cost of adding it is acceptable. Apologies for going a little out of tangent. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 17:59:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26842 for ; Mon, 26 Apr 2004 17:59:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDut-0006LG-7e for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLjV04024363 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDk0-0003Rm-St for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25403 for ; Mon, 26 Apr 2004 17:34: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 1BIDjy-0006V6-Gw for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:34:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDj2-0006Pd-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:33:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDi4-0006LA-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:32:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDYj-0000q9-2H; Mon, 26 Apr 2004 17:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDI8-0004Cx-1L for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22320 for ; Mon, 26 Apr 2004 17:05: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 1BIDI5-0003PK-Pc for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:05:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDCz-0002Vm-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:00:10 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BID5o-0001FP-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 16:52:44 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042613560793:12458 ; Mon, 26 Apr 2004 13:56:07 -0700 Subject: Re: [Forces-protocol] topic 2:: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, "Wang,Weiming" , avri@acm.org, ram.gopal@nokia.com In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC02DBE@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC02DBE@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083012761.1042.68.camel@jzny.localdomain> 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 04/26/2004 01:56:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 01:56:09 PM, Serialize complete at 04/26/2004 01:56:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 16:52:41 -0400 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 Content-Transfer-Encoding: 7bit Hi Hormuzd et al, I apologize for starting with this specific email. I am doing so because this one seems to be capturing good details. Now onto the email On Mon, 2004-04-26 at 01:44, Khosravi, Hormuzd M wrote: > Hi All > > Here is my attempt to start some discussion on topic 2, we just have 1 > week to complete All discussions so we need to move fast! > > Based on our discussions on TML and PL as well as the 3 schemes proposed > by Jamal, here is my suggestion for HA scheme... > > At any time there is one Primary CE controlling the FE and there can be > multiple secondary Ces. The FE PL is aware of the primary and secondary > Ces. Only the primary CE is sending Control messages to the Fes. The FE > may choose to send its events, redirection packets to all the Ces or > only Primary CE (we need to decide one or keep this configurable ?). A > CE-to-CE synchronization may be needed, however that is out of our > current scope for ForCES PL. The association between the FE and primary > CE may change based on the Connection State (triggered by TML) or an > explicit message (such as Move, described by Jamal) from the primary CE. > > This scheme is similar to Scheme 2 proposed by Jamal with a few more > details. Hope we can agree on this and move to the other topics. We can > discuss more details around the Protocol Messages related to this scheme > during topic:4. There is a difference in that in my text i said the responsibility is that of the TML - not the PL. The only role the PL may play is in the move operation. That role could also be played by the FEM/CEM interface making the decision making out of the control of the PL. So i think actually your email adds some clarity to what i had said earlier since you are thinking from a PL level and i was fromn the TML level ;-> I see both as valuable and of different responsibilities: 1) TML level - Transport level: a) The TML controls logical connection availability and failover. b) The TML also controls peer HA managements. At this level in my opinion control of all lower layers example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML or whatever the TML depends on. 2) PL Level: If you are talking about control of say CEids as the meaning of "FE being aware of the primary and secondary Ces", then i think it would be sensible. When i read the text it almost sounded like the PL layer knew about details of things like physical links going up/down. To put the two together, for example if a path to a master CE is down, I would think the TML would take care of failing over to a backup path. Should the CE be totaly unreachable i think only then would the PL be informed and it may decide to move to a new CE. Does this make sense? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:05:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27533 for ; Mon, 26 Apr 2004 18:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE3d-0008Cf-Lb for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:54:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLsXXD031528 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDtp-0006Ay-7b for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:44:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25956 for ; Mon, 26 Apr 2004 17:44: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 1BIDtm-000798-OV for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:44:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDsu-00074U-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:43:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDsI-00070a-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:42:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDa6-0001C5-Ju; Mon, 26 Apr 2004 17:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDMY-0005or-Bn for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23160 for ; Mon, 26 Apr 2004 17:09:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDMW-00045z-2n for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:10:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDKh-0003ru-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:08:08 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIDIE-0003RB-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:05:34 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042614085774:12486 ; Mon, 26 Apr 2004 14:08:57 -0700 Subject: TML requirements WAS(RE: [Forces-protocol] PL/TML Interface From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: david.putzolu@intel.com, hormuzd.m.khosravi@intel.com, forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn In-Reply-To: References: Organization: Znyx Networks Message-Id: <1083013531.1048.80.camel@jzny.localdomain> 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 04/26/2004 02:08:58 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 02:09:00 PM, Serialize complete at 04/26/2004 02:09:00 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 17:05:31 -0400 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 Content-Transfer-Encoding: 7bit Going backwards and referencing a few emails On Mon, 2004-04-26 at 08:47, ram.gopal@nokia.com wrote: > IMHO, We cannot mandate TML layer requirements, they are there and we need to use them as it is. > Forces PL layer can work on IP, TCP or UDP or any layer-2. As far as PL is concerned TML layer > can come and go, PL is the standardized interface point. I think if we are going to allow for interop between FE and CE, we can assume that the TMLs although of the same type maybe written by different people. In addition if you consider that infact a TML maybe a blackbox that hides a few transport protocols (eg A TCP +UDP combo), then one can say that it such a blackbox needs to say or be told what is needed of it. Hence requirenments are needed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:05:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27629 for ; Mon, 26 Apr 2004 18:05:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE88-0000EZ-Co for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLxCO1000892 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDv1-0006R9-9U for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26031 for ; Mon, 26 Apr 2004 17:45: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 1BIDuy-0007Gn-M7 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:45:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDtt-0007AE-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:44:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDt9-00075F-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDc0-0001mB-B2; Mon, 26 Apr 2004 17:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDTl-0006qG-9o for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:17:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23783 for ; Mon, 26 Apr 2004 17:17: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 1BIDTj-0004eD-0Z for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:17:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDSg-0004b3-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:16:23 -0400 Received: from fmr99.intel.com ([192.55.52.32] helo=hermes-pilot.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIDST-0004Y3-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:16:09 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.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 i3QL4I7r009670; Mon, 26 Apr 2004 21:04:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3QL3o6H030758; Mon, 26 Apr 2004 21:04:10 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 M2004042614035805776 ; Mon, 26 Apr 2004 14:03:58 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 14:03:58 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC034B6@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQr0HIEgym2ZdwjQY+X+rHKG7JkzgAACoNA From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , , X-OriginalArrivalTime: 26 Apr 2004 21:03:58.0517 (UTC) FILETIME=[FE245650:01C42BD1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 14:03:58 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, Thanks for your comments. I mostly agree with them. See more comments below... -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > Based on our discussions on TML and PL as well as the 3 schemes proposed > by Jamal, here is my suggestion for HA scheme... >=20 > At any time there is one Primary CE controlling the FE and there can be > multiple secondary Ces. The FE PL is aware of the primary and secondary > Ces. Only the primary CE is sending Control messages to the Fes. The FE > may choose to send its events, redirection packets to all the Ces or > only Primary CE (we need to decide one or keep this configurable ?). A > CE-to-CE synchronization may be needed, however that is out of our > current scope for ForCES PL. The association between the FE and primary > CE may change based on the Connection State (triggered by TML) or an > explicit message (such as Move, described by Jamal) from the primary CE. >=20 > This scheme is similar to Scheme 2 proposed by Jamal with a few more > details. Hope we can agree on this and move to the other topics. We can > discuss more details around the Protocol Messages related to this scheme > during topic:4.=20 There is a difference in that in my text i said the responsibility is that of the TML - not the PL. The only role the PL may play is in the move operation. That role could also be played by the FEM/CEM interface making the decision making out of the control of the PL. So i think actually your email adds some clarity to what i had said earlier since you are thinking from a PL level and i was fromn the TML level ;-> I see both as valuable and of different responsibilities: 1) TML level - Transport level: a) The TML controls logical connection availability and failover.=20 b) The TML also controls peer HA managements. At this level in my opinion control of all lower layers example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML or whatever the TML depends on. [HK] Agreed 2) PL Level: If you are talking about control of say CEids as the meaning of "FE being aware of the primary and secondary Ces", then i think it would be sensible. When i read the text it almost sounded like the PL layer knew about details of things like physical links going up/down. =20 To put the two together, for example if a path to a master CE is down, I would think the TML would take care of failing over to a backup path. Should the CE be totaly unreachable i think only then would the PL be informed and it may decide to move to a new CE. Does this make sense? [HK] Yes, this was my thinking as well. Thanks for adding more text and clarity! I'll send out a more detailed text summarizing the points made by yourself, Weiming, Ram et al. BTW, just wanted to clarify what you meant by 'backup path' above? I am guessing that some TML might implement multiple paths, e.g. multiple TCP/UDP connections between CE & FE. Is that what you mean ?=20 regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:06:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27652 for ; Mon, 26 Apr 2004 18:06:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE89-0000F8-1d for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QLxC8t000928 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 17:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDv6-0006Rl-HJ for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 17:45:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26048 for ; Mon, 26 Apr 2004 17:45: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 1BIDv3-0007HY-T2 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:45:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDtx-0007Aw-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:44:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIDtN-00075P-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 17:43:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDcz-0001vX-4t; Mon, 26 Apr 2004 17:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDVS-0007Z9-LL for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:19:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23866 for ; Mon, 26 Apr 2004 17:19: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 1BIDVQ-0004m1-Bf for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:19:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDUS-0004fy-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:18:13 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIDTX-0004cT-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:17:15 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042614203875:12520 ; Mon, 26 Apr 2004 14:20:38 -0700 Subject: FEM/CEM WAS(Re: [Forces-protocol] RE: PL<-->TML:: topic 1 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org, ram.gopal@nokia.com, hormuzd.m.khosravi@intel.com In-Reply-To: <03b501c42bad$8673a940$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EC02FEA@orsmsx408.jf.intel.com> <03b501c42bad$8673a940$020aa8c0@wwm1> Organization: Znyx Networks Message-Id: <1083014232.1048.92.camel@jzny.localdomain> 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 04/26/2004 02:20:39 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 02:20:40 PM, Serialize complete at 04/26/2004 02:20:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 17:17:12 -0400 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 Content-Transfer-Encoding: 7bit Apologies for jumping the gun. This is somewhere in the future, but since the topic keeps coming up, we may need to address it. First do we agree that the CEM-FEM is a "config plane"? - the interface could be static and in this case it means a one shot, boot/init time parametrization example DHCP could pass the FE its parameters. - a always on mode: This is what i would prefer. Weiming seems to be trying to clarify if this is what we want to do. We can avoid having the CEM/FEM active by introducing some built in "reconfig" or "setup" message in the protocol. Of course at the cost of adding a protocol complexity. I think i am now officialy caught up with posted messages. cheers, jamal On Mon, 2004-04-26 at 12:42, Weiming Wang wrote: > Hormuzd, > > I just stoped at replying your last email and jumped here. Pls see more replies > inline. > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Weiming, > > I think I understand what you mean now. I believe what you are asking is > that, if there is a CE failure or TCP/UDP connection failure, how does > the TML deal with this...right? > [Weiming] Exactly. > > I think the best approach will be to let > the PL control this behavior. If the TML needs to be re-initialized and > restarted after a failure, the PL can appropriately configure/control > the TML... > [Weiming] But how? > > I don't think this belongs in the FEM, CEM. With the > handwaving approach, this can be done without explicitly defining any > procedures. However, we should add some text to the draft to explain > this. > [Weiming] Do you have more clear idea how handwaving approach can handle this? > If it can, I also prefer to choose handwaving approach firstly. > > Thanks for raising this point, > [Weiming] Also thank you very much. > > Cheers, > Weiming > > > > > As for TML capability, etc we can push that as part of pre-association > > phase (FEM, CEM) or even before that (compile, integration time). I > > don't think we should be concerned with that in the PL team. > > > > [Weiming] This is a long lasting question that I think we > > have not resolved very > > well, that is, if we need to go back to pre-association again > > when some TML > > change happens( link failure, CE failure, etc) during the > > post-assoc., and how > > we go back? Or we just let the protocop layer to deal with > > such change? > > > > > Yes this is a better approach to push as part of CEM and FEM > configuration. > > > > Cheers, > > Weiming > > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:15:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28912 for ; Mon, 26 Apr 2004 18:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEF2-0004hH-TO for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:06:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QM6KDD018045 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEDI-0003dg-Il for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:04:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27405 for ; Mon, 26 Apr 2004 18:04:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEDF-0000w4-Rw for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:04:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIECH-0000rp-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:03:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEBm-0000nn-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:02:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDwM-0006wi-G8; Mon, 26 Apr 2004 17:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDrv-0005PD-7X for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:42:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25837 for ; Mon, 26 Apr 2004 17:42:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDrs-0006yo-O9 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:42:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDqt-0006vZ-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:41:24 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIDqY-0006sX-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:41:02 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042614442639:12588 ; Mon, 26 Apr 2004 14:44:26 -0700 Subject: RE: [Forces-protocol] topic 2:: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, "Wang,Weiming" , avri@acm.org, ram.gopal@nokia.com In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC034B6@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC034B6@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083015660.1048.105.camel@jzny.localdomain> 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 04/26/2004 02:44:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/26/2004 02:44:28 PM, Serialize complete at 04/26/2004 02:44:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 26 Apr 2004 17:41:00 -0400 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 Content-Transfer-Encoding: 7bit On Mon, 2004-04-26 at 17:03, Khosravi, Hormuzd M wrote: > BTW, just wanted to clarify what you meant by 'backup path' above? I am > guessing that some TML might implement multiple paths, e.g. multiple > TCP/UDP connections between CE & FE. Is that what you mean ? Multiple TCP/UDP connections could be one of the modes that the TML is responsible for. It could also be multihomed, multinexthop reachable, trunked in active/backup mode, ethernet bonded etc. Point is it is a blackbox and the PL doesnt care about those details. To provide an example: Consider CE with id #102 which is currently considered master. Consider that at the low layer is infact reachable as IP address a.b.c.d and IP address z.x.y.v etc. Consider CE with id #103 and ip address w.e.r.t reachable via interface 3 with nexthop of s.d.f.g and a.w.d.r. The Forces ids #102 and #103 is what PL cares about. The IP addresses is what the TML cares about. At some point when the TML has no way of reaching #102 via any of its know addresses, then the PL needs to make a call to move to CE #103 cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:28:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00076 for ; Mon, 26 Apr 2004 18:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIERk-00036Z-9t for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:19:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMJSu5011926 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEGt-0005jb-AV for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28069 for ; Mon, 26 Apr 2004 18:08: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 1BIEGq-0001HK-KX for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:08:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEFt-0001CL-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:07:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEEw-00015P-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIECm-0003T3-GG; Mon, 26 Apr 2004 18:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDwb-0006zd-Q0 for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:47:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26141 for ; Mon, 26 Apr 2004 17:47:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIDwZ-0007Pc-8f for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:47:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIDve-0007Kj-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:46:19 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIDui-0007Bp-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:45:20 -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 i3QLiv1m018827; Mon, 26 Apr 2004 21:44: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 i3QLhCKR016089; Mon, 26 Apr 2004 21:43:28 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 M2004042614444815702 ; Mon, 26 Apr 2004 14:44:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 14:44:48 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC03553@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQr1zBsyDychpT+Rg2JxUvPD/BUgQAAC93A From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , , X-OriginalArrivalTime: 26 Apr 2004 21:44:48.0160 (UTC) FILETIME=[B23E3200:01C42BD7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 14:44:47 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Jamal, Thanks for the clarification. This looks good to me. I'll send out the updated text soon. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Mon, 2004-04-26 at 17:03, Khosravi, Hormuzd M wrote: > BTW, just wanted to clarify what you meant by 'backup path' above? I am > guessing that some TML might implement multiple paths, e.g. multiple > TCP/UDP connections between CE & FE. Is that what you mean ?=20 Multiple TCP/UDP connections could be one of the modes that the TML is responsible for. It could also be multihomed, multinexthop reachable, trunked in active/backup mode, ethernet bonded etc. Point is it is a blackbox and the PL doesnt care about those details. =20 To provide an example: Consider CE with id #102 which is currently considered master. Consider that at the low layer is infact reachable as IP address a.b.c.d and IP address z.x.y.v etc.=20 Consider CE with id #103 and ip address w.e.r.t reachable via interface 3 with nexthop of s.d.f.g and a.w.d.r. The Forces ids #102 and #103 is what PL cares about. The IP addresses is what the TML cares about. At some point when the TML has no way of reaching #102 via any of its know addresses, then the PL needs to make a call to move to CE #103 cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 18:32:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00383 for ; Mon, 26 Apr 2004 18:32:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEZx-0004R0-Dh for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMRvAG017041 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEOs-0001qY-Lo for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28996 for ; Mon, 26 Apr 2004 18:16:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEOp-0001oq-RP for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:16:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIENz-0001iE-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:15:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEMw-0001dy-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 18:14:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEEj-0004Xq-F2; Mon, 26 Apr 2004 18:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIE5W-0008O6-Ce for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 17:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26666 for ; Mon, 26 Apr 2004 17:56: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 1BIE5T-0000Is-IW for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:56:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE4Z-0000F9-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:55:32 -0400 Received: from fmr99.intel.com ([192.55.52.32] helo=hermes-pilot.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIE4A-0000Ap-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 17:55:06 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.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 i3QLsg7r003113; Mon, 26 Apr 2004 21:54:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3QLq36h008014; Mon, 26 Apr 2004 21:54:28 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 M2004042614541414559 ; Mon, 26 Apr 2004 14:54:14 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 14:54:15 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] PL/TML Interface::topic 1 Message-ID: <468F3FDA28AA87429AD807992E22D07EC03581@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] PL/TML Interface::topic 1 Thread-Index: AcQryPFwF31vMR75R/O9HyqpOlepuwADuLGA From: "Khosravi, Hormuzd M" To: Cc: "Wang,Weiming" , X-OriginalArrivalTime: 26 Apr 2004 21:54:15.0179 (UTC) FILETIME=[04366DB0:01C42BD9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 14:54:12 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, I'll send out a list with more details. Some comments/question below.. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Hormuzd, i would recommend to put more maet if you compile things like this. Sending out bullet forms tends to reignite deiscussions already gone by (as i am noticing in some eamils from Ram). > TML Requirements/Services... >=20 > 1. Reliability acc to Reqs (no data loss, data corruption whats acc? [HK] according > 2. Security > 3. Congestion Control There may be value in the TML informing the PL about congestion events in the transport layer. This is not unlike ECN signals received from IP which get upwards propagated. I would like (not sure of the value) to suggest that the signaling should also be available from PL to TML; if the PL is congested, it could be probably easily detected if it is not pulling packets fast enough. Also one thing we didnt have in this list is prioritization. This is related to congestion. Example: under congestion,=20 the TML may decide to drop lower priority packets from the PL. Likewise if the PL is congested, the TML may decide to drop low prio packets destined to it. [HK] Good point, I will add prioritization to the PL, TML list > 4. Uni/multi/broadcast addressing/delivery > 5. Connection or Association State maintainance(helps with HA) >=20 > Things that belong to PL... >=20 > 1. PL level reliability using Acks/Responses > 2. Timeliness, again using Acks > 3. Batching > 4. transactional operations (2pc etc) > 5. Capability exchange (FE, LFB Caps) (BTW, not sure what Jamal means by > this in context with TML?) Capability also belongs to the TML layer. Example is the FE capability. [HK] I don't think Capability exchange belongs to the TML. Weiming also sent some comments to this effect. LFB Capabilities, LFB graph or topology, FE capabilities (such as whether it supports LFB Topology Reconfiguration or only static topologies) are all part of PL messages and need to be communicated to the Applications running on the CE. I am a bit confused as to why you say this belongs to the TML ? May be you mean some other TML Capabilities ? > 6. HA decisions So the way i see it is: 1)Items that are the responsibility of the TML terminate at the TML. Example i dont see any decryption/encryption/authentication being done by the PL.=20 OTOH, There may be information that needs to be propagated to the PL but i think we are saying that maybe implementation specific, no? Probably thet TML author will say "to get congestion notification you need to register for callback x". [HK] Yes this is implementation specific Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon Apr 26 21:56:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09928 for ; Mon, 26 Apr 2004 21:56:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHm2-0006Ab-L8 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 21:52:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R1qcbw023713 for forces-protocol-archive@odin.ietf.org; Mon, 26 Apr 2004 21:52:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHj1-0005nM-Rq for forces-protocol-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 21:49:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09666 for ; Mon, 26 Apr 2004 21:49:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHiy-0005Rm-Vi for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 21:49:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHi0-0005LO-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 21:48:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHhA-0005Fv-00 for forces-protocol-web-archive@ietf.org; Mon, 26 Apr 2004 21:47:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHfd-0005Wg-IK; Mon, 26 Apr 2004 21:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHdJ-0005J2-Vl for forces-protocol@optimus.ietf.org; Mon, 26 Apr 2004 21:43:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09464 for ; Mon, 26 Apr 2004 21:43: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 1BIHdG-0004s3-Vb for forces-protocol@ietf.org; Mon, 26 Apr 2004 21:43:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHcU-0004lM-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 21:42:47 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIHbr-0004Ye-00 for forces-protocol@ietf.org; Mon, 26 Apr 2004 21:42:07 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.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 i3R1feFT012676; Tue, 27 Apr 2004 01:41:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3R1fb06016117; Tue, 27 Apr 2004 01:41: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 M2004042618413113778 ; Mon, 26 Apr 2004 18:41:31 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Apr 2004 18:41:31 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQRqtU4oFR4UWs6Qze3se+94+unEgZozNtAACStUWA= From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , X-OriginalArrivalTime: 27 Apr 2004 01:41:31.0407 (UTC) FILETIME=[C409B1F0:01C42BF8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 26 Apr 2004 18:41:30 -0700 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 Content-Transfer-Encoding: quoted-printable Hi All Here is the updated text for HA scheme, based on comments from Weiming, Jamal, Ram... (Added some more details/clarifications) At any time there is one Primary CE controlling the FE and there can be multiple secondary CEs. The FE PL is aware of the primary and secondary CEs. This information (primary, secondary CEs) is configured in the FE during pre-association by FEM. Only the primary CE is sending Control messages to the FEs. The FE sends its events, redirection packets to only the Primary CE. A CE-to-CE synchronization may be needed to support fast failover, however that is out of our current scope. During a connection failure between the FE and CE, the TML on the FE will trigger the FE PL regarding the failure. The FE PL will send a message to the Secondary CEs to indicate this failure and one of the Secondary CE takes over as the primary CE for the FE. An explicit message (e.g. 'Move') from the primary CE, can also be used to change the Primary CE for an FE. In order to support fast failover, the FE will establish association (joining) as well as complete the capability exchange with the Primary as well as Secondary CEs. (I'll clarify the details of association establishment, capability exchange during the Protocol Message discussion:topic 4) Responsibilities for HA: 1) TML level - Transport level: a) The TML controls logical connection availability and failover.=20 b) The TML also controls peer HA managements. At this level, control of all lower layers example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML or whatever the TML depends on. 2) PL Level: The CEIDs are used to identify primary, secondary CEs. Protocol Messages will be defined related to "Move" operation, etc. To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. Should the CE be totaly unreachable then would the PL be informed and it may decide to move to a new CE. Let me know what you guys think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 07:29:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23270 for ; Tue, 27 Apr 2004 07:29:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQj9-0000zb-Cp for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 07:26:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RBQFWc003815 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 07:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQgP-0000SJ-63 for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 07:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22927 for ; Tue, 27 Apr 2004 07: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 1BIQgK-000111-R2 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 07:23:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQf6-0000gc-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 07:22:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIQds-0000I2-01 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 07:20:48 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIQa4-0006wJ-9l for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 07:16:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQWM-0007ie-5n; Tue, 27 Apr 2004 07:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQTI-00079l-OH for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 07:09:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22527 for ; Tue, 27 Apr 2004 07:09: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 1BIQTE-0005xZ-ET for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:09:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQSL-0005lR-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:08:53 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BIQRd-0005Yr-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:08:09 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 27 Apr 2004 19:20:26 +0800 Message-ID: <01a501c42c47$6bb990c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EC03158@orsmsx408.jf.intel.com> <1083009946.1041.29.camel@jzny.localdomain> Subject: Re: [Forces-protocol] That dogma in the requirements 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 19:04:33 +0800 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 Jamal, I agree with you that we may only take them more as guidelines, because all of us participating in the ForCES have to confess that a lot of stuff ForCES is trying is much more than being easy, even from the viewpoints of experts of distributed systems, therefore it's reasonable to have what have been done always be open for improvement instead of becoming dogmas. On the other hand, I have an idea that when we are not sure of the ways, we may be better to choose the easier way to go and let the others developed later. Actually I'm not objecting to consider the CE-CE cases, only a little worry that this may be quite complex to consider currently. I'll definitely support it if we eventually can find some good schemes to deal with it. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Khosravi, Hormuzd M" Cc: ; ; ; Sent: Tuesday, April 27, 2004 4:05 AM Subject: [Forces-protocol] That dogma in the requirements > Folks, > > I would like to make a small recommendation: > Lets use anything that exists today in terms of charter, drafts (such as > the model draft), RFCs such as the requirements as good guidelines > not as the Word Of God (if you believe s/he/they exist). > > We need to develop a good protocol, thats what counts the most. > None of the other drafts matter if the protocol is not usable. > For example, i dont think we should rule out CE-CE extension if it makes > sense and the cost of adding it is acceptable. > > Apologies for going a little out of tangent. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 08:30:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26966 for ; Tue, 27 Apr 2004 08:30:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRaX-0002gi-TQ for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 08:21:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RCLPp0010328 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 08:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRSV-0000eX-RN for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 08:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25518 for ; Tue, 27 Apr 2004 08:13:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRSR-0004a4-0J for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 08:13:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRRI-0004Ia-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 08:11:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIRQM-00041c-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 08:10:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRJm-00070L-BU; Tue, 27 Apr 2004 08:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRA4-0005Lw-NO for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 07:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24359 for ; Tue, 27 Apr 2004 07:54:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIR9z-0007nO-U4 for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:54:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIR96-0007Zx-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:53:04 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BIR8W-0007MN-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 07:52:32 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 27 Apr 2004 20:04:50 +0800 Message-ID: <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 2:: HA 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 19:48:57 +0800 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 Hormuzd, Thank you for your hard work. I'm quite fine with it, only with some minute comments as below. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All Here is the updated text for HA scheme, based on comments from Weiming, Jamal, Ram... (Added some more details/clarifications) At any time there is one Primary CE controlling the FE and there can be multiple secondary CEs. The FE PL is aware of the primary and secondary CEs. This information (primary, secondary CEs) is configured in the FE during pre-association by FEM. [Weimng] Then the TML in FE knows the redundant CE id list, but how the PL knows this? And we should also let CEs (primary and redundant ) know all the redundant CEs' ids, so that CE can send 'move' command to FE. Only the primary CE is sending Control messages to the FEs. The FE sends its events, redirection packets to only the Primary CE. A CE-to-CE synchronization may be needed to support fast failover, however that is out of our current scope. During a connection failure between the FE and CE, the TML on the FE will trigger the FE PL regarding the failure. The FE PL will send a message to the Secondary CEs to indicate this failure and one of the Secondary CE takes over as the primary CE for the FE. An explicit message (e.g. 'Move') from the primary CE, can also be used to change the Primary CE for an FE. In order to support fast failover, the FE will establish association (joining) as well as complete the capability exchange with the Primary as well as Secondary CEs. [Weiming] FE joining is needed for secondary CE, but the capability exchange not, because we can assume at this time, the secondary CE has already had the information via the CE-CE syn. mechanism. (I'll clarify the details of association establishment, capability exchange during the Protocol Message discussion:topic 4) Responsibilities for HA: 1) TML level - Transport level: a) The TML controls logical connection availability and failover. b) The TML also controls peer HA managements. At this level, control of all lower layers example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML or whatever the TML depends on. [Weiming]That's ok. 2) PL Level: The CEIDs are used to identify primary, secondary CEs. Protocol Messages will be defined related to "Move" operation, etc. [Weiming] This also means the CE should know the redundant CEids in advance. To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. Should the CE be totaly unreachable then would the PL be informed and it may decide to move to a new CE. [Weiming] Agreed. Let me know what you guys think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 09:11:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29142 for ; Tue, 27 Apr 2004 09:11:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISIX-0006Sy-E3 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 09:06:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RD6rY6024853 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 09:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISCt-00052j-Ce for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 09:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28576 for ; Tue, 27 Apr 2004 09:00:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISCn-0000YQ-WC for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 09:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISBr-0000HO-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 09:00:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BISAr-0007ne-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 08:58:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIS81-00043s-2X; Tue, 27 Apr 2004 08:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRtT-0001wQ-W0 for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 08:41:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27643 for ; Tue, 27 Apr 2004 08:40: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 1BIRtO-0003cs-K4 for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:40:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRsS-0003PQ-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:39:57 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIRrl-0003C9-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:39:13 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042705423642:13378 ; Tue, 27 Apr 2004 05:42:36 -0700 Subject: RE: [Forces-protocol] topic 2:: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, "Wang,Weiming" , avri@acm.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083069550.10438.45.camel@jzny.localdomain> 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 04/27/2004 05:42:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 05:42:39 AM, Serialize complete at 04/27/2004 05:42:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 27 Apr 2004 08:39:10 -0400 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 Content-Transfer-Encoding: 7bit On Mon, 2004-04-26 at 21:41, Khosravi, Hormuzd M wrote: > Hi All > > Here is the updated text for HA scheme, based on comments from Weiming, > Jamal, Ram... > (Added some more details/clarifications) > > At any time there is one Primary CE controlling the FE and there can be > multiple secondary CEs. The FE PL is aware of the primary and secondary > CEs. This information (primary, secondary CEs) is configured in the FE > during pre-association by FEM. Should be clear of "aware" - that it is "aware" of their IDs. Does this restrict on setting the number of secondary CEs? Could you add more CEs in post-association? Do we also wanna talk about multiple FEs which are active backup? > Only the primary CE is sending Control > messages to the FEs. The FE sends its events, redirection packets to > only the Primary CE. A CE-to-CE synchronization may be needed to support > fast failover, however that is out of our current scope. During a > connection failure between the FE and CE, the TML on the FE will trigger > the FE PL regarding the failure. You are assuming the failure is only due to transport breakdown. This is not always the case. > The FE PL will send a message to the > Secondary CEs to indicate this failure and one of the Secondary CE takes > over as the primary CE for the FE. An explicit message (e.g. 'Move') > from the primary CE, can also be used to change the Primary CE for an > FE. There will be PL-PL heartbeats between CE and FE. This is orthogonal to TML-TML heartbeats and TML link detection if it exists. Probably shouldnt talk about TML-TML heartbeats, rather that the TML will deploy some mechanisms which will provide the functionality. The TML can detect the lack of connectivity to the PL Id being monitored; i.e the cause of connectivity breakdown being transport. Otoh, if theres some s/ware breakdown of some PL, then TML cant help you, dependence then is in PL discovery of such a problem. > In order to support fast failover, the FE will establish association > (joining) as well as complete the capability exchange with the Primary > as well as Secondary CEs. (I'll clarify the details of association > establishment, capability exchange during the Protocol Message > discussion:topic 4) Its probably to specific, but fine (dont wanna lag progress) > Responsibilities for HA: > > 1) TML level - Transport level: > a) The TML controls logical connection availability and failover. > b) The TML also controls peer HA managements. > > At this level, control of all lower layers example transport level (such > as IP addresses, MAC addresses etc) and associated links going down are > the role of the TML or whatever the TML depends on. Maybe add transport protocol ports in that list before etc > 2) PL Level: > The CEIDs are used to identify primary, secondary CEs. Protocol Messages > will be defined related to "Move" operation, etc. > > To put the two together, if a path to a primary CE is down, the TML > would take care of failing over to a backup path, if one is available. > Should the CE be totaly unreachable then would the PL be informed and it > may decide to move to a new CE. > > I think the section on HA responsibilities above should come first followed by the details you had at the beggining. cheers, jamal PS: should we posting text on other topics - at the moment only Hormuzd is. Whats next? What can i do? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 09:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29584 for ; Tue, 27 Apr 2004 09:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISUc-0000Ed-Uc for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 09:19:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RDJMnX000894 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 09:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISOW-0007kx-2n for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 09:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29181 for ; Tue, 27 Apr 2004 09:12:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISOQ-0003Rn-Ls for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 09:12:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISNT-0003EE-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 09:12:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BISMt-00030r-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 09:11:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISIe-0006Vx-8z; Tue, 27 Apr 2004 09:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISA0-0004YP-Kg for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 08:58:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28367 for ; Tue, 27 Apr 2004 08:58:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIS9v-0007Yk-9N for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:57:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIS97-0007Jt-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:57:09 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIS8B-00074v-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 08:56:11 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042705593635:13388 ; Tue, 27 Apr 2004 05:59:36 -0700 Subject: Re: [Forces-protocol] topic 2:: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, Hormuzd M In-Reply-To: <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1083070570.10439.110.camel@jzny.localdomain> 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 04/27/2004 05:59:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 05:59:37 AM, Serialize complete at 04/27/2004 05:59:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 27 Apr 2004 08:56:11 -0400 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 Content-Transfer-Encoding: 7bit On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote: > At any time there is one Primary CE controlling the FE and there can be > multiple secondary CEs. The FE PL is aware of the primary and secondary > CEs. This information (primary, secondary CEs) is configured in the FE > during pre-association by FEM. > > [Weimng] Then the TML in FE knows the redundant CE id list, but how the PL knows > this? And we should also let CEs (primary and redundant ) know all the redundant > CEs' ids, so that CE can send 'move' command to FE. Maybe we can have information advertised in some protocol message? Perhaps a "config" message is needed if we are not going to have an always-on FEM-CEM. > In order to support fast failover, the FE will establish association > (joining) as well as complete the capability exchange with the Primary > as well as Secondary CEs. > > [Weiming] FE joining is needed for secondary CE, but the capability exchange > not, because we can assume at this time, the secondary CE has already had the > information via the CE-CE syn. mechanism. Makes sense. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 10:36:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04375 for ; Tue, 27 Apr 2004 10:36:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITbj-0000rc-JU for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 10:30:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3REUloL003316 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 10:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITY5-0008B1-6V for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 10:27:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03829 for ; Tue, 27 Apr 2004 10:26: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 1BITXy-0002Kg-RK for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 10:26:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITX0-0002HB-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 10:25:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BITWP-0002FC-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 10:25:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITLV-0004Qs-Tc; Tue, 27 Apr 2004 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITJU-0003kS-4W for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 10:11:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02476 for ; Tue, 27 Apr 2004 10:11:50 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITJN-0001by-Qt for forces-protocol@ietf.org; Tue, 27 Apr 2004 10:11:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITIO-0001Ya-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 10:10:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BITHP-0001Ut-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 10:09:47 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BITHR-000Mn5-64 for forces-protocol@ietf.org; Tue, 27 Apr 2004 14:09:49 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083070570.10439.110.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> <1083070570.10439.110.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <85BE784D-9854-11D8-932A-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 2:: HA To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:09:39 -0400 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 Content-Transfer-Encoding: 7bit On 27 apr 2004, at 08.56, Jamal Hadi Salim wrote: > On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote: > >> At any time there is one Primary CE controlling the FE and there can >> be >> multiple secondary CEs. The FE PL is aware of the primary and >> secondary >> CEs. This information (primary, secondary CEs) is configured in the FE >> during pre-association by FEM. I am not sure I agree with this since there could be a load share or a specialization opportunity that doing this would prevent. >> >> [Weimng] Then the TML in FE knows the redundant CE id list, but how >> the PL knows >> this? And we should also let CEs (primary and redundant ) know all >> the redundant >> CEs' ids, so that CE can send 'move' command to FE. > > Maybe we can have information advertised in some protocol message? > Perhaps a "config" message is needed if we are not going to have an > always-on FEM-CEM. I don't think the FE should, or even can, count on CE-CE communications. I also think that secondary CE could establish adjacency with an FE at any time during the operation of the NE. One way to deal with this is to have a FE announce any CE rlatioship it establishes to the CEs. this way, even if there is no CE-CE communucation, at least the CE will know who else is talking to an Fe. > >> In order to support fast failover, the FE will establish association >> (joining) as well as complete the capability exchange with the Primary >> as well as Secondary CEs. >> >> [Weiming] FE joining is needed for secondary CE, but the capability >> exchange >> not, because we can assume at this time, the secondary CE has already >> had the >> information via the CE-CE syn. mechanism. > > Makes sense. I do not believe we can count on this. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 11:26:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07180 for ; Tue, 27 Apr 2004 11:26:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUOd-0002JI-7T for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 11:21:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RFLJCA008876 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 11:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUIX-0001Ks-Ax for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06514 for ; Tue, 27 Apr 2004 11:14:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUIU-0004wM-8n for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:14:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUHe-0004sr-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:14:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIUGm-0004pi-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:13:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUBo-0008P2-5X; Tue, 27 Apr 2004 11:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIU8n-0007Va-8C for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 11:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05678 for ; Tue, 27 Apr 2004 11:04:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIU8g-00048I-Kc for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:04:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIU7j-00043k-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:03:53 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BIU6q-0003xv-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:02:56 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3RF2QYO097596; Tue, 27 Apr 2004 15:02:26 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 i3RF2NBK106452; Tue, 27 Apr 2004 17:02:23 +0200 Received: from zurich.ibm.com (dhcp69-40.zurich.ibm.com [9.4.69.40]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA64114; Tue, 27 Apr 2004 17:02:22 +0200 Message-ID: <408E75FE.9040003@zurich.ibm.com> From: Robert Haas Organization: IBM Research Lab 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 To: hadi@znyx.com CC: "Khosravi, Hormuzd M" , forces-protocol@ietf.org, "Wang,Weiming" , avri@acm.org Subject: Re: [Forces-protocol] topic 2:: HA References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <1083069550.10438.45.camel@jzny.localdomain> In-Reply-To: <1083069550.10438.45.camel@jzny.localdomain> Content-Type: multipart/alternative; boundary="------------000209060202080201040303" Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 17:02:22 +0200 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_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000209060202080201040303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate5.de.ibm.com id i3RF2QYO097596 Content-Transfer-Encoding: quoted-printable I note that the current proposal excludes schemes in which the FE sends=20 its events and receives its commands from CEs located in a group of CEs=20 identified by a particular group ID. As a side note, and as an apetizer for the protocol message definition wo= rk: A control-type LFB could be introduced named "HA LFB", which would=20 contain on the FE side the list of primary and secondary CEs. This way,=20 once somebody wants to introduce active-backup FEs, we don't need to=20 change any of the protocol messages. Instead, only need to extend the HA=20 LFB with additional attributes. This applies also to the current FE-CE=20 relationships at an FE that a CE can query (or be informed about, just=20 like some error messages). -Robert Jamal Hadi Salim wrote: >On Mon, 2004-04-26 at 21:41, Khosravi, Hormuzd M wrote:=20 > =20 > >>Hi All >> >>Here is the updated text for HA scheme, based on comments from Weiming, >>Jamal, Ram... >>(Added some more details/clarifications) >> >>At any time there is one Primary CE controlling the FE and there can be >>multiple secondary CEs. The FE PL is aware of the primary and secondary >>CEs. This information (primary, secondary CEs) is configured in the FE >>during pre-association by FEM. >> =20 >> > >Should be clear of "aware" - that it is "aware" of their IDs. >Does this restrict on setting the number of secondary CEs? Could you add >more CEs in post-association? >Do we also wanna talk about multiple FEs which are active backup? > > =20 > >> Only the primary CE is sending Control >>messages to the FEs. The FE sends its events, redirection packets to >>only the Primary CE. A CE-to-CE synchronization may be needed to suppor= t >>fast failover, however that is out of our current scope. During a >>connection failure between the FE and CE, the TML on the FE will trigge= r >>the FE PL regarding the failure.=20 >> =20 >> > >You are assuming the failure is only due to transport breakdown. This is >not always the case. > > =20 > >>The FE PL will send a message to the >>Secondary CEs to indicate this failure and one of the Secondary CE take= s >>over as the primary CE for the FE. An explicit message (e.g. 'Move') >>from the primary CE, can also be used to change the Primary CE for an >>FE. >> =20 >> > >There will be PL-PL heartbeats between CE and FE. >This is orthogonal to TML-TML heartbeats and TML link detection if it >exists. Probably shouldnt talk about TML-TML heartbeats, rather that the >TML will deploy some mechanisms which will provide the functionality. >The TML can detect the lack of connectivity to the PL Id being >monitored; i.e the cause of connectivity breakdown being transport. >Otoh, if theres some s/ware breakdown of some PL, then TML cant help >you, dependence then is in PL discovery of such a problem. > > =20 > >>In order to support fast failover, the FE will establish association >>(joining) as well as complete the capability exchange with the Primary >>as well as Secondary CEs. (I'll clarify the details of association >>establishment, capability exchange during the Protocol Message >>discussion:topic 4) >> =20 >> > >Its probably to specific, but fine (dont wanna lag progress) > > =20 > >>Responsibilities for HA: >> >>1) TML level - Transport level: >>a) The TML controls logical connection availability and failover.=20 >>b) The TML also controls peer HA managements. >> >>At this level, control of all lower layers example transport level (suc= h >>as IP addresses, MAC addresses etc) and associated links going down are >>the role of the TML or whatever the TML depends on. >> =20 >> > >Maybe add transport protocol ports in that list before etc > > =20 > >>2) PL Level: >>The CEIDs are used to identify primary, secondary CEs. Protocol Message= s >>will be defined related to "Move" operation, etc. >> >>To put the two together, if a path to a primary CE is down, the TML >>would take care of failing over to a backup path, if one is available. >>Should the CE be totaly unreachable then would the PL be informed and i= t >>may decide to move to a new CE. >> >> >> =20 >> > >I think the section on HA responsibilities above should come first >followed by the details you had at the beggining. > >cheers, >jamal > >PS: should we posting text on other topics - at the moment only Hormuzd = is. >Whats next? What can i do? > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =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 --------------000209060202080201040303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I note that the current proposal excludes schemes in which the FE sends its events and receives its commands from CEs located in a group of CEs identified by a particular group ID.

As a side note, and as an apetizer for the protocol message definition work:

A control-type LFB could be introduced named "HA LFB", which would contain on the FE side the list of primary and secondary CEs. This way, once somebody wants to introduce active-backup FEs, we don't need to change any of the protocol messages. Instead, only need to extend the HA LFB with additional attributes. This applies also to the current FE-CE relationships at an FE that a CE can query (or be informed about, just like some error messages).

-Robert



Jamal Hadi Salim wrote:
On Mon, 2004-04-26 at 21:41, Khosravi, Hormuzd M wrote: 
  
Hi All

Here is the updated text for HA scheme, based on comments from Weiming,
Jamal, Ram...
(Added some more details/clarifications)

At any time there is one Primary CE controlling the FE and there can be
multiple secondary CEs. The FE PL is aware of the primary and secondary
CEs. This information (primary, secondary CEs) is configured in the FE
during pre-association by FEM.
    

Should be clear of "aware" - that it is "aware" of their IDs.
Does this restrict on setting the number of secondary CEs? Could you add
more CEs in post-association?
Do we also wanna talk about multiple FEs which are active backup?

  
 Only the primary CE is sending Control
messages to the FEs. The FE sends its events, redirection packets to
only the Primary CE. A CE-to-CE synchronization may be needed to support
fast failover, however that is out of our current scope. During a
connection failure between the FE and CE, the TML on the FE will trigger
the FE PL regarding the failure. 
    

You are assuming the failure is only due to transport breakdown. This is
not always the case.

  
The FE PL will send a message to the
Secondary CEs to indicate this failure and one of the Secondary CE takes
over as the primary CE for the FE. An explicit message (e.g. 'Move')
from the primary CE, can also be used to change the Primary CE for an
FE.
    

There will be PL-PL heartbeats between CE and FE.
This is orthogonal to TML-TML heartbeats and TML link detection if it
exists. Probably shouldnt talk about TML-TML heartbeats, rather that the
TML will deploy some mechanisms which will provide the functionality.
The TML can detect the lack of connectivity to the PL Id being
monitored; i.e the cause of connectivity breakdown being transport.
Otoh, if theres some s/ware breakdown of some PL, then TML cant help
you, dependence then is in PL discovery of such a problem.

  
In order to support fast failover, the FE will establish association
(joining) as well as complete the capability exchange with the Primary
as well as Secondary CEs. (I'll clarify the details of association
establishment, capability exchange during the Protocol Message
discussion:topic 4)
    

Its probably to specific, but fine (dont wanna lag progress)

  
Responsibilities for HA:

1) TML level - Transport level:
a) The TML controls logical connection availability and failover. 
b) The TML also controls peer HA managements.

At this level, control of all lower layers example transport level (such
as IP addresses, MAC addresses etc) and associated links going down are
the role of the TML or whatever the TML depends on.
    

Maybe add transport protocol ports in that list before etc

  
2) PL Level:
The CEIDs are used to identify primary, secondary CEs. Protocol Messages
will be defined related to "Move" operation, etc.

To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is available.
Should the CE be totaly unreachable then would the PL be informed and it
may decide to move to a new CE.


    

I think the section on HA responsibilities above should come first
followed by the details you had at the beggining.

cheers,
jamal

PS: should we posting text on other topics - at the moment only Hormuzd is.
Whats next? What can i do?



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol


  

-- 
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
--------------000209060202080201040303-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 12:25:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10218 for ; Tue, 27 Apr 2004 12:25:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV3m-0004DK-Tr for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 12:03:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RG3oQm016199 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 12:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIV01-0003TN-Jk for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 11:59:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08980 for ; Tue, 27 Apr 2004 11:59: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 1BIUzy-0000KJ-Bl for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:59:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUz0-0000EF-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:58:55 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIUy3-00006E-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:57:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIUy7-0003Yb-Bv for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 11:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUlY-0008EW-8v; Tue, 27 Apr 2004 11:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUbp-00055Z-4Z for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 11:34:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07564 for ; Tue, 27 Apr 2004 11:34: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 1BIUbl-0006DT-Tg for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:34:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUap-0006Ao-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:33:56 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BIUaT-00068x-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 11:33:34 -0400 Received: from wwm1 (unverified [219.82.183.159]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 27 Apr 2004 23:46:01 +0800 Message-ID: <006e01c42c6c$7a93c050$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> <1083070570.10439.110.camel@jzny.localdomain> <85BE784D-9854-11D8-932A-000393CC2112@acm.org> Subject: Re: [Forces-protocol] topic 2:: HA X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 23:29:47 +0800 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 Hi Avri, I may have an opinion different from yours on multi-CEs . I think the CE-CE communication is fundamental for multi-CE parallelly working scenario to work. As far as I can think of currently, I can not reach other better means than CE-CE direct communications for inter-CE state syncronization. I'm not sure if you have a better approach for this issue. Pls also see some more reply inline. Thank you. Weiming ----- Original Message ----- From: > > On 27 apr 2004, at 08.56, Jamal Hadi Salim wrote: > > > On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote: > > > >> At any time there is one Primary CE controlling the FE and there can > >> be > >> multiple secondary CEs. The FE PL is aware of the primary and > >> secondary > >> CEs. This information (primary, secondary CEs) is configured in the FE > >> during pre-association by FEM. > > I am not sure I agree with this since there could be a load share or a > specialization opportunity that doing this would prevent. > > >> > >> [Weimng] Then the TML in FE knows the redundant CE id list, but how > >> the PL knows > >> this? And we should also let CEs (primary and redundant ) know all > >> the redundant > >> CEs' ids, so that CE can send 'move' command to FE. > > > > Maybe we can have information advertised in some protocol message? > > Perhaps a "config" message is needed if we are not going to have an > > always-on FEM-CEM. > > I don't think the FE should, or even can, count on CE-CE > communications. I also think that secondary CE could establish > adjacency with an FE at any time during the operation of the NE. > > One way to deal with this is to have a FE announce any CE rlatioship it > establishes to the CEs. this way, even if there is no CE-CE > communucation, at least the CE will know who else is talking to an Fe. > [Weiming] If there is no CE-CE comm., the CE has to do from scratch (only with the FE providing some limited state infomation). In this case, it's of very little help for the CE to even know who the FE used to talk with. > > > >> In order to support fast failover, the FE will establish association > >> (joining) as well as complete the capability exchange with the Primary > >> as well as Secondary CEs. > >> > >> [Weiming] FE joining is needed for secondary CE, but the capability > >> exchange > >> not, because we can assume at this time, the secondary CE has already > >> had the > >> information via the CE-CE syn. mechanism. > > > > Makes sense. > > I do not believe we can count on this. > [Weiming] I think the "copy" mode between CE-CE is the simplest mode for syncronization. If we even can not count on this 'copy' mode, we may also not able to count on other modes to parallel the CE states. I think to do like to let FE broadcast to other redundant CEs actually also only let the CE partially know something instead of everything. > a. > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 13:43:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16108 for ; Tue, 27 Apr 2004 13:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWQ2-0000lc-5e for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 13:30:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHUsLA002944 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 13:30:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWMV-0008Ld-WE for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 13:27:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15365 for ; Tue, 27 Apr 2004 13:27:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIWMR-0000PE-UZ for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 13:27:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIWLV-0000Iv-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 13:26:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIWKb-0000Bm-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 13:25:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWBm-0006WW-Ul; Tue, 27 Apr 2004 13:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW5Q-0004lr-3c for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 13:09:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13760 for ; Tue, 27 Apr 2004 13:09: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 1BIW5M-00062B-0p for forces-protocol@ietf.org; Tue, 27 Apr 2004 13:09:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIW3X-0005cM-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 13:07:41 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIW0W-000591-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 13:04:32 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.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 i3RH3rZu003103; Tue, 27 Apr 2004 17:03:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3RH2qmV026511; Tue, 27 Apr 2004 17:03:56 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 M2004042710034100892 ; Tue, 27 Apr 2004 10:03:42 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 10:03:42 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC79E77@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQsULHsZg/rJuTmQiKj3Dg/DICC8gAKG98Q From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , , X-OriginalArrivalTime: 27 Apr 2004 17:03:42.0230 (UTC) FILETIME=[97C74360:01C42C79] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 10:03:41 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, Jamal, Thanks for your comments. I'll add some more clarifications to address your comments. Regards Hormuzd -----Original Message----- Hormuzd, Thank you for your hard work. I'm quite fine with it, only with some minute comments as below. Cheers, Weiming ----- Original Message ----- Hi All Here is the updated text for HA scheme, based on comments from Weiming, Jamal, Ram... (Added some more details/clarifications) At any time there is one Primary CE controlling the FE and there can be multiple secondary CEs. The FE PL is aware of the primary and secondary CEs. This information (primary, secondary CEs) is configured in the FE during pre-association by FEM. [Weimng] Then the TML in FE knows the redundant CE id list, but how the PL knows this? And we should also let CEs (primary and redundant ) know all the redundant CEs' ids, so that CE can send 'move' command to FE. Only the primary CE is sending Control messages to the FEs. The FE sends its events, redirection packets to only the Primary CE. A CE-to-CE synchronization may be needed to support fast failover, however that is out of our current scope. During a connection failure between the FE and CE, the TML on the FE will trigger the FE PL regarding the failure. The FE PL will send a message to the Secondary CEs to indicate this failure and one of the Secondary CE takes over as the primary CE for the FE. An explicit message (e.g. 'Move') from the primary CE, can also be used to change the Primary CE for an FE. In order to support fast failover, the FE will establish association (joining) as well as complete the capability exchange with the Primary as well as Secondary CEs. [Weiming] FE joining is needed for secondary CE, but the capability exchange not, because we can assume at this time, the secondary CE has already had the information via the CE-CE syn. mechanism. (I'll clarify the details of association establishment, capability exchange during the Protocol Message discussion:topic 4) Responsibilities for HA: 1) TML level - Transport level: a) The TML controls logical connection availability and failover. b) The TML also controls peer HA managements. At this level, control of all lower layers example transport level (such as IP addresses, MAC addresses etc) and associated links going down are the role of the TML or whatever the TML depends on. [Weiming]That's ok. 2) PL Level: The CEIDs are used to identify primary, secondary CEs. Protocol Messages will be defined related to "Move" operation, etc. [Weiming] This also means the CE should know the redundant CEids in advance. To put the two together, if a path to a primary CE is down, the TML would take care of failing over to a backup path, if one is available. Should the CE be totaly unreachable then would the PL be informed and it may decide to move to a new CE. [Weiming] Agreed. Let me know what you guys think ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 14:32:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18608 for ; Tue, 27 Apr 2004 14:32:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXHY-0002ll-RP for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 14:26:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RIQC1A010640 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 14:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXBb-0001kI-UW for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 14:20:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18139 for ; Tue, 27 Apr 2004 14:20:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIXBX-0005Tm-CT for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 14:19:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIXAh-0005O5-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 14:19:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIX9p-0005H7-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 14:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIX7h-00015T-Mc; Tue, 27 Apr 2004 14:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIX2w-0000ZG-H4 for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 14:11:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17639 for ; Tue, 27 Apr 2004 14:11:03 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIX2s-0004ZA-4A for forces-protocol@ietf.org; Tue, 27 Apr 2004 14:11:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIX1t-0004Tc-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 14:10:02 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BIX0r-0004Nz-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 14:08:57 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BIX0t-000DYv-8O for forces-protocol@ietf.org; Tue, 27 Apr 2004 18:08:59 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <006e01c42c6c$7a93c050$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> <1083070570.10439.110.camel@jzny.localdomain> <85BE784D-9854-11D8-932A-000393CC2112@acm.org> <006e01c42c6c$7a93c050$020aa8c0@wwm1> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 2:: HA To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 14:08:56 -0400 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 Content-Transfer-Encoding: 7bit Hi Weiming, On 27 apr 2004, at 11.29, Weiming Wang wrote: > Hi Avri, > > I may have an opinion different from yours on multi-CEs . I think the > CE-CE > communication is fundamental for multi-CE parallelly working scenario > to work. I guess I don't see this as necessary, though it does make it easier. > As far as I can think of currently, I can not reach other better > means than > CE-CE direct communications for inter-CE state syncronization. I'm not > sure if > you have a better approach for this issue. I am not going to argue it is better, but rather it is a scheme for making things work in the absence of CE-CE communications. Basically an FE is responsible for informing all CEs it has association with of which other CEs it is in association with - sending notification every time a new association is created or is lost. This way all CEs know who else is talking Additionally an FE needs the capability to report it state to an CE. So any CE in association can request a reporting of the FE state (this is needed in general, not just for this purpose - I think) > Pls also see some more reply inline. > Thank you. > > Weiming > > ----- Original Message ----- > From: >> >> On 27 apr 2004, at 08.56, Jamal Hadi Salim wrote: >> >>> On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote: >>> >>>> At any time there is one Primary CE controlling the FE and there can >>>> be >>>> multiple secondary CEs. The FE PL is aware of the primary and >>>> secondary >>>> CEs. This information (primary, secondary CEs) is configured in the >>>> FE >>>> during pre-association by FEM. >> >> I am not sure I agree with this since there could be a load share or a >> specialization opportunity that doing this would prevent. > >> >>>> >>>> [Weimng] Then the TML in FE knows the redundant CE id list, but how >>>> the PL knows >>>> this? And we should also let CEs (primary and redundant ) know all >>>> the redundant >>>> CEs' ids, so that CE can send 'move' command to FE. >>> >>> Maybe we can have information advertised in some protocol message? >>> Perhaps a "config" message is needed if we are not going to have an >>> always-on FEM-CEM. >> >> I don't think the FE should, or even can, count on CE-CE >> communications. I also think that secondary CE could establish >> adjacency with an FE at any time during the operation of the NE. >> >> One way to deal with this is to have a FE announce any CE rlatioship >> it >> establishes to the CEs. this way, even if there is no CE-CE >> communucation, at least the CE will know who else is talking to an Fe. >> > [Weiming] If there is no CE-CE comm., the CE has to do from scratch > (only with > the FE providing some limited state infomation). In this case, it's > of very > little help for the CE to even know who the FE used to talk with. [ad] I agree that knowing who had been Primary (assuming there is only a single primary) is not as useful in this case. Still the Fe should be able to supply a rather complete picture of its state if so required. >>> >>>> In order to support fast failover, the FE will establish association >>>> (joining) as well as complete the capability exchange with the >>>> Primary >>>> as well as Secondary CEs. >>>> >>>> [Weiming] FE joining is needed for secondary CE, but the capability >>>> exchange >>>> not, because we can assume at this time, the secondary CE has >>>> already >>>> had the >>>> information via the CE-CE syn. mechanism. >>> >>> Makes sense. >> >> I do not believe we can count on this. >> > [Weiming] I think the "copy" mode between CE-CE is the simplest mode > for > syncronization. If we even can not count on this 'copy' mode, we may > also not > able to count on other modes to parallel the CE states. I think to do > like to > let FE broadcast to other redundant CEs actually also only let the CE > partially > know something instead of everything. [ad] Yet even that mode is not fool proof since there may be a gap between the last CE copy state operation and the time of the failure. [ad]Please note I am not saying that CE-CE coordination is not a good thing, I just don't think it should be required and even if required I don't see it as infallible. There still needs to be a way to query the FE to show its complete state and it still has to be up to the FE to inform its CEs of new CEs in the mix.. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 15:41:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24658 for ; Tue, 27 Apr 2004 15:41:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYJw-0005Qd-GA for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 15:32:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RJWiMN020858 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 15:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYGp-0004kt-Ny for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 15:29:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24051 for ; Tue, 27 Apr 2004 15:29: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 1BIYGm-000564-Eu for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 15:29:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYFO-0004nG-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 15:28:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIYDX-0004Vp-01 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 15:26:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXzu-0000Ks-6D; Tue, 27 Apr 2004 15:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXqI-0001OP-11 for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 15:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20524 for ; Tue, 27 Apr 2004 15:02: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 1BIXqC-0001li-U6 for forces-protocol@ietf.org; Tue, 27 Apr 2004 15:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIXpG-0001ei-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 15:01:03 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIXoO-0001XV-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 15:00:08 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042712033317:13778 ; Tue, 27 Apr 2004 12:03:33 -0700 Subject: Re: [Forces-protocol] topic 2:: HA From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07EC79A4D@orsmsx408.jf.intel.com> <01b901c42c4d$9fc75040$845c21d2@Necom.hzic.edu.cn> <1083070570.10439.110.camel@jzny.localdomain> <85BE784D-9854-11D8-932A-000393CC2112@acm.org> <006e01c42c6c$7a93c050$020aa8c0@wwm1> Organization: Znyx Networks Message-Id: <1083092408.1026.33.camel@jzny.localdomain> 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 04/27/2004 12:03:33 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 12:03:35 PM, Serialize complete at 04/27/2004 12:03:35 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 27 Apr 2004 15:00:08 -0400 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 Content-Transfer-Encoding: 7bit On Tue, 2004-04-27 at 14:08, avri@acm.org wrote: > > [Weiming] If there is no CE-CE comm., the CE has to do from scratch > > (only with > > the FE providing some limited state infomation). In this case, it's > > of very > > little help for the CE to even know who the FE used to talk with. > > [ad] I agree that knowing who had been Primary (assuming there is only > a single primary) is not as useful in this case. Still the Fe should > be able to supply a rather complete picture of its state if so > required. Ok, i think i finaly got what you are saying and i think it is a valid scheme. Since we are already putting responsibility to the FE to be aware of all CEs in multiCE setup, i dont think this additional item will be that much of a cost either performancewise or protolwise (there will be some cost). OTOH, i think if a CE-CE setup decides it wants to likewise pass such information around, that too should be fine. I am not sure how to reach a compromise: Should the setup make the decision? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 17:03:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01432 for ; Tue, 27 Apr 2004 17:03:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZgW-0002TV-ME for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 17:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RL08jH009508 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 17:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZdj-0001o9-Id for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:57:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00888 for ; Tue, 27 Apr 2004 16:57: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 1BIZdf-0001BZ-Is for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:57:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZcj-00012O-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:56:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIZbo-0000u2-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:55:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIZbq-0000kF-PK for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:55:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZPI-0006tz-TR; Tue, 27 Apr 2004 16:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZAg-000071-OS for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 16:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27855 for ; Tue, 27 Apr 2004 16:27:11 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZAc-0004JU-Ta for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZ9p-0004AZ-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:26:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIZ8k-0003yf-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:25:14 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RKPFG08440; Tue, 27 Apr 2004 23:25:16 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 23:25:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3RKPE3V011724; Tue, 27 Apr 2004 23:25:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 009Iz4XL; Tue, 27 Apr 2004 23:25:13 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RKPBH22892; Tue, 27 Apr 2004 23:25:12 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 15:25:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQshCDocq2dmW72Sy6EbIwyHvMKcwAEIvYQ To: , X-OriginalArrivalTime: 27 Apr 2004 20:25:09.0969 (UTC) FILETIME=[BCA1DC10:01C42C95] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 16:25:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello All, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext avri@acm.org > Sent: Tuesday, April 27, 2004 2:09 PM > To: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] topic 2:: HA >=20 >=20 > Hi Weiming, >=20 > On 27 apr 2004, at 11.29, Weiming Wang wrote: >=20 > > Hi Avri, > > > > I may have an opinion different from yours on multi-CEs .=20 > I think the=20 > > CE-CE > > communication is fundamental for multi-CE parallelly=20 > working scenario=20 > > to work. >=20 > I guess I don't see this as necessary, though it does make it easier. Most of the network intelligence and services (like Routing,QoS, = Mobility, Security) logic operates from CE. Hence the CE-CE consideration is good.=20 >=20 > > As far as I can think of currently, I can not reach other better=20 > > means than > > CE-CE direct communications for inter-CE state=20 > syncronization. I'm not=20 > > sure if > > you have a better approach for this issue. >=20 > I am not going to argue it is better, but rather it is a scheme for=20 > making things work in the absence of CE-CE communications. >=20 You have to remember that most of the mangaement interfaces (SNMP or = CLI) talks to CE, using CE-CE has been adopted in various products and also in various standards. > Basically an FE is responsible for informing all CEs it has=20 > association=20 > with of which other CEs it is in association with - sending=20 > notification every time a new association is created or is lost. This=20 > way all CEs know who else is talking >=20 What you are giving is one possible approach. But CE-CE is one of the = important aspect also. =20 Regards Ramg > Additionally an FE needs the capability to report it state to an CE. =20 > So any CE in association can request a reporting of the FE=20 > state (this=20 > is needed in general, not just for this purpose - I think) >=20 > > Pls also see some more reply inline. > > Thank you. > > > > Weiming > > > > ----- Original Message ----- > > From: > >> > >> On 27 apr 2004, at 08.56, Jamal Hadi Salim wrote: > >> > >>> On Tue, 2004-04-27 at 07:48, Wang,Weiming wrote: > >>> > >>>> At any time there is one Primary CE controlling the FE=20 > and there can > >>>> be > >>>> multiple secondary CEs. The FE PL is aware of the primary and > >>>> secondary > >>>> CEs. This information (primary, secondary CEs) is=20 > configured in the=20 > >>>> FE > >>>> during pre-association by FEM. > >> > >> I am not sure I agree with this since there could be a=20 > load share or a > >> specialization opportunity that doing this would prevent. > > > >> > >>>> > >>>> [Weimng] Then the TML in FE knows the redundant CE id=20 > list, but how > >>>> the PL knows > >>>> this? And we should also let CEs (primary and redundant=20 > ) know all > >>>> the redundant > >>>> CEs' ids, so that CE can send 'move' command to FE. > >>> > >>> Maybe we can have information advertised in some protocol message? > >>> Perhaps a "config" message is needed if we are not going=20 > to have an > >>> always-on FEM-CEM. > >> > >> I don't think the FE should, or even can, count on CE-CE > >> communications. I also think that secondary CE could establish > >> adjacency with an FE at any time during the operation of the NE. > >> > >> One way to deal with this is to have a FE announce any CE=20 > rlatioship=20 > >> it > >> establishes to the CEs. this way, even if there is no CE-CE > >> communucation, at least the CE will know who else is=20 > talking to an Fe. > >> > > [Weiming] If there is no CE-CE comm., the CE has to do from scratch=20 > > (only with > > the FE providing some limited state infomation). In this=20 > case, it's=20 > > of very > > little help for the CE to even know who the FE used to talk with. >=20 > [ad] I agree that knowing who had been Primary (assuming=20 > there is only=20 > a single primary) is not as useful in this case. Still the Fe should=20 > be able to supply a rather complete picture of its state if so=20 > required. >=20 >=20 > >>> > >>>> In order to support fast failover, the FE will establish=20 > association > >>>> (joining) as well as complete the capability exchange with the=20 > >>>> Primary > >>>> as well as Secondary CEs. > >>>> > >>>> [Weiming] FE joining is needed for secondary CE, but the=20 > capability > >>>> exchange > >>>> not, because we can assume at this time, the secondary CE has=20 > >>>> already > >>>> had the > >>>> information via the CE-CE syn. mechanism. > >>> > >>> Makes sense. > >> > >> I do not believe we can count on this. > >> > > [Weiming] I think the "copy" mode between CE-CE is the=20 > simplest mode=20 > > for > > syncronization. If we even can not count on this 'copy'=20 > mode, we may=20 > > also not > > able to count on other modes to parallel the CE states. I=20 > think to do=20 > > like to > > let FE broadcast to other redundant CEs actually also only=20 > let the CE=20 > > partially > > know something instead of everything. >=20 >=20 > [ad] Yet even that mode is not fool proof since there may be a gap=20 > between the last CE copy state operation and the time of the failure. >=20 > [ad]Please note I am not saying that CE-CE coordination is not a good=20 > thing, I just don't think it should be required and even if=20 > required I=20 > don't see it as infallible. There still needs to be a way to=20 > query the=20 > FE to show its complete state and it still has to be up to the FE to=20 > inform its CEs of new CEs in the mix.. >=20 >=20 > a. >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 17:03:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01500 for ; Tue, 27 Apr 2004 17:03:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZga-0002Uu-2g for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 17:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RL0BOM009593 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 17:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZds-0001oW-KG for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 16:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00925 for ; Tue, 27 Apr 2004 16:57: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 1BIZdo-0001Cv-LA for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:57:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZd2-000155-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:56:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIZc9-0000wp-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:55:37 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIZcC-0000kz-Fi for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 16:55:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZQ2-00079p-Gg; Tue, 27 Apr 2004 16:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZDo-0001Oy-QT for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 16:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28111 for ; Tue, 27 Apr 2004 16:30:25 -0400 (EDT) From: ram.gopal@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZDk-0004nD-V8 for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:30:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZCv-0004ee-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:29:34 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIZC4-0004VM-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 16:28:41 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RKSaG12288; Tue, 27 Apr 2004 23:28:36 +0300 (EET DST) X-Scanned: Tue, 27 Apr 2004 23:28:33 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3RKSXEh009391; Tue, 27 Apr 2004 23:28:33 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00US0pjB; Tue, 27 Apr 2004 23:28:33 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3RKSWH06588; Tue, 27 Apr 2004 23:28:32 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Apr 2004 15:28:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQsjBp/Qx1uQ5TKS12Y+nLTSB1qngACeB4g To: , Cc: X-OriginalArrivalTime: 27 Apr 2004 20:28:12.0274 (UTC) FILETIME=[294B6520:01C42C96] Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 16:28:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Jamal,All, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > Hadi Salim > Sent: Tuesday, April 27, 2004 3:00 PM > To: avri@acm.org > Cc: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] topic 2:: HA >=20 >=20 > On Tue, 2004-04-27 at 14:08, avri@acm.org wrote: >=20 > > > [Weiming] If there is no CE-CE comm., the CE has to do=20 > from scratch=20 > > > (only with > > > the FE providing some limited state infomation). In this=20 > case, it's=20 > > > of very > > > little help for the CE to even know who the FE used to talk with. > >=20 > > [ad] I agree that knowing who had been Primary (assuming=20 > there is only=20 > > a single primary) is not as useful in this case. Still the=20 > Fe should=20 > > be able to supply a rather complete picture of its state if so=20 > > required. >=20 > Ok, i think i finaly got what you are saying and i think it is > a valid scheme. Since we are already putting responsibility to the > FE to be aware of all CEs in multiCE setup, i dont think this=20 > additional > item will be that much of a cost either performancewise or protolwise > (there will be some cost). > OTOH, i think if a CE-CE setup decides it wants to likewise pass such > information around, that too should be fine. > I am not sure how to reach a compromise: Should the setup make the=20 > decision? This is a alternative scheme. But many vendors address basic HA = mechanism thro'CE-to-CE. But our ForCES should allow extensions if needed to accomudate those. Regards Ramg _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 18:09:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05588 for ; Tue, 27 Apr 2004 18:09:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIacd-0003FJ-VO for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 18:00:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RM0Bg8012468 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 18:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaTH-0001jj-Sd for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 17:50:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04108 for ; Tue, 27 Apr 2004 17:50: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 1BIaTD-00001o-C9 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 17:50:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaSG-0007gk-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 17:49:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIaRJ-0007Yi-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 17:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaI9-0008Uh-Sn; Tue, 27 Apr 2004 17:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaDf-0007BW-P8 for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 17:34:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03287 for ; Tue, 27 Apr 2004 17:34: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 1BIaDb-0005z8-7h for forces-protocol@ietf.org; Tue, 27 Apr 2004 17:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaCk-0005sY-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 17:33:27 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIaCD-0005kT-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 17:32:54 -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 i3RLWhBK020676; Tue, 27 Apr 2004 21:32:43 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 i3RLW7Re024098; Tue, 27 Apr 2004 21:32:37 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 M2004042714322105076 ; Tue, 27 Apr 2004 14:32:21 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 14:32:21 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07EC7A314@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQsi9TPOapLhnSYS5eJ9DmjVQtwKgAEuZVg From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 27 Apr 2004 21:32:21.0925 (UTC) FILETIME=[1FDD8550:01C42C9F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 14:32:21 -0700 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 Content-Transfer-Encoding: quoted-printable > > [Weiming] If there is no CE-CE comm., the CE has to do from scratch=20 > > (only with > > the FE providing some limited state infomation). In this case, it's > > of very > > little help for the CE to even know who the FE used to talk with. >=20 > [ad] I agree that knowing who had been Primary (assuming there is only > a single primary) is not as useful in this case. Still the Fe should=20 > be able to supply a rather complete picture of its state if so=20 > required. Ok, i think i finaly got what you are saying and i think it is a valid scheme. Since we are already putting responsibility to the FE to be aware of all CEs in multiCE setup, i dont think this additional item will be that much of a cost either performancewise or protolwise (there will be some cost). OTOH, i think if a CE-CE setup decides it wants to likewise pass such information around, that too should be fine. I am not sure how to reach a compromise: Should the setup make the=20 decision? [HK] I agree, we can have a compromise to keep both these schemes, i.e. FE may send events, packets to all CEs or just primary CE as configurable. This can be a behavior which is configurable by the CE. Is this acceptable to Avri, Weiming, others ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 19:31:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10363 for ; Tue, 27 Apr 2004 19:31:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbyY-00077A-My for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 19:26:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RNQsYl027340 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 19:26:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbuF-0006Me-Ty for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 19:22:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09973 for ; Tue, 27 Apr 2004 19:22:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbuC-0002b9-Cd for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 19:22:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbt0-0002Iw-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 19:21:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIbrL-00023D-03 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 19:19:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIbcz-000360-28 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 19:04:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbWc-0003L6-4I; Tue, 27 Apr 2004 18:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIbR3-0002Uy-0X for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 18:52:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08743 for ; Tue, 27 Apr 2004 18:52:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIbQx-0007Cb-VL for forces-protocol@ietf.org; Tue, 27 Apr 2004 18:52:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIbPz-00076p-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 18:51:12 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIbPZ-000717-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 18:50:45 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.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 i3RMoFWo001969; Tue, 27 Apr 2004 22:50:15 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3RMl9nr008752; Tue, 27 Apr 2004 22:50:13 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 M2004042715495921564 ; Tue, 27 Apr 2004 15:49:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 15:50:00 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQiS6tv5HOz1kDgRwGUOwSEv3hZSAKMEC9Q From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 27 Apr 2004 22:50:00.0016 (UTC) FILETIME=[F84DCD00:01C42CA9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 15:49:54 -0700 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 Content-Transfer-Encoding: quoted-printable Hi All, Since the discussion around the HA seems to be coming to a reasonable conclusion,=20 I am taking this opportunity to post some text around the Protocol Messages (PL level). This covers both topic 3 (capability exchange) & 4 a,b. Couple of comments...I have categorized the messages in a certain way, however that is Not important to me at this point. I am fine with however, you guys would like to categorize this or Not categorize this at all (?) Also, I have tried to incorporate some of the comments that I received from Weiming, Jamal, others. Note to Weiming: The reason for not categorizing these messages as "FE messages" is so that they can be used by the CEs also in the future. For e.g., the Leave message can be used by the CE also to leave a ForCES association with a FE (actually this is a requirement as well but I wont mention the RFC here, don't want to piss off my friend(Jamal) :-)). Also, the State messages such as UP/DOWN can be used by CEs also thus making the protocol future-proof in a way & simplifying some of the HA schemes. * Association Setup Messages Join Request/Response - The Join Request is used by the FE to join or start an association with the CE. The Join Response is sent by the CE and indicates whether the Join Request was successful or not. The CE also assigns the FE ID to the FE in this message. Leave - This message can be used by an FE or CE to leave an association * Capability Control Messages Capability Req/Resp (only FE Caps which will be defined in the Model) - I wanted to keep the Caps Query separate from all other Queries. However, if folks wont to only use the Query Req/Resp (below) for this, I am fine with that. Query Req/Resp (including FE, LFB Properties as well as LFB topology & Inter-FE Topology) Configuration Req/Resp (FE, LFB attributes) =20 * Control Packet or Traffic Maintenance Messages CP Redirect to CE - This message will contain the packet to be redirected along with some control information such as the FE Port ID on which the FE arrived or the LFB ID on which it arrived. CP Forward to FE - This message also contains the packet along with control information such as the FE Port ID or LFB ID on which the packet is to be forwarded. * Event Notification Messages Event Register/De-register Req/Resp - This allows the CE to register/de-register for FE events, LFB events, packets, etc. Asynchronous FE Event (including FE events such as DoS events, LFB events, etc) * State Maintenance Messages or HA related messages PE Up/Down - These indicate the state of the FE or CE. PE Active/InActive - These are actually commands which can be used by the CE to Activate or Inactivate an FE (change its state). By activating an FE, I mean asking it to start forwarding packets. This is a useful during initial startup of protocol operations, to take the FE into steady state. These commands can also be very useful to handle HA scenarios when there are multiple FEs connected to the CE, some are active and some are standby (or inactive). Move PrimaryCE - This command is used to change the Primary CE for an FE. TBD...(Not sure if this is needed, may be Config Req/Resp can be used for this) * Management Object or SNMP support Messages MO Get/Set MO Response HeartBeat or Keep-alive - This message may Not be needed, depending on whether we want this functionality to be provided by the TML Changes since last post on Protocol Messages... Removed - Leave Response Removed - Vendor Specific messages Added - Move message Hope we can get agreement on this basic set, let me know what you guys think. I will send out a separate email, with some diagrams describing the Protocol scenarios showing the different messages. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 22:30:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18138 for ; Tue, 27 Apr 2004 22:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIekf-0004D9-AH for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2OjZV016183 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIefm-0003gj-6i for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 22:19:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17499 for ; Tue, 27 Apr 2004 22:19:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIefh-0001D1-1Y for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:19:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeef-0000x4-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:18:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIeda-0000m6-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:17:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIeYl-00069c-Jr for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:12:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeXN-0002wI-Dz; Tue, 27 Apr 2004 22:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeSt-0002AB-81 for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 22:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17135 for ; Tue, 27 Apr 2004 22:06:19 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeSo-0007HB-6Y for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:06:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeRr-00079F-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:05:19 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BIeQs-000721-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:04:18 -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 i3S25fep014989 for ; Wed, 28 Apr 2004 04:05:43 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5AEE9CBA-98B8-11D8-B32D-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 2:: HA To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 22:04:17 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 27 apr 2004, at 16.25, ram.gopal@nokia.com wrote: > > > What you are giving is one possible approach. But CE-CE is one of the > important aspect also. > > > [ad] Yes, CE-CE is a possible approach, and yes it is used frequently. But it does not guarantee coordination and is not currently in the charter. My argument is that we should provide the functionality to make ForCES work even in the absence of CE-CE communications. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue Apr 27 22:59:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19372 for ; Tue, 27 Apr 2004 22:59:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfCo-0007Vv-VW for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 22:53:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2rocx028875 for forces-protocol-archive@odin.ietf.org; Tue, 27 Apr 2004 22:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIf8k-00073t-56 for forces-protocol-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 22:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19013 for ; Tue, 27 Apr 2004 22:49:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIf8e-0005d0-Ks for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:49:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIf7h-0005TS-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:48:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIf76-0005KB-00 for forces-protocol-web-archive@ietf.org; Tue, 27 Apr 2004 22:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIf5F-0006mP-Ax; Tue, 27 Apr 2004 22:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIf1y-0006PU-Kp for forces-protocol@optimus.ietf.org; Tue, 27 Apr 2004 22:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18739 for ; Tue, 27 Apr 2004 22:42: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 1BIf1t-0004Y1-4H for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:42:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIf0v-0004N4-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:41:34 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BIf01-0004B2-00 for forces-protocol@ietf.org; Tue, 27 Apr 2004 22:40:37 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042719435821:14228 ; Tue, 27 Apr 2004 19:43:58 -0700 Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083120033.1037.140.camel@jzny.localdomain> 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 04/27/2004 07:43:59 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/27/2004 07:44:04 PM, Serialize complete at 04/27/2004 07:44:04 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 27 Apr 2004 22:40:33 -0400 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 Content-Transfer-Encoding: 7bit On Tue, 2004-04-27 at 18:49, Khosravi, Hormuzd M wrote: > Hi All, > > Since the discussion around the HA seems to be coming to a reasonable > conclusion, > I am taking this opportunity to post some text around the Protocol > Messages (PL level). > This covers both topic 3 (capability exchange) & 4 a,b. Non-tech question: Where are we going with all the txt that so far you are the serial interface to. From the size of it, it seem inadequate to be going into a draft. I know sooner or later we are going to start editing xml pieces. Is this text a lead/summary to that? > Couple of comments...I have categorized the messages in a certain way, > however that is Not important to me at this point. I am fine with > however, you guys would like to categorize this or Not categorize this > at all (?) Also, I have tried to incorporate some of the comments that I > received from Weiming, Jamal, others. > > Note to Weiming: The reason for not categorizing these messages as "FE > messages" is so that they can be used by the CEs also in the future. I like this. the ID should clearly identify if it is a CE or FE, no? > For > e.g., the Leave message can be used by the CE also to leave a ForCES > association with a FE (actually this is a requirement as well but I wont > mention the RFC here, don't want to piss off my friend(Jamal) :-)). > Also, the State messages such as UP/DOWN can be used by CEs also thus > making the protocol future-proof in a way & simplifying some of the HA > schemes. > > * Association Setup Messages > Join Request/Response - The Join Request is used by the FE to join or > start an association with the CE. The Join Response is sent by the CE > and indicates whether the Join Request was successful or not. The CE > also assigns the FE ID to the FE in this message. I am trying my best not to bring up how we did things in order to expidite things(as an example, the way HA is being approached is totaly different from how we did and i hope it makes Ram happy ;->). In some cases, however, sharing the experience helps. We implemented slightly differently. The FEM CEM interface provides the FE its ID. The join/syn/association message could of course be used to override this ID. Infact, in some of the h/ware we used the FE ID could be associated by slot and chasis ID(sometimes referd to as geographical information) which is known to the FE on bootup. > Leave - This message can be used by an FE or CE to leave an association > nod. > * Capability Control Messages > Capability Req/Resp (only FE Caps which will be defined in the Model) - > I wanted to keep the Caps Query separate from all other Queries. > However, if folks wont to only use the Query Req/Resp (below) for this, > I am fine with that. > Query Req/Resp (including FE, LFB Properties as well as LFB topology & > Inter-FE Topology) > Configuration Req/Resp (FE, LFB attributes) I think we may need to explicitly call out details. For one exhaustive listing of all sorts of capabilities that need to be exchanged. > > * Control Packet or Traffic Maintenance Messages > CP Redirect to CE - This message will contain the packet to be > redirected along with some control information such as the FE Port ID on > which the FE arrived or the LFB ID on which it arrived. > CP Forward to FE - This message also contains the packet along with > control information such as the FE Port ID or LFB ID on which the packet > is to be forwarded. The operative term is "such as"; means that there could be more than what you list. Otherwise above is fine. > * Event Notification Messages > Event Register/De-register Req/Resp - This allows the CE to > register/de-register for FE events, LFB events, packets, etc. > Asynchronous FE Event (including FE events such as DoS events, LFB > events, etc) We did things differently, but above is something i can live with. > * State Maintenance Messages or HA related messages Call them maintainance messages. > PE Up/Down - These indicate the state of the FE or CE. Sounds like an event to me. > PE Active/InActive - These are actually commands which can be used by > the CE to Activate or Inactivate an FE (change its state). By activating > an FE, I mean asking it to start forwarding packets. This is a useful > during initial startup of protocol operations, to take the FE into > steady state. These commands can also be very useful to handle HA > scenarios when there are multiple FEs connected to the CE, some are > active and some are standby (or inactive). Could you remove "PE" from that? Should probably be activate/deactivate > Move PrimaryCE - This command is used to change the Primary CE for an > FE. Again, probably "move" is sufficient. > TBD...(Not sure if this is needed, may be Config Req/Resp can be used > for this) > * Management Object or SNMP support Messages > MO Get/Set > MO Response Not sure of need for this. > HeartBeat or Keep-alive - This message may Not be needed, depending on > whether we want this functionality to be provided by the TML I think there is desire to have heartbeats at PL level. So a hearbeat message is needed. > Changes since last post on Protocol Messages... > Removed - Leave Response > Removed - Vendor Specific messages > Added - Move message > > Hope we can get agreement on this basic set, let me know what you guys > think. I am a little slow right now, seems like you covered almost everything. > I will send out a separate email, with some diagrams describing the > Protocol scenarios showing the different messages. Hormuzd, can i accuse you of hogging this? ;-> What text can i write? I asked in the other email cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 01:50:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27312 for ; Wed, 28 Apr 2004 01:50:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhvv-0005fY-PX for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 01:48:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S5mZij021787 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 01:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhv4-0005PT-2j for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 01:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26934 for ; Wed, 28 Apr 2004 01:47: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 1BIhuy-0007na-SQ for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 01:47:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIhu5-0007ZF-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 01:46:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIhtc-0007MK-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 01:46:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhhJ-0002Tm-Io; Wed, 28 Apr 2004 01:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhIB-0007jb-IE for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 01:07:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25315 for ; Wed, 28 Apr 2004 01:07: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 1BIhI6-0007KN-IJ for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:07:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIhH8-00078g-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:06:27 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIhGA-0006mU-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:05:26 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr004.fm.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 i3S55A4B002885; Wed, 28 Apr 2004 05:05:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3S54jaM003813; Wed, 28 Apr 2004 05:05:09 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 M2004042722045630208 ; Tue, 27 Apr 2004 22:04:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 22:04:56 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EC7A664@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQsyjm5ESlROEOdT1O3uILYh63NmgAELYsA From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 28 Apr 2004 05:04:56.0327 (UTC) FILETIME=[59267170:01C42CDE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 22:04:55 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, Thanks for your comments ! I am fine with most of them, will make appropriate changes. Pls see some replies below... -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > Since the discussion around the HA seems to be coming to a reasonable > conclusion,=20 > I am taking this opportunity to post some text around the Protocol > Messages (PL level). > This covers both topic 3 (capability exchange) & 4 a,b. Non-tech question: Where are we going with all the txt that so far you are the serial interface to. From the size of it, it seem inadequate to be going into a draft. I know sooner or later we are going to start editing xml pieces. Is this text a lead/summary to that? [HK] Sure, you can use it as reference, summary or actually use some of the text if you like (of course, I assume some elaboration will be needed in some/most cases) > Couple of comments...I have categorized the messages in a certain way, > however that is Not important to me at this point. I am fine with > however, you guys would like to categorize this or Not categorize this > at all (?) Also, I have tried to incorporate some of the comments that I > received from Weiming, Jamal, others. >=20 > Note to Weiming: The reason for not categorizing these messages as "FE > messages" is so that they can be used by the CEs also in the future.=20 I like this. the ID should clearly identify if it is a CE or FE, no? [HK] Yes IDs can be used for this. > For > e.g., the Leave message can be used by the CE also to leave a ForCES > association with a FE (actually this is a requirement as well but I wont > mention the RFC here, don't want to piss off my friend(Jamal) :-)). > Also, the State messages such as UP/DOWN can be used by CEs also thus > making the protocol future-proof in a way & simplifying some of the HA > schemes. >=20 > * Association Setup Messages > Join Request/Response - The Join Request is used by the FE to join or > start an association with the CE. The Join Response is sent by the CE > and indicates whether the Join Request was successful or not. The CE > also assigns the FE ID to the FE in this message. I am trying my best not to bring up how we did things in order to expidite things(as an example, the way HA is being approached is totaly different from how we did and i hope it makes Ram happy ;->). In some cases, however, sharing the experience helps. We implemented slightly differently. The FEM CEM interface provides the FE its ID. The join/syn/association message could of course be used to override this ID. Infact, in some of the h/ware we used the FE ID could be associated by slot and chasis ID(sometimes referd to as geographical information) which is known to the FE on bootup. [HK] I am fine with this. If the FE already has an ID assigned (e.g. by FEM), it should specify that in the Join Request msg. The CE can always overwrite this value. If an ID has not been assigned for an FE, it should have value of 0 for FE ID in Join Request, in which case the CE must assign an ID for the FE. Does that sound good ? > * State Maintenance Messages or HA related messages Call them maintainance messages. [Sure] > PE Up/Down - These indicate the state of the FE or CE. Sounds like an event to me. [Yes, there is a very subtle difference. What do others think ? ] > PE Active/InActive - These are actually commands which can be used by > the CE to Activate or Inactivate an FE (change its state). By activating > an FE, I mean asking it to start forwarding packets. This is a useful > during initial startup of protocol operations, to take the FE into > steady state. These commands can also be very useful to handle HA > scenarios when there are multiple FEs connected to the CE, some are > active and some are standby (or inactive). Could you remove "PE" from that? Should probably be activate/deactivate [Ok] > Move PrimaryCE - This command is used to change the Primary CE for an > FE. Again, probably "move" is sufficient. [Sure] > TBD...(Not sure if this is needed, may be Config Req/Resp can be used > for this) > * Management Object or SNMP support Messages > MO Get/Set > MO Response Not sure of need for this. > HeartBeat or Keep-alive - This message may Not be needed, depending on > whether we want this functionality to be provided by the TML I think there is desire to have heartbeats at PL level. So a hearbeat message is needed. [HK] I am fine with this. What does Weiming think ? > Changes since last post on Protocol Messages... > Removed - Leave Response > Removed - Vendor Specific messages > Added - Move message >=20 > Hope we can get agreement on this basic set, let me know what you guys > think. I am a little slow right now, seems like you covered almost everything. > I will send out a separate email, with some diagrams describing the > Protocol scenarios showing the different messages. Hormuzd, can i accuse you of hogging this? ;-> What text can i write? I asked in the other email [HK] That's the nicest accusation I have heard so far :-)) After the protocol scenarios, which are mostly diagrams clarifying the messages, the next topic 4.c. is the Common Header. We had one main issue on Type ID which needed to be discussed & closed. Feel free to post some text on that. Here is the remaining list for your reference, 4.c. Common Header 5. Support for Vendor functions 6. Master-Slave or Peer-to-Peer model BTW, even though you may not post text on all issues, I find comments from yourself, Weiming and others very useful...that adds a lot of value to the text. In most cases, I try to reuse most of the text in your comments. regards, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 07:23:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07189 for ; Wed, 28 Apr 2004 07:23:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIn8j-0006Md-E4 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 07:22:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SBM971024463 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 07:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIn6l-0006Bh-KF for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 07:20:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07004 for ; Wed, 28 Apr 2004 07:20: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 1BIn6l-0006lj-3M for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 07:20:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIn5i-0006Rc-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 07:19:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIn4l-00066q-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 07:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIn1s-0005js-Lz; Wed, 28 Apr 2004 07:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhkJ-0002pj-ED for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 01:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26062 for ; Wed, 28 Apr 2004 01:36:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIhkE-00055L-70 for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:36:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIhjF-0004q3-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:35:30 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIhiH-0004Qp-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 01:34:29 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.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 i3S5YEfx022706; Wed, 28 Apr 2004 05:34:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3S5YBa8018914; Wed, 28 Apr 2004 05:34:12 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 M2004042722335900131 ; Tue, 27 Apr 2004 22:33:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 22:33:59 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Protocol Scenarios: topic 4b Message-ID: <468F3FDA28AA87429AD807992E22D07EC7A673@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Scenarios: topic 4b Thread-Index: AcQiS6tv5HOz1kDgRwGUOwSEv3hZSAKMEC9QABkTuSA= From: "Khosravi, Hormuzd M" To: , , , X-OriginalArrivalTime: 28 Apr 2004 05:33:59.0603 (UTC) FILETIME=[68394030:01C42CE2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 27 Apr 2004 22:33:59 -0700 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 Content-Transfer-Encoding: quoted-printable They say pictures speak better than words, here they are... :-) Association Establishment Phase FE PL CE PL | | =20 | Join Req | =20 |---------------------->| =20 | | =20 | Join Resp |=20 |<----------------------| =20 | | =20 | Capability Req | =20 |<----------------------| =20 | | =20 | Capability Resp | =20 |---------------------->| =20 | | =20 | Topo QUERY Req | =20 |<----------------------| =20 | | =20 | Topo QUERY Resp | =20 |---------------------->| =20 | | =20 | UP | =20 |---------------------->| =20 | | =20 | ACTIVATE | =20 |<----------------------| =20 | |=20 Steady State communication phase FE PL CE PL=20 | | =20 | Heart Beat | =20 |<----------------------| =20 | | =20 | Heart Beat |=20 |---------------------->| =20 | | =20 | Configure Req | =20 |<----------------------| =20 | | =20 | Configure Resp | =20 |---------------------->| =20 | | =20 | Event Register Req | =20 |<----------------------| =20 | | =20 | Event Register Resp | =20 |---------------------->| | | =20 | Aysnc Event Notice | =20 |---------------------->| =20 | | =20 | Query Req |=20 |<----------------------| =20 | | =20 | Query Resp |=20 |---------------------->| =20 | | =20 |Control Packet Redirect| |---------------------->| =20 | | =20 Hope these are self-explanatory, let me know if there are any questions/comments, Enjoy, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 09:30:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14912 for ; Wed, 28 Apr 2004 09:30:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoyK-0003bH-RS for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SDJW4n013835 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIomP-0000Fp-2Z for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13455 for ; Wed, 28 Apr 2004 09:07: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 1BIomN-0002jA-JF for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:07:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIolS-0002eP-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:06:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIoky-0002Yd-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoaP-0006i0-4Q; Wed, 28 Apr 2004 08:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInmO-0004xH-Az for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 08:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09447 for ; Wed, 28 Apr 2004 08:03:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInmN-0003Zj-Dg for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:03:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInlW-0003Eo-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:02:15 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BInkj-0002tH-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:01:26 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042805044739:14588 ; Wed, 28 Apr 2004 05:04:47 -0700 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC7A664@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC7A664@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083153682.1034.197.camel@jzny.localdomain> 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 04/28/2004 05:04:47 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 05:04:49 AM, Serialize complete at 04/28/2004 05:04:49 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 Apr 2004 08:01:22 -0400 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 Content-Transfer-Encoding: 7bit On Wed, 2004-04-28 at 01:04, Khosravi, Hormuzd M wrote: > Non-tech question: > Where are we going with all the txt that so far you are the serial > interface to. From the size of it, it seem inadequate to be going into a > draft. I know sooner or later we are going to start editing xml pieces. > Is this text a lead/summary to that? > > [HK] Sure, you can use it as reference, summary or actually use some of > the text if you like (of course, I assume some elaboration will be > needed in some/most cases) I can see you are doing this out of necessity; progress is slow around here. > [HK] I am fine with this. If the FE already has an ID assigned (e.g. by > FEM), it should specify that in the Join Request msg. The CE can always > overwrite this value. If an ID has not been assigned for an FE, it > should have value of 0 for FE ID in Join Request, in which case the CE > must assign an ID for the FE. Does that sound good ? > I know we had some problem with starting with PID 0 in our implementation. I will take a look at the code and my notes to see why. Essentially we eventually went with PID being known preassociation and overriden post association. In the long run we found no need for overriding. I will get back on this. > Hormuzd, can i accuse you of hogging this? ;-> > What text can i write? I asked in the other email > > [HK] That's the nicest accusation I have heard so far :-)) After the > protocol scenarios, which are mostly diagrams clarifying the messages, > the next topic 4.c. is the Common Header. We had one main issue on Type > ID which needed to be discussed & closed. Feel free to post some text on > that. > Here is the remaining list for your reference, > 4.c. Common Header > 5. Support for Vendor functions > 6. Master-Slave or Peer-to-Peer model Wheres the discussion on FEM/CEM? > BTW, even though you may not post text on all issues, I find comments > from yourself, Weiming and others very useful...that adds a lot of value > to the text. In most cases, I try to reuse most of the text in your > comments. The problem is people are lined up to write some XML text; however, in retrospect what you are doing is ok - so continue with the momentum and on my part i will try to respond ASAP - which should keep the ball roling faster. I will do something else that is useful when opportunity presents itself. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 09:31:31 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15038 for ; Wed, 28 Apr 2004 09:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoyT-0003iC-If for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SDJfaE014263 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 09:19:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIotz-0001vO-AW for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 09:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13900 for ; Wed, 28 Apr 2004 09:15: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 1BIotx-0003EC-NR for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:15:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIosw-0003Ad-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:13:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIosi-00037H-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 09:13:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoc8-00074P-AA; Wed, 28 Apr 2004 08:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIo29-0001TQ-0G for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 08:19:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11257 for ; Wed, 28 Apr 2004 08:19:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIo27-0001Fn-VH for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:19:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInzc-0000PH-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:16:48 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BInxK-0007YY-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 08:14:26 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042805174831:14598 ; Wed, 28 Apr 2004 05:17:48 -0700 Subject: Re: [Forces-protocol] Protocol Scenarios: topic 4b From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, wmwang@mail.hzic.edu.cn, avri@acm.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EC7A673@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EC7A673@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083154463.1034.211.camel@jzny.localdomain> 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 04/28/2004 05:17:49 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 05:17:50 AM, Serialize complete at 04/28/2004 05:17:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 Apr 2004 08:14:23 -0400 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 Content-Transfer-Encoding: 7bit On Wed, 2004-04-28 at 01:33, Khosravi, Hormuzd M wrote: > They say pictures speak better than words, here they are... :-) > > Association Establishment Phase > FE PL CE PL > | | > | Join Req | > |---------------------->| > | | > | Join Resp | > |<----------------------| > | | > | Capability Req | > |<----------------------| > | | > | Capability Resp | > |---------------------->| > | | > | Topo QUERY Req | > |<----------------------| > | | > | Topo QUERY Resp | > |---------------------->| > | | > | UP | > |---------------------->| > | | > | ACTIVATE | > |<----------------------| > | | Other than Join, the rest of those messages in my opinion should be available even post-establishment. Example i should be able to activate/deactivate at any time or periodically ask for topology etc. Additionaly, direction of FE->CE could happen at any point as an event IMO; example a new LFB added to FE it may wanna tell the CE about it instead of waiting to be asked by the CE. > > Steady State communication phase > FE PL CE PL > | | > | Heart Beat | > |<----------------------| > | | > | Heart Beat | > |---------------------->| > | | > | Configure Req | > |<----------------------| > | | > | Configure Resp | > |---------------------->| > | | > | Event Register Req | > |<----------------------| > | | > | Event Register Resp | > |---------------------->| > | | > | Aysnc Event Notice | > |---------------------->| > | | > | Query Req | > |<----------------------| > | | > | Query Resp | > |---------------------->| > | | > |Control Packet Redirect| > |---------------------->| > | | > > Hope these are self-explanatory, let me know if there are any > questions/comments, These do look fine. Could you post details on all these messages as you see them with a warning that please stay off FACT? ;-> I know its a lot of work, but you have been doing fine so far ;-> I am going to be a little overwhelmed next two days with customer visit so latency may be introduced in my responses. I will try my best to respond within 1-2 hours. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 11:52:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23228 for ; Wed, 28 Apr 2004 11:52:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrFL-0006eI-BL for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 11:45:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SFjFWt025559 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 11:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqzs-0001bc-Vu for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21562 for ; Wed, 28 Apr 2004 11:29:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqzq-0007Ac-Ig for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 11:29:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqyu-000755-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 11:28:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIqxz-0006zW-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 11:27:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqlZ-0007T0-BD; Wed, 28 Apr 2004 11:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIq5h-00071B-KA for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 10:31:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15358 for ; Wed, 28 Apr 2004 09: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 1BIpGz-0004pp-1k for forces-protocol@ietf.org; Wed, 28 Apr 2004 09:38:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIpG5-0004ne-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 09:37:54 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BIpFO-0004lU-00 for Forces-protocol@ietf.org; Wed, 28 Apr 2004 09:37:11 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 28 Apr 2004 21:49:37 +0800 Message-ID: <038301c42d25$6bc1cf40$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: Cc: "Wang Weiming" References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 21:33:41 +0800 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 Hi Hormuzd, Jamal, and all, ----- Original Message ----- From: "Khosravi, Hormuzd M" Couple of comments...I have categorized the messages in a certain way, however that is Not important to me at this point. I am fine with however, you guys would like to categorize this or Not categorize this at all (?) Also, I have tried to incorporate some of the comments that I received from Weiming, Jamal, others. [Weiming] I suggest that we first list out all possible and necessary messages, then decide if they should be categorized or not. Therefore, the most important for current discussion is not to miss something (messages). Note to Weiming: The reason for not categorizing these messages as "FE messages" is so that they can be used by the CEs also in the future. For e.g., the Leave message can be used by the CE also to leave a ForCES association with a FE (actually this is a requirement as well but I wont mention the RFC here, don't want to piss off my friend(Jamal) :-)). Also, the State messages such as UP/DOWN can be used by CEs also thus making the protocol future-proof in a way & simplifying some of the HA schemes. [Weiming] From my viewpoint, this (for future use) may actually become a reason why we need to explicitly indicate the message functioning direction. I'm sure in many cases, the operation toward FE is different from that toward CE even if they have the same operation name, e.g., if we allow FE to query CE in the future, the message formats for CE->FE and FE->CE are surely diffrent because CE does not have sth like CE model, LFB. I'm also sure we will have messages that can only be allowed functioning in one direction, e.g., config. msg. which is only allowed from CE->FE. Unless we decide that our model is purely peer-to-peer instead mainly Master-slave based. (Jamal, Avri: we may need to lunch this master-slave issue discussion right now along with the protocol message discussion). Back to Hormuzd's question, another reason to use the FE/CE prefix is it may be more clear in the meaning and may be easier for customers to use. Talking about the join message, I think the meaning FE uses is different for that CE (in the future?) uses. A FE actually sends join request message to ask to join, while a CE sends (if needed) only join command to inform the FE of its joining. Besides the join req/resp message, I also have more thinking on the proposed Req/Resp message action mode: 1. I think in a mainly Master-Slave based model, the Req/Resp mode should mainly be used by messages from FE->CE, while for CE->FE msgs, most of them are commands, therefore I think of if it is proper to use word "Request" in this case. They are just commands, therefore it may be more comfortable to say 'config message' instead of 'config request' message. 2. In many cases, Respose msgs are not so necessarily needed, too much use of them may unnecessarily consume more resources. Also, remember we even have ACK mechanism to do the same thing. Even if in some cases we need to define response messages, I have a suggestion that we use a flag in the header or body to allow customers to have a choice whether or not to ask responses. One more thing for response msg to use is we should note the "command result" format (as used in FACT) in the resp msg will eventally be defined by our protocols instead by FE model, I'm just afraid FE model will not be able to define such things. Jamal: I'm afraid what I here talked about the msg direction is a little different from what you may mean. I just mean that we may need to tell customers sth like 'this message can only be sent from CE to FE, and not allowed from FE to CE'. I see what you mean may be for those msgs that can be sent in either directions and you propose that the direction can be implicitly defined by defining the Src ID and Dest ID. I agree that in this case, we may only need to define one msg for both directions, while let the FEid and CEid to decide the direction. And I even think that such direction is very obvious during implementation, because we may never expect a FE will get messages from other FEs. Talking about this, I have to mention our old drafts again. I think the Netlink2 addressing scheme can tell wether the message is from CE or FE, because the PID is universal and the 'Src PID' "Dest. PID' can either be FE or CE, but FACT and GRMP schemes can not. Therefore, I'm afraid here we also have to discuss the common header and addressing mode first. I think we need now decide if we use static field in the header for CE id or FE id, or we just use 'Src. ID' and 'Dest. ID'. In the latter mode, we need to define the address space separately for FEid and CEid. [/Weiming] * Association Setup Messages Join Request/Response - The Join Request is used by the FE to join or start an association with the CE. The Join Response is sent by the CE and indicates whether the Join Request was successful or not. The CE also assigns the FE ID to the FE in this message. [Weiming] As I mentioned above, the FE join may be a little different from CE join. The former is a request, the latter is a command or inform. Leave - This message can be used by an FE or CE to leave an association [Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields instead of 'FEid' and 'CEid' field in the header and let FEid and CEid universally defined, we then only need one message, or else, we may need 'FE leave' and 'CE leave', two msgs. [/Weiming] * Capability Control Messages [Weiming] Can we currently just skip the category name for these messages, because I'm a little confused with the meaning of 'capability' here. Capability Req/Resp (only FE Caps which will be defined in the Model) - I wanted to keep the Caps Query separate from all other Queries. However, if folks wont to only use the Query Req/Resp (below) for this, I am fine with that. [Weiming] I agree to separate capability query from general query here, but I just prefer to use the name '(FE) Capability Query/Resp'instead of 'Capability Req/Resp' for this message, the reason is as I mentioned above. Here the 'resp' is necessary. Query Req/Resp (including FE, LFB Properties as well as LFB topology & Inter-FE Topology) [Weiming] Again, I prefer to use the name '(FE) Query/Query Resp' for this. Here, the 'resp' is necessary. Configuration Req/Resp (FE, LFB attributes) [Weiming]Still prefer '(FE) Configuration message' instead of 'configuration request message' as the name. Note that here the 'resp' is not always necessary. For the contents,it may also include config of LFB topology. * Control Packet or Traffic Maintenance Messages CP Redirect to CE - This message will contain the packet to be redirected along with some control information such as the FE Port ID on which the FE arrived or the LFB ID on which it arrived. CP Forward to FE - This message also contains the packet along with control information such as the FE Port ID or LFB ID on which the packet is to be forwarded. [Weiming]Actually here I think we may only need to define one message the 'Packet Redirect msg', leaving addressing body (FEid CEid) to decide the direction. I don't think the FE port ID or LFB ID here will take effect for the FE to correctly get the packet to be redirected. This should highly rely on the LFB topology to decide where to induce the packets, e.g., from a classifier or a rate limiter (if used for DoS). I suppose that FE model should define a default datapath ID, via which packets enter and are encapusulated as a protocol message. The same is for packets redirected from CE to FE. * Event Notification Messages Event Register/De-register Req/Resp - This allows the CE to register/de-register for FE events, LFB events, packets, etc. Asynchronous FE Event (including FE events such as DoS events, LFB events, etc) [Weiming]In my opinion, we truly do not need to use two specific msgs for event register/de-register. It can be easily done by 'Configuration' msg. no? * State Maintenance Messages or HA related messages PE Up/Down - These indicate the state of the FE or CE. PE Active/InActive - These are actually commands which can be used by the CE to Activate or Inactivate an FE (change its state). By activating an FE, I mean asking it to start forwarding packets. This is a useful during initial startup of protocol operations, to take the FE into steady state. These commands can also be very useful to handle HA scenarios when there are multiple FEs connected to the CE, some are active and some are standby (or inactive). Move PrimaryCE - This command is used to change the Primary CE for an FE. [Weiming]Firstly, I strongly suggest we devide it into FE and CE. They are so different. Then, I think we may only need two messages: FE maintenance msg (CE->FE) -including FE Shutown/Activate/Deactivate/... Note that for FE state Up/Down report, I'm with Jamal that they should be FE events. CE maintenance msg -including move operation To be hornest, I'm still not sure how the CE maintenance msg works, even not sure if it is a CE->FE action or FE->CE. Jamal, could you give more details on how such as Move action works? [/Weiming] [Weiming]I think here we may have missed something that are so important. How we manage the LFB state, that is, how we lunch(mount), activate/deactivate all the LFBs? Can they be included in the 'FE Config msg'? TBD...(Not sure if this is needed, may be Config Req/Resp can be used for this) * Management Object or SNMP support Messages MO Get/Set MO Response [Weiming]We have never had a discussion on how SNMP can be supported from the perspective of protocol. Can we have some on it? What I think is just a case where the SNMP MO and the SNMP agent are located separately in CE and FE. E.g., if an agent is in CE while the set MO is in FE, how then we deal with this if we do not have some protocol message support? A probable way is to define all MOs as FE attribute then to use Config msg to do it. But is is possible to let all MOs be FE attributes? HeartBeat or Keep-alive - This message may Not be needed, depending on whether we want this functionality to be provided by the TML [Weiming]I more prefer to have it as events, therefore, then we can flexibly register/de-register it. Changes since last post on Protocol Messages... Removed - Leave Response Removed - Vendor Specific messages Added - Move message Hope we can get agreement on this basic set, let me know what you guys think. I will send out a separate email, with some diagrams describing the Protocol scenarios showing the different messages. Regards Hormuzd [Weiming] Sorry have made the mail too long. Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 13:22:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00545 for ; Wed, 28 Apr 2004 13:22:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsWF-0001Ys-Cg for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SH6ljo006003 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 13:06:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsS2-0000CW-1G for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28831 for ; Wed, 28 Apr 2004 13:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsRz-0006ze-0I for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:02:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsR1-0006ut-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:01:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIsQ3-0006rT-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:00:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsCD-0005JE-PC; Wed, 28 Apr 2004 12:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs4H-0003AS-TD for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 12:37:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27196 for ; Wed, 28 Apr 2004 12:37:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs4E-0005VR-RX for forces-protocol@ietf.org; Wed, 28 Apr 2004 12:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs3L-0005U3-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 12:36:55 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIs32-0005Ry-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 12:36:36 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.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 i3SGa0fx025842; Wed, 28 Apr 2004 16:36:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3SGZTIC001028; Wed, 28 Apr 2004 16:35:53 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 M2004042809353408257 ; Wed, 28 Apr 2004 09:35:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 09:35:32 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQsi9TPOapLhnSYS5eJ9DmjVQtwKgAEuZVgACf3eeA= From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , , , Cc: X-OriginalArrivalTime: 28 Apr 2004 16:35:32.0404 (UTC) FILETIME=[D2FA0740:01C42D3E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 09:35:31 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, Avri, Ram, Is the compromise proposed by Jamal, myself below acceptable to you guys ? Thanks Hormuzd -----Original Message----- > > [Weiming] If there is no CE-CE comm., the CE has to do from scratch=20 > > (only with > > the FE providing some limited state infomation). In this case, it's > > of very > > little help for the CE to even know who the FE used to talk with. >=20 > [ad] I agree that knowing who had been Primary (assuming there is only > a single primary) is not as useful in this case. Still the Fe should=20 > be able to supply a rather complete picture of its state if so=20 > required. Ok, i think i finaly got what you are saying and i think it is a valid scheme. Since we are already putting responsibility to the FE to be aware of all CEs in multiCE setup, i dont think this additional item will be that much of a cost either performancewise or protolwise (there will be some cost). OTOH, i think if a CE-CE setup decides it wants to likewise pass such information around, that too should be fine. I am not sure how to reach a compromise: Should the setup make the=20 decision? [HK] I agree, we can have a compromise to keep both these schemes, i.e. FE may send events, packets to all CEs or just primary CE as configurable. This can be a behavior which is configurable by the CE. Is this acceptable to Avri, Weiming, others ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 14:17:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05272 for ; Wed, 28 Apr 2004 14:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItV5-0008Hc-DK for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SI9dOO031834 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItKO-0005l9-MF for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:58:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03794 for ; Wed, 28 Apr 2004 13:58: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 1BItKL-0003XR-1Y for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:58:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItJW-0003UU-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:57:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItIq-0003QS-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 13:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt9B-0003R1-ID; Wed, 28 Apr 2004 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsyw-0000ln-D6 for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 13:36:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01911 for ; Wed, 28 Apr 2004 13:36: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 1BIsys-0001tw-Ta for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:36:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsxr-0001ou-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:35:20 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1BIsx2-0001io-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:34:28 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i3SHXkWn092306; Wed, 28 Apr 2004 17:33:46 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 i3SHXjHI158384; Wed, 28 Apr 2004 19:33:45 +0200 Received: from zurich.ibm.com (dhcp69-238.zurich.ibm.com [9.4.69.238]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA34298; Wed, 28 Apr 2004 19:33:44 +0200 Message-ID: <408FEAF8.6040904@zurich.ibm.com> From: Robert Haas Organization: IBM Research Lab 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 To: "Khosravi, Hormuzd M" CC: "Wang,Weiming" , hadi@znyx.com, avri@acm.org, ram.gopal@nokia.com, forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 2:: HA References: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id i3SHXkWn092306 Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 19:33:44 +0200 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 Content-Transfer-Encoding: quoted-printable This seems to address the CE group issue I raised in my previous note,=20 so I am fine with it. The CE group may consist of a single CE or=20 multiple CEs. I suggest to consider symmetry, i.e., FE groups, as well. -Robert Khosravi, Hormuzd M wrote: >Weiming, Avri, Ram, > >Is the compromise proposed by Jamal, myself below acceptable to you guys >? > >Thanks >Hormuzd >-----Original Message----- > > > =20 > >>>[Weiming] If there is no CE-CE comm., the CE has to do from scratch=20 >>>(only with >>>the FE providing some limited state infomation). In this case, it's >>> =20 >>> > > =20 > >>>of very >>>little help for the CE to even know who the FE used to talk with. >>> =20 >>> >>[ad] I agree that knowing who had been Primary (assuming there is only >> =20 >> > > =20 > >>a single primary) is not as useful in this case. Still the Fe should=20 >>be able to supply a rather complete picture of its state if so=20 >>required. >> =20 >> > >Ok, i think i finaly got what you are saying and i think it is >a valid scheme. Since we are already putting responsibility to the >FE to be aware of all CEs in multiCE setup, i dont think this additional >item will be that much of a cost either performancewise or protolwise >(there will be some cost). >OTOH, i think if a CE-CE setup decides it wants to likewise pass such >information around, that too should be fine. >I am not sure how to reach a compromise: Should the setup make the=20 >decision? > >[HK] I agree, we can have a compromise to keep both these schemes, i.e. >FE may send events, packets to all CEs or just primary CE as >configurable. This can be a behavior which is configurable by the CE. Is >this acceptable to Avri, Weiming, others ? > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =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 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 14:22:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05534 for ; Wed, 28 Apr 2004 14:22:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItd0-0001jH-7e for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIHo86006642 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:17:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItXm-0000ff-80 for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04999 for ; Wed, 28 Apr 2004 14:12:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItXi-0004df-IJ for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:12:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItWl-0004WZ-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:11:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItVr-0004Oi-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:10:27 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItVu-0005HB-Ls for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:10:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItP2-0006Om-3A; Wed, 28 Apr 2004 14:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItCi-000473-QX for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 13:50:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03176 for ; Wed, 28 Apr 2004 13:50:38 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItCf-00033i-1Y for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItBm-00030W-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:49:43 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BItB4-0002wP-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 13:48:58 -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 i3SHoEep016054 for ; Wed, 28 Apr 2004 19:50:16 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51AB81B7-993C-11D8-B32D-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 2:: HA To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 13:48:55 -0400 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 Content-Transfer-Encoding: 7bit Hi, Yes, as long as the capability exists in the protocol, I don't mind if someone can turn it off. I would argue, though, that having a FE notify its primary CE (or the CE group) of any new CE association (or loss of association) would be useful even if there is a CE-CE link - just as a safety check. And obviously if everything is going well with CE coordination, then the CE probably will not need to request a state dump from the FE, but of course should be able to. I also think that the ability to stifle event messages, by type including CE association announcements, is probably a general capability which is needed in any case. a. On 28 apr 2004, at 12.35, Khosravi, Hormuzd M wrote: > [HK] I agree, we can have a compromise to keep both these schemes, i.e. > FE may send events, packets to all CEs or just primary CE as > configurable. This can be a behavior which is configurable by the CE. > Is > this acceptable to Avri, Weiming, others ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 14:51:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07105 for ; Wed, 28 Apr 2004 14:51:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItzd-0007ZY-Ps for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:41:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIfDSF029104 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 14:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItuW-0005WI-3o for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:35:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06305 for ; Wed, 28 Apr 2004 14:35: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 1BItuS-0005vh-6m for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:35:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItto-0005qd-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:35:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItsa-0005h7-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:33:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItsc-0005u8-PS for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 14:33:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItpk-0004bo-16; Wed, 28 Apr 2004 14:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItdd-0001vn-DU for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 14:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05392 for ; Wed, 28 Apr 2004 14:18:26 -0400 (EDT) From: avri@acm.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItdZ-0004zW-H3 for forces-protocol@ietf.org; Wed, 28 Apr 2004 14:18:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItcf-0004wi-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 14:17:30 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BItc5-0004u0-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 14:16:53 -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 i3SII8ep016070 for ; Wed, 28 Apr 2004 20:18:10 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083120033.1037.140.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> <1083120033.1037.140.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary=Apple-Mail-14--357688818 Message-Id: <37B28794-9940-11D8-B32D-000393CC2112@acm.org> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 14:16:49 -0400 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,LINES_OF_YELLING, NO_REAL_NAME autolearn=no version=2.60 --Apple-Mail-14--357688818 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 27 apr 2004, at 22.40, Jamal Hadi Salim wrote: > I know sooner or later we are going to start editing xml pieces. Just wanted to let people know that the shell of the draft with all the pieces is ready. So whenever everyone is ready to start dealing with it, they can. a. --Apple-Mail-14--357688818 Content-Type: text/plain; x-unix-mode=0644; name="draft-fpteam-forces-protocol-00.txt" Content-Disposition: attachment; filename=draft-fpteam-forces-protocol-00.txt Content-Transfer-Encoding: quoted-printable Network Working Group F-P Team Internet-Draft May 2004 Expires: October 30, 2004 ForCES Protocol Specification draft-fpteam-forces-protocol-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This is the ForCES protocol specification produced by the protcol design team. Acknowledgment We thank everybody who should be thanked. F-P Team Expires October 30, 2004 [Page 1] =0C Internet-Draft ForCES May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 3 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 8. Security Considerations . . . . . . . . . . . . . . . . . . . 3 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 3 9.2 Informational References . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 3 A. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 B. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 4 Intellectual Property and Copyright Statements . . . . . . . . 5 F-P Team Expires October 30, 2004 [Page 2] =0C Internet-Draft ForCES May 2004 1. Introduction tbd 2. Definitions tbd 3. Protocol Overview tbd 4. TML Requirements tbd 5. Common Header tbd 6. Protocol Messages tbd 7. Protocol Scenarios tbd 8. Security Considerations tbd 9. References 9.1 Normative References 9.2 Informational References Author's Address ForCES Protocol Design Team Phone: EMail: URI: F-P Team Expires October 30, 2004 [Page 3] =0C Internet-Draft ForCES May 2004 Appendix A. IANA considerations tbd Appendix B. Implementation Notes tbd F-P Team Expires October 30, 2004 [Page 4] =0C Internet-Draft ForCES May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION F-P Team Expires October 30, 2004 [Page 5] =0C Internet-Draft ForCES May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. F-P Team Expires October 30, 2004 [Page 6] =0C --Apple-Mail-14--357688818 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-14--357688818-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 17:26:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23544 for ; Wed, 28 Apr 2004 17:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwKI-0001u3-II for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 17:10:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLAgmh007311 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 17:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuzl-00059J-NU for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:45:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12067 for ; Wed, 28 Apr 2004 15:45:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuzi-0002WM-Vx for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 15:45:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuyn-0002RG-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 15:44:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuxq-0002Mt-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 15:43:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuok-0002r4-Ux; Wed, 28 Apr 2004 15:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIugW-0000Q0-3Z for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 15:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10548 for ; Wed, 28 Apr 2004 15:25: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 1BIugT-0001Tw-8V for forces-protocol@ietf.org; Wed, 28 Apr 2004 15:25:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIufT-0001SH-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 15:24:28 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIufB-0001QU-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 15:24:09 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.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 i3SJIafx014386; Wed, 28 Apr 2004 19:18:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3SJITHu022346; Wed, 28 Apr 2004 19:18:33 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 M2004042812182002697 ; Wed, 28 Apr 2004 12:18:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 12:18:20 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1947@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQtT2SB3qZC2vpvRh63nFoG+NeTHQABga9w From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 28 Apr 2004 19:18:20.0232 (UTC) FILETIME=[910E4C80:01C42D55] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 12:18:19 -0700 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 Content-Transfer-Encoding: quoted-printable Thanks a lot, Avri! We all appreciate this effort. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Wednesday, April 28, 2004 11:17 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a On 27 apr 2004, at 22.40, Jamal Hadi Salim wrote: > I know sooner or later we are going to start editing xml pieces. Just wanted to let people know that the shell of the draft with all the=20 pieces is ready. So whenever everyone is ready to start dealing with=20 it, they can. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 18:26:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29397 for ; Wed, 28 Apr 2004 18:26:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxJp-0003EC-NC for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMEHwV012392 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:14:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx4Z-0000IJ-3j for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:58:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26590 for ; Wed, 28 Apr 2004 17:58: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 1BIx4V-00041C-Ay for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 17:58:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIx3X-0003sA-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 17:57:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIx2a-0003kD-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 17:56:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwqg-0003wX-MN; Wed, 28 Apr 2004 17:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwXh-0003DM-Ij for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 17:24:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23379 for ; Wed, 28 Apr 2004 17:24: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 1BIwXd-00003u-NN for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:24:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwWi-0007nI-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:23:33 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwVr-0007hh-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:22:40 -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 i3SLMFBi015711; Wed, 28 Apr 2004 21:22:15 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 i3SLIkFp013763; Wed, 28 Apr 2004 21:20:37 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 M2004042814220327974 ; Wed, 28 Apr 2004 14:22:03 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 14:22:04 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1B19@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQtTDG7YknfsdM0RHGpArPV0c36hgAGiHyg From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 28 Apr 2004 21:22:04.0372 (UTC) FILETIME=[DA302940:01C42D66] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 14:22:03 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Avri, I agree with you on the HA scheme. This would be a reasonable way to go forward. If Weiming, Ram agree with this we can close this issue for good. Regarding, event messages, I have posted an email on the Protocol Messages which addresses your comment I think. If you could review that and let us know what you think, that will be helpful. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Wednesday, April 28, 2004 10:49 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 2:: HA Hi, Yes, as long as the capability exists in the protocol, I don't mind if=20 someone can turn it off. I would argue, though, that having a FE=20 notify its primary CE (or the CE group) of any new CE association (or=20 loss of association) would be useful even if there is a CE-CE link -=20 just as a safety check. And obviously if everything is going well with=20 CE coordination, then the CE probably will not need to request a state=20 dump from the FE, but of course should be able to. I also think that the ability to stifle event messages, by type=20 including CE association announcements, is probably a general=20 capability which is needed in any case. a. On 28 apr 2004, at 12.35, Khosravi, Hormuzd M wrote: > [HK] I agree, we can have a compromise to keep both these schemes, i.e. > FE may send events, packets to all CEs or just primary CE as > configurable. This can be a behavior which is configurable by the CE.=20 > Is > this acceptable to Avri, Weiming, others ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 18:29:04 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29633 for ; Wed, 28 Apr 2004 18:29:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKv-0004PU-9X for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:15:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMFPX4016944 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxCU-0004vv-Om for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:06:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27366 for ; Wed, 28 Apr 2004 18:06:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxCQ-0004Xt-Np for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:06:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxBW-0004TU-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:05:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxAa-0004PS-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:04:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwve-0006II-QO; Wed, 28 Apr 2004 17:49:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIweI-0005eZ-Nr for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 17:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24243 for ; Wed, 28 Apr 2004 17:31: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 1BIweE-00013y-UU for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:31:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwc0-0000fj-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:29:01 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwZC-0000Da-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:26:06 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3SLPlq6015535; Wed, 28 Apr 2004 21:25:48 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 i3SLMHFv016040; Wed, 28 Apr 2004 21:23:56 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 M2004042814252328485 ; Wed, 28 Apr 2004 14:25:23 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 14:25:23 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1B27@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQtR5YPV3bZuAWZSQW0enNW1vQjrwAH3U0g From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: "Wang,Weiming" , , , , X-OriginalArrivalTime: 28 Apr 2004 21:25:23.0359 (UTC) FILETIME=[50CB2AF0:01C42D67] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 14:25:23 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Robert Sorry for the late reply. Yes I think your comments regarding CE Group get addressed by having this scheme. Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 This seems to address the CE group issue I raised in my previous note,=20 so I am fine with it. The CE group may consist of a single CE or=20 multiple CEs. I suggest to consider symmetry, i.e., FE groups, as well. -Robert Khosravi, Hormuzd M wrote: >Weiming, Avri, Ram, > >Is the compromise proposed by Jamal, myself below acceptable to you guys >? > >Thanks >Hormuzd >-----Original Message----- > >>>[Weiming] If there is no CE-CE comm., the CE has to do from scratch=20 >>>(only with >>>the FE providing some limited state infomation). In this case, it's >>>of very >>>little help for the CE to even know who the FE used to talk with. >>> =20 >>> >>[ad] I agree that knowing who had been Primary (assuming there is only >>a single primary) is not as useful in this case. Still the Fe should=20 >>be able to supply a rather complete picture of its state if so=20 >>required. >> =20 > >Ok, i think i finaly got what you are saying and i think it is >a valid scheme. Since we are already putting responsibility to the >FE to be aware of all CEs in multiCE setup, i dont think this additional >item will be that much of a cost either performancewise or protolwise >(there will be some cost). >OTOH, i think if a CE-CE setup decides it wants to likewise pass such >information around, that too should be fine. >I am not sure how to reach a compromise: Should the setup make the=20 >decision? > >[HK] I agree, we can have a compromise to keep both these schemes, i.e. >FE may send events, packets to all CEs or just primary CE as >configurable. This can be a behavior which is configurable by the CE. Is >this acceptable to Avri, Weiming, others ? > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 18:29:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29662 for ; Wed, 28 Apr 2004 18:29:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKv-0004Q5-QM for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:15:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMFP9l016981 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxDH-0005L5-Cz for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:07:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27450 for ; Wed, 28 Apr 2004 18:07: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 1BIxDC-0004al-UG for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:07:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxCG-0004WV-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:06:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxBH-0004Rk-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:05:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwvm-0006LK-Pt; Wed, 28 Apr 2004 17:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwgO-00068O-K6 for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 17:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24602 for ; Wed, 28 Apr 2004 17:33: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 1BIwgK-0001Py-UW for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwfN-0001I1-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:32:31 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwe0-0000xA-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:31:04 -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 i3SLUbBi020330; Wed, 28 Apr 2004 21:30:37 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 i3SLS5Fd019165; Wed, 28 Apr 2004 21:28:58 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 M2004042814302529294 ; Wed, 28 Apr 2004 14:30:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 14:30:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1B36@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQtIe+9VlccXOylR3qBeQADyLKhXQARZEjw From: "Khosravi, Hormuzd M" To: Cc: , X-OriginalArrivalTime: 28 Apr 2004 21:30:25.0455 (UTC) FILETIME=[04DB5BF0:01C42D68] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 14:30:23 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, My replies below...Thanks ! -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > Non-tech question: > Where are we going with all the txt that so far you are the serial > interface to. From the size of it, it seem inadequate to be going into a > draft. I know sooner or later we are going to start editing xml pieces. > Is this text a lead/summary to that? >=20 > [HK] Sure, you can use it as reference, summary or actually use some of > the text if you like (of course, I assume some elaboration will be > needed in some/most cases) I can see you are doing this out of necessity; progress is slow around here.=20 [yep] > [HK] I am fine with this. If the FE already has an ID assigned (e.g. by > FEM), it should specify that in the Join Request msg. The CE can always > overwrite this value. If an ID has not been assigned for an FE, it > should have value of 0 for FE ID in Join Request, in which case the CE > must assign an ID for the FE. Does that sound good ? >=20 I know we had some problem with starting with PID 0 in our implementation. I will take a look at the code and my notes to see why. Essentially we eventually went with PID being known preassociation and overriden post association. In the long run we found no need for overriding. I will get back on this. [Ok, let us know...we can have some other fixed value for the FEID instead of 0, if that makes sense] > Hormuzd, can i accuse you of hogging this? ;-> > What text can i write? I asked in the other email >=20 > [HK] That's the nicest accusation I have heard so far :-)) After the > protocol scenarios, which are mostly diagrams clarifying the messages, > the next topic 4.c. is the Common Header. We had one main issue on Type > ID which needed to be discussed & closed. Feel free to post some text on > that. > Here is the remaining list for your reference, > 4.c. Common Header > 5. Support for Vendor functions > 6. Master-Slave or Peer-to-Peer model Wheres the discussion on FEM/CEM?=20 [HK] That was part of topic 3. I partially covered topic 3 by showing messages for Capability Exchange, Feel free to post text on FEM/CEM if you like. > BTW, even though you may not post text on all issues, I find comments > from yourself, Weiming and others very useful...that adds a lot of value > to the text. In most cases, I try to reuse most of the text in your > comments. The problem is people are lined up to write some XML text; however, in retrospect what you are doing is ok - so continue with the momentum and on my part i will try to respond ASAP - which should keep the ball roling faster. I will do something else that is useful when opportunity presents itself.=20 Thanks a lot, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed Apr 28 18:31:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29832 for ; Wed, 28 Apr 2004 18:31:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxWH-0000QE-KT for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:27:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMR9TT001616 for forces-protocol-archive@odin.ietf.org; Wed, 28 Apr 2004 18:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKF-0003mc-QK for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:14:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28225 for ; Wed, 28 Apr 2004 18:14:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxKB-00052L-Lk for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:14:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxJA-0004w2-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:13:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxIs-0004sG-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 18:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwxK-0006xF-Gy; Wed, 28 Apr 2004 17:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwm9-0000XH-RX for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 17:39:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25064 for ; Wed, 28 Apr 2004 17:39:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwm5-0001wz-Vp for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:39:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwlB-0001u1-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:38:29 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwkN-0001ns-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 17:37:39 -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 i3SLb4Bi023983; Wed, 28 Apr 2004 21:37:04 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 i3SLZMF9023292; Wed, 28 Apr 2004 21:35:25 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 M2004042814365230281 ; Wed, 28 Apr 2004 14:36:52 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 14:36:52 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Scenarios: topic 4b Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1B4E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Scenarios: topic 4b Thread-Index: AcQtIx5yBPQbdO4cTti1D2SYZeCbkwARPzFw From: "Khosravi, Hormuzd M" To: Cc: , , X-OriginalArrivalTime: 28 Apr 2004 21:36:52.0743 (UTC) FILETIME=[EBB2D170:01C42D68] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 14:36:51 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim >=20 > Association Establishment Phase > FE PL CE PL > | | =20 > | Join Req | =20 > |---------------------->| =20 > | | =20 > | Join Resp |=20 > |<----------------------| =20 > | | =20 > | Capability Req | =20 > |<----------------------| =20 > | | =20 > | Capability Resp | =20 > |---------------------->| =20 > | | =20 > | Topo QUERY Req | =20 > |<----------------------| =20 > | | =20 > | Topo QUERY Resp | =20 > |---------------------->| =20 > | | =20 > | UP | =20 > |---------------------->| =20 > | | =20 > | ACTIVATE | =20 > |<----------------------| =20 > | |=20 Other than Join, the rest of those messages in my opinion should be=20 available even post-establishment. Example i should be able to activate/deactivate at any time or periodically ask for topology etc. Additionaly, direction of FE->CE could happen at any point as an event IMO; example a new LFB added to FE it may wanna tell the CE about it instead of waiting to be asked by the=20 CE. [HK] Sure, I agree. Events in the FE->CE direction are covered by Async Event messages (below) >=20 > Steady State communication phase > FE PL CE PL=20 > | | =20 > | Heart Beat | =20 > |<----------------------| =20 > | | =20 > | Heart Beat |=20 > |---------------------->| =20 > | | =20 > | Configure Req | =20 > |<----------------------| =20 > | | =20 > | Configure Resp | =20 > |---------------------->| =20 > | | =20 > | Event Register Req | =20 > |<----------------------| =20 > | | =20 > | Event Register Resp | =20 > |---------------------->| > | | =20 > | Aysnc Event Notice | =20 > |---------------------->| =20 > | | =20 > | Query Req |=20 > |<----------------------| =20 > | | =20 > | Query Resp |=20 > |---------------------->| =20 > | | =20 > |Control Packet Redirect| > |---------------------->| =20 > | | =20 >=20 > Hope these are self-explanatory, let me know if there are any > questions/comments, These do look fine.=20 Could you post details on all these messages as you see them with a warning that please stay off FACT? ;-> I know its a lot of work, but you have been doing fine so far ;-> [HK] Ok, I'll try to do this, once I get doubts of Weiming, other comments on Protocol Messages clarified. I am going to be a little overwhelmed next two days with customer visit so latency may be introduced in my responses. I will try my best to respond within 1-2 hours.=20 [HK] Thanks for your prompt responses ! Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 00:08:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16207 for ; Thu, 29 Apr 2004 00:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2la-0001q8-7F for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 00:03:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T43IV7007073 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 00:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2iC-0000aN-Iu for forces-protocol-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:59:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15775 for ; Wed, 28 Apr 2004 23:59:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ2i7-00075i-7O for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 23:59:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2hB-0006wo-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 23:58:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2g8-0006oB-00 for forces-protocol-web-archive@ietf.org; Wed, 28 Apr 2004 23:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2af-0007YE-1A; Wed, 28 Apr 2004 23:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2Mx-0004H4-PJ for forces-protocol@optimus.ietf.org; Wed, 28 Apr 2004 23:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14326 for ; Wed, 28 Apr 2004 23:37:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ2Ms-0004LN-HA for forces-protocol@ietf.org; Wed, 28 Apr 2004 23:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Lr-0004Er-00 for forces-protocol@ietf.org; Wed, 28 Apr 2004 23:36:44 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ2LE-00049G-00 for Forces-protocol@ietf.org; Wed, 28 Apr 2004 23:36:04 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042820395443:185 ; Wed, 28 Apr 2004 20:39:54 -0700 Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: Forces-protocol@ietf.org In-Reply-To: <038301c42d25$6bc1cf40$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> <038301c42d25$6bc1cf40$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1083209759.1051.50.camel@jzny.localdomain> 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 04/28/2004 08:39:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2004 08:40:01 PM, Serialize complete at 04/28/2004 08:40:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 Apr 2004 23:35:59 -0400 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 Content-Transfer-Encoding: 7bit Weiming, On Wed, 2004-04-28 at 09:33, Wang,Weiming wrote: > > [Weiming] From my viewpoint, this (for future use) may actually become a reason > why we need to explicitly indicate the message functioning direction. I'm sure > in many cases, the operation toward FE is different from that toward CE even if > they have the same operation name, e.g., if we allow FE to query CE in the > future, the message formats for CE->FE and FE->CE are surely diffrent because CE > does not have sth like CE model, LFB. I'm also sure we will have messages that > can only be allowed functioning in one direction, e.g., config. msg. which is > only allowed from CE->FE. Unless we decide that our model is purely > peer-to-peer instead mainly Master-slave based. (Jamal, Avri: > we may need to lunch this master-slave issue discussion right now along with the > protocol message discussion). Back to Hormuzd's question, another reason to use > the FE/CE prefix is it may be more clear in the meaning and may be easier for > customers to use. To take from netlink2 experience: The important piece is the end processor of the "command". If direction is CE->FE thats a config. If direction is FE->CE typically CE would intepret that to be an event. > Talking about the join message, I think the meaning FE uses is different for > that CE (in the future?) uses. A FE actually sends join request message to ask > to join, while a CE sends (if needed) only join command to inform the FE of its > joining. I actually dont like the name "join". SYNchronize or boot are probably more descriptive. Direction of CE->FE could be interpreted by FE to imply that a CE is rebooted/restarting which would cast doubt on its (FE)state. > Besides the join req/resp message, I also have more thinking on the proposed > Req/Resp message action mode: > > 1. I think in a mainly Master-Slave based model, the Req/Resp mode should mainly > be used by messages from FE->CE, while for CE->FE msgs, most of them are > commands, therefore I think of if it is proper to use word "Request" in this > case. They are just commands, therefore it may be more comfortable to say > 'config message' instead of 'config request' message. Refer to my comments above. > 2. In many cases, Respose msgs are not so necessarily needed, too much use of > them may unnecessarily consume more resources. Also, remember we even have ACK > mechanism to do the same thing. Even if in some cases we need to define response > messages, I have a suggestion that we use a flag in the header or body to allow > customers to have a choice whether or not to ask responses. > One more thing for response msg to use is we should note the "command result" > format (as used in FACT) in the resp msg will eventally > be defined by our protocols instead by FE model, I'm just afraid FE model will > not be able to define such things. > > Jamal: I'm afraid what I here talked about the msg direction is a little > different from what you may mean. I just mean that we may need to tell customers > sth like 'this message can only be sent from CE to FE, and not allowed from FE > to CE'. Refer to my comment above. I think the message can be sent in either direction; how its intepretted may be the issue. > I see what you mean may be for those msgs that can be sent in either > directions and you propose that the direction can be implicitly defined by > defining the Src ID and Dest ID. I agree that in this case, we may only need to > define one msg for both directions, while let the FEid and CEid to decide the > direction. And I even think that such direction is very obvious during > implementation, because we may never expect a FE will get messages from other > FEs. Refer to my comments above and lets discuss > Talking about this, I have to mention our old drafts again. I think the Netlink2 > addressing scheme can tell wether the message is from CE or FE, because the PID > is universal and the 'Src PID' "Dest. PID' can either be FE or CE, but FACT and > GRMP schemes can not. Therefore, I'm afraid here we also have to discuss the > common header and addressing mode first. I think we need now decide if we use > static field in the header for CE id or FE id, or we just use 'Src. ID' and > 'Dest. ID'. In the latter mode, we need to define the address space separately > for FEid and CEid. > [/Weiming] > Refer to my comments on intepreting msgs instead of labeling them that they are for a specific type of node. Addressing should direct message to specific types of nodes. When they get to the node, the execution should be the nodes decision. > * Association Setup Messages > Join Request/Response - The Join Request is used by the FE to join or > start an association with the CE. The Join Response is sent by the CE > and indicates whether the Join Request was successful or not. The CE > also assigns the FE ID to the FE in this message. > > [Weiming] As I mentioned above, the FE join may be a little different from CE > join. The former is a request, the latter is a command or inform. > I think we can make great use of CEs sending SYNs to reset FE states. > Leave - This message can be used by an FE or CE to leave an association agreed. > [Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields > instead of 'FEid' and 'CEid' field in the header and let FEid and CEid > universally defined, we then only need one message, or else, we may need 'FE > leave' and 'CE leave', two msgs. > [/Weiming] > Refer to my earlier comment. I will cut my response to here because i think the rest of your message has mostly got thoughts based on direction of message and CEid vs FEid and i will keep repeating the same thing. Lets discuss above then we can continue with the rest. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 02:04:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26989 for ; Thu, 29 Apr 2004 02:04:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4Yx-000104-90 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 01:58:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T5wNsJ003843 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 01:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4TW-0008Bf-9A for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 01:52:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22100 for ; Thu, 29 Apr 2004 01:52:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ4TQ-0006K1-15 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 01:52:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4Ry-00060d-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 01:51:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4Pb-0005Te-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 01:48:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4FG-0005Cb-L6; Thu, 29 Apr 2004 01:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ46W-0003ma-Lv for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 01:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20166 for ; Thu, 29 Apr 2004 01:28: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 1BJ46Q-0002kn-Am for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:28:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ45c-0002cp-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:28:05 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJ452-0002Rv-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:27:28 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 29 Apr 2004 13:39:28 +0800 Message-ID: <03fc01c42daa$1b6b65d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> <038301c42d25$6bc1cf40$845c21d2@Necom.hzic.edu.cn> <1083209759.1051.50.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:23:29 +0800 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 Jamal, Thank you for the reply. ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > > On Wed, 2004-04-28 at 09:33, Wang,Weiming wrote: > > > > > > [Weiming] From my viewpoint, this (for future use) may actually become a reason > > why we need to explicitly indicate the message functioning direction. I'm sure > > in many cases, the operation toward FE is different from that toward CE even if > > they have the same operation name, e.g., if we allow FE to query CE in the > > future, the message formats for CE->FE and FE->CE are surely diffrent because CE > > does not have sth like CE model, LFB. I'm also sure we will have messages that > > can only be allowed functioning in one direction, e.g., config. msg. which is > > only allowed from CE->FE. Unless we decide that our model is purely > > peer-to-peer instead mainly Master-slave based. (Jamal, Avri: > > we may need to lunch this master-slave issue discussion right now along with the > > protocol message discussion). Back to Hormuzd's question, another reason to use > > the FE/CE prefix is it may be more clear in the meaning and may be easier for > > customers to use. > > To take from netlink2 experience: The important piece is the end > processor of the "command". > If direction is CE->FE thats a config. If direction is FE->CE typically > CE would intepret that to be an event. > [Wweiming]I think this approach (we may also call it implicit approach) may be quite different from that Hormuzd proposed. Could you try to list more msgs based on this idea to ease our discussion? I think it is also a feasible approach. My idea was actually moer based on Hormuzd's proposal, that is, the config msg is only allowed from CE->FE. In this case, I think to mark the direction that is to mark as 'FE config' is necessary. Because the following discussion is more related to this base, therefore I also just stop here to let us decide this first. Hormuzd, could you have some of your idea? Thank you. Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 02:30:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07736 for ; Thu, 29 Apr 2004 02:30:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ52M-0007vB-Qa for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:28:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6Skd5030445 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4qw-0002fA-SX for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:16:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06697 for ; Thu, 29 Apr 2004 02:16: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 1BJ4qq-0002UY-5L for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:16:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4q2-0002Kn-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:16:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4p5-00029F-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4fQ-0003oo-2Z; Thu, 29 Apr 2004 02:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4ZZ-000132-Qi for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 01:59:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22440 for ; Thu, 29 Apr 2004 01:58:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ4ZT-0007GZ-CW for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4YV-00077D-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:57:55 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJ4Xk-0006yl-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:57:33 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 29 Apr 2004 14:09:30 +0800 Message-ID: <043f01c42dae$4da03180$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> <1083120033.1037.140.camel@jzny.localdomain> <37B28794-9940-11D8-B32D-000393CC2112@acm.org> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:53:32 +0800 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 Thank you so much for the work. Weiming ----- Original Message ----- From: To: Sent: Thursday, April 29, 2004 2:16 AM Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a > > On 27 apr 2004, at 22.40, Jamal Hadi Salim wrote: > > > I know sooner or later we are going to start editing xml pieces. > > Just wanted to let people know that the shell of the draft with all the > pieces is ready. So whenever everyone is ready to start dealing with > it, they can. > > a. > > -------------------------------------------------------------------------------- > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 02:35:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08055 for ; Thu, 29 Apr 2004 02:35:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ52T-0007yk-VY for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:28:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6SrSn030661 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4vl-0005HV-JG for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:21:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07231 for ; Thu, 29 Apr 2004 02:21: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 1BJ4vf-0003AJ-0a for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:21:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4um-00031w-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:20:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4u7-0002uE-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:20:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4oC-0000tY-0c; Thu, 29 Apr 2004 02:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4aj-0001Ot-1H for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 02:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22667 for ; Thu, 29 Apr 2004 02:00: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 1BJ4ac-0007SM-EZ for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:00:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4Zo-0007Jn-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:59:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJ4ZA-00075b-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 01:58:37 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 29 Apr 2004 14:10:01 +0800 Message-ID: <044401c42dae$60454b90$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07ECE164D@orsmsx408.jf.intel.com> <51AB81B7-993C-11D8-B32D-000393CC2112@acm.org> Subject: Re: [Forces-protocol] topic 2:: HA 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 13:54:03 +0800 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 Hi Avri, Rob, Hormuzd, I actually quite agree to retain the ability at the PL for FE able to Broad/Mulitcast to CEs regarding its events, ability change, etc, and also quite agree with Avri's idea below. What I propose is just we may be careful when we recommend a CE failover (HA) scheme to customers. We should not let customers have a feeling that such B/M ability can solve HA very well. Customers should more rely on their CE-CE implementation for this purpose, with the B/M ability as only some asistance, therefore 'may assist fast CE failover recovery' may be the appropriate description. Cheers, Weiming ----- Original Message ----- From: To: Sent: Thursday, April 29, 2004 1:48 AM Subject: Re: [Forces-protocol] topic 2:: HA > Hi, > > Yes, as long as the capability exists in the protocol, I don't mind if > someone can turn it off. I would argue, though, that having a FE > notify its primary CE (or the CE group) of any new CE association (or > loss of association) would be useful even if there is a CE-CE link - > just as a safety check. And obviously if everything is going well with > CE coordination, then the CE probably will not need to request a state > dump from the FE, but of course should be able to. > > I also think that the ability to stifle event messages, by type > including CE association announcements, is probably a general > capability which is needed in any case. > > a. > > On 28 apr 2004, at 12.35, Khosravi, Hormuzd M wrote: > > > [HK] I agree, we can have a compromise to keep both these schemes, i.e. > > FE may send events, packets to all CEs or just primary CE as > > configurable. This can be a behavior which is configurable by the CE. > > Is > > this acceptable to Avri, Weiming, others ? > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 03:02:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09501 for ; Thu, 29 Apr 2004 03:02:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Us-00071r-GA for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:58:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6wETj027020 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 02:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Nq-0005F3-9k for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08877 for ; Thu, 29 Apr 2004 02:50: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 1BJ5Nj-0007Ey-8v for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:50:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5Mq-000772-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:49:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5M0-0006yo-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5L2-0004AF-1A; Thu, 29 Apr 2004 02:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5BE-00027D-MW for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 02:37:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08223 for ; Thu, 29 Apr 2004 02:37:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5B7-0005QW-Ox for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:37:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5AD-0005HS-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:36:54 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ59I-00052M-00 for Forces-protocol@ietf.org; Thu, 29 Apr 2004 02:35:56 -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 i3T6ZNWp011439; Thu, 29 Apr 2004 06:35:24 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 i3T6ZRnY011139; Thu, 29 Apr 2004 06:35:27 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 M2004042823350909860 ; Wed, 28 Apr 2004 23:35:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 23:34:18 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1E95@orsmsx408.jf.intel.com> Thread-Topic: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQtNU675u8EPopyQ1a8CK9jCcJv2gAQ5HpA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , , , X-OriginalArrivalTime: 29 Apr 2004 06:34:18.0259 (UTC) FILETIME=[FF861630:01C42DB3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 23:34:17 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, This email is way too long, it seems like you are trying to clarify multiple topics in this email. One suggestion for the future, break it into multiple emails and put the appropriate subject headers, that makes it a lot easier for everyone to promptly respond. I'll go ahead and split this email into multiple smaller ones and try to respond to all your comments. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Couple of comments...I have categorized the messages in a certain way, however that is Not important to me at this point. I am fine with however, you guys would like to categorize this or Not categorize this at all (?) Also, I have tried to incorporate some of the comments that I received from Weiming, Jamal, others. [Weiming] I suggest that we first list out all possible and necessary messages, then decide if they should be categorized or not. Therefore, the most important for current discussion is not to miss something (messages). [HK] Agree, that is my thinking as well Note to Weiming: The reason for not categorizing these messages as "FE messages" is so that they can be used by the CEs also in the future. For e.g., the Leave message can be used by the CE also to leave a ForCES association with a FE (actually this is a requirement as well but I wont mention the RFC here, don't want to piss off my friend(Jamal) :-)). Also, the State messages such as UP/DOWN can be used by CEs also thus making the protocol future-proof in a way & simplifying some of the HA schemes. [Weiming] From my viewpoint, this (for future use) may actually become a reason why we need to explicitly indicate the message functioning direction. I'm sure in many cases, the operation toward FE is different from that toward CE even if they have the same operation name, e.g., if we allow FE to query CE in the future, the message formats for CE->FE and FE->CE are surely different because CE does not have sth like CE model, LFB. I'm also sure we will have messages that can only be allowed functioning in one direction, e.g., config. msg. which is only allowed from CE->FE. Unless we decide that our model is purely peer-to-peer instead mainly Master-slave based. (Jamal, Avri: we may need to lunch this master-slave issue discussion right now along with the protocol message discussion). Back to Hormuzd's question, another reason to use the FE/CE prefix is it may be more clear in the meaning and may be easier for customers to use. [HK] I don't believe we need to use FE/CE prefixes for all messages. I agree that messages such as Configuration Req are only from CE to FE. However, messages such as Join, leave can be used from FE->CE or CE->CE (in the future) or CE->FE (only leave). We should just be able to use FEID/CEID for clarifying the direction, see Jamal's email on this. Talking about the join message, I think the meaning FE uses is different for that CE (in the future?) uses. A FE actually sends join request message to ask to join, while a CE sends (if needed) only join command to inform the FE of its joining. [HK] A Join message from a CE will not be sent to another FE, but to other CEs only to try to join a NE (association of CEs & FEs). Hope this clarifies your doubt. The Reqs/framework also mention this I believe. Besides the join req/resp message, I also have more thinking on the proposed Req/Resp message action mode: 1. I think in a mainly Master-Slave based model, the Req/Resp mode should mainly be used by messages from FE->CE, while for CE->FE msgs, most of them are commands, therefore I think of if it is proper to use word "Request" in this case. They are just commands, therefore it may be more comfortable to say 'config message' instead of 'config request' message. [HK] This is a terminology issue. We have been using Request messages to carry Commands. There isn't much to this. Req/Resp is pretty easy terminology, used in a lot of different protocols. 2. In many cases, Respose msgs are not so necessarily needed, too much use of them may unnecessarily consume more resources. Also, remember we even have ACK mechanism to do the same thing. Even if in some cases we need to define response messages, I have a suggestion that we use a flag in the header or body to allow customers to have a choice whether or not to ask responses. One more thing for response msg to use is we should note the "command result" format (as used in FACT) in the resp msg will eventually be defined by our protocols instead by FE model, I'm just afraid FE model will not be able to define such things. [HK] Responses are needed for most messages to give the Status of a request and to the meet the timeliness requirement. You can call this an ACK, but the difference is that a Status or command result is included in Responses as opposed to ACKs, which is just like an echo of the original msg. BTW, I believe the FE Model is already defining or soon going to define these "command results" as you call it. Jamal: I'm afraid what I here talked about the msg direction is a little different from what you may mean. I just mean that we may need to tell customers sth like 'this message can only be sent from CE to FE, and not allowed from FE to CE'.=20 [HK] We will need to put text in the message explanation to take care of this anyway. A FE/CE prefix doesn't necessarily solve this problem. I see what you mean may be for those msgs that can be sent in either directions and you propose that the direction can be implicitly defined by defining the Src ID and Dest ID. I agree that in this case, we may only need to define one msg for both directions, while let the FEid and CEid to decide the direction. And I even think that such direction is very obvious during implementation, because we may never expect a FE will get messages from other FEs. [HK] Sure, this is the same point I was making before. So we agree on this (using CEID, FEID) then ? Talking about this, I have to mention our old drafts again. I think the Netlink2 addressing scheme can tell wether the message is from CE or FE, because the PID is universal and the 'Src PID' "Dest. PID' can either be FE or CE, but FACT and GRMP schemes can not. Therefore, I'm afraid here we also have to discuss the common header and addressing mode first. I think we need now decide if we use static field in the header for CE id or FE id, or we just use 'Src. ID' and 'Dest. ID'. In the latter mode, we need to define the address space separately for FEid and CEid. [/Weiming] [HK] I see your point, I think :) If we call them Src ID, Dest ID, (instead or CEID, FEID) they can be used by the CE to send a message to another CE,...right ? Just as they can be used by a FE to send message to a CE. I am fine with this, I don't think its more than a terminology change in the header (replace CEID, FEID with SrcID, DestID). We don't need any additional address space as you are suggesting. Hope this helps, Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 03:06:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09642 for ; Thu, 29 Apr 2004 03:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Xb-0007QW-2c for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 03:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T7131K028543 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 03:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Sj-0006EG-EO for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:56:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09047 for ; Thu, 29 Apr 2004 02:55: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 1BJ5Sc-0000AJ-GH for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:55:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5Rg-000014-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:54:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5R9-0007gm-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 02:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5M0-0004ip-Ex; Thu, 29 Apr 2004 02:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5DE-0002cr-Ve for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 02:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08361 for ; Thu, 29 Apr 2004 02:39: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 1BJ5D7-0005k7-Vm for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:39:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5CL-0005cP-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:39:06 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ5Bl-0005Ro-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 02:38:29 -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 i3T6c5Wp013204; Thu, 29 Apr 2004 06:38:06 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 i3T6cAnY012855; Thu, 29 Apr 2004 06:38:10 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 M2004042823374910381 ; Wed, 28 Apr 2004 23:37:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 23:37:49 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1E96@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQtraRyThPi03lRSb+mUpCBPHBz1QABmDKQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 29 Apr 2004 06:37:49.0682 (UTC) FILETIME=[7D8AAD20:01C42DB4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Apr 2004 23:37:49 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > > > > > [Weiming] From my viewpoint, this (for future use) may actually become a reason > > why we need to explicitly indicate the message functioning direction. I'm sure > > in many cases, the operation toward FE is different from that toward CE even if > > they have the same operation name, e.g., if we allow FE to query CE in the > > future, the message formats for CE->FE and FE->CE are surely diffrent because CE > > does not have sth like CE model, LFB. I'm also sure we will have messages that > > can only be allowed functioning in one direction, e.g., config. msg. which is > > only allowed from CE->FE. Unless we decide that our model is purely > > peer-to-peer instead mainly Master-slave based. (Jamal, Avri: > > we may need to lunch this master-slave issue discussion right now along with the > > protocol message discussion). Back to Hormuzd's question, another reason to use > > the FE/CE prefix is it may be more clear in the meaning and may be easier for > > customers to use. > > To take from netlink2 experience: The important piece is the end > processor of the "command". > If direction is CE->FE thats a config. If direction is FE->CE typically > CE would intepret that to be an event. > [Wweiming]I think this approach (we may also call it implicit approach) may be quite different from that Hormuzd proposed. Could you try to list more msgs based on this idea to ease our discussion? I think it is also a feasible approach. My idea was actually moer based on Hormuzd's proposal, that is, the config msg is only allowed from CE->FE. In this case, I think to mark the direction that is to mark as 'FE config' is necessary. Because the following discussion is more related to this base, therefore I also just stop here to let us decide this first. Hormuzd, could you have some of your idea? Thank you. [HK] I agree with Jamal, I think we are both saying the same thing. Adding FE/CE prefixes isnt necessary and actually doesn't solve the problem that you are stating, we need to add text to clarify this in the draft anyways. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 03:49:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11340 for ; Thu, 29 Apr 2004 03:49:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ68a-0007dr-JA for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 03:39:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T7dG2X029371 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 03:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ65U-00065O-Qw for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 03:36:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10765 for ; Thu, 29 Apr 2004 03:35:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ65N-0005ya-Fg for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 03:35:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ64O-0005pM-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 03:34:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ63t-0005h2-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 03:34:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5xp-0004gA-Pz; Thu, 29 Apr 2004 03:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5qA-0003Mj-Vi for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 03:20:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10234 for ; Thu, 29 Apr 2004 03:20: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 1BJ5q3-0003ix-Lo for forces-protocol@ietf.org; Thu, 29 Apr 2004 03:20:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5ot-0003Mz-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 03:18:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ5nQ-000355-04 for Forces-protocol@ietf.org; Thu, 29 Apr 2004 03:17:25 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJ5ZU-0008Du-DN for Forces-protocol@ietf.org; Thu, 29 Apr 2004 03:03:00 -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 i3T72gfW013665; Thu, 29 Apr 2004 07:02:42 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 i3T72Snk025126; Thu, 29 Apr 2004 07:02:36 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 M2004042900021813511 ; Thu, 29 Apr 2004 00:02:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 00:02:18 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE1EA0@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQtNU675u8EPopyQ1a8CK9jCcJv2gAUIfYA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 29 Apr 2004 07:02:18.0630 (UTC) FILETIME=[E91A5A60:01C42DB7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 00:02:18 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, Here is the other part of your email. My previous email has already addressed most of your questions, see a few more replies below... -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Leave - This message can be used by an FE or CE to leave an association [Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields instead of 'FEid' and 'CEid' field in the header and let FEid and CEid universally defined, we then only need one message, or else, we may need 'FE leave' and 'CE leave', two msgs. [/Weiming] [HK] See Jamal's email on this, direction is good enough for this. The only time that we need Src, Dest ID is if we want to allow messages between Ces (CE-to-CE) messages in the future. * Capability Control Messages [HK] I don't think a FE prefix is useful for any of these messages. Not sure why you keep asking for this ? There is no good technical reason that I can think of. Configuration Req/Resp (FE, LFB attributes) [Weiming]Still prefer '(FE) Configuration message' instead of 'configuration request message' as the name. Note that here the 'resp' is not always necessary. For the contents,it may also include config of LFB topology. [HK] Response is extremely important for this message. For e.g. Wouldn't you like to know if the routing table install by a CE was successful or not on the FE. This is a basic necessity. * Control Packet or Traffic Maintenance Messages CP Redirect to CE - This message will contain the packet to be redirected along with some control information such as the FE Port ID on which the FE arrived or the LFB ID on which it arrived. CP Forward to FE - This message also contains the packet along with control information such as the FE Port ID or LFB ID on which the packet is to be forwarded. [Weiming]Actually here I think we may only need to define one message the 'Packet Redirect msg', leaving addressing body (FEid CEid) to decide the direction. I don't think the FE port ID or LFB ID here will take effect for the FE to correctly get the packet to be redirected. This should highly rely on the LFB topology to decide where to induce the packets, e.g., from a classifier or a rate limiter (if used for DoS). I suppose that FE model should define a default datapath ID, via which packets enter and are encapusulated as a protocol message. The same is for packets redirected from CE to FE. [HK] Ok, I am thoroughly confused now. For some messages, you want CE/FE prefixes (2 messages), here you want a single message ?? ...Port ID or LFB ID is very important especially for Multicast forwarding & reception on the FE.=20 * Event Notification Messages Event Register/De-register Req/Resp - This allows the CE to register/de-register for FE events, LFB events, packets, etc. Asynchronous FE Event (including FE events such as DoS events, LFB events, etc) [Weiming]In my opinion, we truly do not need to use two specific msgs for event register/de-register. It can be easily done by 'Configuration' msg. no? [HK] Different semantics from Configuration, reg/de-reg is a clearer way to express this. * State Maintenance Messages or HA related messages PE Up/Down - These indicate the state of the FE or CE. PE Active/InActive - These are actually commands which can be used by the CE to Activate or Inactivate an FE (change its state). By activating an FE, I mean asking it to start forwarding packets. This is a useful during initial startup of protocol operations, to take the FE into steady state. These commands can also be very useful to handle HA scenarios when there are multiple FEs connected to the CE, some are active and some are standby (or inactive). Move PrimaryCE - This command is used to change the Primary CE for an FE. [Weiming]Firstly, I strongly suggest we devide it into FE and CE. They are so different. Then, I think we may only need two messages: FE maintenance msg (CE->FE) -including FE Shutown/Activate/Deactivate/... Note that for FE state Up/Down report, I'm with Jamal that they should be FE events. CE maintenance msg -including move operation To be hornest, I'm still not sure how the CE maintenance msg works, even not sure if it is a CE->FE action or FE->CE. Jamal, could you give more details on how such as Move action works? [/Weiming] [HK] Ok, let me think about this. Seems ok in the first read. [Weiming]I think here we may have missed something that are so important. How we manage the LFB state, that is, how we lunch(mount), activate/deactivate all the LFBs? Can they be included in the 'FE Config msg'? [HK] Yes, this will be part of the Config msg and the specifics for LFBs will be defined by the Model team. We don't need to be concerned with this level of detail, TBD...(Not sure if this is needed, may be Config Req/Resp can be used for this) * Management Object or SNMP support Messages MO Get/Set MO Response [Weiming]We have never had a discussion on how SNMP can be supported from the perspective of protocol. Can we have some on it? What I think is just a case where the SNMP MO and the SNMP agent are located separately in CE and FE. E.g., if an agent is in CE while the set MO is in FE, how then we deal with this if we do not have some protocol message support? A probable way is to define all MOs as FE attribute then to use Config msg to do it. But is is possible to let all MOs be FE attributes? [HK] Yes, I think having the Config message take care of this will be the best approach. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 06:15:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18048 for ; Thu, 29 Apr 2004 06:15:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Xm-0000CM-CN for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 06:13:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TADQhO000762 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 06:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8VZ-0007qO-Jp for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 06:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17660 for ; Thu, 29 Apr 2004 06:11: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 1BJ8VQ-0000vH-Rq for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 06:11:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ8UY-0000l2-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 06:10:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ8U2-0000aq-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 06:09:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Oe-0005jM-Bh; Thu, 29 Apr 2004 06:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ8Ju-0004pZ-Bj for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 05:59:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16999 for ; Thu, 29 Apr 2004 05:58:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ8Jl-0006YN-JT for forces-protocol@ietf.org; Thu, 29 Apr 2004 05:58:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ8Iz-0006OF-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 05:58:10 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJ8Hz-00066A-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 05:57:08 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 29 Apr 2004 18:09:26 +0800 Message-ID: <04b901c42dcf$d226e0e0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07ECE1EA0@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a 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 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 17:53:27 +0800 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 Hi Hormuzd, Thank you for your advice on the email length. Pls allow me to reply this email first. ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi Weiming, Here is the other part of your email. My previous email has already addressed most of your questions, see a few more replies below... -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Leave - This message can be used by an FE or CE to leave an association [Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields instead of 'FEid' and 'CEid' field in the header and let FEid and CEid universally defined, we then only need one message, or else, we may need 'FE leave' and 'CE leave', two msgs. [/Weiming] [HK] See Jamal's email on this, direction is good enough for this. The only time that we need Src, Dest ID is if we want to allow messages between Ces (CE-to-CE) messages in the future. [Weiming Re] I don't think so. You may know Jamal's approach is different from pure CEid and FEid in that, the Src ID field can either be CEid and FEid, just the same as IP address for IP protocol. * Capability Control Messages [HK] I don't think a FE prefix is useful for any of these messages. Not sure why you keep asking for this ? There is no good technical reason that I can think of. [Weiming Re] I don't quite like the way you use the word 'keep' here. I think you shoud be more open to different ideas if you like to first propose something for discussion. My idea is very clear, for pure single direction msgs, we'd better to mark the destination, why not? I can also say that there is no good technical reason not to mark the destination, to let customers to read the protocol text carefully then to understand the direction. It's just much more clearer, with little cost. Configuration Req/Resp (FE, LFB attributes) [Weiming]Still prefer '(FE) Configuration message' instead of 'configuration request message' as the name. Note that here the 'resp' is not always necessary. For the contents,it may also include config of LFB topology. [HK] Response is extremely important for this message. For e.g. Wouldn't you like to know if the routing table install by a CE was successful or not on the FE. This is a basic necessity. [Weiming Re] I'm just a little confused with the 'resp msg' and the 'ACK msg'. Do you mean we then do not need any ACK msg? I noticed in your previous email that you may hope FE model can define the command result. Could you take a example (e.g., add route ) to show what the FE model defined 'command result' look like? I think in mose cases, we only need to know the echo like 'successful', "unsuccessful', 'reason', 'error code', etc. All this can be included in a universal ACK msg. ( maybe we need to discuss the ACK msg format first). One more question is, can customers choose not to ask resp? If can, it becomes even more like ACK. If not, I think it may have burdened customers and system resources quite a lot when sometimes they don't actually need the 'resp' so as to fast the huge config tasks, e.g., to add hundreds of thousands of routes. In this case, we may ask only send back echoes when not successful. * Control Packet or Traffic Maintenance Messages CP Redirect to CE - This message will contain the packet to be redirected along with some control information such as the FE Port ID on which the FE arrived or the LFB ID on which it arrived. CP Forward to FE - This message also contains the packet along with control information such as the FE Port ID or LFB ID on which the packet is to be forwarded. [Weiming]Actually here I think we may only need to define one message the 'Packet Redirect msg', leaving addressing body (FEid CEid) to decide the direction. I don't think the FE port ID or LFB ID here will take effect for the FE to correctly get the packet to be redirected. This should highly rely on the LFB topology to decide where to induce the packets, e.g., from a classifier or a rate limiter (if used for DoS). I suppose that FE model should define a default datapath ID, via which packets enter and are encapusulated as a protocol message. The same is for packets redirected from CE to FE. [HK] Ok, I am thoroughly confused now. For some messages, you want CE/FE prefixes (2 messages), here you want a single message ?? ... [Weiming Re] I'm not sure if you are truly confused or not. Let me just keep saying it again, for the msgs that can be used in single direction, we should mark it. For the msgs like packet redirect msg, I dont see any difference for CE->FE and FE->CE, why we should mark it. I have to say you are just unnecessarily using CE/FE prefix here. Actually the confusion is from your side to me, why should you use the CE/FE prefix in the unnecessary place while against using them when they are actually needed? Pls don't let me have a feeling that it is because FACT does like this. Port ID or LFB ID is very important especially for Multicast forwarding & reception on the FE. [Weiming Re] Could you give more details on how these PortID and LFBID are used? What does Port ID here mean? I just can not see every thing here. * Event Notification Messages Event Register/De-register Req/Resp - This allows the CE to register/de-register for FE events, LFB events, packets, etc. Asynchronous FE Event (including FE events such as DoS events, LFB events, etc) [Weiming]In my opinion, we truly do not need to use two specific msgs for event register/de-register. It can be easily done by 'Configuration' msg. no? [HK] Different semantics from Configuration, reg/de-reg is a clearer way to express this. [Weiming Re] I suppose you also ask a clearer description here. But just the cost for the 'clearer' here is too much. Pls also don't let me have a feeling that it is because FACT does like this. * State Maintenance Messages or HA related messages PE Up/Down - These indicate the state of the FE or CE. PE Active/InActive - These are actually commands which can be used by the CE to Activate or Inactivate an FE (change its state). By activating an FE, I mean asking it to start forwarding packets. This is a useful during initial startup of protocol operations, to take the FE into steady state. These commands can also be very useful to handle HA scenarios when there are multiple FEs connected to the CE, some are active and some are standby (or inactive). Move PrimaryCE - This command is used to change the Primary CE for an FE. [Weiming]Firstly, I strongly suggest we devide it into FE and CE. They are so different. Then, I think we may only need two messages: FE maintenance msg (CE->FE) -including FE Shutown/Activate/Deactivate/... Note that for FE state Up/Down report, I'm with Jamal that they should be FE events. CE maintenance msg -including move operation To be hornest, I'm still not sure how the CE maintenance msg works, even not sure if it is a CE->FE action or FE->CE. Jamal, could you give more details on how such as Move action works? [/Weiming] [HK] Ok, let me think about this. Seems ok in the first read. [Weiming]I think here we may have missed something that are so important. How we manage the LFB state, that is, how we lunch(mount), activate/deactivate all the LFBs? Can they be included in the 'FE Config msg'? [HK] Yes, this will be part of the Config msg and the specifics for LFBs will be defined by the Model team. We don't need to be concerned with this level of detail, [Weiming RE] Not completely agree. At least the protocol level should be responsible to manange LFB instances. TBD...(Not sure if this is needed, may be Config Req/Resp can be used for this) * Management Object or SNMP support Messages MO Get/Set MO Response [Weiming]We have never had a discussion on how SNMP can be supported from the perspective of protocol. Can we have some on it? What I think is just a case where the SNMP MO and the SNMP agent are located separately in CE and FE. E.g., if an agent is in CE while the set MO is in FE, how then we deal with this if we do not have some protocol message support? A probable way is to define all MOs as FE attribute then to use Config msg to do it. But is is possible to let all MOs be FE attributes? [HK] Yes, I think having the Config message take care of this will be the best approach. [Weiming Re] Then, we need to define an FE attribute for MO operation? I'm thinking it further to see the possibility. Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 09:03:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27977 for ; Thu, 29 Apr 2004 09:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAig-0004p5-Tm for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 08:32:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TCWodU018535 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 08:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAdy-0003U8-PC for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 08:27:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24278 for ; Thu, 29 Apr 2004 08:27:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAdo-0004kD-Pm for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 08:27:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAbt-0004A5-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 08:25:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJAac-0003pJ-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 08:24:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJART-0000rV-Qe; Thu, 29 Apr 2004 08:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJALp-0007zE-IB for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 08:09:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23236 for ; Thu, 29 Apr 2004 08:09: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 1BJALf-0000c2-Kg for forces-protocol@ietf.org; Thu, 29 Apr 2004 08:09:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAKh-0000PE-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 08:08:04 -0400 Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx with esmtp (Exim 4.12) id 1BJAJi-0000Bl-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 08:07:02 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004042905105519:517 ; Thu, 29 Apr 2004 05:10:55 -0700 Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org In-Reply-To: <03fc01c42daa$1b6b65d0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EC7A45A@orsmsx408.jf.intel.com> <038301c42d25$6bc1cf40$845c21d2@Necom.hzic.edu.cn> <1083209759.1051.50.camel@jzny.localdomain> <03fc01c42daa$1b6b65d0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1083240420.1050.119.camel@jzny.localdomain> 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 04/29/2004 05:10:55 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/29/2004 05:10:59 AM, Serialize complete at 04/29/2004 05:10:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 Apr 2004 08:07:00 -0400 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 Content-Transfer-Encoding: 7bit Hi Weiming, On Thu, 2004-04-29 at 01:23, Wang,Weiming wrote: > > To take from netlink2 experience: The important piece is the end > > processor of the "command". > > If direction is CE->FE thats a config. If direction is FE->CE typically > > CE would intepret that to be an event. > > > [Wweiming]I think this approach (we may also call it implicit approach) may be > quite different from that Hormuzd proposed. Could you try to list more msgs > based on this idea to ease our discussion? I think it is also a feasible > approach. My idea was actually moer based on Hormuzd's proposal, that is, the > config msg is only allowed from CE->FE. In this case, I think to mark the > direction that is to mark as 'FE config' is necessary. > Because the following discussion is more related to this base, therefore I also > just stop here to let us decide this first. Hormuzd, could you have some of your > idea? Thank you. Lets assume a node (CE or FE) receives a message destined to its ID; such a node will have to intepret and may execute the message - its like opening a letter with your name(ID) on the envelope. The execution could be noop such as silently discarding it or returning "please reset your brain" (as in the case of TCP RST) in a response. Defining the name of the address to be FEid or CEid doesnt add any value. Defining the execution of a message when it is received by FE or CE is valuable. And i think this is done in the protcol description text. If you want to go through all the possibilities of the treatment of such a message then lets take a simple example of of what most of the configs will be: "update table X (for LFB Y) with config Z". Essentially all config messages are really state updates from CE to FE. 1)lets take any config message going from CE->FE; a) received by a FE which is capable of using it: it will be interpretted and used to configure something. Response of execution result (maybe a simple ACK) may be sent back to CE b) received by a FE NOT capable of interpretting it - noop will happen on the FE; maybe a NACK or reset sent back. The hope is we dont have too many of #1b above. Even if we did this is a problem that affects any protocol today. Lets take the case of FE->CE in which case CE is receiving the same or similar message 2a) It could be used as a subset (not full set) of Event Notification Messages. This is what netlink2 did. i.e instead of viewing it the way FE did as a command, you view it as something that has already happened. A message of "update table X (for LFB Y) with config Z" as in #1a has a different interpretation at the CE. CE now sees the same message as "table X (on LFB Y) was updated with config X". 2b) You could choose to ignore the message from CE unless it has a speacial tag to it. Hormuzd refers to it as Event Notification Messages; i am indiferent and would like to wait until i see his posting of the Event notification message. So summary of above: - we dont need to have FEid/CEid - srcID and dstID are sufficient. In otherwords there are no ambiguities that need to be resolved. - #2a and #2b are not very different - the message is the same only difference is in what color of envelope(header) you use to deliver the Event Notification Messages; cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 15:52:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24560 for ; Thu, 29 Apr 2004 15:52:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHRn-0002XV-LI for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 15:43:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJhpXF009761 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 15:43:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHD2-0006li-L3 for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:28:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22790 for ; Thu, 29 Apr 2004 15:28: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 1BJHCv-0004hl-RR for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 15:28:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHC0-0004bp-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 15:27:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHB4-0004Vs-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 15:26:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH6R-0004X8-4S; Thu, 29 Apr 2004 15:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGk5-0004tY-Ic for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 14:58:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19687 for ; Thu, 29 Apr 2004 14:58:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGjz-0002l7-A2 for forces-protocol@ietf.org; Thu, 29 Apr 2004 14:58:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGjE-0002hq-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 14:57:49 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJGia-0002OW-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 14:57:08 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3TIv0fW030036; Thu, 29 Apr 2004 18:57:00 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 i3TIqm36000611; Thu, 29 Apr 2004 18:55:05 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 M2004042911563527768 ; Thu, 29 Apr 2004 11:56:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 11:56:36 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ECE2436@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQt5O+NJbUWGXolRCGWige1ErYjKAANVaHg From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 29 Apr 2004 18:56:36.0202 (UTC) FILETIME=[B234DCA0:01C42E1B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 11:56:35 -0700 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 Content-Transfer-Encoding: quoted-printable Jamal, I agree with your comments below. I hope this helps clarify Weiming's doubts. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > > To take from netlink2 experience: The important piece is the end > > processor of the "command". > > If direction is CE->FE thats a config. If direction is FE->CE typically > > CE would intepret that to be an event. > > > [Wweiming]I think this approach (we may also call it implicit approach) may be > quite different from that Hormuzd proposed. Could you try to list more msgs > based on this idea to ease our discussion? I think it is also a feasible > approach. My idea was actually moer based on Hormuzd's proposal, that is, the > config msg is only allowed from CE->FE. In this case, I think to mark the > direction that is to mark as 'FE config' is necessary. > Because the following discussion is more related to this base, therefore I also > just stop here to let us decide this first. Hormuzd, could you have some of your > idea? Thank you. Lets assume a node (CE or FE) receives a message destined to its ID; such a node will have to intepret and may execute the message - its like opening a letter with your name(ID) on the envelope. =20 The execution could be noop such as silently discarding it or returning=20 "please reset your brain" (as in the case of TCP RST) in a response.=20 Defining the name of the address to be FEid or CEid doesnt add any value. Defining the execution of a message when it is received by FE or CE is valuable. And i think this is done in the protcol description text. [HK] Exactly, this is the same point that I am making to Weiming. Lets take the case of FE->CE in which case CE is receiving the same or similar message 2a) It could be used as a subset (not full set) of Event Notification Messages. This is what netlink2 did. i.e instead of viewing it the way FE did as a command, you view it as something that has already happened. A message of "update table X (for LFB Y) with config Z" as in #1a has a different interpretation at the CE. CE now sees the same message as "table X (on LFB Y) was updated with config X". =20 2b) You could choose to ignore the message from CE unless it has a speacial tag to it. Hormuzd refers to it as Event Notification Messages; i am indiferent and would like to wait until i see his posting of the Event notification message. [HK] I would like to do this soon as well, but I am spending too many cycles on clarifying doubts right now. So summary of above: - we dont need to have FEid/CEid - srcID and dstID are sufficient. In otherwords there are no ambiguities that need to be resolved. - #2a and #2b are not very different - the message is the same only difference is in what color of envelope(header) you use to deliver the Event Notification Messages;=20 [HK] I completely agree on this. I hope this clarifies Weiming's doubts. Thanks, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 17:18:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02566 for ; Thu, 29 Apr 2004 17:18:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJInk-0003EG-Sx for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 17:10:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLAaEa012407 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 17:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIZ7-0003C7-6v for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 16:55:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00126 for ; Thu, 29 Apr 2004 16:55: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 1BJIZ0-0004ZQ-1A for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:55:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIXM-0004HB-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:53:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJIVx-00043W-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:52:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJIK3-0000To-Pf for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:39:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHhY-00070N-2t; Thu, 29 Apr 2004 16:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHYB-0004V5-Q7 for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 15:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24443 for ; Thu, 29 Apr 2004 15:50:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHY4-0006CS-Vd for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:50:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHXH-0006AQ-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:49:32 -0400 Received: from fmr99.intel.com ([192.55.52.32] helo=hermes-pilot.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJHWh-00064k-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:48:55 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.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 i3TJmngM003229; Thu, 29 Apr 2004 19:48:49 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3TJjgMI022531; Thu, 29 Apr 2004 19:48:39 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 M2004042912482519091 ; Thu, 29 Apr 2004 12:48:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 12:48:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ED4E20A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQt0g98eBFVfSPKTpS/JJXSzG8uuQARlLvA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , Cc: , , X-OriginalArrivalTime: 29 Apr 2004 19:48:25.0641 (UTC) FILETIME=[EF939990:01C42E22] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 12:48:25 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, At this point, I would like to hear from Avri, Ram, others on what they think. Jamal has provided a lot of good clarification and I think Jamal and myself are on the same page. I am confused about your arguments, since there doesn't seem to be a clear design philosophy. On one hand you would like to see more messages with CE/FE prefix for Join, Leave, etc. On the other hand, you want to see less messages, e.g. remove Reg/de-reg ?? Not sure what the motivation is here, it doesn't make sense to me atleast. Another thing which is not helpful, is to keep going back and trying to compare GRMP, FACT, Netlink-2. We should talk about our experiences, but if we keep going back to specifics in these drafts it will be difficult to achieve our goal of defining a common protocol as soon as we would like. We will always be biased by what we did, and it makes things more difficult. Note I am Not trying to accuse you here, but this has been my observation. I am still hopeful, like Jamal, that we can have an early interop by end of this year. Hope we share this goal. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Leave - This message can be used by an FE or CE to leave an association [Weiming] As mentioned above, If we decide to use 'Src.ID' and 'Dest.ID' fields instead of 'FEid' and 'CEid' field in the header and let FEid and CEid universally defined, we then only need one message, or else, we may need 'FE leave' and 'CE leave', two msgs. [/Weiming] [HK] See Jamal's email on this, direction is good enough for this. The only time that we need Src, Dest ID is if we want to allow messages between Ces (CE-to-CE) messages in the future. [Weiming Re] I don't think so. You may know Jamal's approach is different from pure CEid and FEid in that, the Src ID field can either be CEid and FEid, just the same as IP address for IP protocol. [HK] Yes, and I am fine with that...Pls see my emails. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu Apr 29 17:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02665 for ; Thu, 29 Apr 2004 17:19:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIrW-0005Oj-HI for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 17:14:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLEUAO020744 for forces-protocol-archive@odin.ietf.org; Thu, 29 Apr 2004 17:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIdD-0005MO-Fg for forces-protocol-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 16:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00982 for ; Thu, 29 Apr 2004 16:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJId6-0005F8-8K for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:59:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIc0-00054r-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:58:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJIau-0004u2-00 for forces-protocol-web-archive@ietf.org; Thu, 29 Apr 2004 16:57:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHqA-0001Mt-Np; Thu, 29 Apr 2004 16:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHc3-0005KX-90 for forces-protocol@optimus.ietf.org; Thu, 29 Apr 2004 15:54:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24635 for ; Thu, 29 Apr 2004 15:54:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHbw-0006Kr-Ja for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:54:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHay-0006IK-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:53:21 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJHaG-0006EY-00 for forces-protocol@ietf.org; Thu, 29 Apr 2004 15:52:36 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.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 i3TJqB1Y028922; Thu, 29 Apr 2004 19:52:12 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.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 i3TJpKL2027760; Thu, 29 Apr 2004 19:52:15 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 M2004042912515919641 ; Thu, 29 Apr 2004 12:51:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 12:51:59 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 2:: HA Message-ID: <468F3FDA28AA87429AD807992E22D07ED4E213@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 2:: HA Thread-Index: AcQtsgwQSmhlsCJZTB2RQMXkv1BUKwAcUqow From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 29 Apr 2004 19:51:59.0580 (UTC) FILETIME=[6F1819C0:01C42E23] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Apr 2004 12:51:59 -0700 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 Content-Transfer-Encoding: quoted-printable Weiming, Thanks for this clarification. This helps us move forward on this issue. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Wednesday, April 28, 2004 10:54 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 2:: HA Hi Avri, Rob, Hormuzd, I actually quite agree to retain the ability at the PL for FE able to Broad/Mulitcast to CEs regarding its events, ability change, etc, and also quite agree with Avri's idea below. What I propose is just we may be careful when we recommend a CE failover (HA) scheme to customers. We should not let customers have a feeling that such B/M ability can solve HA very well. Customers should more rely on their CE-CE implementation for this purpose, with the B/M ability as only some asistance, therefore 'may assist fast CE failover recovery' may be the appropriate description. Cheers, Weiming ----- Original Message ----- From: To: Sent: Thursday, April 29, 2004 1:48 AM Subject: Re: [Forces-protocol] topic 2:: HA > Hi, > > Yes, as long as the capability exists in the protocol, I don't mind if > someone can turn it off. I would argue, though, that having a FE > notify its primary CE (or the CE group) of any new CE association (or > loss of association) would be useful even if there is a CE-CE link - > just as a safety check. And obviously if everything is going well with > CE coordination, then the CE probably will not need to request a state > dump from the FE, but of course should be able to. > > I also think that the ability to stifle event messages, by type > including CE association announcements, is probably a general > capability which is needed in any case. > > a. > > On 28 apr 2004, at 12.35, Khosravi, Hormuzd M wrote: > > > [HK] I agree, we can have a compromise to keep both these schemes, i.e. > > FE may send events, packets to all CEs or just primary CE as > > configurable. This can be a behavior which is configurable by the CE. > > Is > > this acceptable to Avri, Weiming, others ? > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 30 13:36:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17434 for ; Fri, 30 Apr 2004 13:36:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbnl-00016G-4Z for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 13:27:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHRrX6004229 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 13:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbiV-0008Vv-9V for forces-protocol-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:22:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16020 for ; Fri, 30 Apr 2004 13:22:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbiT-0002Ic-B7 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 13:22:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbhc-0002D7-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 13:21:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbgi-000283-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 13:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbXW-0006fh-5A; Fri, 30 Apr 2004 13:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbPy-0004vh-1a for forces-protocol@optimus.ietf.org; Fri, 30 Apr 2004 13:03:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14863 for ; Fri, 30 Apr 2004 13:03:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbPw-0000sf-6h for forces-protocol@ietf.org; Fri, 30 Apr 2004 13:03:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbP5-0000od-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 13:02:23 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJbOD-0000eB-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 13:01:33 -0400 Received: from wwm1 (unverified [219.82.186.101]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 1 May 2004 01:13:30 +0800 Message-ID: <004a01c42ed4$2df9b320$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07ED4E20A@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 May 2004 00:57:09 +0800 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 Hi Hormuzd, Ok, then, following compromise scheme may be acceptable to me, and should let it as our initials and open for changes if we enconter some difficulty when we actually begin writing the text: 1. Syncronization msg - for FE join, Leave, CE join, leave 2. Query / Query resp msg - include to query the capability 3. Config / Config resp msg 4. State Maintenance msg 5. Event Notification msg 6. Redirect msg We do not need to categorize them. Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 30 14:45:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21677 for ; Fri, 30 Apr 2004 14:45:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcyc-0004s8-98 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 14:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UIhAv7018724 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 14:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJcp2-0003IT-IF for forces-protocol-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 14:33:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20950 for ; Fri, 30 Apr 2004 14:33:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJcoz-0000Jt-VR for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 14:33:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJco9-0000Fn-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 14:32:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJcnY-0000BT-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 14:31:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJceN-00016S-Vl; Fri, 30 Apr 2004 14:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJccP-0000Tt-48 for forces-protocol@optimus.ietf.org; Fri, 30 Apr 2004 14:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19745 for ; Fri, 30 Apr 2004 14:20: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 1BJccM-0006ki-Eq for forces-protocol@ietf.org; Fri, 30 Apr 2004 14:20:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJcbS-0006hY-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 14:19:15 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJcb3-0006eU-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 14:18:49 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3UIIiBh022206; Fri, 30 Apr 2004 18:18:44 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 i3UIGhTl014416; Fri, 30 Apr 2004 18:16:43 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004043011181316668 ; Fri, 30 Apr 2004 11:18:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 11:18:13 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ED4EB94@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQu13pyG9hN34TgQ9yUhtzPMx+30gAB5ysw From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 30 Apr 2004 18:18:13.0824 (UTC) FILETIME=[804B9C00:01C42EDF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 11:18:12 -0700 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 Content-Transfer-Encoding: quoted-printable Hi Weiming, Thanks for this list! I am mostly fine with it except a few things.. I think we need Event Reg/De-reg messages, these are very different semantically from Config. Also, just a Join msg, instead of FE,CE Join if we use Src/Dst ID in the header. That's all. Thanks again, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Sent: Friday, April 30, 2004 9:57 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a Hi Hormuzd, Ok, then, following compromise scheme may be acceptable to me, and should let it as our initials and open for changes if we enconter some difficulty when we actually begin writing the text: 1. Syncronization msg - for FE join, Leave, CE join, leave 2. Query / Query resp msg - include to query the capability 3. Config / Config resp msg 4. State Maintenance msg 5. Event Notification msg 6. Redirect msg We do not need to categorize them. Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 30 16:59:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02697 for ; Fri, 30 Apr 2004 16:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeAK-0003d5-6z for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 15:59:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UJxKoe013951 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 15:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJe4l-0002fT-Qa for forces-protocol-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 15:53:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27020 for ; Fri, 30 Apr 2004 15:53: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 1BJe4k-0007Kk-Dk for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 15:53:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJe3m-0007Ec-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 15:52:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJe36-00077j-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 15:51:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdpl-0005Bp-2l; Fri, 30 Apr 2004 15:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJdkF-0003cF-K9 for forces-protocol@optimus.ietf.org; Fri, 30 Apr 2004 15:32:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25130 for ; Fri, 30 Apr 2004 15:32: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 1BJdkE-00053y-4q for forces-protocol@ietf.org; Fri, 30 Apr 2004 15:32:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJdjP-0004yz-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 15:31:32 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BJdin-0004tk-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 15:30:54 -0400 Received: from wwm1 (unverified [219.82.184.218]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 1 May 2004 03:43:25 +0800 Message-ID: <004601c42ee9$1f8b0a40$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07ED4EB94@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 May 2004 03:27:05 +0800 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 Hormuzd, Some clarifications so as to answer your two questions: 1. Event reg/de-reg can be very easily implemented by either following two means: a. using config msg as I mentioned. Actually I can not see any difference of it from general config. b. by event msg itself. That is, event msg include the event report and event register, a flag (or a context) can easily notarize it. (Actually I more like the word 'subscribe/unsubscribe' here, but let's leave it for msg writers to choose) 2. I suppose Syn msg is one msg, with the flag in the msg body (or TLV) to notarize if it's Join or leave, and as you mentioned using Src/Dst ID (even by context, as Jamal mentioned) to notarize that of CE or FE (There is no any specific join msg then). Want Jamal to verify it. It's 3am now, and I'm afraid need to go to bed, therefore have to hope others help you to finally decide it then. I know today is the deadline. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi Weiming, Thanks for this list! I am mostly fine with it except a few things.. I think we need Event Reg/De-reg messages, these are very different semantically from Config. Also, just a Join msg, instead of FE,CE Join if we use Src/Dst ID in the header. That's all. Thanks again, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Sent: Friday, April 30, 2004 9:57 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a Hi Hormuzd, Ok, then, following compromise scheme may be acceptable to me, and should let it as our initials and open for changes if we enconter some difficulty when we actually begin writing the text: 1. Syncronization msg - for FE join, Leave, CE join, leave 2. Query / Query resp msg - include to query the capability 3. Config / Config resp msg 4. State Maintenance msg 5. Event Notification msg 6. Redirect msg We do not need to categorize them. Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 30 17:43:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06340 for ; Fri, 30 Apr 2004 17:43:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJffJ-0007nj-BP for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 17:35:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULZPZf029985 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 17:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfVl-0004PS-CX for forces-protocol-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:25:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04858 for ; Fri, 30 Apr 2004 17:25: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 1BJfVj-0003xQ-0d for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 17:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfUv-0003pr-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 17:24:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfTq-0003i6-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 17:23:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfHp-0007WN-2k; Fri, 30 Apr 2004 17:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeek-0001wx-OZ for forces-protocol@optimus.ietf.org; Fri, 30 Apr 2004 16:30:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28842 for ; Fri, 30 Apr 2004 16:30:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeei-0002zZ-O4 for forces-protocol@ietf.org; Fri, 30 Apr 2004 16:30:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJedp-0002oz-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 16:29:50 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJecl-0002Zo-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 16:28:43 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr004.fm.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 i3UKSQVj027889; Fri, 30 Apr 2004 20:28:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.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 i3UKSChS013832; Fri, 30 Apr 2004 20:28: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 M2004043013280907852 ; Fri, 30 Apr 2004 13:28:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 13:28:09 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ED4ECEB@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQu13pyG9hN34TgQ9yUhtzPMx+30gAB5yswAASeO2A= From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 30 Apr 2004 20:28:09.0542 (UTC) FILETIME=[A6E7C660:01C42EF1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 13:28:09 -0700 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 Content-Transfer-Encoding: quoted-printable BTW, we need a Join Resp as well. Sorry I forgot to mention this before. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Friday, April 30, 2004 11:18 AM To: Weiming Wang; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Hi Weiming, Thanks for this list! I am mostly fine with it except a few things.. I think we need Event Reg/De-reg messages, these are very different semantically from Config. Also, just a Join msg, instead of FE,CE Join if we use Src/Dst ID in the header. That's all. Thanks again, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Sent: Friday, April 30, 2004 9:57 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a Hi Hormuzd, Ok, then, following compromise scheme may be acceptable to me, and should let it as our initials and open for changes if we enconter some difficulty when we actually begin writing the text: 1. Syncronization msg - for FE join, Leave, CE join, leave 2. Query / Query resp msg - include to query the capability 3. Config / Config resp msg 4. State Maintenance msg 5. Event Notification msg 6. Redirect msg We do not need to categorize them. Best regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri Apr 30 22:29:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20459 for ; Fri, 30 Apr 2004 22:29:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJkEM-0003Yr-4t for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 22:27:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i412Rsc2013690 for forces-protocol-archive@odin.ietf.org; Fri, 30 Apr 2004 22:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJkC3-0003IM-Nu for forces-protocol-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 22:25:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20330 for ; Fri, 30 Apr 2004 22:25:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJkC0-0003SK-GU for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 22:25:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJkB5-0003Mn-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 22:24:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJkAL-0003H9-00 for forces-protocol-web-archive@ietf.org; Fri, 30 Apr 2004 22:23:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJk8e-0002nQ-W7; Fri, 30 Apr 2004 22:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJk7B-0002S8-Bf for forces-protocol@optimus.ietf.org; Fri, 30 Apr 2004 22:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20091 for ; Fri, 30 Apr 2004 22:20:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJk78-0002uc-1W for forces-protocol@ietf.org; Fri, 30 Apr 2004 22:20:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJk6A-0002lL-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 22:19:27 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BJk5I-0002XX-00 for forces-protocol@ietf.org; Fri, 30 Apr 2004 22:18:32 -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 i412IFKP025556 for ; Sat, 1 May 2004 02:18:15 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 i412IFg2029413 for ; Sat, 1 May 2004 02:18:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004043019180222740 for ; Fri, 30 Apr 2004 19:18:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Apr 2004 19:18:02 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42F22.8753208E" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07ED4F053@orsmsx408.jf.intel.com> Thread-Topic: topic 4c: Common Header Thread-Index: AcQvIocFf9rLAiSmT46go9WhuIA/ug== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 01 May 2004 02:18:02.0077 (UTC) FILETIME=[876E68D0:01C42F22] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] topic 4c: Common Header Sender: forces-protocol-admin@ietf.org Errors-To: forces-protocol-admin@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: forces-protocol List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Apr 2004 19:18:01 -0700 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_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42F22.8753208E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a summary of our discussion so far on the common header... The fields in the common header that there was consensus around are as follows, IDs: CE ID, FE ID (Used to address a single, group or all CEs/FEs respectively) Length: 16-32 bits...TBD Version/sub-ver: 4 bits Sequence No. : 32 bits Length : 16 bits Command Type : 8 bits (semantics - TBD) Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length of Flags and Priority fields is TBD) LFB TypeID: TBD, no consensus on whether it is needed or not in the header ------------------ Based on our latest discussion, I think we have decided to use Src ID, Dst ID fields in the common header instead of CEID, FEID, where a SrcID can be either CEID or FEID, same for Dst ID. The only other outstanding issue remaining is LFB Type ID. Could team members pls post their thoughts on this ?? =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C42F22.8753208E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Here = is a summary of=20 our discussion so far on the common header...
The fields in=20 the common header that there was consensus around are as=20 follows,

IDs: CE ID, FE ID (Used to address a single, group or all = CEs/FEs=20 respectively)

Length: 16-32=20 bits...TBD

Version/sub-ver: 4 = bits

Sequence No. : 32 bits

Length : 16 bits

Command Type : 8 bits (semantics - = TBD)

Flags: 16 bits, including 1-3 bits for = Priority. (The=20 semantics/length of Flags and = Priority=20 fields is TBD)

LFB TypeID: TBD, no consensus on whether = it is needed=20 or not in the=20 header

------------------
Based = on our latest=20 discussion, I think we have decided to use Src ID, Dst ID fields in the = common=20 header instead of CEID, FEID, where a SrcID can be either CEID or FEID, = same for=20 Dst ID.
The = only other=20 outstanding issue remaining is LFB Type ID. Could team members pls post = their=20 thoughts on this ??
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C42F22.8753208E-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol