From exim@www1.ietf.org Sun May 2 11:37:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18795 for ; Sun, 2 May 2004 11:37: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 1BKIzI-0006QG-Lg for forces-protocol-archive@odin.ietf.org; Sun, 02 May 2004 11:34:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42FYeGc024688 for forces-protocol-archive@odin.ietf.org; Sun, 2 May 2004 11:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKIxe-0005bW-DR for forces-protocol-web-archive@optimus.ietf.org; Sun, 02 May 2004 11:32: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 LAA18579 for ; Sun, 2 May 2004 11:32: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 1BKIxd-0001k2-GG for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 11:32:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKIwe-0001SV-00 for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 11:31:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKIvb-00014R-00 for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 11:30:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKIpw-0003eF-UU; Sun, 02 May 2004 11: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 1BKIp2-0003M3-7m for forces-protocol@optimus.ietf.org; Sun, 02 May 2004 11:24: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 LAA18336 for ; Sun, 2 May 2004 11:24: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 1BKIp1-0007PN-9r for forces-protocol@ietf.org; Sun, 02 May 2004 11:24:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKIo4-0007Am-00 for forces-protocol@ietf.org; Sun, 02 May 2004 11:23: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 1BKInk-0006wH-00 for forces-protocol@ietf.org; Sun, 02 May 2004 11:22:45 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050208263241:3849 ; Sun, 2 May 2004 08:26:32 -0700 Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org, Hormuzd M In-Reply-To: <004601c42ee9$1f8b0a40$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07ED4EB94@orsmsx408.jf.intel.com> <004601c42ee9$1f8b0a40$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1083511359.1676.81.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 05/02/2004 08:26:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2004 08:26:36 AM, Serialize complete at 05/02/2004 08:26: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: 02 May 2004 11:22: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-30 at 15:27, Weiming Wang wrote: > 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) > I agree it is not much different from a config called eitehr event register or subscribe - we can call it subscribe because it is more general and have a flag differentiating between unsubscribe and subscribe - perhaps with TLVs for a list of events of interest. > 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. probably same context as subscribe above. A command maybe called synchronize with a flag to distinguish diffrent things. We need to show a state machine for a FE joining/leaving. Also i mentioned an idea we implemented which was to allow the CE to send a broadcast SYN messages to reset the FEs. Even if we dont do it this way, i think we need to have forced restarts. > 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. Sorry, i was away but i should be able to respond faster now. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 2 12:18: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 MAA20889 for ; Sun, 2 May 2004 12:18: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 1BKJeK-00051x-KK for forces-protocol-archive@odin.ietf.org; Sun, 02 May 2004 12:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42GH4pG019332 for forces-protocol-archive@odin.ietf.org; Sun, 2 May 2004 12: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 1BKJaj-0002r9-4b for forces-protocol-web-archive@optimus.ietf.org; Sun, 02 May 2004 12:13: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 MAA20640 for ; Sun, 2 May 2004 12:13: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 1BKJah-0004Rc-Pi for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 12:13:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKJZe-0004B4-00 for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 12:12:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKJZ7-0003uk-00 for forces-protocol-web-archive@ietf.org; Sun, 02 May 2004 12:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKJRh-0007M3-Nm; Sun, 02 May 2004 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKJNv-0006Eo-Ee for forces-protocol@optimus.ietf.org; Sun, 02 May 2004 12:00: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 MAA19872 for ; Sun, 2 May 2004 12:00: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 1BKJNu-0000xN-2n for forces-protocol@ietf.org; Sun, 02 May 2004 12:00:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKJN7-0000hm-00 for forces-protocol@ietf.org; Sun, 02 May 2004 11:59:18 -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 1BKJMW-0000Re-00 for forces-protocol@ietf.org; Sun, 02 May 2004 11:58:40 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050209022967:3864 ; Sun, 2 May 2004 09:02:29 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07ED4F053@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07ED4F053@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083513517.1683.114.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 05/02/2004 09:02:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/02/2004 09:02:31 AM, Serialize complete at 05/02/2004 09:02:31 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: 02 May 2004 11:58: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BTW, there are a few things we seem to be skipping over - all of which are important to the header: - Transactions, definition and scope - Atomicity of transactions - batching of messages (maybe transactions) and this last one i am not one 100% sure, but do we need to have windowing as well for pipelining? or is batching sufficient? In other words can we have only a single transaction active at a time or can we have more running in parallel. Responses to your email below: On Fri, 2004-04-30 at 22:18, Khosravi, Hormuzd M wrote: > 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 Once we answer the question on transactions, this could have slightly different semantics. > Length : 16 bits > > Command Type : 8 bits (semantics - TBD) I am still trying to recover from my zone of last week; the commands will be limited to those 6 or so you posted earlier? > 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 I think you somehow need to be able to inspect the message and say clearly who (FE/CE) and what (LFBID) that the message is directed at. If not for any other reason, this is useful for debugging in the field. I would like to be able to run a tcpdump session in a box where all forces messages are mirrored to and debug a race condition for example. My view would be to have this field to have may be one bit to represent direction and the rest of the bits to represent they type of LFB being targetted (set to zero or all 1s if message is not LFB specific) > > ------------------ > 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 ?? I think we may have overlooked the other requirements like atomicity; better catch them now. I will share the netlink2 experience maybe we can borrow something from it: Batching: 1) We had a flag which indicates "more messages for this transaction are on their way" 2) We had a command (not flag) which said "all messages are done for this transaction" A batch will start with one or more of #1 and end with #2. Atomicity: We had a speacial flag which indicated that a transaction or parts of it are atomic. The sequence number in our case was a strictly per message value. A more interesting approach would be to break it into a transaction:msg sequence. We also had a window of 1. i.e at any point theres only one transaction outstanding. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 00:16:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20939 for ; Mon, 3 May 2004 00:16: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 1BKUqZ-0001Ss-0F for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 00:14:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i434EQQj005626 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 00:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKUlq-0007bY-DO for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 00:09: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 AAA20720 for ; Mon, 3 May 2004 00: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 1BKUlo-0007K1-2F for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:09:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKUir-0006oQ-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:06:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKUfh-0006Mm-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:03:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKUeW-0005ND-59; Mon, 03 May 2004 00:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKUZz-0003pv-ON for forces-protocol@optimus.ietf.org; Sun, 02 May 2004 23: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 XAA20241 for ; Sun, 2 May 2004 23:57: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 1BKUZx-0005Nc-D8 for forces-protocol@ietf.org; Sun, 02 May 2004 23:57:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKUWu-0004rW-00 for forces-protocol@ietf.org; Sun, 02 May 2004 23:54: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 1BKUTQ-00049C-00 for forces-protocol@ietf.org; Sun, 02 May 2004 23:50:32 -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 i433oDZd000890; Mon, 3 May 2004 03:50: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 i433m9FB000995; Mon, 3 May 2004 03:48:14 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 M2004050220495731086 ; Sun, 02 May 2004 20:49: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); Sun, 2 May 2004 20:49: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] Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07ED4F147@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQwWVXK/1V3b3YJT9yDzFQotor8BAAZorxg From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 03 May 2004 03:49:57.0250 (UTC) FILETIME=[B38E8620:01C430C1] 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, 2 May 2004 20:49: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.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 response, see my comments below.. -----Original Message----- > Some clarifications so as to answer your two questions: >=20 > 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) >=20 I agree it is not much different from a config called eitehr event register or subscribe - we can call it subscribe because it is more general and have a flag differentiating between unsubscribe and subscribe - perhaps with TLVs for a list of events of interest. [HK] I am fine with this approach. I like the terminology subscribe/unsubscribe better than what I was proposing (register/de-register). > 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. probably same context as subscribe above. A command maybe called synchronize with a flag to distinguish diffrent things. We need to show a state machine for a FE joining/leaving. [HK] I don't like the term SYN or synchronize, since it is used by TCP. May be we can use names like "Association Setup/teardown" or "Bind/Unbind" which are more ForCES specific ? Let me know which one you like. Also, I am fine with having a single message such as Association with a flag to indicate whether it is setup or teardown, although I think it would be cleaner to have them as separate messages. Also i mentioned an idea we implemented which was to allow the CE to send a broadcast SYN messages to reset the FEs. Even if we dont do it this way, i think we need to have forced restarts. [HK] Yes, I agree we need to have forced restarts. I think the Maintenance message with a command/flag such as FE DOWN would be more suitable for this. =20 > 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. Sorry, i was away but i should be able to respond faster now. [HK] No problem. Always..better late than never :) Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 00:28:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21498 for ; Mon, 3 May 2004 00:28: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 1BKV37-0006Bb-JW for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 00:27:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i434RPcu023757 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 00:27:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKV0H-0005Kf-RS for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 00:24: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 AAA21196 for ; Mon, 3 May 2004 00:24: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 1BKV0F-0001z1-EU for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:24:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKUx9-0001RV-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:21:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKUuB-0000vG-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKUrA-0001gc-9Q; Mon, 03 May 2004 00: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 1BKUoO-00008P-FV for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 00:12: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 AAA20817 for ; Mon, 3 May 2004 00:12:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKUoM-0007l5-1V for forces-protocol@ietf.org; Mon, 03 May 2004 00:12:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKUlQ-0007GA-00 for forces-protocol@ietf.org; Mon, 03 May 2004 00:09:10 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKUhl-0006VH-00 for forces-protocol@ietf.org; Mon, 03 May 2004 00:05:21 -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 i434561e006249 for ; Mon, 3 May 2004 04:05:06 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 i4342r8v006664 for ; Mon, 3 May 2004 04:03:08 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 M2004050221045032538 for ; Sun, 02 May 2004 21:04:50 -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, 2 May 2004 21:04:50 -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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07ED4F14B@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQwXlbuV8IJsVNjR5y+AEfqcD53yQAXdcdwAAHikCA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 03 May 2004 04:04:50.0869 (UTC) FILETIME=[C831F650:01C430C3] 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, 2 May 2004 21:04:50 -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 this since I didn't see it for a long time.. -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Sunday, May 02, 2004 8:32 PM To: 'hadi@znyx.com' Cc: 'forces-protocol@ietf.org' Subject: RE: [Forces-protocol] topic 4c: Common Header Hey Jamal, Glad to see you're back in action ! Also, its good that you brought up these issues (below), I agree on most points. See my comments below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 BTW, there are a few things we seem to be skipping over - all of which are important to the header: - Transactions, definition and scope - Atomicity of transactions - batching of messages (maybe transactions) and this last one i am not one 100% sure, but do we need to have windowing as well for pipelining? or is batching sufficient? In other words can we have only a single transaction active at a time or can we have more running in parallel. [HK] Yes, I agree these are important and was hoping you will bring this up :) The Flags field in the header will cover some of these, if needed. We needed to complete the discussion on the Flags, that we had before (during Protocol Analysis team). Responses to your email below: On Fri, 2004-04-30 at 22:18, Khosravi, Hormuzd M wrote: > Length : 16 bits >=20 > Command Type : 8 bits (semantics - TBD) I am still trying to recover from my zone of last week; the commands will be limited to those 6 or so you posted earlier? [yes] > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) >=20 > LFB TypeID: TBD, no consensus on whether it is needed or not in the > header I think you somehow need to be able to inspect the message and say clearly who (FE/CE) and what (LFBID) that the message is directed at. If not for any other reason, this is useful for debugging in the field. I would like to be able to run a tcpdump session in a box where all forces messages are mirrored to and debug a race condition for example. My view would be to have this field to have may be one bit to represent direction and the rest of the bits to represent they type of LFB being targetted (set to zero or all 1s if message is not LFB specific) [HK] Robert had pointed out that he would like to use this field to address a message to a group of LFBs in different FEs (multicast based on LFB Type ID). Do you agree with this ? That might be a more compelling reason to me for having this field. I don't say that debugging is not important, but we do have sophisticated tools these days, which can easily look beyond headers into protocol messages these days. (I believe even tcpdump can do this quite easily.) >=20 > ------------------ > 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 ?? I think we may have overlooked the other requirements like atomicity; better catch them now. I will share the netlink2 experience maybe we can borrow something from it: Batching: 1) We had a flag which indicates "more messages for this transaction are on their way" 2) We had a command (not flag) which said "all messages are done for this transaction" A batch will start with one or more of #1 and end with #2. Atomicity: We had a speacial flag which indicated that a transaction or parts of it are atomic. The sequence number in our case was a strictly per message value. A more interesting approach would be to break it into a transaction:msg sequence. [HK] We had similar flags/approach for batching/atomicity. The one question that I have is if this is something which will be needed for all messages or only for Config message ? If you think we need Batching/Atomicity for all messages then we need these Flags in the common header, otherwise we can just have it in the Config message. What do you 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 May 3 00:44:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21960 for ; Mon, 3 May 2004 00:44: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 1BKVIn-0002w8-4x for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 00:43:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i434hbZ0011281 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 00:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKVEj-0001qc-KM for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 00:39: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 AAA21743 for ; Mon, 3 May 2004 00:39: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 1BKVEh-0004Qy-2z for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:39:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKVBV-0003tx-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:36:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKV83-0003Ib-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 00:32:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKV3i-0006Fr-RJ; Mon, 03 May 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 1BKV14-0005NT-OT for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 00:25: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 XAA19560 for ; Sun, 2 May 2004 23:39: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 1BKUIU-0002QR-Ka for forces-protocol@ietf.org; Sun, 02 May 2004 23:39:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKUFQ-0001rH-00 for forces-protocol@ietf.org; Sun, 02 May 2004 23:36:06 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKUC0-00017B-00 for forces-protocol@ietf.org; Sun, 02 May 2004 23:32:33 -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 i433Ukq7027002; Mon, 3 May 2004 03:30: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 i433W8ee013417; Mon, 3 May 2004 03:32: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 M2004050220315506781 ; Sun, 02 May 2004 20:31:55 -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, 2 May 2004 20:31: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: [Forces-protocol] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07ED4F144@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQwXlbuV8IJsVNjR5y+AEfqcD53yQAXdcdw From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 03 May 2004 03:31:55.0419 (UTC) FILETIME=[2EBC36B0:01C430BF] 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, 2 May 2004 20:31: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 Hey Jamal, Glad to see you're back in action ! Also, its good that you brought up these issues (below), I agree on most points. See my comments below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 BTW, there are a few things we seem to be skipping over - all of which are important to the header: - Transactions, definition and scope - Atomicity of transactions - batching of messages (maybe transactions) and this last one i am not one 100% sure, but do we need to have windowing as well for pipelining? or is batching sufficient? In other words can we have only a single transaction active at a time or can we have more running in parallel. [HK] Yes, I agree these are important and was hoping you will bring this up :) The Flags field in the header will cover some of these, if needed. We needed to complete the discussion on the Flags, that we had before (during Protocol Analysis team). Responses to your email below: On Fri, 2004-04-30 at 22:18, Khosravi, Hormuzd M wrote: > Length : 16 bits >=20 > Command Type : 8 bits (semantics - TBD) I am still trying to recover from my zone of last week; the commands will be limited to those 6 or so you posted earlier? [yes] > Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length > of Flags and Priority fields is TBD) >=20 > LFB TypeID: TBD, no consensus on whether it is needed or not in the > header I think you somehow need to be able to inspect the message and say clearly who (FE/CE) and what (LFBID) that the message is directed at. If not for any other reason, this is useful for debugging in the field. I would like to be able to run a tcpdump session in a box where all forces messages are mirrored to and debug a race condition for example. My view would be to have this field to have may be one bit to represent direction and the rest of the bits to represent they type of LFB being targetted (set to zero or all 1s if message is not LFB specific) [HK] Robert had pointed out that he would like to use this field to address a message to a group of LFBs in different FEs (multicast based on LFB Type ID). Do you agree with this ? That might be a more compelling reason to me for having this field. I don't say that debugging is not important, but we do have sophisticated tools these days, which can easily look beyond headers into protocol messages these days. (I believe even tcpdump can do this quite easily.) >=20 > ------------------ > 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 ?? I think we may have overlooked the other requirements like atomicity; better catch them now. I will share the netlink2 experience maybe we can borrow something from it: Batching: 1) We had a flag which indicates "more messages for this transaction are on their way" 2) We had a command (not flag) which said "all messages are done for this transaction" A batch will start with one or more of #1 and end with #2. Atomicity: We had a speacial flag which indicated that a transaction or parts of it are atomic. The sequence number in our case was a strictly per message value. A more interesting approach would be to break it into a transaction:msg sequence. [HK] We had similar flags/approach for batching/atomicity. The one question that I have is if this is something which will be needed for all messages or only for Config message ? If you think we need Batching/Atomicity for all messages then we need these Flags in the common header, otherwise we can just have it in the Config message. What do you 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 May 3 12:20: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 MAA10679 for ; Mon, 3 May 2004 12:20: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 1BKfy3-00075p-MV for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 12:06:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43G6tdX027265 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 12:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfpD-000591-UA for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 11:57: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 LAA09553 for ; Mon, 3 May 2004 11:57: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 1BKfpC-0002nD-S0 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 11:57:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfoI-0002jf-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 11:56:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKfnn-0002ga-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 11:56:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfjd-0003ix-PF; Mon, 03 May 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 1BKfbk-00022I-Bn for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 11:43: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 LAA08851 for ; Mon, 3 May 2004 11:43: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 1BKfbj-0001yW-5h for forces-protocol@ietf.org; Mon, 03 May 2004 11:43:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfaq-0001tm-00 for forces-protocol@ietf.org; Mon, 03 May 2004 11:42: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 1BKfaL-0001pP-00 for forces-protocol@ietf.org; Mon, 03 May 2004 11:42:25 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050308461344:4702 ; Mon, 3 May 2004 08:46:13 -0700 Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07ED4F147@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07ED4F147@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083598941.1022.53.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 05/03/2004 08:46:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2004 08:46:16 AM, Serialize complete at 05/03/2004 08:46:16 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: 03 May 2004 11:42: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 Hormuzd, On Sun, 2004-05-02 at 23:49, Khosravi, Hormuzd M wrote: > > 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. > > probably same context as subscribe above. A command maybe called > synchronize with a flag to distinguish diffrent things. > We need to show a state machine for a FE joining/leaving. > [HK] I don't like the term SYN or synchronize, since it is used by TCP. > May be we can use names like "Association Setup/teardown" or > "Bind/Unbind" which are more ForCES specific ? setup/connect etc should be fine. I do find SYN confuses a lot of people; TCP seems to have taken a monopoly there ;-> > Let me know which one you > like. Also, I am fine with having a single message such as Association > with a flag to indicate whether it is setup or teardown, although I > think it would be cleaner to have them as separate messages. Either is fine. > Also i mentioned an idea we implemented which was to allow the CE to > send a broadcast SYN messages to reset the FEs. > Even if we dont do it this way, i think we need to have forced restarts. > > [HK] Yes, I agree we need to have forced restarts. I think the > Maintenance message with a command/flag such as FE DOWN would be more > suitable for this. > Put something out and lets discuss it. What you suggest above sounds reasonable. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 12:41: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 MAA12031 for ; Mon, 3 May 2004 12:41: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 1BKgHe-0005BY-PA for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 12:27:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GRAD5019933 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 12:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgDM-0004KL-8S for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 12:22: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 MAA10792 for ; Mon, 3 May 2004 12:22: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 1BKgDK-0004dQ-PW for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 12:22:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgCN-0004Wb-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 12:21:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKgBS-0004Rq-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 12:20:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfy8-00076u-A5; Mon, 03 May 2004 12: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 1BKfmE-0004IE-Vl for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 11:54: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 LAA09427 for ; Mon, 3 May 2004 11:54: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 1BKfmD-0002b2-Sa for forces-protocol@ietf.org; Mon, 03 May 2004 11:54:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKflG-0002Xf-00 for forces-protocol@ietf.org; Mon, 03 May 2004 11:53:43 -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 1BKfkb-0002VE-00 for forces-protocol@ietf.org; Mon, 03 May 2004 11:53: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 2004050308565082:4712 ; Mon, 3 May 2004 08:56:50 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, Weiming Wang In-Reply-To: <468F3FDA28AA87429AD807992E22D07ED4F144@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07ED4F144@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1083599579.1021.75.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 05/03/2004 08:56:51 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2004 08:56:52 AM, Serialize complete at 05/03/2004 08:56:52 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: 03 May 2004 11:52: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 On Sun, 2004-05-02 at 23:31, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > BTW, there are a few things we seem to be skipping over - all of which > are important to the header: > > - Transactions, definition and scope > - Atomicity of transactions > - batching of messages (maybe transactions) > > and this last one i am not one 100% sure, but do we need to have > windowing as well for pipelining? or is batching sufficient? > In other words can we have only a single transaction active at a time or > can we have more running in parallel. > > [HK] Yes, I agree these are important and was hoping you will bring this > up :) The Flags field in the header will cover some of these, if needed. > We needed to complete the discussion on the Flags, that we had before > (during Protocol Analysis team). > Ok, good. > > 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 > > I think you somehow need to be able to inspect the message and say > clearly who (FE/CE) and what (LFBID) that the message is directed at. > If not for any other reason, this is useful for debugging in the field. > I would like to be able to run a tcpdump session in a box where all > forces messages are mirrored to and debug a race condition for example. > My view would be to have this field to have may be one bit to represent > direction and the rest of the bits to represent they type of LFB being > targetted (set to zero or all 1s if message is not LFB specific) > > [HK] Robert had pointed out that he would like to use this field to > address a message to a group of LFBs in different FEs (multicast based > on LFB Type ID). Do you agree with this ? That might be a more > compelling reason to me for having this field. I don't say that > debugging is not important, but we do have sophisticated tools these > days, which can easily look beyond headers into protocol messages these > days. (I believe even tcpdump can do this quite easily.) I cant remember what Roberts suggestion was; i know its in the archives, my brain is still slow. I 'll let him explain. The problem with standadrd sniffers is they need something to latch on to decide what the packet is. Clearly it is easy to tell the packets is a forces PL message. Next is you need to tell if it is from a CE or FE and whether it is going to a CE or FE. Ok, actually, this may lead back to what Weiming was saying maybe we should allocate the addressing such that we can tell that the packet is for one of those two. Example (I think this has been suggested before), we could have the most significant bit of the ID being set implying the address belongs to the CE. Speaking of which we need to discuss the addressing schemes now (eg broadcast to all FEs, all CEs, subset etc). On the content of the message: tcpdump should be able to decode based on the header if i am not mistaken. But we havent discussed the layout of the message content closely since last time. > [HK] We had similar flags/approach for batching/atomicity. The one > question that I have is if this is something which will be needed for > all messages or only for Config message ? Config messages is all i see rigth now. > If you think we need > Batching/Atomicity for all messages then we need these Flags in the > common header, otherwise we can just have it in the Config message. What > do you think ? The problem is i am not sure if it would be worth to say flags x only apply to messages of type y. I am indifferent. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 18:07: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 SAA06957 for ; Mon, 3 May 2004 18:07: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 1BKlW2-0005IU-JK for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 18:02:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43M2Ml2020349 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 18:02:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlEU-0008Pc-Jb for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 17:44: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 RAA05152 for ; Mon, 3 May 2004 17:44: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 1BKlES-0007bm-1d for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:44:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlDR-0007RN-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:43:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKlCT-0007Gy-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl2I-0002cx-Aw; Mon, 03 May 2004 17:31:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkLU-00058y-N8 for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 16:47: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 QAA29671 for ; Mon, 3 May 2004 16:47: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 1BKkLQ-0005bK-UB for forces-protocol@ietf.org; Mon, 03 May 2004 16:47:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkKX-0005Rl-00 for forces-protocol@ietf.org; Mon, 03 May 2004 16:46:26 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKkJs-0005Ew-00 for forces-protocol@ietf.org; Mon, 03 May 2004 16:45:44 -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 i43Ki0kS014657; Mon, 3 May 2004 20:44: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 i43KiXae015128; Mon, 3 May 2004 20:45:29 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 M2004050313451023983 ; Mon, 03 May 2004 13:45: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); Mon, 3 May 2004 13:45:10 -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: <468F3FDA28AA87429AD807992E22D07EDD5BB3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Protocol Messages: topic 3 & 4a Thread-Index: AcQxJUoY+eqpi1VCRjOR69L5F+fM5AAKbPiA From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 03 May 2004 20:45:10.0235 (UTC) FILETIME=[86866AB0:01C4314F] 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, 3 May 2004 13:45:08 -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 am fine with all your comments below. I'll send out another email to summarize our discussions on Protocol Messages and motivate next steps. Thanks for the prompt responses ! Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Monday, May 03, 2004 8:42 AM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a Hormuzd, On Sun, 2004-05-02 at 23:49, Khosravi, Hormuzd M wrote: > > 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. >=20 > probably same context as subscribe above. A command maybe called > synchronize with a flag to distinguish diffrent things. > We need to show a state machine for a FE joining/leaving. > [HK] I don't like the term SYN or synchronize, since it is used by TCP. > May be we can use names like "Association Setup/teardown" or > "Bind/Unbind" which are more ForCES specific ?=20 setup/connect etc should be fine. I do find SYN confuses a lot of people; TCP seems to have taken a monopoly there ;-> > Let me know which one you > like. Also, I am fine with having a single message such as Association > with a flag to indicate whether it is setup or teardown, although I > think it would be cleaner to have them as separate messages. Either is fine. > Also i mentioned an idea we implemented which was to allow the CE to > send a broadcast SYN messages to reset the FEs. > Even if we dont do it this way, i think we need to have forced restarts. >=20 > [HK] Yes, I agree we need to have forced restarts. I think the > Maintenance message with a command/flag such as FE DOWN would be more > suitable for this. >=20 Put something out and lets discuss it. What you suggest above sounds reasonable. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 18: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 SAA07080 for ; Mon, 3 May 2004 18: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 1BKlZF-0007qb-0Z for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 18:05:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43M5eUF030154 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 18:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlG7-0000fS-0m for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 17:45: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 RAA05276 for ; Mon, 3 May 2004 17:45: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 1BKlG4-00009y-HE for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:45:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlF6-0007kf-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:44:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKlEA-0007Z2-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 17:43:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl4b-0003tZ-AE; Mon, 03 May 2004 17:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkeX-0003K7-Ii for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 17:07: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 RAA01770 for ; Mon, 3 May 2004 17:07: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 1BKkeV-0001ff-BE for forces-protocol@ietf.org; Mon, 03 May 2004 17:07:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkdf-0001Ux-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:06:12 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKkch-00019U-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:05:11 -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 i43L4t1e028688; Mon, 3 May 2004 21:04: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 i43L4Ow1019476; Mon, 3 May 2004 21:05: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 M2004050314043907701 ; Mon, 03 May 2004 14:04:39 -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, 3 May 2004 14:04: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EDD5C21@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQxJruUqHIkfvQxRLisX+MzU5rk/gAKekoQ From: "Khosravi, Hormuzd M" To: Cc: , "Weiming Wang" X-OriginalArrivalTime: 03 May 2004 21:04:39.0250 (UTC) FILETIME=[3F4FF320:01C43152] 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, 3 May 2004 14:04: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, -----Original Message----- > > LFB TypeID: TBD, no consensus on whether it is needed or not in the > > header >=20 > I think you somehow need to be able to inspect the message and say > clearly who (FE/CE) and what (LFBID) that the message is directed at. > If not for any other reason, this is useful for debugging in the field. > I would like to be able to run a tcpdump session in a box where all > forces messages are mirrored to and debug a race condition for example. > My view would be to have this field to have may be one bit to represent > direction and the rest of the bits to represent they type of LFB being > targetted (set to zero or all 1s if message is not LFB specific) >=20 > [HK] Robert had pointed out that he would like to use this field to > address a message to a group of LFBs in different FEs (multicast based > on LFB Type ID). Do you agree with this ? That might be a more > compelling reason to me for having this field. I don't say that > debugging is not important, but we do have sophisticated tools these > days, which can easily look beyond headers into protocol messages these > days. (I believe even tcpdump can do this quite easily.) I cant remember what Roberts suggestion was; i know its in the archives, my brain is still slow. I 'll let him explain. [HK] Robert, any comments ?? The problem with standadrd sniffers is they need something to latch on to decide what the packet is. Clearly it is easy to tell the packets is a forces PL message. Next is you need to tell if it is from a CE or FE and whether it is going to a CE or FE. Ok, actually, this may lead back to what Weiming was saying maybe we should allocate the addressing such that we can tell that the packet is=20 for one of those two. Example (I think this has been suggested before), we could have the most significant bit of the ID being set implying the address belongs to the CE. [HK - Sure we can do this] Speaking of which we need to discuss the addressing schemes now (eg broadcast to all FEs, all CEs, subset etc). [HK] We can directly come up with some standard nos for this, when we are writing the text for Common Header section in the draft. On the content of the message: tcpdump should be able to decode based on the header if i am not mistaken. But we havent discussed the layout of the message content closely since last time.=20 [HK] The basic idea is the same, Common header followed by TLVs. I'll start defining the ones needed for the different protocol messages. > [HK] We had similar flags/approach for batching/atomicity. The one > question that I have is if this is something which will be needed for > all messages or only for Config message ?=20 Config messages is all i see rigth now. [Agree, I see the same] > If you think we need > Batching/Atomicity for all messages then we need these Flags in the > common header, otherwise we can just have it in the Config message. What > do you think ? The problem is i am not sure if it would be worth to say flags x only apply to messages of type y. I am indifferent. [HK] So is it fine with you if we define these Flags only as part of the Config message rather than the Common header ? It seems like you're saying yes, but I would like to confirm. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 18: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 SAA09020 for ; Mon, 3 May 2004 18:34: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 1BKlxM-0000Sk-UU for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 18:30:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43MUaFl001774 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 18:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKllE-0005wn-DY for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 18:18: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 SAA08095 for ; Mon, 3 May 2004 18:17: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 1BKllB-0004Lj-Kg for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlkM-0004Ef-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:17:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKljK-00046h-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlaX-0000Fp-DV; Mon, 03 May 2004 18: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 1BKlK7-0001O9-Am for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 17:50: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 RAA05628 for ; Mon, 3 May 2004 17:49: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 1BKlK4-0000nK-Kl for forces-protocol@ietf.org; Mon, 03 May 2004 17:50:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlJH-0000gP-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:49:12 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKlIY-0000Ue-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:48:26 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i43Lm853020007 for ; Mon, 3 May 2004 21:48:08 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 i43LlOaS028290 for ; Mon, 3 May 2004 21:48:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050314474802285 for ; Mon, 03 May 2004 14:47: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, 3 May 2004 14:47: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 Message-ID: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> Thread-Topic: Timeline - we need to start writing sections for the draft soon. Thread-Index: AcQxJruUqHIkfvQxRLisX+MzU5rk/gAK7M+w From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 03 May 2004 21:47:48.0781 (UTC) FILETIME=[46CB05D0:01C43158] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. 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, 3 May 2004 14:47: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 All Here is the timeline that we had proposed to the Chairs at the start of this team. 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 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 I think we have completed discussion on most topics (2.a.), and should be wrapping up with this by end of this week at the latest (May 7th). So we need to start thinking about writing the different Sections in the draft, that's our next task. I will volunteer to write the section on Protocol Messages, Protocol Scenarios and any other sections that are not taken by anyone. Any other volunteers ?? We need to get the first rev out by May 21st. Here is the outline for the draft for your reference, 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 Note: We will have 10 days to review and send comments on the sections once they are written in the initial draft. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 18:36: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 SAA09139 for ; Mon, 3 May 2004 18:36: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 1BKlxs-0000b2-9j for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 18:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43MV8n8002287 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 18:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKloA-0006tj-5V for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 18:21: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 SAA08276 for ; Mon, 3 May 2004 18:21: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 1BKlo7-0004lD-Ai for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:21:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlnK-0004dM-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:20:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKlma-0004VF-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 18:19:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlaa-0000Hx-OP; Mon, 03 May 2004 18:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlL9-0001Ve-6o for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 17:51: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 RAA05671 for ; Mon, 3 May 2004 17:51:02 -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 1BKlL6-0000uv-Gp for forces-protocol@ietf.org; Mon, 03 May 2004 17:51:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlK9-0000o9-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:50:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKlJf-0000gu-00 for forces-protocol@ietf.org; Mon, 03 May 2004 17:49:35 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKlJf-000Fmb-1Y for forces-protocol@ietf.org; Mon, 03 May 2004 21:49:35 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083599579.1021.75.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07ED4F144@orsmsx408.jf.intel.com> <1083599579.1021.75.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 3 May 2004 23:49:30 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 3 maj 2004, at 17.52, Jamal Hadi Salim wrote: > Ok, actually, this may lead back to what Weiming was saying maybe we > should allocate the addressing such that we can tell that the packet is > for one of those two. Example (I think this has been suggested before), > we could have the most significant bit of the ID being set implying the > address belongs to the CE. I definitely agree with this proposal. When Weiming first sent it out I was trying to form an argument in its favor, then I went invisible for a variety of personal reasons (surgery of a family member), plus travel. I think it also adds extensibility to the protocol over time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 19:31: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 TAA11658 for ; Mon, 3 May 2004 19:31: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 1BKmmm-0005VU-Py for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 19:23:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43NNi0H021162 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 19:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmfK-0003eA-29 for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 19:16: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 TAA11020 for ; Mon, 3 May 2004 19:15: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 1BKmfI-0004C4-M9 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 19:16:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKmeP-000451-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 19:15:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKmdn-0003xy-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 19:14:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmXg-0001gy-PC; Mon, 03 May 2004 19:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmWi-00017A-2n for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 19:07: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 TAA10537 for ; Mon, 3 May 2004 19:07: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 1BKmWe-0002za-KK for forces-protocol@ietf.org; Mon, 03 May 2004 19:07:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKmVs-0002sI-00 for forces-protocol@ietf.org; Mon, 03 May 2004 19:06:17 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKmUp-0002ci-00 for forces-protocol@ietf.org; Mon, 03 May 2004 19:05:11 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i43N4pCp027383; Mon, 3 May 2004 23:04:51 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 i43N1icA018319; Mon, 3 May 2004 23:04:57 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 M2004050316043814412 ; Mon, 03 May 2004 16:04:38 -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, 3 May 2004 16:04: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQxXLRM25YukgVWSLOM3iUKizZ4yQABV2hw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 03 May 2004 23:04:38.0389 (UTC) FILETIME=[02556250:01C43163] 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, 3 May 2004 16:04: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, Glad to have you back! As I said in my previous reply to Jamal, I am fine with this (below) as well. I think any special nos. etc which are needed for addressing can directly be defined by the person writing the section on Common header and we can all review that, once its done. Couple of questions... In your previous email, you had sent a .txt file for the draft. Is there also some XML file which we need to use first to write the draft, which later gets converted to a .txt file ? Did you want to post any other thoughts that you have on peer-to-peer model (topic 6), or do you think we already covered this topic in our protocol messages discussion ? Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > Ok, actually, this may lead back to what Weiming was saying maybe we > should allocate the addressing such that we can tell that the packet is > for one of those two. Example (I think this has been suggested before), > we could have the most significant bit of the ID being set implying the > address belongs to the CE. I definitely agree with this proposal. When Weiming first sent it out=20 I was trying to form an argument in its favor, then I went invisible=20 for a variety of personal reasons (surgery of a family member), plus=20 travel. I think it also adds extensibility to the protocol over time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 21:46: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 VAA16026 for ; Mon, 3 May 2004 21:46: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 1BKozd-0000CR-5H for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 21:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i441j95X000762 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 21:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoyd-0008Nb-4P for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 21:44: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 VAA15925 for ; Mon, 3 May 2004 21:44: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 1BKoya-0007T9-Ab for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:44:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKoxc-0007Kr-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:43:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKowj-0007Dj-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKoth-0007ga-HC; Mon, 03 May 2004 21: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 1BKooy-0006X9-Om for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 21:34: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 VAA15661 for ; Mon, 3 May 2004 21:34: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 1BKoow-0006EC-05 for forces-protocol@ietf.org; Mon, 03 May 2004 21:34:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKoo3-00066u-00 for forces-protocol@ietf.org; Mon, 03 May 2004 21:33: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 1BKonT-0005zF-00 for forces-protocol@ietf.org; Mon, 03 May 2004 21:32:35 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050318362447:5336 ; Mon, 3 May 2004 18:36:24 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, Weiming Wang In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5C21@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EDD5C21@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083634352.1041.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 05/03/2004 06:36:24 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2004 06:36:27 PM, Serialize complete at 05/03/2004 06:36:27 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: 03 May 2004 21:32: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 Mon, 2004-05-03 at 17:04, Khosravi, Hormuzd M wrote: > On the content of the message: tcpdump should be able to decode based > on the header if i am not mistaken. But we havent discussed the layout > of the message content closely since last time. > [HK] The basic idea is the same, Common header followed by TLVs. I'll > start defining the ones needed for the different protocol messages. If you put this together please reference the discussion we already had back when. This should would save time. > The problem is i am not sure if it would be worth to say flags x only > apply to messages of type y. I am indifferent. > > [HK] So is it fine with you if we define these Flags only as part of the > Config message rather than the Common header ? It seems like you're > saying yes, but I would like to confirm. > If you are asking this so you can get rid of the flags from the common header, then i would say i dont wanna take that risk. I have a feeling i misunderstood your intention. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 3 21:49: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 VAA16143 for ; Mon, 3 May 2004 21:49: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 1BKp2l-0000zS-TP for forces-protocol-archive@odin.ietf.org; Mon, 03 May 2004 21:48:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i441mN2B003799 for forces-protocol-archive@odin.ietf.org; Mon, 3 May 2004 21:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKp1Y-0000fD-GY for forces-protocol-web-archive@optimus.ietf.org; Mon, 03 May 2004 21: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 VAA16052 for ; Mon, 3 May 2004 21:47: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 1BKp1V-000062-NL for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKp0c-0007lw-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:46:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKozn-0007e8-00 for forces-protocol-web-archive@ietf.org; Mon, 03 May 2004 21:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKozV-0000Bi-4V; Mon, 03 May 2004 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKovi-0007xR-GP for forces-protocol@optimus.ietf.org; Mon, 03 May 2004 21:41: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 VAA15886 for ; Mon, 3 May 2004 21:41: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 1BKovf-00075h-Ir for forces-protocol@ietf.org; Mon, 03 May 2004 21:41:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKouj-0006yG-00 for forces-protocol@ietf.org; Mon, 03 May 2004 21:40: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 1BKotk-0006qn-00 for forces-protocol@ietf.org; Mon, 03 May 2004 21:39: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 2004050318425465:5344 ; Mon, 3 May 2004 18:42:54 -0700 Subject: Re: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083634737.1039.14.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 05/03/2004 06:42:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/03/2004 06:42:56 PM, Serialize complete at 05/03/2004 06:42:56 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: 03 May 2004 21:38:57 -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-05-03 at 17:47, Khosravi, Hormuzd M wrote: > Hi All > > Here is the timeline that we had proposed to the Chairs at the start of > this team. > > 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 > discussion of major issues > b. Distribute sections for individual writing > 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 > > I think we have completed discussion on most topics (2.a.), and should > be wrapping up with this by end of this week at the latest (May 7th). I would strongly recommend we scrub 2.a before moving on. Its probably the most critical part. No rush. I would rather be late than sorry. > So > we need to start thinking about writing the different Sections in the > draft, that's our next task. I will volunteer to write the section on > Protocol Messages, Protocol Scenarios and any other sections that are > not taken by anyone. I think those are big - so probably stick to those first. I could take starting 5 and up. How about this, i will take 3 and 5 for starters. cheers, jamal > Any other volunteers ?? We need to get the first rev out by May 21st. > > Here is the outline for the draft for your reference, > > 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 > > Note: We will have 10 days to review and send comments on the sections > once they are written in the initial draft. > > Thanks > 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 May 4 01: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 BAA26104 for ; Tue, 4 May 2004 01: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 1BKsTn-0007Aw-0s for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 01:28:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i445SUdG027579 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 01:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKsPi-0005wv-Th for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 01:24: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 BAA25728 for ; Tue, 4 May 2004 01:24: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 1BKsPf-0000ny-SU for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKsOn-0000e5-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:23:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKsNu-0000Uq-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:22:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKsKb-0004cf-KQ; Tue, 04 May 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 1BKsF7-0003CL-J7 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 01:13: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 BAA24910 for ; Tue, 4 May 2004 01:13: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 1BKsF4-0006XE-Gj for forces-protocol@ietf.org; Tue, 04 May 2004 01:13:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKsE3-0006Mf-00 for forces-protocol@ietf.org; Tue, 04 May 2004 01:12:16 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKsDp-0006E3-00 for forces-protocol@ietf.org; Tue, 04 May 2004 01:12:01 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i445Bouk010946; Tue, 4 May 2004 05:11:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i445BvJ6010597; Tue, 4 May 2004 05:12:04 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 M2004050322113022517 ; Mon, 03 May 2004 22:11:30 -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, 3 May 2004 22:11: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] Timeline - we need to start writing sectionsfor the draft soon. Message-ID: <468F3FDA28AA87429AD807992E22D07EDD5FF0@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Timeline - we need to start writing sectionsfor the draft soon. Thread-Index: AcQxeJd5djlCkoBySda4Z+D5j4Q0UwAHI/hA From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 04 May 2004 05:11:30.0561 (UTC) FILETIME=[429C4710:01C43196] 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, 3 May 2004 22:11: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 Jamal, Thanks for volunteering. Pls see my comments below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > Here is the timeline that we had proposed to the Chairs at the start of > this team. >=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 > 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 > I think we have completed discussion on most topics (2.a.), and should > be wrapping up with this by end of this week at the latest (May 7th). I would strongly recommend we scrub 2.a before moving on. Its probably the most critical part. No rush. I would rather be late than sorry. [HK] Sure, could you post some text on any of the remaining topics? I believe we have covered (or are currently discussing) most of the topics, but pls go thru list and comment. Also, I have requested Avri to post her thoughts on topic 6 which she raised, hopefully we will hear back soon. > So > we need to start thinking about writing the different Sections in the > draft, that's our next task. I will volunteer to write the section on > Protocol Messages, Protocol Scenarios and any other sections that are > not taken by anyone. I think those are big - so probably stick to those first. I could take starting 5 and up. How about this, i will take 3 and 5 for starters. [HK] That's fine with me. So just to clarify to rest of the team, 3 is Protocol overview and 5 is the common header. Any other volunteers ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 01:40: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 BAA26590 for ; Tue, 4 May 2004 01:40: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 1BKseS-0001bE-7X for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 01:39:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i445dW3f006144 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 01:39:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKsaT-0000Nv-H1 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 01:35: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 BAA26497 for ; Tue, 4 May 2004 01:35: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 1BKsaQ-00031f-Gc for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:35:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKsZS-0002sK-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:34:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKsZD-0002ip-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 01:34:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKsUN-0007Ft-JM; Tue, 04 May 2004 01:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKsRq-0006VG-Sx for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 01:26: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 BAA25890 for ; Tue, 4 May 2004 01:26: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 1BKsRn-0001FI-OV for forces-protocol@ietf.org; Tue, 04 May 2004 01:26:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKsR5-000148-00 for forces-protocol@ietf.org; Tue, 04 May 2004 01:25:44 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BKsQE-0000oZ-00 for forces-protocol@ietf.org; Tue, 04 May 2004 01:24:50 -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 i445OXdb000483; Tue, 4 May 2004 05:24:33 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 i445OclZ006549; Tue, 4 May 2004 05:24:40 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 M2004050322241709806 ; Mon, 03 May 2004 22:24:17 -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, 3 May 2004 22:24: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EDD5FF4@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQxd67H8Gi2Z3N7QhSkZMCppecYogAHp2ng From: "Khosravi, Hormuzd M" To: Cc: , "Weiming Wang" X-OriginalArrivalTime: 04 May 2004 05:24:17.0154 (UTC) FILETIME=[0B891620:01C43198] 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, 3 May 2004 22:24: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 Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > On the content of the message: tcpdump should be able to decode based > on the header if i am not mistaken. But we havent discussed the layout > of the message content closely since last time.=20 > [HK] The basic idea is the same, Common header followed by TLVs. I'll > start defining the ones needed for the different protocol messages. If you put this together please reference the discussion we already had back when. This should would save time. [HK] Sure, will do when I am writing this section. > The problem is i am not sure if it would be worth to say flags x only > apply to messages of type y. I am indifferent. >=20 > [HK] So is it fine with you if we define these Flags only as part of the > Config message rather than the Common header ? It seems like you're > saying yes, but I would like to confirm. >=20 If you are asking this so you can get rid of the flags from the common header, then i would say i dont wanna take that risk. I have a feeling i misunderstood your intention. [HK] Yes, that is what I was asking. But if you think this is a risk, we can define it in 2 places (Config message & header) in the initial draft and remove it from the common header once we review the draft after May 20th and you are satisfied with the text. Is that fine ? Thanks again, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 03:12:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13553 for ; Tue, 4 May 2004 03:12: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 1BKu3p-0004aR-0D for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 03:09:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4479mdV017626 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 03:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKu2Q-0004HK-5u for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 03:08: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 DAA13378 for ; Tue, 4 May 2004 03:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKu2M-0002xv-7u for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKu1T-0002mi-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03:07:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKu0d-0002az-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03:06:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtuQ-00021W-8G; Tue, 04 May 2004 03:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtsk-0001in-Ae for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 02:58: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 CAA12891 for ; Tue, 4 May 2004 02:58:18 -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 1BKtsg-0001Ad-BD for forces-protocol@ietf.org; Tue, 04 May 2004 02:58:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtrl-0000zT-00 for forces-protocol@ietf.org; Tue, 04 May 2004 02:57:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKtqn-0000nx-00 for forces-protocol@ietf.org; Tue, 04 May 2004 02:56:21 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKtqn-0002li-Kv for forces-protocol@ietf.org; Tue, 04 May 2004 06:56:21 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 4 May 2004 08:56:17 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit HI, On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote: > Avri, > > Glad to have you back! As I said in my previous reply to Jamal, I am > fine with this (below) as well. I think any special nos. etc which are > needed for addressing can directly be defined by the person writing the > section on Common header and we can all review that, once its done. Seems a reasonable approach. > > Couple of questions... > In your previous email, you had sent a .txt file for the draft. Is > there > also some XML file which we need to use first to write the draft, which > later gets converted to a .txt file ? Yes, there is a set of XML files, one for each section, and I can break it down smaller if folks want. I can send those out, but I was waiting for the CVS setup so that they could be started there. And yes, we then put all the xml sections through the xml2rfc tcl script to get the txt output. As I said, I am willing to play the role of assembling the doc from the various xml sections people write, icnluding debugging the xml formatting as needed. Unless someone wants to assign me a section to author, I would prefer to keep myself in a neutral copy-editor role so that I can't be seen as preferring my words over anyone else's. But if there is something that someone wants written I can. I can certainly take care of sections like abstract, maybe an introduction, references, etc. > > Did you want to post any other thoughts that you have on peer-to-peer > model (topic 6), or do you think we already covered this topic in our > protocol messages discussion ? I think we are actually subsuming it into the other discussions. In brief, in pure master-slave model, the FE would only respond when requested to do so, with the exception of alarms etc.. As we progress toward a peer-peer model, each of the peers has its role and can initiate a transaction depending on its own needs. As time goes on, and FE hierarchy and FE-FE communications become a reality, then I can envision occasions where the FE would notify the CE of changes in the FE set that are initiated by the FE based on some policy or other. I am also envisioning that there will be cases, though not 'permitted' where an FE will be directly manipulated by some process or operator other then the CE, where the FE will notify the CE of changed state or function. And while this is not currently an item for discussion, I can see the FE as being instrumental in the neighbor discovery process (I tend to divide routing into 3 not 2 sub-processes) a. ps. in terms of timing, I will be spending May in Sweden, so my response times will be skewed by that. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 03:13:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13595 for ; Tue, 4 May 2004 03:13: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 1BKu6t-0005FS-V2 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 03:12:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i447Cx1I020170 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 03:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKu5R-00050y-AA for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 03:11: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 DAA13502 for ; Tue, 4 May 2004 03:11: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 1BKu5N-0003Tz-Bu for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03:11:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKu4Q-0003Je-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03:10:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKu3a-000392-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 03: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 1BKu1B-0003WN-SL; Tue, 04 May 2004 03:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKtxf-0002ZY-8N for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 03:03: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 DAA13163 for ; Tue, 4 May 2004 03:03:23 -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 1BKtxb-00022G-Bq for forces-protocol@ietf.org; Tue, 04 May 2004 03:03:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKtwf-0001sP-00 for forces-protocol@ietf.org; Tue, 04 May 2004 03:02:26 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKtvh-0001hy-00 for forces-protocol@ietf.org; Tue, 04 May 2004 03:01:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKtvi-0003wd-7C for forces-protocol@ietf.org; Tue, 04 May 2004 07:01:26 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083634737.1039.14.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> <1083634737.1039.14.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. 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, 4 May 2004 09:01:21 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 4 maj 2004, at 03.38, Jamal Hadi Salim wrote: > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > I am wondering whether there might not be a utility in having a conference call at some point to run through some of the remaining knots. Though we are continents apart, there are time that almost work with the Pacific US early in the AM and China late at night. If this call were minuted with the minutes sent to this list for archival and inspection, I think we would still be functioning with the required visibility. I am willing to be the minute taker as I have fewer strong opinions (strange position for me to be in) then the rest of you. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 07:11:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23823 for ; Tue, 4 May 2004 07:11: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 1BKxjY-0008ET-Gz for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 07:05:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B58ws031639 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 07:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxeK-0006hg-8m for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 06:59: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 GAA22502 for ; Tue, 4 May 2004 06:59: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 1BKxeF-0000Id-W4 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 06:59:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxbx-0007PN-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 06:57:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxaQ-00073e-02 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 06:55:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxXy-00055h-9P for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 06:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxIr-0000ar-PI; Tue, 04 May 2004 06:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKwaF-0006iz-Do for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 05:51: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 FAA19179 for ; Tue, 4 May 2004 05:51:23 -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 1BKwaB-0001kL-OR for forces-protocol@ietf.org; Tue, 04 May 2004 05:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKwZD-0001ZN-00 for forces-protocol@ietf.org; Tue, 04 May 2004 05:50:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BKwYB-0001Ed-00 for forces-protocol@ietf.org; Tue, 04 May 2004 05:49:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BKwYA-000CjI-Rv for forces-protocol@ietf.org; Tue, 04 May 2004 09:49:19 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07ECE1E95@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07ECE1E95@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4CC5D322-9DB0-11D8-ACC9-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] peering model was Re: Protocol Messages: topic 3 & 4a 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, 4 May 2004 11:49:13 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 29 apr 2004, at 08.34, Khosravi, Hormuzd M wrote: > 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). Even in the peering, or semi-peer, model there may be messages that only make sense when coming from one type of peer or the other. So certainly a cfg message of the type - set this as your config only makes sense coming from the CE. But a config message that says my config has been changed by a third party could come from the FE and will probably look a lot like a 'set this config' message. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 07:30: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 HAA24916 for ; Tue, 4 May 2004 07:30: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 1BKy61-0006wC-HC for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 07:28:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44BSL5n026668 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 07:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKy2N-0005Xo-1b for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 07:24: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 HAA24483 for ; Tue, 4 May 2004 07: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 1BKy2M-0005uS-F5 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 07:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKy1Q-0005iZ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 07:23:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKy0i-0005WG-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 07:22:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxzs-00051x-Lj; Tue, 04 May 2004 07: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 1BKxyX-0004l6-62 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 07:20: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 HAA24315 for ; Tue, 4 May 2004 07:20:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxyW-00052Y-Ku for forces-protocol@ietf.org; Tue, 04 May 2004 07:20:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxxc-0004q8-00 for forces-protocol@ietf.org; Tue, 04 May 2004 07:19:41 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BKxx0-0004di-00 for forces-protocol@ietf.org; Tue, 04 May 2004 07:19:03 -0400 Received: from wwm1 (unverified [219.82.180.190]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 4 May 2004 19:31:32 +0800 Message-ID: <020c01c431c9$0d078280$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 4 May 2004 19:15: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 All, Sorry be off for a few days owing to a holiday in China. Firstly, on the msg direction indicator in the header, I actually originally have two thoughts for it. One is to define CE id and FE id in a different space, that is, e.g., using a bit in the space head (mst significent bit) to mark the different space, another is to put the 1 bit flag along with the transaction ID, that is, by viewing the ID we then know where the msg is generated. One more advantage for latter approach is it may supply some extra information for FE or CE to trace the transactions, and may be of some help to sth like transaction atomicity? Seems we begin to discuss how the writing task is to be assigned. Hornestly, my team ( I and Ligang) more prefer to take the task of protocol msg and common header writhing, because we think we may be more fit for sth more technique instead of beautiful literature oriented, . Actually protocol msg is a big task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3) for draft starter writing. For common header, if Jamal is interested, I would like to have a close co-work with you for this part. I may also write the definition part, for it seems mostly copy work. I hightly suggest Avri write the introduction as well as acknowledge and ref, and I also highly suggest Jamal you write the TML requirement part, because I think you may have a more understanding of this than us (at least me) anyway. I also agree to continue our discussion on the remained issue even when we have parallelly begun the writing. Sincerely, Weiming ----- Original Message ----- From: > HI, > > On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote: > > > Avri, > > > > Glad to have you back! As I said in my previous reply to Jamal, I am > > fine with this (below) as well. I think any special nos. etc which are > > needed for addressing can directly be defined by the person writing the > > section on Common header and we can all review that, once its done. > > Seems a reasonable approach. > > > > > Couple of questions... > > In your previous email, you had sent a .txt file for the draft. Is > > there > > also some XML file which we need to use first to write the draft, which > > later gets converted to a .txt file ? > > Yes, there is a set of XML files, one for each section, and I can break > it down smaller if folks want. I can send those out, but I was waiting > for the CVS setup so that they could be started there. > > And yes, we then put all the xml sections through the xml2rfc tcl > script to get the txt output. > > As I said, I am willing to play the role of assembling the doc from the > various xml sections people write, icnluding debugging the xml > formatting as needed. > > Unless someone wants to assign me a section to author, I would prefer > to keep myself in a neutral copy-editor role so that I can't be seen as > preferring my words over anyone else's. But if there is something that > someone wants written I can. I can certainly take care of sections > like abstract, maybe an introduction, references, etc. > > > > > Did you want to post any other thoughts that you have on peer-to-peer > > model (topic 6), or do you think we already covered this topic in our > > protocol messages discussion ? > > I think we are actually subsuming it into the other discussions. In > brief, in pure master-slave model, the FE would only respond when > requested to do so, with the exception of alarms etc.. As we progress > toward a peer-peer model, each of the peers has its role and can > initiate a transaction depending on its own needs. > > As time goes on, and FE hierarchy and FE-FE communications become a > reality, then I can envision occasions where the FE would notify the CE > of changes in the FE set that are initiated by the FE based on some > policy or other. I am also envisioning that there will be cases, > though not 'permitted' where an FE will be directly manipulated by some > process or operator other then the CE, where the FE will notify the CE > of changed state or function. And while this is not currently an item > for discussion, I can see the FE as being instrumental in the neighbor > discovery process (I tend to divide routing into 3 not 2 sub-processes) > > a. > > ps. in terms of timing, I will be spending May in Sweden, so my > response times will be skewed by that. > > > _______________________________________________ > 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 May 4 09:03: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 JAA28868 for ; Tue, 4 May 2004 09:03: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 1BKzWr-000892-5x for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44D09Hb031288 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzUI-00075n-ND for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 08:57: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 IAA28608 for ; Tue, 4 May 2004 08:57: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 1BKzUH-00004K-2S for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 08:57:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzTK-00001F-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 08:56:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzSR-0007mB-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 08:55:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzN3-000541-2v; Tue, 04 May 2004 08:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzFo-0003Wo-6P for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 08:42: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 IAA28016 for ; Tue, 4 May 2004 08:42: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 1BKzFm-00075o-Oa for forces-protocol@ietf.org; Tue, 04 May 2004 08:42:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzEv-00072K-00 for forces-protocol@ietf.org; Tue, 04 May 2004 08:41:38 -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 1BKzE2-0006z3-00 for forces-protocol@ietf.org; Tue, 04 May 2004 08:40:42 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050405443027:5820 ; Tue, 4 May 2004 05:44:30 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, Weiming Wang In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5FF4@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EDD5FF4@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083674439.1041.88.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 05/04/2004 05:44:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 05:44:32 AM, Serialize complete at 05/04/2004 05:44:32 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 May 2004 08:40: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 On Tue, 2004-05-04 at 01:24, Khosravi, Hormuzd M wrote: > > If you are asking this so you can get rid of the flags from the common > header, then i would say i dont wanna take that risk. I have a feeling i > misunderstood your intention. > > [HK] Yes, that is what I was asking. But if you think this is a risk, we > can define it in 2 places (Config message & header) in the initial draft > and remove it from the common header once we review the draft after May > 20th and you are satisfied with the text. Is that fine ? Sure, lets revisit when the text is in place. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 09:07: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 JAA29076 for ; Tue, 4 May 2004 09:07: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 1BKzcj-00014n-DX for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:06:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44D6Ddq004132 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09: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 1BKzZ8-0000TA-Kt for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:02: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 JAA28825 for ; Tue, 4 May 2004 09:02: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 1BKzZ7-0000Jw-7p for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:02:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzYB-0000Gp-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:01:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzXE-0000DN-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:00:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzVl-0007i1-3S; Tue, 04 May 2004 08: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 1BKzQV-0005xe-Nc for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 08: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 IAA28529 for ; Tue, 4 May 2004 08:53: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 1BKzQU-0007gF-5W for forces-protocol@ietf.org; Tue, 04 May 2004 08:53:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzPa-0007e2-00 for forces-protocol@ietf.org; Tue, 04 May 2004 08:52:39 -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 1BKzOj-0007bT-00 for forces-protocol@ietf.org; Tue, 04 May 2004 08:51:45 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050405553366:5826 ; Tue, 4 May 2004 05:55:33 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1083675102.1040.100.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 05/04/2004 05:55:33 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 05:55:35 AM, Serialize complete at 05/04/2004 05:55:35 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 May 2004 08:51:42 -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-05-04 at 02:56, avri@acm.org wrote: > Yes, there is a set of XML files, one for each section, and I can break > it down smaller if folks want. I can send those out, but I was waiting > for the CVS setup so that they could be started there. Is there any point in CVS anymore if you are going to be the central authority puttin these together. If the answer is we still need CVS i will put effort in getting us a server somewhere. In regards to you writting a section, i think thats your prerogative. You already play a valuable role putting things together. The rest of your emails a separate subject - will split into another mail. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 09:22: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 JAA29935 for ; Tue, 4 May 2004 09:22: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 1BKzr9-0005RY-6x for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DL7lt020911 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzpe-000536-5W for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:19: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 JAA29679 for ; Tue, 4 May 2004 09:19: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 1BKzpc-0001Ho-Jv for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:19:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzod-00018h-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:18:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzne-00012s-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzfR-0002MB-9d; Tue, 04 May 2004 09:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzd9-0001FW-3J for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:06: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 JAA29002 for ; Tue, 4 May 2004 09:06:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKzd7-0000Xc-K4 for forces-protocol@ietf.org; Tue, 04 May 2004 09:06:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzcH-0000Uh-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:05: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 1BKzbp-0000Rt-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:05:17 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050406090516:5852 ; Tue, 4 May 2004 06:09:05 -0700 Subject: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1083675914.1039.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 05/04/2004 06:09:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 06:09:07 AM, Serialize complete at 05/04/2004 06:09: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: 04 May 2004 09:05:14 -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-05-04 at 02:56, avri@acm.org wrote: > I think we are actually subsuming it into the other discussions. In > brief, in pure master-slave model, the FE would only respond when > requested to do so, with the exception of alarms etc.. As we progress > toward a peer-peer model, each of the peers has its role and can > initiate a transaction depending on its own needs. > > As time goes on, and FE hierarchy and FE-FE communications become a > reality, then I can envision occasions where the FE would notify the CE > of changes in the FE set that are initiated by the FE based on some > policy or other. I am also envisioning that there will be cases, > though not 'permitted' where an FE will be directly manipulated by some > process or operator other then the CE, where the FE will notify the CE > of changed state or function. Very good point which i was unable to adequately express in my email on the desire to have a config message from FE->* I dont think we can avoid the fact that events will be at times (not always) mapped to config messages. On Tue, 2004-05-04 at 05:49, avri@acm.org wrote: > Even in the peering, or semi-peer, model there may be messages that > only make sense when coming from one type of peer or the other. So > certainly a cfg message of the type - set this as your config only > makes sense coming from the CE. But a config message that says my > config has been changed by a third party could come from the FE and > will probably look a lot like a 'set this config' message. To reuse what i stated earlier: --- Config CE->FE message of "update table X (for LFB Y) with config Z" could be reused from FE->CE to say "table X (on LFB Y) was updated with config X". --- I think we should consider this semantic > And while this is not currently an item > for discussion, I can see the FE as being instrumental in the neighbor > discovery process (I tend to divide routing into 3 not 2 sub-processes) Can you explain a little more on this? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 09:29:16 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 JAA00251 for ; Tue, 4 May 2004 09:29: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 1BKzu6-0006Ra-CK for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:24:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DOACJ024762 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09: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 1BKztU-0006BP-1R for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:23: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 JAA29995 for ; Tue, 4 May 2004 09:23: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 1BKztS-0001at-HZ for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:23:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzsV-0001WK-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:22:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzrZ-0001S1-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzr4-0005LL-4g; Tue, 04 May 2004 09: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 1BKzov-0004sv-9U for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:18: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 JAA29627 for ; Tue, 4 May 2004 09:18: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 1BKzot-0001B3-JQ for forces-protocol@ietf.org; Tue, 04 May 2004 09:18:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKznt-00015R-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:17:45 -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 1BKznL-00011I-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:17: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 2004050406205962:5874 ; Tue, 4 May 2004 06:20:59 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <020c01c431c9$0d078280$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1083676628.1040.132.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 05/04/2004 06:21:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 06:21:01 AM, Serialize complete at 05/04/2004 06:21:01 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 May 2004 09:17: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-05-04 at 07:15, Weiming Wang wrote: > Hi All, > > Sorry be off for a few days owing to a holiday in China. How come we dont get as many holidays here? ;-> I just heard of the concept of golden week in Japan and i know Scandanavians (where Avri is to be found lately) has i think a whole month off for holidays/vacation;-> > Firstly, on the msg direction indicator in the header, I actually originally > have two thoughts for it. One is to define CE id and FE id in a different > space, that is, e.g., using a bit in the space head (mst significent bit) to > mark the different space, another is to put the 1 bit flag along with the > transaction ID, that is, by viewing the ID we then know where the msg is > generated. One more advantage for latter approach is it may supply some extra > information for FE or CE to trace the transactions, and may be of some help to > sth like transaction atomicity? > I am worried of making this too complex. Is this how GRMP did it? I explained how we did atomicity and batching and atomic transactions in netlink2; why dont we hear from you and Hormuzd on how you did it and see if we can pick something agreeable to all. I am gonna split your email here since the other is a unrelated topic. Something else we havent talked about in the header. The response part. I see two types of responses (gaian based on netlink2 experience): 1) Positive reply. This would probably be the same message as the config with ACK flag turned on. 2) Negative reply In our case we had a speacial command for this. It contained the result code and the old header cutnpasted back so you can identify which message has an error. I think we need to have both types of responses allowed. I noticed a few other protocols are defining this sort of responses lately. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 09:45:16 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 JAA01104 for ; Tue, 4 May 2004 09:45: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 1BL062-00011J-NI for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:36:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DaUTq003916 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL00G-0007e1-IO for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09: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 JAA00363 for ; Tue, 4 May 2004 09:30: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 1BL00E-00020x-NN for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:30:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzzH-0001wJ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:29:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKzyI-0001rd-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:28:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzty-0006Cs-42; Tue, 04 May 2004 09: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 1BKzsj-0005vw-3g for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:22: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 JAA29927 for ; Tue, 4 May 2004 09:22: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 1BKzsh-0001Xh-BA for forces-protocol@ietf.org; Tue, 04 May 2004 09:22:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzrn-0001UC-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:21: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 1BKzrN-0001QJ-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:21: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 2004050406250942:5884 ; Tue, 4 May 2004 06:25:09 -0700 Subject: Re: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> <1083634737.1039.14.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1083676878.1040.135.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 05/04/2004 06:25:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 06:25:11 AM, Serialize complete at 05/04/2004 06:25:11 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 May 2004 09:21: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 Tue, 2004-05-04 at 03:01, avri@acm.org wrote: > I am wondering whether there might not be a utility in having a > conference call at some point to run through some of the remaining > knots. Though we are continents apart, there are time that almost work > with the Pacific US early in the AM and China late at night. I think this is a good idea. I am sure if we could meet phyiscally for about two days we could close everything down. But that maybe impossible. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 09:47: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 JAA01418 for ; Tue, 4 May 2004 09:47: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 1BL0Et-00042U-45 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:45:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Djdua015514 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0B4-0002r3-IJ for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:41: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 JAA00949 for ; Tue, 4 May 2004 09:41: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 1BL0B2-0002iD-OM for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:41:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0AF-0002f3-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:40:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL09b-0002b2-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL05a-0000mF-IO; Tue, 04 May 2004 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzxS-00071x-6Q for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:27: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 JAA00217 for ; Tue, 4 May 2004 09:27: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 1BKzxQ-0001pe-Eq for forces-protocol@ietf.org; Tue, 04 May 2004 09:27:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzwY-0001n9-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:26:43 -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 1BKzwI-0001kX-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:26: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 2004050406301539:5890 ; Tue, 4 May 2004 06:30:15 -0700 Subject: draft text WAS(Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <020c01c431c9$0d078280$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1083677184.1041.141.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 05/04/2004 06:30:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 06:30:16 AM, Serialize complete at 05/04/2004 06:30:16 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 May 2004 09:26: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 Hi Weiming, On Tue, 2004-05-04 at 07:15, Weiming Wang wrote: > Seems we begin to discuss how the writing task is to be assigned. Hornestly, my > team ( I and Ligang) more prefer to take the task of protocol msg and common > header writhing, because we think we may be more fit for sth more technique > instead of beautiful literature oriented, . Actually protocol msg is a big > task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3) > for draft starter writing. For common header, if Jamal is interested, I would > like to have a close co-work with you for this part. I may also write the > definition part, for it seems mostly copy work. Weiming, come on now, i discovered (like columbus did) the common header section ;-> Ok, you can take that - i will take section 3 and 4. > I hightly suggest Avri write > the introduction as well as acknowledge and ref, and I also highly suggest Jamal > you write the TML requirement part, because I think you may have a more > understanding of this than us (at least me) anyway. Sounds like Avri has been volunteered ;-> cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 10: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 KAA02161 for ; Tue, 4 May 2004 10: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 1BL0Qn-0006qL-23 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 09:57:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DvvAB026300 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 09:57:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0GJ-0004LH-EQ for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:47: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 JAA01324 for ; Tue, 4 May 2004 09: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 1BL0GH-000392-Kb for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0FE-00032s-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:46:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0Eh-0002xE-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:45:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL07V-0001gX-Su; Tue, 04 May 2004 09:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL03H-0008PV-A9 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09: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 JAA00515 for ; Tue, 4 May 2004 09:33:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL03F-0002DJ-Iv for forces-protocol@ietf.org; Tue, 04 May 2004 09:33:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL02M-0002Ao-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:32:43 -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 1BL025-00027q-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:32:25 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050406361456:5895 ; Tue, 4 May 2004 06:36:14 -0700 Subject: remaining topics of discussion WAS(RE: [Forces-protocol] Timeline - we need to start writing sectionsfor the draft soon. From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5FF0@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EDD5FF0@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083677543.1039.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 05/04/2004 06:36:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 06:36:15 AM, Serialize complete at 05/04/2004 06:36: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: 04 May 2004 09:32: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 Tue, 2004-05-04 at 01:11, Khosravi, Hormuzd M wrote: > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > > [HK] Sure, could you post some text on any of the remaining topics? I > believe we have covered (or are currently discussing) most of the > topics, but pls go thru list and comment. Also, I have requested Avri to > post her thoughts on topic 6 which she raised, hopefully we will hear > back soon. The topicas as i see it: 1) It seems to me that the header discussion needs to be completed. I have raised a few points that need to be addressed in relation to the header: - atomicty, transaction definition, windowing, batching, types of replies, configs from FE->CE 2) peering model - discussion active 3) FEM/CEM - missing from your list 4) I would like to add a new one here: message body format. Clearing these i think should get us going on the text. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 10:11: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 KAA03158 for ; Tue, 4 May 2004 10:11: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 1BL0Yn-0003WG-44 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 10:06:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44E6DPR013520 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 10: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 1BL0TQ-00086P-VZ for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:00: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 KAA02109 for ; Tue, 4 May 2004 10:00: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 1BL0TO-00045o-W3 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:00:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0SW-00041i-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:59:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0Rz-0003y1-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 09:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0I9-0004oY-0W; Tue, 04 May 2004 09: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 1BL0F4-00043U-4h for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:45: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 JAA01189 for ; Tue, 4 May 2004 09:45:46 -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 1BL0F2-00030b-7J for forces-protocol@ietf.org; Tue, 04 May 2004 09:45:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0E6-0002vw-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:44:51 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BL0DA-0002s6-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:43:52 -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 i44DhnH21984; Tue, 4 May 2004 16:43:49 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 16:43:48 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i44Dhmdq020732; Tue, 4 May 2004 16:43:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00THEd35; Tue, 04 May 2004 16:43:46 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 i44DheH07251; Tue, 4 May 2004 16:43:40 +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, 4 May 2004 08:43:37 -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] Timeline - we need to start writing sections for the draft soon. Message-ID: Thread-Topic: Timeline - we need to start writing sections for the draft soon. Thread-Index: AcQxJruUqHIkfvQxRLisX+MzU5rk/gAK7M+wACLQQlA= To: , X-OriginalArrivalTime: 04 May 2004 13:43:37.0827 (UTC) FILETIME=[CD7CFB30:01C431DD] 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, 4 May 2004 09:43:36 -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, Sorry i was off sometime due to some personnel work. I was catching up = with emails. 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, May 03, 2004 5:48 PM > To: forces-protocol@ietf.org > Subject: [Forces-protocol] Timeline - we need to start=20 > writing sections > for the draft soon. >=20 >=20 > Hi All >=20 > Here is the timeline that we had proposed to the Chairs at=20 > the start of > this team. >=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 > 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 > I think we have completed discussion on most topics (2.a.), and should > be wrapping up with this by end of this week at the latest=20 > (May 7th). So > we need to start thinking about writing the different Sections in the > draft, that's our next task. I will volunteer to write the section on > Protocol Messages, Protocol Scenarios and any other sections that are > not taken by anyone. > Any other volunteers ?? We need to get the first rev out by May 21st. >=20 > Here is the outline for the draft for your reference, >=20 > 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 >=20 > Note: We will have 10 days to review and send comments on the sections > once they are written in the initial draft. >=20 > Thanks > 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 May 4 10:11: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 KAA03200 for ; Tue, 4 May 2004 10:11: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 1BL0Zh-0003rk-5I for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 10:07:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44E79Pg014842 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 10:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0WM-00026t-Rj for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:03: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 KAA02283 for ; Tue, 4 May 2004 10:03: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 1BL0WK-0004G3-ML for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0VQ-0004DI-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:02:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0Uv-0004A2-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Pt-0006W8-Cv; Tue, 04 May 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 1BL0G8-0004JA-7N for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 09:46: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 JAA01287 for ; Tue, 4 May 2004 09:46: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 1BL0G6-00037U-BJ for forces-protocol@ietf.org; Tue, 04 May 2004 09:46:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0F4-000311-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:45:51 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BL0EF-0002wP-00 for forces-protocol@ietf.org; Tue, 04 May 2004 09:44:59 -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 i44Diuv12538; Tue, 4 May 2004 16:44:56 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 16:44:51 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i44DipJt022853; Tue, 4 May 2004 16:44:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 009xyJO8; Tue, 04 May 2004 16:44:48 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 i44DilH07963; Tue, 4 May 2004 16:44:47 +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, 4 May 2004 08:44:46 -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] Timeline - we need to start writing sections for the draft soon. Message-ID: Thread-Topic: Timeline - we need to start writing sections for the draft soon. Thread-Index: AcQxJruUqHIkfvQxRLisX+MzU5rk/gAK7M+wACLZShA= To: , X-OriginalArrivalTime: 04 May 2004 13:44:46.0668 (UTC) FILETIME=[F68548C0:01C431DD] 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, 4 May 2004 09:44: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.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, I would like to volunteer for protocol scenario and Security = consideration section. 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, May 03, 2004 5:48 PM > To: forces-protocol@ietf.org > Subject: [Forces-protocol] Timeline - we need to start=20 > writing sections > for the draft soon. >=20 >=20 > Hi All >=20 > Here is the timeline that we had proposed to the Chairs at=20 > the start of > this team. >=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 > 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 > I think we have completed discussion on most topics (2.a.), and should > be wrapping up with this by end of this week at the latest=20 > (May 7th). So > we need to start thinking about writing the different Sections in the > draft, that's our next task. I will volunteer to write the section on > Protocol Messages, Protocol Scenarios and any other sections that are > not taken by anyone. > Any other volunteers ?? We need to get the first rev out by May 21st. >=20 > Here is the outline for the draft for your reference, >=20 > 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 >=20 > Note: We will have 10 days to review and send comments on the sections > once they are written in the initial draft. >=20 > Thanks > 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 May 4 10:29: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 KAA04414 for ; Tue, 4 May 2004 10:29: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 1BL0ro-0003KX-50 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 10:25:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44EPqkF012802 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 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 1BL0qn-000347-8y for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 10: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 KAA04125 for ; Tue, 4 May 2004 10:24: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 1BL0ql-0005Zf-2T for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:24:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0pt-0005Vj-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:23:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0pT-0005Qb-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 10:23:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0mC-0001mC-TE; Tue, 04 May 2004 10:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0iw-0000AY-Sm for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 10:16: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 KAA03745 for ; Tue, 4 May 2004 10:16:39 -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 1BL0iu-000541-Mr for forces-protocol@ietf.org; Tue, 04 May 2004 10:16:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0i5-00050w-00 for forces-protocol@ietf.org; Tue, 04 May 2004 10:15:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BL0hj-0004x8-00 for forces-protocol@ietf.org; Tue, 04 May 2004 10:15: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 1BL0hi-000EfM-KF for forces-protocol@ietf.org; Tue, 04 May 2004 14:15:26 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083675102.1040.100.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <1083675102.1040.100.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7A1ED10C-9DD5-11D8-ACC9-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 4 May 2004 16:15:20 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 4 maj 2004, at 14.51, Jamal Hadi Salim wrote: > On Tue, 2004-05-04 at 02:56, avri@acm.org wrote: > > >> Yes, there is a set of XML files, one for each section, and I can >> break >> it down smaller if folks want. I can send those out, but I was >> waiting >> for the CVS setup so that they could be started there. > > Is there any point in CVS anymore if you are going to be the central > authority puttin these together. perhaps not. though i will probably use it on my system in any case just to make sure i can keep history. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 11: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 LAA07521 for ; Tue, 4 May 2004 11: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 1BL1bN-0008Kn-9u for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 11:12:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44FCvaS032033 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 11:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1WN-00072Z-Pl for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 11:07: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 LAA07058 for ; Tue, 4 May 2004 11:07: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 1BL1WL-0001On-91 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 11:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1VX-0001Jv-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 11:06:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Um-0001Ej-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 11:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Oy-0004iJ-7p; Tue, 04 May 2004 11: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 1BL1MW-00040o-M2 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 10:57: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 KAA06516 for ; Tue, 4 May 2004 10:57: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 1BL1MU-0000Yr-3X for forces-protocol@ietf.org; Tue, 04 May 2004 10:57:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1LW-0000Uc-00 for forces-protocol@ietf.org; Tue, 04 May 2004 10:56:35 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Kb-0000Nd-00 for forces-protocol@ietf.org; Tue, 04 May 2004 10:55:37 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i44EstMp126338; Tue, 4 May 2004 14:54:55 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 i44Essov284442; Tue, 4 May 2004 16:54:55 +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 QAA60214; Tue, 4 May 2004 16:54:54 +0200 Message-ID: <4097AEBD.80908@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, forces-protocol@ietf.org, Weiming Wang Subject: Re: [Forces-protocol] topic 4c: Common Header References: <468F3FDA28AA87429AD807992E22D07EDD5C21@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07EDD5C21@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------050206040105000607020207" 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, 04 May 2004 16:54:53 +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.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050206040105000607020207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate6.de.ibm.com id i44EstMp126338 Content-Transfer-Encoding: quoted-printable Hormuzd, Jamal, See my clarifications below. Khosravi, Hormuzd M wrote: >Jamal, > >-----Original Message----- > > =20 > >>>LFB TypeID: TBD, no consensus on whether it is needed or not in the >>>header >>> =20 >>> >>I think you somehow need to be able to inspect the message and say >>clearly who (FE/CE) and what (LFBID) that the message is directed at. >>If not for any other reason, this is useful for debugging in the >> =20 >> >field. > =20 > >>I would like to be able to run a tcpdump session in a box where all >>forces messages are mirrored to and debug a race condition for >> =20 >> >example. > =20 > >>My view would be to have this field to have may be one bit to >> =20 >> >represent > =20 > >>direction and the rest of the bits to represent they type of LFB being >>targetted (set to zero or all 1s if message is not LFB specific) >> >>[HK] Robert had pointed out that he would like to use this field to >>address a message to a group of LFBs in different FEs (multicast based >>on LFB Type ID). Do you agree with this ? That might be a more >>compelling reason to me for having this field. I don't say that >>debugging is not important, but we do have sophisticated tools these >>days, which can easily look beyond headers into protocol messages >> =20 >> >these > =20 > >>days. (I believe even tcpdump can do this quite easily.) >> =20 >> > >I cant remember what Roberts suggestion was; i know its in the archives, >my brain is still slow. I 'll let him explain. >[HK] Robert, any comments ?? > The idea behind the LFB TypeID is to be able to easily broadcast a=20 message to all instances of a particular LFB class in an NE, without=20 having to address these LFBs individually. For instance, this can be useful if we want to get all interfaces=20 active, or if we want to update a route in all FEs. It greatly simplifies the use of the PL as one can start downloading=20 routes to the FEs without even knowing the ID of the FEs or of the LFBs.=20 Can call this a "plug-and-play" feature, which is invaluable from a=20 user's perspective. More precisely, I see the following three cases of interest (with=20 increasing scope): dest ID: FE x, LFBType: y addresses all LFBs of type y=20 in FE x dest ID: group FE z, LFBType: y addresses all LFBS of type y in=20 the group z of FEs. dest ID: FE broadcast, LFBType: y addresses all LFBS of type y in=20 all FEs in the NE. Regards, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------050206040105000607020207 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hormuzd, Jamal,
See my clarifications below.

Khosravi, Hormuzd M wrote:
Jamal,

-----Original Message-----

  
LFB TypeID: TBD, no consensus on whether it is needed or not in the
header
      
I think you somehow need to be able to inspect the message and say
clearly who (FE/CE) and what (LFBID) that the message is directed at.
If not for any other reason, this is useful for debugging in the
    
field.
  
I would like to be able to run a tcpdump session in a box where all
forces messages are mirrored to and debug a race condition for
    
example.
  
My view would be to have this field to have may be one bit to
    
represent
  
direction and the rest of the bits to represent they type of LFB being
targetted (set to zero or all 1s if message is not LFB specific)

[HK] Robert had pointed out that he would like to use this field to
address a message to a group of LFBs in different FEs (multicast based
on LFB Type ID). Do you agree with this ? That might be a more
compelling reason to me for having this field. I don't say that
debugging is not important, but we do have sophisticated tools these
days, which can easily look beyond headers into protocol messages
    
these
  
days. (I believe even tcpdump can do this quite easily.)
    

I cant remember what Roberts suggestion was; i know its in the archives,
my brain is still slow. I 'll let him explain.
[HK] Robert, any comments ??

The idea behind the LFB TypeID is to be able to easily broadcast a message to all instances of a particular LFB class in an NE, without having to address these LFBs individually.

For instance, this can be useful if we want to get all interfaces active, or if we want to update a route in all FEs.

It greatly simplifies the use of the PL as one can start downloading routes to the FEs without even knowing the ID of the FEs or of the LFBs. Can call this a "plug-and-play" feature, which is invaluable from a user's perspective.

More precisely, I see the following three cases of interest (with increasing scope):

dest ID: FE x,               LFBType: y     addresses all LFBs of type y in FE x
dest ID: group FE z,     LFBType: y     addresses all LFBS of type y in the group z of FEs.
dest ID: FE broadcast, LFBType: y     addresses all LFBS of type y in all FEs in the NE.



Regards,
-- 
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
--------------050206040105000607020207-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 12:30:15 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 MAA11451 for ; Tue, 4 May 2004 12:30: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 1BL2m2-0003Qu-Ry for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 12:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44GS28e013192 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 12: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 1BL2dy-0001qJ-PH for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 12: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 MAA10965 for ; Tue, 4 May 2004 12:19: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 1BL2dx-0007Ng-CS for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 12:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2dA-0007JK-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 12:18:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL2cK-0007Er-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 12:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2Np-0004MV-69; Tue, 04 May 2004 12:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2J4-0003No-NR for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 11:58: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 LAA10045 for ; Tue, 4 May 2004 11:58: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 1BL2J3-0005c7-Fr for forces-protocol@ietf.org; Tue, 04 May 2004 11:58:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2I0-0005VL-00 for forces-protocol@ietf.org; Tue, 04 May 2004 11:57:01 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BL2HD-0005P3-00 for forces-protocol@ietf.org; Tue, 04 May 2004 11:56:15 -0400 Received: from wwm1 (unverified [219.82.181.168]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 5 May 2004 00:08:48 +0800 Message-ID: <019401c431ef$c8b0a0e0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> <1083676628.1040.132.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 4 May 2004 23:52:18 +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 Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > On Tue, 2004-05-04 at 07:15, Weiming Wang wrote: > > Hi All, > > > > Sorry be off for a few days owing to a holiday in China. > > How come we dont get as many holidays here? ;-> > I just heard of the concept of golden week in Japan and i know > Scandanavians (where Avri is to be found lately) has i think a whole > month off for holidays/vacation;-> [Weiming]That's easy. Just put two weekends together so that we can go far away and spend more money, then the economy goes up. :) > > Firstly, on the msg direction indicator in the header, I actually originally > > have two thoughts for it. One is to define CE id and FE id in a different > > space, that is, e.g., using a bit in the space head (mst significent bit) to > > mark the different space, another is to put the 1 bit flag along with the > > transaction ID, that is, by viewing the ID we then know where the msg is > > generated. One more advantage for latter approach is it may supply some extra > > information for FE or CE to trace the transactions, and may be of some help to > > sth like transaction atomicity? > > > > I am worried of making this too complex. Is this how GRMP did it? [Weiming]Maybe it has very little to do with atomicity (after I read Netlink2 again). Actually it was very important in GRMP because GRMP used it as a signal to indicate if it is a ACK or Response message. GRMP defined the ACK and Response msgs that they had the same transaction ID as the msg they responsed. Speaking of this, I agree with you that we need to see the transaction definition more carefully. For instance, we need to decide what does one trasaction (with same tran. ID) mean? Can we treat a config msg and its response msg as in the same transaction? How about ACK msg then? (may have two ACKs here, ACK to config msg and ACK to config response msg) My idea more tends to treat all them as in one transaction therefore they all have the same tran.ID. > I explained how we did atomicity and batching and atomic transactions in > netlink2; why dont we hear from you and Hormuzd on how you did it and > see if we can pick something agreeable to all. > [Weiming]As well as above, we took an 'I'flag and a 'submsg number' field (as GSMP) in the message header for msg fragments. This 'I' flag is quite the same as the '_MULTI' flag in Netlink2. The 'submsg number' may be useful for some transport layer that does not provide reordering back. > I am gonna split your email here since the other is a unrelated topic. > > Something else we havent talked about in the header. > The response part. I see two types of responses (gaian based on netlink2 > experience): > > 1) Positive reply. > This would probably be the same message as the config with ACK flag > turned on. > > 2) Negative reply > In our case we had a speacial command for this. It contained the result > code and the old header cutnpasted back so you can identify which > message has an error. > > I think we need to have both types of responses allowed. I noticed a few > other protocols are defining this sort of responses lately. > [Weiming]I agree. Actually we need to discuss the ACK msg now. Hornestly, I'm now with a little confusion between the 'ACK' and the 'response', their definitions, scope,and differences. > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 13:37: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 NAA14865 for ; Tue, 4 May 2004 13:37: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 1BL3iO-0004In-Os for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 13:28:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HSKSg016537 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 13:28:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3b4-0002SP-G5 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:20: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 NAA14052 for ; Tue, 4 May 2004 13:20: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 1BL3b2-0005NB-F0 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 13:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3aB-0005Gd-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 13:19:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3ZH-0005AX-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 13:18:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3XR-0000pC-T7; Tue, 04 May 2004 13:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Ne-0006FL-A7 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 13:06: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 NAA13051 for ; Tue, 4 May 2004 13:06: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 1BL3Nc-0003jw-FH for forces-protocol@ietf.org; Tue, 04 May 2004 13:06:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3Mn-0003di-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:06:02 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BL3MA-0003XK-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:05:27 -0400 Received: from wwm1 (unverified [219.82.181.168]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 5 May 2004 01:17:54 +0800 Message-ID: <01b301c431f9$6f8918d0$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> <1083677184.1041.141.camel@jzny.localdomain> Subject: Re: draft text WAS(Re: [Forces-protocol] topic 4c: Common Header 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: Wed, 5 May 2004 01:01: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, ----- Original Message ----- From: "Jamal Hadi Salim" > Hi Weiming, > > On Tue, 2004-05-04 at 07:15, Weiming Wang wrote: > > > Seems we begin to discuss how the writing task is to be assigned. Hornestly, my > > team ( I and Ligang) more prefer to take the task of protocol msg and common > > header writhing, because we think we may be more fit for sth more technique > > instead of beautiful literature oriented, . Actually protocol msg is a big > > task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3) > > for draft starter writing. For common header, if Jamal is interested, I would > > like to have a close co-work with you for this part. I may also write the > > definition part, for it seems mostly copy work. > > Weiming, come on now, i discovered (like columbus did) the common header > section ;-> > Ok, you can take that - i will take section 3 and 4. [Weiming]Thank you very much. I'l do my best. :) > > > I hightly suggest Avri write > > the introduction as well as acknowledge and ref, and I also highly suggest Jamal > > you write the TML requirement part, because I think you may have a more > > understanding of this than us (at least me) anyway. > > Sounds like Avri has been volunteered ;-> > > > 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 Tue May 4 14: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 OAA17715 for ; Tue, 4 May 2004 14: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 1BL4QZ-0003Iy-85 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:13:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IDxS4012699 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Ld-0001wX-FV for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:08: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 OAA16675 for ; Tue, 4 May 2004 14:08: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 1BL4Lb-0002V4-36 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:08:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Ki-0002OG-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:07:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Jr-0002GC-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4BC-0006c3-EX; Tue, 04 May 2004 13:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL445-0002PG-Nm for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 13:50: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 NAA15639 for ; Tue, 4 May 2004 13:50: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 1BL443-0000X6-AZ for forces-protocol@ietf.org; Tue, 04 May 2004 13:50:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL43B-0000SM-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:49:50 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1BL42e-0000Lh-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:49:16 -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 i44HmiWn138634; Tue, 4 May 2004 17:48:44 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 i44Hmiov201574; Tue, 4 May 2004 19:48: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 TAA56100; Tue, 4 May 2004 19:48:44 +0200 Message-ID: <4097D77C.3080908@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> In-Reply-To: <020c01c431c9$0d078280$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------060205090907060005000002" 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, 04 May 2004 19:48: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.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060205090907060005000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id i44HmiWn138634 Content-Transfer-Encoding: quoted-printable Weiming, and all, Weiming Wang wrote: >Hi All, > >Sorry be off for a few days owing to a holiday in China. > >Firstly, on the msg direction indicator in the header, I actually origi= nally >have two thoughts for it. One is to define CE id and FE id in a differe= nt >space, that is, e.g., using a bit in the space head (mst significent bit= ) to >mark the different space, another is to put the 1 bit flag along with t= he >transaction ID, that is, by viewing the ID we then know where the msg is >generated. One more advantage for latter approach is it may supply some = extra >information for FE or CE to trace the transactions, and may be of some = help to >sth like transaction atomicity? > Frankly, I can't see how adding a flag in the message to indicate its=20 direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and FE=20 to FE ?) adds further information to help tracing transactions. Please=20 explain. For simplicity I'd rather stick to the usual IP header=20 semantics with a dst field and a src field. Splitting the ID address space in two equal subspaces (which would be=20 the case if we choose the MSB of the ID to distinguish among CE and FE=20 ID) would be an overkill for CE space. I guesstimate the ratio of FEs vs=20 CEs in an NE to be in the order of 100 to 1000. Who has a proposal how to best split the address space ? Regards, -Robert > >Seems we begin to discuss how the writing task is to be assigned. Horne= stly, my >team ( I and Ligang) more prefer to take the task of protocol msg and co= mmon >header writhing, because we think we may be more fit for sth more techni= que >instead of beautiful literature oriented, . Actually protocol msg is a = big >task, I just suggest we assign the 6 msgs to two individuals (1st 3, and= last 3) >for draft starter writing. For common header, if Jamal is interested, I= would >like to have a close co-work with you for this part. I may also write t= he >definition part, for it seems mostly copy work. I hightly suggest Avri = write >the introduction as well as acknowledge and ref, and I also highly sugge= st Jamal >you write the TML requirement part, because I think you may have a more >understanding of this than us (at least me) anyway. > >I also agree to continue our discussion on the remained issue even when = we have >parallelly begun the writing. > >Sincerely, >Weiming > >----- Original Message ----- >From: > > =20 > >>HI, >> >>On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote: >> >> =20 >> >>>Avri, >>> >>>Glad to have you back! As I said in my previous reply to Jamal, I am >>>fine with this (below) as well. I think any special nos. etc which are >>>needed for addressing can directly be defined by the person writing th= e >>>section on Common header and we can all review that, once its done. >>> =20 >>> >>Seems a reasonable approach. >> >> =20 >> >>>Couple of questions... >>>In your previous email, you had sent a .txt file for the draft. Is >>>there >>>also some XML file which we need to use first to write the draft, whic= h >>>later gets converted to a .txt file ? >>> =20 >>> >>Yes, there is a set of XML files, one for each section, and I can break >>it down smaller if folks want. I can send those out, but I was waiting >>for the CVS setup so that they could be started there. >> >>And yes, we then put all the xml sections through the xml2rfc tcl >>script to get the txt output. >> >>As I said, I am willing to play the role of assembling the doc from the >>various xml sections people write, icnluding debugging the xml >>formatting as needed. >> >>Unless someone wants to assign me a section to author, I would prefer >>to keep myself in a neutral copy-editor role so that I can't be seen as >>preferring my words over anyone else's. But if there is something that >>someone wants written I can. I can certainly take care of sections >>like abstract, maybe an introduction, references, etc. >> >> =20 >> >>>Did you want to post any other thoughts that you have on peer-to-peer >>>model (topic 6), or do you think we already covered this topic in our >>>protocol messages discussion ? >>> =20 >>> >>I think we are actually subsuming it into the other discussions. In >>brief, in pure master-slave model, the FE would only respond when >>requested to do so, with the exception of alarms etc.. As we progress >>toward a peer-peer model, each of the peers has its role and can >>initiate a transaction depending on its own needs. >> >>As time goes on, and FE hierarchy and FE-FE communications become a >>reality, then I can envision occasions where the FE would notify the CE >>of changes in the FE set that are initiated by the FE based on some >>policy or other. I am also envisioning that there will be cases, >>though not 'permitted' where an FE will be directly manipulated by some >>process or operator other then the CE, where the FE will notify the CE >>of changed state or function. And while this is not currently an item >>for discussion, I can see the FE as being instrumental in the neighbor >>discovery process (I tend to divide routing into 3 not 2 sub-processes) >> >>a. >> >>ps. in terms of timing, I will be spending May in Sweden, so my >>response times will be skewed by that. >> >> >>_______________________________________________ >>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 > > > =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 --------------060205090907060005000002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming, and all,

Weiming Wang wrote:
Hi All,

Sorry be off  for a few days owing to a holiday in China.

Firstly,  on the msg direction indicator in the header, I actually originally
have two thoughts for it.  One is to define CE id and FE id in a different
space, that is, e.g., using a bit in the space head (mst significent bit) to
mark the different space, another is to  put the 1 bit flag along with the
transaction ID, that is, by viewing the ID we then know where the msg is
generated. One more advantage for latter approach is it may supply some extra
information for FE or CE to trace the transactions,  and may be of some help to
sth like transaction atomicity?
Frankly, I can't see how adding a flag in the message to indicate its direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and FE to FE ?) adds further information to help tracing transactions. Please explain. For simplicity I'd rather stick to the usual IP header semantics with a dst field and a src field.

Splitting the ID address space in two equal subspaces (which would be the case if we choose the MSB of the ID to distinguish among CE and FE ID) would be an overkill for CE space. I guesstimate the ratio of FEs vs CEs in an NE to be in the order of 100 to 1000.

Who has a proposal how to best split the address space ?

Regards,
-Robert

Seems we begin to discuss how the writing task is to be assigned.  Hornestly, my
team ( I and Ligang) more prefer to take the task of protocol msg and common
header writhing, because we think we may be more fit for sth more technique
instead of beautiful literature oriented, .  Actually protocol msg is a big
task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3)
for draft starter writing.  For common header, if Jamal is interested, I would
like to have a close co-work with you for this part.  I may also write the
definition part, for it seems mostly copy work. I hightly suggest  Avri write
the introduction as well as acknowledge and ref, and I also highly suggest Jamal
you write the TML requirement part, because I think you may have a more
understanding of this than us (at least me) anyway.

I also agree to continue our discussion on the remained issue even when we have
parallelly begun the writing.

Sincerely,
Weiming

----- Original Message -----
From: <avri@acm.org>

  
HI,

On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote:

    
Avri,

Glad to have you back! As I said in my previous reply to Jamal, I am
fine with this (below) as well. I think any special nos. etc which are
needed for addressing can directly be defined by the person writing the
section on Common header and we can all review that, once its done.
      
Seems a reasonable approach.

    
Couple of questions...
In your previous email, you had sent a .txt file for the draft. Is
there
also some XML file which we need to use first to write the draft, which
later gets converted to a .txt file ?
      
Yes, there is a set of XML files, one for each section, and I can break
it down smaller if folks want.  I can send those out, but I was waiting
for the CVS setup so that they could be started there.

And yes, we then put all the xml sections through the xml2rfc tcl
script to get the txt output.

As I said, I am willing to play the role of assembling the doc from the
various xml sections people write, icnluding debugging the xml
formatting as needed.

Unless someone wants to assign me a section to author, I would prefer
to keep myself in a neutral copy-editor role so that I can't be seen as
preferring my words over anyone else's. But if there is something that
someone wants written I can.  I can certainly take care of sections
like abstract, maybe an introduction, references, etc.

    
Did you want to post any other thoughts that you have on peer-to-peer
model (topic 6), or do you think we already covered this topic in our
protocol messages discussion ?
      
I think we are actually subsuming it into the other discussions.  In
brief, in pure master-slave model, the FE would only respond when
requested to do so, with the exception of alarms etc..  As we progress
toward a peer-peer model, each of the peers has its role and can
initiate a transaction depending on its own needs.

As time goes on, and FE hierarchy and FE-FE communications become a
reality, then I can envision occasions where the FE would notify the CE
of changes in the FE set that are initiated by the FE based on some
policy or other.  I am also envisioning that there will be cases,
though not 'permitted' where an FE will be directly manipulated by some
process or operator other then the CE, where the FE will notify the CE
of changed state or function.  And while this is not currently an item
for discussion, I can see the FE as being instrumental in the neighbor
discovery process (I tend to divide routing into 3 not 2 sub-processes)

a.

ps. in terms of timing, I will be spending May in Sweden, so my
response times will be skewed by that.


_______________________________________________
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


  

-- 
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
--------------060205090907060005000002-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 14:26: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 OAA17953 for ; Tue, 4 May 2004 14: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 1BL4Tq-0004M1-LO for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:17:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IHMpA016733 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4PQ-0002t5-Rd for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:12: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 OAA16889 for ; Tue, 4 May 2004 14:12: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 1BL4PO-0002u2-HY for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:12:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4OU-0002oJ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:11:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Nl-0002jF-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4BG-0006gk-DZ; Tue, 04 May 2004 13:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL45G-0002cf-KO for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 13: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 NAA15698 for ; Tue, 4 May 2004 13:51: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 1BL45E-0000ex-93 for forces-protocol@ietf.org; Tue, 04 May 2004 13:51:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL44G-0000Z4-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:50: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 1BL43g-0000SR-00 for forces-protocol@ietf.org; Tue, 04 May 2004 13:50:20 -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 i44Hntdb020212; Tue, 4 May 2004 17:49:55 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 i44HnrlZ014691; Tue, 4 May 2004 17:50: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 M2004050410493817228 ; Tue, 04 May 2004 10:49:38 -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, 4 May 2004 10:49: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EDD649C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQxyiPllISlVih+R9K7EJZpLPeGtwANRMhA From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 04 May 2004 17:49:38.0189 (UTC) FILETIME=[2B597BD0:01C43200] 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, 4 May 2004 10:49: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 Weiming, Thanks for volunteering ! -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Seems we begin to discuss how the writing task is to be assigned. Hornestly, my team ( I and Ligang) more prefer to take the task of protocol msg and common header writhing, because we think we may be more fit for sth more technique instead of beautiful literature oriented. Actually protocol msg is a big task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3) for draft starter writing. [HK] I have already been putting a lot of time into the Protocol Messages and would like to continue with this work. I will be happy to work with you if you think this cant be done by a single individual. BTW, there are more than 6 messages for the protocol...have you seen the emails sent by Jamal on this ?? I'll send out a summary on this topic. On the Common Header, I would like to suggest working together with Jamal, if he has the time. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 14:50:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20404 for ; Tue, 4 May 2004 14:50: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 1BL4qZ-0002qv-5C for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:40:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Iepon010961 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4mi-0001IY-11 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:36: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 OAA19183 for ; Tue, 4 May 2004 14:36: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 1BL4mf-0005sR-CZ for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:36:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4lf-0005iG-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:35:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4kh-0005ZY-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4dB-0006rt-HW; Tue, 04 May 2004 14: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 1BL4UG-0004OY-DQ for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 14:17: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 OAA17287 for ; Tue, 4 May 2004 14:17:45 -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 1BL4UD-0003Qv-Su for forces-protocol@ietf.org; Tue, 04 May 2004 14:17:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4TF-0003LX-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:16:47 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BL4SR-0003G8-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:15:55 -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 i44IFpH17402; Tue, 4 May 2004 21:15:51 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 21:15:29 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i44IFTbX019122; Tue, 4 May 2004 21:15:29 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LlXKFW; Tue, 04 May 2004 21:15:28 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 i44IFMH07452; Tue, 4 May 2004 21: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); Tue, 4 May 2004 13:14:58 -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_01C43203.B49E84EF" Subject: RE: [Forces-protocol] topic 4c: Common Header Message-ID: Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyArdKKA6rVbitQTSM5UU5NirmaQAAJ8Aw To: , Cc: X-OriginalArrivalTime: 04 May 2004 18:14:58.0878 (UTC) FILETIME=[B5C035E0:01C43203] 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, 4 May 2004 14:14: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.7 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TITLE_EMPTY,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43203.B49E84EF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Robert, =20 Comments are inline. -----Original Message----- From: forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Robert Haas Sent: Tuesday, May 04, 2004 1:49 PM To: Weiming Wang Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header Weiming, and all, Weiming Wang wrote: Hi All, Sorry be off for a few days owing to a holiday in China. Firstly, on the msg direction indicator in the header, I actually = originally have two thoughts for it. One is to define CE id and FE id in a = different space, that is, e.g., using a bit in the space head (mst significent = bit) to mark the different space, another is to put the 1 bit flag along with = the transaction ID, that is, by viewing the ID we then know where the msg is generated. One more advantage for latter approach is it may supply some = extra information for FE or CE to trace the transactions, and may be of some = help to sth like transaction atomicity? Frankly, I can't see how adding a flag in the message to indicate its = direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and FE = to FE ?) adds further information to help tracing transactions. Please = explain. For simplicity I'd rather stick to the usual IP header = semantics with a dst field and a src field. Splitting the ID address space in two equal subspaces (which would be = the case if we choose the MSB of the ID to distinguish among CE and FE = ID) would be an overkill for CE space. I guesstimate the ratio of FEs vs = CEs in an NE to be in the order of 100 to 1000. Who has a proposal how to best split the address space ? [] Instead of splitting in two halves you can reserve a portion = of region for CE and portion for FE. This will make better utlization = of address space. =20 Regards Ramg Regards, -Robert Seems we begin to discuss how the writing task is to be assigned. = Hornestly, my team ( I and Ligang) more prefer to take the task of protocol msg and = common header writhing, because we think we may be more fit for sth more = technique instead of beautiful literature oriented, . Actually protocol msg is a = big task, I just suggest we assign the 6 msgs to two individuals (1st 3, and = last 3) for draft starter writing. For common header, if Jamal is interested, I = would like to have a close co-work with you for this part. I may also write = the definition part, for it seems mostly copy work. I hightly suggest Avri = write the introduction as well as acknowledge and ref, and I also highly = suggest Jamal you write the TML requirement part, because I think you may have a more understanding of this than us (at least me) anyway. I also agree to continue our discussion on the remained issue even when = we have parallelly begun the writing. Sincerely, Weiming ----- Original Message ----- From: =20 HI, On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote: =20 Avri, Glad to have you back! As I said in my previous reply to Jamal, I am fine with this (below) as well. I think any special nos. etc which are needed for addressing can directly be defined by the person writing the section on Common header and we can all review that, once its done. =20 Seems a reasonable approach. =20 Couple of questions... In your previous email, you had sent a .txt file for the draft. Is there also some XML file which we need to use first to write the draft, which later gets converted to a .txt file ? =20 Yes, there is a set of XML files, one for each section, and I can break it down smaller if folks want. I can send those out, but I was waiting for the CVS setup so that they could be started there. And yes, we then put all the xml sections through the xml2rfc tcl script to get the txt output. As I said, I am willing to play the role of assembling the doc from the various xml sections people write, icnluding debugging the xml formatting as needed. Unless someone wants to assign me a section to author, I would prefer to keep myself in a neutral copy-editor role so that I can't be seen as preferring my words over anyone else's. But if there is something that someone wants written I can. I can certainly take care of sections like abstract, maybe an introduction, references, etc. =20 Did you want to post any other thoughts that you have on peer-to-peer model (topic 6), or do you think we already covered this topic in our protocol messages discussion ? =20 I think we are actually subsuming it into the other discussions. In brief, in pure master-slave model, the FE would only respond when requested to do so, with the exception of alarms etc.. As we progress toward a peer-peer model, each of the peers has its role and can initiate a transaction depending on its own needs. As time goes on, and FE hierarchy and FE-FE communications become a reality, then I can envision occasions where the FE would notify the CE of changes in the FE set that are initiated by the FE based on some policy or other. I am also envisioning that there will be cases, though not 'permitted' where an FE will be directly manipulated by some process or operator other then the CE, where the FE will notify the CE of changed state or function. And while this is not currently an item for discussion, I can see the FE as being instrumental in the neighbor discovery process (I tend to divide routing into 3 not 2 sub-processes) a. ps. in terms of timing, I will be spending May in Sweden, so my response times will be skewed by that. _______________________________________________ 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 =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 ------_=_NextPart_001_01C43203.B49E84EF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 Robert,
 
Comments are inline.
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org]On=20 Behalf Of ext Robert Haas
Sent: Tuesday, May 04, 2004 = 1:49=20 PM
To: Weiming Wang
Cc:=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] = topic 4c:=20 Common Header

Weiming, and all,

Weiming = Wang=20 wrote:
Hi All,

Sorry be off  for a few days owing to a holiday in China.

Firstly,  on the msg direction indicator in the header, I actually =
originally
have two thoughts for it.  One is to define CE id and FE id in a =
different
space, that is, e.g., using a bit in the space head (mst significent =
bit) to
mark the different space, another is to  put the 1 bit flag along with =
the
transaction ID, that is, by viewing the ID we then know where the msg is
generated. One more advantage for latter approach is it may supply some =
extra
information for FE or CE to trace the transactions,  and may be of some =
help to
sth like transaction atomicity?
Frankly, I can't see how adding a flag in the message to indicate = its=20 direction (i.e., FE to CE, or CE to FE, and later maybe CE to CE and = FE to FE=20 ?) adds further information to help tracing transactions. Please = explain. For=20 simplicity I'd rather stick to the usual IP header semantics with a = dst field=20 and a src field.

Splitting the ID address space in two equal = subspaces=20 (which would be the case if we choose the MSB of the ID to distinguish = among=20 CE and FE ID) would be an overkill for CE space. I guesstimate the = ratio of=20 FEs vs CEs in an NE to be in the order of 100 to 1000.

Who has = a=20 proposal how to best split the address space ?


[<Ramg>]  Instead of splitting in two halves you = can reserve=20 a portion of region for CE and portion for FE.   This will = make=20 better utlization of address space.
 
Regards
Ramg
  Regards,
-Robert
Seems we begin to discuss how the writing task is to be assigned.  =
Hornestly, my
team ( I and Ligang) more prefer to take the task of protocol msg and =
common
header writhing, because we think we may be more fit for sth more =
technique
instead of beautiful literature oriented, .  Actually protocol msg is a =
big
task, I just suggest we assign the 6 msgs to two individuals (1st 3, and =
last 3)
for draft starter writing.  For common header, if Jamal is interested, I =
would
like to have a close co-work with you for this part.  I may also write =
the
definition part, for it seems mostly copy work. I hightly suggest  Avri =
write
the introduction as well as acknowledge and ref, and I also highly =
suggest Jamal
you write the TML requirement part, because I think you may have a more
understanding of this than us (at least me) anyway.

I also agree to continue our discussion on the remained issue even when =
we have
parallelly begun the writing.

Sincerely,
Weiming

----- Original Message -----
From: <avri@acm.org>

  
HI,

On 4 maj 2004, at 01.04, Khosravi, Hormuzd M wrote:

    
Avri,

Glad to have you back! As I said in my previous reply to Jamal, I am
fine with this (below) as well. I think any special nos. etc which are
needed for addressing can directly be defined by the person writing the
section on Common header and we can all review that, once its done.
      
Seems a reasonable approach.

    
Couple of questions...
In your previous email, you had sent a .txt file for the draft. Is
there
also some XML file which we need to use first to write the draft, which
later gets converted to a .txt file ?
      
Yes, there is a set of XML =
files, one for each section, and I can break
it down smaller if folks want.  I can send those out, but I was waiting
for the CVS setup so that they could be started there.

And yes, we then put all the xml sections through the xml2rfc tcl
script to get the txt output.

As I said, I am willing to play the role of assembling the doc from the
various xml sections people write, icnluding debugging the xml
formatting as needed.

Unless someone wants to assign me a section to author, I would prefer
to keep myself in a neutral copy-editor role so that I can't be seen as
preferring my words over anyone else's. But if there is something that
someone wants written I can.  I can certainly take care of sections
like abstract, maybe an introduction, references, etc.

    
Did you want to post any =
other thoughts that you have on peer-to-peer
model (topic 6), or do you think we already covered this topic in our
protocol messages discussion ?
      
I think we are actually =
subsuming it into the other discussions.  In
brief, in pure master-slave model, the FE would only respond when
requested to do so, with the exception of alarms etc..  As we progress
toward a peer-peer model, each of the peers has its role and can
initiate a transaction depending on its own needs.

As time goes on, and FE hierarchy and FE-FE communications become a
reality, then I can envision occasions where the FE would notify the CE
of changes in the FE set that are initiated by the FE based on some
policy or other.  I am also envisioning that there will be cases,
though not 'permitted' where an FE will be directly manipulated by some
process or operator other then the CE, where the FE will notify the CE
of changed state or function.  And while this is not currently an item
for discussion, I can see the FE as being instrumental in the neighbor
discovery process (I tend to divide routing into 3 not 2 sub-processes)

a.

ps. in terms of timing, I will be spending May in Sweden, so my
response times will be skewed by that.


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



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


  

--=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
------_=_NextPart_001_01C43203.B49E84EF-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 14:57:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20959 for ; Tue, 4 May 2004 14:57: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 1BL568-0006pB-U4 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:56:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Iuuop026234 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:56:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL52R-000658-Ps for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14: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 OAA20612 for ; Tue, 4 May 2004 14: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 1BL52P-00005h-0x for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:53:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL51H-0007jT-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:51:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL50n-0007cT-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:51:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4sf-00031f-Lw; Tue, 04 May 2004 14: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 1BL4nh-0001ff-Bk for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 14:37: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 OAA19310 for ; Tue, 4 May 2004 14: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 1BL4ne-000611-Ii for forces-protocol@ietf.org; Tue, 04 May 2004 14:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4mn-0005ta-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:36: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 1BL4lz-0005dP-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:36: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 i44IZkdb014735; Tue, 4 May 2004 18:35:47 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 i44IZblr011620; Tue, 4 May 2004 18:35:53 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 M2004050411352726183 ; Tue, 04 May 2004 11:35:27 -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, 4 May 2004 11:35: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] Timeline - we need to start writing sections for the draft soon. Message-ID: <468F3FDA28AA87429AD807992E22D07EE4024A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. Thread-Index: AcQxJruUqHIkfvQxRLisX+MzU5rk/gAK7M+wACLZShAACimqUA== From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 04 May 2004 18:35:25.0316 (UTC) FILETIME=[90C3CC40:01C43206] 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, 4 May 2004 11:35: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 Ram, I'll be happy to work with you on Protocol Scenarios section. Thanks for volunteering ! Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Tuesday, May 04, 2004 6:45 AM To: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. Hello All, I would like to volunteer for protocol scenario and Security consideration section. Regards Ramg _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 15:03:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21297 for ; Tue, 4 May 2004 15:03: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 1BL56T-00074A-2f for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IvHBx027158 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:57:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL540-0006ML-VE for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:54: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 OAA20772 for ; Tue, 4 May 2004 14:54: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 1BL53y-0000Lc-5k for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:54:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL52z-0000CK-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:53:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL521-00001l-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:52:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL50P-0005NO-I6; Tue, 04 May 2004 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4qs-0002vI-H4 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 14:41: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 OAA19538 for ; Tue, 4 May 2004 14:41: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 1BL4qp-0006PG-QP for forces-protocol@ietf.org; Tue, 04 May 2004 14:41:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4pi-0006Gd-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:39:59 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL4oz-00066x-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:39:13 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i44IbRuv017417; Tue, 4 May 2004 18:37:28 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i44IdBJ4008563; Tue, 4 May 2004 18:39:11 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 M2004050411383623654 ; Tue, 04 May 2004 11:38:36 -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, 4 May 2004 11:38: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 Message-ID: <468F3FDA28AA87429AD807992E22D07EE40264@orsmsx408.jf.intel.com> Thread-Topic: Conference call ? Thread-Index: AcQxpsKul0TeBGl5Sgqzq4ScP92AnwAXqXnQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 04 May 2004 18:38:36.0614 (UTC) FILETIME=[02C98E60:01C43207] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Conference call ? 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, 4 May 2004 11:38: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 Avri, > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > I am wondering whether there might not be a utility in having a=20 conference call at some point to run through some of the remaining=20 knots. Though we are continents apart, there are time that almost work=20 with the Pacific US early in the AM and China late at night. [HK] I think this is a good idea, to make fast progress. Although, it might be difficult for Weiming with the time difference and English barrier. What do others think ? I remember that Ram had also proposed this in the past. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 15:03:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21314 for ; Tue, 4 May 2004 15:03: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 1BL56T-00074o-Eq for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 14:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IvHHj027191 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 14:57:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL54C-0006Mf-0F for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:54: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 OAA20790 for ; Tue, 4 May 2004 14:54: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 1BL549-0000NJ-6p for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:54:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL53N-0000Fp-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:54:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL52Z-00007K-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 14:53:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL50R-0005Oo-Na; Tue, 04 May 2004 14:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4sV-000303-Vr for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 14:42: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 OAA19694 for ; Tue, 4 May 2004 14:42: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 1BL4sT-0006dH-8c for forces-protocol@ietf.org; Tue, 04 May 2004 14:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4rN-0006UX-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:41:42 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL4qN-0006HI-00 for forces-protocol@ietf.org; Tue, 04 May 2004 14:40: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 i44IeaaX014742; Tue, 4 May 2004 18:40:36 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 i44IdBmH013929; Tue, 4 May 2004 18:40: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 M2004050411400427058 ; Tue, 04 May 2004 11:40:04 -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, 4 May 2004 11:40: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 Message-ID: <468F3FDA28AA87429AD807992E22D07EE4026A@orsmsx408.jf.intel.com> Thread-Topic: Conference call ? Thread-Index: AcQxpsKul0TeBGl5Sgqzq4ScP92AnwAXqXnQAABpL/A= From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 04 May 2004 18:40:04.0771 (UTC) FILETIME=[37553F30:01C43207] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: Conference call ? 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, 4 May 2004 11:40:04 -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, I will be happy to setup a conference call if everyone would like this. -----Original Message----- From: Khosravi, Hormuzd M=20 Avri, > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > I am wondering whether there might not be a utility in having a=20 conference call at some point to run through some of the remaining=20 knots. Though we are continents apart, there are time that almost work=20 with the Pacific US early in the AM and China late at night. [HK] I think this is a good idea, to make fast progress. Although, it might be difficult for Weiming with the time difference and English barrier. What do others think ? I remember that Ram had also proposed this in the past. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 16:29:07 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 QAA27335 for ; Tue, 4 May 2004 16: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 1BL6Ut-000553-JT for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 16:26:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44KQZQ2019530 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 16:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6RQ-00041T-Ta for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 16:23: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 QAA27005 for ; Tue, 4 May 2004 16:22: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 1BL6RP-0002hA-3T for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:22:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6QS-0002a7-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:22:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL6Py-0002TA-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:21:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6Es-0000ZN-W2; Tue, 04 May 2004 16:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL69w-0007P2-B3 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 16:04: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 QAA26111 for ; Tue, 4 May 2004 16:04: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 1BL69u-0000Zs-Ig for forces-protocol@ietf.org; Tue, 04 May 2004 16:04:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL696-0000Tu-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:04:04 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL68b-0000Mo-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:03:33 -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 i44K3UaX000523; Tue, 4 May 2004 20:03:31 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 i44K3MlV001137; Tue, 4 May 2004 20:03:22 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 M2004050413025808511 ; Tue, 04 May 2004 13:02:58 -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, 4 May 2004 13:02: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: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Thread-Index: AcQxJUoY+eqpi1VCRjOR69L5F+fM5AAKbPiAAC4ZpfA= From: "Khosravi, Hormuzd M" To: , Cc: "Weiming Wang" X-OriginalArrivalTime: 04 May 2004 20:02:58.0069 (UTC) FILETIME=[CBA64C50:01C43212] 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, 4 May 2004 13:02: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 All Here is the list of Protocol Messages based on final comments made by Jamal. Association Setup, Setup Resp msg Association Teardown msg Query/Query Resp msg (including Capability query) Config/Config Resp msg Subscribe/Unsubscribe msg State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE, etc) Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) Packet Redirect msg Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > > 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. >=20 > probably same context as subscribe above. A command maybe called > synchronize with a flag to distinguish diffrent things. > We need to show a state machine for a FE joining/leaving. > [HK] I don't like the term SYN or synchronize, since it is used by TCP. > May be we can use names like "Association Setup/teardown" or > "Bind/Unbind" which are more ForCES specific ?=20 setup/connect etc should be fine. I do find SYN confuses a lot of people; TCP seems to have taken a monopoly there ;-> > Let me know which one you > like. Also, I am fine with having a single message such as Association > with a flag to indicate whether it is setup or teardown, although I > think it would be cleaner to have them as separate messages. Either is fine. > Also i mentioned an idea we implemented which was to allow the CE to > send a broadcast SYN messages to reset the FEs. > Even if we dont do it this way, i think we need to have forced restarts. >=20 > [HK] Yes, I agree we need to have forced restarts. I think the > Maintenance message with a command/flag such as FE DOWN would be more > suitable for this. >=20 Put something out and lets discuss it. What you suggest above sounds reasonable. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 16:35: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 QAA27740 for ; Tue, 4 May 2004 16:35: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 1BL6cB-000711-IK for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 16:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44KY7pt026961 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 16:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6X6-0005eG-EM for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 16:28: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 QAA27311 for ; Tue, 4 May 2004 16:28: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 1BL6X4-0003R5-Ke for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:28:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6WA-0003JG-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:27:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL6VG-0003CY-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:26:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6RV-0004Ba-6A; Tue, 04 May 2004 16:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6Il-0001ku-KY for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 16:14: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 QAA26532 for ; Tue, 4 May 2004 16:14: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 1BL6Ij-0001bF-Qg for forces-protocol@ietf.org; Tue, 04 May 2004 16:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6Hu-0001TD-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:13: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 1BL6HD-0001Iy-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:12:27 -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 i44KCOaX006308; Tue, 4 May 2004 20:12: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 i44KA0Sa015098; Tue, 4 May 2004 20:10:01 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 M2004050413114610101 ; Tue, 04 May 2004 13:11: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); Tue, 4 May 2004 13:11: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: <468F3FDA28AA87429AD807992E22D07EE403B9@orsmsx408.jf.intel.com> Thread-Topic: CVS discussion Thread-Index: AcQx415UVKfzig5JS9akWuZ3H/6XvAAMGppg From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 04 May 2004 20:11:46.0486 (UTC) FILETIME=[069C5560:01C43214] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] CVS 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: Tue, 4 May 2004 13:11: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 Avri, Yes I think it will be a good idea to keep the history and a local CVS repository atleast. Jamal, if you could set up a cvs server for all of us, that will be great. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org On 4 maj 2004, at 14.51, Jamal Hadi Salim wrote: > On Tue, 2004-05-04 at 02:56, avri@acm.org wrote: > > >> Yes, there is a set of XML files, one for each section, and I can=20 >> break >> it down smaller if folks want. I can send those out, but I was=20 >> waiting >> for the CVS setup so that they could be started there. > > Is there any point in CVS anymore if you are going to be the central > authority puttin these together. perhaps not. though i will probably use it on my system in any case=20 just to make sure i can keep history. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 16:46:40 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 QAA28284 for ; Tue, 4 May 2004 16:46: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 1BL6mO-0001Pl-Gb for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 16:44:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44KiekA005430 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 16:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6iy-0000e0-Am for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 16:41: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 QAA28017 for ; Tue, 4 May 2004 16:41: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 1BL6iw-0004rp-Ah for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:41:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6hw-0004jg-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:40:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL6hG-0004cN-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 16:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6e5-0007X7-7H; Tue, 04 May 2004 16:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6c0-0006nU-3L for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 16:33: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 QAA27624 for ; Tue, 4 May 2004 16:33: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 1BL6by-000439-1T for forces-protocol@ietf.org; Tue, 04 May 2004 16:33:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6bC-0003xc-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:33:08 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL6ah-0003qv-00 for forces-protocol@ietf.org; Tue, 04 May 2004 16:32:35 -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 i44KWUaX018581; Tue, 4 May 2004 20:32:31 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 i44KVUlx018252; Tue, 4 May 2004 20:32:12 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 M2004050413314813751 ; Tue, 04 May 2004 13:31: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); Tue, 4 May 2004 13:31:48 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43216.D2B0A1C4" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE40424@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQx581hYpLaqCTbQ8S0I3zibZvHZwALkjYg From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: , , "Weiming Wang" X-OriginalArrivalTime: 04 May 2004 20:31:48.0205 (UTC) FILETIME=[D2E419D0:01C43216] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 4 May 2004 13:31: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.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43216.D2B0A1C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 Thanks for the clarification. I like your reasoning. Pls see my comments below. -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com] =20 =20 LFB TypeID: TBD, no consensus on whether it is needed or not in the header =20 I think you somehow need to be able to inspect the message and say clearly who (FE/CE) and what (LFBID) that the message is directed at. If not for any other reason, this is useful for debugging in the field. =20 I would like to be able to run a tcpdump session in a box where all forces messages are mirrored to and debug a race condition for example. My view would be to have this field to have may be one bit to represent =20 direction and the rest of the bits to represent they type of LFB being targetted (set to zero or all 1s if message is not LFB specific) [HK] Robert had pointed out that he would like to use this field to address a message to a group of LFBs in different FEs (multicast based on LFB Type ID). Do you agree with this ? That might be a more compelling reason to me for having this field. I don't say that debugging is not important, but we do have sophisticated tools these days, which can easily look beyond headers into protocol messages these days. =20 (I believe even tcpdump can do this quite easily.) =20 I cant remember what Roberts suggestion was; i know its in the archives, my brain is still slow. I 'll let him explain. [HK] Robert, any comments ?? The idea behind the LFB TypeID is to be able to easily broadcast a message to all instances of a particular LFB class in an NE, without having to address these LFBs individually.=20 For instance, this can be useful if we want to get all interfaces active, or if we want to update a route in all FEs. It greatly simplifies the use of the PL as one can start downloading routes to the FEs without even knowing the ID of the FEs or of the LFBs. Can call this a "plug-and-play" feature, which is invaluable from a user's perspective. More precisely, I see the following three cases of interest (with increasing scope): dest ID: FE x, LFBType: y addresses all LFBs of type y in FE x dest ID: group FE z, LFBType: y addresses all LFBS of type y in the group z of FEs. dest ID: FE broadcast, LFBType: y addresses all LFBS of type y in all FEs in the NE. [HK] I like this use of the LFB Type ID, this is a good reason for having it in the common header. We had proposed a different approach for addressing LFBs of same type, but this is also fine. =20 regards Hormuzd=20 ------_=_NextPart_001_01C43216.D2B0A1C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Robert,
 
Thanks=20 for the clarification. I like your reasoning. Pls see my comments=20 below.
-----Original = Message-----
From: Robert=20 Haas [mailto:rha@zurich.ibm.com]   
 
 LFB TypeID: TBD, no consensus = on whether=20 it is needed or not in the
header
      = 
I think you somehow need to =
be able to inspect the message and say
clearly who (FE/CE) and what (LFBID) that the message is directed at.
If not for any other reason, this is useful for debugging in the   field.   
I would like to be able to run a =
tcpdump session in a box where all
forces messages are mirrored to and debug a race condition for example.   
My view would be to have this field to =
have may be one bit to  =
 represent  
direction and the rest =
of the bits to represent they type of LFB being
targetted (set to zero or all 1s if message is not LFB specific)

[HK] Robert had pointed out that he would like to use this field to
address a message to a group of LFBs in different FEs (multicast based
on LFB Type ID). Do you agree with this ? That might be a more
compelling reason to me for having this field. I don't say that
debugging is not important, but we do have sophisticated tools these
days, which can easily look beyond headers into protocol messages =
these   days.  
(I believe even tcpdump can do this =
quite easily.)    

I cant remember what Roberts suggestion was; i know its in the archives,
my brain is still slow. I 'll let him explain.
[HK] Robert, any comments ??

The idea behind the LFB TypeID is to be able to easily = broadcast a=20 message to all instances of a particular LFB class in an NE, without = having to=20 address these LFBs individually.

For instance, this can be = useful if=20 we want to get all interfaces active, or if we want to update a route = in all=20 FEs.

It greatly simplifies the use of the PL as one can start=20 downloading routes to the FEs without even knowing the ID of the FEs = or of the=20 LFBs. Can call this a "plug-and-play" feature, which is invaluable = from a=20 user's perspective.

More precisely, I see the following three = cases of=20 interest (with increasing scope):

dest ID: FE=20 = x,            = ;  =20 LFBType: y     addresses all LFBs of type y in FE x
dest = ID:=20 group FE z,     LFBType: y     = addresses all LFBS of type y in the group z of FEs.
dest ID: FE = broadcast,=20 LFBType: y     addresses all LFBS of type y in all = FEs in=20 the NE.

 [HK] I like this use of the LFB Type ID, this is a = good=20 reason for having it in the common header. We had proposed a = different approach for addressing LFBs of same type, but = this is=20 also fine.
 
regards
Hormuzd 
------_=_NextPart_001_01C43216.D2B0A1C4-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 17:52: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 RAA01508 for ; Tue, 4 May 2004 17:52: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 1BL7og-0002Mm-Ju for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 17:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Lp6C5009091 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 17:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7mZ-0001bW-NW for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 17:48: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 RAA01367 for ; Tue, 4 May 2004 17:48: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 1BL7mX-00056p-4K for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:48:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL7lc-00050j-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:47:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL7kr-0004un-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:47:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7hq-0000ZL-Ni; Tue, 04 May 2004 17:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7a7-0006hf-HA for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 17:36: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 RAA00833 for ; Tue, 4 May 2004 17: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 1BL7a4-0003hh-W0 for forces-protocol@ietf.org; Tue, 04 May 2004 17:36:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL7ZF-0003ax-00 for forces-protocol@ietf.org; Tue, 04 May 2004 17:35:09 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL7Yd-0003Qn-00 for forces-protocol@ietf.org; Tue, 04 May 2004 17:34:31 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i44LWluv000597; Tue, 4 May 2004 21:32:47 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i44LY7JI001412; Tue, 4 May 2004 21:34:31 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 M2004050414335618994 ; Tue, 04 May 2004 14:33: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, 4 May 2004 14:33: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE4056F@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQx2raX9Gq/ZoNXQgmE4zpyaQ1TWgAOrtvw From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 04 May 2004 21:33:56.0572 (UTC) FILETIME=[812BC1C0:01C4321F] 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, 4 May 2004 14:33: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, Weiming, -----Original Message----- Something else we havent talked about in the header. The response part. I see two types of responses (gaian based on netlink2 experience): 1) Positive reply. This would probably be the same message as the config with ACK flag turned on. 2) Negative reply In our case we had a speacial command for this. It contained the result code and the old header cutnpasted back so you can identify which message has an error. I think we need to have both types of responses allowed. I noticed a few other protocols are defining this sort of responses lately. [Weiming]I agree. Actually we need to discuss the ACK msg now. Hornestly, I'm now with a little confusion between the 'ACK' and the 'response', their definitions, scope,and differences. [HK] Let me try to clarify this question about ACK vs Response. I thought we had already discussed and closed on this before (for common header in Protocol Analysis team), but may be I am wrong. Anyways we need an Ack or Response for almost all messages (except control packet Redirect msgs & Events/HBs) to meet the timeliness requirement specified in the Requirements rfc. So we don't really need an ACK Flag in the header as I see it. The difference between an ACK msg and Response msg in my mind is that, an ACK only provides an acknowledgement from the receiver, that it received the message that was sent to it. A Response msg provides bit more information e.g. if a Config was sent by the CE to FE, the Config Resp msg says whether Config was successful or not on the FE, if partially successful then which config parameters failed. Another example would be a Query Resp which would give the results of the Query such as some FE or LFB attributes, FE Caps, etc. So to answer your question Jamal, Yes I think we need both kinds of Replies and the Response messages will address both of these replies. Do you agree ? Hope this helps, regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 17:59: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 RAA01782 for ; Tue, 4 May 2004 17:59: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 1BL7pe-0002cv-LH for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 17:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Lq6pc010092 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 17:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7ob-0002Ac-K5 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 17:51: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 RAA01466 for ; Tue, 4 May 2004 17:50: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 1BL7oZ-0005LI-4V for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:50:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL7ne-0005F1-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:50:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL7nJ-000587-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 17:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7im-0000ju-Mx; Tue, 04 May 2004 17: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 1BL7hg-0000VY-DH for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 17:43: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 RAA01228 for ; Tue, 4 May 2004 17:43: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 1BL7hd-0004Y0-Nc for forces-protocol@ietf.org; Tue, 04 May 2004 17:43:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL7gi-0004Se-00 for forces-protocol@ietf.org; Tue, 04 May 2004 17:42:53 -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 1BL7gK-0004Me-00 for forces-protocol@ietf.org; Tue, 04 May 2004 17:42:28 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i44LgT0b024846; Tue, 4 May 2004 21:42:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i44LfbJW006765; Tue, 4 May 2004 21:42:32 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 M2004050414415720518 ; Tue, 04 May 2004 14:41:57 -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, 4 May 2004 14:41: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE4059D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQx82BzMvU+Fo8NT2+VqnH9uRd3/gALEwtw From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 04 May 2004 21:41:57.0607 (UTC) FILETIME=[9FE3DF70:01C43220] 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, 4 May 2004 14:41: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 Weiming, ----- Original Message ----- > > Firstly, on the msg direction indicator in the header, I actually originally > > have two thoughts for it. One is to define CE id and FE id in a different > > space, that is, e.g., using a bit in the space head (mst significent bit) to > > mark the different space, another is to put the 1 bit flag along with the > > transaction ID, that is, by viewing the ID we then know where the msg is > > generated. One more advantage for latter approach is it may supply some extra > > information for FE or CE to trace the transactions, and may be of some help to > > sth like transaction atomicity? > > > > I am worried of making this too complex. Is this how GRMP did it? [Weiming]Maybe it has very little to do with atomicity (after I read Netlink2 again). Actually it was very important in GRMP because GRMP used it as a signal to indicate if it is a ACK or Response message. GRMP defined the ACK and Response msgs that they had the same transaction ID as the msg they responsed. Speaking of this, I agree with you that we need to see the transaction definition more carefully. For instance, we need to decide what does one trasaction (with same tran. ID) mean? Can we treat a config msg and its response msg as in the same transaction? How about ACK msg then? (may have two ACKs here, ACK to config msg and ACK to config response msg) My idea more tends to treat all them as in one transaction therefore they all have the same tran.ID. [HK] I agree. The Transaction ID or Sequence No. should be the same in both Request and Response msgs e.g. Config/Config Resp to denote that they are part of the same transaction. That was the reason for having a Sequence no to begin with. Pls see my other email for clarification on Ack/Resp msg. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 20:31: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 UAA10430 for ; Tue, 4 May 2004 20:31: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 1BLAIR-0006O0-MF for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 20:29:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i450Tx2k024544 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 20:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA9s-0004JP-Tb for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 20:21: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 UAA09957 for ; Tue, 4 May 2004 20:21: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 1BLA9q-0000WO-OQ for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLA8s-0000Ni-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:20:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLA81-0000GH-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:19:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA05-0001rb-9P; Tue, 04 May 2004 20: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 1BL9uN-0000NY-5t for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 20:05: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 UAA09364 for ; Tue, 4 May 2004 20:05: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 1BL9uL-0006JD-0f for forces-protocol@ietf.org; Tue, 04 May 2004 20:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL9tR-0006AY-00 for forces-protocol@ietf.org; Tue, 04 May 2004 20:04:09 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL9sZ-0005vc-00 for forces-protocol@ietf.org; Tue, 04 May 2004 20:03:15 -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 i4503CaX005735; Wed, 5 May 2004 00:03:12 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 i4501nm5008240; Wed, 5 May 2004 00:03:01 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 M2004050417021216696 ; Tue, 04 May 2004 17:02:14 -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, 4 May 2004 17:01:41 -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: <468F3FDA28AA87429AD807992E22D07EE40856@orsmsx408.jf.intel.com> Thread-Topic: remaining topics of discussion Thread-Index: AcQx3D3P0AGDb3irTGGUvCe/bHONLQAV6x2g From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 05 May 2004 00:01:41.0365 (UTC) FILETIME=[24FFD250:01C43234] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] remaining topics of 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: Tue, 4 May 2004 17:01: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 Jamal, I am fine with this list. I'll send out some text to address # 4 below. Feel free to send text on any of these topics. Thanks Hormuzd -----Original Message----- The topicas as i see it: 1) It seems to me that the header discussion needs to be completed. I have raised a few points that need to be addressed in relation to the header: - atomicty, transaction definition, windowing, batching, types of replies, configs from FE->CE 2) peering model - discussion active 3) FEM/CEM - missing from your list 4) I would like to add a new one here: message body format. Clearing these i think should get us going on the text. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 20:34: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 UAA10594 for ; Tue, 4 May 2004 20:34: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 1BLAJa-0006fj-P2 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 20:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i450VAle025642 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 20: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 1BLACd-0004ro-Eq for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 20:23: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 UAA10078 for ; Tue, 4 May 2004 20:23: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 1BLACb-0000t7-Bv for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:23:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLABj-0000mQ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:23:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLAAw-0000fk-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 20:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA8p-00042M-LS; Tue, 04 May 2004 20:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA15-00029A-2k for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 20:12: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 UAA09672 for ; Tue, 4 May 2004 20:12: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 1BLA12-0007D4-Rf for forces-protocol@ietf.org; Tue, 04 May 2004 20:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLA0D-00075R-00 for forces-protocol@ietf.org; Tue, 04 May 2004 20:11:09 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BL9zY-0006w4-00 for forces-protocol@ietf.org; Tue, 04 May 2004 20:10:28 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i4509wMp016829 for ; Wed, 5 May 2004 00:09:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i4509BJ4032528 for ; Wed, 5 May 2004 00:09:11 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 M2004050417083609183 for ; Tue, 04 May 2004 17:08:36 -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, 4 May 2004 17:08: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 Message-ID: <468F3FDA28AA87429AD807992E22D07EE4086C@orsmsx408.jf.intel.com> Thread-Topic: draft text - summary of volunteers Thread-Index: AcQx3VLGid4GPZZ9T2i/8IuCQuX3+AAVufqA From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 05 May 2004 00:08:36.0730 (UTC) FILETIME=[1C937DA0:01C43235] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: draft text - summary of volunteers 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, 4 May 2004 17:08: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 All Based on the volunteers so far here is a list of draft sections and volunteers for writing it. Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang (Jamal/Robert ?) 6. Protocol Messages - Hormuzd, Weiming ? 7. Protocol Scenarios - Hormuzd, Ram 8. Security Considerations - Ram 9. References - Avri 10. Acknowledgments - All Appendix A. Implementation Notes - All? Let me know if I missed out anyone. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 22:46: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 WAA16570 for ; Tue, 4 May 2004 22:46: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 1BLCPe-0005cL-9k for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 22:45:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i452jYXn021594 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 22:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCNG-0005BU-9I for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 22:43: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 WAA16469 for ; Tue, 4 May 2004 22:43: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 1BLCNC-0004Ww-TN for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:43:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCMJ-0004PV-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:42:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCLV-0004IC-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:41:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCJK-00041r-6l; Tue, 04 May 2004 22:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCHX-0003QM-Gi for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 22:37: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 WAA16247 for ; Tue, 4 May 2004 22:37: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 1BLCHT-0003l0-NL for forces-protocol@ietf.org; Tue, 04 May 2004 22:37:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCGU-0003cf-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:36:07 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLCFe-0003Nv-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:35:14 -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 i452Yvdb008878; Wed, 5 May 2004 02:34:58 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 i452Yllj029464; Wed, 5 May 2004 02:35: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 M2004050419344000942 ; Tue, 04 May 2004 19:34:40 -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, 4 May 2004 19:34: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: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE408E9@orsmsx408.jf.intel.com> Thread-Topic: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQx2iv6KnvHgT84T2m3oYh3e5MYYgAbot4A From: "Khosravi, Hormuzd M" To: , Cc: X-OriginalArrivalTime: 05 May 2004 02:34:40.0115 (UTC) FILETIME=[83F5EC30:01C43249] 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, 4 May 2004 19:34: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 Avri, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > And while this is not currently an item=20 > for discussion, I can see the FE as being instrumental in the neighbor > discovery process (I tend to divide routing into 3 not 2 sub-processes) Can you explain a little more on this? [HK] Avri, are you talking about Distributed routing or distributed control plane in terms offloading some of the routing protocol functionality such as neighbor discovery (e.g. OSPF Hello offload) onto FEs ? If so, I agree with your view and believe we had covered this in the Requirements for the FE Model (Protocol Offload functions support). Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 22:47: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 WAA16620 for ; Tue, 4 May 2004 22:47: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 1BLCPe-0005cn-Kv for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 22:45:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i452jYZg021616 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 22:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCOE-0005Nv-IA for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 22:44: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 WAA16488 for ; Tue, 4 May 2004 22:44: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 1BLCOB-0004eo-9v for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:44:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCNG-0004XQ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:43:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCMr-0004QD-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCLE-0004Wn-Gm; Tue, 04 May 2004 22:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCIS-0003os-73 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 22:38: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 WAA16310 for ; Tue, 4 May 2004 22:38: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 1BLCIO-0003t5-OU for forces-protocol@ietf.org; Tue, 04 May 2004 22:38:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCHZ-0003lk-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:37:14 -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 1BLCGj-0003dh-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:36: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 2004050419400606:6788 ; Tue, 4 May 2004 19:40:06 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE4056F@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE4056F@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083724575.1073.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 05/04/2004 07:40:06 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 07:40:12 PM, Serialize complete at 05/04/2004 07:40:12 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: 04 May 2004 22:36: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 On Tue, 2004-05-04 at 17:33, Khosravi, Hormuzd M wrote: > > [HK] Let me try to clarify this question about ACK vs Response. I > thought we had already discussed and closed on this before (for common > header in Protocol Analysis team), but may be I am wrong. Anyways we > need an Ack or Response for almost all messages (except control packet > Redirect msgs & Events/HBs) to meet the timeliness requirement specified > in the Requirements rfc. So we don't really need an ACK Flag in the > header as I see it. The difference between an ACK msg and Response msg > in my mind is that, an ACK only provides an acknowledgement from the > receiver, that it received the message that was sent to it. A Response > msg provides bit more information e.g. if a Config was sent by the CE to > FE, the Config Resp msg says whether Config was successful or not on the > FE, if partially successful then which config parameters failed. Another > example would be a Query Resp which would give the results of the Query > such as some FE or LFB attributes, FE Caps, etc. So to answer your > question Jamal, Yes I think we need both kinds of Replies and the > Response messages will address both of these replies. Do you agree ? I will have to wait and see what the response message looks like. To me theres no ambiguity in the desire to have responses when things go wrong or right. There will also be times when i wont be interested in the response (and this is not just in the case of events). You can call it big spoon(ACK/NACK) or spade(positive/neg reply) as long as it ends delivering the above functionality. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 22:55: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 WAA16821 for ; Tue, 4 May 2004 22:55: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 1BLCVw-000711-3H for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 22:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i452q4Oh026962 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 22:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCT6-0006PD-CV for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 22:49: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 WAA16708 for ; Tue, 4 May 2004 22:49: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 1BLCT2-0005K9-W1 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:49:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCSE-0005Cj-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:48:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCRe-00054u-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:47:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCQ3-0005dC-E3; Tue, 04 May 2004 22:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCNF-0005BK-DQ for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 22:43: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 WAA16466 for ; Tue, 4 May 2004 22:43: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 1BLCNB-0004Wo-WA for forces-protocol@ietf.org; Tue, 04 May 2004 22:43:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCMD-0004Op-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:42:02 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLCLK-0004Gy-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:41:07 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 5 May 2004 10:53:44 +0800 Message-ID: <06b001c43249$e6e427d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , "Jamal Hadi Salim" , References: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> <4097D81C.1030503@zurich.ibm.com> Subject: Re: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. 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, 5 May 2004 10:37:25 +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 Robert, and Jamal, It's my and I think also Ligang's great pleasure to work together with you. Note that I just want to be one of the worker in the continent after Jamal discovered it and have actually begun to develop it. Maybe I can do more labour work for it, if possible. Cheers, Weiming ----- Original Message ----- From: "Robert Haas" > Hormuzd, Weiming, > I volunteer for the Addressing subsection. It could fit in Section 5 > Common Header, for which Weiming volunteered as well (and this will be a > big section), or should Addressing be a section of its own ? Sorry to > jump in so late on the draft outline. > > Regards, > -Robert > > Khosravi, Hormuzd M wrote: > > >Hi All > > > >Here is the timeline that we had proposed to the Chairs at the start of > >this team. > > > >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 > > discussion of major issues > > b. Distribute sections for individual writing > >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 > > > >I think we have completed discussion on most topics (2.a.), and should > >be wrapping up with this by end of this week at the latest (May 7th). So > >we need to start thinking about writing the different Sections in the > >draft, that's our next task. I will volunteer to write the section on > >Protocol Messages, Protocol Scenarios and any other sections that are > >not taken by anyone. > >Any other volunteers ?? We need to get the first rev out by May 21st. > > > >Here is the outline for the draft for your reference, > > > >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 > > > >Note: We will have 10 days to review and send comments on the sections > >once they are written in the initial draft. > > > >Thanks > >Hormuzd > > > >_______________________________________________ > >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 > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 22:58: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 WAA16928 for ; Tue, 4 May 2004 22:58: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 1BLCaz-0008Ir-78 for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 22:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i452vHNx031911 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 22:57:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCX0-0007Ac-4v for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 22:53: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 WAA16794 for ; Tue, 4 May 2004 22:53: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 1BLCWw-0005p5-Ml for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:53:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCW2-0005hh-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:52:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCVn-0005Zw-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 22:51:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCR2-0005sz-MY; Tue, 04 May 2004 22:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCPG-0005bg-CZ for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 22:45: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 WAA16536 for ; Tue, 4 May 2004 22:45: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 1BLCPC-0004n3-QG for forces-protocol@ietf.org; Tue, 04 May 2004 22:45:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCOG-0004fW-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:44: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 1BLCNs-0004Y0-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:43:44 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050419473367:6794 ; Tue, 4 May 2004 19:47:33 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE4059D@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE4059D@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083725023.1073.43.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 05/04/2004 07:47:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 07:47:35 PM, Serialize complete at 05/04/2004 07:47: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: 04 May 2004 22:43:43 -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-05-04 at 17:41, Khosravi, Hormuzd M wrote: > [HK] I agree. The Transaction ID or Sequence No. should be the same in > both Request and Response msgs e.g. Config/Config Resp to denote that > they are part of the same transaction. That was the reason for having a > Sequence no to begin with. If you call that 32 bit value a transaction # it may be a little misleading; example a transaction may take several messages not just one (Consider a two phase commit transaction where you send several messages followed by a commit to complete the transaction). I think we should define it as a message sequence. Next big question (I asked this earlier) how many PL level messages can we have in flight? If more than one, do we need a windowing syntax in the common 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 May 4 23:21: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 XAA17888 for ; Tue, 4 May 2004 23:21: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 1BLCru-0004KG-7g for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:14:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453Ekv5016624 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCqO-0003ye-80 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:13: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 XAA17517 for ; Tue, 4 May 2004 23:13: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 1BLCqM-0000no-DF for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCpY-0000fJ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:12:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCov-0000X0-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCiW-0001aD-FY; Tue, 04 May 2004 23: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 1BLCdk-0000U2-3T for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:00: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 XAA17005 for ; Tue, 4 May 2004 23:00: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 1BLCdg-0006nz-HU for forces-protocol@ietf.org; Tue, 04 May 2004 23:00:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCcg-0006eD-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:59:02 -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 1BLCbf-0006OI-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:57:59 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050420014802:6803 ; Tue, 4 May 2004 20:01:48 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header - Atomicit From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <019401c431ef$c8b0a0e0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> <1083676628.1040.132.camel@jzny.localdomain> <019401c431ef$c8b0a0e0$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1083725877.1072.75.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 05/04/2004 08:01:48 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 08:01:50 PM, Serialize complete at 05/04/2004 08:01: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: 04 May 2004 22:57:57 -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-05-04 at 11:52, Weiming Wang wrote: > [Weiming]As well as above, we took an 'I'flag and a 'submsg number' field (as > GSMP) in the message header for msg fragments. This 'I' flag is quite the same > as the '_MULTI' flag in Netlink2. The 'submsg number' may be useful for some > transport layer that does not provide reordering back. Can we assume the TML will take care of ordering as well as fragmentation issues? I think the idea of "more messages coming" is useful per transaction - so i am not against it - but a single bit flag should do it or maybe two: Start of Transaction (SoT) and End of Transaction (EoT) to steal from DMA view of the world with SOP and EOP. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:22: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 XAA17935 for ; Tue, 4 May 2004 23:22: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 1BLCxj-0005UF-JX for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:20:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453Kli7021087 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:20:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCrS-0004GC-Js for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:14: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 XAA17581 for ; Tue, 4 May 2004 23:14: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 1BLCrQ-0000xu-FU for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:14:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCqV-0000pC-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:13:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCpu-0000gC-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:12:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCjS-0001fa-93; Tue, 04 May 2004 23:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCep-0000hb-Ry for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:01: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 XAA17065 for ; Tue, 4 May 2004 23: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 1BLCem-0006yu-8U for forces-protocol@ietf.org; Tue, 04 May 2004 23:01:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCdv-0006q1-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:00:20 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLCdK-0006gx-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:59:43 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 5 May 2004 11:12:18 +0800 Message-ID: <06ec01c4324c$7e45bf60$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07EDD5E5B@orsmsx408.jf.intel.com> <23EAB7FC-9D98-11D8-ACC9-000393CC2112@acm.org> <020c01c431c9$0d078280$020aa8c0@wwm1> <4097D77C.3080908@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E9_01C4328F.8C5131A0" 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, 5 May 2004 10:55:58 +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,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_06E9_01C4328F.8C5131A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Um9ib2VydCwNCg0KUGxzIHNlZSBjb21tZW50cyBpbmxpbmUuDQogIC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQogIEZyb206IFJvYmVydCBIYWFzIA0KICBUbzogV2VpbWluZyBXYW5nIA0K ICBDYzogZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBTZW50OiBXZWRuZXNkYXksIE1heSAw NSwgMjAwNCAxOjQ4IEFNDQogIFN1YmplY3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSB0b3BpYyA0 YzogQ29tbW9uIEhlYWRlcg0KDQoNCiAgV2VpbWluZywgYW5kIGFsbCwNCg0KICBXZWltaW5nIFdh bmcgd3JvdGU6DQoNCkhpIEFsbCwNCg0KU29ycnkgYmUgb2ZmICBmb3IgYSBmZXcgZGF5cyBvd2lu ZyB0byBhIGhvbGlkYXkgaW4gQ2hpbmEuDQoNCkZpcnN0bHksICBvbiB0aGUgbXNnIGRpcmVjdGlv biBpbmRpY2F0b3IgaW4gdGhlIGhlYWRlciwgSSBhY3R1YWxseSBvcmlnaW5hbGx5DQpoYXZlIHR3 byB0aG91Z2h0cyBmb3IgaXQuICBPbmUgaXMgdG8gZGVmaW5lIENFIGlkIGFuZCBGRSBpZCBpbiBh IGRpZmZlcmVudA0Kc3BhY2UsIHRoYXQgaXMsIGUuZy4sIHVzaW5nIGEgYml0IGluIHRoZSBzcGFj ZSBoZWFkIChtc3Qgc2lnbmlmaWNlbnQgYml0KSB0bw0KbWFyayB0aGUgZGlmZmVyZW50IHNwYWNl LCBhbm90aGVyIGlzIHRvICBwdXQgdGhlIDEgYml0IGZsYWcgYWxvbmcgd2l0aCB0aGUNCnRyYW5z YWN0aW9uIElELCB0aGF0IGlzLCBieSB2aWV3aW5nIHRoZSBJRCB3ZSB0aGVuIGtub3cgd2hlcmUg dGhlIG1zZyBpcw0KZ2VuZXJhdGVkLiBPbmUgbW9yZSBhZHZhbnRhZ2UgZm9yIGxhdHRlciBhcHBy b2FjaCBpcyBpdCBtYXkgc3VwcGx5IHNvbWUgZXh0cmENCmluZm9ybWF0aW9uIGZvciBGRSBvciBD RSB0byB0cmFjZSB0aGUgdHJhbnNhY3Rpb25zLCAgYW5kIG1heSBiZSBvZiBzb21lIGhlbHAgdG8N CnN0aCBsaWtlIHRyYW5zYWN0aW9uIGF0b21pY2l0eT8NCiAgRnJhbmtseSwgSSBjYW4ndCBzZWUg aG93IGFkZGluZyBhIGZsYWcgaW4gdGhlIG1lc3NhZ2UgdG8gaW5kaWNhdGUgaXRzIGRpcmVjdGlv biAoaS5lLiwgRkUgdG8gQ0UsIG9yIENFIHRvIEZFLCBhbmQgbGF0ZXIgbWF5YmUgQ0UgdG8gQ0Ug YW5kIEZFIHRvIEZFID8pIGFkZHMgZnVydGhlciBpbmZvcm1hdGlvbiB0byBoZWxwIHRyYWNpbmcg dHJhbnNhY3Rpb25zLiBQbGVhc2UgZXhwbGFpbi4gRm9yIHNpbXBsaWNpdHkgSSdkIHJhdGhlciBz dGljayB0byB0aGUgdXN1YWwgSVAgaGVhZGVyIHNlbWFudGljcyB3aXRoIGEgZHN0IGZpZWxkIGFu ZCBhIHNyYyBmaWVsZC4NCg0KICBbV2VpbWluZ10gQWN0dWFsbHksIHR3byBpdGVtcyBpbiBteSB0 aG91Z2h0cy4gT25lIGlzIGZvciBhZGRyZXNzIHNwYWNpbmcgZm9yIFNyY0lEIGFuZCBEc3RJRCwg dGhlIG90aGVyIGlzIGZvciB0cmFuc2FjdGlvbiBJRC4gSSBhZ3JlZSB0aGUgZm9ybWVyIGhhcyBs aXR0bGUgdG8gZG8gd2l0aCB0cmFuc2FjdGlvbiB0cmFjaW5nLCB0aGUgbGF0dGVyIG1heSBoYXZl LiBKdXN0IGFzIEkgbWVudGlvbmVkIGluIG15IGVhcmxpZXIgZW1haWwsIGVzcGVjaWFsbHkgd2hl biB3ZSB0cmVhdCBlLmcuIGEgJ2NvbmZpZyAtIHJlc3BvbnNlJyBhcyBvbmUgdHJhbnNhY3Rpb24u IEknbSBub3cgYWxzbyB0cnlpbmcgdG8gY2hlY2sgd2V0aGVyIGEgcmVzcG9uc2UgKG9yIEFDSykg d2lsbCBoYXZlIGFtYmlndW91cyBtZWFuaW5nIG9yIG5vdC4gDQoNCiAgU3BsaXR0aW5nIHRoZSBJ RCBhZGRyZXNzIHNwYWNlIGluIHR3byBlcXVhbCBzdWJzcGFjZXMgKHdoaWNoIHdvdWxkIGJlIHRo ZSBjYXNlIGlmIHdlIGNob29zZSB0aGUgTVNCIG9mIHRoZSBJRCB0byBkaXN0aW5ndWlzaCBhbW9u ZyBDRSBhbmQgRkUgSUQpIHdvdWxkIGJlIGFuIG92ZXJraWxsIGZvciBDRSBzcGFjZS4gSSBndWVz c3RpbWF0ZSB0aGUgcmF0aW8gb2YgRkVzIHZzIENFcyBpbiBhbiBORSB0byBiZSBpbiB0aGUgb3Jk ZXIgb2YgMTAwIHRvIDEwMDAuDQoNCiAgW1dlaW1pbmddIFRvIGVxdWFsbHkgc3BsaXQgdGhlIHNw YWNlIGlzIG9ubHkgb25lIHNjaGVtZS4gSSBkZWZpbml0ZWx5IGFncmVlIHdpdGggeW91IHRvIG1v cmUgZ2VuZXJhbGx5IGFzc2lnbiB0aGUgc3BhY2UsIGp1c3QgbGlrZSBJUCBhZGRyZXNzIGRpZC4g SG93IGFib3V0IGxldCdzIGRvIGl0IHdoZW4gd2UgY29tcG9zZSB0aGUgdGV4dD8NCg0KICBXaG8g aGFzIGEgcHJvcG9zYWwgaG93IHRvIGJlc3Qgc3BsaXQgdGhlIGFkZHJlc3Mgc3BhY2UgPw0KDQog IFJlZ2FyZHMsDQogIC1Sb2JlcnQNCg0KICBDaGVlcnMsDQogIFdlaW1pbmcNCg0KU2VlbXMgd2Ug YmVnaW4gdG8gZGlzY3VzcyBob3cgdGhlIHdyaXRpbmcgdGFzayBpcyB0byBiZSBhc3NpZ25lZC4g IEhvcm5lc3RseSwgbXkNCnRlYW0gKCBJIGFuZCBMaWdhbmcpIG1vcmUgcHJlZmVyIHRvIHRha2Ug dGhlIHRhc2sgb2YgcHJvdG9jb2wgbXNnIGFuZCBjb21tb24NCmhlYWRlciB3cml0aGluZywgYmVj YXVzZSB3ZSB0aGluayB3ZSBtYXkgYmUgbW9yZSBmaXQgZm9yIHN0aCBtb3JlIHRlY2huaXF1ZQ0K aW5zdGVhZCBvZiBiZWF1dGlmdWwgbGl0ZXJhdHVyZSBvcmllbnRlZCwgLiAgQWN0dWFsbHkgcHJv dG9jb2wgbXNnIGlzIGEgYmlnDQp0YXNrLCBJIGp1c3Qgc3VnZ2VzdCB3ZSBhc3NpZ24gdGhlIDYg bXNncyB0byB0d28gaW5kaXZpZHVhbHMgKDFzdCAzLCBhbmQgbGFzdCAzKQ0KZm9yIGRyYWZ0IHN0 YXJ0ZXIgd3JpdGluZy4gIEZvciBjb21tb24gaGVhZGVyLCBpZiBKYW1hbCBpcyBpbnRlcmVzdGVk LCBJIHdvdWxkDQpsaWtlIHRvIGhhdmUgYSBjbG9zZSBjby13b3JrIHdpdGggeW91IGZvciB0aGlz IHBhcnQuICBJIG1heSBhbHNvIHdyaXRlIHRoZQ0KZGVmaW5pdGlvbiBwYXJ0LCBmb3IgaXQgc2Vl bXMgbW9zdGx5IGNvcHkgd29yay4gSSBoaWdodGx5IHN1Z2dlc3QgIEF2cmkgd3JpdGUNCnRoZSBp bnRyb2R1Y3Rpb24gYXMgd2VsbCBhcyBhY2tub3dsZWRnZSBhbmQgcmVmLCBhbmQgSSBhbHNvIGhp Z2hseSBzdWdnZXN0IEphbWFsDQp5b3Ugd3JpdGUgdGhlIFRNTCByZXF1aXJlbWVudCBwYXJ0LCBi ZWNhdXNlIEkgdGhpbmsgeW91IG1heSBoYXZlIGEgbW9yZQ0KdW5kZXJzdGFuZGluZyBvZiB0aGlz IHRoYW4gdXMgKGF0IGxlYXN0IG1lKSBhbnl3YXkuDQoNCkkgYWxzbyBhZ3JlZSB0byBjb250aW51 ZSBvdXIgZGlzY3Vzc2lvbiBvbiB0aGUgcmVtYWluZWQgaXNzdWUgZXZlbiB3aGVuIHdlIGhhdmUN CnBhcmFsbGVsbHkgYmVndW4gdGhlIHdyaXRpbmcuDQoNClNpbmNlcmVseSwNCldlaW1pbmcNCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogPGF2cmlAYWNtLm9yZz4NCg0KICAN CkhJLA0KDQpPbiA0IG1haiAyMDA0LCBhdCAwMS4wNCwgS2hvc3JhdmksIEhvcm11emQgTSB3cm90 ZToNCg0KICAgIA0KQXZyaSwNCg0KR2xhZCB0byBoYXZlIHlvdSBiYWNrISBBcyBJIHNhaWQgaW4g bXkgcHJldmlvdXMgcmVwbHkgdG8gSmFtYWwsIEkgYW0NCmZpbmUgd2l0aCB0aGlzIChiZWxvdykg YXMgd2VsbC4gSSB0aGluayBhbnkgc3BlY2lhbCBub3MuIGV0YyB3aGljaCBhcmUNCm5lZWRlZCBm b3IgYWRkcmVzc2luZyBjYW4gZGlyZWN0bHkgYmUgZGVmaW5lZCBieSB0aGUgcGVyc29uIHdyaXRp bmcgdGhlDQpzZWN0aW9uIG9uIENvbW1vbiBoZWFkZXIgYW5kIHdlIGNhbiBhbGwgcmV2aWV3IHRo YXQsIG9uY2UgaXRzIGRvbmUuDQogICAgICANClNlZW1zIGEgcmVhc29uYWJsZSBhcHByb2FjaC4N Cg0KICAgIA0KQ291cGxlIG9mIHF1ZXN0aW9ucy4uLg0KSW4geW91ciBwcmV2aW91cyBlbWFpbCwg eW91IGhhZCBzZW50IGEgLnR4dCBmaWxlIGZvciB0aGUgZHJhZnQuIElzDQp0aGVyZQ0KYWxzbyBz b21lIFhNTCBmaWxlIHdoaWNoIHdlIG5lZWQgdG8gdXNlIGZpcnN0IHRvIHdyaXRlIHRoZSBkcmFm dCwgd2hpY2gNCmxhdGVyIGdldHMgY29udmVydGVkIHRvIGEgLnR4dCBmaWxlID8NCiAgICAgIA0K WWVzLCB0aGVyZSBpcyBhIHNldCBvZiBYTUwgZmlsZXMsIG9uZSBmb3IgZWFjaCBzZWN0aW9uLCBh bmQgSSBjYW4gYnJlYWsNCml0IGRvd24gc21hbGxlciBpZiBmb2xrcyB3YW50LiAgSSBjYW4gc2Vu ZCB0aG9zZSBvdXQsIGJ1dCBJIHdhcyB3YWl0aW5nDQpmb3IgdGhlIENWUyBzZXR1cCBzbyB0aGF0 IHRoZXkgY291bGQgYmUgc3RhcnRlZCB0aGVyZS4NCg0KQW5kIHllcywgd2UgdGhlbiBwdXQgYWxs IHRoZSB4bWwgc2VjdGlvbnMgdGhyb3VnaCB0aGUgeG1sMnJmYyB0Y2wNCnNjcmlwdCB0byBnZXQg dGhlIHR4dCBvdXRwdXQuDQoNCkFzIEkgc2FpZCwgSSBhbSB3aWxsaW5nIHRvIHBsYXkgdGhlIHJv bGUgb2YgYXNzZW1ibGluZyB0aGUgZG9jIGZyb20gdGhlDQp2YXJpb3VzIHhtbCBzZWN0aW9ucyBw ZW9wbGUgd3JpdGUsIGljbmx1ZGluZyBkZWJ1Z2dpbmcgdGhlIHhtbA0KZm9ybWF0dGluZyBhcyBu ZWVkZWQuDQoNClVubGVzcyBzb21lb25lIHdhbnRzIHRvIGFzc2lnbiBtZSBhIHNlY3Rpb24gdG8g YXV0aG9yLCBJIHdvdWxkIHByZWZlcg0KdG8ga2VlcCBteXNlbGYgaW4gYSBuZXV0cmFsIGNvcHkt ZWRpdG9yIHJvbGUgc28gdGhhdCBJIGNhbid0IGJlIHNlZW4gYXMNCnByZWZlcnJpbmcgbXkgd29y ZHMgb3ZlciBhbnlvbmUgZWxzZSdzLiBCdXQgaWYgdGhlcmUgaXMgc29tZXRoaW5nIHRoYXQNCnNv bWVvbmUgd2FudHMgd3JpdHRlbiBJIGNhbi4gIEkgY2FuIGNlcnRhaW5seSB0YWtlIGNhcmUgb2Yg c2VjdGlvbnMNCmxpa2UgYWJzdHJhY3QsIG1heWJlIGFuIGludHJvZHVjdGlvbiwgcmVmZXJlbmNl cywgZXRjLg0KDQogICAgDQpEaWQgeW91IHdhbnQgdG8gcG9zdCBhbnkgb3RoZXIgdGhvdWdodHMg dGhhdCB5b3UgaGF2ZSBvbiBwZWVyLXRvLXBlZXINCm1vZGVsICh0b3BpYyA2KSwgb3IgZG8geW91 IHRoaW5rIHdlIGFscmVhZHkgY292ZXJlZCB0aGlzIHRvcGljIGluIG91cg0KcHJvdG9jb2wgbWVz c2FnZXMgZGlzY3Vzc2lvbiA/DQogICAgICANCkkgdGhpbmsgd2UgYXJlIGFjdHVhbGx5IHN1YnN1 bWluZyBpdCBpbnRvIHRoZSBvdGhlciBkaXNjdXNzaW9ucy4gIEluDQpicmllZiwgaW4gcHVyZSBt YXN0ZXItc2xhdmUgbW9kZWwsIHRoZSBGRSB3b3VsZCBvbmx5IHJlc3BvbmQgd2hlbg0KcmVxdWVz dGVkIHRvIGRvIHNvLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgYWxhcm1zIGV0Yy4uICBBcyB3ZSBw cm9ncmVzcw0KdG93YXJkIGEgcGVlci1wZWVyIG1vZGVsLCBlYWNoIG9mIHRoZSBwZWVycyBoYXMg aXRzIHJvbGUgYW5kIGNhbg0KaW5pdGlhdGUgYSB0cmFuc2FjdGlvbiBkZXBlbmRpbmcgb24gaXRz IG93biBuZWVkcy4NCg0KQXMgdGltZSBnb2VzIG9uLCBhbmQgRkUgaGllcmFyY2h5IGFuZCBGRS1G RSBjb21tdW5pY2F0aW9ucyBiZWNvbWUgYQ0KcmVhbGl0eSwgdGhlbiBJIGNhbiBlbnZpc2lvbiBv Y2Nhc2lvbnMgd2hlcmUgdGhlIEZFIHdvdWxkIG5vdGlmeSB0aGUgQ0UNCm9mIGNoYW5nZXMgaW4g dGhlIEZFIHNldCB0aGF0IGFyZSBpbml0aWF0ZWQgYnkgdGhlIEZFIGJhc2VkIG9uIHNvbWUNCnBv bGljeSBvciBvdGhlci4gIEkgYW0gYWxzbyBlbnZpc2lvbmluZyB0aGF0IHRoZXJlIHdpbGwgYmUg Y2FzZXMsDQp0aG91Z2ggbm90ICdwZXJtaXR0ZWQnIHdoZXJlIGFuIEZFIHdpbGwgYmUgZGlyZWN0 bHkgbWFuaXB1bGF0ZWQgYnkgc29tZQ0KcHJvY2VzcyBvciBvcGVyYXRvciBvdGhlciB0aGVuIHRo ZSBDRSwgd2hlcmUgdGhlIEZFIHdpbGwgbm90aWZ5IHRoZSBDRQ0Kb2YgY2hhbmdlZCBzdGF0ZSBv ciBmdW5jdGlvbi4gIEFuZCB3aGlsZSB0aGlzIGlzIG5vdCBjdXJyZW50bHkgYW4gaXRlbQ0KZm9y IGRpc2N1c3Npb24sIEkgY2FuIHNlZSB0aGUgRkUgYXMgYmVpbmcgaW5zdHJ1bWVudGFsIGluIHRo ZSBuZWlnaGJvcg0KZGlzY292ZXJ5IHByb2Nlc3MgKEkgdGVuZCB0byBkaXZpZGUgcm91dGluZyBp bnRvIDMgbm90IDIgc3ViLXByb2Nlc3NlcykNCg0KYS4NCg0KcHMuIGluIHRlcm1zIG9mIHRpbWlu ZywgSSB3aWxsIGJlIHNwZW5kaW5nIE1heSBpbiBTd2VkZW4sIHNvIG15DQpyZXNwb25zZSB0aW1l cyB3aWxsIGJlIHNrZXdlZCBieSB0aGF0Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQpGb3Jj ZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ZvcmNlcy1wcm90b2NvbA0KICAgIA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcy1wcm90b2NvbCBtYWlsaW5nIGxpc3QNCkZv cmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZm9yY2VzLXByb3RvY29sDQoNCg0KICANCg0KDQotLSANClJvYmVydCBIYWFzDQpJQk0g WnVyaWNoIFJlc2VhcmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2UgNA0KQ0gtODgwMyBS/HNj aGxpa29uL1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04 NTc4ICBodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGENCg0K ------=_NextPart_000_06E9_01C4328F.8C5131A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+Um9ib2VydCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+UGxzIHNlZSBjb21tZW50cyBpbmxpbmUuPC9GT05UPjwvRElWPg0KPEJMT0NLUVVP VEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4 OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+LS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6 ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwv Qj4gDQogIDxBIHRpdGxlPXJoYUB6dXJpY2guaWJtLmNvbSBocmVmPSJtYWlsdG86cmhhQHp1cmlj aC5pYm0uY29tIj5Sb2JlcnQgSGFhczwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U OiAxMHB0IGFyaWFsIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNu IA0KICBocmVmPSJtYWlsdG86d213YW5nQG1haWwuaHppYy5lZHUuY24iPldlaW1pbmcgV2FuZzwv QT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPkNjOjwvQj4gPEEg dGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Zm9yY2VzLXBy b3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBNYXkg MDUsIDIwMDQgMTo0OCANCiAgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlh bCI+PEI+U3ViamVjdDo8L0I+IFJlOiBbRm9yY2VzLXByb3RvY29sXSB0b3BpYyA0YzogDQogIENv bW1vbiBIZWFkZXI8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+V2VpbWluZywgYW5kIGFsbCw8QlI+ PEJSPldlaW1pbmcgV2FuZyB3cm90ZTo8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMDIwYzAx YzQzMWM5JDBkMDc4MjgwJDAyMGFhOGMwQHd3bTEgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPkhp IEFsbCwNCg0KU29ycnkgYmUgb2ZmICBmb3IgYSBmZXcgZGF5cyBvd2luZyB0byBhIGhvbGlkYXkg aW4gQ2hpbmEuDQoNCkZpcnN0bHksICBvbiB0aGUgbXNnIGRpcmVjdGlvbiBpbmRpY2F0b3IgaW4g dGhlIGhlYWRlciwgSSBhY3R1YWxseSBvcmlnaW5hbGx5DQpoYXZlIHR3byB0aG91Z2h0cyBmb3Ig aXQuICBPbmUgaXMgdG8gZGVmaW5lIENFIGlkIGFuZCBGRSBpZCBpbiBhIGRpZmZlcmVudA0Kc3Bh Y2UsIHRoYXQgaXMsIGUuZy4sIHVzaW5nIGEgYml0IGluIHRoZSBzcGFjZSBoZWFkIChtc3Qgc2ln bmlmaWNlbnQgYml0KSB0bw0KbWFyayB0aGUgZGlmZmVyZW50IHNwYWNlLCBhbm90aGVyIGlzIHRv ICBwdXQgdGhlIDEgYml0IGZsYWcgYWxvbmcgd2l0aCB0aGUNCnRyYW5zYWN0aW9uIElELCB0aGF0 IGlzLCBieSB2aWV3aW5nIHRoZSBJRCB3ZSB0aGVuIGtub3cgd2hlcmUgdGhlIG1zZyBpcw0KZ2Vu ZXJhdGVkLiBPbmUgbW9yZSBhZHZhbnRhZ2UgZm9yIGxhdHRlciBhcHByb2FjaCBpcyBpdCBtYXkg c3VwcGx5IHNvbWUgZXh0cmENCmluZm9ybWF0aW9uIGZvciBGRSBvciBDRSB0byB0cmFjZSB0aGUg dHJhbnNhY3Rpb25zLCAgYW5kIG1heSBiZSBvZiBzb21lIGhlbHAgdG8NCnN0aCBsaWtlIHRyYW5z YWN0aW9uIGF0b21pY2l0eT88L1BSRT48L0JMT0NLUVVPVEU+DQogIDxESVY+RnJhbmtseSwgSSBj YW4ndCBzZWUgaG93IGFkZGluZyBhIGZsYWcgaW4gdGhlIG1lc3NhZ2UgdG8gaW5kaWNhdGUgaXRz IA0KICBkaXJlY3Rpb24gKGkuZS4sIEZFIHRvIENFLCBvciBDRSB0byBGRSwgYW5kIGxhdGVyIG1h eWJlIENFIHRvIENFIGFuZCBGRSB0byBGRSANCiAgPykgYWRkcyBmdXJ0aGVyIGluZm9ybWF0aW9u IHRvIGhlbHAgdHJhY2luZyB0cmFuc2FjdGlvbnMuIFBsZWFzZSBleHBsYWluLiBGb3IgDQogIHNp bXBsaWNpdHkgSSdkIHJhdGhlciBzdGljayB0byB0aGUgdXN1YWwgSVAgaGVhZGVyIHNlbWFudGlj cyB3aXRoIGEgZHN0IGZpZWxkIA0KICBhbmQgYSBzcmMgZmllbGQuPEJSPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5b V2VpbWluZ10gQWN0dWFsbHksIHR3byBpdGVtcyBpbiBteSB0aG91Z2h0cy4gT25lIA0KICBpcyBm b3IgYWRkcmVzcyBzcGFjaW5nIGZvciBTcmNJRCBhbmQgRHN0SUQsIHRoZSBvdGhlciBpcyBmb3Ig dHJhbnNhY3Rpb24gSUQuIEkgDQogIGFncmVlIHRoZSBmb3JtZXIgaGFzIGxpdHRsZSB0byBkbyB3 aXRoIHRyYW5zYWN0aW9uIHRyYWNpbmcsIHRoZSBsYXR0ZXIgbWF5IA0KICBoYXZlLiBKdXN0IGFz IEkgbWVudGlvbmVkIGluIG15IGVhcmxpZXIgZW1haWwsIGVzcGVjaWFsbHkgd2hlbiB3ZSB0cmVh dCBlLmcuIGEgDQogICdjb25maWcgLSByZXNwb25zZScgYXMgb25lIHRyYW5zYWN0aW9uLiBJJ20m bmJzcDtub3cgYWxzbyB0cnlpbmcgDQogIHRvJm5ic3A7Y2hlY2smbmJzcDt3ZXRoZXIgYSByZXNw b25zZSAob3IgQUNLKSB3aWxsIGhhdmUgYW1iaWd1b3VzIG1lYW5pbmcgb3IgDQogIG5vdC4gPC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9O VD48QlI+U3BsaXR0aW5nIHRoZSBJRCBhZGRyZXNzIHNwYWNlIGluIHR3byBlcXVhbCANCiAgc3Vi c3BhY2VzICh3aGljaCB3b3VsZCBiZSB0aGUgY2FzZSBpZiB3ZSBjaG9vc2UgdGhlIE1TQiBvZiB0 aGUgSUQgdG8gDQogIGRpc3Rpbmd1aXNoIGFtb25nIENFIGFuZCBGRSBJRCkgd291bGQgYmUgYW4g b3ZlcmtpbGwgZm9yIENFIHNwYWNlLiBJIA0KICBndWVzc3RpbWF0ZSB0aGUgcmF0aW8gb2YgRkVz IHZzIENFcyBpbiBhbiBORSB0byBiZSBpbiB0aGUgb3JkZXIgb2YgMTAwIHRvIA0KICAxMDAwLjxC Uj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5bV2VpbWluZ10gVG8gZXF1 YWxseSZuYnNwO3NwbGl0IHRoZSBzcGFjZSBpcyBvbmx5IA0KICBvbmUgc2NoZW1lLiBJIGRlZmlu aXRlbHkgYWdyZWUgd2l0aCB5b3UgdG8gbW9yZSBnZW5lcmFsbHkgYXNzaWduIHRoZSBzcGFjZSwg DQogIGp1c3QgbGlrZSBJUCBhZGRyZXNzIGRpZC4gSG93IGFib3V0IGxldCdzIGRvIGl0IHdoZW4g d2UmbmJzcDtjb21wb3NlIHRoZSANCiAgdGV4dD88L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPldobyBoYXMgYSBw cm9wb3NhbCBob3cgdG8gYmVzdCBzcGxpdCB0aGUgYWRkcmVzcyBzcGFjZSANCiAgPzxCUj48QlI+ UmVnYXJkcyw8QlI+LVJvYmVydDxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5DaGVlcnMsPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PldlaW1pbmc8L0ZPTlQ+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMDIwYzAxYzQzMWM5 JDBkMDc4MjgwJDAyMGFhOGMwQHd3bTEgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPg0KU2VlbXMg d2UgYmVnaW4gdG8gZGlzY3VzcyBob3cgdGhlIHdyaXRpbmcgdGFzayBpcyB0byBiZSBhc3NpZ25l ZC4gIEhvcm5lc3RseSwgbXkNCnRlYW0gKCBJIGFuZCBMaWdhbmcpIG1vcmUgcHJlZmVyIHRvIHRh a2UgdGhlIHRhc2sgb2YgcHJvdG9jb2wgbXNnIGFuZCBjb21tb24NCmhlYWRlciB3cml0aGluZywg YmVjYXVzZSB3ZSB0aGluayB3ZSBtYXkgYmUgbW9yZSBmaXQgZm9yIHN0aCBtb3JlIHRlY2huaXF1 ZQ0KaW5zdGVhZCBvZiBiZWF1dGlmdWwgbGl0ZXJhdHVyZSBvcmllbnRlZCwgLiAgQWN0dWFsbHkg cHJvdG9jb2wgbXNnIGlzIGEgYmlnDQp0YXNrLCBJIGp1c3Qgc3VnZ2VzdCB3ZSBhc3NpZ24gdGhl IDYgbXNncyB0byB0d28gaW5kaXZpZHVhbHMgKDFzdCAzLCBhbmQgbGFzdCAzKQ0KZm9yIGRyYWZ0 IHN0YXJ0ZXIgd3JpdGluZy4gIEZvciBjb21tb24gaGVhZGVyLCBpZiBKYW1hbCBpcyBpbnRlcmVz dGVkLCBJIHdvdWxkDQpsaWtlIHRvIGhhdmUgYSBjbG9zZSBjby13b3JrIHdpdGggeW91IGZvciB0 aGlzIHBhcnQuICBJIG1heSBhbHNvIHdyaXRlIHRoZQ0KZGVmaW5pdGlvbiBwYXJ0LCBmb3IgaXQg c2VlbXMgbW9zdGx5IGNvcHkgd29yay4gSSBoaWdodGx5IHN1Z2dlc3QgIEF2cmkgd3JpdGUNCnRo ZSBpbnRyb2R1Y3Rpb24gYXMgd2VsbCBhcyBhY2tub3dsZWRnZSBhbmQgcmVmLCBhbmQgSSBhbHNv IGhpZ2hseSBzdWdnZXN0IEphbWFsDQp5b3Ugd3JpdGUgdGhlIFRNTCByZXF1aXJlbWVudCBwYXJ0 LCBiZWNhdXNlIEkgdGhpbmsgeW91IG1heSBoYXZlIGEgbW9yZQ0KdW5kZXJzdGFuZGluZyBvZiB0 aGlzIHRoYW4gdXMgKGF0IGxlYXN0IG1lKSBhbnl3YXkuDQoNCkkgYWxzbyBhZ3JlZSB0byBjb250 aW51ZSBvdXIgZGlzY3Vzc2lvbiBvbiB0aGUgcmVtYWluZWQgaXNzdWUgZXZlbiB3aGVuIHdlIGhh dmUNCnBhcmFsbGVsbHkgYmVndW4gdGhlIHdyaXRpbmcuDQoNClNpbmNlcmVseSwNCldlaW1pbmcN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogPEEgY2xhc3M9bW96LXR4dC1s aW5rLXJmYzIzOTZFIGhyZWY9Im1haWx0bzphdnJpQGFjbS5vcmciPiZsdDthdnJpQGFjbS5vcmcm Z3Q7PC9BPg0KDQogIDwvUFJFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxQUkUgd3Jh cD0iIj5ISSwNCg0KT24gNCBtYWogMjAwNCwgYXQgMDEuMDQsIEtob3NyYXZpLCBIb3JtdXpkIE0g d3JvdGU6DQoNCiAgICA8L1BSRT4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxQUkUg d3JhcD0iIj5BdnJpLA0KDQpHbGFkIHRvIGhhdmUgeW91IGJhY2shIEFzIEkgc2FpZCBpbiBteSBw cmV2aW91cyByZXBseSB0byBKYW1hbCwgSSBhbQ0KZmluZSB3aXRoIHRoaXMgKGJlbG93KSBhcyB3 ZWxsLiBJIHRoaW5rIGFueSBzcGVjaWFsIG5vcy4gZXRjIHdoaWNoIGFyZQ0KbmVlZGVkIGZvciBh ZGRyZXNzaW5nIGNhbiBkaXJlY3RseSBiZSBkZWZpbmVkIGJ5IHRoZSBwZXJzb24gd3JpdGluZyB0 aGUNCnNlY3Rpb24gb24gQ29tbW9uIGhlYWRlciBhbmQgd2UgY2FuIGFsbCByZXZpZXcgdGhhdCwg b25jZSBpdHMgZG9uZS4NCiAgICAgIDwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+U2Vl bXMgYSByZWFzb25hYmxlIGFwcHJvYWNoLg0KDQogICAgPC9QUkU+DQogICAgICA8QkxPQ0tRVU9U RSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+Q291cGxlIG9mIHF1ZXN0aW9ucy4uLg0KSW4geW91 ciBwcmV2aW91cyBlbWFpbCwgeW91IGhhZCBzZW50IGEgLnR4dCBmaWxlIGZvciB0aGUgZHJhZnQu IElzDQp0aGVyZQ0KYWxzbyBzb21lIFhNTCBmaWxlIHdoaWNoIHdlIG5lZWQgdG8gdXNlIGZpcnN0 IHRvIHdyaXRlIHRoZSBkcmFmdCwgd2hpY2gNCmxhdGVyIGdldHMgY29udmVydGVkIHRvIGEgLnR4 dCBmaWxlID8NCiAgICAgIDwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+WWVzLCB0aGVy ZSBpcyBhIHNldCBvZiBYTUwgZmlsZXMsIG9uZSBmb3IgZWFjaCBzZWN0aW9uLCBhbmQgSSBjYW4g YnJlYWsNCml0IGRvd24gc21hbGxlciBpZiBmb2xrcyB3YW50LiAgSSBjYW4gc2VuZCB0aG9zZSBv dXQsIGJ1dCBJIHdhcyB3YWl0aW5nDQpmb3IgdGhlIENWUyBzZXR1cCBzbyB0aGF0IHRoZXkgY291 bGQgYmUgc3RhcnRlZCB0aGVyZS4NCg0KQW5kIHllcywgd2UgdGhlbiBwdXQgYWxsIHRoZSB4bWwg c2VjdGlvbnMgdGhyb3VnaCB0aGUgeG1sMnJmYyB0Y2wNCnNjcmlwdCB0byBnZXQgdGhlIHR4dCBv dXRwdXQuDQoNCkFzIEkgc2FpZCwgSSBhbSB3aWxsaW5nIHRvIHBsYXkgdGhlIHJvbGUgb2YgYXNz ZW1ibGluZyB0aGUgZG9jIGZyb20gdGhlDQp2YXJpb3VzIHhtbCBzZWN0aW9ucyBwZW9wbGUgd3Jp dGUsIGljbmx1ZGluZyBkZWJ1Z2dpbmcgdGhlIHhtbA0KZm9ybWF0dGluZyBhcyBuZWVkZWQuDQoN ClVubGVzcyBzb21lb25lIHdhbnRzIHRvIGFzc2lnbiBtZSBhIHNlY3Rpb24gdG8gYXV0aG9yLCBJ IHdvdWxkIHByZWZlcg0KdG8ga2VlcCBteXNlbGYgaW4gYSBuZXV0cmFsIGNvcHktZWRpdG9yIHJv bGUgc28gdGhhdCBJIGNhbid0IGJlIHNlZW4gYXMNCnByZWZlcnJpbmcgbXkgd29yZHMgb3ZlciBh bnlvbmUgZWxzZSdzLiBCdXQgaWYgdGhlcmUgaXMgc29tZXRoaW5nIHRoYXQNCnNvbWVvbmUgd2Fu dHMgd3JpdHRlbiBJIGNhbi4gIEkgY2FuIGNlcnRhaW5seSB0YWtlIGNhcmUgb2Ygc2VjdGlvbnMN Cmxpa2UgYWJzdHJhY3QsIG1heWJlIGFuIGludHJvZHVjdGlvbiwgcmVmZXJlbmNlcywgZXRjLg0K DQogICAgPC9QUkU+DQogICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+ RGlkIHlvdSB3YW50IHRvIHBvc3QgYW55IG90aGVyIHRob3VnaHRzIHRoYXQgeW91IGhhdmUgb24g cGVlci10by1wZWVyDQptb2RlbCAodG9waWMgNiksIG9yIGRvIHlvdSB0aGluayB3ZSBhbHJlYWR5 IGNvdmVyZWQgdGhpcyB0b3BpYyBpbiBvdXINCnByb3RvY29sIG1lc3NhZ2VzIGRpc2N1c3Npb24g Pw0KICAgICAgPC9QUkU+PC9CTE9DS1FVT1RFPjxQUkUgd3JhcD0iIj5JIHRoaW5rIHdlIGFyZSBh Y3R1YWxseSBzdWJzdW1pbmcgaXQgaW50byB0aGUgb3RoZXIgZGlzY3Vzc2lvbnMuICBJbg0KYnJp ZWYsIGluIHB1cmUgbWFzdGVyLXNsYXZlIG1vZGVsLCB0aGUgRkUgd291bGQgb25seSByZXNwb25k IHdoZW4NCnJlcXVlc3RlZCB0byBkbyBzbywgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIGFsYXJtcyBl dGMuLiAgQXMgd2UgcHJvZ3Jlc3MNCnRvd2FyZCBhIHBlZXItcGVlciBtb2RlbCwgZWFjaCBvZiB0 aGUgcGVlcnMgaGFzIGl0cyByb2xlIGFuZCBjYW4NCmluaXRpYXRlIGEgdHJhbnNhY3Rpb24gZGVw ZW5kaW5nIG9uIGl0cyBvd24gbmVlZHMuDQoNCkFzIHRpbWUgZ29lcyBvbiwgYW5kIEZFIGhpZXJh cmNoeSBhbmQgRkUtRkUgY29tbXVuaWNhdGlvbnMgYmVjb21lIGENCnJlYWxpdHksIHRoZW4gSSBj YW4gZW52aXNpb24gb2NjYXNpb25zIHdoZXJlIHRoZSBGRSB3b3VsZCBub3RpZnkgdGhlIENFDQpv ZiBjaGFuZ2VzIGluIHRoZSBGRSBzZXQgdGhhdCBhcmUgaW5pdGlhdGVkIGJ5IHRoZSBGRSBiYXNl ZCBvbiBzb21lDQpwb2xpY3kgb3Igb3RoZXIuICBJIGFtIGFsc28gZW52aXNpb25pbmcgdGhhdCB0 aGVyZSB3aWxsIGJlIGNhc2VzLA0KdGhvdWdoIG5vdCAncGVybWl0dGVkJyB3aGVyZSBhbiBGRSB3 aWxsIGJlIGRpcmVjdGx5IG1hbmlwdWxhdGVkIGJ5IHNvbWUNCnByb2Nlc3Mgb3Igb3BlcmF0b3Ig b3RoZXIgdGhlbiB0aGUgQ0UsIHdoZXJlIHRoZSBGRSB3aWxsIG5vdGlmeSB0aGUgQ0UNCm9mIGNo YW5nZWQgc3RhdGUgb3IgZnVuY3Rpb24uICBBbmQgd2hpbGUgdGhpcyBpcyBub3QgY3VycmVudGx5 IGFuIGl0ZW0NCmZvciBkaXNjdXNzaW9uLCBJIGNhbiBzZWUgdGhlIEZFIGFzIGJlaW5nIGluc3Ry dW1lbnRhbCBpbiB0aGUgbmVpZ2hib3INCmRpc2NvdmVyeSBwcm9jZXNzIChJIHRlbmQgdG8gZGl2 aWRlIHJvdXRpbmcgaW50byAzIG5vdCAyIHN1Yi1wcm9jZXNzZXMpDQoNCmEuDQoNCnBzLiBpbiB0 ZXJtcyBvZiB0aW1pbmcsIEkgd2lsbCBiZSBzcGVuZGluZyBNYXkgaW4gU3dlZGVuLCBzbyBteQ0K cmVzcG9uc2UgdGltZXMgd2lsbCBiZSBza2V3ZWQgYnkgdGhhdC4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRm9yY2VzLXByb3RvY29sIG1haWxp bmcgbGlzdA0KPEEgY2xhc3M9bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIGhyZWY9Im1haWx0bzpG b3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPkZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4NCjxB IGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbDwvQT4NCiAgICA8L1BSRT48L0JMT0NLUVVP VEU+PFBSRSB3cmFwPSIiPjwhLS0tLT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPEEgY2xh c3M9bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIGhyZWY9Im1haWx0bzpGb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmciPkZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4NCjxBIGNsYXNzPW1vei10eHQt bGluay1mcmVldGV4dCBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mb3JjZXMtcHJvdG9jb2wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZvcmNlcy1wcm90b2NvbDwvQT4NCg0KDQogIDwvUFJFPjwvQkxPQ0tRVU9URT48QlI+PFBSRSBj bGFzcz1tb3otc2lnbmF0dXJlIGNvbHM9IjcyIj4tLSANClJvYmVydCBIYWFzDQpJQk0gWnVyaWNo IFJlc2VhcmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2UgNA0KQ0gtODgwMyBS/HNjaGxpa29u L1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICA8 QSBjbGFzcz1tb3otdHh0LWxpbmstZnJlZXRleHQgaHJlZj0iaHR0cDovL3d3dy56dXJpY2guaWJt LmNvbS9+cmhhIj5odHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGE8L0E+PC9QUkU+PC9CTE9D S1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_06E9_01C4328F.8C5131A0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:22: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 XAA17975 for ; Tue, 4 May 2004 23:22: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 1BLCxz-0005hs-BX for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453L3xH021931 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23: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 1BLCsD-0004SJ-46 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23: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 XAA17588 for ; Tue, 4 May 2004 23:15: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 1BLCsB-00015V-8k for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:15:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCrC-0000w7-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:14:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCqC-0000hR-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCjW-0001gP-OO; Tue, 04 May 2004 23:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCeq-0000hd-QI for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:01: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 XAA17068 for ; Tue, 4 May 2004 23:01: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 1BLCem-0006yz-Uf for forces-protocol@ietf.org; Tue, 04 May 2004 23:01:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCdw-0006q9-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:00:20 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLCdX-0006gv-00 for forces-protocol@ietf.org; Tue, 04 May 2004 22:59:55 -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 i452xedb018934; Wed, 5 May 2004 02:59: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 i452xWlf006211; Wed, 5 May 2004 02:59:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050419592303302 ; Tue, 04 May 2004 19:59: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); Tue, 4 May 2004 19:59: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE408FD@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQySsx9I9eP4if+RCG8hBMX0OzhigAAP/4g From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 05 May 2004 02:59:23.0280 (UTC) FILETIME=[F7FEF100:01C4324C] 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, 4 May 2004 19:59: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 > [HK] I agree. The Transaction ID or Sequence No. should be the same in > both Request and Response msgs e.g. Config/Config Resp to denote that > they are part of the same transaction. That was the reason for having a > Sequence no to begin with. If you call that 32 bit value a transaction # it may be a little misleading; example a transaction may take several messages not just one (Consider a two phase commit transaction where you send several messages followed by a commit to complete the transaction).=20 I think we should define it as a message sequence.=20 [HK] Sure, I thought we already decided to call it Sequence no. Not sure why Weiming used a different name ? BTW, do you agree with having the same Sequence no in Req/Resp to match them ? I think you do, but just wanted to confirm. Next big question (I asked this earlier) how many PL level messages can we have in flight? If more than one, do we need a windowing syntax in the common header? [HK] We can have more than one PL msg in flight, but I don't think we need any windowing syntax in the common header. This will be provided by the TML layer if needed. We will just use the Sequence no to match the request/response msgs. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:23: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 XAA17993 for ; Tue, 4 May 2004 23:23: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 1BLCy1-0005j3-BS for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453L57l022002 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23: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 1BLCvK-000509-1p for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:18: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 XAA17805 for ; Tue, 4 May 2004 23:18: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 1BLCvI-0001bF-0u for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:18:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCuY-0001SW-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:17:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCtW-0001IJ-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:16:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCrB-0004Bj-Pd; Tue, 04 May 2004 23: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 1BLCky-000217-Ta for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:07: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 XAA17254 for ; Tue, 4 May 2004 23: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 1BLCku-000009-57 for forces-protocol@ietf.org; Tue, 04 May 2004 23:07:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCjv-0007fX-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:06: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 1BLCj8-0007X9-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:05: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 i4535Odb021616; Wed, 5 May 2004 03:05: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 i4535QlX008947; Wed, 5 May 2004 03:05:31 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050420050703980 ; Tue, 04 May 2004 20:05:07 -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, 4 May 2004 20:05: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyScGFU6s3PNlgQyqHtikhiF+QNAAA1o9g From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 05 May 2004 03:05:04.0548 (UTC) FILETIME=[C3684E40:01C4324D] 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, 4 May 2004 20:05: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 Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > [HK] Let me try to clarify this question about ACK vs Response. I > thought we had already discussed and closed on this before (for common > header in Protocol Analysis team), but may be I am wrong. Anyways we > need an Ack or Response for almost all messages (except control packet > Redirect msgs & Events/HBs) to meet the timeliness requirement specified > in the Requirements rfc. So we don't really need an ACK Flag in the > header as I see it. The difference between an ACK msg and Response msg > in my mind is that, an ACK only provides an acknowledgement from the > receiver, that it received the message that was sent to it. A Response > msg provides bit more information e.g. if a Config was sent by the CE to > FE, the Config Resp msg says whether Config was successful or not on the > FE, if partially successful then which config parameters failed. Another > example would be a Query Resp which would give the results of the Query > such as some FE or LFB attributes, FE Caps, etc. So to answer your > question Jamal, Yes I think we need both kinds of Replies and the > Response messages will address both of these replies. Do you agree ? I will have to wait and see what the response message looks like. To me theres no ambiguity in the desire to have responses when things go wrong or right.=20 [Agreed] There will also be times when i wont be interested in the response (and this is not just in the case of events). =20 [HK] Most of the Control Plane Apps such as routing/switching protocols that I have worked with need responses for any commands such as Config or Query msgs. Could you give some examples of what msgs you don't need responses for ? Also, how do we satisfy the timeliness requirement which without protocol level responses or acks ? Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:30: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 XAA18295 for ; Tue, 4 May 2004 23: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 1BLD5K-0007OR-Rx for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:28:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453ScJg028414 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCzy-0006Ch-2b for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:23: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 XAA18011 for ; Tue, 4 May 2004 23:23: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 1BLCzw-0002Gp-66 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:23:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCyx-00027P-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:22:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCxy-0001wb-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23: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 1BLCsB-0004QH-1a; Tue, 04 May 2004 23: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 1BLCqT-0003yk-BQ for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:13: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 XAA17525 for ; Tue, 4 May 2004 23:13: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 1BLCqR-0000oZ-Cr for forces-protocol@ietf.org; Tue, 04 May 2004 23:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCpd-0000fo-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:12:25 -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 1BLCoz-0000X6-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:11:45 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050420153529:6818 ; Tue, 4 May 2004 20:15:35 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE408FD@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE408FD@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083726704.1072.99.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 05/04/2004 08:15:35 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 08:15:36 PM, Serialize complete at 05/04/2004 08:15:36 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: 04 May 2004 23:11:44 -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-05-04 at 22:59, Khosravi, Hormuzd M wrote: > I think we should define it as a message sequence. > > [HK] Sure, I thought we already decided to call it Sequence no. Not sure > why Weiming used a different name ? BTW, do you agree with having the > same Sequence no in Req/Resp to match them ? I think you do, but just > wanted to confirm. Yes i do. > > Next big question (I asked this earlier) how many PL level messages can > we have in flight? If more than one, do we need a windowing syntax in > the common header? > > [HK] We can have more than one PL msg in flight, but I don't think we > need any windowing syntax in the common header. This will be provided by > the TML layer if needed. We will just use the Sequence no to match the > request/response msgs. I thinks its harder than that. Pipeling is known to improve throughput; basically for a given b/width and RTT, you should be able to send in the range of BW*RTT bytes without getting an ACK that the first message you sent. Windowing just keeps track of how many such messages you have delivered to the network. Imagine that given a 10Gige pipe, you can only using 100Mbps. Now i agree that adding windowing complicates things, but theres no way you can pass the pipelining responsibility to the TML. The TML will send as much data as you give it. Batching may be sufficient - dont know. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:35: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 XAA18839 for ; Tue, 4 May 2004 23:35: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 1BLDB0-0008Qw-Hk for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:34:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453YU7x032414 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:34:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLD6y-0007u7-AJ for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:30: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 XAA18330 for ; Tue, 4 May 2004 23:30: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 1BLD6w-0003J2-Ar for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD5r-000394-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:29:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLD5A-000313-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCyv-00067T-L4; Tue, 04 May 2004 23: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 1BLCtX-0004lS-Mf for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:16: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 XAA17715 for ; Tue, 4 May 2004 23:16: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 1BLCtV-0001I8-MH for forces-protocol@ietf.org; Tue, 04 May 2004 23:16:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCsM-00017D-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:15:14 -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 1BLCrs-0000yi-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:14:44 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050420183293:6823 ; Tue, 4 May 2004 20:18:32 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083726882.1070.106.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 05/04/2004 08:18:33 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 08:18:35 PM, Serialize complete at 05/04/2004 08:18: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: 04 May 2004 23:14:42 -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-05-04 at 23:05, Khosravi, Hormuzd M wrote: > There will also be times when i wont be interested in > the response (and this is not just in the case of events). > > [HK] Most of the Control Plane Apps such as routing/switching protocols > that I have worked with need responses for any commands such as Config > or Query msgs. Could you give some examples of what msgs you don't need > responses for ? Also, how do we satisfy the timeliness requirement which > without protocol level responses or acks ? I dont wanna speculate about others - i think the possibilty is certainly there, but a simple example is a PL heartbeat scheme where i can occasionaly request for an ACK. We have used this and found it useful. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:36:03 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 XAA18857 for ; Tue, 4 May 2004 23:36: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 1BLDB0-0008RJ-Sg for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:34:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453YU2l032435 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:34:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLD71-0007uS-3A for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:30: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 XAA18345 for ; Tue, 4 May 2004 23:30: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 1BLD6z-0003JO-6a for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:30:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD5u-00039b-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:29:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLD5U-00031E-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:28:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLD0q-0006F9-Iq; Tue, 04 May 2004 23:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCy5-0005rL-A0 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:21: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 XAA17886 for ; Tue, 4 May 2004 23:21: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 1BLCy3-0001zK-Co for forces-protocol@ietf.org; Tue, 04 May 2004 23:21:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCx6-0001rL-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:20:09 -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 1BLCwJ-0001c5-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:19:19 -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 i453JK0b017905; Wed, 5 May 2004 03:19:20 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 i453J8UI009695; Wed, 5 May 2004 03:19:08 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 M2004050420184723193 ; Tue, 04 May 2004 20:18:47 -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, 4 May 2004 20:18: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE4090E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyTx/H+gaSvfkZRZCgyV0KQuJpTQAACHbA From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 05 May 2004 03:18:47.0945 (UTC) FILETIME=[AE30B790:01C4324F] 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, 4 May 2004 20:18: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 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > There will also be times when i wont be interested in > the response (and this is not just in the case of events). =20 >=20 > [HK] Most of the Control Plane Apps such as routing/switching protocols > that I have worked with need responses for any commands such as Config > or Query msgs. Could you give some examples of what msgs you don't need > responses for ? Also, how do we satisfy the timeliness requirement which > without protocol level responses or acks ? I dont wanna speculate about others - i think the possibilty is certainly there, but a simple example is a PL heartbeat scheme where i can occasionaly request for an ACK. We have used this and found it useful. [HK] Sure, HB is probably a good example and that falls under the category of Event messages for now (as Weiming suggested). Except for HBs, events, packet redirection msgs, the app or CE will need responses for all other msgs. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:46: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 XAA19368 for ; Tue, 4 May 2004 23:46: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 1BLDHL-0002Pu-TO for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453f3n7009286 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDCg-0000tj-78 for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:36: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 XAA18906 for ; Tue, 4 May 2004 23:36: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 1BLDCe-0004Hl-4g for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:36:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDBg-00048H-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:35:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDAw-0003zX-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:34:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLD6h-0007qB-FL; Tue, 04 May 2004 23: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 1BLD4u-0007Mz-9m for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:28: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 XAA18228 for ; Tue, 4 May 2004 23:28: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 1BLD4s-00030S-6P for forces-protocol@ietf.org; Tue, 04 May 2004 23:28:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD3z-0002sP-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:27:16 -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 1BLD36-0002k2-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:26: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 2004050420300949:6830 ; Tue, 4 May 2004 20:30:09 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE4090E@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE4090E@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083727578.1074.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 05/04/2004 08:30:09 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/04/2004 08:30:11 PM, Serialize complete at 05/04/2004 08:30:11 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: 04 May 2004 23:26:19 -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-05-04 at 23:18, Khosravi, Hormuzd M wrote: > -----Original Message----- > [HK] Sure, HB is probably a good example and that falls under the > category of Event messages for now (as Weiming suggested). Except for > HBs, events, packet redirection msgs, the app or CE will need responses > for all other msgs. You say HB is a good example, but its under event - does that imply you cant request for a heartbeat response? I think thats what you said, just double checking cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:49:31 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 XAA19527 for ; Tue, 4 May 2004 23:49: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 1BLDMi-0003p9-Ud for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:46:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453ka1K014694 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDHb-0002SL-Hr for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:41: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 XAA19135 for ; Tue, 4 May 2004 23:41: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 1BLDHZ-00051D-Ia for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:41:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDGX-0004rW-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:40:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDFY-0004ia-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:39:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDBX-0000GK-Sp; Tue, 04 May 2004 23:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLD85-0007xq-H6 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:31: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 XAA18453 for ; Tue, 4 May 2004 23:31: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 1BLD83-0003Us-Fe for forces-protocol@ietf.org; Tue, 04 May 2004 23:31:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD73-0003K2-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:30:25 -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 1BLD6D-00037I-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:29:33 -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 i453TY0b021951; Wed, 5 May 2004 03:29:34 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 i453TNUI015997; Wed, 5 May 2004 03:29:23 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 M2004050420290224301 ; Tue, 04 May 2004 20:29: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, 4 May 2004 20: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: [Forces-protocol] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE40916@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyTrTZmNtgw1++S1KS7yheDWGUHgAAQFiQ From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 05 May 2004 03:29:02.0874 (UTC) FILETIME=[1CB76FA0:01C43251] 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, 4 May 2004 20:29: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 Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > I think we should define it as a message sequence.=20 >=20 > [HK] Sure, I thought we already decided to call it Sequence no. Not sure > why Weiming used a different name ? BTW, do you agree with having the > same Sequence no in Req/Resp to match them ? I think you do, but just > wanted to confirm. Yes i do. [Thanks] >=20 > Next big question (I asked this earlier) how many PL level messages can > we have in flight? If more than one, do we need a windowing syntax in > the common header? >=20 > [HK] We can have more than one PL msg in flight, but I don't think we > need any windowing syntax in the common header. This will be provided by > the TML layer if needed. We will just use the Sequence no to match the > request/response msgs. I thinks its harder than that.=20 Pipeling is known to improve throughput; basically for a given b/width and RTT, you should be able to send in the range of BW*RTT bytes without getting an ACK that the first message you sent. Windowing just keeps track of how many such messages you have delivered to the network. Imagine that given a 10Gige pipe, you can only using 100Mbps.=20 Now i agree that adding windowing complicates things, but theres no way you can pass the pipelining responsibility to the TML. The TML will send as much data as you give it. Batching may be sufficient - dont know. [HK] Yes when you send multiple msgs in a single transaction, batching should be sufficient. As long as you get responses/acks back for all your msgs (atleast the important control msgs), you don't need windowing...also assuming the TML will provide strict reliability for control msgs atleast. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:51:25 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 XAA19613 for ; Tue, 4 May 2004 23:51: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 1BLDOr-0004HZ-7k for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:48:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453mnPn016457 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDId-0002gq-Fp for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:42: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 XAA19186 for ; Tue, 4 May 2004 23:42: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 1BLDIb-0005C8-Dd for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:42:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDHi-00052X-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:41:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDHH-0004t7-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDCU-0000f1-Gp; Tue, 04 May 2004 23:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDAg-0008OY-Sh for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:34: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 XAA18621 for ; Tue, 4 May 2004 23:34: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 1BLDAe-0003xQ-On for forces-protocol@ietf.org; Tue, 04 May 2004 23:34:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD9k-0003nU-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:33:13 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLD9V-0003fS-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:32:58 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 5 May 2004 11:45:37 +0800 Message-ID: <07a601c43251$260a1030$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EDD649C@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 5 May 2004 11:29:18 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, Thanks for volunteering ! -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Seems we begin to discuss how the writing task is to be assigned. Hornestly, my team ( I and Ligang) more prefer to take the task of protocol msg and common header writhing, because we think we may be more fit for sth more technique instead of beautiful literature oriented. Actually protocol msg is a big task, I just suggest we assign the 6 msgs to two individuals (1st 3, and last 3) for draft starter writing. [HK] I have already been putting a lot of time into the Protocol Messages and would like to continue with this work. I will be happy to work with you if you think this cant be done by a single individual. BTW, there are more than 6 messages for the protocol...have you seen the emails sent by Jamal on this ?? I'll send out a summary on this topic. [Weiming] I think every one here in our design team put lots of time for it. Msgs are the core part of the protocol, and also note that we are a design team, therefore I definitely don't think it is proper to have only one person for the work. I even suggest Jamal also need to pick up some here, e.g., the 'association and config. msg 'part, so as to keep consistancy with other part. I'm willing to do the part for 'query/resp and event msg'. On the Common Header, I would like to suggest working together with Jamal, if he has the time. [Weiming] Yes, that's also my thought. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 4 23:58:43 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 XAA19936 for ; Tue, 4 May 2004 23:58: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 1BLDRj-00055k-UN for forces-protocol-archive@odin.ietf.org; Tue, 04 May 2004 23:51:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453plnZ019567 for forces-protocol-archive@odin.ietf.org; Tue, 4 May 2004 23:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDQB-0004mf-Mq for forces-protocol-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:50: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 XAA19569 for ; Tue, 4 May 2004 23:50: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 1BLDQ9-0006MK-Hz for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:50:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDPJ-0006ED-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:49:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDOd-00065X-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:48:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDIK-0002du-Jk; Tue, 04 May 2004 23:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDEd-0001Yn-2B for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:38: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 XAA19041 for ; Tue, 4 May 2004 23:38: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 1BLDEb-0004a1-0W for forces-protocol@ietf.org; Tue, 04 May 2004 23:38:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDDe-0004Rg-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:37:15 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLDDJ-0004JE-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:36:54 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 5 May 2004 11:49:26 +0800 Message-ID: <07c601c43251$ae604120$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EE40264@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Conference call ? 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, 5 May 2004 11:33: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Teleconference is ok for us, though I more prefer the Netmeeting (just afraid some may not use it). Also, I need to check if teleconference is available for us, and will let you know soon. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: ; Sent: Wednesday, May 05, 2004 2:38 AM Subject: [Forces-protocol] Conference call ? Avri, > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > I am wondering whether there might not be a utility in having a conference call at some point to run through some of the remaining knots. Though we are continents apart, there are time that almost work with the Pacific US early in the AM and China late at night. [HK] I think this is a good idea, to make fast progress. Although, it might be difficult for Weiming with the time difference and English barrier. What do others think ? I remember that Ram had also proposed this in the past. 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 Wed May 5 00:06:11 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 AAA20366 for ; Wed, 5 May 2004 00:06: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 1BLDeT-000895-0k for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 00:04:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4544uRl031312 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 00:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDa1-0006ye-3a for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 00:00: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 AAA20056 for ; Wed, 5 May 2004 00:00: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 1BLDZy-000039-RW for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDZ7-0007gt-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:59:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDYA-0007Wv-00 for forces-protocol-web-archive@ietf.org; Tue, 04 May 2004 23:58:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDRx-0005E2-1A; Tue, 04 May 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 1BLDPC-0004Wn-F3 for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:49: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 XAA19481 for ; Tue, 4 May 2004 23:49: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 1BLDPA-0006Cn-9B for forces-protocol@ietf.org; Tue, 04 May 2004 23:49:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDOF-00063c-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:48: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 1BLDNI-0005m9-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:47:12 -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 i453jVuv020068; Wed, 5 May 2004 03:45:31 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 i453kfUS027479; Wed, 5 May 2004 03:47:00 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 M2004050420464026188 ; Tue, 04 May 2004 20:46: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); Tue, 4 May 2004 20:46: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE4091E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyUL2fAwXBBtVJTjiLgYom7pp/+AAARFEQ From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 05 May 2004 03:46:40.0435 (UTC) FILETIME=[93127030:01C43253] 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, 4 May 2004 20:46: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 Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > [HK] Sure, HB is probably a good example and that falls under the > category of Event messages for now (as Weiming suggested). Except for > HBs, events, packet redirection msgs, the app or CE will need responses > for all other msgs. You say HB is a good example, but its under event - does that imply=20 you cant request for a heartbeat response? I think thats what you said, just double checking [HK] You got me on that one buddy :-) Guess its been a long day for me. Anyways, although my email implies that you cant request a HB resp, that was not my intention. I think HB msgs are special as such (we have put them in a separate category in the Reqs as well) and we definitely need responses for them. It might be better to define HBs are separate msgs rather than Events...do you agree ? In any case, the point that I was trying to make is that you do need responses for all your control msgs such as Association Setup, Config, Query, Subscribe, State Maintenance (I notice I forgot to all Responses for the latter 2 in my protocol message summary). Do you agree ? regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 00:08:31 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 AAA20508 for ; Wed, 5 May 2004 00:08: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 1BLDhG-0000eN-1l for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 00:07:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4547neJ002492 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 00:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDft-0000At-2r for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 00:06: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 AAA20420 for ; Wed, 5 May 2004 00:06:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLDfq-0000vZ-PH for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:06:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDew-0000mU-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:05:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDeG-0000ch-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00: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 1BLDZm-0006xj-OW; Wed, 05 May 2004 00:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDV9-0005qQ-NR for forces-protocol@optimus.ietf.org; Tue, 04 May 2004 23:55: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 XAA19838 for ; Tue, 4 May 2004 23:55: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 1BLDV7-00075a-9y for forces-protocol@ietf.org; Tue, 04 May 2004 23:55:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDUB-0006x7-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:54: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 1BLDTP-0006fT-00 for forces-protocol@ietf.org; Tue, 04 May 2004 23:53: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 i453rIdb011792; Wed, 5 May 2004 03:53:18 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 i453rPlV030804; Wed, 5 May 2004 03:53: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 M2004050420530109669 ; Tue, 04 May 2004 20:53:01 -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, 4 May 2004 20:53:01 -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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE40920@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyUstzVevZ47xFT92EFDDml3YC0gAANE+Q From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 05 May 2004 03:53:01.0377 (UTC) FILETIME=[76219310:01C43254] 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, 4 May 2004 20:53:00 -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 find your comment below, rather rude. If you notice the summary of volunteers that I sent out, it has names of all the members of the team not just one person. Also, I have already put your name on the Protocol Msgs. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming [Weiming] I think every one here in our design team put lots of time for it. Msgs are the core part of the protocol, and also note that we are a design team, therefore I definitely don't think it is proper to have only one person for the work.=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 00:22:22 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 AAA21121 for ; Wed, 5 May 2004 00:22: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 1BLDrH-0004Ms-QU for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 00:18:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i454IBm2016786 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 00:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDnQ-0002wJ-Gw for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 00:14: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 AAA20764 for ; Wed, 5 May 2004 00:14: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 1BLDnO-00028d-5n for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDmT-0001zM-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:13:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDla-0001ns-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:12:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDhS-0000rz-MQ; Wed, 05 May 2004 00:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDfn-0000Ai-Gv for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 00:06: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 AAA20411 for ; Wed, 5 May 2004 00:06: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 1BLDfl-0000vJ-4p for forces-protocol@ietf.org; Wed, 05 May 2004 00:06:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDet-0000m0-00 for forces-protocol@ietf.org; Wed, 05 May 2004 00:05:24 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLDe6-0000cM-00 for forces-protocol@ietf.org; Wed, 05 May 2004 00:04:34 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 5 May 2004 12:17:03 +0800 Message-ID: <083e01c43255$89ec24e0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07EE40920@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 5 May 2004 12:00:43 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, I'm very unhappy with your reply. Could you show me where I show my rude? I think you should respect others more. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Sent: Wednesday, May 05, 2004 11:53 AM Subject: RE: [Forces-protocol] topic 4c: Common Header Weiming, I find your comment below, rather rude. If you notice the summary of volunteers that I sent out, it has names of all the members of the team not just one person. Also, I have already put your name on the Protocol Msgs. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming [Weiming] I think every one here in our design team put lots of time for it. Msgs are the core part of the protocol, and also note that we are a design team, therefore I definitely don't think it is proper to have only one person for the work. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 00:31:52 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 AAA21445 for ; Wed, 5 May 2004 00:31: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 1BLDzy-0006DB-Nl for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 00:27:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i454RAu8023860 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 00:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDz3-0005wg-SA for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 00:26: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 AAA21265 for ; Wed, 5 May 2004 00:26: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 1BLDz1-0003rJ-DZ for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDy5-0003jQ-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:25:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDxQ-0003bH-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 00:24:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDuy-0005D3-Af; Wed, 05 May 2004 00: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 1BLDpN-0003lP-6N for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 00:16: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 AAA20812 for ; Wed, 5 May 2004 00:16: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 1BLDpK-0002Qo-Du for forces-protocol@ietf.org; Wed, 05 May 2004 00:16:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDoS-0002IU-00 for forces-protocol@ietf.org; Wed, 05 May 2004 00:15:16 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLDna-00029x-00 for forces-protocol@ietf.org; Wed, 05 May 2004 00:14:25 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 5 May 2004 12:26:58 +0800 Message-ID: <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary : 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, 5 May 2004 12:10: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.1 required=5.0 tests=AWL autolearn=no version=2.60 ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All Here is the list of Protocol Messages based on final comments made by Jamal. Association Setup, Setup Resp msg Association Teardown msg [Weiming] I agree to use the name 'Association'. But I can not find where Jamal disagree to use only one msg approach, that is 'association msg'. Again, I have to say a flag is definitely enough to indicate the command 'setup' 'setup resp', and 'teardown'. Can you give reasons why they should be two msgs? Query/Query Resp msg (including Capability query) Config/Config Resp msg Subscribe/Unsubscribe msg [Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I don't think Jamal agrees this also. A config or a Event msg can do this well. State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE, etc) Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) [Weiming] I suggest just an 'Event msg' may be better. Packet Redirect msg Regards Hormuzd 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 May 5 01:57: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 BAA24800 for ; Wed, 5 May 2004 01:57: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 1BLFNh-0003J6-UC for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 01:55:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i455tjTU012708 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 01:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFGW-0001pd-H6 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 01:48: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 BAA24432 for ; Wed, 5 May 2004 01:48: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 1BLFGT-00014u-Br for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 01:48:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFFY-0000uz-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 01:47:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLFF7-0000lH-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 01:46:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFAQ-0008P1-OD; Wed, 05 May 2004 01: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 1BLF5s-0007CL-IL for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 01:37: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 BAA23982 for ; Wed, 5 May 2004 01:37: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 1BLF5p-00074h-Dp for forces-protocol@ietf.org; Wed, 05 May 2004 01:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLF52-0006uw-00 for forces-protocol@ietf.org; Wed, 05 May 2004 01:36:28 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLF4S-0006kb-00 for forces-protocol@ietf.org; Wed, 05 May 2004 01:35:53 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 5 May 2004 13:48:27 +0800 Message-ID: <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header 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, 5 May 2004 13:32: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.1 required=5.0 tests=AWL autolearn=no version=2.60 ----- Original Message ----- From: "Jamal Hadi Salim" To: "Khosravi, Hormuzd M" Cc: "Weiming Wang" ; Sent: Wednesday, May 05, 2004 11:14 AM Subject: RE: [Forces-protocol] topic 4c: Common Header > On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote: > > > There will also be times when i wont be interested in > > the response (and this is not just in the case of events). > > > > [HK] Most of the Control Plane Apps such as routing/switching protocols > > that I have worked with need responses for any commands such as Config > > or Query msgs. Could you give some examples of what msgs you don't need > > responses for ? Also, how do we satisfy the timeliness requirement which > > without protocol level responses or acks ? > > I dont wanna speculate about others - i think the possibilty is > certainly there, but a simple example is a PL heartbeat scheme where i > can occasionaly request for an ACK. We have used this and found it > useful. > [Weiming]I think the scheme as 'Pls let me know when you encounter difficulties, otherwise pls don't bother' should be very useful for ForCES architecture, where we can think of the heavy burden of FE resources and lack of b/w resouces for CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add huge routes, I would prefer to let FE send back responses when it finds some difficulty to do that. App level response is different from low level responses. Still take add huge routes as e.g., App level may only get a response by low level (not necessariy from FE) to tell that the huge routes (as one task) has been implemented sucessfully (or stoped owing to an error). It's not always the case the app. level needs the huge responses. > cheers, > jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 05:17: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 FAA01661 for ; Wed, 5 May 2004 05:17: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 1BLIO0-0006h8-Ek for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 05:08:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4598Gkr025727 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 05:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLICY-0003Qw-GL for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 04:56: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 EAA00986 for ; Wed, 5 May 2004 04:56: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 1BLICV-0004mf-II for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 04:56:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIBd-0004bH-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 04:55:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLIAz-0004Pw-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 04:54:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLI5O-0001bG-3T; Wed, 05 May 2004 04:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLHzx-00006v-4C for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 04:43: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 EAA00526 for ; Wed, 5 May 2004 04:43:22 -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 1BLHzt-0002J0-Qx for forces-protocol@ietf.org; Wed, 05 May 2004 04:43:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLHyz-000284-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:42:26 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BLHyZ-0001x8-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:41:59 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i458fov20394; Wed, 5 May 2004 11:41:50 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 11:41:49 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i458fnF0027277; Wed, 5 May 2004 11:41:49 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00kkhav9; Wed, 05 May 2004 11:41:48 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 i458flH22470; Wed, 5 May 2004 11:41:47 +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); Wed, 5 May 2004 03:41:46 -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 4c: Common Header Message-ID: Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyURVaVcsgunZsRI6La0z7C9guBAAK0GEA To: , Cc: , X-OriginalArrivalTime: 05 May 2004 08:41:46.0954 (UTC) FILETIME=[CCFAD2A0:01C4327C] 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, 5 May 2004 04:41:46 -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,Hormuzd and others, > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > Hadi Salim > Sent: Tuesday, May 04, 2004 11:15 PM > To: Khosravi, Hormuzd M > Cc: Weiming Wang; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] topic 4c: Common Header >=20 >=20 > On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote: >=20 > > There will also be times when i wont be interested in > > the response (and this is not just in the case of events). =20 > >=20 > > [HK] Most of the Control Plane Apps such as=20 > routing/switching protocols > > that I have worked with need responses for any commands=20 > such as Config > > or Query msgs. Could you give some examples of what msgs=20 > you don't need > > responses for ? Also, how do we satisfy the timeliness=20 > requirement which > > without protocol level responses or acks ? >=20 > I dont wanna speculate about others - i think the possibility is > certainly there, but a simple example is a PL heartbeat scheme where i > can occasionaly request for an ACK. We have used this and found it > useful. >=20 Purpose of heart beat is to check whether other endpoint is alive, there = are several ways to go for HB. One could be clients can periodically send their liveness to servers = (and considered as ACK). - OR server can request and client respond in this case ACK is a must. - OR if there are a periodic or (Semi-periodic) message exchange that = can also be considered to reset the=20 HB intiation. IMHO, many configuration messages that happens between CE to FE (on FE) = requires confirmation to assure that it has really been communicated and acted upon. regards ramg > 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 Wed May 5 05:28:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02280 for ; Wed, 5 May 2004 05:28: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 1BLIXE-0000b1-ME for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 05:17:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i459HmEZ002292 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 05:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIP5-0006yh-Fu for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 05: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 FAA01387 for ; Wed, 5 May 2004 05:09: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 1BLIP2-0007HH-BD for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:09:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIO2-00073X-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:08:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLIN1-0006hk-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:07:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLICJ-0003KW-FL; Wed, 05 May 2004 04:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLI5t-0001jv-9D for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 04:49: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 EAA00794 for ; Wed, 5 May 2004 04:49:30 -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 1BLI5q-0003T6-6D for forces-protocol@ietf.org; Wed, 05 May 2004 04:49:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLI4y-0003Gx-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:48:37 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BLI4D-00034a-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:47:49 -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 i458leH24694; Wed, 5 May 2004 11:47:40 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 11:47:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i458lZCl012293; Wed, 5 May 2004 11:47:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00BsBM5F; Wed, 05 May 2004 11:47: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 i458lWH07409; Wed, 5 May 2004 11:47:32 +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); Wed, 5 May 2004 03:47:32 -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 4c: Common Header Message-ID: Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQySsx9I9eP4if+RCG8hBMX0OzhigAAP/4gAAxjtwA= To: , Cc: , X-OriginalArrivalTime: 05 May 2004 08:47:32.0043 (UTC) FILETIME=[9AAB39B0:01C4327D] 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, 5 May 2004 04:47:30 -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,Jamal and others, 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, May 04, 2004 10:59 PM > To: hadi@znyx.com > Cc: Weiming Wang; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] topic 4c: Common Header >=20 >=20 > Jamal, >=20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > > [HK] I agree. The Transaction ID or Sequence No. should be=20 > the same in > > both Request and Response msgs e.g. Config/Config Resp to=20 > denote that > > they are part of the same transaction. That was the reason=20 > for having > a > > Sequence no to begin with. >=20 > If you call that 32 bit value a transaction # it may be a little > misleading; example a transaction may take several messages=20 > not just one > (Consider a two phase commit transaction where you send=20 > several messages > followed by a commit to complete the transaction).=20 > I think we should define it as a message sequence.=20 >=20 One more id requirement.... If we use command bundling (mulitple queries or configs in one) then CE = needs to match not only the Seqno but also each command response against some other = identifier???. Each command should be self contained with some unique id to match the = response. > [HK] Sure, I thought we already decided to call it Sequence=20 > no. Not sure > why Weiming used a different name ? BTW, do you agree with having the > same Sequence no in Req/Resp to match them ? I think you do, but just > wanted to confirm. >=20 > Next big question (I asked this earlier) how many PL level=20 > messages can > we have in flight? If more than one, do we need a windowing syntax in > the common header? >=20 > [HK] We can have more than one PL msg in flight, but I don't think we > need any windowing syntax in the common header. This will be=20 > provided by > the TML layer if needed. We will just use the Sequence no to match the > request/response msgs. >=20 > Thanks > 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 Wed May 5 05:28:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02352 for ; Wed, 5 May 2004 05:28: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 1BLIXI-0000c7-9g for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 05:17:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i459HqFs002355 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 05:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIQ3-0007Ak-6N for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 05:10: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 FAA01427 for ; Wed, 5 May 2004 05:10: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 1BLIPz-0007TR-Vw for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:10:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIP4-0007Hb-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:09:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLIOD-00074v-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 05:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIIv-0004fN-1c; Wed, 05 May 2004 05:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLI9b-0002cS-Tz for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 04:53: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 EAA00905 for ; Wed, 5 May 2004 04:53: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 1BLI9Y-0004D9-Qz for forces-protocol@ietf.org; Wed, 05 May 2004 04:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLI8b-00042A-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:52:22 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BLI7h-0003g7-00 for forces-protocol@ietf.org; Wed, 05 May 2004 04:51:25 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i458otPk137476; Wed, 5 May 2004 08:50:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i458otVH140002; Wed, 5 May 2004 10:50:55 +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 KAA37540; Wed, 5 May 2004 10:50:55 +0200 Message-ID: <4098AAEE.9030704@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: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: batching References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------030906020408070509000207" 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, 05 May 2004 10:50:54 +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.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030906020408070509000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i458otPk137476 Content-Transfer-Encoding: quoted-printable Weiming, I think the approach of 'Pls let me know when you encounter=20 difficulties, otherwise pls don't bother' is indeed useful. Let me=20 elaborate a bit on this. Sorry for the rather long message. I'll devote=20 another note to windowing. Batching is used to group commands together. Each command possibly has=20 its own sequence number (or transaction number), or the group has its=20 own number with subnumbers for each message (this remains to be=20 decided.) The main use of batching is to perform atomicity: all commands=20 in the group will be performed at the same time or none will be=20 performed. This is where 2-phase commit kicks in: all commands are first=20 transmitted to the FE, and unless the FE reports an error, the CE can=20 ultimately issue a commit command so all these commands are executed in=20 an atomic operation at the FE. We investigated the idea of packing multiple commands in the same ForCES=20 message (it saves quite some headers and the associated processing). As=20 a motivation, think of adding 100'000 routes on an FE: should we use=20 100'000 ForCES messages, or only 1000 (say 15 bytes per route update=20 command to be generous, with a 1500 bytes MTU size, or even less if we=20 have Jumbo frames) ? Note that having many commands in the same ForCES message results in=20 slighlty more complex error/ack reporting. Take this example: two=20 commands A and B in the same ForCES message issued by a CE. FE executes=20 both of them, but only A succeeds. It should report this somehow to the=20 CE. A possible solution is to return the original message trimmed down=20 such that it contains exactly two responses, a positive and a negative on= e. I think we should focus our effort on defining the format and state=20 machine of the ForCES protocol as seen on the wire (and define a few=20 encapsulation methods for ForCES over UDP, TCP, etc, with specific=20 reserved port numbers). So I don't think we need to worry about the way=20 the Apps get notifications from the PL and so on, and if a=20 single/multiple signal/s is/are used to confirm that a batch of messages=20 has been successfully executed. This will remain vendor specific. Do you=20 have different views ? Cheers, -Robert Wang,Weiming wrote: >----- Original Message ----- >From: "Jamal Hadi Salim" >To: "Khosravi, Hormuzd M" >Cc: "Weiming Wang" ; >Sent: Wednesday, May 05, 2004 11:14 AM >Subject: RE: [Forces-protocol] topic 4c: Common Header > > > =20 > >>On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote: >> >> =20 >> >>>There will also be times when i wont be interested in >>>the response (and this is not just in the case of events). >>> >>>[HK] Most of the Control Plane Apps such as routing/switching protocol= s >>>that I have worked with need responses for any commands such as Config >>>or Query msgs. Could you give some examples of what msgs you don't nee= d >>>responses for ? Also, how do we satisfy the timeliness requirement whi= ch >>>without protocol level responses or acks ? >>> =20 >>> >>I dont wanna speculate about others - i think the possibilty is >>certainly there, but a simple example is a PL heartbeat scheme where i >>can occasionaly request for an ACK. We have used this and found it >>useful. >> >> =20 >> >[Weiming]I think the scheme as 'Pls let me know when you encounter diffi= culties, >otherwise pls don't bother' should be very useful for ForCES architectur= e, where >we can think of the heavy burden of FE resources and lack of b/w resouce= s for >CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add= huge >routes, I would prefer to let FE send back responses when it finds some >difficulty to do that. App level response is different from low level re= sponses. >Still take add huge routes as e.g., App level may only get a response by= low >level (not necessariy from FE) to tell that the huge routes (as one task= ) has >been implemented sucessfully (or stoped owing to an error). It's not alw= ays the >case the app. level needs the huge responses. > > =20 > >>cheers, >>jamal >> =20 >> > > > >_______________________________________________ >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 --------------030906020408070509000207 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,
I think the approach of  'Pls let me know when you encounter difficulties, otherwise pls don't bother' is indeed useful. Let me elaborate a bit on this. Sorry for the rather long message. I'll devote another note to windowing.

 Batching is used to group commands together. Each command possibly has its own sequence number (or transaction number), or the group has its own number with subnumbers for each message (this remains to be decided.) The main use of batching is to perform atomicity: all commands in the group will be performed at the same time or none will be performed. This is where 2-phase commit kicks in: all commands are first transmitted to the FE, and unless the FE reports an error, the CE can ultimately issue a commit command so all these commands are executed in an atomic operation at the FE.

We investigated the idea of packing multiple commands in the same ForCES message (it saves quite some headers and the associated processing). As a motivation, think of adding 100'000 routes on an FE: should we use 100'000 ForCES messages, or only 1000 (say 15 bytes per route update command to be generous, with a 1500 bytes MTU size, or even less if we have Jumbo frames) ?

Note that having many commands in the same ForCES message results in slighlty more complex error/ack reporting. Take this example: two commands A and B in the same ForCES message issued by a CE. FE executes both of  them, but only A succeeds. It should report this somehow to the CE. A possible solution is to return the original message trimmed down such that it contains exactly two responses, a positive and a negative one.

I think we should focus our effort on defining the format and state machine of the ForCES protocol as seen on the wire (and define a few encapsulation methods for ForCES over UDP, TCP, etc, with specific reserved port numbers). So I don't think we need to worry about the way the Apps get notifications from the PL and so on, and if a single/multiple signal/s is/are used to confirm that a batch of messages has been successfully executed. This will remain vendor specific. Do you have different views ?

Cheers,
-Robert



Wang,Weiming wrote:
----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Cc: "Weiming Wang" <wmwang@mail.hzic.edu.cn>; <forces-protocol@ietf.org>
Sent: Wednesday, May 05, 2004 11:14 AM
Subject: RE: [Forces-protocol] topic 4c: Common Header


  
On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote:

    
There will also be times when i wont be interested in
the response (and this is not just in the case of events).

[HK] Most of the Control Plane Apps such as routing/switching protocols
that I have worked with need responses for any commands such as Config
or Query msgs. Could you give some examples of what msgs you don't need
responses for ? Also, how do we satisfy the timeliness requirement which
without protocol level responses or acks ?
      
I dont wanna speculate about others - i think the possibilty is
certainly there, but a simple example is a PL heartbeat scheme where i
can occasionaly request for an ACK. We have used this and found it
useful.

    
[Weiming]I think the scheme as 'Pls let me know when you encounter difficulties,
otherwise pls don't bother' should be very useful for ForCES architecture, where
we can think of the heavy burden of FE resources and lack of b/w resouces for
CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add huge
routes, I would prefer to let FE send back responses when it finds some
difficulty to do that. App level response is different from low level responses.
Still take add huge routes as e.g., App level may only get a response by low
level (not necessariy from FE) to tell that the huge routes (as one task) has
been implemented sucessfully (or stoped owing to an error). It's not always the
case the app. level needs the huge responses.

  
cheers,
jamal
    



_______________________________________________
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
--------------030906020408070509000207-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 07:31:42 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 HAA07872 for ; Wed, 5 May 2004 07:31: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 1BLKbQ-0005XJ-Sh for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 07:30:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45BUGai021282 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 07:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKZi-00051c-6h for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 07:28: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 HAA07706 for ; Wed, 5 May 2004 07:28: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 1BLKZh-00055F-LL for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 07:28:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLKYl-0004s8-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 07:27:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLKXt-0004fV-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 07:26:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKTS-0003NK-MQ; Wed, 05 May 2004 07:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLKSD-0002l7-DS for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 07:20: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 HAA07106 for ; Wed, 5 May 2004 07:20: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 1BLKSC-0003DL-RU for forces-protocol@ietf.org; Wed, 05 May 2004 07:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLKR5-0002xf-00 for forces-protocol@ietf.org; Wed, 05 May 2004 07:19:35 -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 1BLKQn-0002l3-00 for forces-protocol@ietf.org; Wed, 05 May 2004 07:19:17 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050504230511:7108 ; Wed, 5 May 2004 04:23:05 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE4091E@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE4091E@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083755954.1071.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 05/05/2004 04:23:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 04:23:07 AM, Serialize complete at 05/05/2004 04:23: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: 05 May 2004 07:19:14 -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-05-04 at 23:46, Khosravi, Hormuzd M wrote: > [HK] > I think HB msgs are special as such (we have put them in a separate > category in the Reqs as well) and we definitely need responses for them. > It might be better to define HBs are separate msgs rather than > Events...do you agree ? That sounds reasonable. Note, however, i gave that as just as an example because we used that feature. There could be vendor specific messages which may have these needs. What is the cost of adding such a feature? > In any case, the point that I was trying to make > is that you do need responses for all your control msgs such as > Association Setup, Config, Query, Subscribe, State Maintenance (I notice > I forgot to all Responses for the latter 2 in my protocol message > summary). Do you agree ? Except when you deliver such messages from FE towards CE where they come out as events. Did we settle on whether we want to do this? Refer to discussion on peer model. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 09:54:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13489 for ; Wed, 5 May 2004 09:54: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 1BLMnd-0004xc-5s for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 09:51:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Dp18J019060 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 09:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMiZ-0003Ky-D9 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 09:45: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 JAA13098 for ; Wed, 5 May 2004 09:45: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 1BLMiX-0005Dk-Ge for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 09:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMha-0004zL-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 09:44:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLMhA-0004kr-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 09:44:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMb6-0001DY-AB; Wed, 05 May 2004 09: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 1BLMZo-0000Wy-5A for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 09:36: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 JAA12684 for ; Wed, 5 May 2004 09:36:41 -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 1BLMZm-000360-Co for forces-protocol@ietf.org; Wed, 05 May 2004 09:36:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMYn-0002rN-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:35:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BLMY4-0002cy-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:34:56 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLMY2-0003w4-VE for forces-protocol@ietf.org; Wed, 05 May 2004 13:34:55 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE408E9@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE408E9@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header 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, 5 May 2004 15:34:48 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5 maj 2004, at 04.34, Khosravi, Hormuzd M wrote: > [HK] Avri, are you talking about Distributed routing or distributed > control plane in terms offloading some of the routing protocol > functionality such as neighbor discovery (e.g. OSPF Hello offload) onto > FEs ? If so, I agree with your view and believe we had covered this in > the Requirements for the FE Model (Protocol Offload functions support). > > [ad] yes, that is essentially it. In this case the FE will be informing the CE of results that, while not a command, is essentially a peering type of activity in the split of operations between the CE and FE. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 10:23:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15740 for ; Wed, 5 May 2004 10:23: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 1BLNFx-00029u-DK for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 10:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45EKHUL008295 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 10:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN9C-0007A4-RH for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 10: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 KAA14789 for ; Wed, 5 May 2004 10: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 1BLN9A-0003bF-Mk for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:13:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN7f-0003Fr-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:11:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7L-00031T-01 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:11:23 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLN2C-0003O4-EV for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN0D-0002EL-1i; Wed, 05 May 2004 10:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMu1-0006S0-KR for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 09:57: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 JAA13560 for ; Wed, 5 May 2004 09:57: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 1BLMtz-0000Bb-OX for forces-protocol@ietf.org; Wed, 05 May 2004 09:57:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMt2-0007ld-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:56:37 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BLMsg-0007YB-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:56:14 -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 i45DtgYO144908; Wed, 5 May 2004 13:55:42 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 i45DtfKH280802; Wed, 5 May 2004 15:55:41 +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 PAA67434; Wed, 5 May 2004 15:55:41 +0200 Message-ID: <4098F25C.1080008@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: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a References: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate5.de.ibm.com id i45DtgYO144908 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, 05 May 2004 15:55:40 +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 All, I've seen some interesting ideas floating around regarding the number of=20 messages needed. Let me illustrate the kind of messages I think we need=20 with two scenari: Usual scenario: CE sends a Config message to FE. FE applies it and sends an appropriate=20 response (ACK if successful or NACK otherwise). This can be the same=20 message type with a flag that indicates the result. Batching scenario with 2-phase commit: CE sends a serie (batch or bundle, as you prefer) of Config messages to=20 the FE, followed by a Commit message (which could be signalled with a=20 flag in the last Config message). The FE returns a serie of responses to=20 indicate that it got the messages, but DOES NOT apply them until the=20 Commit comes. The Response to the Commit indicates if the batch of=20 Config messages was successfully applied or not. Conclusion: You need a Config message type. You may use a flag to indicate whether it's the message itself, an ACK,=20 or an NACK. You may use a flag to indicate if the message is one of a batch, or the=20 last of the batch (i.e., the Commit). In the Query case, as there is no 2-phase commit necessary: You need a Query message type. You may use a flag to indicate whether it's the message, an ACK, or an NA= CK. I'd like to know more about the type of actions that can be performed on=20 the LFBs according to the model. Maybe a Config and a Query are enough.=20 But I don't know how the Event Generation is handled in the model. Can=20 someone explain ? For FE UP and DOWN, I'd rather include this in existing message types.=20 For instance, define an FE LFB that can be acted upon, and events such=20 as UP and DOWN may be subscribed to. Use the same messages and semantics=20 as the one used for other LFBs. You may apply the same reasoning to a Packet Redirect LFB, which=20 produces packets as events. Regards, -Robert Wang,Weiming wrote: >----- Original Message ----- >From: "Khosravi, Hormuzd M" >Hi All > >Here is the list of Protocol Messages based on final comments made by >Jamal. > >Association Setup, Setup Resp msg >Association Teardown msg >[Weiming] I agree to use the name 'Association'. But I can not find wher= e Jamal >disagree to use only one msg approach, that is 'association msg'. Again,= I have >to say a flag is definitely enough to indicate the command 'setup' 'setu= p resp', >and 'teardown'. Can you give reasons why they should be two msgs? > >Query/Query Resp msg (including Capability query) > >Config/Config Resp msg > >Subscribe/Unsubscribe msg >[Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub'= ? I >don't think Jamal agrees this also. A config or a Event msg can do this= well. > >State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE, >etc) > >Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) > >[Weiming] I suggest just an 'Event msg' may be better. > >Packet Redirect msg > >Regards >Hormuzd > >Best regards, >Weiming > > > > >_______________________________________________ >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 May 5 10:24:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15760 for ; Wed, 5 May 2004 10:24: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 1BLNFy-0002AT-At for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 10:20:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45EKHtf008329 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 10:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN9L-0007Bi-E3 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:13: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 KAA14828 for ; Wed, 5 May 2004 10:13: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 1BLN9J-0003cO-D0 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:13:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN7n-0003H6-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:11:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7O-00031T-01 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:11: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 1BLMzY-0003HP-22 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:03:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLMsT-000696-FL; Wed, 05 May 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 1BLMr7-0005m0-SO for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 09:54: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 JAA13524 for ; Wed, 5 May 2004 09:54: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 1BLMr5-0007JZ-Ug for forces-protocol@ietf.org; Wed, 05 May 2004 09:54:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLMqC-00075u-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:53:40 -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 1BLMpK-0006sH-00 for forces-protocol@ietf.org; Wed, 05 May 2004 09:52:46 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050506563466:7189 ; Wed, 5 May 2004 06:56:34 -0700 Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, hormuzd.m.khosravi@intel.com In-Reply-To: <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1083765164.1023.51.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 05/05/2004 06:56:34 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 06:56:36 AM, Serialize complete at 05/05/2004 06:56: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: 05 May 2004 09:52:44 -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 Olla, On Wed, 2004-05-05 at 00:10, Wang,Weiming wrote: > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > Hi All > > Here is the list of Protocol Messages based on final comments made by > Jamal. > > Association Setup, Setup Resp msg > Association Teardown msg > [Weiming] I agree to use the name 'Association'. But I can not find where Jamal > disagree to use only one msg approach, that is 'association msg'. Again, I have > to say a flag is definitely enough to indicate the command 'setup' 'setup resp', > and 'teardown'. Can you give reasons why they should be two msgs? We need to have a setup and teardown. The setup can be either accepted or rejected. Thats the general concept - and i dont think anyone disagrees with that. I personally dont care what you end up calling such messages. Theres two ways to represent the messages: 1) A command for both. 2) A single command with flags differentiating the two. The first scheme has more commands being used. The second scheme indicates we need flags in the common header. I think we will have flags regardless: I know Hormuzd has tried to pinpoint where flags on the main header could be moved to be only specific to a message but i would violently disagree with such a move at this stage. I would prefer #2, but i wont fight over it. > Query/Query Resp msg (including Capability query) > > Config/Config Resp msg > > Subscribe/Unsubscribe msg > [Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I > don't think Jamal agrees this also. A config or a Event msg can do this well. > Again this relates to the peer discussion going on. I will move this under that subject. > State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE, > etc) > > Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) > > [Weiming] I suggest just an 'Event msg' may be better. Event maybe insufficient if you need to have a response to a heartbeart. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 10:42:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17021 for ; Wed, 5 May 2004 10:42: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 1BLNVI-0007Dt-Fg for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 10:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Ea8i9027766 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 10:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNMG-0003qH-JC for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:26: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 KAA15866 for ; Wed, 5 May 2004 10:26: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 1BLNME-0006v1-Bg for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:26:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNLI-0006g8-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:25:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLNKu-0006RF-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 10:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGh-0002U6-QV; Wed, 05 May 2004 10: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 1BLN9j-0007Gi-Gz for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 10:13: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 KAA14903 for ; Wed, 5 May 2004 10:13: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 1BLN9h-0003ra-C1 for forces-protocol@ietf.org; Wed, 05 May 2004 10:13:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN8h-0003Wj-00 for forces-protocol@ietf.org; Wed, 05 May 2004 10:12:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7U-00031T-01 for forces-protocol@ietf.org; Wed, 05 May 2004 10:11:32 -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 1BLMvQ-0003Ce-O0 for forces-protocol@ietf.org; Wed, 05 May 2004 09:59:04 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050507025026:7195 ; Wed, 5 May 2004 07:02:50 -0700 Subject: peering WAS(Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: forces-protocol@ietf.org, avri@acm.org, hormuzd.m.khosravi@intel.com In-Reply-To: <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1083765539.1022.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 05/05/2004 07:02:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:02:52 AM, Serialize complete at 05/05/2004 07:02:52 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: 05 May 2004 09:59: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 Wed, 2004-05-05 at 00:10, Wang,Weiming wrote: > Query/Query Resp msg (including Capability query) > > Config/Config Resp msg > > Subscribe/Unsubscribe msg > [Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I > don't think Jamal agrees this also. A config or a Event msg can do this well. I think we need config messages going from FE to CE informing it of events as well. Not all events fit under this message, but a subset does. Is this what you are refering to Weiming? Just remember that not all events fit in that model. Also the subscription is needed otherwise the default should be you get no events. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 11:49:36 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 LAA22017 for ; Wed, 5 May 2004 11: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 1BLOWB-000100-3Q for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 11:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Ff73Q003829 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 11: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 1BLOIF-00047k-Mw for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:26: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 LAA20786 for ; Wed, 5 May 2004 11:26: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 1BLOIE-00002g-P0 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:26:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOHI-0007ZP-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:25:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLOGK-0007Il-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:24:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOEg-0002Qd-Q2; Wed, 05 May 2004 11: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 1BLNzv-0004fZ-Fn for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 11:07: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 LAA18960 for ; Wed, 5 May 2004 11:07: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 1BLNzs-0002a5-T9 for forces-protocol@ietf.org; Wed, 05 May 2004 11:07:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNy3-00023R-00 for forces-protocol@ietf.org; Wed, 05 May 2004 11:05:53 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BLNwz-0001Ud-00 for forces-protocol@ietf.org; Wed, 05 May 2004 11:04:45 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i45F4Dn5091108; Wed, 5 May 2004 15:04:13 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i45F4DVH264218; Wed, 5 May 2004 17:04:13 +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 RAA52976; Wed, 5 May 2004 17:04:12 +0200 Message-ID: <4099026D.70903@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: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: windowing References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------090301090908060007030206" 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, 05 May 2004 17:04:13 +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.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090301090908060007030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id i45F4Dn5091108 Content-Transfer-Encoding: quoted-printable All, Let me try to briefly tackle the windowing issue now: First, we should definitely not shoot for a TCP-like flow-control=20 solution at the PL level. Instead, we could define a high-priority/control message that an FE can=20 send in case of overruns. Overruns occur when the FE is too slow at=20 processing the incoming CE messages, and its receive buffers are full.=20 The reaction of the CE to the overrun message can be left vendor=20 specific. It the TML is TCP, then the TCP flow-control will=20 automatically take care of this and overruns will not be generated by=20 the FE. Other TMLs might not provide such capability, hence the need for=20 this (extremely simple) windowing scheme at the PL level using overrun=20 messages. Let me know what other approaches you would consider. The approach above=20 fits in the 'Pls let me know when you encounter difficulties, otherwise=20 pls don't bother' category Weiming already suggested. Regards, -Robert Wang,Weiming wrote: >----- Original Message ----- >From: "Jamal Hadi Salim" >To: "Khosravi, Hormuzd M" >Cc: "Weiming Wang" ; >Sent: Wednesday, May 05, 2004 11:14 AM >Subject: RE: [Forces-protocol] topic 4c: Common Header > > > =20 > >>On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote: >> >> =20 >> >>>There will also be times when i wont be interested in >>>the response (and this is not just in the case of events). >>> >>>[HK] Most of the Control Plane Apps such as routing/switching protocol= s >>>that I have worked with need responses for any commands such as Config >>>or Query msgs. Could you give some examples of what msgs you don't nee= d >>>responses for ? Also, how do we satisfy the timeliness requirement whi= ch >>>without protocol level responses or acks ? >>> =20 >>> >>I dont wanna speculate about others - i think the possibilty is >>certainly there, but a simple example is a PL heartbeat scheme where i >>can occasionaly request for an ACK. We have used this and found it >>useful. >> >> =20 >> >[Weiming]I think the scheme as 'Pls let me know when you encounter diffi= culties, >otherwise pls don't bother' should be very useful for ForCES architectur= e, where >we can think of the heavy burden of FE resources and lack of b/w resouce= s for >CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add= huge >routes, I would prefer to let FE send back responses when it finds some >difficulty to do that. App level response is different from low level re= sponses. >Still take add huge routes as e.g., App level may only get a response by= low >level (not necessariy from FE) to tell that the huge routes (as one task= ) has >been implemented sucessfully (or stoped owing to an error). It's not alw= ays the >case the app. level needs the huge responses. > > =20 > >>cheers, >>jamal >> =20 >> > > > >_______________________________________________ >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 --------------090301090908060007030206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,

Let me try to briefly tackle the windowing issue now:

First, we should definitely not shoot for a TCP-like flow-control solution at the PL level.

Instead, we could define a high-priority/control message that an FE can send in case of overruns. Overruns occur when the FE is too slow at processing the incoming CE messages, and its receive buffers are full. The reaction of the CE to the overrun message can be left vendor specific. It the TML is TCP, then the TCP flow-control will automatically take care of this and overruns will not be generated by the FE. Other TMLs might not provide such capability, hence the need for this (extremely simple) windowing scheme at the PL level using overrun messages.

Let me know what other approaches you would consider. The approach above fits in the 'Pls let me know when you encounter difficulties, otherwise pls don't bother' category Weiming already suggested.

Regards,
-Robert


Wang,Weiming wrote:
----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Cc: "Weiming Wang" <wmwang@mail.hzic.edu.cn>; <forces-protocol@ietf.org>
Sent: Wednesday, May 05, 2004 11:14 AM
Subject: RE: [Forces-protocol] topic 4c: Common Header


  
On Tue, 2004-05-04 at 23:05, Khosravi, Hormuzd M wrote:

    
There will also be times when i wont be interested in
the response (and this is not just in the case of events).

[HK] Most of the Control Plane Apps such as routing/switching protocols
that I have worked with need responses for any commands such as Config
or Query msgs. Could you give some examples of what msgs you don't need
responses for ? Also, how do we satisfy the timeliness requirement which
without protocol level responses or acks ?
      
I dont wanna speculate about others - i think the possibilty is
certainly there, but a simple example is a PL heartbeat scheme where i
can occasionaly request for an ACK. We have used this and found it
useful.

    
[Weiming]I think the scheme as 'Pls let me know when you encounter difficulties,
otherwise pls don't bother' should be very useful for ForCES architecture, where
we can think of the heavy burden of FE resources and lack of b/w resouces for
CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add huge
routes, I would prefer to let FE send back responses when it finds some
difficulty to do that. App level response is different from low level responses.
Still take add huge routes as e.g., App level may only get a response by low
level (not necessariy from FE) to tell that the huge routes (as one task) has
been implemented sucessfully (or stoped owing to an error). It's not always the
case the app. level needs the huge responses.

  
cheers,
jamal
    



_______________________________________________
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
--------------090301090908060007030206-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 12:24:31 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 MAA23427 for ; Wed, 5 May 2004 12:24: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 1BLOto-0001Fh-Pj for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 12:05:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45G5WN2004812 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 12:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOlV-0006Ou-Sz for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:56: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 LAA22491 for ; Wed, 5 May 2004 11:56: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 1BLOlU-00007u-OR for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:56:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOkS-0007fC-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:55:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLOjs-0007Pn-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 11:55:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOXG-0001dC-02; Wed, 05 May 2004 11:42:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOSz-0007Au-Dp for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 11:37: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 LAA21530 for ; Wed, 5 May 2004 11:37: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 1BLOSy-00033B-Ci for forces-protocol@ietf.org; Wed, 05 May 2004 11:37:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOS8-0002oY-00 for forces-protocol@ietf.org; Wed, 05 May 2004 11:36:56 -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 1BLORi-0002Yz-00 for forces-protocol@ietf.org; Wed, 05 May 2004 11:36:30 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050508401706:7347 ; Wed, 5 May 2004 08:40:17 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: ram.gopal@nokia.com Cc: hormuzd.m.khosravi@intel.com, wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org In-Reply-To: References: Organization: Znyx Networks Message-Id: <1083771386.1022.246.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 05/05/2004 08:40:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 08:40:19 AM, Serialize complete at 05/05/2004 08:40: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: 05 May 2004 11:36: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 Hi Ram, On Wed, 2004-05-05 at 04:41, ram.gopal@nokia.com wrote: > > Purpose of heart beat is to check whether other endpoint is alive, Right. Caveat: Remember most livelines in protocols unidirectional. > there are several ways to go for HB. > One could be clients can periodically send their liveness to servers > (and considered as ACK). So unidirectional livelines request. > - OR server can request and client respond in this case ACK is a must. So purely bidirectional liveliness. A little salt to the above - server can _sometimes_ ask for response; not always. It reduces amount of traffic. This is the feature i was requesting for. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 15:25: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 PAA06755 for ; Wed, 5 May 2004 15:25: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 1BLRpN-0005i3-JI for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 15:13:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45JD9At021942 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 15:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRhV-0007Z9-37 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 15:05: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 PAA05170 for ; Wed, 5 May 2004 15:04: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 1BLRhS-0006O7-4w for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:04:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRgU-00067V-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:03:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLRfv-0005qc-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRZn-0007qz-Pj; Wed, 05 May 2004 14:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRUk-0005Em-72 for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 14:51: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 OAA04349 for ; Wed, 5 May 2004 14:51: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 1BLRUh-0002dQ-BO for forces-protocol@ietf.org; Wed, 05 May 2004 14:51:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRTj-0002L2-00 for forces-protocol@ietf.org; Wed, 05 May 2004 14:50:47 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLRSl-0001lx-00 for forces-protocol@ietf.org; Wed, 05 May 2004 14:49:47 -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 i45InjJL016064; Wed, 5 May 2004 18:49:45 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 i45InVxB007013; Wed, 5 May 2004 18:49: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 M2004050511491100327 ; Wed, 05 May 2004 11:49: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); Wed, 5 May 2004 11:49: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] Conference call ? Message-ID: <468F3FDA28AA87429AD807992E22D07EE40DE9@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call ? Thread-Index: AcQyU9i7PSwIRbGATbq9irSrBEaGWAAfCgbQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 05 May 2004 18:49:11.0697 (UTC) FILETIME=[A7BD4810:01C432D1] 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, 5 May 2004 11:49:10 -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 can setup a teleconference call for this Friday (May 7th), either at 8 AM PST or 5/6 PM PST. Let me know which timing will work for you guys, especially Weiming, Ligang ? If Friday is not good, then may be we can have one on Monday (May 10th)... again either morning or evening depending on your preferences ? Let me know, Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Hi, Teleconference is ok for us, though I more prefer the Netmeeting (just afraid some may not use it). Also, I need to check if teleconference is available for us, and will let you know soon. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Avri, > I would strongly recommend we scrub 2.a before moving on. Its probably > the most critical part. No rush. I would rather be late than sorry. > I am wondering whether there might not be a utility in having a conference call at some point to run through some of the remaining knots. Though we are continents apart, there are time that almost work with the Pacific US early in the AM and China late at night. [HK] I think this is a good idea, to make fast progress. Although, it might be difficult for Weiming with the time difference and English barrier. What do others think ? I remember that Ram had also proposed this in the past. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 15:37:02 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07331 for ; Wed, 5 May 2004 15:37: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 1BLS7J-00062s-4t for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 15:31:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45JVfUN023238 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 15:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRs2-0007M5-43 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 15:15: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 PAA06276 for ; Wed, 5 May 2004 15:15: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 1BLRs0-0001dQ-Ug for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:15:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRr4-0001MO-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:14:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLRqD-00015s-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 15:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRjT-0000gv-Hd; Wed, 05 May 2004 15:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRbh-0000AW-8I for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 14: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 OAA04819 for ; Wed, 5 May 2004 14: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 1BLRbe-0004jR-9c for forces-protocol@ietf.org; Wed, 05 May 2004 14:58:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRat-0004S6-00 for forces-protocol@ietf.org; Wed, 05 May 2004 14:58:12 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLRa1-00042l-00 for forces-protocol@ietf.org; Wed, 05 May 2004 14:57:17 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i45Iv06p013341; Wed, 5 May 2004 18:57:00 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i45IutJk029364; Wed, 5 May 2004 18:57: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 M2004050511563832401 ; Wed, 05 May 2004 11:56:38 -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, 5 May 2004 11:56: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EE40E00@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyVhZ/x5HwkPv/SISENSF+m23AAQAe6BlA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" Cc: X-OriginalArrivalTime: 05 May 2004 18:56:38.0110 (UTC) FILETIME=[B1D27FE0:01C432D2] 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, 5 May 2004 11:56: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 Weiming, Seems like this is again cause of our English barrier. Since you don't seem to realize what your comment implied, atleast this was not intentional. Anyways, hope we don't have such misunderstandings in the future. regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Tuesday, May 04, 2004 9:01 PM To: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header Hormuzd, I'm very unhappy with your reply. Could you show me where I show my rude? I think you should respect others more. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Sent: Wednesday, May 05, 2004 11:53 AM Subject: RE: [Forces-protocol] topic 4c: Common Header Weiming, I find your comment below, rather rude. If you notice the summary of volunteers that I sent out, it has names of all the members of the team not just one person. Also, I have already put your name on the Protocol Msgs. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming [Weiming] I think every one here in our design team put lots of time for it. Msgs are the core part of the protocol, and also note that we are a design team, therefore I definitely don't think it is proper to have only one person for the work. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:13:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26323 for ; Wed, 5 May 2004 22:13: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 1BLYMn-0007ze-R5 for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:12:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462C5lE030723 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYIG-0005ta-OP for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22: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 WAA25893 for ; Wed, 5 May 2004 22:07: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 1BLYID-0007BS-PN for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:07:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYH4-0006nM-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:06:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYGI-0006UY-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:05:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLY5M-0000dV-Oe; Wed, 05 May 2004 21:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLY3b-00063b-Tg for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 21:52: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 VAA25143 for ; Wed, 5 May 2004 21:52: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 1BLY3Y-0002P0-TA for forces-protocol@ietf.org; Wed, 05 May 2004 21:52:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLY2e-00026C-00 for forces-protocol@ietf.org; Wed, 05 May 2004 21:51:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLY2F-0001nM-00 for forces-protocol@ietf.org; Wed, 05 May 2004 21:50:52 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 6 May 2004 10:03:27 +0800 Message-ID: <004101c4330c$0394e410$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" Cc: References: <468F3FDA28AA87429AD807992E22D07EE40E00@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header 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: Thu, 6 May 2004 09:46:55 +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, Thank you for the reply. Maybe we also experience some cultural difference here, not sure. Anyway, if it had made you a little unhappy, pls believe that it was absolutely not my intention. Let's move forward. Best regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" Cc: Sent: Thursday, May 06, 2004 2:56 AM Subject: RE: [Forces-protocol] topic 4c: Common Header Weiming, Seems like this is again cause of our English barrier. Since you don't seem to realize what your comment implied, atleast this was not intentional. Anyways, hope we don't have such misunderstandings in the future. regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] Sent: Tuesday, May 04, 2004 9:01 PM To: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header Hormuzd, I'm very unhappy with your reply. Could you show me where I show my rude? I think you should respect others more. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Sent: Wednesday, May 05, 2004 11:53 AM Subject: RE: [Forces-protocol] topic 4c: Common Header Weiming, I find your comment below, rather rude. If you notice the summary of volunteers that I sent out, it has names of all the members of the team not just one person. Also, I have already put your name on the Protocol Msgs. Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming [Weiming] I think every one here in our design team put lots of time for it. Msgs are the core part of the protocol, and also note that we are a design team, therefore I definitely don't think it is proper to have only one person for the work. _______________________________________________ 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 May 5 22:27:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26820 for ; Wed, 5 May 2004 22:27: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 1BLYZG-0003fR-Ae for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:24:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462OwYl014093 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYUj-0002DK-4o for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:20: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 WAA26639 for ; Wed, 5 May 2004 22:20: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 1BLYUg-0003Xm-0g for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:20:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYTl-0003EJ-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:19:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYSt-0002vJ-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:18:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYOg-0000IG-RL; Wed, 05 May 2004 22:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYK3-0006o2-Lw for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:09: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 WAA26113 for ; Wed, 5 May 2004 22:09: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 1BLYK0-00003t-JC for forces-protocol@ietf.org; Wed, 05 May 2004 22:09:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYJ6-0007XX-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:08: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 1BLYI6-0006rs-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:07:14 -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 i4626xK7006921; Thu, 6 May 2004 02:06:59 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 i4624i5u016027; Thu, 6 May 2004 02:04:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004050519064109907 ; Wed, 05 May 2004 19:06:41 -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, 5 May 2004 19:06:41 -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: peering WAS(Re: [Forces-protocol] Summary : Protocol Messages:topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EEABD94@orsmsx408.jf.intel.com> Thread-Topic: peering WAS(Re: [Forces-protocol] Summary : Protocol Messages:topic 3 & 4a Thread-Index: AcQyqSJMo/YuhIljRTaPds0drgYMUAAZW7SQ From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: , X-OriginalArrivalTime: 06 May 2004 02:06:41.0295 (UTC) FILETIME=[C5B811F0:01C4330E] 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, 5 May 2004 19:06: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 Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > Subscribe/Unsubscribe msg > [Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I > don't think Jamal agrees this also. A config or a Event msg can do this well. I think we need config messages going from FE to CE informing it of events as well. Not all events fit under this message, but a subset does. Is this what you are refering to Weiming? Just remember that not all events fit in that model. Also the subscription is needed otherwise the default should be you get no events. [HK] Just to clarify again, you are saying that we need a Subscribe msg, right ? Just want to clear this one, Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:41:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27857 for ; Wed, 5 May 2004 22:41: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 1BLYnk-0001S8-Mk for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:39:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462dueh005579 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYl4-0007o1-Sm for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:37: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 WAA27518 for ; Wed, 5 May 2004 22:37: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 1BLYl1-0001FG-Li for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:37:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYjG-0000bv-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:35:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYiS-0000I5-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:34:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYh2-0006kx-Rt; Wed, 05 May 2004 22:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYbS-0004X2-LG for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22: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 WAA26817 for ; Wed, 5 May 2004 22:27: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 1BLYbP-0005gl-C9 for forces-protocol@ietf.org; Wed, 05 May 2004 22:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYaW-0005Ob-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:26:16 -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 1BLYa7-000560-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:25:51 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050519293845:8194 ; Wed, 5 May 2004 19:29:38 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Robert Haas , forces-protocol@ietf.org, Weiming Wang In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE40424@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE40424@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083810348.1068.30.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 05/05/2004 07:29:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:29:41 PM, Serialize complete at 05/05/2004 07:29:41 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: 05 May 2004 22:25: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is actually one challenge with keeping the LFBid in the header: You cant mix different LFBs in one batch. In order to send a batch with different LFB commands you have to send a batch of separate PL messages. We could introduce an "opaque" LFBid which translates to "look inside the message body for LFB type" and then that could be used for mixed LFB messages. cheers, jamal On Tue, 2004-05-04 at 16:31, Khosravi, Hormuzd M wrote: > Robert, > > Thanks for the clarification. I like your reasoning. Pls see my > comments below. > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com] > [..] > The idea behind the LFB TypeID is to be able to easily > broadcast a message to all instances of a particular LFB class > in an NE, without having to address these LFBs individually. > > For instance, this can be useful if we want to get all > interfaces active, or if we want to update a route in all FEs. > > It greatly simplifies the use of the PL as one can start > downloading routes to the FEs without even knowing the ID of > the FEs or of the LFBs. Can call this a "plug-and-play" > feature, which is invaluable from a user's perspective. > > More precisely, I see the following three cases of interest > (with increasing scope): > > dest ID: FE x, LFBType: y addresses all LFBs > of type y in FE x > dest ID: group FE z, LFBType: y addresses all LFBS of > type y in the group z of FEs. > dest ID: FE broadcast, LFBType: y addresses all LFBS of > type y in all FEs in the NE. > > [HK] I like this use of the LFB Type ID, this is a good > reason for having it in the common header. We had proposed a > different approach for addressing LFBs of same type, but this > is also fine. > > regards > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:41:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27888 for ; Wed, 5 May 2004 22:41: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 1BLYnk-0001SM-PA for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:39:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462duX0005592 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYl5-0007o3-FP for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:37: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 WAA27521 for ; Wed, 5 May 2004 22:37: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 1BLYl2-0001FL-9F for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:37:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYjH-0000c3-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:35:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYig-0000I7-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:34:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYh3-0006l7-20; Wed, 05 May 2004 22:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYcR-0004tR-R2 for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:28: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 WAA26852 for ; Wed, 5 May 2004 22: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 1BLYcO-00061M-Hw for forces-protocol@ietf.org; Wed, 05 May 2004 22:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYbQ-0005h6-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:27:13 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLYb8-0005Oi-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:26: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 i462QvJL015292; Thu, 6 May 2004 02:26:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i462Ni6M023815; Thu, 6 May 2004 02:24:30 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 M2004050519262312014 ; Wed, 05 May 2004 19:26: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, 5 May 2004 19:26: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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEABD9A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyktG8x0/C5tm1SoiXGO2SmiE9kwAfi0Yw From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 06 May 2004 02:26:23.0771 (UTC) FILETIME=[868796B0:01C43311] 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, 5 May 2004 19:26: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, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Tue, 2004-05-04 at 23:46, Khosravi, Hormuzd M wrote: > [HK]=20 > I think HB msgs are special as such (we have put them in a separate > category in the Reqs as well) and we definitely need responses for them. > It might be better to define HBs are separate msgs rather than > Events...do you agree ?=20 That sounds reasonable. Note, however, i gave that as just as an example because we used that feature. There could be vendor specific messages which may have these needs. What is the cost of adding such a feature? [HK] So just to clarify, you would like to have an ACK flag in the header to indicate whether you need a Response/Ack for a particular msg or not...correct ? If that is the case, then I agree that this is not very costly, just 1 bit in the header...I can live with this if you think this is something your customers want. I will always have this turned on in my code, cause all our customers want responses for all the control msgs. Let me know if this one is resolved, then ? > In any case, the point that I was trying to make > is that you do need responses for all your control msgs such as > Association Setup, Config, Query, Subscribe, State Maintenance (I notice > I forgot to all Responses for the latter 2 in my protocol message > summary). Do you agree ? Except when you deliver such messages from FE towards CE where they come out as events. Did we settle on whether we want to do this? Refer to discussion on peer model. [HK] I think we did, but let me respond to the peer model email. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:50:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28119 for ; Wed, 5 May 2004 22: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 1BLYuh-0004VK-Po for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462l7sO017310 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYp2-00025d-10 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:41: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 WAA27811 for ; Wed, 5 May 2004 22:41: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 1BLYoy-0002dZ-Lz for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:41:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYo4-0002Hd-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:40:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYmz-0001vZ-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:39:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYjx-0007mR-2P; Wed, 05 May 2004 22: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 1BLYhX-000722-Q4 for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22: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 WAA27366 for ; Wed, 5 May 2004 22:33: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 1BLYhU-0007k9-As for forces-protocol@ietf.org; Wed, 05 May 2004 22:33:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYge-0007Nl-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:32: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 1BLYes-0006o7-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:30:46 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050519343379:8201 ; Wed, 5 May 2004 19:34:33 -0700 Subject: RE: peering WAS(Re: [Forces-protocol] Summary : Protocol Messages:topic 3 & 4a From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Wang,Weiming" , forces-protocol@ietf.org, avri@acm.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EEABD94@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EEABD94@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083810592.1067.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 05/05/2004 07:34:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:34:36 PM, Serialize complete at 05/05/2004 07:34:36 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: 05 May 2004 22:30:43 -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-05-05 at 22:06, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > Subscribe/Unsubscribe msg > > [Weiming] This is a little ridiculous msg. Do you mean 'event > sub/unsub' ? I > > don't think Jamal agrees this also. A config or a Event msg can do > this well. > > I think we need config messages going from FE to CE informing it of > events as well. Not all events fit under this message, but a subset > does. > Is this what you are refering to Weiming? Just remember that not all > events fit in that model. Also the subscription is needed otherwise the > default should be you get no events. > > [HK] Just to clarify again, you are saying that we need a Subscribe msg, > right ? > Just want to clear this one, I think a subscribe message is important to have. In our implementation we didnt have a subscribe message and the default was to send all config events. This sometimes resulted in a lot of annoying unneeded messages. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:51:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28140 for ; Wed, 5 May 2004 22:51: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 1BLYuh-0004VY-S6 for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462l7KC017323 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYp9-00025f-2X for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:41: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 WAA27840 for ; Wed, 5 May 2004 22:41: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 1BLYp5-0002eZ-Qs for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:41:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYoN-0002K4-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:40:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYnO-0001zL-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:39:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYjx-0007mZ-6M; Wed, 05 May 2004 22: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 1BLYhY-000724-BB for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22: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 WAA27370 for ; Wed, 5 May 2004 22:33: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 1BLYhV-0007kF-0T for forces-protocol@ietf.org; Wed, 05 May 2004 22:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYgg-0007O3-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:32:38 -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 1BLYet-0006oZ-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:30: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 2004050519343679:8202 ; Wed, 5 May 2004 19:34:36 -0700 Subject: RE: [Forces-protocol] Conference call ? From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: "Wang,Weiming" , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EE40DE9@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EE40DE9@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083810621.1066.40.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 05/05/2004 07:34:37 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:34:38 PM, Serialize complete at 05/05/2004 07:34:38 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: 05 May 2004 22:30:46 -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 will attend the call. Probably Weiming who is on the most different time zone should pick and i will be available. Lets have some agenda to avoid chaso. cheers, jamal On Wed, 2004-05-05 at 14:49, Khosravi, Hormuzd M wrote: > Hi All, > > I can setup a teleconference call for this Friday (May 7th), either at 8 > AM PST or 5/6 PM PST. > Let me know which timing will work for you guys, especially Weiming, > Ligang ? > If Friday is not good, then may be we can have one on Monday (May > 10th)... again either morning or evening depending on your preferences ? > > Let me know, > > Thanks > Hormuzd > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > > Hi, > > Teleconference is ok for us, though I more prefer the Netmeeting (just > afraid > some may not use it). Also, I need to check if teleconference is > available for > us, and will let you know soon. > > Thank you. > Weiming > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > > Avri, > > > I would strongly recommend we scrub 2.a before moving on. Its probably > > the most critical part. No rush. I would rather be late than sorry. > > > > I am wondering whether there might not be a utility in having a > conference call at some point to run through some of the remaining > knots. Though we are continents apart, there are time that almost work > with the Pacific US early in the AM and China late at night. > > [HK] I think this is a good idea, to make fast progress. Although, it > might be difficult for Weiming with the time difference and English > barrier. What do others think ? I remember that Ram had also proposed > this in the past. > > > _______________________________________________ > 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 May 5 22:51: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 WAA28185 for ; Wed, 5 May 2004 22:51: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 1BLYuh-0004Vl-UM for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462l7lU017336 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYpC-00025h-Cy for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:41: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 WAA27847 for ; Wed, 5 May 2004 22:41: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 1BLYp9-0002f0-5Z for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:41:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYoQ-0002KT-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:40:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYng-0001zQ-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:39:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYjx-0007mh-AK; Wed, 05 May 2004 22: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 1BLYhZ-000726-42 for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:33: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 WAA27375 for ; Wed, 5 May 2004 22: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 1BLYhV-0007kL-QX for forces-protocol@ietf.org; Wed, 05 May 2004 22:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYgg-0007OB-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:32: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 1BLYeu-0006f6-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:30:48 -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 i462UpJL017066; Thu, 6 May 2004 02:30:51 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 i462SN5s025859; Thu, 6 May 2004 02:28:24 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 M2004050519301812420 ; Wed, 05 May 2004 19:30: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, 5 May 2004 19:30: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEABD9D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQyZFJHAWuiBWUJTl+PIs0SeLT7OAArXfkw From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 06 May 2004 02:30:17.0974 (UTC) FILETIME=[12202160:01C43312] 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, 5 May 2004 19:30: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, All > > > There will also be times when i wont be interested in > > the response (and this is not just in the case of events). > > > > [HK] Most of the Control Plane Apps such as routing/switching protocols > > that I have worked with need responses for any commands such as Config > > or Query msgs. Could you give some examples of what msgs you don't need > > responses for ? Also, how do we satisfy the timeliness requirement which > > without protocol level responses or acks ? > > I dont wanna speculate about others - i think the possibilty is > certainly there, but a simple example is a PL heartbeat scheme where i > can occasionaly request for an ACK. We have used this and found it > useful. > [Weiming]I think the scheme as 'Pls let me know when you encounter difficulties, otherwise pls don't bother' should be very useful for ForCES architecture, where we can think of the heavy burden of FE resources and lack of b/w resouces for CE-FE interconnection. E.g., (as I mentioned in my earlier post), to add huge routes, I would prefer to let FE send back responses when it finds some difficulty to do that. App level response is different from low level responses. Still take add huge routes as e.g., App level may only get a response by low level (not necessariy from FE) to tell that the huge routes (as one task) has been implemented sucessfully (or stoped owing to an error). It's not always the case the app. level needs the huge responses. [HK] I just responded to this in context to Jamal's email. I am fine with an ACK flag in the header, if you guys find this useful. It hasn't been our experience but that's fine. Hope that helps, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:51: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 WAA28204 for ; Wed, 5 May 2004 22:51: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 1BLYuo-0004Wi-Cz for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:47:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462lE8l017395 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYrs-0002zl-J7 for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:44: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 WAA27962 for ; Wed, 5 May 2004 22:44: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 1BLYrp-0003a9-6l for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:44:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYqr-0003HL-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:43:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYpw-0002y1-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22: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 1BLYnp-0001c4-9j; Wed, 05 May 2004 22: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 1BLYkE-0007mo-Hl for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:36: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 WAA27514 for ; Wed, 5 May 2004 22:36: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 1BLYkB-0000xe-7i for forces-protocol@ietf.org; Wed, 05 May 2004 22:36:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYjB-0000bB-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:35: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 1BLYiI-0000Gk-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:34: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 2004050519380629:8206 ; Wed, 5 May 2004 19:38:06 -0700 Subject: RE: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EEABD9A@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EEABD9A@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1083810856.1064.47.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 05/05/2004 07:38:06 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/05/2004 07:38:08 PM, Serialize complete at 05/05/2004 07:38: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: 05 May 2004 22:34: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-05-05 at 22:26, Khosravi, Hormuzd M wrote: > [HK] So just to clarify, you would like to have an ACK flag in the > header to indicate whether you need a Response/Ack for a particular msg > or not...correct ? If that is the case, then I agree that this is not > very costly, just 1 bit in the header...I can live with this if you > think this is something your customers want. I will always have this > turned on in my code, cause all our customers want responses for all the > control msgs. Let me know if this one is resolved, then ? I think the ACK flag would be sufficient to close this. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:55:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28394 for ; Wed, 5 May 2004 22:55: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 1BLZ0V-0006j1-9Z for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462r7eS025847 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYwm-0005CY-5Q for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:49: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 WAA28100 for ; Wed, 5 May 2004 22:49: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 1BLYwi-00057u-P0 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:49:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYvk-0004pG-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:48:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYuv-0004Wj-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:47:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYse-0003G0-Vg; Wed, 05 May 2004 22: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 1BLYo6-0001ds-D9 for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:40: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 WAA27701 for ; Wed, 5 May 2004 22:40: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 1BLYo2-0002HL-UE for forces-protocol@ietf.org; Wed, 05 May 2004 22:40:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYmy-0001vD-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:39:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLYlt-0001Ot-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:38:02 -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 1BLYlv-0006qE-9I for forces-protocol@ietf.org; Wed, 05 May 2004 22:38:03 -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 i462bsJL020274; Thu, 6 May 2004 02:37:54 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 i462ZR5q029063; Thu, 6 May 2004 02: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 M2004050519372013126 ; Wed, 05 May 2004 19:37: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, 5 May 2004 19:37: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEABDA0@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQzEqROVVZZxv5oTEGvIe5nBFuJiAAAEEGQ From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 06 May 2004 02:37:20.0697 (UTC) FILETIME=[0E168A90:01C43313] 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, 5 May 2004 19:37:20 -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 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > [HK] So just to clarify, you would like to have an ACK flag in the > header to indicate whether you need a Response/Ack for a particular msg > or not...correct ? If that is the case, then I agree that this is not > very costly, just 1 bit in the header...I can live with this if you > think this is something your customers want. I will always have this > turned on in my code, cause all our customers want responses for all the > control msgs. Let me know if this one is resolved, then ? I think the ACK flag would be sufficient to close this.=20 [HK] Consider this closed from my side (assuming you agree with the description for the Ack flag above) _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 22:57:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28539 for ; Wed, 5 May 2004 22:57: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 1BLZ3E-0007vr-0v for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 22:55:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i462ttsD030483 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 22:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZ1Y-0007A0-LD for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 22:54: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 WAA28344 for ; Wed, 5 May 2004 22:54: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 1BLZ1V-0006iy-4C for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:54:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLZ0W-0006O2-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:53:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLYzV-0005wv-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 22:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYvZ-0004rT-PC; Wed, 05 May 2004 22:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLYq4-0002Pa-LN for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22: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 WAA27919 for ; Wed, 5 May 2004 22:42: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 1BLYq1-0002yg-9N for forces-protocol@ietf.org; Wed, 05 May 2004 22:42:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLYpA-0002fF-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:41:25 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLYoS-0002HE-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:40:40 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i462eT6p023919; Thu, 6 May 2004 02:40:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i462eZJa010325; Thu, 6 May 2004 02:40:44 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 M2004050519400730801 ; Wed, 05 May 2004 19:40:07 -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, 5 May 2004 19:40:07 -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 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEABDA2@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQzEXTRwNr6VBxoTOCH+u2HUKRwpAAAamdw From: "Khosravi, Hormuzd M" To: Cc: "Robert Haas" , , "Weiming Wang" X-OriginalArrivalTime: 06 May 2004 02:40:07.0495 (UTC) FILETIME=[7181E570:01C43313] 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, 5 May 2004 19:40:07 -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 There is actually one challenge with keeping the LFBid in the header: You cant mix different LFBs in one batch. In order to send a batch with=20 different LFB commands you have to send a batch of separate PL messages. We could introduce an "opaque" LFBid which translates to "look inside the message body for LFB type" and then that could be used for mixed LFB messages. [HK] Good point, thanks for bringing this up. I remember having discussed this before. Yes we will need the concept of "opaque" LFB Type ID, if we have it in the common header and have to support Command Bundling (diff LFB Types in the same msg) regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 5 23:15:54 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 XAA29484 for ; Wed, 5 May 2004 23:15: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 1BLZJA-0005bp-0P for forces-protocol-archive@odin.ietf.org; Wed, 05 May 2004 23:12:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i463CNDP021526 for forces-protocol-archive@odin.ietf.org; Wed, 5 May 2004 23:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZBX-0002XZ-BW for forces-protocol-web-archive@optimus.ietf.org; Wed, 05 May 2004 23:04: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 XAA28951 for ; Wed, 5 May 2004 23:04: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 1BLZBS-0002IQ-3t for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 23:04:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLZ9b-0001gX-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 23:02:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLZ95-0001LY-00 for forces-protocol-web-archive@ietf.org; Wed, 05 May 2004 23:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZ6E-0000if-3l; Wed, 05 May 2004 22:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZ4n-0008NR-FA for forces-protocol@optimus.ietf.org; Wed, 05 May 2004 22:57: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 WAA28582 for ; Wed, 5 May 2004 22:57: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 1BLZ4j-0007ka-Re for forces-protocol@ietf.org; Wed, 05 May 2004 22:57:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLZ3o-0007PE-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:56:33 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLZ2j-0006kr-00 for forces-protocol@ietf.org; Wed, 05 May 2004 22:55:26 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i462sv4a030639; Thu, 6 May 2004 02:54:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i462soJm016337; Thu, 6 May 2004 02:55: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 M2004050519544332052 ; Wed, 05 May 2004 19:54: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); Wed, 5 May 2004 19:54: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: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEABDB2@orsmsx408.jf.intel.com> Thread-Topic: peering model WAS(Re: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQypxdI/HXGD+0GTHyS2yspHSPptwAbaUJQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 06 May 2004 02:54:43.0415 (UTC) FILETIME=[7B98AE70:01C43315] 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, 5 May 2004 19:54: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 Avri, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > [HK] Avri, are you talking about Distributed routing or distributed > control plane in terms offloading some of the routing protocol > functionality such as neighbor discovery (e.g. OSPF Hello offload) onto > FEs ? If so, I agree with your view and believe we had covered this in > the Requirements for the FE Model (Protocol Offload functions support). > > [ad] yes, that is essentially it. In this case the FE will be=20 informing the CE of results that, while not a command, is essentially a=20 peering type of activity in the split of operations between the CE and=20 FE. [hk] Sure I agree. I think we can deal with this and other such situations using Event msgs from the FE and defining special Event Types which will cover this case (actually in this case, it might just be an event from OSPF Hello offload LFB on the FE). Also, we can similarly cover the case when the FE is configured by an external Mgmt entity which is not the CE. Do you agree ? Thanks for bringing this up, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 01:58:58 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 BAA06889 for ; Thu, 6 May 2004 01:58: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 1BLbsj-0007be-1m for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 01:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i465vHNB029239 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 01:57:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbpw-0006gH-9F for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 01:54: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 BAA06518 for ; Thu, 6 May 2004 01:54: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 1BLbpt-0003x7-1H for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:54:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbow-0003bc-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:53:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLbo8-0003HV-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:52:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbjk-0004Qx-Ms; Thu, 06 May 2004 01: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 1BLbdH-0001cq-92 for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 01:41: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 BAA05730 for ; Thu, 6 May 2004 01:41: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 1BLbdD-0007CV-T6 for forces-protocol@ietf.org; Thu, 06 May 2004 01:41:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbcF-0006qQ-00 for forces-protocol@ietf.org; Thu, 06 May 2004 01:40:15 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLbb0-0006Du-00 for forces-protocol@ietf.org; Thu, 06 May 2004 01:38:58 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 6 May 2004 13:51:30 +0800 Message-ID: <029201c4332b$dca18640$020aa8c0@wwm1> From: "Weiming Wang" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028F_01C4336E.E870C420" 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: Thu, 6 May 2004 13:34:51 +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_028F_01C4336E.E870C420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Um9iZXJ0LCBKYW1hbCwgYW5kIGFsbCwNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KICBGcm9tOiBSb2JlcnQgSGFhcyANCiAgVG86IFdhbmcsV2VpbWluZyANCiAgQ2M6IGZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZyANCiAgU2VudDogV2VkbmVzZGF5LCBNYXkgMDUsIDIwMDQgNDo1 MCBQTQ0KICBTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gdG9waWMgNGM6IENvbW1vbiBI ZWFkZXI6IGJhdGNoaW5nDQoNCg0KICBXZWltaW5nLA0KICBJIHRoaW5rIHRoZSBhcHByb2FjaCBv ZiAgJ1BscyBsZXQgbWUga25vdyB3aGVuIHlvdSBlbmNvdW50ZXIgZGlmZmljdWx0aWVzLCBvdGhl cndpc2UgcGxzIGRvbid0IGJvdGhlcicgaXMgaW5kZWVkIHVzZWZ1bC4gTGV0IG1lIGVsYWJvcmF0 ZSBhIGJpdCBvbiB0aGlzLiBTb3JyeSBmb3IgdGhlIHJhdGhlciBsb25nIG1lc3NhZ2UuIEknbGwg ZGV2b3RlIGFub3RoZXIgbm90ZSB0byB3aW5kb3dpbmcuDQoNCiAgIEJhdGNoaW5nIGlzIHVzZWQg dG8gZ3JvdXAgY29tbWFuZHMgdG9nZXRoZXIuIEVhY2ggY29tbWFuZCBwb3NzaWJseSBoYXMgaXRz IG93biBzZXF1ZW5jZSBudW1iZXIgKG9yIHRyYW5zYWN0aW9uIG51bWJlciksIA0KICBbV2VpbWlu Z11ObyBwcm9ibGVtIHdpdGggdGhlIG5hbWUgc2VxdWVuY2UgbnVtYmVyLCBJIGFsc28gbGlrZSBp dC4NCiAgb3IgdGhlIGdyb3VwIGhhcyBpdHMgb3duIG51bWJlciB3aXRoIHN1Ym51bWJlcnMgZm9y IGVhY2ggbWVzc2FnZSAodGhpcyByZW1haW5zIHRvIGJlIGRlY2lkZWQuKSBUaGUgbWFpbiB1c2Ug b2YgYmF0Y2hpbmcgaXMgdG8gcGVyZm9ybSBhdG9taWNpdHk6IA0KICBbV2VpbWluZ11JIGFncmVl IHRoaXMsIHRob3VnaCBJIHdhcyBhIGxpdHRsZSBjb25mdXNlZCBiZWZvcmUgd2l0aCB0aGUgbm90 aW9ucyAnYmF0Y2hpbmcsIGF0b21pY2l0eSwgMi1waGFzZSBjb21taXQsIGFsbCBvciBub3RoaW5n Jy4gQ2FuIHdlIHVuZGVyc3RhbmQgdGhhdCB0aGV5IGFyZSBhbGwgdGFyZ2V0aW5nIHRoZSBzYW1l IHRoaW5nOiBhbGwgb3Igbm90aGluZz8gT3Igd2UgaGF2ZSBvdGhlciBwdXJwb3NlIGZvciBiYXRj aGluZyBzdWNoIGFzIGp1c3QgZm9yIHBhY2tldGl6aW5nPw0KDQogIGFsbCBjb21tYW5kcyBpbiB0 aGUgZ3JvdXAgd2lsbCBiZSBwZXJmb3JtZWQgYXQgdGhlIHNhbWUgdGltZSBvciBub25lIHdpbGwg YmUgcGVyZm9ybWVkLiBUaGlzIGlzIHdoZXJlIDItcGhhc2UgY29tbWl0IGtpY2tzIGluOiBhbGwg Y29tbWFuZHMgYXJlIGZpcnN0IHRyYW5zbWl0dGVkIHRvIHRoZSBGRSwgYW5kIHVubGVzcyB0aGUg RkUgcmVwb3J0cyBhbiBlcnJvciwgdGhlIENFIGNhbiB1bHRpbWF0ZWx5IGlzc3VlIGEgY29tbWl0 IGNvbW1hbmQgc28gYWxsIHRoZXNlIGNvbW1hbmRzIGFyZSBleGVjdXRlZCBpbiBhbiBhdG9taWMg b3BlcmF0aW9uIGF0IHRoZSBGRS4NCiAgW1dlaW1pbmddWWVzLg0KICBXZSBpbnZlc3RpZ2F0ZWQg dGhlIGlkZWEgb2YgcGFja2luZyBtdWx0aXBsZSBjb21tYW5kcyBpbiB0aGUgc2FtZSBGb3JDRVMg bWVzc2FnZSAoaXQgc2F2ZXMgcXVpdGUgc29tZSBoZWFkZXJzIGFuZCB0aGUgYXNzb2NpYXRlZCBw cm9jZXNzaW5nDQogIFtXZWltaW5nXUhlcmUsIEkgdGhpbmsgd2UgbmVlZCB0byBldmFsdWF0ZSBp ZiB0aGUgaGVhZGVycyBhcmUgd29ydGggdGhlcmUgb3Igbm90LiBNeSBvcmlnaW5hbCBpZGVhIHdh cyBpdCB3YXMgbm90IHdvcnRoIGl0IChkdXJpbmcgR1JNUCB0aW1lKSwgYnV0IG5vdyBJIGNoYW5n ZSBzb21lLiBKdXN0IGNoZWNrIHRoZSBwb3NzaWJsZSBoZWFkZXIgZmllbGRzLCB3ZSBtYXkgZmlu ZCB0aGF0IG1vc3Qgb2YgdGhlbSBhcmUgd29ydGggdGhlcmUsIGFuZCB0aGUgcmV3YXJkIGlzIGdy ZWF0LCBhbGxvd2luZyBwZXIgbXNnIEFDSywgYW5kIHdpdGggbXVjaCBsZXNzIGNvbXBsZXhpdHkg Zm9yIHByb3RvY29sIHN0YXRlIHRyYWNlLg0KDQogICkuIEFzIGEgbW90aXZhdGlvbiwgdGhpbmsg b2YgYWRkaW5nIDEwMCcwMDAgcm91dGVzIG9uIGFuIEZFOiBzaG91bGQgd2UgdXNlIDEwMCcwMDAg Rm9yQ0VTIG1lc3NhZ2VzLCBvciBvbmx5IDEwMDAgKHNheSAxNSBieXRlcyBwZXIgcm91dGUgdXBk YXRlIGNvbW1hbmQgdG8gYmUgZ2VuZXJvdXMsIHdpdGggYSAxNTAwIGJ5dGVzIE1UVSBzaXplLCBv ciBldmVuIGxlc3MgaWYgd2UgaGF2ZSBKdW1ibyBmcmFtZXMpID8gDQoNCiAgTm90ZSB0aGF0IGhh dmluZyBtYW55IGNvbW1hbmRzIGluIHRoZSBzYW1lIEZvckNFUyBtZXNzYWdlIHJlc3VsdHMgaW4g c2xpZ2hsdHkgbW9yZSBjb21wbGV4IGVycm9yL2FjayByZXBvcnRpbmcuIFRha2UgdGhpcyBleGFt cGxlOiB0d28gY29tbWFuZHMgQSBhbmQgQiBpbiB0aGUgc2FtZSBGb3JDRVMgbWVzc2FnZSBpc3N1 ZWQgYnkgYSBDRS4gRkUgZXhlY3V0ZXMgYm90aCBvZiAgdGhlbSwgYnV0IG9ubHkgQSBzdWNjZWVk cy4gSXQgc2hvdWxkIHJlcG9ydCB0aGlzIHNvbWVob3cgdG8gdGhlIENFLiBBIHBvc3NpYmxlIHNv bHV0aW9uIGlzIHRvIHJldHVybiB0aGUgb3JpZ2luYWwgbWVzc2FnZSB0cmltbWVkIGRvd24gc3Vj aCB0aGF0IGl0IGNvbnRhaW5zIGV4YWN0bHkgdHdvIHJlc3BvbnNlcywgYSBwb3NpdGl2ZSBhbmQg YSBuZWdhdGl2ZSBvbmUuDQogIFtXZWltaW5nXVllcywgSSB0aGluayB5b3UgYXJlIGFsc28gdHJ5 aW5nIHRvIHNlZSB3aGljaCBpcyBiZXR0ZXIgYW1vbmcgdGhlIGZvbGxvd2luZyB0d28gcG9zc2li bGUgYmF0Y2hpbmcgc2NoZW1lczoNCiAgMS4gQmF0Y2hlZCBtc2dzIGluIG9uZSBwYWNrZXQgb3Ig ZXZlbiBrZWVwaW5nIHRoZSBtc2dzIHNlcGFyYXRlbHkgYXMgaXRzIG9yaWdpbiwgd2hpbGUgd2l0 aCBzb21lIGZsYWdzIHN1Y2ggYXMgQXRvbWljaXR5IGFuZC9vciBEb25lIEZsYWcgdG8gaW5kaWNh dGUgdGhlIGJlZ2luIGFuZCB0aGUgZW5kLg0KICAyLiBNYW55IGNvbW1hbmRzIGluIG9uZSBtc2cg YXMgeW91IG1lbnRpb25lZCBhYm92ZS4gDQogIEkgYSBsaXR0bGUgbW9yZSBpbmNsaW5lIHRvICMx IHNjaGVtZSwgYXMgdGhlIHJlYXNvbiBJIG1lbnRpb25lZCBhYm92ZS4gQnV0IHRoZXJlIGlzIGEg cmVtYWluZWQgaXNzdWUgZm9yIHN1Y2Nlc3NmdWwgYXRvbWljaXR5LCB0aGF0IGlzLCBpdCBkb2Vz IG5vdCBzdXBwb3J0IG11bHRpcHVsIHRyYW5zYWN0aW9ucyBpZiB3ZSB1c2UgZGlmZmVyZW50IHNl cXVlY2UgbnVtYmVyIGZvciBkaWZmZXJlbnQgbXNncyBpbiBhIGJhdGNoLCBhbmQgaWYgd2UgdXNl IHNhbWUgc2VxdWVuY2UgbnVtYmVyIGZvciBhbGwgdGhlIG1zZ3MsIHRoZW4gaXQgbWF5IHJlc3Vs dCBpbiBhbWJpZ3VpdHkgZm9yIG1zZyBtZWFuaW5nIGFuZCBoYXJkIGZvciBBQ0suIFRoZXJlZm9y ZSwgSSB0cnkgdG8gcHJvcG9zZSB0byB1c2UgYSBzdWIgbXNnIG51bWJlciB0byBzZWUgaWYgaXQg aXMgZmVhc2libGUgZm9yIHRoZSBwdXJwb3NlLiBQbHMgbGV0IG1lIHRyeSB0byBzdW1tYXJpemUg c3RoIHdlJ3YgYWxyZWFkeSBnb3QgKE5ldGxpbmsyPykgYWxvbmcgd2l0aCB0aGUgYmF0Y2ggbXNn ICMgdGhvdWdodCBhcyBmb2xsb3dzOg0KDQogIEJhdGNoaW5nIG1zZyBhczoNCg0KICBNc2cxOk1z ZzI6Li4uTXNnTiAoZWl0aGVyIG9uZSBwYWNrZXQgb3Igc2VwYXJhdGVkIHBhY2tldHMpDQoNCiAg SW4gaGVhZGVycyBvZiBhbGwgdGhlIG1zZ3MsDQoNCiAgU2VxdWVuY2UgTnVtYmVyczogYWxsIHRo ZSBzYW1lLCB0aGF0IG1lYW5zIGEgYmF0Y2ggaXMgdHJlYXRlZCBhcyBhIHRyYW5zYWN0aW9uLg0K ICBBVE0gZmxhZzogbWFyayB0aGUgZW5kIG9mIGJhdGNoaW5nIChlLmcuLDAgZm9yIE1zZ04sIGFu ZCBhbHNvIGEgc2lnbmFsIHRvIGV4Y3V0ZSB0aGUgYmF0Y2gsIDEgZm9yIG90aGVycywgYW5kIGFs c28gYXMgYSBzaWduYWwgdG8gcmVzZXJ2ZSBpdCkNCiAgQUNLIGZsYWc6IGluZGljYXRlIGlmIHRo aXMgbXNnIG5lZWQgYW4gQUNLDQogIEJhdGNoTXNnTnVtOiBtYXJrIHRoZSBiYXRlaGVkIG1zZyBz ZXF1ZW5jZSBudW1iZXIsIDAgZm9yIE1zZzEsIC4uLiAoTi0xKSBmb3IgTXNnTi4gQW55IEFDSyBz aG91bGQgaW5jbHVkZSBCYXRjaE1zZ051bSBhcyB3ZWxsIGFzIG90aGVycy4NCg0KICBBbnkgb2Yg dGhlIE1zZyBpbiB0aGUgYmF0Y2ggc3RpbGwgY2FuIGJlIGZyYWdtZW50ZWQgaWYgaXQgZXhjZWVk cyB0aGUgTVRVLCBhIEZSRyBmbGFnIGlzIHVzZWQgdG8gdHJlYXQgaXQsIHdpdGggdGhlIHRoaW5r aW5nIHRoYXQgdGhlIHBhY2tldHMgd2lsbCBub3QgYmUgcmVvcmRlcmVkLg0KICBSb2I6IGNhbiB5 b3UgdHJ5IHRvIHByZXNlbnQgYSBzdW1tYXJ5IHJlZ2FyZGluZyB0aGUgIzIgc2NoZW1lLCBzbyB0 aGF0IHdlIGNhbiBjYXJlZnVsbHkgY29tcGFyZSBhbmQgZXZhbHVhdGUgaXQ/DQoNCiAgSSB0aGlu ayB3ZSBzaG91bGQgZm9jdXMgb3VyIGVmZm9ydCBvbiBkZWZpbmluZyB0aGUgZm9ybWF0IGFuZCBz dGF0ZSBtYWNoaW5lIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgYXMgc2VlbiBvbiB0aGUgd2lyZSAN CiAgW1dlaW1pbmddIFllcywgYWdyZWVkLiBUaGUgc3RhdGUgdHJhbnNmZXIgZGlhZ3JhbSBpcyBp bXBvcnRhbnQuDQoNCiAgKGFuZCBkZWZpbmUgYSBmZXcgZW5jYXBzdWxhdGlvbiBtZXRob2RzIGZv ciBGb3JDRVMgb3ZlciBVRFAsIFRDUCwgZXRjLCB3aXRoIHNwZWNpZmljIHJlc2VydmVkIHBvcnQg bnVtYmVycw0KICBbV2VpbWluZ11JJ20gbm90IHN1cmUgaWYgVE1MIHdpbGwgZG8gdGhpcyBvciBu b3QuDQogICkuIFNvIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB3b3JyeSBhYm91dCB0aGUgd2F5 IHRoZSBBcHBzIGdldCBub3RpZmljYXRpb25zIGZyb20gdGhlIFBMIGFuZCBzbyBvbiwgYW5kIGlm IGEgc2luZ2xlL211bHRpcGxlIHNpZ25hbC9zIGlzL2FyZSB1c2VkIHRvIGNvbmZpcm0gdGhhdCBh IGJhdGNoIG9mIG1lc3NhZ2VzIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBleGVjdXRlZC4gVGhpcyB3 aWxsIHJlbWFpbiB2ZW5kb3Igc3BlY2lmaWMuIERvIHlvdSBoYXZlIGRpZmZlcmVudCB2aWV3cyA/ DQogIFtXZWltaW5nXUFncmVlZC4NCg0KICBDaGVlcnMsDQogIC1Sb2JlcnQNCg0KICBDaGVlcnMs DQogIFdlaW1pbmcNCg== ------=_NextPart_000_028F_01C4336E.E870C420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9ND5Sb2JlcnQsIEphbWFsLCBhbmQgYWxs LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURE SU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JE RVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBz dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZv bnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXJoYUB6dXJpY2guaWJt LmNvbSBocmVmPSJtYWlsdG86cmhhQHp1cmljaC5pYm0uY29tIj5Sb2JlcnQgSGFhczwvQT4gDQog IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86 PC9CPiA8QSB0aXRsZT13bXdhbmdAbWFpbC5oemljLmVkdS5jbiANCiAgaHJlZj0ibWFpbHRvOndt d2FuZ0BtYWlsLmh6aWMuZWR1LmNuIj5XYW5nLFdlaW1pbmc8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1mb3Jj ZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBNYXkg MDUsIDIwMDQgNDo1MCBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbRm9yY2VzLXByb3RvY29sXSB0b3BpYyA0Yzog DQogIENvbW1vbiBIZWFkZXI6IGJhdGNoaW5nPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8 RElWPldlaW1pbmcsPEJSPkkgdGhpbmsgdGhlIGFwcHJvYWNoIG9mJm5ic3A7ICdQbHMgbGV0IG1l IGtub3cgd2hlbiB5b3UgDQogIGVuY291bnRlciBkaWZmaWN1bHRpZXMsIG90aGVyd2lzZSBwbHMg ZG9uJ3QgYm90aGVyJyBpcyBpbmRlZWQgdXNlZnVsLiBMZXQgbWUgDQogIGVsYWJvcmF0ZSBhIGJp dCBvbiB0aGlzLiBTb3JyeSBmb3IgdGhlIHJhdGhlciBsb25nIG1lc3NhZ2UuIEknbGwgZGV2b3Rl IA0KICBhbm90aGVyIG5vdGUgdG8gd2luZG93aW5nLjxCUj48QlI+Jm5ic3A7QmF0Y2hpbmcgaXMg dXNlZCB0byBncm91cCBjb21tYW5kcyANCiAgdG9nZXRoZXIuIEVhY2ggY29tbWFuZCBwb3NzaWJs eSBoYXMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXIgKG9yIHRyYW5zYWN0aW9uIA0KICBudW1iZXIp LCA8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPltXZWlt aW5nXU5vIHByb2JsZW0gd2l0aCB0aGUgbmFtZSBzZXF1ZW5jZSBudW1iZXIsIEkgDQogIGFsc28g bGlrZSBpdC48L0ZPTlQ+PC9ESVY+DQogIDxESVY+b3IgdGhlIGdyb3VwIGhhcyBpdHMgb3duIG51 bWJlciB3aXRoIHN1Ym51bWJlcnMgZm9yIGVhY2ggbWVzc2FnZSAodGhpcyANCiAgcmVtYWlucyB0 byBiZSBkZWNpZGVkLikgVGhlIG1haW4gdXNlIG9mIGJhdGNoaW5nIGlzIHRvIHBlcmZvcm0gYXRv bWljaXR5OiANCiAgPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PltX ZWltaW5nXUkgYWdyZWUgdGhpcywgdGhvdWdoIEkgd2FzIGEgbGl0dGxlIGNvbmZ1c2VkIA0KICBi ZWZvcmUgd2l0aCB0aGUgbm90aW9ucyAnYmF0Y2hpbmcsIGF0b21pY2l0eSwgMi1waGFzZSBjb21t aXQsIGFsbCBvciBub3RoaW5nJy4gDQogIENhbiB3ZSB1bmRlcnN0YW5kIHRoYXQgdGhleSBhcmUg YWxsIHRhcmdldGluZyB0aGUgc2FtZSB0aGluZzogYWxsIG9yIG5vdGhpbmc/IA0KICBPciB3ZSBo YXZlIG90aGVyIHB1cnBvc2UgZm9yIGJhdGNoaW5nIHN1Y2ggYXMganVzdCBmb3IgDQogIHBhY2tl dGl6aW5nPzwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj5hbGwgY29tbWFuZHMgaW4gdGhlIGdy b3VwIHdpbGwgYmUgcGVyZm9ybWVkIGF0IHRoZSBzYW1lIHRpbWUgb3Igbm9uZSB3aWxsIA0KICBi ZSBwZXJmb3JtZWQuIFRoaXMgaXMgd2hlcmUgMi1waGFzZSBjb21taXQga2lja3MgaW46IGFsbCBj b21tYW5kcyBhcmUgZmlyc3QgDQogIHRyYW5zbWl0dGVkIHRvIHRoZSBGRSwgYW5kIHVubGVzcyB0 aGUgRkUgcmVwb3J0cyBhbiBlcnJvciwgdGhlIENFIGNhbiANCiAgdWx0aW1hdGVseSBpc3N1ZSBh IGNvbW1pdCBjb21tYW5kIHNvIGFsbCB0aGVzZSBjb21tYW5kcyBhcmUgZXhlY3V0ZWQgaW4gYW4g DQogIGF0b21pYyBvcGVyYXRpb24gYXQgdGhlIEZFLjxCUj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPltXZWltaW5nXVllcy48L0ZPTlQ+PEJSPldlIA0KICBpbnZlc3RpZ2F0ZWQg dGhlIGlkZWEgb2YgcGFja2luZyBtdWx0aXBsZSBjb21tYW5kcyBpbiB0aGUgc2FtZSBGb3JDRVMg bWVzc2FnZSANCiAgKGl0IHNhdmVzIHF1aXRlIHNvbWUgaGVhZGVycyBhbmQgdGhlIGFzc29jaWF0 ZWQgcHJvY2Vzc2luZzwvRElWPg0KICA8RElWPltXZWltaW5nXUhlcmUsIEkgdGhpbmsmbmJzcDt3 ZSBuZWVkIHRvIGV2YWx1YXRlIGlmIHRoZSBoZWFkZXJzIGFyZSB3b3J0aCANCiAgdGhlcmUgb3Ig bm90LiBNeSBvcmlnaW5hbCBpZGVhIHdhcyBpdCB3YXMgbm90IHdvcnRoIGl0IChkdXJpbmcgR1JN UCB0aW1lKSwgYnV0IA0KICBub3cgSSBjaGFuZ2Ugc29tZS4gSnVzdCBjaGVjayB0aGUgcG9zc2li bGUgaGVhZGVyIGZpZWxkcywgd2UgbWF5IGZpbmQgdGhhdCANCiAgbW9zdCBvZiB0aGVtIGFyZSB3 b3J0aCB0aGVyZSwgYW5kIHRoZSByZXdhcmQgaXMgZ3JlYXQsIGFsbG93aW5nIHBlciBtc2cgQUNL LCANCiAgYW5kIHdpdGggbXVjaCBsZXNzIGNvbXBsZXhpdHkgZm9yIHByb3RvY29sIHN0YXRlIHRy YWNlLjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+KS4gQXMgYSBtb3RpdmF0aW9uLCB0aGluayBvZiBhZGRpbmcgMTAw JzAwMCByb3V0ZXMgb24gYW4gRkU6IHNob3VsZCB3ZSANCiAgdXNlIDEwMCcwMDAgRm9yQ0VTIG1l c3NhZ2VzLCBvciBvbmx5IDEwMDAgKHNheSAxNSBieXRlcyBwZXIgcm91dGUgdXBkYXRlIA0KICBj b21tYW5kIHRvIGJlIGdlbmVyb3VzLCB3aXRoIGEgMTUwMCBieXRlcyBNVFUgc2l6ZSwgb3IgZXZl biBsZXNzIGlmIHdlIGhhdmUgDQogIEp1bWJvIGZyYW1lcykgPyA8QlI+PEJSPk5vdGUgdGhhdCBo YXZpbmcgbWFueSBjb21tYW5kcyBpbiB0aGUgc2FtZSBGb3JDRVMgDQogIG1lc3NhZ2UgcmVzdWx0 cyBpbiBzbGlnaGx0eSBtb3JlIGNvbXBsZXggZXJyb3IvYWNrIHJlcG9ydGluZy4gVGFrZSB0aGlz IA0KICBleGFtcGxlOiB0d28gY29tbWFuZHMgQSBhbmQgQiBpbiB0aGUgc2FtZSBGb3JDRVMgbWVz c2FnZSBpc3N1ZWQgYnkgYSBDRS4gRkUgDQogIGV4ZWN1dGVzIGJvdGggb2YmbmJzcDsgdGhlbSwg YnV0IG9ubHkgQSBzdWNjZWVkcy4gSXQgc2hvdWxkIHJlcG9ydCB0aGlzIA0KICBzb21laG93IHRv IHRoZSBDRS4gQSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0byByZXR1cm4gdGhlIG9yaWdpbmFsIG1l c3NhZ2UgDQogIHRyaW1tZWQgZG93biBzdWNoIHRoYXQgaXQgY29udGFpbnMgZXhhY3RseSB0d28g cmVzcG9uc2VzLCBhIHBvc2l0aXZlIGFuZCBhIA0KICBuZWdhdGl2ZSBvbmUuPC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PltXZWltaW5nXVllcywgSSB0aGluayB5b3Ug YXJlIGFsc28gdHJ5aW5nIHRvIHNlZSB3aGljaCBpcyANCiAgYmV0dGVyIGFtb25nIHRoZSBmb2xs b3dpbmcgdHdvIHBvc3NpYmxlIGJhdGNoaW5nIHNjaGVtZXM6PC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4xLiBCYXRjaGVkIG1zZ3MgaW4gb25lIHBhY2tl dCZuYnNwO29yIGV2ZW4mbmJzcDtrZWVwaW5nIHRoZSANCiAgbXNncyBzZXBhcmF0ZWx5IGFzIGl0 cyBvcmlnaW4sIHdoaWxlJm5ic3A7d2l0aCZuYnNwO3NvbWUgZmxhZ3Mgc3VjaCBhcyANCiAgQXRv bWljaXR5IGFuZC9vciBEb25lIEZsYWcgdG8gaW5kaWNhdGUgdGhlIGJlZ2luIGFuZCB0aGUgZW5k LjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+Mi4gTWFu eSBjb21tYW5kcyBpbiBvbmUgbXNnIGFzIHlvdSBtZW50aW9uZWQgYWJvdmUuIA0KICA8L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkkgYSBsaXR0bGUgbW9y ZSBpbmNsaW5lIHRvICMxIHNjaGVtZSwgYXMgdGhlIHJlYXNvbiBJIA0KICBtZW50aW9uZWQgYWJv dmUuIEJ1dCB0aGVyZSBpcyBhJm5ic3A7cmVtYWluZWQgaXNzdWUgZm9yIHN1Y2Nlc3NmdWwgYXRv bWljaXR5LCANCiAgdGhhdCBpcywgaXQgZG9lcyBub3Qgc3VwcG9ydCBtdWx0aXB1bCB0cmFuc2Fj dGlvbnMgaWYgd2UgdXNlIGRpZmZlcmVudCBzZXF1ZWNlIA0KICBudW1iZXIgZm9yIGRpZmZlcmVu dCBtc2dzIGluIGEgYmF0Y2gsIGFuZCBpZiB3ZSB1c2Ugc2FtZSBzZXF1ZW5jZSBudW1iZXIgZm9y IA0KICBhbGwgdGhlIG1zZ3MsIHRoZW4gaXQgbWF5IHJlc3VsdCBpbiBhbWJpZ3VpdHkgZm9yIG1z ZyBtZWFuaW5nIGFuZCBoYXJkIGZvciANCiAgQUNLLiBUaGVyZWZvcmUsIEkgdHJ5IHRvIHByb3Bv c2UgdG8gdXNlIGEgc3ViIG1zZyBudW1iZXImbmJzcDt0byBzZWUgaWYgaXQgaXMgDQogIGZlYXNp YmxlIGZvciB0aGUgcHVycG9zZS4mbmJzcDtQbHMgbGV0IG1lIHRyeSB0byBzdW1tYXJpemUmbmJz cDtzdGggd2UndiANCiAgYWxyZWFkeSBnb3QgKE5ldGxpbmsyPykmbmJzcDthbG9uZyB3aXRoJm5i c3A7dGhlIGJhdGNoIG1zZyAjIHRob3VnaHQgYXMgDQogIGZvbGxvd3M6PC9GT05UPjwvRElWPg0K ICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog IDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkJhdGNoaW5nIG1zZyBhczo8L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+TXNnMTpNc2cyOi4uLk1z Z04gKGVpdGhlciBvbmUgcGFja2V0IG9yIHNlcGFyYXRlZCANCiAgcGFja2V0cyk8L0ZPTlQ+PC9E SVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+SW4gaGVhZGVycyBvZiBhbGwg dGhlIG1zZ3MsPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PlNlcXVlbmNlIE51bWJlcnM6Jm5ic3A7YWxsIHRoZSBzYW1lLCB0aGF0IG1lYW5zIGEgYmF0Y2gg aXMgDQogIHRyZWF0ZWQgYXMgYSB0cmFuc2FjdGlvbi48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkFUTSBmbGFnOiBtYXJrIHRoZSBlbmQgb2YgYmF0Y2hp bmcgKGUuZy4sMCBmb3IgTXNnTiwgYW5kIA0KICBhbHNvIGEgc2lnbmFsIHRvIGV4Y3V0ZSB0aGUg YmF0Y2gsIDEgZm9yIG90aGVycywgYW5kIGFsc28gYXMgYSBzaWduYWwgdG8gDQogIHJlc2VydmUg aXQpPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5BQ0sg ZmxhZzogaW5kaWNhdGUgaWYgdGhpcyBtc2cgbmVlZCBhbiBBQ0s8L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkJhdGNoTXNnTnVtOiBtYXJrIHRoZSBiYXRl aGVkIG1zZyBzZXF1ZW5jZSBudW1iZXIsIDAgZm9yIA0KICBNc2cxLCAuLi4gKE4tMSkgZm9yIE1z Z04uIEFueSBBQ0sgc2hvdWxkIGluY2x1ZGUgQmF0Y2hNc2dOdW0gYXMgd2VsbCBhcyANCiAgb3Ro ZXJzLjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9G T05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5Bbnkg b2YgdGhlIE1zZyBpbiB0aGUgYmF0Y2ggc3RpbGwgY2FuIGJlIGZyYWdtZW50ZWQgaWYgaXQgDQog IGV4Y2VlZHMgdGhlIE1UVSwgYSBGUkcgZmxhZyBpcyB1c2VkIHRvJm5ic3A7dHJlYXQgaXQsIHdp dGggdGhlIHRoaW5raW5nIHRoYXQgDQogIHRoZSBwYWNrZXRzIHdpbGwgbm90IGJlIHJlb3JkZXJl ZC48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxl PSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAg PERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+Um9iOiBjYW4geW91IHRyeSB0byBwcmVz ZW50IGEgc3VtbWFyeSByZWdhcmRpbmcgdGhlICMyIA0KICBzY2hlbWUsIHNvIHRoYXQgd2UgY2Fu IGNhcmVmdWxseSBjb21wYXJlIGFuZCBldmFsdWF0ZSBpdD88L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj5J IHRoaW5rIHdlIHNob3VsZCBmb2N1cyBvdXIgZWZmb3J0IG9uIGRlZmluaW5nIHRoZSBmb3JtYXQg YW5kIHN0YXRlIA0KICBtYWNoaW5lIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgYXMgc2VlbiBvbiB0 aGUgd2lyZSA8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+W1dlaW1p bmddIFllcywgYWdyZWVkLiBUaGUgc3RhdGUgdHJhbnNmZXIgZGlhZ3JhbSBpcyANCiAgaW1wb3J0 YW50LjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9G T05UPiZuYnNwOzwvRElWPg0KICA8RElWPihhbmQgZGVmaW5lIGEgZmV3IGVuY2Fwc3VsYXRpb24g bWV0aG9kcyBmb3IgRm9yQ0VTIG92ZXIgVURQLCBUQ1AsIGV0YywgDQogIHdpdGggc3BlY2lmaWMg cmVzZXJ2ZWQgcG9ydCBudW1iZXJzPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7PltXZWltaW5nXUknbSBub3Qgc3VyZSBpZiBUTUwgd2lsbCBkbyB0aGlzIG9yIA0KICBu b3QuPC9GT05UPjwvRElWPg0KICA8RElWPikuIFNvIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB3 b3JyeSBhYm91dCB0aGUgd2F5IHRoZSBBcHBzIGdldCANCiAgbm90aWZpY2F0aW9ucyBmcm9tIHRo ZSBQTCBhbmQgc28gb24sIGFuZCBpZiBhIHNpbmdsZS9tdWx0aXBsZSBzaWduYWwvcyBpcy9hcmUg DQogIHVzZWQgdG8gY29uZmlybSB0aGF0IGEgYmF0Y2ggb2YgbWVzc2FnZXMgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IGV4ZWN1dGVkLiBUaGlzIA0KICB3aWxsIHJlbWFpbiB2ZW5kb3Igc3BlY2lmaWMu IERvIHlvdSBoYXZlIGRpZmZlcmVudCB2aWV3cyA/PEJSPjxGT05UIA0KICBmYWNlPSYjMjM0MzU7 JiMyMDMwNzs+W1dlaW1pbmddQWdyZWVkLjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4NCiAgPERJVj48QlI+Q2hlZXJzLDxCUj4tUm9iZXJ0PEJS PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5DaGVlcnMsPC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5XZWltaW5nPC9GT05U PjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_028F_01C4336E.E870C420-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 02:02: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 CAA09316 for ; Thu, 6 May 2004 02: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 1BLbvR-0000Ua-S2 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 02:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46605lR001886 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 02: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 1BLbuH-0008JW-K6 for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 01:58: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 BAA06876 for ; Thu, 6 May 2004 01:58: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 1BLbuE-0005QP-Ba for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:58:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbtD-00052k-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:57:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLbsV-0004eQ-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 01:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbpe-0006Xv-IY; Thu, 06 May 2004 01:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbn4-00053s-7D for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 01: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 BAA06360 for ; Thu, 6 May 2004 01:51: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 1BLbn0-0002vT-SX for forces-protocol@ietf.org; Thu, 06 May 2004 01:51:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLblw-0002Ze-00 for forces-protocol@ietf.org; Thu, 06 May 2004 01:50:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLbka-0001Tg-00 for forces-protocol@ietf.org; Thu, 06 May 2004 01:48:53 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 6 May 2004 14:00:16 +0800 Message-ID: <029e01c4332d$1645baf0$020aa8c0@wwm1> From: "Weiming Wang" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4099026D.70903@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: windowing MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029B_01C43370.22259AA0" 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: Thu, 6 May 2004 13:43:37 +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_029B_01C43370.22259AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBSb2Jl cnQgSGFhcyANCiAgVG86IFdhbmcsV2VpbWluZyANCiAgQ2M6IGZvcmNlcy1wcm90b2NvbEBpZXRm Lm9yZyANCiAgU2VudDogV2VkbmVzZGF5LCBNYXkgMDUsIDIwMDQgMTE6MDQgUE0NCiAgU3ViamVj dDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIHRvcGljIDRjOiBDb21tb24gSGVhZGVyOiB3aW5kb3dp bmcNCg0KDQogIEFsbCwNCg0KICBMZXQgbWUgdHJ5IHRvIGJyaWVmbHkgdGFja2xlIHRoZSB3aW5k b3dpbmcgaXNzdWUgbm93Og0KDQogIEZpcnN0LCB3ZSBzaG91bGQgZGVmaW5pdGVseSBub3Qgc2hv b3QgZm9yIGEgVENQLWxpa2UgZmxvdy1jb250cm9sIHNvbHV0aW9uIGF0IHRoZSBQTCBsZXZlbC4N Cg0KICBJbnN0ZWFkLCB3ZSBjb3VsZCBkZWZpbmUgYSBoaWdoLXByaW9yaXR5L2NvbnRyb2wgbWVz c2FnZSB0aGF0IGFuIEZFIGNhbiBzZW5kIGluIGNhc2Ugb2Ygb3ZlcnJ1bnMuIA0KICBbV2VtaW5n XUNvdWxkIHlvdSBleHBsYWluIGEgbGl0dGxlIG1vcmUgb24gdGhpcy4gU29ycnksIEkganVzdCBj YW4gbm90IGNhdGNoIHVwIHdpdGggaXQgd2VsbC4gSXMgdGhlIHByaW9yaXR5IHRoZSBzYW1lIGFz IHRoYXQgd2UgZGVmaW5lZCBpbiB0aGUgaGVhZGVyPw0KDQogIE92ZXJydW5zIG9jY3VyIHdoZW4g dGhlIEZFIGlzIHRvbyBzbG93IGF0IHByb2Nlc3NpbmcgdGhlIGluY29taW5nIENFIG1lc3NhZ2Vz LCBhbmQgaXRzIHJlY2VpdmUgYnVmZmVycyBhcmUgZnVsbC4gVGhlIHJlYWN0aW9uIG9mIHRoZSBD RSB0byB0aGUgb3ZlcnJ1biBtZXNzYWdlIGNhbiBiZSBsZWZ0IHZlbmRvciBzcGVjaWZpYy4gSXQg dGhlIFRNTCBpcyBUQ1AsIHRoZW4gdGhlIFRDUCBmbG93LWNvbnRyb2wgd2lsbCBhdXRvbWF0aWNh bGx5IHRha2UgY2FyZSBvZiB0aGlzIGFuZCBvdmVycnVucyB3aWxsIG5vdCBiZSBnZW5lcmF0ZWQg YnkgdGhlIEZFLiBPdGhlciBUTUxzIG1pZ2h0IG5vdCBwcm92aWRlIHN1Y2ggY2FwYWJpbGl0eSwg aGVuY2UgdGhlIG5lZWQgZm9yIHRoaXMgKGV4dHJlbWVseSBzaW1wbGUpIHdpbmRvd2luZyBzY2hl bWUgYXQgdGhlIFBMIGxldmVsIHVzaW5nIG92ZXJydW4gbWVzc2FnZXMuDQogIFtXZWltaW5nXSBJ cyBpdCBhIHNwZWNpZmljIG1zZyB3YWxraW5nIGJldHdlZW4gQ0UgYW5kIEZFIHRvIG1hbmFnZSB0 aGUgb3ZlcnJ1bnM/DQoNCiAgTGV0IG1lIGtub3cgd2hhdCBvdGhlciBhcHByb2FjaGVzIHlvdSB3 b3VsZCBjb25zaWRlci4gVGhlIGFwcHJvYWNoIGFib3ZlIGZpdHMgaW4gdGhlICdQbHMgbGV0IG1l IGtub3cgd2hlbiB5b3UgZW5jb3VudGVyIGRpZmZpY3VsdGllcywgb3RoZXJ3aXNlIHBscyBkb24n dCBib3RoZXInIGNhdGVnb3J5IFdlaW1pbmcgYWxyZWFkeSBzdWdnZXN0ZWQuDQoNCiAgUmVnYXJk cywNCiAgLVJvYmVydA0KDQogIENoZWVycywNCiAgV2VpbWluZw0K ------=_NextPart_000_029B_01C43370.22259AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaSBSb2JlcnQsPC9GT05UPjwvRElW Pg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJ TkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHgg c29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYg c3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBm b250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1yaGFAenVyaWNoLmli bS5jb20gaHJlZj0ibWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbSI+Um9iZXJ0IEhhYXM8L0E+IA0K ICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRv OjwvQj4gPEEgdGl0bGU9d213YW5nQG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0bzp3 bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2FuZyxXZWltaW5nPC9BPiA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9Zm9y Y2VzLXByb3RvY29sQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGll dGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgTWF5 IDA1LCAyMDA0IDExOjA0IFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1 OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtGb3JjZXMtcHJvdG9jb2xdIHRvcGljIDRj OiANCiAgQ29tbW9uIEhlYWRlcjogd2luZG93aW5nPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPkFsbCw8QlI+ PEJSPkxldCBtZSB0cnkgdG8gYnJpZWZseSB0YWNrbGUgdGhlIHdpbmRvd2luZyBpc3N1ZSANCiAg bm93OjxCUj48QlI+Rmlyc3QsIHdlIHNob3VsZCBkZWZpbml0ZWx5IG5vdCBzaG9vdCBmb3IgYSBU Q1AtbGlrZSBmbG93LWNvbnRyb2wgDQogIHNvbHV0aW9uIGF0IHRoZSBQTCBsZXZlbC48QlI+PEJS Pkluc3RlYWQsIHdlIGNvdWxkIGRlZmluZSBhIA0KICBoaWdoLXByaW9yaXR5L2NvbnRyb2wgbWVz c2FnZSB0aGF0IGFuIEZFIGNhbiBzZW5kIGluIGNhc2Ugb2Ygb3ZlcnJ1bnMuIDwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5bV2VtaW5nXUNvdWxkIHlvdSBleHBsYWlu IGEgbGl0dGxlIG1vcmUgb24gdGhpcy4gU29ycnksIA0KICBJJm5ic3A7anVzdCBjYW4gbm90IGNh dGNoIHVwIHdpdGggaXQgd2VsbC4gSXMgdGhlIHByaW9yaXR5IHRoZSBzYW1lIGFzIHRoYXQgd2Ug DQogIGRlZmluZWQgaW4gdGhlIGhlYWRlcj88L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+T3Zl cnJ1bnMgb2NjdXIgd2hlbiB0aGUgRkUgaXMgdG9vIHNsb3cgYXQgcHJvY2Vzc2luZyB0aGUgaW5j b21pbmcgQ0UgDQogIG1lc3NhZ2VzLCBhbmQgaXRzIHJlY2VpdmUgYnVmZmVycyBhcmUgZnVsbC4g VGhlIHJlYWN0aW9uIG9mIHRoZSBDRSB0byB0aGUgDQogIG92ZXJydW4gbWVzc2FnZSBjYW4gYmUg bGVmdCB2ZW5kb3Igc3BlY2lmaWMuIEl0IHRoZSBUTUwgaXMgVENQLCB0aGVuIHRoZSBUQ1AgDQog IGZsb3ctY29udHJvbCB3aWxsIGF1dG9tYXRpY2FsbHkgdGFrZSBjYXJlIG9mIHRoaXMgYW5kIG92 ZXJydW5zIHdpbGwgbm90IGJlIA0KICBnZW5lcmF0ZWQgYnkgdGhlIEZFLiBPdGhlciBUTUxzIG1p Z2h0IG5vdCBwcm92aWRlIHN1Y2ggY2FwYWJpbGl0eSwgaGVuY2UgdGhlIA0KICBuZWVkIGZvciB0 aGlzIChleHRyZW1lbHkgc2ltcGxlKSB3aW5kb3dpbmcgc2NoZW1lIGF0IHRoZSBQTCBsZXZlbCB1 c2luZyANCiAgb3ZlcnJ1biBtZXNzYWdlcy48L0RJVj4NCiAgPERJVj5bV2VpbWluZ10gSXMgaXQg YSBzcGVjaWZpYyBtc2cgd2Fsa2luZyBiZXR3ZWVuIENFIGFuZCBGRSB0byBtYW5hZ2UgdGhlIA0K ICBvdmVycnVucz88QlI+PEJSPkxldCBtZSBrbm93IHdoYXQgb3RoZXIgYXBwcm9hY2hlcyB5b3Ug d291bGQgY29uc2lkZXIuIFRoZSANCiAgYXBwcm9hY2ggYWJvdmUgZml0cyBpbiB0aGUgJ1BscyBs ZXQgbWUga25vdyB3aGVuIHlvdSBlbmNvdW50ZXIgZGlmZmljdWx0aWVzLCANCiAgb3RoZXJ3aXNl IHBscyBkb24ndCBib3RoZXInIGNhdGVnb3J5IFdlaW1pbmcgYWxyZWFkeSANCiAgc3VnZ2VzdGVk LjxCUj48QlI+UmVnYXJkcyw8QlI+LVJvYmVydDxCUj48QlI+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IA0KICBzaXplPTI+Q2hlZXJzLDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5i c3A7PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_029B_01C43370.22259AA0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 02:13:12 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 CAA20173 for ; Thu, 6 May 2004 02:13: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 1BLc6e-0000is-04 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 02:11:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i466BdG8002760 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 02:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLc5V-0008VE-SX for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 02:10: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 CAA17493 for ; Thu, 6 May 2004 02:10: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 1BLc5S-0001ot-Da for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:10:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLc4V-0001T3-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:09:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLc3c-00018E-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:08:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLc29-0006Jb-1j; Thu, 06 May 2004 02: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 1BLc0h-000534-Lt for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 02:05: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 CAA12632 for ; Thu, 6 May 2004 02:05: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 1BLc0e-00004i-6e for forces-protocol@ietf.org; Thu, 06 May 2004 02:05:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbzm-0007Wm-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:04:35 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLbzA-00079Z-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:03:57 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 6 May 2004 14:16:07 +0800 Message-ID: <02ac01c4332f$4d85cb70$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EEABDA2@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header 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: Thu, 6 May 2004 13:59: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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, Jamal, Sorry I did not catch up with LFB id discussion well. Just a few questions regarding it: 1. We seem pay more attention to LFBtype ID, what about the LFB Instance ID then? 2. Jamal, I have a feeling that you seem very careful not to put too many flags in msg bodies. I wonder if there are some technical disadvantage or barrier behind to do like this according to your implementation experience? Hornestly, I'm short of experiences on this. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Jamal, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] There is actually one challenge with keeping the LFBid in the header: You cant mix different LFBs in one batch. In order to send a batch with different LFB commands you have to send a batch of separate PL messages. We could introduce an "opaque" LFBid which translates to "look inside the message body for LFB type" and then that could be used for mixed LFB messages. [HK] Good point, thanks for bringing this up. I remember having discussed this before. Yes we will need the concept of "opaque" LFB Type ID, if we have it in the common header and have to support Command Bundling (diff LFB Types in the same msg) 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 May 6 02:37: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 CAA22292 for ; Thu, 6 May 2004 02:37: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 1BLcTr-00059y-Nx for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 02:35:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i466Zd3u019822 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 02:35:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcPj-0003Vj-9K for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 02: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 CAA21803 for ; Thu, 6 May 2004 02:31: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 1BLcPf-0001Dr-Ng for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:31:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcOg-0000ss-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:30:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLcNc-0000Es-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 02:29:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcKg-00011y-6z; Thu, 06 May 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 1BLcF3-00061y-Sg for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 02:20: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 CAA21243 for ; Thu, 6 May 2004 02:20: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 1BLcF0-0005BE-6u for forces-protocol@ietf.org; Thu, 06 May 2004 02:20:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcE1-0004qf-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:19:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLcCx-0004Cy-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:18:15 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 6 May 2004 14:30:39 +0800 Message-ID: <02c201c43331$54f7b330$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EEABD9A@orsmsx408.jf.intel.com> <1083810856.1064.47.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header 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: Thu, 6 May 2004 14:13:58 +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 also think a ACK flag to give customers more flexibility will be benificial for our protocol being futher more widely used. One thing now remained is we may now need to decide if we put ACK as a specific msg and included in the msgs, or just let others such as common header section do it. I also think, by carefully designing the ACK msg, we may able to have it only as one msg to include 'positive', 'negative', and specific response functions. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > On Wed, 2004-05-05 at 22:26, Khosravi, Hormuzd M wrote: > > > [HK] So just to clarify, you would like to have an ACK flag in the > > header to indicate whether you need a Response/Ack for a particular msg > > or not...correct ? If that is the case, then I agree that this is not > > very costly, just 1 bit in the header...I can live with this if you > > think this is something your customers want. I will always have this > > turned on in my code, cause all our customers want responses for all the > > control msgs. Let me know if this one is resolved, then ? > > I think the ACK flag would be sufficient to close this. > > 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 Thu May 6 03:07: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 DAA23364 for ; Thu, 6 May 2004 03:07: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 1BLcwL-0008Mw-Nm for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 03:05:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46755kC032171 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 03:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcuo-0007lc-0v for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 03: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 DAA23250 for ; Thu, 6 May 2004 03:03: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 1BLcuk-0004IW-1t for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLctm-0003xn-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:02:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLctR-0003dH-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcqT-0004pd-Fo; Thu, 06 May 2004 02: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 1BLckE-0002uQ-F1 for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 02:52: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 CAA22872 for ; Thu, 6 May 2004 02:52:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLckA-0000di-Jh for forces-protocol@ietf.org; Thu, 06 May 2004 02:52:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcjF-0000JJ-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:51:33 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLcio-0007lh-00 for forces-protocol@ietf.org; Thu, 06 May 2004 02:51:08 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 6 May 2004 15:03:33 +0800 Message-ID: <02d401c43335$edb19ce0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EE40DE9@orsmsx408.jf.intel.com> <1083810621.1066.40.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Conference call ? 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: Thu, 6 May 2004 14:46:55 +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, Maybe Friday 5/6PST is more suitable for us. We are trying our best to attend the meeting, but just want to let you know that even if we finally can not attend the meeting (I'm not sure if our equipment (Dialpad PC to phone) will support us well at that time), pls just go ahead with you others. You know, we just don't want to be a barrier for our team to speed up our process. In the case we can not join, I think a minutes may help us to understand all your ideas well. Though English is another barrier for us, it's just our pleasure to carefully listen more and try to understand your ideas:). Thank you. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Khosravi, Hormuzd M" Cc: "Wang,Weiming" ; Sent: Thursday, May 06, 2004 10:30 AM Subject: RE: [Forces-protocol] Conference call ? > I will attend the call. Probably Weiming who is on the most different > time zone should pick and i will be available. > Lets have some agenda to avoid chaso. > > cheers, > jamal > > On Wed, 2004-05-05 at 14:49, Khosravi, Hormuzd M wrote: > > Hi All, > > > > I can setup a teleconference call for this Friday (May 7th), either at 8 > > AM PST or 5/6 PM PST. > > Let me know which timing will work for you guys, especially Weiming, > > Ligang ? > > If Friday is not good, then may be we can have one on Monday (May > > 10th)... again either morning or evening depending on your preferences ? > > > > Let me know, > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming > > > > Hi, > > > > Teleconference is ok for us, though I more prefer the Netmeeting (just > > afraid > > some may not use it). Also, I need to check if teleconference is > > available for > > us, and will let you know soon. > > > > Thank you. > > Weiming > > ----- Original Message ----- > > From: "Khosravi, Hormuzd M" > > > > > > Avri, > > > > > I would strongly recommend we scrub 2.a before moving on. Its probably > > > the most critical part. No rush. I would rather be late than sorry. > > > > > > > I am wondering whether there might not be a utility in having a > > conference call at some point to run through some of the remaining > > knots. Though we are continents apart, there are time that almost work > > with the Pacific US early in the AM and China late at night. > > > > [HK] I think this is a good idea, to make fast progress. Although, it > > might be difficult for Weiming with the time difference and English > > barrier. What do others think ? I remember that Ram had also proposed > > this in the past. > > > > > > _______________________________________________ > > 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 May 6 03:14: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 DAA23587 for ; Thu, 6 May 2004 03:14: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 1BLd32-0002v3-07 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 03:12:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i467Bx5p011222 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 03:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLd2W-0002Z2-Po for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 03:11: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 DAA23450 for ; Thu, 6 May 2004 03:11: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 1BLd2S-00073B-QP for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:11:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLd1b-0006hE-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:10:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLd0j-0006MH-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 03:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLczF-0000fy-7y; Thu, 06 May 2004 03:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLcwl-0008Ne-IW for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 03:05: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 DAA23323 for ; Thu, 6 May 2004 03:05: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 1BLcwh-0004yw-Id for forces-protocol@ietf.org; Thu, 06 May 2004 03:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLcvo-0004eO-00 for forces-protocol@ietf.org; Thu, 06 May 2004 03:04:33 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLcvN-0004J2-00 for forces-protocol@ietf.org; Thu, 06 May 2004 03:04:05 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i466wlEJ007050; Thu, 6 May 2004 07:02:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i462KmJk001132; Thu, 6 May 2004 02:21:04 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 M2004050519202528972 ; Wed, 05 May 2004 19:20: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); Wed, 5 May 2004 19:20: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] Summary : Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EEABD99@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Thread-Index: AcQyqa1F9dgLadVzR+2hxUrvG3BcaAAZR/fQ From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: X-OriginalArrivalTime: 06 May 2004 02:20:25.0701 (UTC) FILETIME=[B11A7150:01C43310] 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, 5 May 2004 19: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, All -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim >=20 > Here is the list of Protocol Messages based on final comments made by > Jamal. >=20 > Association Setup, Setup Resp msg > Association Teardown msg > [Weiming] I agree to use the name 'Association'. But I can not find where Jamal > disagree to use only one msg approach, that is 'association msg'. Again, I have > to say a flag is definitely enough to indicate the command 'setup' 'setup resp', > and 'teardown'. Can you give reasons why they should be two msgs? We need to have a setup and teardown. The setup can be either accepted or rejected. Thats the general concept - and i dont think anyone disagrees with that. I personally dont care what you end up calling such messages.=20 Theres two ways to represent the messages: 1) A command for both. 2) A single command with flags differentiating the two. The first scheme has more commands being used. The second scheme indicates we need flags in the common header. I think we will have flags regardless: I know Hormuzd has tried to pinpoint where flags on the main header could be moved to be only specific to a message but i would violently disagree with such a move at this stage. I would prefer #2, but i wont fight over it. [HK] I agree with the general concept of setup, setup Resp, teardown (I think we all do) and don't want to fight over names or bits either. I will make a simple technical point...we have reserved 8 bits for Msg Type which means we can define 256 Msgs, so why not use this ? It will be much easier & efficient for someone implementing the protocol to look at the Msg type field and say if it is a Asso Setup msg, Teardown msg or Setup Resp...rather than parsing the Msg type field and then some flags and then coming to the same conclusion. Do you guys agree ?? May be we can have some middle ground like 4 bits for Msg Type, 4 bits for Msg Sub-type such that...Msg Type =3D Association & Subtype =3D = Setup or Teardown or Setup Resp. This might be easier to implement/parse and also use the bits more efficiently. Let me know what you guys think ? I am positive that we can close on this discussion soon. >=20 > Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) >=20 > [Weiming] I suggest just an 'Event msg' may be better. Event maybe insufficient if you need to have a response to a heartbeart. [HK] I agree, it might be better to have separate msg for HBs Thanks for the clarifications, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 04:34: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 EAA27352 for ; Thu, 6 May 2004 04:34: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 1BLe8u-0005II-VS for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 04:22:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i468M82f020351 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 04:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLe7W-0004Sj-P8 for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 04:20: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 EAA26713 for ; Thu, 6 May 2004 04:20: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 1BLe7T-0001Co-W3 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 04:20:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLe6W-0000om-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 04:19:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLe64-0000Rc-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 04:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLe08-0001bZ-FG; Thu, 06 May 2004 04: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 1BLdvj-0006Se-7e for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 04:08: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 EAA26100 for ; Thu, 6 May 2004 04:08: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 1BLdvg-0004L9-F5 for forces-protocol@ietf.org; Thu, 06 May 2004 04:08:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdur-0003xw-00 for forces-protocol@ietf.org; Thu, 06 May 2004 04:07:38 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLdu3-0003YW-00 for forces-protocol@ietf.org; Thu, 06 May 2004 04:06:48 -0400 Received: from wwm1 (unverified [219.82.186.205]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 6 May 2004 16:19:24 +0800 Message-ID: <030401c43340$85f4e840$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EEABD99@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary : 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: Thu, 6 May 2004 16:02:42 +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, Jamal as well, ----- Original Message ----- From: "Khosravi, Hormuzd M" Jamal, All -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim > > Here is the list of Protocol Messages based on final comments made by > Jamal. > > Association Setup, Setup Resp msg > Association Teardown msg > [Weiming] I agree to use the name 'Association'. But I can not find where Jamal > disagree to use only one msg approach, that is 'association msg'. Again, I have > to say a flag is definitely enough to indicate the command 'setup' 'setup resp', > and 'teardown'. Can you give reasons why they should be two msgs? We need to have a setup and teardown. The setup can be either accepted or rejected. Thats the general concept - and i dont think anyone disagrees with that. I personally dont care what you end up calling such messages. Theres two ways to represent the messages: 1) A command for both. 2) A single command with flags differentiating the two. The first scheme has more commands being used. The second scheme indicates we need flags in the common header. I think we will have flags regardless: I know Hormuzd has tried to pinpoint where flags on the main header could be moved to be only specific to a message but i would violently disagree with such a move at this stage. I would prefer #2, but i wont fight over it. [HK] I agree with the general concept of setup, setup Resp, teardown (I think we all do) and don't want to fight over names or bits either. I will make a simple technical point...we have reserved 8 bits for Msg Type which means we can define 256 Msgs, so why not use this ? It will be much easier & efficient for someone implementing the protocol to look at the Msg type field and say if it is a Asso Setup msg, Teardown msg or Setup Resp...rather than parsing the Msg type field and then some flags and then coming to the same conclusion. Do you guys agree ?? [Weiming] Hormuzd, what you said really confused me. This was exactly my idea. I mentioned this many times before. But at that time, seemed you as well as Jamal objected it , which made me actually give it up completely. I think now we have come to a compromise to use more sythisized msg type mode. Why should we try to break this compromise again? If you now realize we can make full use of the msg type field, then I would like to pick something more for discussion, because I think many of them have much meaning than just 'setup' teardown'. [/Weiming] May be we can have some middle ground like 4 bits for Msg Type, 4 bits for Msg Sub-type such that...Msg Type = Association & Subtype = Setup or Teardown or Setup Resp. This might be easier to implement/parse and also use the bits more efficiently. Let me know what you guys think ? I am positive that we can close on this discussion soon. > > Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) > > [Weiming] I suggest just an 'Event msg' may be better. Event maybe insufficient if you need to have a response to a heartbeart. [HK] I agree, it might be better to have separate msg for HBs [Weiming] I'm afraid it is not meant to use another msg, just the msg name for the event operation, right? Moreover, after we'v concluded that an ACK flag in the header is necessary, it is easy to let heartbeats or other events to have responses. regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 07:54: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 HAA07975 for ; Thu, 6 May 2004 07:54: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 1BLhPN-0003LO-Bt for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 07:51:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46BpLAI012854 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 07:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhOh-00030g-65 for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 07: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 HAA07821 for ; Thu, 6 May 2004 07:50: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 1BLhOg-0005fX-HH for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 07:50:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLhNi-0005Fl-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 07:49:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLhMu-0004rc-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 07:48:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhJH-0001Jp-3O; Thu, 06 May 2004 07:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhH1-0008Ny-Ql for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 07:42: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 HAA07424 for ; Thu, 6 May 2004 07:42: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 1BLhH1-0002Rh-09 for forces-protocol@ietf.org; Thu, 06 May 2004 07:42:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLhGG-00023S-00 for forces-protocol@ietf.org; Thu, 06 May 2004 07:41:56 -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 1BLhFI-0001dP-00 for forces-protocol@ietf.org; Thu, 06 May 2004 07:40:56 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050604444097:8623 ; Thu, 6 May 2004 04:44:40 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <02ac01c4332f$4d85cb70$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EEABDA2@orsmsx408.jf.intel.com> <02ac01c4332f$4d85cb70$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1083843651.1065.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 05/06/2004 04:44:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/06/2004 04:44:45 AM, Serialize complete at 05/06/2004 04:44:45 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 May 2004 07:40: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 Weiming, On Thu, 2004-05-06 at 01:59, Weiming Wang wrote: > Hormuzd, Jamal, > > Sorry I did not catch up with LFB id discussion well. Just a few questions > regarding it: > > 1. We seem pay more attention to LFBtype ID, what about the LFB Instance ID > then? Sorry, I caused the confusion by calling it LFBId. It is actually LFBTYPE that uniquely maps to the type of LFB. Do that substituion in the text and it will make sense. The Instanc ID should be in the body message. > 2. Jamal, I have a feeling that you seem very careful not to put too many flags > in msg bodies. I wonder if there are some technical disadvantage or barrier > behind to do like this according to your implementation experience? Hornestly, > I'm short of experiences on this. I am not picky. I think flags in the main header are for extending the message. A lot of of protocols i know keep them there - thats where my bias is coming from. I have no problem with putting flags in the submsg;however, since you will have flags in the main header, why not use them? Note we can also have flags in the TLVs T part. I think diameter does this. cheers, jamal > Thank you. > Weiming > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Jamal, > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > There is actually one challenge with keeping the LFBid in the header: > You cant mix different LFBs in one batch. In order to send a batch with > different LFB commands you have to send a batch of separate PL messages. > > We could introduce an "opaque" LFBid which translates to "look inside > the message body for LFB type" and then that could be used for mixed LFB > messages. > > [HK] Good point, thanks for bringing this up. I remember having > discussed this before. Yes we will need the concept of "opaque" LFB Type > ID, if we have it in the common header and have to support Command > Bundling (diff LFB Types in the same msg) > > 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 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 09:33:02 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 JAA12082 for ; Thu, 6 May 2004 09:33: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 1BLisD-0002Yd-6m for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 09:25:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46DPDSc009826 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 09:25:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLipt-0001iu-7l for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 09: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 JAA11632 for ; Thu, 6 May 2004 09:22: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 1BLipr-00034R-LL for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09:22:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLioz-0002fq-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09:21:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLioA-0002Ho-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09: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 1BLiiL-0007ar-Di; Thu, 06 May 2004 09:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLidH-0005p9-6t for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 09:09: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 JAA11008 for ; Thu, 6 May 2004 09:09:44 -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 1BLidF-0005fC-Me for forces-protocol@ietf.org; Thu, 06 May 2004 09:09:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLicQ-0005H2-00 for forces-protocol@ietf.org; Thu, 06 May 2004 09:08:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLibk-0004sa-00 for forces-protocol@ietf.org; Thu, 06 May 2004 09:08:12 -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 i46D85B01132; Thu, 6 May 2004 16:08:05 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 16:07:55 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i46D7tAY032739; Thu, 6 May 2004 16:07:55 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00YHxsMF; Thu, 06 May 2004 16:07: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 i46D7kH10303; Thu, 6 May 2004 16:07:46 +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, 6 May 2004 08:07:11 -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] Conference call ? Message-ID: Thread-Topic: [Forces-protocol] Conference call ? Thread-Index: AcQyU9i7PSwIRbGATbq9irSrBEaGWAAfCgbQACbBCDA= To: , , X-OriginalArrivalTime: 06 May 2004 13:07:11.0136 (UTC) FILETIME=[0AF1EA00:01C4336B] 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, 6 May 2004 09:07: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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable sounds ok to me. > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, > Hormuzd M > Sent: Wednesday, May 05, 2004 2:49 PM > To: Wang,Weiming; forces-protocol@ietf.org > Subject: RE: [Forces-protocol] Conference call ? >=20 >=20 > Hi All, >=20 > I can setup a teleconference call for this Friday (May 7th),=20 > either at 8 > AM PST or 5/6 PM PST. > Let me know which timing will work for you guys, especially Weiming, > Ligang ? > If Friday is not good, then may be we can have one on Monday (May > 10th)... again either morning or evening depending on your=20 > preferences ? >=20 > Let me know, >=20 > Thanks > Hormuzd >=20 > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming >=20 > Hi, >=20 > Teleconference is ok for us, though I more prefer the Netmeeting (just > afraid > some may not use it). Also, I need to check if teleconference is > available for > us, and will let you know soon. >=20 > Thank you. > Weiming > ----- Original Message ----- > From: "Khosravi, Hormuzd M" >=20 >=20 > Avri, >=20 > > I would strongly recommend we scrub 2.a before moving on.=20 > Its probably > > the most critical part. No rush. I would rather be late than sorry. > > >=20 > I am wondering whether there might not be a utility in having a > conference call at some point to run through some of the remaining > knots. Though we are continents apart, there are time that=20 > almost work > with the Pacific US early in the AM and China late at night. >=20 > [HK] I think this is a good idea, to make fast progress. Although, it > might be difficult for Weiming with the time difference and English > barrier. What do others think ? I remember that Ram had also proposed > this in the past. >=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 May 6 10:06:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14565 for ; Thu, 6 May 2004 10:06: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 1BLjQJ-0007QK-Ih for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 10:00:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46E0RUw028533 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 10:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjHM-0003Ve-Qt for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:51: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 JAA13352 for ; Thu, 6 May 2004 09:51: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 1BLjHK-0007Dw-V9 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09:51:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjGT-0006lI-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09:50:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLjFS-0006GZ-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 09:49:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjBN-0000ql-Lx; Thu, 06 May 2004 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLj3b-0006Kd-PU for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 09:37: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 JAA12343 for ; Thu, 6 May 2004 09:36: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 1BLj3Z-0000vr-Mu for forces-protocol@ietf.org; Thu, 06 May 2004 09:36:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj2b-0000Wa-00 for forces-protocol@ietf.org; Thu, 06 May 2004 09:35:58 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BLj22-00005J-00 for forces-protocol@ietf.org; Thu, 06 May 2004 09:35:22 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i46DYlMp152720; Thu, 6 May 2004 13:34:47 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i46DYkI5277560; Thu, 6 May 2004 15:34:46 +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 PAA31160; Thu, 6 May 2004 15:34:46 +0200 Message-ID: <409A3EF5.1090400@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: ram.gopal@nokia.com CC: hormuzd.m.khosravi@intel.com, wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call ? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020209040106040601020907" 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, 06 May 2004 15:34:45 +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.7 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020209040106040601020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate6.de.ibm.com id i46DYlMp152720 Content-Transfer-Encoding: quoted-printable Unfortunately there is no way to get a reasonable common time for=20 Eastern Asia, West Coast, and Europe. But I will be in California next=20 week, and available for a conf call on Monday anytime, Thursday=20 afternoon, and Friday anytime. If you can't do the teleconf on Monday PST 5-6pm, please signal it and=20 propose another alternative. Thanks, -Robert ram.gopal@nokia.com wrote: >sounds ok to me. > > =20 > >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, >>Hormuzd M >>Sent: Wednesday, May 05, 2004 2:49 PM >>To: Wang,Weiming; forces-protocol@ietf.org >>Subject: RE: [Forces-protocol] Conference call ? >> >> >>Hi All, >> >>I can setup a teleconference call for this Friday (May 7th),=20 >>either at 8 >>AM PST or 5/6 PM PST. >>Let me know which timing will work for you guys, especially Weiming, >>Ligang ? >>If Friday is not good, then may be we can have one on Monday (May >>10th)... again either morning or evening depending on your=20 >>preferences ? >> >>Let me know, >> >>Thanks >>Hormuzd >> >>-----Original Message----- >>From: forces-protocol-admin@ietf.org >>[mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming >> >>Hi, >> >>Teleconference is ok for us, though I more prefer the Netmeeting (just >>afraid >>some may not use it). Also, I need to check if teleconference is >>available for >>us, and will let you know soon. >> >>Thank you. >>Weiming >>----- Original Message ----- >>From: "Khosravi, Hormuzd M" >> >> >>Avri, >> >> =20 >> >>>I would strongly recommend we scrub 2.a before moving on.=20 >>> =20 >>> >>Its probably >> =20 >> >>>the most critical part. No rush. I would rather be late than sorry. >>> >>> =20 >>> >>I am wondering whether there might not be a utility in having a >>conference call at some point to run through some of the remaining >>knots. Though we are continents apart, there are time that=20 >>almost work >>with the Pacific US early in the AM and China late at night. >> >>[HK] I think this is a good idea, to make fast progress. Although, it >>might be difficult for Weiming with the time difference and English >>barrier. What do others think ? I remember that Ram had also proposed >>this in the past. >> >> >>_______________________________________________ >>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 > > > =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 --------------020209040106040601020907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Unfortunately there is no way to get a reasonable common time for Eastern Asia, West Coast, and Europe. But I will be in California next week, and available for a conf call on Monday anytime, Thursday afternoon, and Friday anytime.
If you can't do the teleconf on Monday PST 5-6pm, please signal it and propose another alternative.
Thanks,
-Robert

ram.gopal@nokia.com wrote:
sounds ok to me.

  
-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi,
Hormuzd M
Sent: Wednesday, May 05, 2004 2:49 PM
To: Wang,Weiming; forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Conference call ?


Hi All,

I can setup a teleconference call for this Friday (May 7th), 
either at 8
AM PST or 5/6 PM PST.
Let me know which timing will work for you guys, especially Weiming,
Ligang ?
If Friday is not good, then may be we can have one on Monday (May
10th)... again either morning or evening depending on your 
preferences ?

Let me know,

Thanks
Hormuzd

-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming

Hi,

Teleconference is ok for us, though I more prefer the Netmeeting (just
afraid
some may not use it). Also, I need to check if teleconference is
available for
us, and will let you know soon.

Thank you.
Weiming
----- Original Message -----
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>


Avri,

    
I would strongly recommend we scrub 2.a before moving on. 
      
Its probably
    
the most critical part. No rush. I would rather be late than sorry.

      
I am wondering whether there might not be a utility in having a
conference call at some point to run through some of the remaining
knots.  Though we are continents apart, there are time that 
almost work
with the Pacific US early in the AM and China late at night.

[HK] I think this is a good idea, to make fast progress. Although, it
might be difficult for Weiming with the time difference and English
barrier. What do others think ? I remember that Ram had also proposed
this in the past.


_______________________________________________
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


  

-- 
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
--------------020209040106040601020907-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 13:24:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04108 for ; Thu, 6 May 2004 13:24: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 1BLmNC-0002PT-4b for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 13:09:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46H9QL3009263 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 13:09:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlOA-0008AO-MC for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:06: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 MAA23727 for ; Thu, 6 May 2004 12:06: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 1BLlO9-0003b9-AR for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 12:06:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlKi-0002Dn-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 12:02:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlHM-0000oK-01 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 11:59:20 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLl5u-0000gB-W5 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 11:47:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkp2-0004s8-IR; Thu, 06 May 2004 11:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkh6-0001t9-CI for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 11:21: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 LAA19751 for ; Thu, 6 May 2004 11:21: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 1BLkh5-0007H0-EI for forces-protocol@ietf.org; Thu, 06 May 2004 11:21:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkgA-0006ny-00 for forces-protocol@ietf.org; Thu, 06 May 2004 11:20:55 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BLkf5-0005xL-00 for forces-protocol@ietf.org; Thu, 06 May 2004 11:19:47 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i46FF6Vi067770 for ; Thu, 6 May 2004 15:15:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i46FF6lW277500 for ; Thu, 6 May 2004 17:15:06 +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 RAA65032 for ; Thu, 6 May 2004 17:15:06 +0200 Message-ID: <409A5679.8050501@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: forces-protocol@ietf.org Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] Content-Type: multipart/alternative; boundary="------------040805090502060807020306" 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, 06 May 2004 17:15:05 +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.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------040805090502060807020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i46FF6Vi067770 Content-Transfer-Encoding: quoted-printable Maybe my last message on that topic went unnoticed, so I wanted to again=20 stress the possibility to create an FE LFB (call it meta LFB, control=20 LFB, etc) that can be configured, events can be subscribed to, etc. The=20 difference between the FE LFB and the other "regular" LFBs is that no=20 data packet traverses the FE LFB. The purpose of the FE LFB is to=20 facilitate the control of the FE: Examples: - FE UP and DOWN don't need to be special ForCES messages. Instead, they=20 can be events originated by the FE LFB. - Configuring the interval timer for heartbeats messages can be done=20 using a Config message to the hearbeat interval attribute of the FE LFB. The reason to introduce this LFB versus creating specific ForCES=20 messages is flexibility: at some point in time, if we need to enhance=20 the ForCES protocol, we don't necessarily need to change the protocol=20 itself. Instead, we can create a new version of the FE LFB that supports=20 new features. I'd like to have your comments on such an FE LFB. Regards, -Robert -------- Original Message -------- Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Date: Wed, 05 May 2004 15:55:40 +0200 From: Robert Haas Organization: IBM Research Lab To: Wang,Weiming CC: forces-protocol@ietf.org References:=20 <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com>=20 <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> All, I've seen some interesting ideas floating around regarding the number of=20 messages needed. Let me illustrate the kind of messages I think we need=20 with two scenari: Usual scenario: CE sends a Config message to FE. FE applies it and sends an appropriate=20 response (ACK if successful or NACK otherwise). This can be the same=20 message type with a flag that indicates the result. Batching scenario with 2-phase commit: CE sends a serie (batch or bundle, as you prefer) of Config messages to=20 the FE, followed by a Commit message (which could be signalled with a=20 flag in the last Config message). The FE returns a serie of responses to=20 indicate that it got the messages, but DOES NOT apply them until the=20 Commit comes. The Response to the Commit indicates if the batch of=20 Config messages was successfully applied or not. Conclusion: You need a Config message type. You may use a flag to indicate whether it's the message itself, an ACK,=20 or an NACK. You may use a flag to indicate if the message is one of a batch, or the=20 last of the batch (i.e., the Commit). In the Query case, as there is no 2-phase commit necessary: You need a Query message type. You may use a flag to indicate whether it's the message, an ACK, or an NA= CK. I'd like to know more about the type of actions that can be performed on=20 the LFBs according to the model. Maybe a Config and a Query are enough.=20 But I don't know how the Event Generation is handled in the model. Can=20 someone explain ? For FE UP and DOWN, I'd rather include this in existing message types.=20 For instance, define an FE LFB that can be acted upon, and events such=20 as UP and DOWN may be subscribed to. Use the same messages and semantics=20 as the one used for other LFBs. You may apply the same reasoning to a Packet Redirect LFB, which=20 produces packets as events. Regards, -Robert Wang,Weiming wrote: >----- Original Message ----- >From: "Khosravi, Hormuzd M" >Hi All > >Here is the list of Protocol Messages based on final comments made by >Jamal. > >Association Setup, Setup Resp msg >Association Teardown msg >[Weiming] I agree to use the name 'Association'. But I can not find wher= e Jamal >disagree to use only one msg approach, that is 'association msg'. Again,= I have >to say a flag is definitely enough to indicate the command 'setup' 'setu= p resp', >and 'teardown'. Can you give reasons why they should be two msgs? > >Query/Query Resp msg (including Capability query) > >Config/Config Resp msg > >Subscribe/Unsubscribe msg >[Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub'= ? I >don't think Jamal agrees this also. A config or a Event msg can do this= well. > >State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE, >etc) > >Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc) > >[Weiming] I suggest just an 'Event msg' may be better. > >Packet Redirect msg > >Regards >Hormuzd > >Best regards, >Weiming > > > > >_______________________________________________ >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 --=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 --------------040805090502060807020306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Maybe my last message on that topic went unnoticed, so I wanted to again stress the possibility to create an FE LFB (call it meta LFB, control LFB, etc) that can be configured, events can be subscribed to, etc. The difference between the FE LFB and the other "regular" LFBs is that no data packet traverses the FE LFB. The purpose of the FE LFB is to facilitate the control of the FE:

Examples:

- FE UP and DOWN don't need to be special ForCES messages. Instead, they can be events originated by the FE LFB.
- Configuring the interval timer for heartbeats messages can be done using a Config message to the hearbeat interval attribute of the FE LFB.

The reason to introduce this LFB versus creating specific ForCES messages is flexibility: at some point in time, if we need to enhance the ForCES protocol, we don't necessarily need to change the protocol itself. Instead, we can create a new version of the FE LFB that supports new features.

I'd like to have your comments on such an FE LFB.

Regards,
-Robert

-------- Original Message --------
Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a
Date: Wed, 05 May 2004 15:55:40 +0200
From: Robert Haas <rha@zurich.ibm.com>
Organization: IBM Research Lab
To: Wang,Weiming <wmwang@mail.hzic.edu.cn>
CC: forces-protocol@ietf.org
References: <468F3FDA28AA87429AD807992E22D07EE40393@orsmsx408.jf.intel.com> <087701c43256$ecd49eb0$845c21d2@Necom.hzic.edu.cn> 


All,
I've seen some interesting ideas floating around regarding the number of 
messages needed. Let me illustrate the kind of messages I think we need 
with two scenari:

Usual scenario:
CE sends a Config message to FE. FE applies it and sends an appropriate 
response (ACK if successful or NACK otherwise). This can be the same 
message type with a flag that indicates the result.

Batching scenario with 2-phase commit:
CE sends a serie (batch or bundle, as you prefer) of Config messages to 
the FE, followed by a Commit message (which could be signalled with a 
flag in the last Config message). The FE returns a serie of responses to 
indicate that it got the messages, but DOES NOT apply them until the 
Commit comes. The Response to the Commit indicates if the batch of 
Config messages was successfully applied or not.

Conclusion:
You need a Config message type.
You may use a flag to indicate whether it's the message itself, an ACK, 
or an NACK.
You may use a flag to indicate if the message is one of a batch, or the 
last of the batch (i.e., the Commit).

In the Query case, as there is no 2-phase commit necessary:
You need a Query message type.
You may use a flag to indicate whether it's the message, an ACK, or an NACK.

I'd like to know more about the type of actions that can be performed on 
the LFBs according to the model. Maybe a Config and a Query are enough. 
But I don't know how the Event Generation is handled in the model. Can 
someone explain ?

For FE UP and DOWN, I'd rather include this in existing message types. 
For instance, define an FE LFB that can be acted upon, and events such 
as UP and DOWN may be subscribed to. Use the same messages and semantics 
as the one used for other LFBs.

You may apply the same reasoning to a Packet Redirect LFB, which 
produces packets as events.

Regards,
-Robert

Wang,Weiming wrote:

>----- Original Message -----
>From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
>Hi All
>
>Here is the list of Protocol Messages based on final comments made by
>Jamal.
>
>Association Setup, Setup Resp msg
>Association Teardown msg
>[Weiming] I agree to use the name 'Association'. But I can not find where Jamal
>disagree to use only one msg approach, that is 'association msg'. Again, I have
>to say a flag is definitely enough to indicate the command 'setup' 'setup resp',
>and 'teardown'. Can you give reasons why they should be two msgs?
>
>Query/Query Resp msg (including Capability query)
>
>Config/Config Resp msg
>
>Subscribe/Unsubscribe msg
>[Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I
>don't think Jamal agrees this also.  A config or a Event msg can do this well.
>
>State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE,
>etc)
>
>Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc)
>
>[Weiming] I suggest just an 'Event msg' may be better.
>
>Packet Redirect msg
>
>Regards
>Hormuzd
>
>Best regards,
>Weiming
>
>
>
>
>_______________________________________________
>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



_______________________________________________
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
--------------040805090502060807020306-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 13:31:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05366 for ; Thu, 6 May 2004 13:31: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 1BLmXO-0001sd-QF for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 13:19:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HJw7n007208 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 13:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlwA-0002Mw-T9 for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:41: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 MAA28672 for ; Thu, 6 May 2004 12:41: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 1BLlw9-0001ZW-8G for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 12:41:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLltj-0000Uf-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 12:39:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLlqg-0007RE-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 12:35:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlBF-0000j9-9M; Thu, 06 May 2004 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkpk-0005Am-GG for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 11: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 LAA20306 for ; Thu, 6 May 2004 11:30: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 1BLkpj-0003D8-HE for forces-protocol@ietf.org; Thu, 06 May 2004 11:30:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLknq-0002Q8-00 for forces-protocol@ietf.org; Thu, 06 May 2004 11:28:51 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1BLkn6-0001dd-00 for forces-protocol@ietf.org; Thu, 06 May 2004 11:28:04 -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 i46FRXWn016260; Thu, 6 May 2004 15:27:33 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 i46FRXlW286684; Thu, 6 May 2004 17:27:33 +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 RAA61036; Thu, 6 May 2004 17:27:32 +0200 Message-ID: <409A5964.1080502@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: windowing References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4099026D.70903@zurich.ibm.com> <029e01c4332d$1645baf0$020aa8c0@wwm1> In-Reply-To: <029e01c4332d$1645baf0$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------000800040704050502010009" 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, 06 May 2004 17:27:32 +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.8 required=5.0 tests=AWL,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000800040704050502010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate7.de.ibm.com id i46FRXWn016260 Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: > Hi Robert, > > ----- Original Message ----- > From: Robert Haas > To: Wang,Weiming > Cc: forces-protocol@ietf.org > Sent: Wednesday, May 05, 2004 11:04 PM > Subject: Re: [Forces-protocol] topic 4c: Common Header: windowing > > All, > > Let me try to briefly tackle the windowing issue now: > > First, we should definitely not shoot for a TCP-like flow-control > solution at the PL level. > > Instead, we could define a high-priority/control message that an > FE can send in case of overruns. > [Weming]Could you explain a little more on this. Sorry, I just can > not catch up with it well. Is the priority the same as that we > defined in the header? > Yes > =20 > Overruns occur when the FE is too slow at processing the incoming > CE messages, and its receive buffers are full. The reaction of the > CE to the overrun message can be left vendor specific. It the TML > is TCP, then the TCP flow-control will automatically take care of > this and overruns will not be generated by the FE. Other TMLs > might not provide such capability, hence the need for this > (extremely simple) windowing scheme at the PL level using overrun > messages. > [Weiming] Is it a specific msg walking between CE and FE to manage > the overruns? > Yes. In fact, it could be an event generated by the FE LFB that I=20 proposed in the note I sent a few minutes ago. The CE could configure=20 the FE LFB it and decide whether it is interested to listen to the=20 overrun event. Regards, -Robert > > > Let me know what other approaches you would consider. The approach > above fits in the 'Pls let me know when you encounter > difficulties, otherwise pls don't bother' category Weiming already > suggested. > > Regards, > -Robert > > Cheers, > Weiming > =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 --------------000800040704050502010009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,

Weiming Wang wrote:
Hi Robert,
----- Original Message -----
Sent: Wednesday, May 05, 2004 11:04 PM
Subject: Re: [Forces-protocol] topic 4c: Common Header: windowing

All,

Let me try to briefly tackle the windowing issue now:

First, we should definitely not shoot for a TCP-like flow-control solution at the PL level.

Instead, we could define a high-priority/control message that an FE can send in case of overruns.
[Weming]Could you explain a little more on this. Sorry, I just can not catch up with it well. Is the priority the same as that we defined in the header?
Yes
 
Overruns occur when the FE is too slow at processing the incoming CE messages, and its receive buffers are full. The reaction of the CE to the overrun message can be left vendor specific. It the TML is TCP, then the TCP flow-control will automatically take care of this and overruns will not be generated by the FE. Other TMLs might not provide such capability, hence the need for this (extremely simple) windowing scheme at the PL level using overrun messages.
[Weiming] Is it a specific msg walking between CE and FE to manage the overruns?
Yes. In fact, it could be an event generated by the FE LFB that I proposed in the note I sent a few minutes ago. The CE could configure the FE LFB it and decide whether it is interested to listen to the overrun event.

Regards,
-Robert


Let me know what other approaches you would consider. The approach above fits in the 'Pls let me know when you encounter difficulties, otherwise pls don't bother' category Weiming already suggested.

Regards,
-Robert

Cheers,
Weiming
 

-- 
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
--------------000800040704050502010009-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 14:02:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07996 for ; Thu, 6 May 2004 14:02: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 1BLn0j-0002gM-KX for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 13:50:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HoHEH010306 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 13:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmhN-00019c-9Z for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:30: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 NAA05072 for ; Thu, 6 May 2004 13:30: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 1BLmhL-0000Aa-50 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:30:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmfp-000735-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:28:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLme1-00062g-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:26:49 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLme2-0002oK-UY for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:26:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmOG-0003Cc-Qn; Thu, 06 May 2004 13:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlSk-0002ku-MA for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 12: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 MAA24280 for ; Thu, 6 May 2004 12:11: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 1BLlSj-00051C-78 for forces-protocol@ietf.org; Thu, 06 May 2004 12:11:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlPW-0003rV-00 for forces-protocol@ietf.org; Thu, 06 May 2004 12:07:49 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BLlMO-0002YI-00 for forces-protocol@ietf.org; Thu, 06 May 2004 12:04:32 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i46G40Mp031872; Thu, 6 May 2004 16:04:01 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i46G40lW265796; Thu, 6 May 2004 18:04:00 +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 SAA41928; Thu, 6 May 2004 18:04:00 +0200 Message-ID: <409A61EF.2090600@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: batching References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> In-Reply-To: <029201c4332b$dca18640$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------050308050009090209060704" 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, 06 May 2004 18:03:59 +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.9 required=5.0 tests=AWL,HTML_20_30,HTML_FONT_BIG, HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050308050009090209060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate6.de.ibm.com id i46G40Mp031872 Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: > Robert, Jamal, and all, > =20 > =20 > ----- Original Message ----- > > From: Robert Haas > To: Wang,Weiming > Cc: forces-protocol@ietf.org > Sent: Wednesday, May 05, 2004 4:50 PM > Subject: Re: [Forces-protocol] topic 4c: Common Header: batching > > Weiming, > I think the approach of 'Pls let me know when you encounter > difficulties, otherwise pls don't bother' is indeed useful. Let me > elaborate a bit on this. Sorry for the rather long message. I'll > devote another note to windowing. > > Batching is used to group commands together. Each command > possibly has its own sequence number (or transaction number), > [Weiming]No problem with the name sequence number, I also like it. > or the group has its own number with subnumbers for each message > (this remains to be decided.) The main use of batching is to > perform atomicity: > [Weiming]I agree this, though I was a little confused before with > the notions 'batching, atomicity, 2-phase commit, all or nothing'. > Can we understand that they are all targeting the same thing: all > or nothing? Or we have other purpose for batching such as just for > packetizing? > The purpose of batching, bundling, grouping, atomicity, 2-phase-commit,=20 is for the same purpose: execute a serie of commands in such a way that=20 their effect is the same as if it had been a single command. If the number of commands/TLVs to include on a ForCES Msg exceeds the=20 maximum length of the ForCES message, then I would simply use another=20 ForCES Msg, and only set batching ON if I wanted atomicity across the=20 commands in the two separate ForCES Msgs. Does that sound reasonable ? > =20 > all commands in the group will be performed at the same time or > none will be performed. This is where 2-phase commit kicks in: all > commands are first transmitted to the FE, and unless the FE > reports an error, the CE can ultimately issue a commit command so > all these commands are executed in an atomic operation at the FE. > [Weiming]Yes. > We investigated the idea of packing multiple commands in the same > ForCES message (it saves quite some headers and the associated > processing > [Weiming]Here, I think we need to evaluate if the headers are > worth there or not. My original idea was it was not worth it > (during GRMP time), but now I change some. Just check the possible > header fields, we may find that most of them are worth there, and > the reward is great, allowing per msg ACK, and with much less > complexity for protocol state trace. > =20 > ). As a motivation, think of adding 100'000 routes on an FE: > should we use 100'000 ForCES messages, or only 1000 (say 15 bytes > per route update command to be generous, with a 1500 bytes MTU > size, or even less if we have Jumbo frames) ? > > Note that having many commands in the same ForCES message results > in slighlty more complex error/ack reporting. Take this example: > two commands A and B in the same ForCES message issued by a CE. FE > executes both of them, but only A succeeds. It should report this > somehow to the CE. A possible solution is to return the original > message trimmed down such that it contains exactly two responses, > a positive and a negative one. > [Weiming]Yes, I think you are also trying to see which is better > among the following two possible batching schemes: > 1. Batched msgs in one packet or even keeping the msgs separately > as its origin, while with some flags such as Atomicity and/or Done > Flag to indicate the begin and the end. > 2. Many commands in one msg as you mentioned above. > I a little more incline to #1 scheme, as the reason I mentioned > above. But there is a remained issue for successful atomicity, > that is, it does not support multipul transactions if we use > different sequece number for different msgs in a batch, and if we > use same sequence number for all the msgs, then it may result in > ambiguity for msg meaning and hard for ACK. Therefore, I try to > propose to use a sub msg number to see if it is feasible for the > purpose. Pls let me try to summarize sth we'v already got > (Netlink2?) along with the batch msg # thought as follows: > =20 > Batching msg as: > =20 > Msg1:Msg2:...MsgN (either one packet or separated packets) > =20 > In headers of all the msgs, > =20 > Sequence Numbers: all the same, that means a batch is treated as a > transaction. > ATM flag: mark the end of batching (e.g.,0 for MsgN, and also a > signal to excute the batch, 1 for others, and also as a signal to > reserve it) > ACK flag: indicate if this msg need an ACK > BatchMsgNum: mark the batehed msg sequence number, 0 for Msg1, ... > (N-1) for MsgN. Any ACK should include BatchMsgNum as well as other= s. > =20 > Any of the Msg in the batch still can be fragmented if it exceeds > the MTU, a FRG flag is used to treat it, with the thinking that > the packets will not be reordered. > > Rob: can you try to present a summary regarding the #2 scheme, so > that we can carefully compare and evaluate it? > Let me try: One single ForCES Msg, with N TLVs (TLVs are basically the command=20 destined to LFBs). If the batch spans more than one single ForCES Msg=20 the ATM flag will have to be set accordingly. The resulting ACK Msg can=20 be for the entire ForCES Msg (using the sequence number). Or the ACK Msg=20 can contain the same TLVs as the original Message, with a flag in each=20 TLV to indicate if that particular TLV succeeded or not. If the Atomic=20 flag was set with the 2-phase commit, then all TLVs succeed or none. The sequence number must be incremented for each new ForCES Msg. If the=20 batch of TLVs/commands (TLVs/commands that logically belong to the same=20 transaction) are split into two ForCES Msgs, then there will be two=20 sequence numbers. I am reluctant to keep the sequence number the same.=20 Acknowledging the highest number will mean that all previous Msg were=20 received and processed OK. Do you need to have another number (such as=20 transaction number or submsg number) necessarily ? If someone wants to do a transaction and ensure that only a single=20 sequence number is associated to it, then it must pack all the TLVs into=20 the same ForCES message. Would this be satisfactory ? I realize that in my previous note I confused command and ForCEs Msg:=20 there can be one or more commands (=3DTLVs) in a ForCES Msg. The sequence= =20 number is associated with a ForCES Msg. Regards, -Robert > =20 > I think we should focus our effort on defining the format and > state machine of the ForCES protocol as seen on the wire > [Weiming] Yes, agreed. The state transfer diagram is important. > =20 > (and define a few encapsulation methods for ForCES over UDP, TCP, > etc, with specific reserved port numbers > [Weiming]I'm not sure if TML will do this or not. > ). So I don't think we need to worry about the way the Apps get > notifications from the PL and so on, and if a single/multiple > signal/s is/are used to confirm that a batch of messages has been > successfully executed. This will remain vendor specific. Do you > have different views ? > [Weiming]Agreed. > > Cheers, > -Robert > Cheers, > Weiming > --=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 --------------050308050009090209060704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,

Weiming Wang wrote:
Robert, Jamal, and all,
 
 
----- Original Message -----
Sent: Wednesday, May 05, 2004 4:50 PM
Subject: Re: [Forces-protocol] topic 4c: Common Header: batching

Weiming,
I think the approach of  'Pls let me know when you encounter difficulties, otherwise pls don't bother' is indeed useful. Let me elaborate a bit on this. Sorry for the rather long message. I'll devote another note to windowing.

 Batching is used to group commands together. Each command possibly has its own sequence number (or transaction number),
[Weiming]No problem with the name sequence number, I also like it.
or the group has its own number with subnumbers for each message (this remains to be decided.) The main use of batching is to perform atomicity:
[Weiming]I agree this, though I was a little confused before with the notions 'batching, atomicity, 2-phase commit, all or nothing'. Can we understand that they are all targeting the same thing: all or nothing? Or we have other purpose for batching such as just for packetizing?

The purpose of batching, bundling, grouping, atomicity, 2-phase-commit, is for the same purpose: execute a serie of commands in such a way that their effect is the same as if it had been a single command.

If the number of commands/TLVs to include on a ForCES Msg exceeds the maximum length of the ForCES message, then I would simply use another ForCES Msg, and only set batching ON if I wanted atomicity across the commands in the two separate ForCES Msgs. Does that sound reasonable ?

 
all commands in the group will be performed at the same time or none will be performed. This is where 2-phase commit kicks in: all commands are first transmitted to the FE, and unless the FE reports an error, the CE can ultimately issue a commit command so all these commands are executed in an atomic operation at the FE.
[Weiming]Yes.
We investigated the idea of packing multiple commands in the same ForCES message (it saves quite some headers and the associated processing
[Weiming]Here, I think we need to evaluate if the headers are worth there or not. My original idea was it was not worth it (during GRMP time), but now I change some. Just check the possible header fields, we may find that most of them are worth there, and the reward is great, allowing per msg ACK, and with much less complexity for protocol state trace.
 
). As a motivation, think of adding 100'000 routes on an FE: should we use 100'000 ForCES messages, or only 1000 (say 15 bytes per route update command to be generous, with a 1500 bytes MTU size, or even less if we have Jumbo frames) ?

Note that having many commands in the same ForCES message results in slighlty more complex error/ack reporting. Take this example: two commands A and B in the same ForCES message issued by a CE. FE executes both of  them, but only A succeeds. It should report this somehow to the CE. A possible solution is to return the original message trimmed down such that it contains exactly two responses, a positive and a negative one.
[Weiming]Yes, I think you are also trying to see which is better among the following two possible batching schemes:
1. Batched msgs in one packet or even keeping the msgs separately as its origin, while with some flags such as Atomicity and/or Done Flag to indicate the begin and the end.
2. Many commands in one msg as you mentioned above.
I a little more incline to #1 scheme, as the reason I mentioned above. But there is a remained issue for successful atomicity, that is, it does not support multipul transactions if we use different sequece number for different msgs in a batch, and if we use same sequence number for all the msgs, then it may result in ambiguity for msg meaning and hard for ACK. Therefore, I try to propose to use a sub msg number to see if it is feasible for the purpose. Pls let me try to summarize sth we'v already got (Netlink2?) along with the batch msg # thought as follows:
 
Batching msg as:
 
Msg1:Msg2:...MsgN (either one packet or separated packets)
 
In headers of all the msgs,
 
Sequence Numbers: all the same, that means a batch is treated as a transaction.
ATM flag: mark the end of batching (e.g.,0 for MsgN, and also a signal to excute the batch, 1 for others, and also as a signal to reserve it)
ACK flag: indicate if this msg need an ACK
BatchMsgNum: mark the batehed msg sequence number, 0 for Msg1, ... (N-1) for MsgN. Any ACK should include BatchMsgNum as well as others.
 
Any of the Msg in the batch still can be fragmented if it exceeds the MTU, a FRG flag is used to treat it, with the thinking that the packets will not be reordered.
Rob: can you try to present a summary regarding the #2 scheme, so that we can carefully compare and evaluate it?
Let me try:

One single ForCES Msg, with N TLVs (TLVs are basically the command destined to LFBs). If the batch spans more than one single ForCES Msg the ATM flag will have to be set accordingly. The resulting ACK Msg can be for the entire ForCES Msg (using the sequence number). Or the ACK Msg can contain the same TLVs as the original Message, with a flag in each TLV to indicate if that particular TLV succeeded or not. If the Atomic flag was set with the 2-phase commit, then all TLVs succeed or none.

The sequence number must be incremented for each new ForCES Msg. If the batch of TLVs/commands (TLVs/commands that logically belong to the same transaction) are split into two ForCES Msgs, then there will be two sequence numbers. I am reluctant to keep the sequence number the same. Acknowledging the highest number will mean that all previous Msg were received and processed OK. Do you need to have another number (such as transaction number or submsg number) necessarily ?

If someone wants to do a transaction and ensure that only a single sequence number is associated to it, then it must pack all the TLVs into the same ForCES message. Would this be satisfactory ?

I realize that in my previous note I confused command and ForCEs Msg: there can be one or more commands (=TLVs) in a ForCES Msg. The sequence number is associated with a ForCES Msg.

Regards,
-Robert

 
I think we should focus our effort on defining the format and state machine of the ForCES protocol as seen on the wire
[Weiming] Yes, agreed. The state transfer diagram is important.
 
(and define a few encapsulation methods for ForCES over UDP, TCP, etc, with specific reserved port numbers
[Weiming]I'm not sure if TML will do this or not.
). So I don't think we need to worry about the way the Apps get notifications from the PL and so on, and if a single/multiple signal/s is/are used to confirm that a batch of messages has been successfully executed. This will remain vendor specific. Do you have different views ?
[Weiming]Agreed.

Cheers,
-Robert
Cheers,
Weiming

-- 
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
--------------050308050009090209060704-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 14:17:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08739 for ; Thu, 6 May 2004 14:17: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 1BLnFG-00021p-B8 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 14:05:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46I5Ikl007792 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 14:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn3I-0004Pp-Pd for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:52: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 NAA07239 for ; Thu, 6 May 2004 13:52: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 1BLn3G-0002iB-Ii for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:52:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn2E-0002Dq-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:51:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLn18-0001SP-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:50:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmiG-0001tU-1W; Thu, 06 May 2004 13:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmVG-0000K5-VU for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 13: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 NAA03077 for ; Thu, 6 May 2004 13: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 1BLmVE-0002DQ-Or for forces-protocol@ietf.org; Thu, 06 May 2004 13:17:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmSI-00011X-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:14: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 1BLmOr-0007P4-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:11: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 i46HAc0Y011095; Thu, 6 May 2004 17:10:39 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 i46H8KkA005037; Thu, 6 May 2004 17:08: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 M2004050610101701131 ; Thu, 06 May 2004 10:10:17 -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, 6 May 2004 10:10:17 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4338D.00A87244" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Conference call - Monday 5-6 PM PST Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC168@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday 5-6 PM PST Thread-Index: AcQzbutmOamN+Q5KQaCL1up03nTwZQAHXxEA From: "Khosravi, Hormuzd M" To: "Robert Haas" , Cc: , X-OriginalArrivalTime: 06 May 2004 17:10:17.0159 (UTC) FILETIME=[00E46570:01C4338D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 6 May 2004 10:10: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.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4338D.00A87244 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Monday, 5-6 PM PST is fine with me. I think it should work for most of us based on the replies that I saw. It will also give Weiming and his team more time to make arrangements for attending the call. =20 But I do hope we have most issues resolved by then, we are already almost a week behind schedule. =20 Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Thursday, May 06, 2004 6:35 AM To: ram.gopal@nokia.com Cc: Khosravi, Hormuzd M; wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call ? Unfortunately there is no way to get a reasonable common time for Eastern Asia, West Coast, and Europe. But I will be in California next week, and available for a conf call on Monday anytime, Thursday afternoon, and Friday anytime. If you can't do the teleconf on Monday PST 5-6pm, please signal it and propose another alternative. Thanks, -Robert ram.gopal@nokia.com wrote: sounds ok to me. =20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Wednesday, May 05, 2004 2:49 PM To: Wang,Weiming; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Conference call ? Hi All, I can setup a teleconference call for this Friday (May 7th),=20 either at 8 AM PST or 5/6 PM PST. Let me know which timing will work for you guys, especially Weiming, Ligang ? If Friday is not good, then may be we can have one on Monday (May 10th)... again either morning or evening depending on your=20 preferences ? Let me know, Thanks Hormuzd ------_=_NextPart_001_01C4338D.00A87244 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Monday, 5-6 PM PST is fine with me. I think it should work for = most of us=20 based on the replies that I saw.
It=20 will also give Weiming and his team more time to make arrangements for = attending=20 the call.
 
But I do hope we have most issues resolved by then, we are = already=20 almost a week behind schedule.
 
Thanks
Hormuzd
-----Original Message-----
From: = Robert Haas=20 [mailto:rha@zurich.ibm.com]
Sent: Thursday, May 06, 2004 = 6:35=20 AM
To: ram.gopal@nokia.com
Cc: Khosravi, Hormuzd = M;=20 wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org
Subject: = Re:=20 [Forces-protocol] Conference call ?

Unfortunately = there is=20 no way to get a reasonable common time for Eastern Asia, West Coast, = and=20 Europe. But I will be in California next week, and available for a = conf call=20 on Monday anytime, Thursday afternoon, and Friday anytime.
If you = can't do=20 the teleconf on Monday PST 5-6pm, please signal it and propose another = alternative.
Thanks,
-Robert

ram.gopal@nokia.com wrote:
sounds ok to me.

  
-----Original Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org]On Behalf Of ext Khosravi,
Hormuzd M
Sent: Wednesday, May 05, 2004 2:49 PM
To: Wang,Weiming; forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Conference call ?


Hi All,

I can setup a teleconference call for this Friday (May 7th),=20
either at 8
AM PST or 5/6 PM PST.
Let me know which timing will work for you guys, especially Weiming,
Ligang ?
If Friday is not good, then may be we can have one on Monday (May
10th)... again either morning or evening depending on your=20
preferences ?

Let me know,

Thanks
Hormuzd
------_=_NextPart_001_01C4338D.00A87244-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 14:21:53 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 OAA08987 for ; Thu, 6 May 2004 14:21: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 1BLnHH-00033A-FL for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 14:07:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46I7NOu011718 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 14:07:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn4q-00053P-Lh for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:54: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 NAA07432 for ; Thu, 6 May 2004 13:54: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 1BLn4o-0003Gl-Ei for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:54:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn3o-0002no-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:53:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLn30-0002K0-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 13:52:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmm3-0003v9-NR; Thu, 06 May 2004 13:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLma3-0004Ac-Nn for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 13:22: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 NAA03814 for ; Thu, 6 May 2004 13:22:41 -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 1BLma1-0004KB-Mi for forces-protocol@ietf.org; Thu, 06 May 2004 13:22:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmYp-0003mv-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:21:29 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BLmXO-00032E-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:19:58 -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 i46HJfv29004; Thu, 6 May 2004 20:19:41 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 20:19:24 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i46HJOjm008430; Thu, 6 May 2004 20:19:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00ZFa2hW; Thu, 06 May 2004 20:19:23 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 i46HJHH22028; Thu, 6 May 2004 20:19:17 +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, 6 May 2004 12:18:55 -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_01C4338E.35730C88" Subject: RE: [Forces-protocol] Conference call - Monday 5-6 PM PST Message-ID: Thread-Topic: [Forces-protocol] Conference call - Monday 5-6 PM PST Thread-Index: AcQzbutmOamN+Q5KQaCL1up03nTwZQAHXxEAAABsRRA= To: , Cc: , X-OriginalArrivalTime: 06 May 2004 17:18:55.0898 (UTC) FILETIME=[3615AFA0:01C4338E] 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, 6 May 2004 13:18: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.8 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4338E.35730C88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a flight at 9:00 (EST) can you make one or two hours earlier.=20 Regards Ramg []=20 -----Original Message----- From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Thursday, May 06, 2004 1:10 PM To: Robert Haas; Gopal Ram (Nokia-NRC/Boston) Cc: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: [Forces-protocol] Conference call - Monday 5-6 PM PST Monday, 5-6 PM PST is fine with me. I think it should work for most of = us based on the replies that I saw. It will also give Weiming and his team more time to make arrangements = for attending the call. =20 But I do hope we have most issues resolved by then, we are already = almost a week behind schedule. =20 Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Thursday, May 06, 2004 6:35 AM To: ram.gopal@nokia.com Cc: Khosravi, Hormuzd M; wmwang@mail.hzic.edu.cn; = forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call ? Unfortunately there is no way to get a reasonable common time for = Eastern Asia, West Coast, and Europe. But I will be in California next = week, and available for a conf call on Monday anytime, Thursday = afternoon, and Friday anytime. If you can't do the teleconf on Monday PST 5-6pm, please signal it and = propose another alternative. Thanks, -Robert ram.gopal@nokia.com wrote: sounds ok to me. =20 -----Original Message----- From: forces-protocol-admin@ietf.org [ mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Wednesday, May 05, 2004 2:49 PM To: Wang,Weiming; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Conference call ? Hi All, I can setup a teleconference call for this Friday (May 7th),=20 either at 8 AM PST or 5/6 PM PST. Let me know which timing will work for you guys, especially Weiming, Ligang ? If Friday is not good, then may be we can have one on Monday (May 10th)... again either morning or evening depending on your=20 preferences ? Let me know, Thanks Hormuzd ------_=_NextPart_001_01C4338E.35730C88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I have=20 a flight at 9:00 (EST) can you make one  or two hours earlier.=20

Regards
Ramg
[<Ramg>] 
 -----Original=20 Message-----
From: ext Khosravi, Hormuzd M=20 [mailto:hormuzd.m.khosravi@intel.com]
Sent: Thursday, May 06, = 2004=20 1:10 PM
To: Robert Haas; Gopal Ram = (Nokia-NRC/Boston)
Cc:=20 wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org
Subject:=20 [Forces-protocol] Conference call - Monday 5-6 PM=20 PST
Monday, 5-6 PM PST is fine with me. I think it should work = for most of=20 us based on the replies that I saw.
It=20 will also give Weiming and his team more time to make arrangements for = attending the call.
 
But I do hope we have most issues resolved by then, we = are already=20 almost a week behind schedule.
 
Thanks
Hormuzd
-----Original Message-----
From: = Robert Haas=20 [mailto:rha@zurich.ibm.com]
Sent: Thursday, May 06, 2004 = 6:35=20 AM
To: ram.gopal@nokia.com
Cc: Khosravi, Hormuzd = M;=20 wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org
Subject: = Re:=20 [Forces-protocol] Conference call = ?

Unfortunately there=20 is no way to get a reasonable common time for Eastern Asia, West = Coast, and=20 Europe. But I will be in California next week, and available for a = conf call=20 on Monday anytime, Thursday afternoon, and Friday anytime.
If you = can't=20 do the teleconf on Monday PST 5-6pm, please signal it and propose = another=20 alternative.
Thanks,
-Robert

ram.gopal@nokia.com = wrote:
sounds ok to me.

  
-----Original =
Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org]On Behalf Of ext Khosravi,
Hormuzd M
Sent: Wednesday, May 05, 2004 2:49 PM
To: Wang,Weiming; forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Conference call ?


Hi All,

I can setup a teleconference call for this Friday (May 7th),=20
either at 8
AM PST or 5/6 PM PST.
Let me know which timing will work for you guys, especially Weiming,
Ligang ?
If Friday is not good, then may be we can have one on Monday (May
10th)... again either morning or evening depending on your=20
preferences ?

Let me know,

Thanks
Hormuzd
------_=_NextPart_001_01C4338E.35730C88-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 14:22:08 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 OAA09009 for ; Thu, 6 May 2004 14:22: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 1BLnHv-0003Ur-Bm for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 14:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46I83A8013428 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 14:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnC5-0000En-SN for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:02: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 OAA07985 for ; Thu, 6 May 2004 14:01: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 1BLnC3-0006mB-Is for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 14:01:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnBA-0006Ku-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 14:01:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnAD-0005tJ-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 14:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmzY-0001cJ-NR; Thu, 06 May 2004 13: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 1BLmeh-00088N-ED for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 13:27: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 NAA04517 for ; Thu, 6 May 2004 13:27: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 1BLmef-0006Sd-8Q for forces-protocol@ietf.org; Thu, 06 May 2004 13:27:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmcP-0005Wd-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:25:10 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmac-0004Ko-00 for forces-protocol@ietf.org; Thu, 06 May 2004 13:23:18 -0400 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 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 i46HMwjx031115; Thu, 6 May 2004 17:22:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus-pilot.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 i46HMKQ3011530; Thu, 6 May 2004 17:23:15 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 M2004050610223130412 ; Thu, 06 May 2004 10:22: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); Thu, 6 May 2004 10:22:32 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4338E.B0302388" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Conference call - Monday 5-6 PM PST Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC1A0@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday 5-6 PM PST Thread-Index: AcQzbutmOamN+Q5KQaCL1up03nTwZQAHXxEAAABsRRAAAB5psA== From: "Khosravi, Hormuzd M" To: , Cc: , X-OriginalArrivalTime: 06 May 2004 17:22:32.0184 (UTC) FILETIME=[B7004F80:01C4338E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 6 May 2004 10:22:20 -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,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4338E.B0302388 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am fine with starting this earlier say at 4 PM PST. Weiming & team will this work for you guys ?? =20 Thanks Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Thursday, May 06, 2004 10:19 AM To: Khosravi, Hormuzd M; rha@zurich.ibm.com Cc: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Conference call - Monday 5-6 PM PST I have a flight at 9:00 (EST) can you make one or two hours earlier.=20 Regards Ramg []=20 -----Original Message----- From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Thursday, May 06, 2004 1:10 PM To: Robert Haas; Gopal Ram (Nokia-NRC/Boston) Cc: wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: [Forces-protocol] Conference call - Monday 5-6 PM PST Monday, 5-6 PM PST is fine with me. I think it should work for most of us based on the replies that I saw. It will also give Weiming and his team more time to make arrangements for attending the call. =20 But I do hope we have most issues resolved by then, we are already almost a week behind schedule. =20 Thanks Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Thursday, May 06, 2004 6:35 AM To: ram.gopal@nokia.com Cc: Khosravi, Hormuzd M; wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call ? Unfortunately there is no way to get a reasonable common time for Eastern Asia, West Coast, and Europe. But I will be in California next week, and available for a conf call on Monday anytime, Thursday afternoon, and Friday anytime. If you can't do the teleconf on Monday PST 5-6pm, please signal it and propose another alternative. Thanks, -Robert ram.gopal@nokia.com wrote: sounds ok to me. =20 -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Wednesday, May 05, 2004 2:49 PM To: Wang,Weiming; forces-protocol@ietf.org Subject: RE: [Forces-protocol] Conference call ? Hi All, I can setup a teleconference call for this Friday (May 7th),=20 either at 8 AM PST or 5/6 PM PST. Let me know which timing will work for you guys, especially Weiming, Ligang ? If Friday is not good, then may be we can have one on Monday (May 10th)... again either morning or evening depending on your=20 preferences ? Let me know, Thanks Hormuzd ------_=_NextPart_001_01C4338E.B0302388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I am=20 fine with starting this earlier say at 4 PM PST. Weiming & team will = this=20 work for you guys ??
 
Thanks
Hormuzd
-----Original Message-----
From:=20 ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]
Sent: = Thursday,=20 May 06, 2004 10:19 AM
To: Khosravi, Hormuzd M;=20 rha@zurich.ibm.com
Cc: wmwang@mail.hzic.edu.cn;=20 forces-protocol@ietf.org
Subject: RE: [Forces-protocol] = Conference=20 call - Monday 5-6 PM PST

I=20 have a flight at 9:00 (EST) can you make one  or two hours = earlier.=20

Regards
Ramg
[<Ramg>] 
 -----Original=20 Message-----
From: ext Khosravi, Hormuzd M=20 [mailto:hormuzd.m.khosravi@intel.com]
Sent: Thursday, May = 06, 2004=20 1:10 PM
To: Robert Haas; Gopal Ram = (Nokia-NRC/Boston)
Cc:=20 wmwang@mail.hzic.edu.cn; forces-protocol@ietf.org
Subject:=20 [Forces-protocol] Conference call - Monday 5-6 PM=20 PST
Monday, 5-6 PM PST is fine with me. I think it should work = for most=20 of us based on the replies that I saw.
It=20 will also give Weiming and his team more time to make arrangements = for=20 attending the call.
 
But I do hope we have most issues resolved by then, we = are=20 already almost a week behind schedule.
 
Thanks
Hormuzd
-----Original Message-----
From: = Robert Haas=20 [mailto:rha@zurich.ibm.com]
Sent: Thursday, May 06, = 2004 6:35=20 AM
To: ram.gopal@nokia.com
Cc: Khosravi, = Hormuzd M;=20 wmwang@mail.hzic.edu.cn; = forces-protocol@ietf.org
Subject: Re:=20 [Forces-protocol] Conference call = ?

Unfortunately=20 there is no way to get a reasonable common time for Eastern Asia, = West=20 Coast, and Europe. But I will be in California next week, and = available=20 for a conf call on Monday anytime, Thursday afternoon, and Friday=20 anytime.
If you can't do the teleconf on Monday PST 5-6pm, = please=20 signal it and propose another = alternative.
Thanks,
-Robert

ram.gopal@nokia.com = wrote:
sounds ok to me.

  
-----Original =
Message-----
From: forces-protocol-admin@ietf=
.org
[mailto:forces-protocol-adm=
in@ietf.org]On Behalf Of ext Khosravi,
Hormuzd M
Sent: Wednesday, May 05, 2004 2:49 PM
To: Wang,Weiming; forces-protocol@ietf.org
Subject: RE: [Forces-protocol] Conference call ?


Hi All,

I can setup a teleconference call for this Friday (May 7th),=20
either at 8
AM PST or 5/6 PM PST.
Let me know which timing will work for you guys, especially Weiming,
Ligang ?
If Friday is not good, then may be we can have one on Monday (May
10th)... again either morning or evening depending on your=20
preferences ?

Let me know,

Thanks
Hormuzd
------_=_NextPart_001_01C4338E.B0302388-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 19:04:16 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 TAA25880 for ; Thu, 6 May 2004 19:04: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 1BLrtK-0001OC-6B for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 19:02:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46N2waN005334 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 19:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrsy-00016k-UP for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 19:02: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 TAA25792 for ; Thu, 6 May 2004 19:02: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 1BLrsv-0000JW-Nr for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:02:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrrt-0007eo-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:01:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLrqn-0007D9-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrpV-0000Sx-Mx; Thu, 06 May 2004 18: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 1BLroe-00009T-BV for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 18:58: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 SAA25614 for ; Thu, 6 May 2004 18:58: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 1BLrob-0006MQ-0j for forces-protocol@ietf.org; Thu, 06 May 2004 18:58:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrnd-0005wK-00 for forces-protocol@ietf.org; Thu, 06 May 2004 18:57:06 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BLrmg-0005Vp-00 for forces-protocol@ietf.org; Thu, 06 May 2004 18:56:06 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLrmf-000Afd-W7 for forces-protocol@ietf.org; Thu, 06 May 2004 22:56:06 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083810621.1066.40.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EE40DE9@orsmsx408.jf.intel.com> <1083810621.1066.40.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89858093-9FB0-11D8-B6A1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Conference call ? 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, 7 May 2004 00:55:57 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> I can setup a teleconference call for this Friday (May 7th), either >> at 8 >> AM PST or 5/6 PM PST. I will be visiting a site in the Arctic that does not have any communications of any sort during the first slot. Since the second slot falls at 11 PM here, I might be able to make it - assuming i am back south (just below the arctic circle) in time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 19:27:18 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 TAA27137 for ; Thu, 6 May 2004 19:27: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 1BLsFa-0008OV-U6 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 19:25:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46NPw17032263 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 19:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsCr-0007WH-A1 for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 19:23: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 TAA26527 for ; Thu, 6 May 2004 19:23: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 1BLsCp-0001GS-OV for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:23:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsBp-0000pD-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:22:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLsAi-00007R-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 19:20:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLs5z-0005d0-VZ; Thu, 06 May 2004 19:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLs4B-0004xy-Sz for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 19:14: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 TAA26245 for ; Thu, 6 May 2004 19:14: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 1BLs4A-0005Ji-9r for forces-protocol@ietf.org; Thu, 06 May 2004 19:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLs3C-0004u6-00 for forces-protocol@ietf.org; Thu, 06 May 2004 19:13: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 1BLs2G-000446-00 for forces-protocol@ietf.org; Thu, 06 May 2004 19:12:12 -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 i46NC9dm004498; Thu, 6 May 2004 23:12: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 i46N9bk8004656; Thu, 6 May 2004 23:09: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 M2004050616113331870 ; Thu, 06 May 2004 16:11:33 -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, 6 May 2004 16:11: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] Conference call - Monday now! Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC73F@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday now! Thread-Index: AcQzveDggj+Cm9OiQ72J5yaZT0cxNgAALdDQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 06 May 2004 23:11:34.0093 (UTC) FILETIME=[795A07D0:01C433BF] 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, 6 May 2004 16:11: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 changed the day for the conference call to Monday 5-6PM PST based on Robert's request. Did you see my email ?? The time might change to an earlier time based on Ram's request if that is suitable for Weiming. Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Thursday, May 06, 2004 3:56 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call ? > I can setup a teleconference call for this Friday (May 7th), either=20 >> at 8 >> AM PST or 5/6 PM PST. I will be visiting a site in the Arctic that does not have any=20 communications of any sort during the first slot. Since the second=20 slot falls at 11 PM here, I might be able to make it - assuming i am=20 back south (just below the arctic circle) in time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 22:09:11 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 WAA04694 for ; Thu, 6 May 2004 22:09: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 1BLumn-0006Of-6g for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 22:08:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4728P0h024584 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 22:08:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuik-00053N-8I for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 22:04: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 WAA04536 for ; Thu, 6 May 2004 22:04: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 1BLuih-0006QQ-86 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:04:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuhj-0005zj-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:03:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLugk-0005Ze-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLufd-0004Ig-CP; Thu, 06 May 2004 22:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLucx-0003ON-Lb for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 21:58: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 VAA04190 for ; Thu, 6 May 2004 21:58: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 1BLucu-0003rt-MP for forces-protocol@ietf.org; Thu, 06 May 2004 21:58:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLubz-0003RZ-00 for forces-protocol@ietf.org; Thu, 06 May 2004 21:57:16 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLua1-0002ZI-00 for forces-protocol@ietf.org; Thu, 06 May 2004 21:55:14 -0400 Received: from wwm1 (unverified [219.82.188.218]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 7 May 2004 10:07:50 +0800 Message-ID: <004101c433d5$c7696400$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EEAC1A0@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Conference call - Monday 5-6 PM PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C43418.D4486430" 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, 7 May 2004 09:51:11 +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_003E_01C43418.D4486430 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZVRoYXQncyBvaywgd2UnbGwgdHJ5IHRvIG1lZXQgaXQuDQoNClJlZ2FyZHMsDQpXZWlt aW5nDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEtob3NyYXZpLCBI b3JtdXpkIE0gDQogIFRvOiByYW0uZ29wYWxAbm9raWEuY29tIDsgcmhhQHp1cmljaC5pYm0uY29t IA0KICBDYzogd213YW5nQG1haWwuaHppYy5lZHUuY24gOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmcgDQogIFNlbnQ6IEZyaWRheSwgTWF5IDA3LCAyMDA0IDE6MjIgQU0NCiAgU3ViamVjdDogUkU6 IFtGb3JjZXMtcHJvdG9jb2xdIENvbmZlcmVuY2UgY2FsbCAtIE1vbmRheSA1LTYgUE0gUFNUDQoN Cg0KICBJIGFtIGZpbmUgd2l0aCBzdGFydGluZyB0aGlzIGVhcmxpZXIgc2F5IGF0IDQgUE0gUFNU LiBXZWltaW5nICYgdGVhbSB3aWxsIHRoaXMgd29yayBmb3IgeW91IGd1eXMgPz8NCg0KICBUaGFu a3MNCiAgSG9ybXV6ZA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTog cmFtLmdvcGFsQG5va2lhLmNvbSBbbWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb21dIA0KICAgIFNl bnQ6IFRodXJzZGF5LCBNYXkgMDYsIDIwMDQgMTA6MTkgQU0NCiAgICBUbzogS2hvc3JhdmksIEhv cm11emQgTTsgcmhhQHp1cmljaC5pYm0uY29tDQogICAgQ2M6IHdtd2FuZ0BtYWlsLmh6aWMuZWR1 LmNuOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBSRTogW0ZvcmNlcy1w cm90b2NvbF0gQ29uZmVyZW5jZSBjYWxsIC0gTW9uZGF5IDUtNiBQTSBQU1QNCg0KDQogICAgSSBo YXZlIGEgZmxpZ2h0IGF0IDk6MDAgKEVTVCkgY2FuIHlvdSBtYWtlIG9uZSAgb3IgdHdvIGhvdXJz IGVhcmxpZXIuIA0KDQogICAgUmVnYXJkcw0KICAgIFJhbWcNCiAgICBbPFJhbWc+XSANCiAgICAg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBleHQgS2hvc3JhdmksIEhvcm11 emQgTSBbbWFpbHRvOmhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb21dDQogICAgU2VudDogVGh1 cnNkYXksIE1heSAwNiwgMjAwNCAxOjEwIFBNDQogICAgVG86IFJvYmVydCBIYWFzOyBHb3BhbCBS YW0gKE5va2lhLU5SQy9Cb3N0b24pDQogICAgQ2M6IHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuOyBm b3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBbRm9yY2VzLXByb3RvY29sXSBD b25mZXJlbmNlIGNhbGwgLSBNb25kYXkgNS02IFBNIFBTVA0KDQoNCiAgICAgIE1vbmRheSwgNS02 IFBNIFBTVCBpcyBmaW5lIHdpdGggbWUuIEkgdGhpbmsgaXQgc2hvdWxkIHdvcmsgZm9yIG1vc3Qg b2YgdXMgYmFzZWQgb24gdGhlIHJlcGxpZXMgdGhhdCBJIHNhdy4NCiAgICAgIEl0IHdpbGwgYWxz byBnaXZlIFdlaW1pbmcgYW5kIGhpcyB0ZWFtIG1vcmUgdGltZSB0byBtYWtlIGFycmFuZ2VtZW50 cyBmb3IgYXR0ZW5kaW5nIHRoZSBjYWxsLg0KDQogICAgICBCdXQgSSBkbyBob3BlIHdlIGhhdmUg bW9zdCBpc3N1ZXMgcmVzb2x2ZWQgYnkgdGhlbiwgd2UgYXJlIGFscmVhZHkgYWxtb3N0IGEgd2Vl ayBiZWhpbmQgc2NoZWR1bGUuDQoNCiAgICAgIFRoYW5rcw0KICAgICAgSG9ybXV6ZA0KICAgICAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICBGcm9tOiBSb2JlcnQgSGFhcyBb bWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbV0gDQogICAgICAgIFNlbnQ6IFRodXJzZGF5LCBNYXkg MDYsIDIwMDQgNjozNSBBTQ0KICAgICAgICBUbzogcmFtLmdvcGFsQG5va2lhLmNvbQ0KICAgICAg ICBDYzogS2hvc3JhdmksIEhvcm11emQgTTsgd213YW5nQG1haWwuaHppYy5lZHUuY247IGZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZw0KICAgICAgICBTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2Nv bF0gQ29uZmVyZW5jZSBjYWxsID8NCg0KDQogICAgICAgIFVuZm9ydHVuYXRlbHkgdGhlcmUgaXMg bm8gd2F5IHRvIGdldCBhIHJlYXNvbmFibGUgY29tbW9uIHRpbWUgZm9yIEVhc3Rlcm4gQXNpYSwg V2VzdCBDb2FzdCwgYW5kIEV1cm9wZS4gQnV0IEkgd2lsbCBiZSBpbiBDYWxpZm9ybmlhIG5leHQg d2VlaywgYW5kIGF2YWlsYWJsZSBmb3IgYSBjb25mIGNhbGwgb24gTW9uZGF5IGFueXRpbWUsIFRo dXJzZGF5IGFmdGVybm9vbiwgYW5kIEZyaWRheSBhbnl0aW1lLg0KICAgICAgICBJZiB5b3UgY2Fu J3QgZG8gdGhlIHRlbGVjb25mIG9uIE1vbmRheSBQU1QgNS02cG0sIHBsZWFzZSBzaWduYWwgaXQg YW5kIHByb3Bvc2UgYW5vdGhlciBhbHRlcm5hdGl2ZS4NCiAgICAgICAgVGhhbmtzLA0KICAgICAg ICAtUm9iZXJ0DQoNCiAgICAgICAgcmFtLmdvcGFsQG5va2lhLmNvbSB3cm90ZToNCg0Kc291bmRz IG9rIHRvIG1lLg0KDQogIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBmb3JjZXMt cHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmcNClttYWlsdG86Zm9yY2VzLXByb3RvY29sLWFkbWluQGll dGYub3JnXU9uIEJlaGFsZiBPZiBleHQgS2hvc3JhdmksDQpIb3JtdXpkIE0NClNlbnQ6IFdlZG5l c2RheSwgTWF5IDA1LCAyMDA0IDI6NDkgUE0NClRvOiBXYW5nLFdlaW1pbmc7IGZvcmNlcy1wcm90 b2NvbEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtGb3JjZXMtcHJvdG9jb2xdIENvbmZlcmVuY2Ug Y2FsbCA/DQoNCg0KSGkgQWxsLA0KDQpJIGNhbiBzZXR1cCBhIHRlbGVjb25mZXJlbmNlIGNhbGwg Zm9yIHRoaXMgRnJpZGF5IChNYXkgN3RoKSwgDQplaXRoZXIgYXQgOA0KQU0gUFNUIG9yIDUvNiBQ TSBQU1QuDQpMZXQgbWUga25vdyB3aGljaCB0aW1pbmcgd2lsbCB3b3JrIGZvciB5b3UgZ3V5cywg ZXNwZWNpYWxseSBXZWltaW5nLA0KTGlnYW5nID8NCklmIEZyaWRheSBpcyBub3QgZ29vZCwgdGhl biBtYXkgYmUgd2UgY2FuIGhhdmUgb25lIG9uIE1vbmRheSAoTWF5DQoxMHRoKS4uLiBhZ2FpbiBl aXRoZXIgbW9ybmluZyBvciBldmVuaW5nIGRlcGVuZGluZyBvbiB5b3VyIA0KcHJlZmVyZW5jZXMg Pw0KDQpMZXQgbWUga25vdywNCg0KVGhhbmtzDQpIb3JtdXpkDQo= ------=_NextPart_000_003E_01C43418.D4486430 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHRleHQ9IzAwMDAwMCBiZ0NvbG9yPSNmZmZm ZmY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+VGhhdCdzIG9rLCB3 ZSdsbCB0cnkgdG8gbWVldCBpdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tR VU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1 cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFS R0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFD S0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6 IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWhvcm11emQubS5raG9zcmF2aUBpbnRl bC5jb20gDQogIGhyZWY9Im1haWx0bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9z cmF2aSwgSG9ybXV6ZCBNPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9cmFtLmdvcGFsQG5va2lhLmNvbSANCiAg aHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+ IDsgPEEgDQogIHRpdGxlPXJoYUB6dXJpY2guaWJtLmNvbSANCiAgaHJlZj0ibWFpbHRvOnJoYUB6 dXJpY2guaWJtLmNvbSI+cmhhQHp1cmljaC5pYm0uY29tPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9d213YW5n QG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5j biI+d213YW5nQG1haWwuaHppYy5lZHUuY248L0E+IDsgPEEgDQogIHRpdGxlPWZvcmNlcy1wcm90 b2NvbEBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+ Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIE1heSAwNywgMjAwNCAx OjIyIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5TdWJqZWN0OjwvQj4gUkU6IFtGb3JjZXMtcHJvdG9jb2xdIENvbmZlcmVuY2UgDQogIGNhbGwg LSBNb25kYXkgNS02IFBNIFBTVDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz04MDQzMDIxMTctMDYwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IHNpemU9Mj5JIGFtIA0KICBmaW5lIHdpdGggc3RhcnRpbmcgdGhpcyBlYXJsaWVyIHNheSBhdCA0 IFBNIFBTVC4gV2VpbWluZyAmYW1wOyB0ZWFtIHdpbGwgdGhpcyANCiAgd29yayBmb3IgeW91IGd1 eXMgPz88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgwNDMwMjExNy0w NjA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgwNDMwMjExNy0wNjA1MjAw ND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5UaGFua3M8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTgwNDMwMjExNy0wNjA1MjAwND48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5Ib3JtdXpkPC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgi Pg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBs YW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAgICBmYWNlPVRhaG9tYSBzaXpl PTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IDxBIA0KICAgIGhy ZWY9Im1haWx0bzpyYW0uZ29wYWxAbm9raWEuY29tIj5yYW0uZ29wYWxAbm9raWEuY29tPC9BPiAN CiAgICBbbWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb21dIDxCUj48Qj5TZW50OjwvQj4gVGh1cnNk YXksIE1heSAwNiwgMjAwNCAxMDoxOSANCiAgICBBTTxCUj48Qj5Ubzo8L0I+IEtob3NyYXZpLCBI b3JtdXpkIE07IDxBIA0KICAgIGhyZWY9Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPnJoYUB6 dXJpY2guaWJtLmNvbTwvQT48QlI+PEI+Q2M6PC9CPiA8QSANCiAgICBocmVmPSJtYWlsdG86d213 YW5nQG1haWwuaHppYy5lZHUuY24iPndtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPC9BPjsgPEEgDQog ICAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29s QGlldGYub3JnPC9BPjxCUj48Qj5TdWJqZWN0OjwvQj4gDQogICAgUkU6IFtGb3JjZXMtcHJvdG9j b2xdIENvbmZlcmVuY2UgY2FsbCAtIE1vbmRheSA1LTYgUE0gDQogICAgUFNUPEJSPjxCUj48L0ZP TlQ+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz03MjAwNjE4MTctMDYwNTIwMDQ+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5JIA0KICAgIGhhdmUgYSBmbGlnaHQgYXQg OTowMCAoRVNUKSBjYW4geW91IG1ha2Ugb25lJm5ic3A7IG9yIHR3byBob3VycyBlYXJsaWVyLiAN CiAgICA8L0ZPTlQ+PC9TUEFOPjwvRElWPjxTUEFOIGNsYXNzPTcyMDA2MTgxNy0wNjA1MjAwND48 L1NQQU4+PEZPTlQgZmFjZT1UYWhvbWE+DQogICAgPERJVj48QlI+PEZPTlQgc2l6ZT0yPjxTUEFO IGNsYXNzPTcyMDA2MTgxNy0wNjA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMw MDAwZmY+UmVnYXJkczwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQg c2l6ZT0yPjxTUEFOIGNsYXNzPTcyMDA2MTgxNy0wNjA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0K ICAgIGNvbG9yPSMwMDAwZmY+UmFtZzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxE SVY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTcyMDA2MTgxNy0wNjA1MjAwND48Rk9OVCBmYWNl PUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmY+WyZsdDtSYW1nJmd0O10mbmJzcDs8L0ZPTlQ+PC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz03MjAw NjE4MTctMDYwNTIwMDQ+Jm5ic3A7PC9TUEFOPi0tLS0tT3JpZ2luYWwgDQogICAgTWVzc2FnZS0t LS0tPEJSPjxCPkZyb206PC9CPiBleHQgS2hvc3JhdmksIEhvcm11emQgTSANCiAgICBbbWFpbHRv Omhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb21dPEJSPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwg TWF5IDA2LCAyMDA0IA0KICAgIDE6MTAgUE08QlI+PEI+VG86PC9CPiBSb2JlcnQgSGFhczsgR29w YWwgUmFtIA0KICAgIChOb2tpYS1OUkMvQm9zdG9uKTxCUj48Qj5DYzo8L0I+IHdtd2FuZ0BtYWls Lmh6aWMuZWR1LmNuOyANCiAgICBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8QlI+PEI+U3ViamVj dDo8L0I+IFtGb3JjZXMtcHJvdG9jb2xdIENvbmZlcmVuY2UgDQogICAgY2FsbCAtIE1vbmRheSA1 LTYgUE0gUFNUPEJSPjxCUj48L0RJVj48L0ZPTlQ+PC9GT05UPg0KICAgIDxCTE9DS1FVT1RFIGRp cj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAg IDxESVY+PFNQQU4gY2xhc3M9MTIyMDAwNjE3LTA2MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj5Nb25kYXksIDUtNiBQTSBQU1QgaXMgZmluZSB3aXRo IG1lLiBJIHRoaW5rIGl0IHNob3VsZCB3b3JrIGZvciBtb3N0IA0KICAgICAgb2YgdXMgYmFzZWQg b24gdGhlIHJlcGxpZXMgdGhhdCBJIHNhdy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJ Vj48U1BBTiBjbGFzcz0xMjIwMDA2MTctMDYwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICAgICAgc2l6ZT0yPkl0IHdpbGwgYWxzbyBnaXZlIFdlaW1pbmcgYW5kIGhpcyB0 ZWFtIG1vcmUgdGltZSB0byBtYWtlIA0KICAgICAgYXJyYW5nZW1lbnRzIGZvciBhdHRlbmRpbmcg dGhlIGNhbGwuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9MTIy MDAwNjE3LTA2MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz0x MjIwMDA2MTctMDYwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAg c2l6ZT0yPkJ1dCZuYnNwO0kgZG8gaG9wZSB3ZSBoYXZlIG1vc3QgaXNzdWVzIHJlc29sdmVkIGJ5 IHRoZW4sIHdlIGFyZSANCiAgICAgIGFscmVhZHkgYWxtb3N0IGEgd2VlayBiZWhpbmQgc2NoZWR1 bGUuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9MTIyMDAwNjE3 LTA2MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz0xMjIwMDA2 MTctMDYwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0y PlRoYW5rczwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNzPTEyMjAw MDYxNy0wNjA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXpl PTI+SG9ybXV6ZDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8QkxPQ0tRVU9URSBkaXI9bHRy IHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICAgIDxESVY+PC9ESVY+DQogICAgICAg IDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWdu PWxlZnQ+PEZPTlQgDQogICAgICAgIGZhY2U9VGFob21hIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gUm9iZXJ0IA0KICAgICAgICBIYWFzIFttYWlsdG86 cmhhQHp1cmljaC5pYm0uY29tXSA8QlI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBNYXkgMDYsIDIw MDQgDQogICAgICAgIDY6MzUgQU08QlI+PEI+VG86PC9CPiByYW0uZ29wYWxAbm9raWEuY29tPEJS PjxCPkNjOjwvQj4gS2hvc3JhdmksIA0KICAgICAgICBIb3JtdXpkIE07IHdtd2FuZ0BtYWlsLmh6 aWMuZWR1LmNuOyANCiAgICAgICAgZm9yY2VzLXByb3RvY29sQGlldGYub3JnPEJSPjxCPlN1Ympl Y3Q6PC9CPiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gDQogICAgICAgIENvbmZlcmVuY2UgY2FsbCA/ PEJSPjxCUj48L0ZPTlQ+PC9ESVY+VW5mb3J0dW5hdGVseSB0aGVyZSBpcyBubyB3YXkgdG8gDQog ICAgICAgIGdldCBhIHJlYXNvbmFibGUgY29tbW9uIHRpbWUgZm9yIEVhc3Rlcm4gQXNpYSwgV2Vz dCBDb2FzdCwgYW5kIEV1cm9wZS4gDQogICAgICAgIEJ1dCBJIHdpbGwgYmUgaW4gQ2FsaWZvcm5p YSBuZXh0IHdlZWssIGFuZCBhdmFpbGFibGUgZm9yIGEgY29uZiBjYWxsIG9uIA0KICAgICAgICBN b25kYXkgYW55dGltZSwgVGh1cnNkYXkgYWZ0ZXJub29uLCBhbmQgRnJpZGF5IGFueXRpbWUuPEJS PklmIHlvdSBjYW4ndCANCiAgICAgICAgZG8gdGhlIHRlbGVjb25mIG9uIE1vbmRheSBQU1QgNS02 cG0sIHBsZWFzZSBzaWduYWwgaXQgYW5kIHByb3Bvc2UgDQogICAgICAgIGFub3RoZXIgYWx0ZXJu YXRpdmUuPEJSPlRoYW5rcyw8QlI+LVJvYmVydDxCUj48QlI+PEEgDQogICAgICAgIGNsYXNzPW1v ei10eHQtbGluay1hYmJyZXZpYXRlZCANCiAgICAgICAgaHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBu b2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+IHdyb3RlOjxCUj4NCiAgICAgICAgPEJM T0NLUVVPVEUgDQogICAgICAgIGNpdGU9bWlkREM1MDRFOUMzMzg0MDU0Qzg1MDZEM0U2QkIwMTI0 NjAwMTM4ODNCRkBic2ViZTAwMS5hbWVyaWNhcy5ub2tpYS5jb20gDQogICAgICAgIHR5cGU9ImNp dGUiPjxQUkUgd3JhcD0iIj5zb3VuZHMgb2sgdG8gbWUuDQoNCiAgPC9QUkU+DQogICAgICAgICAg PEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiA8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgaHJlZj0ibWFp bHRvOmZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sLWFkbWlu QGlldGYub3JnPC9BPg0KWzxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJtYWls dG86Zm9yY2VzLXByb3RvY29sLWFkbWluQGlldGYub3JnIj5tYWlsdG86Zm9yY2VzLXByb3RvY29s LWFkbWluQGlldGYub3JnPC9BPl1PbiBCZWhhbGYgT2YgZXh0IEtob3NyYXZpLA0KSG9ybXV6ZCBN DQpTZW50OiBXZWRuZXNkYXksIE1heSAwNSwgMjAwNCAyOjQ5IFBNDQpUbzogV2FuZyxXZWltaW5n OyA8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgaHJlZj0ibWFpbHRvOmZvcmNlcy1w cm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPg0KU3ViamVjdDog UkU6IFtGb3JjZXMtcHJvdG9jb2xdIENvbmZlcmVuY2UgY2FsbCA/DQoNCg0KSGkgQWxsLA0KDQpJ IGNhbiBzZXR1cCBhIHRlbGVjb25mZXJlbmNlIGNhbGwgZm9yIHRoaXMgRnJpZGF5IChNYXkgN3Ro KSwgDQplaXRoZXIgYXQgOA0KQU0gUFNUIG9yIDUvNiBQTSBQU1QuDQpMZXQgbWUga25vdyB3aGlj aCB0aW1pbmcgd2lsbCB3b3JrIGZvciB5b3UgZ3V5cywgZXNwZWNpYWxseSBXZWltaW5nLA0KTGln YW5nID8NCklmIEZyaWRheSBpcyBub3QgZ29vZCwgdGhlbiBtYXkgYmUgd2UgY2FuIGhhdmUgb25l IG9uIE1vbmRheSAoTWF5DQoxMHRoKS4uLiBhZ2FpbiBlaXRoZXIgbW9ybmluZyBvciBldmVuaW5n IGRlcGVuZGluZyBvbiB5b3VyIA0KcHJlZmVyZW5jZXMgPw0KDQpMZXQgbWUga25vdywNCg0KVGhh bmtzDQpIb3JtdXpkDQo8L1BSRT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9U RT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_003E_01C43418.D4486430-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 22: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 WAA05402 for ; Thu, 6 May 2004 22: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 1BLv6v-0002yC-VK for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 22:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472TDwD011417 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 22:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLv3I-0001xy-PQ for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 22:25: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 WAA05302 for ; Thu, 6 May 2004 22:25: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 1BLv3F-0007HQ-IQ for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLv2H-0006r6-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:24:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLv1o-0006RJ-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:23:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuzy-0001dr-9K; Thu, 06 May 2004 22:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuxX-0000pk-JG for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 22:19: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 WAA05089 for ; Thu, 6 May 2004 22:19: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 1BLuxU-0004mC-Cj for forces-protocol@ietf.org; Thu, 06 May 2004 22:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuwG-0004Kk-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:18: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 1BLuv9-0003WK-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:17:04 -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 i472Gn0Y012416; Fri, 7 May 2004 02:16: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 i472GoKq029415; Fri, 7 May 2004 02:16:56 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 M2004050619163027509 ; Thu, 06 May 2004 19:16: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); Thu, 6 May 2004 19:16: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] Summary : Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC87E@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Thread-Index: AcQzQtXPlNYrTGnTQZedO2J/SYKVuAAj+YWw From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 07 May 2004 02:16:30.0157 (UTC) FILETIME=[4F1F07D0:01C433D9] 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, 6 May 2004 19:16: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 Weiming, -----Original Message----- > > Association Setup, Setup Resp msg > Association Teardown msg [HK] I agree with the general concept of setup, setup Resp, teardown (I think we all do) and don't want to fight over names or bits either. I will make a simple technical point...we have reserved 8 bits for Msg Type which means we can define 256 Msgs, so why not use this ? It will be much easier & efficient for someone implementing the protocol to look at the Msg type field and say if it is a Asso Setup msg, Teardown msg or Setup Resp...rather than parsing the Msg type field and then some flags and then coming to the same conclusion. Do you guys agree ?? [Weiming] Hormuzd, what you said really confused me. This was exactly my idea. I mentioned this many times before. But at that time, seemed you as well as Jamal objected it , which made me actually give it up completely. I think now we have come to a compromise to use more sythisized msg type mode. Why should we try to break this compromise again? If you now realize we can make full use of the msg type field, then I would like to pick something more for discussion, because I think many of them have much meaning than just 'setup' teardown'. [/Weiming] [HK] I think you have misunderstood some of my arguments. I would like to use the bits in the Msg Type field as much as possible for describing messages rather than using it in conjunction with some other fields. At the same time, I don't think we need too many messages. Also, I think our main argument was around using FE/CE prefix for messages... Jamal, others & myself see that as limiting the scope of some messages such as Join, leave, etc to a certain extent. Does that make sense ? Hope this clarifies your confusion. So the big question is how do we proceed forward ?? :-) We have couple of options... One is to use the compromise list that I sent out (as you can clearly see, Jamal agrees with having a Subscribe msg) -OR- We can go with the approach that I have described below using Msg type, Msg sub-type (4 bits each).... May be we can have some middle ground like 4 bits for Msg Type, 4 bits for Msg Sub-type such that...Msg Type =3D Association & Subtype =3D = Setup or Teardown or Setup Resp. This might be easier to implement/parse and also use the bits more efficiently. Think about this and let us know ? I don't want us to keep spending so many cycles discussing Msg names when we all agree on what kinds of msgs/functionality we need... Here is the summary of what we need... Setup, setup resp, teardown Query, query resp Config, config resp Subscribe, subscribe resp, unsubscribe, unsubscribe resp State maintenance, state maintenance resp=20 Event Notification Packet redirection Heart beat, HB resp (Its better to keep this separate from Event msg as Jamal suggested) We can arrange this as either Msg Types or Msg Type/subtype, let us know what you like ? Also, if adding FE/CE prefixes to some of these messages such as Setup, makes you happy, I am fine with that :) I want us to make fast progress on this and not get stuck on names. But pls take into account all the discussions that we have had so far on peering, msgs, etc. Sorry about the confusion before, but hope this helps clarify stuff, regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 22:30:45 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 WAA05509 for ; Thu, 6 May 2004 22:30: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 1BLv6w-0002yi-G1 for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 22:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472TEOC011443 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 22:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLv4E-0001zQ-UJ for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 22:26: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 WAA05359 for ; Thu, 6 May 2004 22:26: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 1BLv4B-0007gg-OT for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLv3H-0007Hf-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:25:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLv2M-0006rX-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22: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 1BLuzz-0001eB-4D; Thu, 06 May 2004 22:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuxg-0000qC-7Z for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 22:19: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 WAA05125 for ; Thu, 6 May 2004 22:19:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLuxd-0004nE-2e for forces-protocol@ietf.org; Thu, 06 May 2004 22:19:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuwb-0004ND-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:18:33 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLuvx-0003vT-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:17:53 -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 i472HZjx011338; Fri, 7 May 2004 02:17:36 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 i472HgOn030323; Fri, 7 May 2004 02:17: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 M2004050619172007638 ; Thu, 06 May 2004 19:17: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); Thu, 6 May 2004 19:17: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC87F@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQzM3Qfa9bf4vIPQ1iItwtPX7lrDgApRJBA From: "Khosravi, Hormuzd M" To: "Weiming Wang" Cc: X-OriginalArrivalTime: 07 May 2004 02:17:20.0505 (UTC) FILETIME=[6D218690:01C433D9] 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, 6 May 2004 19:17:20 -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 Weiming Wang I also think a ACK flag to give customers more flexibility will be benificial for our protocol being futher more widely used. One thing now remained is we may now need to decide if we put ACK as a specific msg and included in the msgs, or just let others such as common header section do it. [HK] I don't think we need an ACK msg, we already have Response messages for all the messages that we need a response/ack for. As I had explained before, you can think of Response as being a superset of ACK, i.e. it does convey ack and them some more stuff. Also, look at my email on Msg Types for more clarification. 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 May 6 22:38: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 WAA05759 for ; Thu, 6 May 2004 22:38: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 1BLvDK-0004rA-1p for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 22:35:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472ZoXT018660 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 22:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvC2-0004bE-3A for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 22:34: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 WAA05618 for ; Thu, 6 May 2004 22:34: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 1BLvBy-0003Cr-U7 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:34:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvAx-0002nb-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:33:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLvAT-0002OL-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLv8e-0003e0-2W; Thu, 06 May 2004 22: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 1BLv74-0002yx-Ck for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 22:29: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 WAA05394 for ; Thu, 6 May 2004 22:29: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 1BLv71-000153-1Z for forces-protocol@ietf.org; Thu, 06 May 2004 22:29:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLv5y-0000fp-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:28:15 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLv5E-0007gu-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:27:29 -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 i472RDjx014812; Fri, 7 May 2004 02:27:13 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 i472QwP1002440; Fri, 7 May 2004 02:27:20 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 M2004050619265608432 ; Thu, 06 May 2004 19:26: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); Thu, 6 May 2004 19:26: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] topic 4c: Common Header Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC881@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header Thread-Index: AcQzYBzNso+ZBnEpQB2z4efcu7boYAAefozA From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 07 May 2004 02:26:56.0478 (UTC) FILETIME=[C47007E0:01C433DA] 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, 6 May 2004 19:26: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- > 2. Jamal, I have a feeling that you seem very careful not to put too many flags > in msg bodies. I wonder if there are some technical disadvantage or barrier > behind to do like this according to your implementation experience? Hornestly, > I'm short of experiences on this. I am not picky. I think flags in the main header are for extending the message. A lot of of protocols i know keep them there - thats where my bias is coming from. I have no problem with putting flags in the submsg;however, since you will have flags in the main header, why not use them? Note we can also have flags in the TLVs T part. I think diameter does this. [HK] For some cases in our case, such as 2-phase commit, I think it makes sense to have flags only in the message body or the TLV that we define for that msg rather than the msg header. But I don't want to be too picky about this either. Let us know if you're fine with this (having flags in msg body) ?=20 BTW, we don't need to have 16 bits for Flags in the common header if we don't need them. We can just do with 4-5 bits for example, if that is sufficient. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 6 23:00:42 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 XAA06577 for ; Thu, 6 May 2004 23:00: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 1BLvXu-0001fM-2p for forces-protocol-archive@odin.ietf.org; Thu, 06 May 2004 22:57:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472v6EL006399 for forces-protocol-archive@odin.ietf.org; Thu, 6 May 2004 22:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvRT-0000QS-RX for forces-protocol-web-archive@optimus.ietf.org; Thu, 06 May 2004 22: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 WAA06204 for ; Thu, 6 May 2004 22: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 1BLvRQ-00026p-Ev for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:50:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvQS-0001hI-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:49:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLvPV-0001Hc-00 for forces-protocol-web-archive@ietf.org; Thu, 06 May 2004 22:48:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvKI-0006tI-5L; Thu, 06 May 2004 22:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvHk-0006EQ-D1 for forces-protocol@optimus.ietf.org; Thu, 06 May 2004 22:40: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 WAA05867 for ; Thu, 6 May 2004 22:40: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 1BLvHg-0005hJ-VN for forces-protocol@ietf.org; Thu, 06 May 2004 22:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvGl-0005IX-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:39:24 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BLvGO-0004tK-00 for forces-protocol@ietf.org; Thu, 06 May 2004 22:39:00 -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 i472bKCj014696; Fri, 7 May 2004 02:37:20 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 i472cJPB007387; Fri, 7 May 2004 02:38:47 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 M2004050619382509335 ; Thu, 06 May 2004 19:38: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); Thu, 6 May 2004 19:38:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C433DC.5EA6903C" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] Message-ID: <468F3FDA28AA87429AD807992E22D07EEAC883@orsmsx408.jf.intel.com> Thread-Topic: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] Thread-Index: AcQzgXFVYyXa1EadRrWzPuVEW4JSUAAWaT9Q From: "Khosravi, Hormuzd M" To: "Robert Haas" , X-OriginalArrivalTime: 07 May 2004 02:38:25.0096 (UTC) FILETIME=[5EE2CC80:01C433DC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 6 May 2004 19:38: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.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C433DC.5EA6903C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 I like this concept, however there are couple of issues I can think of... One, I wouldn't call it an LFB, that is very confusing to me. Two, are you suggesting that this should be defined by the Model team instead of this team ? I don't think so but again, if you call this LFB we might run into that issue. =20 I think if we define the a TLV for addressing this, we can achieve the same flexibility that you are talking about. That TLV could be carried in whatever msg makes sense, e.g. Event msg or State Maintenance msg, etc. =20 Does that help ? Let me know what you think. =20 Thanks again for this posting, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Robert Haas Sent: Thursday, May 06, 2004 8:15 AM To: forces-protocol@ietf.org Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] Maybe my last message on that topic went unnoticed, so I wanted to again stress the possibility to create an FE LFB (call it meta LFB, control LFB, etc) that can be configured, events can be subscribed to, etc. The difference between the FE LFB and the other "regular" LFBs is that no data packet traverses the FE LFB. The purpose of the FE LFB is to facilitate the control of the FE: Examples: - FE UP and DOWN don't need to be special ForCES messages. Instead, they can be events originated by the FE LFB. - Configuring the interval timer for heartbeats messages can be done using a Config message to the hearbeat interval attribute of the FE LFB. The reason to introduce this LFB versus creating specific ForCES messages is flexibility: at some point in time, if we need to enhance the ForCES protocol, we don't necessarily need to change the protocol itself. Instead, we can create a new version of the FE LFB that supports new features. I'd like to have your comments on such an FE LFB. Regards, -Robert ------_=_NextPart_001_01C433DC.5EA6903C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Robert,
 
I like=20 this concept, however there are couple of issues I can think=20 of...
One, I=20 wouldn't call it an LFB, that is very confusing to = me.
Two,=20 are you suggesting that this should be defined by the Model team instead = of this=20 team ? I don't think so but again, if you call this LFB we might run = into that=20 issue.
 
I=20 think if we define the a TLV for addressing this, we can achieve the = same=20 flexibility that you are talking about. That TLV could be carried in = whatever=20 msg makes sense, e.g. Event msg or State Maintenance msg,=20 etc.
 
Does=20 that help ? Let me know what you think.
 
Thanks=20 again for this posting,
Hormuzd
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On=20 Behalf Of Robert Haas
Sent: Thursday, May 06, 2004 8:15=20 AM
To: forces-protocol@ietf.org
Subject: [Fwd: Re: = [Forces-protocol] Summary : Protocol Messages: topic 3 &=20 4a]

Maybe my last message on that topic went = unnoticed, so=20 I wanted to again stress the possibility to create an FE LFB (call it = meta=20 LFB, control LFB, etc) that can be configured, events can be = subscribed to,=20 etc. The difference between the FE LFB and the other "regular" LFBs is = that no=20 data packet traverses the FE LFB. The purpose of the FE LFB is to = facilitate=20 the control of the FE:

Examples:

- FE UP and DOWN don't = need to=20 be special ForCES messages. Instead, they can be events originated by = the FE=20 LFB.
- Configuring the interval timer for heartbeats messages can = be done=20 using a Config message to the hearbeat interval attribute of the FE=20 LFB.

The reason to introduce this LFB versus creating specific = ForCES=20 messages is flexibility: at some point in time, if we need to enhance = the=20 ForCES protocol, we don't necessarily need to change the protocol = itself.=20 Instead, we can create a new version of the FE LFB that supports new=20 features.

I'd like to have your comments on such an FE=20 LFB.

Regards,
-Robert
------_=_NextPart_001_01C433DC.5EA6903C-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 00:19: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 AAA09860 for ; Fri, 7 May 2004 00:19: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 1BLwjk-0005e1-4L for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 00:13:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i474DOWc021693 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 00:13:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLwgo-0003wx-Hq for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 00:10: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 AAA09541 for ; Fri, 7 May 2004 00:10: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 1BLwgm-0002jT-8O for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 00:10:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwfn-0002L5-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 00:09:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLwfM-0001x7-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 00:08:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLwcb-0002ri-RH; Fri, 07 May 2004 00: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 1BLwax-0002X7-Ns for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 00:04: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 AAA09292 for ; Fri, 7 May 2004 00:04: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 1BLwav-0000EQ-Ac for forces-protocol@ietf.org; Fri, 07 May 2004 00:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwZv-0007am-00 for forces-protocol@ietf.org; Fri, 07 May 2004 00:03:16 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLwYC-0006l6-00 for forces-protocol@ietf.org; Fri, 07 May 2004 00:01:31 -0400 Received: from wwm1 (unverified [219.82.188.218]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 7 May 2004 12:14:00 +0800 Message-ID: <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <409A5679.8050501@zurich.ibm.com> Subject: Re: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01C4342A.732E4720" 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, 7 May 2004 11:57:19 +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_00E7_01C4342A.732E4720 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQpIaSBSb2JlcnQsIGFuZCBhbGwsDQoNCkknbSB2ZXJ5IGdsYWQgdGhhdCB5b3VyIGlkZWEgb2Yg RkUgTEZCIG1heSBxdWl0ZSBtZWV0IHdpdGggbXkgaWRlYSBhbnl3YXkuIEFjdHVhbGx5IEkgY2Fs bGVkIGl0ICdGRSBTbGF2ZScgaW5zdGVhZCBvZiBGRSBMRkIuIEkgdGhpbmsgYm90aCBvZiB1cyB0 aGluayBvZiB0aGlzIGVudGl0eSBiZWNhdXNlIHdlIGhhdmUgcmVhbGl6ZWQgdGhhdCBtYW55IG9m IHRoZSBmdW5jdGlvbnMgaW4gRkUgYXJlIGFjdHVhbGx5IGJleW9uZCB0aGUgc2NvcGUgb2YgTEZC cyBkZWZpbmVkIGJ5IEZFIG1vZGVscy4gVGhlc2UgZnVuY3Rpb25zIGNhbiBhbHNvIGJlIGRlc2Ny aWJlZCBieSB1c2luZyBub3Rpb25zIHN1Y2ggYXMgYXR0aWJ1dGVzLCBldmVudHMsIGNhcGFiaWxp dGVzLCBhbmQgc3RhdGVzKFVQL0Rvd24pLiBCZWNhdXNlIHRoZXNlIG5vdGlvbnMgaGVyZSBhcmUg bWFpbmx5IGVmZmVjdGl2ZSBmb3Igd2hvbGUgRkUgKHRoYXQgaXMsIHRha2Ugd2hvZSBGRSAoYXQg YSBjb2Fyc2UgbGF5ZXIpIGFzIGEgbWFuYWdlZCBlbnRpdHkpLCBpbiBteSBzY2hlbWUsIHdlIGp1 c3QgY2FsbCB0aGVuIEZFIGF0dHJpYnV0ZXMsIEZFIGV2ZW50cywgYW5kIEZFIGNhcGFiaWxpdGll cywgd2hpY2ggYXJlIGRpc2NyaW1pbmF0ZWQgZnJvbSBMRkIgYXR0cmlidXRlcywgTEZCIGV2ZW50 cywgYW5kIExGQiBjYXBhYmlsaXRpZXMuDQoNCkknZCBsaWtlIHRvIHNob3cgc29tZSBvZiB0aGUg Y29udGVudHMgdG8gc2VlIGlmIHRoZXkgbWVldCB5b3VyIHRob3VnaHRzOg0KRm9yIEZFIGV2ZW50 cywgd2UgbWF5IGhhdmU6DQouRkUgc3RhdGUgZXZlbnRzIChGRSBVcC9Eb3duL0FjdGl2ZS9JbmFj dGl2ZS9GYWlsb3ZlcikNCi5GRSBoZWFydGJlYXQNCi5GRSBEb1MgYWxlcnQNCi5GRSBjYXBhYmls aXR5IGNoYW5nZQ0KLkZFIFRNTCBldmVudHMNCg0KRm9yIEZFIGNhcGFiaWxpdHksIHdlIG1heSBo YXZlDQouQ3VycmVudGx5IHN1cHBvcnRlZCBGb3JDRVMgcHJvdG9jb2wgdmVyc2lvbiBieSB0aGUg RkUNCi5DdXJyZW50bHkgc3VwcG9ydGVkIEZvckNFUyBGRSBtb2RlbCBieSB0aGUgRkUNCi5Tb21l IFRNTCBjYXBhYmlsaXR5IGRlc2NyaXB0aW9uDQoNCkZlIEZFIGF0dHJpYnV0ZXMsIHZpYSB3aGlj aCB3ZSBtYXkgYWJsZSB0byBkbzoNCi4gVG8gc2V0dXAgb3IgbmVnb3RpYXRlIGEgdmVyc2lvbiBv ZiBGRSBtb2RlbCBvciB0aGUgRm9yQ0VTIHByb3RvY29sDQouIFRvIHNldHVwIG1hbnkgcG9saWNp ZXMgZm9yIHRoZSBGRSwgZm9yIHdoaWNoIEZFIG1vZGVsIGlzIG5vdCBhYmxlIHRvIGRvIChvdXQg b2YgaXRzIHNjb3BlKSwgZS5nLiwNCiAgLSBGRSBmYWlsb3ZlciBhbmQgcmVzdGFydCBwb2xpY3kg KHN1Y2ggYXMgZ3JhY2VmdWwgcmVzdGFydCBvciBub3QpDQogIC0gRkUgaGVhcnRiZWF0IHBvbGlj eSAoc3VjaCBhcyB0aGUgaW50ZXJ2YWxzIGZvciB0aGUgaGVhcnRiZWF0LCBldGMpDQoNCi4gRkUg ZXZlbnRzIHN1YnNjcmliZS91bnN1YnNjcmliZSAoaW5jbHVkaW5nIHRvIHN0YXJ0IG9yIHN0b3Ag aGVhcnRiZWF0cykNCi4gZm9yIFRNTCBtYW5hZ2VtZW50IGlmIG5lZWRlZC4NCg0KQW55d2F5LCBh bnkgbWFuYWdlbWVudCB0aGF0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgRkUgbW9kZWwgY2FuIGJl IHB1dCBpbiB0aGUgRkUgTEZCLyBGRSBzbGF2ZSBlbnRpdHkuIFRoYXQgaXMgSSB0aGluayBvdXIg aWRlYSwgaXMgaXQgcmlnaHQ/DQoNCkNoZWVycywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCiAgRnJvbTogUm9iZXJ0IEhhYXMgDQogIFRvOiBmb3JjZXMtcHJvdG9j b2xAaWV0Zi5vcmcgDQogIFNlbnQ6IFRodXJzZGF5LCBNYXkgMDYsIDIwMDQgMTE6MTUgUE0NCiAg U3ViamVjdDogW0Z3ZDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFN1bW1hcnkgOiBQcm90b2NvbCBN ZXNzYWdlczogdG9waWMgMyAmIDRhXQ0KDQoNCiAgTWF5YmUgbXkgbGFzdCBtZXNzYWdlIG9uIHRo YXQgdG9waWMgd2VudCB1bm5vdGljZWQsIHNvIEkgd2FudGVkIHRvIGFnYWluIHN0cmVzcyB0aGUg cG9zc2liaWxpdHkgdG8gY3JlYXRlIGFuIEZFIExGQiAoY2FsbCBpdCBtZXRhIExGQiwgY29udHJv bCBMRkIsIGV0YykgdGhhdCBjYW4gYmUgY29uZmlndXJlZCwgZXZlbnRzIGNhbiBiZSBzdWJzY3Jp YmVkIHRvLCBldGMuIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIEZFIExGQiBhbmQgdGhlIG90 aGVyICJyZWd1bGFyIiBMRkJzIGlzIHRoYXQgbm8gZGF0YSBwYWNrZXQgdHJhdmVyc2VzIHRoZSBG RSBMRkIuIFRoZSBwdXJwb3NlIG9mIHRoZSBGRSBMRkIgaXMgdG8gZmFjaWxpdGF0ZSB0aGUgY29u dHJvbCBvZiB0aGUgRkU6DQoNCiAgRXhhbXBsZXM6DQoNCiAgLSBGRSBVUCBhbmQgRE9XTiBkb24n dCBuZWVkIHRvIGJlIHNwZWNpYWwgRm9yQ0VTIG1lc3NhZ2VzLiBJbnN0ZWFkLCB0aGV5IGNhbiBi ZSBldmVudHMgb3JpZ2luYXRlZCBieSB0aGUgRkUgTEZCLg0KICAtIENvbmZpZ3VyaW5nIHRoZSBp bnRlcnZhbCB0aW1lciBmb3IgaGVhcnRiZWF0cyBtZXNzYWdlcyBjYW4gYmUgZG9uZSB1c2luZyBh IENvbmZpZyBtZXNzYWdlIHRvIHRoZSBoZWFyYmVhdCBpbnRlcnZhbCBhdHRyaWJ1dGUgb2YgdGhl IEZFIExGQi4NCg0KICBUaGUgcmVhc29uIHRvIGludHJvZHVjZSB0aGlzIExGQiB2ZXJzdXMgY3Jl YXRpbmcgc3BlY2lmaWMgRm9yQ0VTIG1lc3NhZ2VzIGlzIGZsZXhpYmlsaXR5OiBhdCBzb21lIHBv aW50IGluIHRpbWUsIGlmIHdlIG5lZWQgdG8gZW5oYW5jZSB0aGUgRm9yQ0VTIHByb3RvY29sLCB3 ZSBkb24ndCBuZWNlc3NhcmlseSBuZWVkIHRvIGNoYW5nZSB0aGUgcHJvdG9jb2wgaXRzZWxmLiBJ bnN0ZWFkLCB3ZSBjYW4gY3JlYXRlIGEgbmV3IHZlcnNpb24gb2YgdGhlIEZFIExGQiB0aGF0IHN1 cHBvcnRzIG5ldyBmZWF0dXJlcy4NCg0KICBJJ2QgbGlrZSB0byBoYXZlIHlvdXIgY29tbWVudHMg b24gc3VjaCBhbiBGRSBMRkIuDQoNCiAgUmVnYXJkcywNCiAgLVJvYmVydA0K ------=_NextPart_000_00E7_01C4342A.732E4720 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkhpIFJvYmVydCwgYW5kIGFsbCw8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkknbSB2ZXJ5IGdsYWQgdGhhdCB5b3VyIGlkZWEgb2YgRkUgTEZCIG1heSBx dWl0ZSBtZWV0IHdpdGggbXkgaWRlYSBhbnl3YXkuIA0KQWN0dWFsbHkgSSBjYWxsZWQgaXQgJ0ZF IFNsYXZlJyBpbnN0ZWFkIG9mIEZFIExGQi4gSSB0aGluayBib3RoIG9mIHVzIHRoaW5rIG9mIA0K dGhpcyBlbnRpdHkgYmVjYXVzZSB3ZSBoYXZlIHJlYWxpemVkIHRoYXQgbWFueSBvZiB0aGUgZnVu Y3Rpb25zIGluIEZFIGFyZSANCmFjdHVhbGx5IGJleW9uZCB0aGUgc2NvcGUgb2YgTEZCcyBkZWZp bmVkIGJ5IEZFIG1vZGVscy4gVGhlc2UgZnVuY3Rpb25zIGNhbiBhbHNvIA0KYmUgZGVzY3JpYmVk IGJ5IHVzaW5nIG5vdGlvbnMgc3VjaCBhcyBhdHRpYnV0ZXMsIGV2ZW50cywgY2FwYWJpbGl0ZXMs IGFuZCANCnN0YXRlcyhVUC9Eb3duKS4gQmVjYXVzZSB0aGVzZSBub3Rpb25zIGhlcmUgYXJlIG1h aW5seSBlZmZlY3RpdmUgZm9yIHdob2xlIEZFIA0KKHRoYXQgaXMsIHRha2Ugd2hvZSBGRSAoYXQg YSBjb2Fyc2UgbGF5ZXIpJm5ic3A7YXMgYSBtYW5hZ2VkIGVudGl0eSksIGluIG15IA0Kc2NoZW1l LCB3ZSBqdXN0IGNhbGwgdGhlbiBGRSBhdHRyaWJ1dGVzLCBGRSBldmVudHMsJm5ic3A7YW5kIEZF IGNhcGFiaWxpdGllcywgDQp3aGljaCBhcmUgZGlzY3JpbWluYXRlZCBmcm9tIExGQiBhdHRyaWJ1 dGVzLCBMRkIgZXZlbnRzLCBhbmQgTEZCIA0KY2FwYWJpbGl0aWVzLjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ SSdkIGxpa2UgdG8gc2hvdyBzb21lIG9mIHRoZSBjb250ZW50cyB0byBzZWUgaWYgdGhleSBtZWV0 IHlvdXIgDQp0aG91Z2h0czo8L0RJVj4NCjxESVY+Rm9yIEZFJm5ic3A7ZXZlbnRzLCB3ZSBtYXkg aGF2ZTo8L0RJVj4NCjxESVY+LkZFIHN0YXRlIGV2ZW50cyAoRkUgVXAvRG93bi9BY3RpdmUvSW5h Y3RpdmUvRmFpbG92ZXIpPC9ESVY+DQo8RElWPi5GRSBoZWFydGJlYXQ8L0RJVj4NCjxESVY+LkZF IERvUyBhbGVydDwvRElWPg0KPERJVj4uRkUgY2FwYWJpbGl0eSBjaGFuZ2U8L0RJVj4NCjxESVY+ LkZFIFRNTCBldmVudHM8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkZvciBGRSBjYXBh YmlsaXR5LCB3ZSBtYXkgaGF2ZTwvRElWPg0KPERJVj4uQ3VycmVudGx5IHN1cHBvcnRlZCBGb3JD RVMgcHJvdG9jb2wgdmVyc2lvbiBieSB0aGUgRkU8L0RJVj4NCjxESVY+LkN1cnJlbnRseSBzdXBw b3J0ZWQgRm9yQ0VTIEZFIG1vZGVsIGJ5IHRoZSBGRTwvRElWPg0KPERJVj4uU29tZSBUTUwgY2Fw YWJpbGl0eSBkZXNjcmlwdGlvbjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+RmUmbmJz cDtGRSBhdHRyaWJ1dGVzLCB2aWEgd2hpY2ggd2UgbWF5IGFibGUgdG8gZG86PC9ESVY+DQo8RElW Pi4gVG8gc2V0dXAgb3IgbmVnb3RpYXRlIGEgdmVyc2lvbiBvZiBGRSBtb2RlbCBvciB0aGUgRm9y Q0VTIHByb3RvY29sPC9ESVY+DQo8RElWPi4gVG8gc2V0dXAgbWFueSBwb2xpY2llcyBmb3IgdGhl IEZFLCBmb3Igd2hpY2gmbmJzcDtGRSBtb2RlbCBpcyBub3QgYWJsZSB0byANCmRvIChvdXQgb2Yg aXRzIHNjb3BlKSwgZS5nLiw8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7LSBGRSBmYWlsb3ZlciBh bmQgcmVzdGFydCBwb2xpY3kgKHN1Y2ggYXMgZ3JhY2VmdWwgcmVzdGFydCBvciANCm5vdCk8L0RJ Vj4NCjxESVY+Jm5ic3A7Jm5ic3A7LSBGRSBoZWFydGJlYXQgcG9saWN5IChzdWNoIGFzIHRoZSBp bnRlcnZhbHMgZm9yIHRoZSBoZWFydGJlYXQsIA0KZXRjKTwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+LiZuYnNwO0ZFIGV2ZW50cyBzdWJzY3JpYmUvdW5zdWJzY3JpYmUgKGluY2x1ZGlu ZyB0byBzdGFydCBvciBzdG9wIA0KaGVhcnRiZWF0cyk8L0RJVj4NCjxESVY+LiBmb3IgVE1MIG1h bmFnZW1lbnQgaWYgbmVlZGVkLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QW55d2F5 LCBhbnkgbWFuYWdlbWVudCB0aGF0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgRkUgbW9kZWwgY2Fu IGJlIHB1dCBpbiANCnRoZSBGRSBMRkIvIEZFIHNsYXZlIGVudGl0eS4gVGhhdCBpcyBJIHRoaW5r IG91ciBpZGVhLCBpcyBpdCByaWdodD88L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPkNoZWVycyw8L0RJVj4NCjxE SVY+V2VpbWluZzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQ QURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6 ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBmb250LWNvbG9yOiBibGFjayI+ PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRv OnJoYUB6dXJpY2guaWJtLmNvbSI+Um9iZXJ0IEhhYXM8L0E+IA0KICA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9Zm9y Y2VzLXByb3RvY29sQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGll dGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBNYXkg MDYsIDIwMDQgMTE6MTUgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBbRndkOiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gU3Vt bWFyeSANCiAgOiBQcm90b2NvbCBNZXNzYWdlczogdG9waWMgMyAmYW1wOyA0YV08L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48QlI+PC9ESVY+ DQogIDxESVY+TWF5YmUgbXkgbGFzdCBtZXNzYWdlIG9uIHRoYXQgdG9waWMgd2VudCB1bm5vdGlj ZWQsIHNvIEkgd2FudGVkIHRvIGFnYWluIA0KICBzdHJlc3MgdGhlIHBvc3NpYmlsaXR5IHRvIGNy ZWF0ZSBhbiBGRSBMRkIgKGNhbGwgaXQgbWV0YSBMRkIsIGNvbnRyb2wgTEZCLCANCiAgZXRjKSB0 aGF0IGNhbiBiZSBjb25maWd1cmVkLCBldmVudHMgY2FuIGJlIHN1YnNjcmliZWQgdG8sIGV0Yy4g VGhlIGRpZmZlcmVuY2UgDQogIGJldHdlZW4gdGhlIEZFIExGQiBhbmQgdGhlIG90aGVyICJyZWd1 bGFyIiBMRkJzIGlzIHRoYXQgbm8gZGF0YSBwYWNrZXQgDQogIHRyYXZlcnNlcyB0aGUgRkUgTEZC LiBUaGUgcHVycG9zZSBvZiB0aGUgRkUgTEZCIGlzIHRvIGZhY2lsaXRhdGUgdGhlIGNvbnRyb2wg DQogIG9mIHRoZSBGRTo8QlI+PEJSPkV4YW1wbGVzOjxCUj48QlI+LSBGRSBVUCBhbmQgRE9XTiBk b24ndCBuZWVkIHRvIGJlIHNwZWNpYWwgDQogIEZvckNFUyBtZXNzYWdlcy4gSW5zdGVhZCwgdGhl eSBjYW4gYmUgZXZlbnRzIG9yaWdpbmF0ZWQgYnkgdGhlIEZFIExGQi48QlI+LSANCiAgQ29uZmln dXJpbmcgdGhlIGludGVydmFsIHRpbWVyIGZvciBoZWFydGJlYXRzIG1lc3NhZ2VzIGNhbiBiZSBk b25lIHVzaW5nIGEgDQogIENvbmZpZyBtZXNzYWdlIHRvIHRoZSBoZWFyYmVhdCBpbnRlcnZhbCBh dHRyaWJ1dGUgb2YgdGhlIEZFIExGQi48QlI+PEJSPlRoZSANCiAgcmVhc29uIHRvIGludHJvZHVj ZSB0aGlzIExGQiB2ZXJzdXMgY3JlYXRpbmcgc3BlY2lmaWMgRm9yQ0VTIG1lc3NhZ2VzIGlzIA0K ICBmbGV4aWJpbGl0eTogYXQgc29tZSBwb2ludCBpbiB0aW1lLCBpZiB3ZSBuZWVkIHRvIGVuaGFu Y2UgdGhlIEZvckNFUyBwcm90b2NvbCwgDQogIHdlIGRvbid0IG5lY2Vzc2FyaWx5IG5lZWQgdG8g Y2hhbmdlIHRoZSBwcm90b2NvbCBpdHNlbGYuIEluc3RlYWQsIHdlIGNhbiANCiAgY3JlYXRlIGEg bmV3IHZlcnNpb24gb2YgdGhlIEZFIExGQiB0aGF0IHN1cHBvcnRzIG5ldyBmZWF0dXJlcy48QlI+ PEJSPkknZCBsaWtlIA0KICB0byBoYXZlIHlvdXIgY29tbWVudHMgb24gc3VjaCBhbiBGRSANCkxG Qi48QlI+PEJSPlJlZ2FyZHMsPEJSPi1Sb2JlcnQ8QlI+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_00E7_01C4342A.732E4720-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 01:46: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 BAA13238 for ; Fri, 7 May 2004 01:46: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 1BLyAA-0005YJ-VF for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 01:44:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i475ikRe021336 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 01:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLy7s-0004zJ-GJ for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 01:42: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 BAA13050 for ; Fri, 7 May 2004 01:42: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 1BLy7p-0001X7-DO for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:42:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLy6r-00017L-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:41:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLy5w-0000iR-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:40:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLxxp-0001t0-Qh; Fri, 07 May 2004 01: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 1BLxrV-0008SP-0d for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 01:25: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 BAA12224 for ; Fri, 7 May 2004 01:25: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 1BLxrS-0002Ev-0i for forces-protocol@ietf.org; Fri, 07 May 2004 01:25:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLxqU-0001oa-00 for forces-protocol@ietf.org; Fri, 07 May 2004 01:24:27 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLxpd-0001Nd-00 for forces-protocol@ietf.org; Fri, 07 May 2004 01:23:34 -0400 Received: from wwm1 (unverified [219.82.188.218]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 7 May 2004 13:36:08 +0800 Message-ID: <013a01c433f2$e068c000$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EEABD94@orsmsx408.jf.intel.com> <1083810592.1067.38.camel@jzny.localdomain> Subject: Re: peering WAS(Re: [Forces-protocol] Summary : ProtocolMessages: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: Fri, 7 May 2004 13:19: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > On Wed, 2004-05-05 at 22:06, Khosravi, Hormuzd M wrote: > > Jamal, > > > > -----Original Message----- > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > > > Subscribe/Unsubscribe msg > > > [Weiming] This is a little ridiculous msg. Do you mean 'event > > sub/unsub' ? I > > > don't think Jamal agrees this also. A config or a Event msg can do > > this well. > > > > I think we need config messages going from FE to CE informing it of > > events as well. Not all events fit under this message, but a subset > > does. > > Is this what you are refering to Weiming? Just remember that not all > > events fit in that model. Also the subscription is needed otherwise the > > default should be you get no events. > > > > [HK] Just to clarify again, you are saying that we need a Subscribe msg, > > right ? > > Just want to clear this one, > > I think a subscribe message is important to have. In our implementation > we didnt have a subscribe message and the default was to send all config > events. This sometimes resulted in a lot of annoying unneeded messages. [Weiming]Jamal, I think we all have no doubt that to subscribe/unsubscribe events is definitely necessary. The difference between Hormuzd and me is if we need to have specific msgs to do this or not. My idea is it can be very easily done by config msg, therefore we don't need a specific msg (according to Hormuzd idea, 4 msgs, sub and resp, unsub and resp) to do this. In this way, we actually treat the sub/unsub as an FE attribute, behind which is actually an event sub/unsub table. My idea is we have just used a quite synthisized msg mode, why should we spend so many msgs in this very tiny task then. We'd like to hear your thoughs on this. Thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 02:00: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 CAA14885 for ; Fri, 7 May 2004 02:00: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 1BLyHH-0007Q3-FY for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 01:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i475q71j028514 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 01:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLyCj-0006JL-4v for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 01:47: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 BAA13262 for ; Fri, 7 May 2004 01:47: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 1BLyCf-0003b9-RR for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:47:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLyBk-0003Ba-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:46:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLyAs-0002mg-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 01:45:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLy8U-0005Gk-ER; Fri, 07 May 2004 01:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLy59-0003nR-9w for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 01:39: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 BAA12921 for ; Fri, 7 May 2004 01:39: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 1BLy56-0000JP-2u for forces-protocol@ietf.org; Fri, 07 May 2004 01:39:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLy43-0007i1-00 for forces-protocol@ietf.org; Fri, 07 May 2004 01:38:28 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BLy3V-0007C5-00 for forces-protocol@ietf.org; Fri, 07 May 2004 01:37:54 -0400 Received: from wwm1 (unverified [219.82.188.218]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Fri, 7 May 2004 13:49:49 +0800 Message-ID: <013b01c433f4$c9ab73b0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EEAC87E@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary : 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: Fri, 7 May 2004 13:33: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, -----Original Message----- > > Association Setup, Setup Resp msg > Association Teardown msg [HK] I agree with the general concept of setup, setup Resp, teardown (I think we all do) and don't want to fight over names or bits either. I will make a simple technical point...we have reserved 8 bits for Msg Type which means we can define 256 Msgs, so why not use this ? It will be much easier & efficient for someone implementing the protocol to look at the Msg type field and say if it is a Asso Setup msg, Teardown msg or Setup Resp...rather than parsing the Msg type field and then some flags and then coming to the same conclusion. Do you guys agree ?? [Weiming] Hormuzd, what you said really confused me. This was exactly my idea. I mentioned this many times before. But at that time, seemed you as well as Jamal objected it , which made me actually give it up completely. I think now we have come to a compromise to use more sythisized msg type mode. Why should we try to break this compromise again? If you now realize we can make full use of the msg type field, then I would like to pick something more for discussion, because I think many of them have much meaning than just 'setup' teardown'. [/Weiming] [HK] I think you have misunderstood some of my arguments. I would like to use the bits in the Msg Type field as much as possible for describing messages rather than using it in conjunction with some other fields. At the same time, I don't think we need too many messages. [WeimingRe] I'm afraid there is a little contradiction here with your idea. To make more use of MsgType field is to have more messages, rights? My original idea was to use the field more fully. E.g., I would prefer to distinguish msgs such as config, query, and event msgs between the LFB config, event, and query from others, because I'm sure the msgs for LFB operations are quite different from others like FE coarse layer operations (as Robert proposed for FE LFB or I proposed for FE slave). This LFB difference is much bigger than the difference of association 'Setup' and 'Teardown'. My idea is If we have decided to use flags in msg body to describe the former difference, we have no reason not to use the msg body flag for the latter description, unless you can present other reasons that the 'setup' and 'teardown' MUST be two msgs other than that the Msg type field is enough. [/Weiming] Also, I think our main argument was around using FE/CE prefix for messages... Jamal, others & myself see that as limiting the scope of some messages such as Join, leave, etc to a certain extent. Does that make sense ? Hope this clarifies your confusion. [WeimingRe] Prefix itself makes no sense. The arguments behind it is I think for some messages, the FE->CE and the CE->FE are quite different, therefore we may need two messages for the purpose. For some other msgs, we can only currently define one direction operation, such as the query msg, config msg, capability msg (if we have). Therefore, I think our main difference is if we should use more messages or not and if we need to use more clear names for the msgs or not. My confusion with your idea is that, it seems sometimes you like using less msgs and more synthisizied msg names, but sometimes especially in some I think very tiny cases, you seem like using more msgs and verbose msg names. I just think a good protocol may need to be more uniform and consistent even by the appearance. [/Weiming] So the big question is how do we proceed forward ?? :-) We have couple of options... One is to use the compromise list that I sent out (as you can clearly see, Jamal agrees with having a Subscribe msg) -OR- We can go with the approach that I have described below using Msg type, Msg sub-type (4 bits each).... May be we can have some middle ground like 4 bits for Msg Type, 4 bits for Msg Sub-type such that...Msg Type = Association & Subtype = Setup or Teardown or Setup Resp. This might be easier to implement/parse and also use the bits more efficiently. Think about this and let us know ? I don't want us to keep spending so many cycles discussing Msg names when we all agree on what kinds of msgs/functionality we need... [WeimingRe] Actually I don't see any differences between the two schemes you proposed, I don't think it is me who have slowed down the progress in this point :) What I just want to know is the reasonable reason (other than making more use of MsgType) why you don't agree the following two schemes, instead to use more complex scheme: 1. to use flags in the msg body to describe the operation of 'setup/resp' 'teardown'. I think Jamal more inclide to this also. 2. to use flags or an FE attribute to describe subscribing/unsubscribing events. I think Jamal more means the subscribe function is important. [/WeimingRe] Here is the summary of what we need... Setup, setup resp, teardown Query, query resp Config, config resp Subscribe, subscribe resp, unsubscribe, unsubscribe resp State maintenance, state maintenance resp Event Notification Packet redirection Heart beat, HB resp (Its better to keep this separate from Event msg as Jamal suggested) We can arrange this as either Msg Types or Msg Type/subtype, let us know what you like ? Also, if adding FE/CE prefixes to some of these messages such as Setup, makes you happy, I am fine with that :) [WeimingRe] Not actually. If you'd like to have the Prefix to make me happy, pls add some for msgs like query, config:). I actually don't care if using FE setup or not, because I have seriously considered your idea that we may need to setup CE in the future. I want us to make fast progress on this and not get stuck on names. But pls take into account all the discussions that we have had so far on peering, msgs, etc. [WeimingRe] I think I have already given up pushing the prefix for the purpose of our fast progress. I'm not sure why you mention this here again. Do you think it is still the barrier? [/WeimingRe] Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 06:03:28 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 GAA12230 for ; Fri, 7 May 2004 06:03: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 1BM2AU-0006wU-10 for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 06:01:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47A1Mck026686 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 06:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM23M-0004n4-NU for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 05:54: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 FAA11635 for ; Fri, 7 May 2004 05:53: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 1BM23J-0005Jg-2M for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 05:53:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM22C-0004oA-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 05:52:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM21F-0004Lb-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 05:51:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1yX-00030M-7R; Fri, 07 May 2004 05: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 1BM1ke-0005RY-B3 for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 05:34: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 FAA10352 for ; Fri, 7 May 2004 05:34:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM1ka-0004aW-QU for forces-protocol@ietf.org; Fri, 07 May 2004 05:34:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM1jX-0004BK-00 for forces-protocol@ietf.org; Fri, 07 May 2004 05:33:33 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BM1ib-0003PW-00 for forces-protocol@ietf.org; Fri, 07 May 2004 05:32:33 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i479W3Mp131634; Fri, 7 May 2004 09:32: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 i479W2X6287420; Fri, 7 May 2004 11:32:02 +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 LAA55758; Fri, 7 May 2004 11:32:02 +0200 Message-ID: <409B5792.9080808@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] References: <409A5679.8050501@zurich.ibm.com> <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> In-Reply-To: <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------070906030903020402090807" 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, 07 May 2004 11:32:02 +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.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070906030903020402090807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate6.de.ibm.com id i479W3Mp131634 Content-Transfer-Encoding: quoted-printable Weiming, Yes, I think we have very much the same view on this issue. I called it=20 FE LFB because from a protocol point of view, setting FE attributes (and=20 other operations) will be done the same way as to any other (real) LFB.=20 Hormuzd pointed out that the model team could take over the definition=20 of this particular FE LFB. I think it should not. While the model team=20 can define the general structure of LFBs, we'll have to fill the FE LFB=20 with content, i.e., define the events and attributes of interest to run=20 the ForCES protocol. The list you have put up already seems very=20 reasonable to me. I hope that by defining such an FE LFB we can limit the amount of=20 message types that must be defined for the ForCES protocol. Regards, -Robert Weiming Wang wrote: > =20 > Hi Robert, and all, > =20 > I'm very glad that your idea of FE LFB may quite meet with my idea=20 > anyway. Actually I called it 'FE Slave' instead of FE LFB. I think=20 > both of us think of this entity because we have realized that many of=20 > the functions in FE are actually beyond the scope of LFBs defined by=20 > FE models. These functions can also be described by using notions such=20 > as attibutes, events, capabilites, and states(UP/Down). Because these=20 > notions here are mainly effective for whole FE (that is, take whoe FE=20 > (at a coarse layer) as a managed entity), in my scheme, we just call=20 > then FE attributes, FE events, and FE capabilities, which are=20 > discriminated from LFB attributes, LFB events, and LFB capabilities. > =20 > I'd like to show some of the contents to see if they meet your thoughts= : > For FE events, we may have: > .FE state events (FE Up/Down/Active/Inactive/Failover) > .FE heartbeat > .FE DoS alert > .FE capability change > .FE TML events > =20 > For FE capability, we may have > .Currently supported ForCES protocol version by the FE > .Currently supported ForCES FE model by the FE > .Some TML capability description > =20 > Fe FE attributes, via which we may able to do: > . To setup or negotiate a version of FE model or the ForCES protocol > . To setup many policies for the FE, for which FE model is not able to=20 > do (out of its scope), e.g., > - FE failover and restart policy (such as graceful restart or not) > - FE heartbeat policy (such as the intervals for the heartbeat, etc) > =20 > . FE events subscribe/unsubscribe (including to start or stop heartbeat= s) > . for TML management if needed. > =20 > Anyway, any management that is out of the scope of FE model can be put=20 > in the FE LFB/ FE slave entity. That is I think our idea, is it right? > =20 > Cheers, > Weiming > =20 > ----- Original Message ----- > > From: Robert Haas > To: forces-protocol@ietf.org > Sent: Thursday, May 06, 2004 11:15 PM > Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: > topic 3 & 4a] > > Maybe my last message on that topic went unnoticed, so I wanted to > again stress the possibility to create an FE LFB (call it meta > LFB, control LFB, etc) that can be configured, events can be > subscribed to, etc. The difference between the FE LFB and the > other "regular" LFBs is that no data packet traverses the FE LFB. > The purpose of the FE LFB is to facilitate the control of the FE: > > Examples: > > - FE UP and DOWN don't need to be special ForCES messages. > Instead, they can be events originated by the FE LFB. > - Configuring the interval timer for heartbeats messages can be > done using a Config message to the hearbeat interval attribute of > the FE LFB. > > The reason to introduce this LFB versus creating specific ForCES > messages is flexibility: at some point in time, if we need to > enhance the ForCES protocol, we don't necessarily need to change > the protocol itself. Instead, we can create a new version of the > FE LFB that supports new features. > > I'd like to have your comments on such an FE LFB. > > Regards, > -Robert > --=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 --------------070906030903020402090807 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,
Yes, I think we have very much the same view on this issue. I called it FE LFB because from a protocol point of view, setting FE attributes (and other operations) will be done the same way as to any other (real) LFB. Hormuzd pointed out that the model team could take over the definition of this particular FE LFB. I think it should not. While the model team can define the general structure of LFBs, we'll have to fill the FE LFB with content, i.e., define the events and attributes of interest to run the ForCES protocol. The list you have put up already seems very reasonable to me.

I hope that by defining such an FE LFB we can limit the amount of message types that must be defined for the ForCES protocol.

Regards,
-Robert

Weiming Wang wrote:
 
Hi Robert, and all,
 
I'm very glad that your idea of FE LFB may quite meet with my idea anyway. Actually I called it 'FE Slave' instead of FE LFB. I think both of us think of this entity because we have realized that many of the functions in FE are actually beyond the scope of LFBs defined by FE models. These functions can also be described by using notions such as attibutes, events, capabilites, and states(UP/Down). Because these notions here are mainly effective for whole FE (that is, take whoe FE (at a coarse layer) as a managed entity), in my scheme, we just call then FE attributes, FE events, and FE capabilities, which are discriminated from LFB attributes, LFB events, and LFB capabilities.
 
I'd like to show some of the contents to see if they meet your thoughts:
For FE events, we may have:
.FE state events (FE Up/Down/Active/Inactive/Failover)
.FE heartbeat
.FE DoS alert
.FE capability change
.FE TML events
 
For FE capability, we may have
.Currently supported ForCES protocol version by the FE
.Currently supported ForCES FE model by the FE
.Some TML capability description
 
Fe FE attributes, via which we may able to do:
. To setup or negotiate a version of FE model or the ForCES protocol
. To setup many policies for the FE, for which FE model is not able to do (out of its scope), e.g.,
  - FE failover and restart policy (such as graceful restart or not)
  - FE heartbeat policy (such as the intervals for the heartbeat, etc)
 
. FE events subscribe/unsubscribe (including to start or stop heartbeats)
. for TML management if needed.
 
Anyway, any management that is out of the scope of FE model can be put in the FE LFB/ FE slave entity. That is I think our idea, is it right?
 
Cheers,
Weiming
 
----- Original Message -----
Sent: Thursday, May 06, 2004 11:15 PM
Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a]

Maybe my last message on that topic went unnoticed, so I wanted to again stress the possibility to create an FE LFB (call it meta LFB, control LFB, etc) that can be configured, events can be subscribed to, etc. The difference between the FE LFB and the other "regular" LFBs is that no data packet traverses the FE LFB. The purpose of the FE LFB is to facilitate the control of the FE:

Examples:

- FE UP and DOWN don't need to be special ForCES messages. Instead, they can be events originated by the FE LFB.
- Configuring the interval timer for heartbeats messages can be done using a Config message to the hearbeat interval attribute of the FE LFB.

The reason to introduce this LFB versus creating specific ForCES messages is flexibility: at some point in time, if we need to enhance the ForCES protocol, we don't necessarily need to change the protocol itself. Instead, we can create a new version of the FE LFB that supports new features.

I'd like to have your comments on such an FE LFB.

Regards,
-Robert

-- 
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
--------------070906030903020402090807-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 11:13:03 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 LAA29949 for ; Fri, 7 May 2004 11:13: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 1BM6dm-0006O9-1E for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 10:47:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47ElsnG024558 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 10:47:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Ue-000300-PN for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 10: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 KAA26643 for ; Fri, 7 May 2004 10:38: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 1BM6Uc-0001hQ-EK for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:38:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6T1-00017m-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:36:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6R1-0000Ww-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:34:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5vt-0001ED-Fj; Fri, 07 May 2004 10:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM4R8-0002HG-E8 for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 08:26: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 IAA18132 for ; Fri, 7 May 2004 08:26: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 1BM4R7-0006MU-8z for forces-protocol@ietf.org; Fri, 07 May 2004 08:26:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM4Q8-0005xK-00 for forces-protocol@ietf.org; Fri, 07 May 2004 08:25: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 1BM4PG-0005Z0-00 for forces-protocol@ietf.org; Fri, 07 May 2004 08:24:46 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050705282944:9870 ; Fri, 7 May 2004 05:28:29 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang , Hormuzd M Cc: forces-protocol@ietf.org Organization: ZNYX Networks Message-Id: <1083932680.1036.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 05/07/2004 05:28:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 05:28:34 AM, Serialize complete at 05/07/2004 05:28:34 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] header: flags vs commands 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 May 2004 08:24: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 Just changed the subject to map the two conversations under the same subject header. On Thu, 2004-05-06 at 22:26, Khosravi, Hormuzd M wrote: [HK] For some cases in our case, such as 2-phase commit, I think it > makes sense to have flags only in the message body or the TLV that we > define for that msg rather than the msg header. But I don't want to be > too picky about this either. Let us know if you're fine with this > (having flags in msg body) ? > > BTW, we don't need to have 16 bits for Flags in the common header if we > don't need them. We can just do with 4-5 bits for example, if that is > sufficient. On Fri, 2004-05-07 at 01:19, Weiming Wang wrote: [Weiming]Jamal, I think we all have no doubt that to subscribe/unsubscribe > events is definitely necessary. The difference between Hormuzd and me is if we > need to have specific msgs to do this or not. My idea is it can be very easily > done by config msg, therefore we don't need a specific msg (according to Hormuzd > idea, 4 msgs, sub and resp, unsub and resp) to do this. In this way, we actually > treat the sub/unsub as an FE attribute, behind which is actually an event > sub/unsub table. My idea is we have just used a quite synthisized msg mode, why > should we spend so many msgs in this very tiny task then. Let me talk about something related first: My view is we need those flags in the header. It doesnt make sense to be protective of 12 bits (restricting flags to 4 bits). While i am against over zealous future-proof designs, i think at this stage of the game we cant afford to be extreme on the other end of the stick either. So my thoughts: 16 bit flags and 16 bit command. I dont see a big deal of using 20 more bits (come on, guys - some people are preaching XML, imagine the million of bits overhead per second there). Note i dont have a problem using the headers on the T part of things in the message body. However, i think those are very precious(not many bits) and we should use them cautiously. Now to the issue at hand of whether to use more commands or extend commands via flags. Like i said earlier, i am indifferent; however, i have used the second scheme and it worked well (and i know a lot of protocols using it) and for that reason i am biased towards it. Hormuzd, what is it that is attractive to have the use of commands instead of the flags extensions? Is it implementation experience, another protocol you are familiar with, or you just think it is cleaner. If cleaner, contrasting against the flag extension, why is it better? I dont think we should stall on this. so lets resolve this and move on. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 11:15: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 LAA00120 for ; Fri, 7 May 2004 11:15: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 1BM6eM-0006Zg-3y for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 10:48:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EmUHO025267 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 10:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Vn-0003CR-Cd for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:39: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 KAA26761 for ; Fri, 7 May 2004 10:39: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 1BM6Vl-0002Hd-5y for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:39:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6U9-0001d9-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:37:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6SC-0000gB-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:35:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5w0-0001Ki-3d; Fri, 07 May 2004 10:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM4el-0000TV-AQ for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 08:40: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 IAA18698 for ; Fri, 7 May 2004 08:40: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 1BM4ej-0004M7-UW for forces-protocol@ietf.org; Fri, 07 May 2004 08:40:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM4dy-0003xM-00 for forces-protocol@ietf.org; Fri, 07 May 2004 08:39: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 1BM4d6-0003YG-00 for forces-protocol@ietf.org; Fri, 07 May 2004 08:39: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 2004050705425069:9878 ; Fri, 7 May 2004 05:42:50 -0700 Subject: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <409B5792.9080808@zurich.ibm.com> References: <409A5679.8050501@zurich.ibm.com> <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> <409B5792.9080808@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1083933541.1036.42.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 05/07/2004 05:42:51 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 05:42:52 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 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: 07 May 2004 08:39: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=1.1 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Um9iZXJ0L1dlaW1pbmcsDQoNCkkgYXBvbG9naXplIGZvciBhY3R1YWxseSBub3Qgc2F5aW5nIGFu eXRoaW5nIG9uIHRoaXMgc3ViamVjdC4NCkluaXRpYWxseSBpIHdhcyBjb25mdXNlZCA7LT4NCg0K SSB0aGluayB0aGUgInRoaW5nIiB5b3UgYXJlIGRlc2NyaWJpbmcgYWRkcyB2YWx1ZSwgdGhlIHBy b2JsZW0gaXMNCndoZXRoZXIgaXQgc2hvdWxkIGJlIGNhbGxlZCBhbiBMRkIsIExGQi13YW5uYWJl LCBGRS1tYW5hZ2VyLiBUbyBiZQ0KaG9uZXN0IGl0IGlzIGFsbW9zdCBsaWtlIGFuIGltcGxlbWVu dGF0aW9uIGxldmVsIGFyY2hpdGVjdHVyZSBkZXRhaWwuIEkNCmFsc28gZG9udCBzZWUgaG93IHlv dSBjYW4gcmVkdWNlIHRoZSBudW1iZXIgb2YgbWVzc2FnZSB0eXBlcy4gRm9yDQpleGFtcGxlLCBp dCBzaG91bGQgYmUgcG9zc2libGUgdG8gdGFyZ2V0IGhlYXJiZWF0cyB0byBhbnkgTEZCIG5vdCBq dXN0DQp0byB0aGlzICJ0aGluZyIuDQpBcmUgeW91IHN1Z2dlc3RpbmcgaXQgaXMgYSAibXV4ZXIi IG9mIGFsbCBoZWFydGJlYXRzIGV0Yz8gDQoNCkkgYW0gbm90IGFnYWluc3QgaXQsIGkgdGhpbmsg aXQgd2lsbCBlYXNlIHRoZSBpbXBsZW1lbnRhdGlvbnM7IGkgYW0ganVzdA0KdHJ5aW5nIHRvIGZv cm11bGF0ZSBpdHMgbmVlZCBpbiBteSBoZWFkLg0KDQpjaGVlcnMsDQpqYW1hbA0KDQpPbiBGcmks IDIwMDQtMDUtMDcgYXQgMDU6MzIsIFJvYmVydCBIYWFzIHdyb3RlOg0KPiBXZWltaW5nLA0KPiBZ ZXMsIEkgdGhpbmsgd2UgaGF2ZSB2ZXJ5IG11Y2ggdGhlIHNhbWUgdmlldyBvbiB0aGlzIGlzc3Vl LiBJIGNhbGxlZA0KPiBpdCBGRSBMRkIgYmVjYXVzZSBmcm9tIGEgcHJvdG9jb2wgcG9pbnQgb2Yg dmlldywgc2V0dGluZyBGRSBhdHRyaWJ1dGVzDQo+IChhbmQgb3RoZXIgb3BlcmF0aW9ucykgd2ls bCBiZSBkb25lIHRoZSBzYW1lIHdheSBhcyB0byBhbnkgb3RoZXINCj4gKHJlYWwpIExGQi4gSG9y bXV6ZCBwb2ludGVkIG91dCB0aGF0IHRoZSBtb2RlbCB0ZWFtIGNvdWxkIHRha2Ugb3Zlcg0KPiB0 aGUgZGVmaW5pdGlvbiBvZiB0aGlzIHBhcnRpY3VsYXIgRkUgTEZCLiBJIHRoaW5rIGl0IHNob3Vs ZCBub3QuIFdoaWxlDQo+IHRoZSBtb2RlbCB0ZWFtIGNhbiBkZWZpbmUgdGhlIGdlbmVyYWwgc3Ry dWN0dXJlIG9mIExGQnMsIHdlJ2xsIGhhdmUgdG8NCj4gZmlsbCB0aGUgRkUgTEZCIHdpdGggY29u dGVudCwgaS5lLiwgZGVmaW5lIHRoZSBldmVudHMgYW5kIGF0dHJpYnV0ZXMNCj4gb2YgaW50ZXJl c3QgdG8gcnVuIHRoZSBGb3JDRVMgcHJvdG9jb2wuIFRoZSBsaXN0IHlvdSBoYXZlIHB1dCB1cA0K PiBhbHJlYWR5IHNlZW1zIHZlcnkgcmVhc29uYWJsZSB0byBtZS4NCj4gDQo+IEkgaG9wZSB0aGF0 IGJ5IGRlZmluaW5nIHN1Y2ggYW4gRkUgTEZCIHdlIGNhbiBsaW1pdCB0aGUgYW1vdW50IG9mDQo+ IG1lc3NhZ2UgdHlwZXMgdGhhdCBtdXN0IGJlIGRlZmluZWQgZm9yIHRoZSBGb3JDRVMgcHJvdG9j b2wuDQo+IA0KPiBSZWdhcmRzLA0KPiAtUm9iZXJ0DQo+IA0KPiBXZWltaW5nIFdhbmcgd3JvdGU6 DQo+ID4gIA0KPiA+IEhpIFJvYmVydCwgYW5kIGFsbCwNCj4gPiAgDQo+ID4gSSdtIHZlcnkgZ2xh ZCB0aGF0IHlvdXIgaWRlYSBvZiBGRSBMRkIgbWF5IHF1aXRlIG1lZXQgd2l0aCBteSBpZGVhDQo+ ID4gYW55d2F5LiBBY3R1YWxseSBJIGNhbGxlZCBpdCAnRkUgU2xhdmUnIGluc3RlYWQgb2YgRkUg TEZCLiBJIHRoaW5rDQo+ID4gYm90aCBvZiB1cyB0aGluayBvZiB0aGlzIGVudGl0eSBiZWNhdXNl IHdlIGhhdmUgcmVhbGl6ZWQgdGhhdCBtYW55DQo+ID4gb2YgdGhlIGZ1bmN0aW9ucyBpbiBGRSBh cmUgYWN0dWFsbHkgYmV5b25kIHRoZSBzY29wZSBvZiBMRkJzIGRlZmluZWQNCj4gPiBieSBGRSBt b2RlbHMuIFRoZXNlIGZ1bmN0aW9ucyBjYW4gYWxzbyBiZSBkZXNjcmliZWQgYnkgdXNpbmcgbm90 aW9ucw0KPiA+IHN1Y2ggYXMgYXR0aWJ1dGVzLCBldmVudHMsIGNhcGFiaWxpdGVzLCBhbmQgc3Rh dGVzKFVQL0Rvd24pLiBCZWNhdXNlDQo+ID4gdGhlc2Ugbm90aW9ucyBoZXJlIGFyZSBtYWlubHkg ZWZmZWN0aXZlIGZvciB3aG9sZSBGRSAodGhhdCBpcywgdGFrZQ0KPiA+IHdob2UgRkUgKGF0IGEg Y29hcnNlIGxheWVyKSBhcyBhIG1hbmFnZWQgZW50aXR5KSwgaW4gbXkgc2NoZW1lLCB3ZQ0KPiA+ IGp1c3QgY2FsbCB0aGVuIEZFIGF0dHJpYnV0ZXMsIEZFIGV2ZW50cywgYW5kIEZFIGNhcGFiaWxp dGllcywgd2hpY2gNCj4gPiBhcmUgZGlzY3JpbWluYXRlZCBmcm9tIExGQiBhdHRyaWJ1dGVzLCBM RkIgZXZlbnRzLCBhbmQgTEZCDQo+ID4gY2FwYWJpbGl0aWVzLg0KPiA+ICANCj4gPiBJJ2QgbGlr ZSB0byBzaG93IHNvbWUgb2YgdGhlIGNvbnRlbnRzIHRvIHNlZSBpZiB0aGV5IG1lZXQgeW91cg0K PiA+IHRob3VnaHRzOg0KPiA+IEZvciBGRSBldmVudHMsIHdlIG1heSBoYXZlOg0KPiA+IC5GRSBz dGF0ZSBldmVudHMgKEZFIFVwL0Rvd24vQWN0aXZlL0luYWN0aXZlL0ZhaWxvdmVyKQ0KPiA+IC5G RSBoZWFydGJlYXQNCj4gPiAuRkUgRG9TIGFsZXJ0DQo+ID4gLkZFIGNhcGFiaWxpdHkgY2hhbmdl DQo+ID4gLkZFIFRNTCBldmVudHMNCj4gPiAgDQo+ID4gRm9yIEZFIGNhcGFiaWxpdHksIHdlIG1h eSBoYXZlDQo+ID4gLkN1cnJlbnRseSBzdXBwb3J0ZWQgRm9yQ0VTIHByb3RvY29sIHZlcnNpb24g YnkgdGhlIEZFDQo+ID4gLkN1cnJlbnRseSBzdXBwb3J0ZWQgRm9yQ0VTIEZFIG1vZGVsIGJ5IHRo ZSBGRQ0KPiA+IC5Tb21lIFRNTCBjYXBhYmlsaXR5IGRlc2NyaXB0aW9uDQo+ID4gIA0KPiA+IEZl IEZFIGF0dHJpYnV0ZXMsIHZpYSB3aGljaCB3ZSBtYXkgYWJsZSB0byBkbzoNCj4gPiAuIFRvIHNl dHVwIG9yIG5lZ290aWF0ZSBhIHZlcnNpb24gb2YgRkUgbW9kZWwgb3IgdGhlIEZvckNFUyBwcm90 b2NvbA0KPiA+IC4gVG8gc2V0dXAgbWFueSBwb2xpY2llcyBmb3IgdGhlIEZFLCBmb3Igd2hpY2gg RkUgbW9kZWwgaXMgbm90IGFibGUNCj4gPiB0byBkbyAob3V0IG9mIGl0cyBzY29wZSksIGUuZy4s DQo+ID4gICAtIEZFIGZhaWxvdmVyIGFuZCByZXN0YXJ0IHBvbGljeSAoc3VjaCBhcyBncmFjZWZ1 bCByZXN0YXJ0IG9yIG5vdCkNCj4gPiAgIC0gRkUgaGVhcnRiZWF0IHBvbGljeSAoc3VjaCBhcyB0 aGUgaW50ZXJ2YWxzIGZvciB0aGUgaGVhcnRiZWF0LA0KPiA+IGV0YykNCj4gPiAgDQo+ID4gLiBG RSBldmVudHMgc3Vic2NyaWJlL3Vuc3Vic2NyaWJlIChpbmNsdWRpbmcgdG8gc3RhcnQgb3Igc3Rv cA0KPiA+IGhlYXJ0YmVhdHMpDQo+ID4gLiBmb3IgVE1MIG1hbmFnZW1lbnQgaWYgbmVlZGVkLg0K PiA+ICANCj4gPiBBbnl3YXksIGFueSBtYW5hZ2VtZW50IHRoYXQgaXMgb3V0IG9mIHRoZSBzY29w ZSBvZiBGRSBtb2RlbCBjYW4gYmUNCj4gPiBwdXQgaW4gdGhlIEZFIExGQi8gRkUgc2xhdmUgZW50 aXR5LiBUaGF0IGlzIEkgdGhpbmsgb3VyIGlkZWEsIGlzIGl0DQo+ID4gcmlnaHQ/DQo+ID4gIA0K PiA+IENoZWVycywNCj4gPiBXZWltaW5nDQo+ID4gIA0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQo+ID4gICAgICAgICBGcm9tOiBSb2JlcnQgSGFhcw0KPiA+ICAgICAgICAgVG86 IGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KPiA+ICAgICAgICAgU2VudDogVGh1cnNkYXksIE1h eSAwNiwgMjAwNCAxMToxNSBQTQ0KPiA+ICAgICAgICAgU3ViamVjdDogW0Z3ZDogUmU6IFtGb3Jj ZXMtcHJvdG9jb2xdIFN1bW1hcnkgOiBQcm90b2NvbA0KPiA+ICAgICAgICAgTWVzc2FnZXM6IHRv cGljIDMgJiA0YV0NCj4gPiAgICAgICAgIA0KPiA+ICAgICAgICAgTWF5YmUgbXkgbGFzdCBtZXNz YWdlIG9uIHRoYXQgdG9waWMgd2VudCB1bm5vdGljZWQsIHNvIEkNCj4gPiAgICAgICAgIHdhbnRl ZCB0byBhZ2FpbiBzdHJlc3MgdGhlIHBvc3NpYmlsaXR5IHRvIGNyZWF0ZSBhbiBGRSBMRkINCj4g PiAgICAgICAgIChjYWxsIGl0IG1ldGEgTEZCLCBjb250cm9sIExGQiwgZXRjKSB0aGF0IGNhbiBi ZSBjb25maWd1cmVkLA0KPiA+ICAgICAgICAgZXZlbnRzIGNhbiBiZSBzdWJzY3JpYmVkIHRvLCBl dGMuIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQo+ID4gICAgICAgICBGRSBMRkIgYW5kIHRo ZSBvdGhlciAicmVndWxhciIgTEZCcyBpcyB0aGF0IG5vIGRhdGEgcGFja2V0DQo+ID4gICAgICAg ICB0cmF2ZXJzZXMgdGhlIEZFIExGQi4gVGhlIHB1cnBvc2Ugb2YgdGhlIEZFIExGQiBpcyB0bw0K PiA+ICAgICAgICAgZmFjaWxpdGF0ZSB0aGUgY29udHJvbCBvZiB0aGUgRkU6DQo+ID4gICAgICAg ICANCj4gPiAgICAgICAgIEV4YW1wbGVzOg0KPiA+ICAgICAgICAgDQo+ID4gICAgICAgICAtIEZF IFVQIGFuZCBET1dOIGRvbid0IG5lZWQgdG8gYmUgc3BlY2lhbCBGb3JDRVMgbWVzc2FnZXMuDQo+ ID4gICAgICAgICBJbnN0ZWFkLCB0aGV5IGNhbiBiZSBldmVudHMgb3JpZ2luYXRlZCBieSB0aGUg RkUgTEZCLg0KPiA+ICAgICAgICAgLSBDb25maWd1cmluZyB0aGUgaW50ZXJ2YWwgdGltZXIgZm9y IGhlYXJ0YmVhdHMgbWVzc2FnZXMgY2FuDQo+ID4gICAgICAgICBiZSBkb25lIHVzaW5nIGEgQ29u ZmlnIG1lc3NhZ2UgdG8gdGhlIGhlYXJiZWF0IGludGVydmFsDQo+ID4gICAgICAgICBhdHRyaWJ1 dGUgb2YgdGhlIEZFIExGQi4NCj4gPiAgICAgICAgIA0KPiA+ICAgICAgICAgVGhlIHJlYXNvbiB0 byBpbnRyb2R1Y2UgdGhpcyBMRkIgdmVyc3VzIGNyZWF0aW5nIHNwZWNpZmljDQo+ID4gICAgICAg ICBGb3JDRVMgbWVzc2FnZXMgaXMgZmxleGliaWxpdHk6IGF0IHNvbWUgcG9pbnQgaW4gdGltZSwg aWYgd2UNCj4gPiAgICAgICAgIG5lZWQgdG8gZW5oYW5jZSB0aGUgRm9yQ0VTIHByb3RvY29sLCB3 ZSBkb24ndCBuZWNlc3NhcmlseQ0KPiA+ICAgICAgICAgbmVlZCB0byBjaGFuZ2UgdGhlIHByb3Rv Y29sIGl0c2VsZi4gSW5zdGVhZCwgd2UgY2FuIGNyZWF0ZSBhDQo+ID4gICAgICAgICBuZXcgdmVy c2lvbiBvZiB0aGUgRkUgTEZCIHRoYXQgc3VwcG9ydHMgbmV3IGZlYXR1cmVzLg0KPiA+ICAgICAg ICAgDQo+ID4gICAgICAgICBJJ2QgbGlrZSB0byBoYXZlIHlvdXIgY29tbWVudHMgb24gc3VjaCBh biBGRSBMRkIuDQo+ID4gICAgICAgICANCj4gPiAgICAgICAgIFJlZ2FyZHMsDQo+ID4gICAgICAg ICAtUm9iZXJ0DQo+ID4gICAgICAgICANCj4gDQo+IA0KPiAtLSANCj4gUm9iZXJ0IEhhYXMNCj4g SUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+IFPkdW1lcnN0cmFzc2UgNA0KPiBDSC04 ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCAr NDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoNCg== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 11:17:52 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 LAA00372 for ; Fri, 7 May 2004 11:17: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 1BM6gT-0007Bt-En for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 10:50:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EofcB027637 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 10:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Zg-0004Q8-CQ for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:43: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 KAA27315 for ; Fri, 7 May 2004 10:43:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6Zd-0004Sc-UV for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:43:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6YG-0003oy-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:42:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6Wh-0002o4-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:40:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5xL-0002lg-Bc; Fri, 07 May 2004 10:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM55o-0000Im-EP for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 09:08: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 JAA20418 for ; Fri, 7 May 2004 09:08: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 1BM55m-000138-Kw for forces-protocol@ietf.org; Fri, 07 May 2004 09:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM54n-0000bq-00 for forces-protocol@ietf.org; Fri, 07 May 2004 09:07:42 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BM53K-0007ZT-00 for forces-protocol@ietf.org; Fri, 07 May 2004 09:06:10 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 7 May 2004 21:18:35 +0800 Message-ID: <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , "Jamal Hadi Salim" , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C43475.E7B6EE80" 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, 7 May 2004 20:57: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=1.8 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_002F_01C43475.E7B6EE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgcm9iZXJ0LCBhbmQgSmFtYWwgYXMgd2VsbCwNCg0KDQogICAgICBXZWltaW5nLA0KICAgICAg SSB0aGluayB0aGUgYXBwcm9hY2ggb2YgICdQbHMgbGV0IG1lIGtub3cgd2hlbiB5b3UgZW5jb3Vu dGVyIGRpZmZpY3VsdGllcywgb3RoZXJ3aXNlIHBscyBkb24ndCBib3RoZXInIGlzIGluZGVlZCB1 c2VmdWwuIExldCBtZSBlbGFib3JhdGUgYSBiaXQgb24gdGhpcy4gU29ycnkgZm9yIHRoZSByYXRo ZXIgbG9uZyBtZXNzYWdlLiBJJ2xsIGRldm90ZSBhbm90aGVyIG5vdGUgdG8gd2luZG93aW5nLg0K DQogICAgICAgQmF0Y2hpbmcgaXMgdXNlZCB0byBncm91cCBjb21tYW5kcyB0b2dldGhlci4gRWFj aCBjb21tYW5kIHBvc3NpYmx5IGhhcyBpdHMgb3duIHNlcXVlbmNlIG51bWJlciAob3IgdHJhbnNh Y3Rpb24gbnVtYmVyKSwgDQogICAgICBbV2VpbWluZ11ObyBwcm9ibGVtIHdpdGggdGhlIG5hbWUg c2VxdWVuY2UgbnVtYmVyLCBJIGFsc28gbGlrZSBpdC4NCiAgICAgIG9yIHRoZSBncm91cCBoYXMg aXRzIG93biBudW1iZXIgd2l0aCBzdWJudW1iZXJzIGZvciBlYWNoIG1lc3NhZ2UgKHRoaXMgcmVt YWlucyB0byBiZSBkZWNpZGVkLikgVGhlIG1haW4gdXNlIG9mIGJhdGNoaW5nIGlzIHRvIHBlcmZv cm0gYXRvbWljaXR5OiANCiAgICAgIFtXZWltaW5nXUkgYWdyZWUgdGhpcywgdGhvdWdoIEkgd2Fz IGEgbGl0dGxlIGNvbmZ1c2VkIGJlZm9yZSB3aXRoIHRoZSBub3Rpb25zICdiYXRjaGluZywgYXRv bWljaXR5LCAyLXBoYXNlIGNvbW1pdCwgYWxsIG9yIG5vdGhpbmcnLiBDYW4gd2UgdW5kZXJzdGFu ZCB0aGF0IHRoZXkgYXJlIGFsbCB0YXJnZXRpbmcgdGhlIHNhbWUgdGhpbmc6IGFsbCBvciBub3Ro aW5nPyBPciB3ZSBoYXZlIG90aGVyIHB1cnBvc2UgZm9yIGJhdGNoaW5nIHN1Y2ggYXMganVzdCBm b3IgcGFja2V0aXppbmc/DQoNCiAgVGhlIHB1cnBvc2Ugb2YgYmF0Y2hpbmcsIGJ1bmRsaW5nLCBn cm91cGluZywgYXRvbWljaXR5LCAyLXBoYXNlLWNvbW1pdCwgaXMgZm9yIHRoZSBzYW1lIHB1cnBv c2U6IGV4ZWN1dGUgYSBzZXJpZSBvZiBjb21tYW5kcyBpbiBzdWNoIGEgd2F5IHRoYXQgdGhlaXIg ZWZmZWN0IGlzIHRoZSBzYW1lIGFzIGlmIGl0IGhhZCBiZWVuIGEgc2luZ2xlIGNvbW1hbmQuDQoN CiAgSWYgdGhlIG51bWJlciBvZiBjb21tYW5kcy9UTFZzIHRvIGluY2x1ZGUgb24gYSBGb3JDRVMg TXNnIGV4Y2VlZHMgdGhlIG1heGltdW0gbGVuZ3RoIG9mIHRoZSBGb3JDRVMgbWVzc2FnZSwgdGhl biBJIHdvdWxkIHNpbXBseSB1c2UgYW5vdGhlciBGb3JDRVMgTXNnLCBhbmQgb25seSBzZXQgYmF0 Y2hpbmcgT04gaWYgSSB3YW50ZWQgYXRvbWljaXR5IGFjcm9zcyB0aGUgY29tbWFuZHMgaW4gdGhl IHR3byBzZXBhcmF0ZSBGb3JDRVMgTXNncy4gRG9lcyB0aGF0IHNvdW5kIHJlYXNvbmFibGUgPw0K DQoNCg0KICAgICAgYWxsIGNvbW1hbmRzIGluIHRoZSBncm91cCB3aWxsIGJlIHBlcmZvcm1lZCBh dCB0aGUgc2FtZSB0aW1lIG9yIG5vbmUgd2lsbCBiZSBwZXJmb3JtZWQuIFRoaXMgaXMgd2hlcmUg Mi1waGFzZSBjb21taXQga2lja3MgaW46IGFsbCBjb21tYW5kcyBhcmUgZmlyc3QgdHJhbnNtaXR0 ZWQgdG8gdGhlIEZFLCBhbmQgdW5sZXNzIHRoZSBGRSByZXBvcnRzIGFuIGVycm9yLCB0aGUgQ0Ug Y2FuIHVsdGltYXRlbHkgaXNzdWUgYSBjb21taXQgY29tbWFuZCBzbyBhbGwgdGhlc2UgY29tbWFu ZHMgYXJlIGV4ZWN1dGVkIGluIGFuIGF0b21pYyBvcGVyYXRpb24gYXQgdGhlIEZFLg0KICAgICAg W1dlaW1pbmddWWVzLg0KICAgICAgV2UgaW52ZXN0aWdhdGVkIHRoZSBpZGVhIG9mIHBhY2tpbmcg bXVsdGlwbGUgY29tbWFuZHMgaW4gdGhlIHNhbWUgRm9yQ0VTIG1lc3NhZ2UgKGl0IHNhdmVzIHF1 aXRlIHNvbWUgaGVhZGVycyBhbmQgdGhlIGFzc29jaWF0ZWQgcHJvY2Vzc2luZw0KICAgICAgW1dl aW1pbmddSGVyZSwgSSB0aGluayB3ZSBuZWVkIHRvIGV2YWx1YXRlIGlmIHRoZSBoZWFkZXJzIGFy ZSB3b3J0aCB0aGVyZSBvciBub3QuIE15IG9yaWdpbmFsIGlkZWEgd2FzIGl0IHdhcyBub3Qgd29y dGggaXQgKGR1cmluZyBHUk1QIHRpbWUpLCBidXQgbm93IEkgY2hhbmdlIHNvbWUuIEp1c3QgY2hl Y2sgdGhlIHBvc3NpYmxlIGhlYWRlciBmaWVsZHMsIHdlIG1heSBmaW5kIHRoYXQgbW9zdCBvZiB0 aGVtIGFyZSB3b3J0aCB0aGVyZSwgYW5kIHRoZSByZXdhcmQgaXMgZ3JlYXQsIGFsbG93aW5nIHBl ciBtc2cgQUNLLCBhbmQgd2l0aCBtdWNoIGxlc3MgY29tcGxleGl0eSBmb3IgcHJvdG9jb2wgc3Rh dGUgdHJhY2UuDQoNCiAgICAgICkuIEFzIGEgbW90aXZhdGlvbiwgdGhpbmsgb2YgYWRkaW5nIDEw MCcwMDAgcm91dGVzIG9uIGFuIEZFOiBzaG91bGQgd2UgdXNlIDEwMCcwMDAgRm9yQ0VTIG1lc3Nh Z2VzLCBvciBvbmx5IDEwMDAgKHNheSAxNSBieXRlcyBwZXIgcm91dGUgdXBkYXRlIGNvbW1hbmQg dG8gYmUgZ2VuZXJvdXMsIHdpdGggYSAxNTAwIGJ5dGVzIE1UVSBzaXplLCBvciBldmVuIGxlc3Mg aWYgd2UgaGF2ZSBKdW1ibyBmcmFtZXMpID8gDQoNCiAgICAgIE5vdGUgdGhhdCBoYXZpbmcgbWFu eSBjb21tYW5kcyBpbiB0aGUgc2FtZSBGb3JDRVMgbWVzc2FnZSByZXN1bHRzIGluIHNsaWdobHR5 IG1vcmUgY29tcGxleCBlcnJvci9hY2sgcmVwb3J0aW5nLiBUYWtlIHRoaXMgZXhhbXBsZTogdHdv IGNvbW1hbmRzIEEgYW5kIEIgaW4gdGhlIHNhbWUgRm9yQ0VTIG1lc3NhZ2UgaXNzdWVkIGJ5IGEg Q0UuIEZFIGV4ZWN1dGVzIGJvdGggb2YgIHRoZW0sIGJ1dCBvbmx5IEEgc3VjY2VlZHMuIEl0IHNo b3VsZCByZXBvcnQgdGhpcyBzb21laG93IHRvIHRoZSBDRS4gQSBwb3NzaWJsZSBzb2x1dGlvbiBp cyB0byByZXR1cm4gdGhlIG9yaWdpbmFsIG1lc3NhZ2UgdHJpbW1lZCBkb3duIHN1Y2ggdGhhdCBp dCBjb250YWlucyBleGFjdGx5IHR3byByZXNwb25zZXMsIGEgcG9zaXRpdmUgYW5kIGEgbmVnYXRp dmUgb25lLg0KICAgICAgW1dlaW1pbmddWWVzLCBJIHRoaW5rIHlvdSBhcmUgYWxzbyB0cnlpbmcg dG8gc2VlIHdoaWNoIGlzIGJldHRlciBhbW9uZyB0aGUgZm9sbG93aW5nIHR3byBwb3NzaWJsZSBi YXRjaGluZyBzY2hlbWVzOg0KICAgICAgMS4gQmF0Y2hlZCBtc2dzIGluIG9uZSBwYWNrZXQgb3Ig ZXZlbiBrZWVwaW5nIHRoZSBtc2dzIHNlcGFyYXRlbHkgYXMgaXRzIG9yaWdpbiwgd2hpbGUgd2l0 aCBzb21lIGZsYWdzIHN1Y2ggYXMgQXRvbWljaXR5IGFuZC9vciBEb25lIEZsYWcgdG8gaW5kaWNh dGUgdGhlIGJlZ2luIGFuZCB0aGUgZW5kLg0KICAgICAgMi4gTWFueSBjb21tYW5kcyBpbiBvbmUg bXNnIGFzIHlvdSBtZW50aW9uZWQgYWJvdmUuIA0KICAgICAgSSBhIGxpdHRsZSBtb3JlIGluY2xp bmUgdG8gIzEgc2NoZW1lLCBhcyB0aGUgcmVhc29uIEkgbWVudGlvbmVkIGFib3ZlLiBCdXQgdGhl cmUgaXMgYSByZW1haW5lZCBpc3N1ZSBmb3Igc3VjY2Vzc2Z1bCBhdG9taWNpdHksIHRoYXQgaXMs IGl0IGRvZXMgbm90IHN1cHBvcnQgbXVsdGlwdWwgdHJhbnNhY3Rpb25zIGlmIHdlIHVzZSBkaWZm ZXJlbnQgc2VxdWVjZSBudW1iZXIgZm9yIGRpZmZlcmVudCBtc2dzIGluIGEgYmF0Y2gsIGFuZCBp ZiB3ZSB1c2Ugc2FtZSBzZXF1ZW5jZSBudW1iZXIgZm9yIGFsbCB0aGUgbXNncywgdGhlbiBpdCBt YXkgcmVzdWx0IGluIGFtYmlndWl0eSBmb3IgbXNnIG1lYW5pbmcgYW5kIGhhcmQgZm9yIEFDSy4g VGhlcmVmb3JlLCBJIHRyeSB0byBwcm9wb3NlIHRvIHVzZSBhIHN1YiBtc2cgbnVtYmVyIHRvIHNl ZSBpZiBpdCBpcyBmZWFzaWJsZSBmb3IgdGhlIHB1cnBvc2UuIFBscyBsZXQgbWUgdHJ5IHRvIHN1 bW1hcml6ZSBzdGggd2UndiBhbHJlYWR5IGdvdCAoTmV0bGluazI/KSBhbG9uZyB3aXRoIHRoZSBi YXRjaCBtc2cgIyB0aG91Z2h0IGFzIGZvbGxvd3M6DQoNCiAgICAgIEJhdGNoaW5nIG1zZyBhczoN Cg0KICAgICAgTXNnMTpNc2cyOi4uLk1zZ04gKGVpdGhlciBvbmUgcGFja2V0IG9yIHNlcGFyYXRl ZCBwYWNrZXRzKQ0KDQogICAgICBJbiBoZWFkZXJzIG9mIGFsbCB0aGUgbXNncywNCg0KICAgICAg U2VxdWVuY2UgTnVtYmVyczogYWxsIHRoZSBzYW1lLCB0aGF0IG1lYW5zIGEgYmF0Y2ggaXMgdHJl YXRlZCBhcyBhIHRyYW5zYWN0aW9uLg0KICAgICAgQVRNIGZsYWc6IG1hcmsgdGhlIGVuZCBvZiBi YXRjaGluZyAoZS5nLiwwIGZvciBNc2dOLCBhbmQgYWxzbyBhIHNpZ25hbCB0byBleGN1dGUgdGhl IGJhdGNoLCAxIGZvciBvdGhlcnMsIGFuZCBhbHNvIGFzIGEgc2lnbmFsIHRvIHJlc2VydmUgaXQp DQogICAgICBBQ0sgZmxhZzogaW5kaWNhdGUgaWYgdGhpcyBtc2cgbmVlZCBhbiBBQ0sNCiAgICAg IEJhdGNoTXNnTnVtOiBtYXJrIHRoZSBiYXRlaGVkIG1zZyBzZXF1ZW5jZSBudW1iZXIsIDAgZm9y IE1zZzEsIC4uLiAoTi0xKSBmb3IgTXNnTi4gQW55IEFDSyBzaG91bGQgaW5jbHVkZSBCYXRjaE1z Z051bSBhcyB3ZWxsIGFzIG90aGVycy4NCg0KICAgICAgQW55IG9mIHRoZSBNc2cgaW4gdGhlIGJh dGNoIHN0aWxsIGNhbiBiZSBmcmFnbWVudGVkIGlmIGl0IGV4Y2VlZHMgdGhlIE1UVSwgYSBGUkcg ZmxhZyBpcyB1c2VkIHRvIHRyZWF0IGl0LCB3aXRoIHRoZSB0aGlua2luZyB0aGF0IHRoZSBwYWNr ZXRzIHdpbGwgbm90IGJlIHJlb3JkZXJlZC4NCiAgICAgIFJvYjogY2FuIHlvdSB0cnkgdG8gcHJl c2VudCBhIHN1bW1hcnkgcmVnYXJkaW5nIHRoZSAjMiBzY2hlbWUsIHNvIHRoYXQgd2UgY2FuIGNh cmVmdWxseSBjb21wYXJlIGFuZCBldmFsdWF0ZSBpdD8NCiAgTGV0IG1lIHRyeToNCg0KICBPbmUg c2luZ2xlIEZvckNFUyBNc2csIHdpdGggTiBUTFZzIChUTFZzIGFyZSBiYXNpY2FsbHkgdGhlIGNv bW1hbmQgZGVzdGluZWQgdG8gTEZCcykuIElmIHRoZSBiYXRjaCBzcGFucyBtb3JlIHRoYW4gb25l IHNpbmdsZSBGb3JDRVMgTXNnIHRoZSBBVE0gZmxhZyB3aWxsIGhhdmUgdG8gYmUgc2V0IGFjY29y ZGluZ2x5LiBUaGUgcmVzdWx0aW5nIEFDSyBNc2cgY2FuIGJlIGZvciB0aGUgZW50aXJlIEZvckNF UyBNc2cgKHVzaW5nIHRoZSBzZXF1ZW5jZSBudW1iZXIpLiBPciB0aGUgQUNLIE1zZyBjYW4gY29u dGFpbiB0aGUgc2FtZSBUTFZzIGFzIHRoZSBvcmlnaW5hbCBNZXNzYWdlLCB3aXRoIGEgZmxhZyBp biBlYWNoIFRMViB0byBpbmRpY2F0ZSBpZiB0aGF0IHBhcnRpY3VsYXIgVExWIHN1Y2NlZWRlZCBv ciBub3QuIElmIHRoZSBBdG9taWMgZmxhZyB3YXMgc2V0IHdpdGggdGhlIDItcGhhc2UgY29tbWl0 LCB0aGVuIGFsbCBUTFZzIHN1Y2NlZWQgb3Igbm9uZS4NCiAgW1dlaW1pbmddIEkganVzdCB0cnkg dG8gdGhpbmsgb2YgaXQgaW50byBhIGxpdHRsZSBtb3JlIGRldGFpbC4gU28sIHdpbGwgdGhlIFRM VnMgdGhlbXNlbHZlcyBpbmNsdWRlIHRoaW5ncyBhcyBBQ0sgZmxhZywgYW5kIGEgbnVtYmVyIHRv IGluZGljYXRlIHRoZSBwbGFjZSBvZiB0aGUgVExWIGluIHRoZSB3aG9sZSBiaWcgbXNnPyAgDQoN CiAgVGhlIHNlcXVlbmNlIG51bWJlciBtdXN0IGJlIGluY3JlbWVudGVkIGZvciBlYWNoIG5ldyBG b3JDRVMgTXNnLiBJZiB0aGUgYmF0Y2ggb2YgVExWcy9jb21tYW5kcyAoVExWcy9jb21tYW5kcyB0 aGF0IGxvZ2ljYWxseSBiZWxvbmcgdG8gdGhlIHNhbWUgdHJhbnNhY3Rpb24pIGFyZSBzcGxpdCBp bnRvIHR3byBGb3JDRVMgTXNncywgdGhlbiB0aGVyZSB3aWxsIGJlIHR3byBzZXF1ZW5jZSBudW1i ZXJzLiBJIGFtIHJlbHVjdGFudCB0byBrZWVwIHRoZSBzZXF1ZW5jZSBudW1iZXIgdGhlIHNhbWUu IEFja25vd2xlZGdpbmcgdGhlIGhpZ2hlc3QgbnVtYmVyIHdpbGwgbWVhbiB0aGF0IGFsbCBwcmV2 aW91cyBNc2cgd2VyZSByZWNlaXZlZCBhbmQgcHJvY2Vzc2VkIE9LLiBEbyB5b3UgbmVlZCB0byBo YXZlIGFub3RoZXIgbnVtYmVyIChzdWNoIGFzIHRyYW5zYWN0aW9uIG51bWJlciBvciBzdWJtc2cg bnVtYmVyKSBuZWNlc3NhcmlseSA/DQogIFtXZWltaW5nXSBNeSB0aG91Z2h0IHRvIHVzZSBhIHVu aWZvcm0gU2VxdWVuY2UgTnVtYmVyIGZvciBhbGwgYmF0Y2hlZCBGb3JDRVMgbXNnIGFuZCB1c2Ug QmF0Y2hNc2dOdW0gdG8gaW5kaWNhdGUgdGhlIG1zZyBpbnNpZGUgdGhlIGJhdGNoIGlzIG1haW5s eSBmb3Igc3VwcG9ydGluZyBvZiBtdWx0aXB1bCB0cmFuc2FjdGlvbnMgd29ya2luZyBpbiBwYXJh bGxlbC4gQ29uc2lkZXIgYSBjYXNlIHdoZXJlIHdlIGhhdmUgaGFkIHR3byBiYXRjaCBtc2dzIGlu dGVybGVhdmluZ2x5IGJlZW4gc2VudCB0byBGRSBhczoNCg0KICBCMU1zZzEsIEIyTXNnMSwgQjFN c2cyLCBCMk1zZzIsLi4uLi4NCiAgSW4gdGhpcyBjYXNlLCBpZiB3ZSBkbyBub3QgdXNlIGEgdW5p Zm9ybSBzZXF1ZWNlIG51bWJlciBmb3IgQmF0Y2gxIGFuZCBCYXRjaDIsIEl0IHdpbGwgYmUgaGFy ZCB0byBjb3JyZWN0bHkgZG8gYXRvbWljaXR5LCBiZWNhdXNlIHdlIHRoZW4gYXQgYSBsb3NzIHdo aWNoIG1zZ3MgYmVsb25nIHRvIEJhdGNoMSBhbmQgd2hpY2ggYmVsb25nIHRvIEJhdGNoMi4gDQoN CiAgSGkgSmFtYWwsIGNvdWxkIHlvdSBhbHNvIGpvaW4gdXMgaW4gdGhpcyBkaXNjdXNzaW9uPyBJ IHRoaW5rIHdlIGhhdmUgbm90IGFkZHJlc3NlZCB0aGUgYmF0Y2ggYW5kIHRoZSBtdWx0aS1zZXNz aW9ucyBpc3N1ZXMgYmVmb3JlIHRob3VnaCB5b3UgaGF2ZSBwcm9wb3NlZCB0aGUgbXVsdGkgc2Vz c2lvbnMgcHJvYmxlbS4gSSdtIGFmcmFpZCB3ZSBoYXZlIHRvIHNvbHZlIGl0IGJlZm9yZSB3ZSBi ZWdpbiB0aGUgaGVhZGVyIGNvbXBvc2luZy4NCiAgWy9XZWltaW5nXQ0KDQogIElmIHNvbWVvbmUg d2FudHMgdG8gZG8gYSB0cmFuc2FjdGlvbiBhbmQgZW5zdXJlIHRoYXQgb25seSBhIHNpbmdsZSBz ZXF1ZW5jZSBudW1iZXIgaXMgYXNzb2NpYXRlZCB0byBpdCwgdGhlbiBpdCBtdXN0IHBhY2sgYWxs IHRoZSBUTFZzIGludG8gdGhlIHNhbWUgRm9yQ0VTIG1lc3NhZ2UuIFdvdWxkIHRoaXMgYmUgc2F0 aXNmYWN0b3J5ID8NCiAgW1dlaW1pbmddIFRoYXQncyBqdXN0IGluIHRoZSBjYXNlIG9mIHNjaGVt ZSAjMiAod2l0aCBtYW55IFRMVnMpLiBJIGFncmVlIGluIHRoaXMgY2FzZSwgd2UgZG8gbm90IGhh dmUgdGhlIHByb2JsZW0gYXMgSSBtZW50aW9uZWQgYWJvdmUuDQoNCiAgSSByZWFsaXplIHRoYXQg aW4gbXkgcHJldmlvdXMgbm90ZSBJIGNvbmZ1c2VkIGNvbW1hbmQgYW5kIEZvckNFcyBNc2c6IHRo ZXJlIGNhbiBiZSBvbmUgb3IgbW9yZSBjb21tYW5kcyAoPVRMVnMpIGluIGEgRm9yQ0VTIE1zZy4g VGhlIHNlcXVlbmNlIG51bWJlciBpcyBhc3NvY2lhdGVkIHdpdGggYSBGb3JDRVMgTXNnLg0KICBb V2VpbWluZ10gWWVzLCBJIGFjdHVhbGx5IHVuZGVyc3RhbmQgaXQuIEp1c3Qgd2UgYXJlIHByb3Bv c2luZyB0d28gc2NoZW1lcy4gVGhlIGZpcnN0IHNjaGVtZSBpcyBzdXBwb3NlZCBub3QgdG8gdXNl IGNvbW1hbmQgVExWcywgaW5zdGVhZCBqdXN0IHVzZSBGb3JDRVMgbXNncyBmb3IgYmF0Y2hpbmcg cHVycG9zZXMuIEkgdGhpbmsgTmV0bGluazIgYWxzbyBoYXMgdGhpcyBzY2hlbWUsIHJpZ2h0Pw0K DQogIFJlZ2FyZHMsDQogIC1Sb2JlcnQNCg0KICBCUiwNCiAgV2VpbWluZw0KDQo= ------=_NextPart_000_002F_01C43475.E7B6EE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD5IaSByb2JlcnQsIGFuZCBKYW1hbCBhcyB3ZWxsLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxCUj4mbmJzcDs8L0RJVj4NCjxC TE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxF RlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlk OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMDI5MjAxYzQzMzJi JGRjYTE4NjQwJDAyMGFhOGMwQHd3bTEgdHlwZT0iY2l0ZSI+DQogICAgPEJMT0NLUVVPVEUgZGly PWx0ciANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsg TUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkgMnB4IHNvbGlkOyBNQVJH SU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPldlaW1pbmcsPEJSPkkgdGhpbmsgdGhlIGFwcHJv YWNoIG9mJm5ic3A7ICdQbHMgbGV0IG1lIGtub3cgd2hlbiB5b3UgDQogICAgICBlbmNvdW50ZXIg ZGlmZmljdWx0aWVzLCBvdGhlcndpc2UgcGxzIGRvbid0IGJvdGhlcicgaXMgaW5kZWVkIHVzZWZ1 bC4gTGV0IA0KICAgICAgbWUgZWxhYm9yYXRlIGEgYml0IG9uIHRoaXMuIFNvcnJ5IGZvciB0aGUg cmF0aGVyIGxvbmcgbWVzc2FnZS4gSSdsbCBkZXZvdGUgDQogICAgICBhbm90aGVyIG5vdGUgdG8g d2luZG93aW5nLjxCUj48QlI+Jm5ic3A7QmF0Y2hpbmcgaXMgdXNlZCB0byBncm91cCBjb21tYW5k cyANCiAgICAgIHRvZ2V0aGVyLiBFYWNoIGNvbW1hbmQgcG9zc2libHkgaGFzIGl0cyBvd24gc2Vx dWVuY2UgbnVtYmVyIChvciANCiAgICAgIHRyYW5zYWN0aW9uIG51bWJlciksIDwvRElWPg0KICAg ICAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPltXZWltaW5nXU5vIHBy b2JsZW0gd2l0aCB0aGUgbmFtZSBzZXF1ZW5jZSANCiAgICAgIG51bWJlciwgSSBhbHNvIGxpa2Ug aXQuPC9GT05UPjwvRElWPg0KICAgICAgPERJVj5vciB0aGUgZ3JvdXAgaGFzIGl0cyBvd24gbnVt YmVyIHdpdGggc3VibnVtYmVycyBmb3IgZWFjaCBtZXNzYWdlIA0KICAgICAgKHRoaXMgcmVtYWlu cyB0byBiZSBkZWNpZGVkLikgVGhlIG1haW4gdXNlIG9mIGJhdGNoaW5nIGlzIHRvIHBlcmZvcm0g DQogICAgICBhdG9taWNpdHk6IDwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzs+W1dlaW1pbmddSSBhZ3JlZSB0aGlzLCB0aG91Z2ggSSB3YXMgYSBsaXR0bGUgY29u ZnVzZWQgDQogICAgICBiZWZvcmUgd2l0aCB0aGUgbm90aW9ucyAnYmF0Y2hpbmcsIGF0b21pY2l0 eSwgMi1waGFzZSBjb21taXQsIGFsbCBvciANCiAgICAgIG5vdGhpbmcnLiBDYW4gd2UgdW5kZXJz dGFuZCB0aGF0IHRoZXkgYXJlIGFsbCB0YXJnZXRpbmcgdGhlIHNhbWUgdGhpbmc6IA0KICAgICAg YWxsIG9yIG5vdGhpbmc/IE9yIHdlIGhhdmUgb3RoZXIgcHVycG9zZSBmb3IgYmF0Y2hpbmcgc3Vj aCBhcyBqdXN0IGZvciANCiAgICAgIHBhY2tldGl6aW5nPzwvRk9OVD48L0RJVj48L0JMT0NLUVVP VEU+PC9CTE9DS1FVT1RFPjxCUj5UaGUgcHVycG9zZSBvZiANCiAgYmF0Y2hpbmcsIGJ1bmRsaW5n LCBncm91cGluZywgYXRvbWljaXR5LCAyLXBoYXNlLWNvbW1pdCwgaXMgZm9yIHRoZSBzYW1lIA0K ICBwdXJwb3NlOiBleGVjdXRlIGEgc2VyaWUgb2YgY29tbWFuZHMgaW4gc3VjaCBhIHdheSB0aGF0 IHRoZWlyIGVmZmVjdCBpcyB0aGUgDQogIHNhbWUgYXMgaWYgaXQgaGFkIGJlZW4gYSBzaW5nbGUg Y29tbWFuZC48QlI+PEJSPklmIHRoZSBudW1iZXIgb2YgY29tbWFuZHMvVExWcyANCiAgdG8gaW5j bHVkZSBvbiBhIEZvckNFUyBNc2cgZXhjZWVkcyB0aGUgbWF4aW11bSBsZW5ndGggb2YgdGhlIEZv ckNFUyBtZXNzYWdlLCANCiAgdGhlbiBJIHdvdWxkIHNpbXBseSB1c2UgYW5vdGhlciBGb3JDRVMg TXNnLCBhbmQgb25seSBzZXQgYmF0Y2hpbmcgT04gaWYgSSANCiAgd2FudGVkIGF0b21pY2l0eSBh Y3Jvc3MgdGhlIGNvbW1hbmRzIGluIHRoZSB0d28gc2VwYXJhdGUgRm9yQ0VTIE1zZ3MuIERvZXMg DQogIHRoYXQgc291bmQgcmVhc29uYWJsZSA/PEJSPjxCUj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1t aWQwMjkyMDFjNDMzMmIkZGNhMTg2NDAkMDIwYWE4YzBAd3dtMSB0eXBlPSJjaXRlIj4NCiAgICA8 QkxPQ0tRVU9URSBkaXI9bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJ TkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogcmdiKDAsMCwwKSAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgICA8RElWPmFsbCBjb21tYW5kcyBpbiB0aGUgZ3JvdXAgd2lsbCBiZSBwZXJmb3JtZWQgYXQg dGhlIHNhbWUgdGltZSBvciBub25lIA0KICAgICAgd2lsbCBiZSBwZXJmb3JtZWQuIFRoaXMgaXMg d2hlcmUgMi1waGFzZSBjb21taXQga2lja3MgaW46IGFsbCBjb21tYW5kcyBhcmUgDQogICAgICBm aXJzdCB0cmFuc21pdHRlZCB0byB0aGUgRkUsIGFuZCB1bmxlc3MgdGhlIEZFIHJlcG9ydHMgYW4g ZXJyb3IsIHRoZSBDRSANCiAgICAgIGNhbiB1bHRpbWF0ZWx5IGlzc3VlIGEgY29tbWl0IGNvbW1h bmQgc28gYWxsIHRoZXNlIGNvbW1hbmRzIGFyZSBleGVjdXRlZCANCiAgICAgIGluIGFuIGF0b21p YyBvcGVyYXRpb24gYXQgdGhlIEZFLjxCUj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQog ICAgICBzaXplPTI+W1dlaW1pbmddWWVzLjwvRk9OVD48QlI+V2UgaW52ZXN0aWdhdGVkIHRoZSBp ZGVhIG9mIHBhY2tpbmcgDQogICAgICBtdWx0aXBsZSBjb21tYW5kcyBpbiB0aGUgc2FtZSBGb3JD RVMgbWVzc2FnZSAoaXQgc2F2ZXMgcXVpdGUgc29tZSBoZWFkZXJzIA0KICAgICAgYW5kIHRoZSBh c3NvY2lhdGVkIHByb2Nlc3Npbmc8L0RJVj4NCiAgICAgIDxESVY+W1dlaW1pbmddSGVyZSwgSSB0 aGluayZuYnNwO3dlIG5lZWQgdG8gZXZhbHVhdGUgaWYgdGhlIGhlYWRlcnMgYXJlIA0KICAgICAg d29ydGggdGhlcmUgb3Igbm90LiBNeSBvcmlnaW5hbCBpZGVhIHdhcyBpdCB3YXMgbm90IHdvcnRo IGl0IChkdXJpbmcgR1JNUCANCiAgICAgIHRpbWUpLCBidXQgbm93IEkgY2hhbmdlIHNvbWUuIEp1 c3QgY2hlY2sgdGhlIHBvc3NpYmxlIGhlYWRlciBmaWVsZHMsIHdlIA0KICAgICAgbWF5IGZpbmQg dGhhdCBtb3N0IG9mIHRoZW0gYXJlIHdvcnRoIHRoZXJlLCBhbmQgdGhlIHJld2FyZCBpcyBncmVh dCwgDQogICAgICBhbGxvd2luZyBwZXIgbXNnIEFDSywgYW5kIHdpdGggbXVjaCBsZXNzIGNvbXBs ZXhpdHkgZm9yIHByb3RvY29sIHN0YXRlIA0KICAgICAgdHJhY2UuPC9ESVY+DQogICAgICA8RElW PiZuYnNwOzwvRElWPg0KICAgICAgPERJVj4pLiBBcyBhIG1vdGl2YXRpb24sIHRoaW5rIG9mIGFk ZGluZyAxMDAnMDAwIHJvdXRlcyBvbiBhbiBGRTogc2hvdWxkIA0KICAgICAgd2UgdXNlIDEwMCcw MDAgRm9yQ0VTIG1lc3NhZ2VzLCBvciBvbmx5IDEwMDAgKHNheSAxNSBieXRlcyBwZXIgcm91dGUg DQogICAgICB1cGRhdGUgY29tbWFuZCB0byBiZSBnZW5lcm91cywgd2l0aCBhIDE1MDAgYnl0ZXMg TVRVIHNpemUsIG9yIGV2ZW4gbGVzcyBpZiANCiAgICAgIHdlIGhhdmUgSnVtYm8gZnJhbWVzKSA/ IDxCUj48QlI+Tm90ZSB0aGF0IGhhdmluZyBtYW55IGNvbW1hbmRzIGluIHRoZSBzYW1lIA0KICAg ICAgRm9yQ0VTIG1lc3NhZ2UgcmVzdWx0cyBpbiBzbGlnaGx0eSBtb3JlIGNvbXBsZXggZXJyb3Iv YWNrIHJlcG9ydGluZy4gVGFrZSANCiAgICAgIHRoaXMgZXhhbXBsZTogdHdvIGNvbW1hbmRzIEEg YW5kIEIgaW4gdGhlIHNhbWUgRm9yQ0VTIG1lc3NhZ2UgaXNzdWVkIGJ5IGEgDQogICAgICBDRS4g RkUgZXhlY3V0ZXMgYm90aCBvZiZuYnNwOyB0aGVtLCBidXQgb25seSBBIHN1Y2NlZWRzLiBJdCBz aG91bGQgcmVwb3J0IA0KICAgICAgdGhpcyBzb21laG93IHRvIHRoZSBDRS4gQSBwb3NzaWJsZSBz b2x1dGlvbiBpcyB0byByZXR1cm4gdGhlIG9yaWdpbmFsIA0KICAgICAgbWVzc2FnZSB0cmltbWVk IGRvd24gc3VjaCB0aGF0IGl0IGNvbnRhaW5zIGV4YWN0bHkgdHdvIHJlc3BvbnNlcywgYSANCiAg ICAgIHBvc2l0aXZlIGFuZCBhIG5lZ2F0aXZlIG9uZS48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7PltXZWltaW5nXVllcywgSSB0aGluayB5b3UgYXJlIGFsc28g dHJ5aW5nIHRvIHNlZSB3aGljaCANCiAgICAgIGlzIGJldHRlciBhbW9uZyB0aGUgZm9sbG93aW5n IHR3byBwb3NzaWJsZSBiYXRjaGluZyBzY2hlbWVzOjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjEuIEJhdGNoZWQgbXNncyBpbiBvbmUgcGFja2V0 Jm5ic3A7b3IgZXZlbiZuYnNwO2tlZXBpbmcgDQogICAgICB0aGUgbXNncyBzZXBhcmF0ZWx5IGFz IGl0cyBvcmlnaW4sIHdoaWxlJm5ic3A7d2l0aCZuYnNwO3NvbWUgZmxhZ3Mgc3VjaCBhcyANCiAg ICAgIEF0b21pY2l0eSBhbmQvb3IgRG9uZSBGbGFnIHRvIGluZGljYXRlIHRoZSBiZWdpbiBhbmQg dGhlIGVuZC48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3Oz4yLiBNYW55IGNvbW1hbmRzIGluIG9uZSBtc2cgYXMgeW91IG1lbnRpb25lZCBhYm92ZS4g DQogICAgICA8L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3Oz5JIGEgbGl0dGxlIG1vcmUgaW5jbGluZSB0byAjMSBzY2hlbWUsIGFzIHRoZSByZWFzb24g SSANCiAgICAgIG1lbnRpb25lZCBhYm92ZS4gQnV0IHRoZXJlIGlzIGEmbmJzcDtyZW1haW5lZCBp c3N1ZSBmb3Igc3VjY2Vzc2Z1bCANCiAgICAgIGF0b21pY2l0eSwgdGhhdCBpcywgaXQgZG9lcyBu b3Qgc3VwcG9ydCBtdWx0aXB1bCB0cmFuc2FjdGlvbnMgaWYgd2UgdXNlIA0KICAgICAgZGlmZmVy ZW50IHNlcXVlY2UgbnVtYmVyIGZvciBkaWZmZXJlbnQgbXNncyBpbiBhIGJhdGNoLCBhbmQgaWYg d2UgdXNlIHNhbWUgDQogICAgICBzZXF1ZW5jZSBudW1iZXIgZm9yIGFsbCB0aGUgbXNncywgdGhl biBpdCBtYXkgcmVzdWx0IGluIGFtYmlndWl0eSBmb3IgbXNnIA0KICAgICAgbWVhbmluZyBhbmQg aGFyZCBmb3IgQUNLLiBUaGVyZWZvcmUsIEkgdHJ5IHRvIHByb3Bvc2UgdG8gdXNlIGEgc3ViIG1z ZyANCiAgICAgIG51bWJlciZuYnNwO3RvIHNlZSBpZiBpdCBpcyBmZWFzaWJsZSBmb3IgdGhlIHB1 cnBvc2UuJm5ic3A7UGxzIGxldCBtZSB0cnkgDQogICAgICB0byBzdW1tYXJpemUmbmJzcDtzdGgg d2UndiBhbHJlYWR5IGdvdCAoTmV0bGluazI/KSZuYnNwO2Fsb25nIA0KICAgICAgd2l0aCZuYnNw O3RoZSBiYXRjaCBtc2cgIyB0aG91Z2h0IGFzIGZvbGxvd3M6PC9GT05UPjwvRElWPg0KICAgICAg PERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PkJhdGNoaW5nIG1zZyBhczo8L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+TXNnMTpNc2cyOi4uLk1zZ04g KGVpdGhlciBvbmUgcGFja2V0IG9yIHNlcGFyYXRlZCANCiAgICAgIHBhY2tldHMpPC9GT05UPjwv RElWPg0KICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0mIzIz NDM1OyYjMjAzMDc7PkluIGhlYWRlcnMgb2YgYWxsIHRoZSBtc2dzLDwvRk9OVD48L0RJVj4NCiAg ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3Oz5TZXF1ZW5jZSBOdW1iZXJzOiZuYnNwO2FsbCB0aGUgc2FtZSwgdGhhdCBtZWFucyBhIGJh dGNoIA0KICAgICAgaXMgdHJlYXRlZCBhcyBhIHRyYW5zYWN0aW9uLjwvRk9OVD48L0RJVj4NCiAg ICAgIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkFUTSBmbGFnOiBtYXJrIHRoZSBl bmQgb2YgYmF0Y2hpbmcgKGUuZy4sMCBmb3IgTXNnTiwgDQogICAgICBhbmQgYWxzbyBhIHNpZ25h bCB0byBleGN1dGUgdGhlIGJhdGNoLCAxIGZvciBvdGhlcnMsIGFuZCBhbHNvIGFzIGEgc2lnbmFs IA0KICAgICAgdG8gcmVzZXJ2ZSBpdCk8L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz5BQ0sgZmxhZzogaW5kaWNhdGUgaWYgdGhpcyBtc2cgbmVlZCBh biBBQ0s8L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz5CYXRjaE1zZ051bTogbWFyayB0aGUgYmF0ZWhlZCBtc2cgc2VxdWVuY2UgbnVtYmVyLCAwIA0K ICAgICAgZm9yIE1zZzEsIC4uLiAoTi0xKSBmb3IgTXNnTi4gQW55IEFDSyBzaG91bGQgaW5jbHVk ZSBCYXRjaE1zZ051bSBhcyB3ZWxsIA0KICAgICAgYXMgb3RoZXJzLjwvRk9OVD48L0RJVj4NCiAg ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3Oz5Bbnkgb2YgdGhlIE1zZyBpbiB0aGUgYmF0Y2ggc3RpbGwgY2FuIGJlIGZyYWdtZW50ZWQg aWYgDQogICAgICBpdCBleGNlZWRzIHRoZSBNVFUsIGEgRlJHIGZsYWcgaXMgdXNlZCB0byZuYnNw O3RyZWF0IGl0LCB3aXRoIHRoZSB0aGlua2luZyANCiAgICAgIHRoYXQgdGhlIHBhY2tldHMgd2ls bCBub3QgYmUgcmVvcmRlcmVkLjwvRk9OVD48L0RJVj48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NL UVVPVEUgZGlyPWx0ciANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxF RlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkgMnB4IHNv bGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3Oz5Sb2I6IGNhbiB5b3UgdHJ5IHRvIHByZXNlbnQgYSBzdW1tYXJ5IHJlZ2FyZGluZyB0 aGUgIzIgDQogICAgICBzY2hlbWUsIHNvIHRoYXQgd2UgY2FuIGNhcmVmdWxseSBjb21wYXJlIGFu ZCBldmFsdWF0ZSANCiAgICBpdD88L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9U RT4NCiAgPERJVj5MZXQgbWUgdHJ5OjxCUj48QlI+T25lIHNpbmdsZSBGb3JDRVMgTXNnLCB3aXRo IE4gVExWcyAoVExWcyBhcmUgYmFzaWNhbGx5IA0KICB0aGUgY29tbWFuZCBkZXN0aW5lZCB0byBM RkJzKS4gSWYgdGhlIGJhdGNoIHNwYW5zIG1vcmUgdGhhbiBvbmUgc2luZ2xlIEZvckNFUyANCiAg TXNnIHRoZSBBVE0gZmxhZyB3aWxsIGhhdmUgdG8gYmUgc2V0IGFjY29yZGluZ2x5LiBUaGUgcmVz dWx0aW5nIEFDSyBNc2cgY2FuIGJlIA0KICBmb3IgdGhlIGVudGlyZSBGb3JDRVMgTXNnICh1c2lu ZyB0aGUgc2VxdWVuY2UgbnVtYmVyKS4gT3IgdGhlIEFDSyBNc2cgY2FuIA0KICBjb250YWluIHRo ZSBzYW1lIFRMVnMgYXMgdGhlIG9yaWdpbmFsIE1lc3NhZ2UsIHdpdGggYSBmbGFnIGluIGVhY2gg VExWIHRvIA0KICBpbmRpY2F0ZSBpZiB0aGF0IHBhcnRpY3VsYXIgVExWIHN1Y2NlZWRlZCBvciBu b3QuIElmIHRoZSBBdG9taWMgZmxhZyB3YXMgc2V0IA0KICB3aXRoIHRoZSAyLXBoYXNlIGNvbW1p dCwgdGhlbiBhbGwgVExWcyBzdWNjZWVkIG9yIG5vbmUuPEJSPjxGT05UIGZhY2U9QXJpYWwgDQog IHNpemU9Mj5bV2VpbWluZ10gSSBqdXN0IHRyeSB0byB0aGluayBvZiBpdCBpbnRvIGEgbGl0dGxl IG1vcmUgZGV0YWlsLiBTbywgd2lsbCANCiAgdGhlIFRMVnMgdGhlbXNlbHZlcyBpbmNsdWRlIHRo aW5ncyBhcyBBQ0sgZmxhZywgYW5kIGEgbnVtYmVyIHRvIGluZGljYXRlIHRoZSANCiAgcGxhY2Ug b2YgdGhlIFRMViBpbiB0aGUgd2hvbGUgYmlnIG1zZz8mbmJzcDsgPC9GT05UPjwvRElWPjxGT05U IGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9G T05UPg0KICA8RElWPjxCUj5UaGUgc2VxdWVuY2UgbnVtYmVyIG11c3QgYmUgaW5jcmVtZW50ZWQg Zm9yIGVhY2ggbmV3IEZvckNFUyBNc2cuIElmIA0KICB0aGUgYmF0Y2ggb2YgVExWcy9jb21tYW5k cyAoVExWcy9jb21tYW5kcyB0aGF0IGxvZ2ljYWxseSBiZWxvbmcgdG8gdGhlIHNhbWUgDQogIHRy YW5zYWN0aW9uKSBhcmUgc3BsaXQgaW50byB0d28gRm9yQ0VTIE1zZ3MsIHRoZW4gdGhlcmUgd2ls bCBiZSB0d28gc2VxdWVuY2UgDQogIG51bWJlcnMuIEkgYW0gcmVsdWN0YW50IHRvIGtlZXAgdGhl IHNlcXVlbmNlIG51bWJlciB0aGUgc2FtZS4gQWNrbm93bGVkZ2luZyANCiAgdGhlIGhpZ2hlc3Qg bnVtYmVyIHdpbGwgbWVhbiB0aGF0IGFsbCBwcmV2aW91cyBNc2cgd2VyZSByZWNlaXZlZCBhbmQg cHJvY2Vzc2VkIA0KICBPSy4gRG8geW91IG5lZWQgdG8gaGF2ZSBhbm90aGVyIG51bWJlciAoc3Vj aCBhcyB0cmFuc2FjdGlvbiBudW1iZXIgb3Igc3VibXNnIA0KICBudW1iZXIpIG5lY2Vzc2FyaWx5 ID88QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+W1dlaW1pbmddIE15IHRob3VnaHQgdG8gdXNl IGEgDQogIHVuaWZvcm0gU2VxdWVuY2UgTnVtYmVyIGZvciBhbGwgYmF0Y2hlZCBGb3JDRVMgbXNn IGFuZCB1c2UgQmF0Y2hNc2dOdW0gdG8gDQogIGluZGljYXRlIHRoZSBtc2cgaW5zaWRlIHRoZSBi YXRjaCBpcyBtYWlubHkgZm9yIHN1cHBvcnRpbmcgb2YgbXVsdGlwdWwgDQogIHRyYW5zYWN0aW9u cyB3b3JraW5nIGluIHBhcmFsbGVsLiBDb25zaWRlciBhIGNhc2Ugd2hlcmUgd2UgaGF2ZSBoYWQg dHdvIGJhdGNoIA0KICBtc2dzIGludGVybGVhdmluZ2x5IGJlZW4gc2VudCB0byBGRSBhczo8L0ZP TlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkIxTXNnMSwgQjJNc2cxLCBCMU1z ZzIsIA0KICBCMk1zZzIsLi4uLi48L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9CTE9DS1FVT1RFPg0K PEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkct TEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29s aWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij48Rk9OVCANCiAgZmFjZT1BcmlhbCBzaXplPTI+SW4gdGhp cyBjYXNlLCBpZiB3ZSBkbyBub3QgdXNlIGEgdW5pZm9ybSBzZXF1ZWNlIG51bWJlciBmb3IgDQog IEJhdGNoMSBhbmQgQmF0Y2gyLCBJdCB3aWxsIGJlIGhhcmQgdG8gY29ycmVjdGx5IGRvIGF0b21p Y2l0eSwgYmVjYXVzZSB3ZSB0aGVuIA0KICBhdCBhIGxvc3Mgd2hpY2ggbXNncyBiZWxvbmcgdG8g QmF0Y2gxIGFuZCB3aGljaCBiZWxvbmcgdG8gDQogIEJhdGNoMi4mbmJzcDs8L0ZPTlQ+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZP TlQ+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIEphbWFsLCBjb3VsZCB5b3UgYWxzbyBq b2luIHVzIGluIHRoaXMgDQogIGRpc2N1c3Npb24/IEkgdGhpbmsgd2UgaGF2ZSBub3QgYWRkcmVz c2VkIHRoZSBiYXRjaCBhbmQgdGhlIG11bHRpLXNlc3Npb25zIA0KICBpc3N1ZXMgYmVmb3JlIHRo b3VnaCB5b3UgaGF2ZSBwcm9wb3NlZCB0aGUgbXVsdGkgc2Vzc2lvbnMgcHJvYmxlbS4gSSdtIGFm cmFpZCANCiAgd2UgaGF2ZSB0byBzb2x2ZSBpdCBiZWZvcmUgd2UgYmVnaW4gdGhlIGhlYWRlciBj b21wb3NpbmcuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlsv V2VpbWluZ108L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9G T05UPjxCUj5JZiBzb21lb25lIHdhbnRzIHRvIGRvIGEgdHJhbnNhY3Rpb24gDQogIGFuZCBlbnN1 cmUgdGhhdCBvbmx5IGEgc2luZ2xlIHNlcXVlbmNlIG51bWJlciBpcyBhc3NvY2lhdGVkIHRvIGl0 LCB0aGVuIGl0IA0KICBtdXN0IHBhY2sgYWxsIHRoZSBUTFZzIGludG8gdGhlIHNhbWUgRm9yQ0VT IG1lc3NhZ2UuIFdvdWxkIHRoaXMgYmUgDQogIHNhdGlzZmFjdG9yeSA/PC9ESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PC9GT05UPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPltX ZWltaW5nXSBUaGF0J3MganVzdCBpbiB0aGUgY2FzZSBvZiBzY2hlbWUgIzIgDQogICh3aXRoIG1h bnkgVExWcykuIEkgYWdyZWUgaW4gdGhpcyBjYXNlLCB3ZSBkbyBub3QgaGF2ZSB0aGUgcHJvYmxl bSBhcyBJIA0KICBtZW50aW9uZWQgYWJvdmUuPC9GT05UPjwvRElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPg0KICA8RElW PjxCUj5JIHJlYWxpemUgdGhhdCBpbiBteSBwcmV2aW91cyBub3RlIEkgY29uZnVzZWQgY29tbWFu ZCBhbmQgRm9yQ0VzIE1zZzogDQogIHRoZXJlIGNhbiBiZSBvbmUgb3IgbW9yZSBjb21tYW5kcyAo PVRMVnMpIGluIGEgRm9yQ0VTIE1zZy4gVGhlIHNlcXVlbmNlIG51bWJlciANCiAgaXMgYXNzb2Np YXRlZCB3aXRoIGEgRm9yQ0VTIE1zZy48QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+W1dlaW1p bmddIFllcywgSSANCiAgYWN0dWFsbHkgdW5kZXJzdGFuZCBpdC4gSnVzdCB3ZSBhcmUgcHJvcG9z aW5nIHR3byBzY2hlbWVzLiBUaGUgZmlyc3Qgc2NoZW1lIGlzIA0KICBzdXBwb3NlZCBub3QgdG8g dXNlIGNvbW1hbmQgVExWcywgaW5zdGVhZCBqdXN0IHVzZSBGb3JDRVMgbXNncyBmb3IgYmF0Y2hp bmcgDQogIHB1cnBvc2VzLiBJIHRoaW5rIE5ldGxpbmsyIGFsc28gaGFzIHRoaXMgc2NoZW1lLCBy aWdodD88L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05U PjxCUj5SZWdhcmRzLDxCUj4tUm9iZXJ0PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QlIsPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_002F_01C43475.E7B6EE80-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 11:18: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 LAA00446 for ; Fri, 7 May 2004 11:18: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 1BM6qW-0002bf-7L for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 11:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47F14Wd010017 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 11:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6aG-0004iu-2j for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:44: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 KAA27401 for ; Fri, 7 May 2004 10:44: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 1BM6aD-0004tv-JJ for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:44:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6Yv-00047b-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:42:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6XM-0003Ad-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 10:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5xS-0002nq-8s; Fri, 07 May 2004 10:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5ZY-00014H-SO for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 09:39: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 JAA21388 for ; Fri, 7 May 2004 09:39: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 1BM5ZW-00064K-Un for forces-protocol@ietf.org; Fri, 07 May 2004 09:39:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM5YF-0005aq-00 for forces-protocol@ietf.org; Fri, 07 May 2004 09:38:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BM5XI-00058u-00 for forces-protocol@ietf.org; Fri, 07 May 2004 09:37:08 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by mx2.foretec.com with esmtp (Exim 4.24) id 1BM5XI-0001Uy-Aj for forces-protocol@ietf.org; Fri, 07 May 2004 09:37:08 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 7 May 2004 21:49:24 +0800 Message-ID: <001c01c43437$cf65d6e0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <409A5679.8050501@zurich.ibm.com> <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> <409B5792.9080808@zurich.ibm.com> <1083933541.1036.42.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Summary : 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: Fri, 7 May 2004 21:32: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.2 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, I think the focus we are discussing is if there are something that shoud be operated via ForCES protocol, while at the same time, is out of the accessibility of LFBs defined by FE model. Now we can see that FE model has mainly treated LFBs as the elements for forwarding process, that is, they are mainly along the packet datapathes (at least one datapathes in or out of it). I just a little worry if an LFB like a heartbeat generator can be included in. Moreover, even if heartbeat can be treated as a LFB, we still have many left as I mentioned below. I agree that to define the 'thing' may not reduce msg number. My main idea is whether we specifically distinguish the 'thing', it exists in our protocol. Or, from other perspective, I just want to say that we may need to define some FE attributes, capabilities, and events by ourseves in our ForCES protocol, which we may not rely on FE model to define. BR Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > Robert/Weiming, > > I apologize for actually not saying anything on this subject. > Initially i was confused ;-> > > I think the "thing" you are describing adds value, the problem is > whether it should be called an LFB, LFB-wannabe, FE-manager. To be > honest it is almost like an implementation level architecture detail. I > also dont see how you can reduce the number of message types. For > example, it should be possible to target hearbeats to any LFB not just > to this "thing". > Are you suggesting it is a "muxer" of all heartbeats etc? > > I am not against it, i think it will ease the implementations; i am just > trying to formulate its need in my head. > > cheers, > jamal > > On Fri, 2004-05-07 at 05:32, Robert Haas wrote: > > Weiming, > > Yes, I think we have very much the same view on this issue. I called > > it FE LFB because from a protocol point of view, setting FE attributes > > (and other operations) will be done the same way as to any other > > (real) LFB. Hormuzd pointed out that the model team could take over > > the definition of this particular FE LFB. I think it should not. While > > the model team can define the general structure of LFBs, we'll have to > > fill the FE LFB with content, i.e., define the events and attributes > > of interest to run the ForCES protocol. The list you have put up > > already seems very reasonable to me. > > > > I hope that by defining such an FE LFB we can limit the amount of > > message types that must be defined for the ForCES protocol. > > > > Regards, > > -Robert > > > > Weiming Wang wrote: > > > > > > Hi Robert, and all, > > > > > > I'm very glad that your idea of FE LFB may quite meet with my idea > > > anyway. Actually I called it 'FE Slave' instead of FE LFB. I think > > > both of us think of this entity because we have realized that many > > > of the functions in FE are actually beyond the scope of LFBs defined > > > by FE models. These functions can also be described by using notions > > > such as attibutes, events, capabilites, and states(UP/Down). Because > > > these notions here are mainly effective for whole FE (that is, take > > > whoe FE (at a coarse layer) as a managed entity), in my scheme, we > > > just call then FE attributes, FE events, and FE capabilities, which > > > are discriminated from LFB attributes, LFB events, and LFB > > > capabilities. > > > > > > I'd like to show some of the contents to see if they meet your > > > thoughts: > > > For FE events, we may have: > > > .FE state events (FE Up/Down/Active/Inactive/Failover) > > > .FE heartbeat > > > .FE DoS alert > > > .FE capability change > > > .FE TML events > > > > > > For FE capability, we may have > > > .Currently supported ForCES protocol version by the FE > > > .Currently supported ForCES FE model by the FE > > > .Some TML capability description > > > > > > Fe FE attributes, via which we may able to do: > > > . To setup or negotiate a version of FE model or the ForCES protocol > > > . To setup many policies for the FE, for which FE model is not able > > > to do (out of its scope), e.g., > > > - FE failover and restart policy (such as graceful restart or not) > > > - FE heartbeat policy (such as the intervals for the heartbeat, > > > etc) > > > > > > . FE events subscribe/unsubscribe (including to start or stop > > > heartbeats) > > > . for TML management if needed. > > > > > > Anyway, any management that is out of the scope of FE model can be > > > put in the FE LFB/ FE slave entity. That is I think our idea, is it > > > right? > > > > > > Cheers, > > > Weiming > > > > > > ----- Original Message ----- > > > From: Robert Haas > > > To: forces-protocol@ietf.org > > > Sent: Thursday, May 06, 2004 11:15 PM > > > Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol > > > Messages: topic 3 & 4a] > > > > > > Maybe my last message on that topic went unnoticed, so I > > > wanted to again stress the possibility to create an FE LFB > > > (call it meta LFB, control LFB, etc) that can be configured, > > > events can be subscribed to, etc. The difference between the > > > FE LFB and the other "regular" LFBs is that no data packet > > > traverses the FE LFB. The purpose of the FE LFB is to > > > facilitate the control of the FE: > > > > > > Examples: > > > > > > - FE UP and DOWN don't need to be special ForCES messages. > > > Instead, they can be events originated by the FE LFB. > > > - Configuring the interval timer for heartbeats messages can > > > be done using a Config message to the hearbeat interval > > > attribute of the FE LFB. > > > > > > The reason to introduce this LFB versus creating specific > > > ForCES messages is flexibility: at some point in time, if we > > > need to enhance the ForCES protocol, we don't necessarily > > > need to change the protocol itself. Instead, we can create a > > > new version of the FE LFB that supports new features. > > > > > > I'd like to have your comments on such an FE LFB. > > > > > > Regards, > > > -Robert > > > > > > > > > -- > > 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 > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 15:14:49 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 PAA14657 for ; Fri, 7 May 2004 15:14: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 1BMAkf-0007b6-3f for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 15:11:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JBHMQ029203 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 15: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 1BMAet-0002Wf-OP for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:05: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 PAA13335 for ; Fri, 7 May 2004 15:05: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 1BMAeq-0004gs-Pd for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAde-0004EO-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:04:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAco-0003oL-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:03:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAVz-0003eQ-Uh; Fri, 07 May 2004 14:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMANM-0000kT-J0 for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 14:47: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 OAA11879 for ; Fri, 7 May 2004 14:47: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 1BMANJ-0004Os-S9 for forces-protocol@ietf.org; Fri, 07 May 2004 14:47:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAMP-0003xC-00 for forces-protocol@ietf.org; Fri, 07 May 2004 14:46: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 1BMALO-0003M4-00 for forces-protocol@ietf.org; Fri, 07 May 2004 14:45: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 2004050711485411:10199 ; Fri, 7 May 2004 11:48:54 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header: batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: Robert Haas , forces-protocol@ietf.org In-Reply-To: <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1083955505.1598.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 05/07/2004 11:48:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 11:48:58 AM, Serialize complete at 05/07/2004 11:48: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: 07 May 2004 14:45: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 Ok, I just deleted everything that was said and i am going to summarize with a twist of my opinions. (I hope i read all the discussions correctly). Robert/Weiming please double check. Hopefully, this summary will allow other people to pitch in. Why do we batch? 1) to pipeline and improve throughput 2) to achieve atomic operations spanning multiple packets. Note that #1 may not be necessarily be atomic operation. PL message/transaction exceeding MTU: I think the PL should carefully ensure that the messages going across are each at least going to fit in the MTU size packet. I think if we can avoid fragmentation of a command, then we should. Types of batching: 1) several PL messages in one TML level PDU. PL level header SOT and EOT indicate start and end of a train of these messages. Is this responsibility of TML or PL to put them in one PDU or that of PL? I feel it is the responsibility of PL. 2) Within one message several TLVs which require that each "atomic" unit have its own subsequence number (and treat the top header sequence number as a flat transaction number). My preference is using #1 mostly because now we have to look for a trick to stash a subsequence number. too complex. You can already pack many routes for example in one message - so no need to be clever. Each message will have a unique sequence number. Start of transaction gets marked by SoT and end of transaction gets marked by EoT. And any middle messages probably marked with MoT? Weiming points to a concern about the common header introducing ovrehead. My opinion is the overhead is so small that it is irrelevant against the benefits of keeping track of subsequence numbers. What to do in case of failures? Lets say you sent an atomic batch of A) a del route, B) an add route and C) add route Techniques (listed by Joel Halpern once). 1) All or nothing: if B fails A should also fail; if A was done then you undo 2) Fail upto: If B fails but A passes, then we just inform CE of Bs failure and dont execute C. 3) I cant remember it, but i think there was a third technique I think the most interesting this is what happens if FE1 executes A successfuly and FE2 both A and B but not C. You need to make sure things are synchronized I hope i summarized everuthing that was said. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 7 15:19:56 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 PAA15168 for ; Fri, 7 May 2004 15:19: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 1BMAn8-0000XZ-Jy for forces-protocol-archive@odin.ietf.org; Fri, 07 May 2004 15:13:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JDoq9002057 for forces-protocol-archive@odin.ietf.org; Fri, 7 May 2004 15: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 1BMAjZ-0006qv-59 for forces-protocol-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:10: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 PAA14090 for ; Fri, 7 May 2004 15:10: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 1BMAjW-0006zb-7F for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:10:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAii-0006Z9-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:09:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAhv-00068X-00 for forces-protocol-web-archive@ietf.org; Fri, 07 May 2004 15:08:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAWs-0003v1-1r; Fri, 07 May 2004 14:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAV1-00037z-Cf for forces-protocol@optimus.ietf.org; Fri, 07 May 2004 14:55: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 OAA12298 for ; Fri, 7 May 2004 14:55: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 1BMAUy-00009w-Cn for forces-protocol@ietf.org; Fri, 07 May 2004 14:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAU5-0007WY-00 for forces-protocol@ietf.org; Fri, 07 May 2004 14:54: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 1BMATC-000759-00 for forces-protocol@ietf.org; Fri, 07 May 2004 14:53:14 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004050711565999:10212 ; Fri, 7 May 2004 11:56:59 -0700 Subject: Re: [Forces-protocol] Summary : 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: <001c01c43437$cf65d6e0$875c21d2@Necom.hzic.edu.cn> References: <409A5679.8050501@zurich.ibm.com> <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> <409B5792.9080808@zurich.ibm.com> <1083933541.1036.42.camel@jzny.localdomain> <001c01c43437$cf65d6e0$875c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1083955989.1612.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 05/07/2004 11:57:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/07/2004 11:57:02 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 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: 07 May 2004 14:53: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=1.1 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2VpbWluZywNCg0KSSB0aGluayB0aGUgaWRlYSBpcyB2YWx1YWJsZS4gVGhlIHByb2JsZW0gaXMg dGhlIGJyb2FkIGRlZmluaXRpb24gb2YgYW4NCkxGQi4gSXMgdGhpcyAidGhpbmciIGFuIExGQj8g RXhhbXBsZSwgaXMgc29tZXRoaW5nIHRoYXQgb2ZmbG9hZHMgYQ0KcHJvdG9jb2wgYnV0IGRvZXMg aXRzIHdvcmsgaW4gdGhlIGNvbnRyb2wgQ1BVIChhbmQgbm90IG9uIHRoZSBkYXRhcGF0aCkNCnNh eSBvZiBhbiBGRSBmaXR0aW5nIHRvIGJlIGNhbGxlZCBhbiBMRkI/IFRha2UgYW4gZXhhbXBsZSBv ZiBhbiBPU1BGDQpvZmZsb2FkaW5nIG9mIGhlYXJ0YmVhdHMgdG8gYW4gRkUuIEl0IHdpbGwgbm90 IHJlc2lkZSBpbiB0aGUgZGF0YXBhdGgsDQpidXQgaXQgc3VyZSBnb3QgaXRzIG1ham9yIGNvbXBv bmVudCBpbiB0aGUgQ0UuIEFsbCBpdCBkb2VzIG9uIHRoZSBGRSBpcw0KcGVyaW9kaWNhbGx5IHNl bmQgaGVsbG8vaGVhcnRiZWF0cyBvdXQgdGhlIGludGVyZmFjZXMgaXQgd2FzIGNvbmZpZ3VyZWQN CnRvIGFuZCBteWFiZSBvbmNlIGluIGEgd2hpbGUgY29tcGxhaW4gYWJvdXQgaW5hY2Nlc3NpYmls aXR5IG9mIGNlcnRhaW4NCnJvdXRlcyBldGMuDQpOb3csIElmIHlvdSBjYW4gbW9kZWwgdGhlIE9T UEYgY29tcG9uZW50IGFzIGFuIExGQiB0aGVuIGkgYWdyZWUgd2l0aA0KeW91LCB0aGlzICJ0aGlu ZyIgIGNvdWxkIGFsc28gYmUgbW9kZWxsZWQgYXMgYSBzcGVhY2lhbCBMRkIuDQoNCmNoZWVycywN CmphbWFsDQoNCg0KT24gRnJpLCAyMDA0LTA1LTA3IGF0IDA5OjMyLCBXYW5nLFdlaW1pbmcgd3Jv dGU6DQo+IEhpIEphbWFsLA0KPiANCj4gSSB0aGluayB0aGUgZm9jdXMgd2UgYXJlIGRpc2N1c3Np bmcgaXMgaWYgdGhlcmUgYXJlIHNvbWV0aGluZyB0aGF0IHNob3VkIGJlDQo+IG9wZXJhdGVkIHZp YSBGb3JDRVMgcHJvdG9jb2wsIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUsIGlzIG91dCBvZiB0aGUN Cj4gYWNjZXNzaWJpbGl0eSBvZiBMRkJzIGRlZmluZWQgYnkgRkUgbW9kZWwuIE5vdyB3ZSBjYW4g c2VlIHRoYXQgRkUgbW9kZWwgaGFzDQo+IG1haW5seSB0cmVhdGVkIExGQnMgYXMgdGhlIGVsZW1l bnRzIGZvciBmb3J3YXJkaW5nIHByb2Nlc3MsIHRoYXQgaXMsIHRoZXkgYXJlDQo+IG1haW5seSBh bG9uZyB0aGUgcGFja2V0IGRhdGFwYXRoZXMgKGF0IGxlYXN0IG9uZSBkYXRhcGF0aGVzIGluIG9y IG91dCBvZiBpdCkuIEkNCj4ganVzdCBhIGxpdHRsZSB3b3JyeSBpZiBhbiBMRkIgbGlrZSBhIGhl YXJ0YmVhdCBnZW5lcmF0b3IgY2FuIGJlIGluY2x1ZGVkIGluLg0KPiBNb3Jlb3ZlciwgZXZlbiBp ZiAgaGVhcnRiZWF0IGNhbiBiZSB0cmVhdGVkIGFzIGEgTEZCLCB3ZSBzdGlsbCBoYXZlIG1hbnkg bGVmdCBhcw0KPiBJIG1lbnRpb25lZCBiZWxvdy4gSSBhZ3JlZSB0aGF0IHRvIGRlZmluZSB0aGUg J3RoaW5nJyBtYXkgbm90IHJlZHVjZSBtc2cgbnVtYmVyLg0KPiBNeSBtYWluIGlkZWEgaXMgd2hl dGhlciB3ZSBzcGVjaWZpY2FsbHkgZGlzdGluZ3Vpc2ggdGhlICd0aGluZycsIGl0IGV4aXN0cyBp bg0KPiBvdXIgcHJvdG9jb2wuIE9yLCBmcm9tIG90aGVyIHBlcnNwZWN0aXZlLCBJIGp1c3Qgd2Fu dCB0byBzYXkgdGhhdCB3ZSBtYXkgbmVlZCB0bw0KPiBkZWZpbmUgc29tZSBGRSBhdHRyaWJ1dGVz LCBjYXBhYmlsaXRpZXMsIGFuZCBldmVudHMgYnkgb3Vyc2V2ZXMgaW4gb3VyIEZvckNFUw0KPiBw cm90b2NvbCwgd2hpY2ggd2UgbWF5IG5vdCByZWx5IG9uIEZFIG1vZGVsIHRvIGRlZmluZS4NCj4g DQo+IEJSDQo+IFdlaW1pbmcNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9t OiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQo+IA0KPiA+IFJvYmVydC9XZWlt aW5nLA0KPiA+DQo+ID4gSSBhcG9sb2dpemUgZm9yIGFjdHVhbGx5IG5vdCBzYXlpbmcgYW55dGhp bmcgb24gdGhpcyBzdWJqZWN0Lg0KPiA+IEluaXRpYWxseSBpIHdhcyBjb25mdXNlZCA7LT4NCj4g Pg0KPiA+IEkgdGhpbmsgdGhlICJ0aGluZyIgeW91IGFyZSBkZXNjcmliaW5nIGFkZHMgdmFsdWUs IHRoZSBwcm9ibGVtIGlzDQo+ID4gd2hldGhlciBpdCBzaG91bGQgYmUgY2FsbGVkIGFuIExGQiwg TEZCLXdhbm5hYmUsIEZFLW1hbmFnZXIuIFRvIGJlDQo+ID4gaG9uZXN0IGl0IGlzIGFsbW9zdCBs aWtlIGFuIGltcGxlbWVudGF0aW9uIGxldmVsIGFyY2hpdGVjdHVyZSBkZXRhaWwuIEkNCj4gPiBh bHNvIGRvbnQgc2VlIGhvdyB5b3UgY2FuIHJlZHVjZSB0aGUgbnVtYmVyIG9mIG1lc3NhZ2UgdHlw ZXMuIEZvcg0KPiA+IGV4YW1wbGUsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB0YXJnZXQgaGVh cmJlYXRzIHRvIGFueSBMRkIgbm90IGp1c3QNCj4gPiB0byB0aGlzICJ0aGluZyIuDQo+ID4gQXJl IHlvdSBzdWdnZXN0aW5nIGl0IGlzIGEgIm11eGVyIiBvZiBhbGwgaGVhcnRiZWF0cyBldGM/DQo+ ID4NCj4gPiBJIGFtIG5vdCBhZ2FpbnN0IGl0LCBpIHRoaW5rIGl0IHdpbGwgZWFzZSB0aGUgaW1w bGVtZW50YXRpb25zOyBpIGFtIGp1c3QNCj4gPiB0cnlpbmcgdG8gZm9ybXVsYXRlIGl0cyBuZWVk IGluIG15IGhlYWQuDQo+ID4NCj4gPiBjaGVlcnMsDQo+ID4gamFtYWwNCj4gPg0KPiA+IE9uIEZy aSwgMjAwNC0wNS0wNyBhdCAwNTozMiwgUm9iZXJ0IEhhYXMgd3JvdGU6DQo+ID4gPiBXZWltaW5n LA0KPiA+ID4gWWVzLCBJIHRoaW5rIHdlIGhhdmUgdmVyeSBtdWNoIHRoZSBzYW1lIHZpZXcgb24g dGhpcyBpc3N1ZS4gSSBjYWxsZWQNCj4gPiA+IGl0IEZFIExGQiBiZWNhdXNlIGZyb20gYSBwcm90 b2NvbCBwb2ludCBvZiB2aWV3LCBzZXR0aW5nIEZFIGF0dHJpYnV0ZXMNCj4gPiA+IChhbmQgb3Ro ZXIgb3BlcmF0aW9ucykgd2lsbCBiZSBkb25lIHRoZSBzYW1lIHdheSBhcyB0byBhbnkgb3RoZXIN Cj4gPiA+IChyZWFsKSBMRkIuIEhvcm11emQgcG9pbnRlZCBvdXQgdGhhdCB0aGUgbW9kZWwgdGVh bSBjb3VsZCB0YWtlIG92ZXINCj4gPiA+IHRoZSBkZWZpbml0aW9uIG9mIHRoaXMgcGFydGljdWxh ciBGRSBMRkIuIEkgdGhpbmsgaXQgc2hvdWxkIG5vdC4gV2hpbGUNCj4gPiA+IHRoZSBtb2RlbCB0 ZWFtIGNhbiBkZWZpbmUgdGhlIGdlbmVyYWwgc3RydWN0dXJlIG9mIExGQnMsIHdlJ2xsIGhhdmUg dG8NCj4gPiA+IGZpbGwgdGhlIEZFIExGQiB3aXRoIGNvbnRlbnQsIGkuZS4sIGRlZmluZSB0aGUg ZXZlbnRzIGFuZCBhdHRyaWJ1dGVzDQo+ID4gPiBvZiBpbnRlcmVzdCB0byBydW4gdGhlIEZvckNF UyBwcm90b2NvbC4gVGhlIGxpc3QgeW91IGhhdmUgcHV0IHVwDQo+ID4gPiBhbHJlYWR5IHNlZW1z IHZlcnkgcmVhc29uYWJsZSB0byBtZS4NCj4gPiA+DQo+ID4gPiBJIGhvcGUgdGhhdCBieSBkZWZp bmluZyBzdWNoIGFuIEZFIExGQiB3ZSBjYW4gbGltaXQgdGhlIGFtb3VudCBvZg0KPiA+ID4gbWVz c2FnZSB0eXBlcyB0aGF0IG11c3QgYmUgZGVmaW5lZCBmb3IgdGhlIEZvckNFUyBwcm90b2NvbC4N Cj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4gLVJvYmVydA0KPiA+ID4NCj4gPiA+IFdlaW1p bmcgV2FuZyB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gSGkgUm9iZXJ0LCBhbmQgYWxsLA0KPiA+ ID4gPg0KPiA+ID4gPiBJJ20gdmVyeSBnbGFkIHRoYXQgeW91ciBpZGVhIG9mIEZFIExGQiBtYXkg cXVpdGUgbWVldCB3aXRoIG15IGlkZWENCj4gPiA+ID4gYW55d2F5LiBBY3R1YWxseSBJIGNhbGxl ZCBpdCAnRkUgU2xhdmUnIGluc3RlYWQgb2YgRkUgTEZCLiBJIHRoaW5rDQo+ID4gPiA+IGJvdGgg b2YgdXMgdGhpbmsgb2YgdGhpcyBlbnRpdHkgYmVjYXVzZSB3ZSBoYXZlIHJlYWxpemVkIHRoYXQg bWFueQ0KPiA+ID4gPiBvZiB0aGUgZnVuY3Rpb25zIGluIEZFIGFyZSBhY3R1YWxseSBiZXlvbmQg dGhlIHNjb3BlIG9mIExGQnMgZGVmaW5lZA0KPiA+ID4gPiBieSBGRSBtb2RlbHMuIFRoZXNlIGZ1 bmN0aW9ucyBjYW4gYWxzbyBiZSBkZXNjcmliZWQgYnkgdXNpbmcgbm90aW9ucw0KPiA+ID4gPiBz dWNoIGFzIGF0dGlidXRlcywgZXZlbnRzLCBjYXBhYmlsaXRlcywgYW5kIHN0YXRlcyhVUC9Eb3du KS4gQmVjYXVzZQ0KPiA+ID4gPiB0aGVzZSBub3Rpb25zIGhlcmUgYXJlIG1haW5seSBlZmZlY3Rp dmUgZm9yIHdob2xlIEZFICh0aGF0IGlzLCB0YWtlDQo+ID4gPiA+IHdob2UgRkUgKGF0IGEgY29h cnNlIGxheWVyKSBhcyBhIG1hbmFnZWQgZW50aXR5KSwgaW4gbXkgc2NoZW1lLCB3ZQ0KPiA+ID4g PiBqdXN0IGNhbGwgdGhlbiBGRSBhdHRyaWJ1dGVzLCBGRSBldmVudHMsIGFuZCBGRSBjYXBhYmls aXRpZXMsIHdoaWNoDQo+ID4gPiA+IGFyZSBkaXNjcmltaW5hdGVkIGZyb20gTEZCIGF0dHJpYnV0 ZXMsIExGQiBldmVudHMsIGFuZCBMRkINCj4gPiA+ID4gY2FwYWJpbGl0aWVzLg0KPiA+ID4gPg0K PiA+ID4gPiBJJ2QgbGlrZSB0byBzaG93IHNvbWUgb2YgdGhlIGNvbnRlbnRzIHRvIHNlZSBpZiB0 aGV5IG1lZXQgeW91cg0KPiA+ID4gPiB0aG91Z2h0czoNCj4gPiA+ID4gRm9yIEZFIGV2ZW50cywg d2UgbWF5IGhhdmU6DQo+ID4gPiA+IC5GRSBzdGF0ZSBldmVudHMgKEZFIFVwL0Rvd24vQWN0aXZl L0luYWN0aXZlL0ZhaWxvdmVyKQ0KPiA+ID4gPiAuRkUgaGVhcnRiZWF0DQo+ID4gPiA+IC5GRSBE b1MgYWxlcnQNCj4gPiA+ID4gLkZFIGNhcGFiaWxpdHkgY2hhbmdlDQo+ID4gPiA+IC5GRSBUTUwg ZXZlbnRzDQo+ID4gPiA+DQo+ID4gPiA+IEZvciBGRSBjYXBhYmlsaXR5LCB3ZSBtYXkgaGF2ZQ0K PiA+ID4gPiAuQ3VycmVudGx5IHN1cHBvcnRlZCBGb3JDRVMgcHJvdG9jb2wgdmVyc2lvbiBieSB0 aGUgRkUNCj4gPiA+ID4gLkN1cnJlbnRseSBzdXBwb3J0ZWQgRm9yQ0VTIEZFIG1vZGVsIGJ5IHRo ZSBGRQ0KPiA+ID4gPiAuU29tZSBUTUwgY2FwYWJpbGl0eSBkZXNjcmlwdGlvbg0KPiA+ID4gPg0K PiA+ID4gPiBGZSBGRSBhdHRyaWJ1dGVzLCB2aWEgd2hpY2ggd2UgbWF5IGFibGUgdG8gZG86DQo+ ID4gPiA+IC4gVG8gc2V0dXAgb3IgbmVnb3RpYXRlIGEgdmVyc2lvbiBvZiBGRSBtb2RlbCBvciB0 aGUgRm9yQ0VTIHByb3RvY29sDQo+ID4gPiA+IC4gVG8gc2V0dXAgbWFueSBwb2xpY2llcyBmb3Ig dGhlIEZFLCBmb3Igd2hpY2ggRkUgbW9kZWwgaXMgbm90IGFibGUNCj4gPiA+ID4gdG8gZG8gKG91 dCBvZiBpdHMgc2NvcGUpLCBlLmcuLA0KPiA+ID4gPiAgIC0gRkUgZmFpbG92ZXIgYW5kIHJlc3Rh cnQgcG9saWN5IChzdWNoIGFzIGdyYWNlZnVsIHJlc3RhcnQgb3Igbm90KQ0KPiA+ID4gPiAgIC0g RkUgaGVhcnRiZWF0IHBvbGljeSAoc3VjaCBhcyB0aGUgaW50ZXJ2YWxzIGZvciB0aGUgaGVhcnRi ZWF0LA0KPiA+ID4gPiBldGMpDQo+ID4gPiA+DQo+ID4gPiA+IC4gRkUgZXZlbnRzIHN1YnNjcmli ZS91bnN1YnNjcmliZSAoaW5jbHVkaW5nIHRvIHN0YXJ0IG9yIHN0b3ANCj4gPiA+ID4gaGVhcnRi ZWF0cykNCj4gPiA+ID4gLiBmb3IgVE1MIG1hbmFnZW1lbnQgaWYgbmVlZGVkLg0KPiA+ID4gPg0K PiA+ID4gPiBBbnl3YXksIGFueSBtYW5hZ2VtZW50IHRoYXQgaXMgb3V0IG9mIHRoZSBzY29wZSBv ZiBGRSBtb2RlbCBjYW4gYmUNCj4gPiA+ID4gcHV0IGluIHRoZSBGRSBMRkIvIEZFIHNsYXZlIGVu dGl0eS4gVGhhdCBpcyBJIHRoaW5rIG91ciBpZGVhLCBpcyBpdA0KPiA+ID4gPiByaWdodD8NCj4g PiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBXZWltaW5nDQo+ID4gPiA+DQo+ID4gPiA+ IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID4gICAgICAgICBGcm9tOiBSb2Jl cnQgSGFhcw0KPiA+ID4gPiAgICAgICAgIFRvOiBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCj4g PiA+ID4gICAgICAgICBTZW50OiBUaHVyc2RheSwgTWF5IDA2LCAyMDA0IDExOjE1IFBNDQo+ID4g PiA+ICAgICAgICAgU3ViamVjdDogW0Z3ZDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFN1bW1hcnkg OiBQcm90b2NvbA0KPiA+ID4gPiAgICAgICAgIE1lc3NhZ2VzOiB0b3BpYyAzICYgNGFdDQo+ID4g PiA+DQo+ID4gPiA+ICAgICAgICAgTWF5YmUgbXkgbGFzdCBtZXNzYWdlIG9uIHRoYXQgdG9waWMg d2VudCB1bm5vdGljZWQsIHNvIEkNCj4gPiA+ID4gICAgICAgICB3YW50ZWQgdG8gYWdhaW4gc3Ry ZXNzIHRoZSBwb3NzaWJpbGl0eSB0byBjcmVhdGUgYW4gRkUgTEZCDQo+ID4gPiA+ICAgICAgICAg KGNhbGwgaXQgbWV0YSBMRkIsIGNvbnRyb2wgTEZCLCBldGMpIHRoYXQgY2FuIGJlIGNvbmZpZ3Vy ZWQsDQo+ID4gPiA+ICAgICAgICAgZXZlbnRzIGNhbiBiZSBzdWJzY3JpYmVkIHRvLCBldGMuIFRo ZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlDQo+ID4gPiA+ICAgICAgICAgRkUgTEZCIGFuZCB0aGUg b3RoZXIgInJlZ3VsYXIiIExGQnMgaXMgdGhhdCBubyBkYXRhIHBhY2tldA0KPiA+ID4gPiAgICAg ICAgIHRyYXZlcnNlcyB0aGUgRkUgTEZCLiBUaGUgcHVycG9zZSBvZiB0aGUgRkUgTEZCIGlzIHRv DQo+ID4gPiA+ICAgICAgICAgZmFjaWxpdGF0ZSB0aGUgY29udHJvbCBvZiB0aGUgRkU6DQo+ID4g PiA+DQo+ID4gPiA+ICAgICAgICAgRXhhbXBsZXM6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAg LSBGRSBVUCBhbmQgRE9XTiBkb24ndCBuZWVkIHRvIGJlIHNwZWNpYWwgRm9yQ0VTIG1lc3NhZ2Vz Lg0KPiA+ID4gPiAgICAgICAgIEluc3RlYWQsIHRoZXkgY2FuIGJlIGV2ZW50cyBvcmlnaW5hdGVk IGJ5IHRoZSBGRSBMRkIuDQo+ID4gPiA+ICAgICAgICAgLSBDb25maWd1cmluZyB0aGUgaW50ZXJ2 YWwgdGltZXIgZm9yIGhlYXJ0YmVhdHMgbWVzc2FnZXMgY2FuDQo+ID4gPiA+ICAgICAgICAgYmUg ZG9uZSB1c2luZyBhIENvbmZpZyBtZXNzYWdlIHRvIHRoZSBoZWFyYmVhdCBpbnRlcnZhbA0KPiA+ ID4gPiAgICAgICAgIGF0dHJpYnV0ZSBvZiB0aGUgRkUgTEZCLg0KPiA+ID4gPg0KPiA+ID4gPiAg ICAgICAgIFRoZSByZWFzb24gdG8gaW50cm9kdWNlIHRoaXMgTEZCIHZlcnN1cyBjcmVhdGluZyBz cGVjaWZpYw0KPiA+ID4gPiAgICAgICAgIEZvckNFUyBtZXNzYWdlcyBpcyBmbGV4aWJpbGl0eTog YXQgc29tZSBwb2ludCBpbiB0aW1lLCBpZiB3ZQ0KPiA+ID4gPiAgICAgICAgIG5lZWQgdG8gZW5o YW5jZSB0aGUgRm9yQ0VTIHByb3RvY29sLCB3ZSBkb24ndCBuZWNlc3NhcmlseQ0KPiA+ID4gPiAg ICAgICAgIG5lZWQgdG8gY2hhbmdlIHRoZSBwcm90b2NvbCBpdHNlbGYuIEluc3RlYWQsIHdlIGNh biBjcmVhdGUgYQ0KPiA+ID4gPiAgICAgICAgIG5ldyB2ZXJzaW9uIG9mIHRoZSBGRSBMRkIgdGhh dCBzdXBwb3J0cyBuZXcgZmVhdHVyZXMuDQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgSSdkIGxp a2UgdG8gaGF2ZSB5b3VyIGNvbW1lbnRzIG9uIHN1Y2ggYW4gRkUgTEZCLg0KPiA+ID4gPg0KPiA+ ID4gPiAgICAgICAgIFJlZ2FyZHMsDQo+ID4gPiA+ICAgICAgICAgLVJvYmVydA0KPiA+ID4gPg0K PiA+ID4NCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ID4gUm9iZXJ0IEhhYXMNCj4gPiA+IElCTSBadXJp Y2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KPiA+ID4gU+R1bWVyc3RyYXNzZSA0DQo+ID4gPiBDSC04 ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gPiA+IHBob25lICs0MS0xLTcyNC04Njk4ICBm YXggKzQxLTEtNzI0LTg1NzggIGh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYQ0KPiA+DQo+ ID4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPiBGb3JjZXMtcHJvdG9j b2xAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9y Y2VzLXByb3RvY29sDQoNCg== _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat May 8 00:39:15 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 AAA11646 for ; Sat, 8 May 2004 00:39: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 1BMJY6-0007Ga-SC for forces-protocol-archive@odin.ietf.org; Sat, 08 May 2004 00:34:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i484YsIw027932 for forces-protocol-archive@odin.ietf.org; Sat, 8 May 2004 00:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMJWm-0006uu-09 for forces-protocol-web-archive@optimus.ietf.org; Sat, 08 May 2004 00: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 AAA11494 for ; Sat, 8 May 2004 00:33: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 1BMJWj-0007EF-8t for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:33:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMJVo-0006oA-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:32:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMJVO-0006OH-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMJQT-0005X6-Nf; Sat, 08 May 2004 00: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 1BMJMc-0004dd-Kp for forces-protocol@optimus.ietf.org; Sat, 08 May 2004 00:23: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 AAA10829 for ; Sat, 8 May 2004 00:22: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 1BMJMa-0002ju-06 for forces-protocol@ietf.org; Sat, 08 May 2004 00:23:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMJJX-0001mp-00 for forces-protocol@ietf.org; Sat, 08 May 2004 00:19:53 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BMJH8-0000Xp-00 for forces-protocol@ietf.org; Sat, 08 May 2004 00:17:44 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 8 May 2004 12:29:30 +0800 Message-ID: <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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: Sat, 8 May 2004 12:13: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 Jamal, Thank you for the post, which makes thing much clearer. ----- Original Message ----- From: "Jamal Hadi Salim" > > > Ok, I just deleted everything that was said and i am going to summarize > with a twist of my opinions. (I hope i read all the discussions > correctly). Robert/Weiming please double check. Hopefully, this summary > will allow other people to pitch in. > > Why do we batch? > 1) to pipeline and improve throughput > 2) to achieve atomic operations spanning multiple packets. > > Note that #1 may not be necessarily be atomic operation. > [Weiming]Agreed. Then you mean batch is for 1) or 1)AND 2), right? How about just for 2) then, it will not be called batching? > PL message/transaction exceeding MTU: > I think the PL should carefully ensure that the messages going across > are each at least going to fit in the MTU size packet. I think if we can > avoid fragmentation of a command, then we should. > [Weiming]I just a little worry if the pipeline and the MTU requirement will have some contradiction with each other. > Types of batching: > > 1) several PL messages in one TML level PDU. PL level header SOT and EOT > indicate start and end of a train of these messages. > Is this responsibility of TML or PL to put them in one PDU or that of > PL? I feel it is the responsibility of PL. > [Weiming] I also incline for PL to define the pinelining format. Then, we need to have a batch format (not necessarily a batch msg) to be defined in the protocol text. Where do you think to put it, in the protocol overviw, common header, or in the protocol messages? [/Weiming] > 2) Within one message several TLVs which require that each "atomic" unit > have its own subsequence number (and treat the top header sequence > number as a flat transaction number). > [Weiming]In this case, we need to define a batching msg, which I think should be defined by protocol msgs. > My preference is using #1 mostly because now we have to look for a trick > to stash a subsequence number. too complex. You can already pack many > routes for example in one message - so no need to be clever. > Each message will have a unique sequence number. Start of transaction > gets marked by SoT and end of transaction gets marked by EoT. And any > middle messages probably marked with MoT? [Weiming]Can we summarize that we may need two flags, one for atomicity, and another for pipelining batch? > Weiming points to a concern about the common header introducing > ovrehead. My opinion is the overhead is so small that it is irrelevant > against the benefits of keeping track of subsequence numbers. [Weiming]Actually I more inclide to #1 also (pls see my previous reply to robert), with the same idea that the header may waste less. Note that in TLV mode (#2 mode), we also have to have many in the TLV, such as ACK flag, subsequece number, etc. Actually I was trying to propose another approach other than #1 and #2, which is mainly for atomicity. The approach is to let a bunch of msgs that need atomicity still be separatedly sent via TML instead of pipelining, while only using the Atomic flag to trace the start and the end of atomiciy. Do you think we need this? Moreover, I was considering how we can support multipul atomicity transactions in this case. [/Weiming] > > What to do in case of failures? > Lets say you sent an atomic batch of A) a del route, B) an add route and > C) add route > > Techniques (listed by Joel Halpern once). > > 1) All or nothing: > if B fails A should also fail; if A was done then you undo [Weiming]My understanding of atomicity is just for this. > > 2) Fail upto: > If B fails but A passes, then we just inform CE of Bs failure and dont > execute C. [Weiming]I'm afraid this fail model may only apply to batching msg(s). > 3) I cant remember it, but i think there was a third technique > [Weiming]Is it the most general one, that is, to do whatever it can do, and fail whatever it cannt do? > I think the most interesting this is what happens if FE1 executes A > successfuly and FE2 both A and B but not C. You need to make sure things > are synchronized [Weiming]I think in broadcast case, we may have to choose to use a simple fail scheme such as all or nothing, or else, I'm just afraid it may make things much complex. > > I hope i summarized everuthing that was said. > > 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 Sat May 8 00:54:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12031 for ; Sat, 8 May 2004 00:54:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMJpb-0002SM-Mp for forces-protocol-archive@odin.ietf.org; Sat, 08 May 2004 00:53:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i484qx6p009438 for forces-protocol-archive@odin.ietf.org; Sat, 8 May 2004 00:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMJlI-0001q5-Ua for forces-protocol-web-archive@optimus.ietf.org; Sat, 08 May 2004 00:48: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 AAA11881 for ; Sat, 8 May 2004 00:48: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 1BMJlG-0005eg-3S for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:48:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMJkI-0005Eu-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:47:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMJjh-0004p2-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 00:46:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMJfx-0000fX-Ui; Sat, 08 May 2004 00: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 1BMJdQ-0008Ut-E9 for forces-protocol@optimus.ietf.org; Sat, 08 May 2004 00:40: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 AAA11682 for ; Sat, 8 May 2004 00:40: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 1BMJdN-0002M4-NT for forces-protocol@ietf.org; Sat, 08 May 2004 00:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMJcR-0001xF-00 for forces-protocol@ietf.org; Sat, 08 May 2004 00:39:24 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BMJba-0001Sd-00 for forces-protocol@ietf.org; Sat, 08 May 2004 00:38:31 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 8 May 2004 12:51:03 +0800 Message-ID: <006801c434b5$c40085b0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <409A5679.8050501@zurich.ibm.com> <00ea01c433e7$66cd9eb0$020aa8c0@wwm1> <409B5792.9080808@zurich.ibm.com> <1083933541.1036.42.camel@jzny.localdomain> <001c01c43437$cf65d6e0$875c21d2@Necom.hzic.edu.cn> <1083955989.1612.60.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Summary : 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: Sat, 8 May 2004 12:34: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=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, I'm afraid our discussion has come to the same point. Actually my idea is a little different from Robert's in that, i would not call the 'thing' a LFB, because many of its functions actually have to be ready there even before the ForCES protocol begin to run, e.g., the protocol version information, the TML capability. While for a LFB, I more think it should be lunched by our protocol, that is, should work only after the protocol core runs. I agree with Robert in that, we do have such a 'thing' in the protocol, which I'm afraid not included in our current protocol contents. The 'thing' has its attributes, capabilities, evnets, which we need to describe in our protocol text. To be more presie, I just think we need to define some attributes, capabilities, events by ourselves in our protocol, which can not be defined by FE model. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > > I think the idea is valuable. The problem is the broad definition of an > LFB. Is this "thing" an LFB? Example, is something that offloads a > protocol but does its work in the control CPU (and not on the datapath) > say of an FE fitting to be called an LFB? Take an example of an OSPF > offloading of heartbeats to an FE. It will not reside in the datapath, > but it sure got its major component in the CE. All it does on the FE is > periodically send hello/heartbeats out the interfaces it was configured > to and myabe once in a while complain about inaccessibility of certain > routes etc. > Now, If you can model the OSPF component as an LFB then i agree with > you, this "thing" could also be modelled as a speacial LFB. > > cheers, > jamal > > > On Fri, 2004-05-07 at 09:32, Wang,Weiming wrote: > > Hi Jamal, > > > > I think the focus we are discussing is if there are something that shoud be > > operated via ForCES protocol, while at the same time, is out of the > > accessibility of LFBs defined by FE model. Now we can see that FE model has > > mainly treated LFBs as the elements for forwarding process, that is, they are > > mainly along the packet datapathes (at least one datapathes in or out of it). I > > just a little worry if an LFB like a heartbeat generator can be included in. > > Moreover, even if heartbeat can be treated as a LFB, we still have many left as > > I mentioned below. I agree that to define the 'thing' may not reduce msg number. > > My main idea is whether we specifically distinguish the 'thing', it exists in > > our protocol. Or, from other perspective, I just want to say that we may need to > > define some FE attributes, capabilities, and events by ourseves in our ForCES > > protocol, which we may not rely on FE model to define. > > > > BR > > Weiming > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > Robert/Weiming, > > > > > > I apologize for actually not saying anything on this subject. > > > Initially i was confused ;-> > > > > > > I think the "thing" you are describing adds value, the problem is > > > whether it should be called an LFB, LFB-wannabe, FE-manager. To be > > > honest it is almost like an implementation level architecture detail. I > > > also dont see how you can reduce the number of message types. For > > > example, it should be possible to target hearbeats to any LFB not just > > > to this "thing". > > > Are you suggesting it is a "muxer" of all heartbeats etc? > > > > > > I am not against it, i think it will ease the implementations; i am just > > > trying to formulate its need in my head. > > > > > > cheers, > > > jamal > > > > > > On Fri, 2004-05-07 at 05:32, Robert Haas wrote: > > > > Weiming, > > > > Yes, I think we have very much the same view on this issue. I called > > > > it FE LFB because from a protocol point of view, setting FE attributes > > > > (and other operations) will be done the same way as to any other > > > > (real) LFB. Hormuzd pointed out that the model team could take over > > > > the definition of this particular FE LFB. I think it should not. While > > > > the model team can define the general structure of LFBs, we'll have to > > > > fill the FE LFB with content, i.e., define the events and attributes > > > > of interest to run the ForCES protocol. The list you have put up > > > > already seems very reasonable to me. > > > > > > > > I hope that by defining such an FE LFB we can limit the amount of > > > > message types that must be defined for the ForCES protocol. > > > > > > > > Regards, > > > > -Robert > > > > > > > > Weiming Wang wrote: > > > > > > > > > > Hi Robert, and all, > > > > > > > > > > I'm very glad that your idea of FE LFB may quite meet with my idea > > > > > anyway. Actually I called it 'FE Slave' instead of FE LFB. I think > > > > > both of us think of this entity because we have realized that many > > > > > of the functions in FE are actually beyond the scope of LFBs defined > > > > > by FE models. These functions can also be described by using notions > > > > > such as attibutes, events, capabilites, and states(UP/Down). Because > > > > > these notions here are mainly effective for whole FE (that is, take > > > > > whoe FE (at a coarse layer) as a managed entity), in my scheme, we > > > > > just call then FE attributes, FE events, and FE capabilities, which > > > > > are discriminated from LFB attributes, LFB events, and LFB > > > > > capabilities. > > > > > > > > > > I'd like to show some of the contents to see if they meet your > > > > > thoughts: > > > > > For FE events, we may have: > > > > > .FE state events (FE Up/Down/Active/Inactive/Failover) > > > > > .FE heartbeat > > > > > .FE DoS alert > > > > > .FE capability change > > > > > .FE TML events > > > > > > > > > > For FE capability, we may have > > > > > .Currently supported ForCES protocol version by the FE > > > > > .Currently supported ForCES FE model by the FE > > > > > .Some TML capability description > > > > > > > > > > Fe FE attributes, via which we may able to do: > > > > > . To setup or negotiate a version of FE model or the ForCES protocol > > > > > . To setup many policies for the FE, for which FE model is not able > > > > > to do (out of its scope), e.g., > > > > > - FE failover and restart policy (such as graceful restart or not) > > > > > - FE heartbeat policy (such as the intervals for the heartbeat, > > > > > etc) > > > > > > > > > > . FE events subscribe/unsubscribe (including to start or stop > > > > > heartbeats) > > > > > . for TML management if needed. > > > > > > > > > > Anyway, any management that is out of the scope of FE model can be > > > > > put in the FE LFB/ FE slave entity. That is I think our idea, is it > > > > > right? > > > > > > > > > > Cheers, > > > > > Weiming > > > > > > > > > > ----- Original Message ----- > > > > > From: Robert Haas > > > > > To: forces-protocol@ietf.org > > > > > Sent: Thursday, May 06, 2004 11:15 PM > > > > > Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol > > > > > Messages: topic 3 & 4a] > > > > > > > > > > Maybe my last message on that topic went unnoticed, so I > > > > > wanted to again stress the possibility to create an FE LFB > > > > > (call it meta LFB, control LFB, etc) that can be configured, > > > > > events can be subscribed to, etc. The difference between the > > > > > FE LFB and the other "regular" LFBs is that no data packet > > > > > traverses the FE LFB. The purpose of the FE LFB is to > > > > > facilitate the control of the FE: > > > > > > > > > > Examples: > > > > > > > > > > - FE UP and DOWN don't need to be special ForCES messages. > > > > > Instead, they can be events originated by the FE LFB. > > > > > - Configuring the interval timer for heartbeats messages can > > > > > be done using a Config message to the hearbeat interval > > > > > attribute of the FE LFB. > > > > > > > > > > The reason to introduce this LFB versus creating specific > > > > > ForCES messages is flexibility: at some point in time, if we > > > > > need to enhance the ForCES protocol, we don't necessarily > > > > > need to change the protocol itself. Instead, we can create a > > > > > new version of the FE LFB that supports new features. > > > > > > > > > > I'd like to have your comments on such an FE LFB. > > > > > > > > > > Regards, > > > > > -Robert > > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > _______________________________________________ > > 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 Sat May 8 09:21:55 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 JAA01585 for ; Sat, 8 May 2004 09:21: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 1BMRkk-0000R0-3I for forces-protocol-archive@odin.ietf.org; Sat, 08 May 2004 09:20:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i48DKUbR001665 for forces-protocol-archive@odin.ietf.org; Sat, 8 May 2004 09:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMRk2-0000KP-Qx for forces-protocol-web-archive@optimus.ietf.org; Sat, 08 May 2004 09:19: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 JAA01496 for ; Sat, 8 May 2004 09:19: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 1BMRk1-0002Ju-8Z for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 09:19:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMRj6-0001wV-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 09:18:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMRi6-0001Yb-00 for forces-protocol-web-archive@ietf.org; Sat, 08 May 2004 09:17:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMRfQ-0008Ix-W5; Sat, 08 May 2004 09: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 1BMRdH-00086r-2t for forces-protocol@optimus.ietf.org; Sat, 08 May 2004 09:12: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 JAA01372 for ; Sat, 8 May 2004 09:12:44 -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 1BMRdF-0007S9-Hu for forces-protocol@ietf.org; Sat, 08 May 2004 09:12:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMRcK-00074e-00 for forces-protocol@ietf.org; Sat, 08 May 2004 09:11:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BMRbY-0006gr-00 for forces-protocol@ietf.org; Sat, 08 May 2004 09:11:00 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMRbX-000NVB-Jl for forces-protocol@ietf.org; Sat, 08 May 2004 13:10:59 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1083955505.1598.50.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <24D96F5C-A0F1-11D8-9E89-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 8 May 2004 15:10:57 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 7 maj 2004, at 20.45, Jamal Hadi Salim wrote: > > > Ok, I just deleted everything that was said and i am going to summarize > with a twist of my opinions. (I hope i read all the discussions > correctly). Robert/Weiming please double check. Hopefully, this summary > will allow other people to pitch in. > > Why do we batch? > 1) to pipeline and improve throughput > 2) to achieve atomic operations spanning multiple packets. > > Note that #1 may not be necessarily be atomic operation. > > PL message/transaction exceeding MTU: > I think the PL should carefully ensure that the messages going across > are each at least going to fit in the MTU size packet. I think if we > can > avoid fragmentation of a command, then we should. Yes, in fact some sort of MTU discovery might be in order. I think avoiding fragmentation is of positive value. This is probably a TML responsibility. > > Types of batching: > > 1) several PL messages in one TML level PDU. PL level header SOT and > EOT > indicate start and end of a train of these messages. > Is this responsibility of TML or PL to put them in one PDU or that of > PL? I feel it is the responsibility of PL. Well it sort of depends on which entity is responsible for non-fragmentations and hence knowing what MTU size to use. It is certainly the PL's responsibility to know which msgs are batched and especially which are atomically batched. > > 2) Within one message several TLVs which require that each "atomic" > unit > have its own subsequence number (and treat the top header sequence > number as a flat transaction number). > > My preference is using #1 mostly because now we have to look for a > trick > to stash a subsequence number. too complex. You can already pack many > routes for example in one message - so no need to be clever. > Each message will have a unique sequence number. Start of transaction > gets marked by SoT and end of transaction gets marked by EoT. And any > middle messages probably marked with MoT? > Weiming points to a concern about the common header introducing > ovrehead. My opinion is the overhead is so small that it is irrelevant > against the benefits of keeping track of subsequence numbers. > > What to do in case of failures? > Lets say you sent an atomic batch of A) a del route, B) an add route > and > C) add route > > Techniques (listed by Joel Halpern once). > > 1) All or nothing: > if B fails A should also fail; if A was done then you undo > > 2) Fail upto: > If B fails but A passes, then we just inform CE of Bs failure and dont > execute C. > > 3) I cant remember it, but i think there was a third technique > > > I think the most interesting this is what happens if FE1 executes A > successfuly and FE2 both A and B but not C. You need to make sure > things > are synchronized when I think of the two kinds of batching, atomic and non, I make the distinction that in non-atomic, each goes on and you get a separate ack/error code back on each of the component messages. With atomic, I tend to support option 1 above. Option 2, the do until fail, would seem to me to be a different sort of batching and I am not sure how useful, or safe, a variant it is. > > I hope i summarized everuthing that was said. I like the summaries. I get confused in the back and forth conversations and don't really know how to jump in with a response. So thanks. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 9 02:50:48 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 CAA19967 for ; Sun, 9 May 2004 02:50: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 1BMi6o-0001Kc-3D for forces-protocol-archive@odin.ietf.org; Sun, 09 May 2004 02:48:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i496mMY8005119 for forces-protocol-archive@odin.ietf.org; Sun, 9 May 2004 02:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMi3E-0000p4-Qo for forces-protocol-web-archive@optimus.ietf.org; Sun, 09 May 2004 02:44: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 CAA19717 for ; Sun, 9 May 2004 02:44: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 1BMi3B-0004eq-8X for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 02:44:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMi26-0004EE-00 for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 02:43:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMi17-0002ue-01 for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 02:42:30 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BMhqt-0004Q0-M4 for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 02:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMhp7-0007LU-D8; Sun, 09 May 2004 02:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMhjk-0005ge-Ci for forces-protocol@optimus.ietf.org; Sun, 09 May 2004 02:24: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 CAA12491 for ; Sun, 9 May 2004 02:24: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 1BMhjg-0004s1-6t for forces-protocol@ietf.org; Sun, 09 May 2004 02:24:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMhim-0004Vh-00 for forces-protocol@ietf.org; Sun, 09 May 2004 02:23:32 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BMhi3-000499-00 for forces-protocol@ietf.org; Sun, 09 May 2004 02:22:51 -0400 Received: from dlg (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 9 May 2004 14:35:27 +0800 Message-ID: <001101c4358d$aa4a3f70$8401a8c0@dlg> From: "Ligang Dong" To: References: <468F3FDA28AA87429AD807992E22D07EDD5CDE@orsmsx408.jf.intel.com> <1083634737.1039.14.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Timeline - we need to start writing sections for the draft soon. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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, 9 May 2004 14:20: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=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aGksIA0KDQpJICB3b3VsZCBsaWtlIHRvIGF0dGVuZCB0aGUgd3JpdGluZyBvZiBDb21tb24gSGVh ZGVyICh0b2dldGhlciB3aXRoIEphbWFsIEhhZGkgU2FsaW0sIFdlaW1pbmcgV2FuZywgYW5kIFJv YmVydCBIYWFzKSBhbmQgUHJvdG9jb2wgTWVzc2FnZXMgKHRvZ2V0aGVyIHdpdGggSG9ybXV6ZCBL aG9zcmF2aSBhbmQgV2VpbWluZyBXYW5nKS4NCmJlc3QgcmVnYXJkcw0KTGlnYW5nDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8YXZyaUBhY20ub3JnPg0KVG86IDxmb3Jj ZXMtcHJvdG9jb2xAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXkgMDQsIDIwMDQgMzowMSBQ TQ0KU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFRpbWVsaW5lIC0gd2UgbmVlZCB0byBz dGFydCB3cml0aW5nIHNlY3Rpb25zIGZvciB0aGUgZHJhZnQgc29vbi4NCg0KDQo+IA0KPiBPbiA0 IG1haiAyMDA0LCBhdCAwMy4zOCwgSmFtYWwgSGFkaSBTYWxpbSB3cm90ZToNCj4gDQo+ID4gSSB3 b3VsZCBzdHJvbmdseSByZWNvbW1lbmQgd2Ugc2NydWIgMi5hIGJlZm9yZSBtb3Zpbmcgb24uIEl0 cyBwcm9iYWJseQ0KPiA+IHRoZSBtb3N0IGNyaXRpY2FsIHBhcnQuIE5vIHJ1c2guIEkgd291bGQg cmF0aGVyIGJlIGxhdGUgdGhhbiBzb3JyeS4NCj4gPg0KPiANCj4gSSBhbSB3b25kZXJpbmcgd2hl dGhlciB0aGVyZSBtaWdodCBub3QgYmUgYSB1dGlsaXR5IGluIGhhdmluZyBhIA0KPiBjb25mZXJl bmNlIGNhbGwgYXQgc29tZSBwb2ludCB0byBydW4gdGhyb3VnaCBzb21lIG9mIHRoZSByZW1haW5p bmcgDQo+IGtub3RzLiAgVGhvdWdoIHdlIGFyZSBjb250aW5lbnRzIGFwYXJ0LCB0aGVyZSBhcmUg dGltZSB0aGF0IGFsbW9zdCB3b3JrIA0KPiB3aXRoIHRoZSBQYWNpZmljIFVTIGVhcmx5IGluIHRo ZSBBTSBhbmQgQ2hpbmEgbGF0ZSBhdCBuaWdodC4NCj4gDQo+IElmIHRoaXMgY2FsbCB3ZXJlIG1p bnV0ZWQgd2l0aCB0aGUgbWludXRlcyBzZW50IHRvIHRoaXMgbGlzdCBmb3IgDQo+IGFyY2hpdmFs IGFuZCBpbnNwZWN0aW9uLCBJIHRoaW5rIHdlIHdvdWxkIHN0aWxsIGJlIGZ1bmN0aW9uaW5nIHdp dGggdGhlIA0KPiByZXF1aXJlZCB2aXNpYmlsaXR5LiAgSSBhbSB3aWxsaW5nIHRvIGJlIHRoZSBt aW51dGUgdGFrZXIgYXMgSSBoYXZlIA0KPiBmZXdlciBzdHJvbmcgb3BpbmlvbnMgKHN0cmFuZ2Ug cG9zaXRpb24gZm9yIG1lIHRvIGJlIGluKSB0aGVuIHRoZSByZXN0IA0KPiBvZiB5b3UuDQo+IA0K PiBhLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEZvcmNlcy1wcm90b2NvbCBtYWlsaW5nIGxpc3QNCj4gRm9yY2VzLXByb3RvY29s QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNl cy1wcm90b2NvbA0KPiA= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 9 04:33: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 EAA23371 for ; Sun, 9 May 2004 04:33: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 1BMjiV-0004Gs-Al for forces-protocol-archive@odin.ietf.org; Sun, 09 May 2004 04:31:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i498VN4q016418 for forces-protocol-archive@odin.ietf.org; Sun, 9 May 2004 04:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjfm-00048U-Od for forces-protocol-web-archive@optimus.ietf.org; Sun, 09 May 2004 04:28: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 EAA23279 for ; Sun, 9 May 2004 04: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 1BMjfj-0003Ze-VT for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 04:28:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjer-0003EN-00 for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 04:27:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMjeR-0002ss-00 for forces-protocol-web-archive@ietf.org; Sun, 09 May 2004 04:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjdL-0003mw-0X; Sun, 09 May 2004 04:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjax-0003eE-6y for forces-protocol@optimus.ietf.org; Sun, 09 May 2004 04:23: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 EAA23168 for ; Sun, 9 May 2004 04:23: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 1BMjau-0001ng-7v for forces-protocol@ietf.org; Sun, 09 May 2004 04:23:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjZv-0001S7-00 for forces-protocol@ietf.org; Sun, 09 May 2004 04:22:32 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BMjZD-00016P-00 for Forces-protocol@ietf.org; Sun, 09 May 2004 04:21:49 -0400 Received: from dlg (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with SMTP id for ; Sun, 9 May 2004 16:34:12 +0800 Message-ID: <001801c4359e$40bd28e0$8401a8c0@dlg> From: "Ligang Dong" To: References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 9 May 2004 16:18: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=1.5 required=5.0 tests=AWL,MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0i IDxoYWRpQHpueXguY29tPg0KVG86ICJXYW5nLFdlaW1pbmciIDx3bXdhbmdAbWFpbC5oemljLmVk dS5jbj4NCkNjOiAiUm9iZXJ0IEhhYXMiIDxyaGFAenVyaWNoLmlibS5jb20+OyA8Zm9yY2VzLXBy b3RvY29sQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIE1heSAwOCwgMjAwNCAyOjQ1IEFNDQpT dWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gdG9waWMgNGM6IENvbW1vbiBIZWFkZXI6IGJh dGNoaW5nDQoNCg0KPiANCj4gDQo+IE9rLCBJIGp1c3QgZGVsZXRlZCBldmVyeXRoaW5nIHRoYXQg d2FzIHNhaWQgYW5kIGkgYW0gZ29pbmcgdG8gc3VtbWFyaXplDQo+IHdpdGggYSB0d2lzdCBvZiBt eSBvcGluaW9ucy4gKEkgaG9wZSBpIHJlYWQgYWxsIHRoZSBkaXNjdXNzaW9ucw0KPiBjb3JyZWN0 bHkpLiBSb2JlcnQvV2VpbWluZyBwbGVhc2UgZG91YmxlIGNoZWNrLiBIb3BlZnVsbHksIHRoaXMg c3VtbWFyeQ0KPiB3aWxsIGFsbG93IG90aGVyIHBlb3BsZSB0byBwaXRjaCBpbi4NCj4gDQo+IFdo eSBkbyB3ZSBiYXRjaD8NCj4gMSkgdG8gcGlwZWxpbmUgYW5kIGltcHJvdmUgdGhyb3VnaHB1dA0K PiAyKSB0byBhY2hpZXZlIGF0b21pYyBvcGVyYXRpb25zIHNwYW5uaW5nIG11bHRpcGxlIHBhY2tl dHMuIA0KPiANCltEb25nIExpZ2FuZ10gWW91IGFjdHVhbGx5IGRlc2NyaWJlIHR3byBraW5kIG9m IGJhdGNoaW5nLiAiRmFpbCB1cHRvIiBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIGZpcnN0IHR5cGUu DQoNCj4gTm90ZSB0aGF0ICMxIG1heSBub3QgYmUgbmVjZXNzYXJpbHkgYmUgYXRvbWljIG9wZXJh dGlvbi4NCj4gDQo+IFBMIG1lc3NhZ2UvdHJhbnNhY3Rpb24gZXhjZWVkaW5nIE1UVToNCj4gSSB0 aGluayB0aGUgUEwgc2hvdWxkIGNhcmVmdWxseSBlbnN1cmUgdGhhdCB0aGUgbWVzc2FnZXMgZ29p bmcgYWNyb3NzDQo+IGFyZSBlYWNoIGF0IGxlYXN0IGdvaW5nIHRvIGZpdCBpbiB0aGUgTVRVIHNp emUgcGFja2V0LiBJIHRoaW5rIGlmIHdlIGNhbg0KPiBhdm9pZCBmcmFnbWVudGF0aW9uIG9mIGEg Y29tbWFuZCwgdGhlbiB3ZSBzaG91bGQuIA0KDQpbRG9uZyBMaWdhbmddIEkgdGhpbmsgdGhhdCBN VFUgaXMgVE1MJ3MgcmVzcG9uc2liaWxpdHkuIFdlIG5lZWQgbm90IGNvbnNpZGVyIGl0IGluIFBM LiANCg0KPiANCj4gVHlwZXMgb2YgYmF0Y2hpbmc6DQo+IA0KPiAxKSBzZXZlcmFsIFBMIG1lc3Nh Z2VzIGluIG9uZSBUTUwgbGV2ZWwgUERVLiBQTCBsZXZlbCBoZWFkZXIgU09UIGFuZCBFT1QNCj4g aW5kaWNhdGUgc3RhcnQgYW5kIGVuZCBvZiBhIHRyYWluIG9mIHRoZXNlIG1lc3NhZ2VzLg0KPiBJ cyB0aGlzIHJlc3BvbnNpYmlsaXR5IG9mIFRNTCBvciBQTCB0byBwdXQgdGhlbSBpbiBvbmUgUERV IG9yIHRoYXQgb2YNCj4gUEw/IEkgZmVlbCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgUEwu DQo+IA0KPiAyKSBXaXRoaW4gb25lIG1lc3NhZ2Ugc2V2ZXJhbCBUTFZzIHdoaWNoIHJlcXVpcmUg dGhhdCBlYWNoICJhdG9taWMiIHVuaXQNCj4gaGF2ZSBpdHMgb3duIHN1YnNlcXVlbmNlIG51bWJl ciAoYW5kIHRyZWF0IHRoZSB0b3AgaGVhZGVyIHNlcXVlbmNlDQo+IG51bWJlciBhcyBhIGZsYXQg dHJhbnNhY3Rpb24gbnVtYmVyKS4NCj4gDQo+IE15IHByZWZlcmVuY2UgaXMgdXNpbmcgIzEgbW9z dGx5IGJlY2F1c2Ugbm93IHdlIGhhdmUgdG8gbG9vayBmb3IgYSB0cmljaw0KPiB0byBzdGFzaCBh IHN1YnNlcXVlbmNlIG51bWJlci4gdG9vIGNvbXBsZXguIFlvdSBjYW4gYWxyZWFkeSBwYWNrIG1h bnkNCj4gcm91dGVzIGZvciBleGFtcGxlIGluIG9uZSBtZXNzYWdlIC0gc28gbm8gbmVlZCB0byBi ZSBjbGV2ZXIuIA0KPiBFYWNoIG1lc3NhZ2Ugd2lsbCBoYXZlIGEgdW5pcXVlIHNlcXVlbmNlIG51 bWJlci4gU3RhcnQgb2YgdHJhbnNhY3Rpb24NCj4gZ2V0cyBtYXJrZWQgYnkgU29UIGFuZCBlbmQg b2YgdHJhbnNhY3Rpb24gZ2V0cyBtYXJrZWQgYnkgRW9ULiBBbmQgYW55DQo+IG1pZGRsZSBtZXNz YWdlcyBwcm9iYWJseSBtYXJrZWQgd2l0aCBNb1Q/DQo+IFdlaW1pbmcgcG9pbnRzIHRvIGEgY29u Y2VybiBhYm91dCB0aGUgY29tbW9uIGhlYWRlciBpbnRyb2R1Y2luZw0KPiBvdnJlaGVhZC4gTXkg b3BpbmlvbiBpcyB0aGUgb3ZlcmhlYWQgaXMgc28gc21hbGwgdGhhdCBpdCBpcyBpcnJlbGV2YW50 DQo+IGFnYWluc3QgdGhlIGJlbmVmaXRzIG9mIGtlZXBpbmcgdHJhY2sgb2Ygc3Vic2VxdWVuY2Ug bnVtYmVycy4NCj4gDQo+IFdoYXQgdG8gZG8gaW4gY2FzZSBvZiBmYWlsdXJlcz8NCj4gTGV0cyBz YXkgeW91IHNlbnQgYW4gYXRvbWljIGJhdGNoIG9mIEEpIGEgZGVsIHJvdXRlLCBCKSBhbiBhZGQg cm91dGUgYW5kDQo+IEMpIGFkZCByb3V0ZQ0KPiANCltEb25nIExpZ2FuZ10gDQoxKSBCYXRjaGVk IFBMIG1lc3NhZ2VzIGFyZSBvYnZpb3VzbHkgaW4gb25lIFBMIGxldmVsIFBEVS4gSG93ZXZlciwg aXQgaXMgbm90IG5lY2Vzc2FyeSB0aGF0IGJhdGNoZWQgUEwgbWVzc2FnZXMgYXJlIGluIG9uZSBU TUwgbGV2ZWwgUERVLiANCjIpIFBMIGxldmVsIGhlYWRlciBTT1QgYW5kIEVPVCBhcmUgbm90IG5l Y2Vzc2FyeSwgYXMgdGhlIHBsYWNlbWVudCBvcmRlciBpbiBvbmUgUEwgUERVIGNhbiBpbXBsaWNp dGx5IGRldGVybWluZSB0aGUgc2VxdWVuY2Ugb2YgYmF0Y2hlZCBtZXNzYWdlcy4gDQozKSBBIGZp ZWxkIChlLmcuLCBCQVRDSCBmaWVsZCkgaW4gdGhlIFBMIG1lc3NhZ2VzIGhlYWRlciBpcyB1c2Vk IHRvIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHRoaXMgbWVzc2FnZSBjb250YWluIG11bHRpcGxl IGJhdGNodGVkIG1lc3NhZ2VzLiBBbHNvLCB0aGlzIGZpZWxkIGNhbiBiZSB1c2VkIHRvIGluZGlj YXRlIHdlIGFyZSBiYXRjaGluZyBpbmRlcGVuZGVudCBtZXNzYWdlcyBvciB0cmFuc2FjdGlvbiBt ZXNzYWdlcy4gDQogNCkgRm9yIGJhdGNoaW5nIG9mIGluZGVwZW5kZW50IG1lc3NhZ2VzLCB0aGUg cmVzcG9uc2VzIGFyZSBhbHNvIGluZGVwZW5kZW50OyBmb3IgYmF0Y2hpbmcgb2YgdHJhbnNhY3Rp b24gbWVzc2FnZXMsIHRoZSByZXNwb25zZSBpcyBzaW5nbGUuIA0KDQoNCj4gVGVjaG5pcXVlcyAo bGlzdGVkIGJ5IEpvZWwgSGFscGVybiBvbmNlKS4NCj4gDQo+IDEpIEFsbCBvciBub3RoaW5nOg0K PiBpZiBCIGZhaWxzIEEgc2hvdWxkIGFsc28gZmFpbDsgaWYgQSB3YXMgZG9uZSB0aGVuIHlvdSB1 bmRvDQo+IA0KPiAyKSBGYWlsIHVwdG86DQo+IElmIEIgZmFpbHMgYnV0IEEgcGFzc2VzLCB0aGVu IHdlIGp1c3QgaW5mb3JtIENFIG9mIEJzIGZhaWx1cmUgYW5kIGRvbnQNCj4gZXhlY3V0ZSBDLg0K PiANCj4gMykgSSBjYW50IHJlbWVtYmVyIGl0LCBidXQgaSB0aGluayB0aGVyZSB3YXMgYSB0aGly ZCB0ZWNobmlxdWUNCj4gDQo+IA0KPiBJIHRoaW5rIHRoZSBtb3N0IGludGVyZXN0aW5nIHRoaXMg aXMgd2hhdCBoYXBwZW5zIGlmIEZFMSBleGVjdXRlcyBBDQo+IHN1Y2Nlc3NmdWx5IGFuZCBGRTIg Ym90aCBBIGFuZCBCIGJ1dCBub3QgQy4gWW91IG5lZWQgdG8gbWFrZSBzdXJlIHRoaW5ncw0KPiBh cmUgc3luY2hyb25pemVkDQo+IA0KPiBJIGhvcGUgaSBzdW1tYXJpemVkIGV2ZXJ1dGhpbmcgdGhh dCB3YXMgc2FpZC4NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGb3JjZXMtcHJvdG9jb2wg bWFpbGluZyBsaXN0DQo+IEZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2w= _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 00:18:38 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 AAA08276 for ; Mon, 10 May 2004 00:18: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 1BN2E2-0007HE-JL for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 00:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A4HAm5027968 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 00: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 1BN2DJ-0007CX-II for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 00:16: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 AAA08236 for ; Mon, 10 May 2004 00:16: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 1BN2DH-00035G-6c for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 00:16:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN2CT-0002nz-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 00:15:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN2Bz-0002WK-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 00: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 1BN2A1-0006rk-6g; Mon, 10 May 2004 00:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN27u-0006hh-EB for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 00:10: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 AAA08049 for ; Mon, 10 May 2004 00:10: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 1BN27r-0001Kp-UG for forces-protocol@ietf.org; Mon, 10 May 2004 00:10:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN26o-00010T-00 for forces-protocol@ietf.org; Mon, 10 May 2004 00:09: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 1BN25V-0000P9-00 for forces-protocol@ietf.org; Mon, 10 May 2004 00:08:21 -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 i4A46rPV010010 for ; Mon, 10 May 2004 04:06:53 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 i4A48DaR009267 for ; Mon, 10 May 2004 04:08:19 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 M2004050921074711979 for ; Sun, 09 May 2004 21:07: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); Sun, 9 May 2004 21:07:47 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43644.5A89509E" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C15B@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details Thread-Index: AcQz11JhCSlxGjhTQney6OlC89Sb4QCbCFvQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 10 May 2004 04:07:47.0986 (UTC) FILETIME=[5AA81F20:01C43644] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 9 May 2004 21:07: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.1 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43644.5A89509E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team =20 Here are the details for the teleconference call =20 Dial in # 916-356-2663 Bridge: 2 Passcode: 8836206 =20 Hope you all will attend, =20 regards Hormuzd ------_=_NextPart_001_01C43644.5A89509E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Team
 
Here=20 are the details for the teleconference call
 
Dial in=20 # 916-356-2663
Bridge: 2
Passcode: 8836206
 
Hope=20 you all will attend,
 
regards
Hormuzd
------_=_NextPart_001_01C43644.5A89509E-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 09:23: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 JAA02596 for ; Mon, 10 May 2004 09:23: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 1BNAcf-0001Sb-TJ for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 09:15:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ADF9DE005611 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 09:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAbV-0001Bl-6M for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 09:13: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 JAA02155 for ; Mon, 10 May 2004 09:13: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 1BNAbT-0004a2-M0 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:13:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAaa-0004Ei-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:13:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNAZg-0003rp-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAXh-0006PO-CP; Mon, 10 May 2004 09:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAKn-0004CY-OH for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 08: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 IAA01049 for ; Mon, 10 May 2004 08:56: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 1BNAKm-0006ix-8R for forces-protocol@ietf.org; Mon, 10 May 2004 08:56:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAJo-0006Nj-00 for forces-protocol@ietf.org; Mon, 10 May 2004 08:55: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 1BNAIl-0005oN-00 for forces-protocol@ietf.org; Mon, 10 May 2004 08:54:35 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051005581306:12048 ; Mon, 10 May 2004 05:58:13 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header: batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" , avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1084193665.1043.143.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 05/10/2004 05:58:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/10/2004 05:58:21 AM, Serialize complete at 05/10/2004 05:58: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: 10 May 2004 08:54: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Sat, 2004-05-08 at 00:13, Wang,Weiming wrote: > Jamal, > > Thank you for the post, which makes thing much clearer. > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > > > Ok, I just deleted everything that was said and i am going to summarize > > with a twist of my opinions. (I hope i read all the discussions > > correctly). Robert/Weiming please double check. Hopefully, this summary > > will allow other people to pitch in. > > > > Why do we batch? > > 1) to pipeline and improve throughput > > 2) to achieve atomic operations spanning multiple packets. > > > > Note that #1 may not be necessarily be atomic operation. > > > [Weiming]Agreed. Then you mean batch is for 1) or 1)AND 2), right? Probably both - 2) is atomic. > How about just for 2) then, it will not be called batching? Hrm. I would probably still wanna call it batching although it has other connotations. The simplest standalone atomic transaction is probably a single packet for a single transaction such as "add route X". Now lets say such a simple message wont fit in one packet, then you break it into several messages unified by the atomicity flag. Same applies when you group a "batch" of such unified transactions across multiple train of packets. So i would say, for simplicty sake lets just call it a batch. > > PL message/transaction exceeding MTU: > > I think the PL should carefully ensure that the messages going across > > are each at least going to fit in the MTU size packet. I think if we can > > avoid fragmentation of a command, then we should. > > > [Weiming]I just a little worry if the pipeline and the MTU requirement will have > some contradiction with each other. > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > Yes, in fact some sort of MTU discovery might be in order. I think > avoiding fragmentation is of positive value. This is probably a TML > responsibility. > Agreed TML should be responsible. My worry is more when the TML is stream oriented (such as in the case of TCP) and there are no distinct message boundaries at the TML level. Someone needs to feed the PL complete PL messages. For this reason it may be valuable for the PL to be pMTU aware. Thoughts? > > > Types of batching: > > > > 1) several PL messages in one TML level PDU. PL level header SOT and EOT > > indicate start and end of a train of these messages. > > Is this responsibility of TML or PL to put them in one PDU or that of > > PL? I feel it is the responsibility of PL. > > > [Weiming] I also incline for PL to define the pinelining format. Then, we need > to have a batch format (not necessarily a batch msg) to be defined in the > protocol text. Where do you think to put it, in the protocol overviw, common > header, or in the protocol messages? > [/Weiming] On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > Well it sort of depends on which entity is responsible for > non-fragmentations and hence knowing what MTU size to use. It is > certainly the PL's responsibility to know which msgs are batched and > especially which are atomically batched. > Ok, shall we say then that if the PL is pMTU aware it will do a better job? > > 2) Within one message several TLVs which require that each "atomic" unit > > have its own subsequence number (and treat the top header sequence > > number as a flat transaction number). > > > [Weiming]In this case, we need to define a batching msg, which I think should be > defined by protocol msgs. Note, my view is we may not need this approach since it is too complex. > > > My preference is using #1 mostly because now we have to look for a trick > > to stash a subsequence number. too complex. You can already pack many > > routes for example in one message - so no need to be clever. > > Each message will have a unique sequence number. Start of transaction > > gets marked by SoT and end of transaction gets marked by EoT. And any > > middle messages probably marked with MoT? > > [Weiming]Can we summarize that we may need two flags, one for atomicity, and > another for pipelining batch? 3 flags: 1. Atomicity 2. SoT (Start of Transaction) 3. EoT (End of Transaction) A fourth one maybe MoT (Middle of Transaction). Not sure if it is needed; maybe it can be represented by Sot = 0 and Eot = 0 A transaction that fits within one message will always have SoT and EoT set to 1. A two phase commit will at minimal have two message. Something like: msg 1 := {Atomic, SoT, EoT} = { 1,1,0} msg ..:= { 1,0,0} msg ..:= { 1,0,0} msg ..:= { 1,0,0} msg last := {1,0,1} > > Weiming points to a concern about the common header introducing > > ovrehead. My opinion is the overhead is so small that it is irrelevant > > against the benefits of keeping track of subsequence numbers. > > [Weiming]Actually I more inclide to #1 also (pls see my previous reply to > robert), with the same idea that the header may waste less. Note that in TLV > mode (#2 mode), we also have to have many in the TLV, such as ACK flag, > subsequece number, etc. Ok. > Actually I was trying to propose another approach other than #1 and #2, which is > mainly for atomicity. The approach is to let a bunch of msgs that need atomicity > still be separatedly sent via TML instead of pipelining, while only using the > Atomic flag to trace the start and the end of atomiciy. Do you think we need > this? Moreover, I was considering how we can support multipul atomicity > transactions in this case. > [/Weiming] refer > > > > What to do in case of failures? > > Lets say you sent an atomic batch of A) a del route, B) an add route and > > C) add route > > > > Techniques (listed by Joel Halpern once). > > > > 1) All or nothing: > > if B fails A should also fail; if A was done then you undo > [Weiming]My understanding of atomicity is just for this. > > > > 2) Fail upto: > > If B fails but A passes, then we just inform CE of Bs failure and dont > > execute C. > [Weiming]I'm afraid this fail model may only apply to batching msg(s). > [Dong Ligang] You actually describe two kind of batching. "Fail upto" can be > included in the first type. The difference is that in 2) you dont have to undo. But they are probably the same thing. > > 3) I cant remember it, but i think there was a third technique > > > [Weiming]Is it the most general one, that is, to do whatever it can do, and fail > whatever it cannt do? I think so. [Dong Ligang] > 1) Batched PL messages are obviously in one PL level PDU. However, it is not > necessary that batched PL messages are in one TML level PDU. Refer to my comments above about having TML not aware of message boundaries. Also to my comment that the PL being aware of the MTU would help. > 2) PL level header SOT and EOT are not necessary, as the placement order in > one PL PDU can implicitly determine the sequence of batched messages. What about two phase commits? > 3) A field (e.g., BATCH field) in the PL messages header is used to indicate > whether or not this message contain multiple batchted messages. Also, this field > can be used to indicate we are batching independent messages or transaction messages. Refer to my comments above on {Atomic, SoT, EoT} then lets discuss if you disagree. > 4) For batching of independent messages, the responses are also independent; for > batching of transaction messages, the response is single. Yes, this is why it is preferable to have multiple PL level messages because each has its own sequence number that can be responded to. > > I think the most interesting this is what happens if FE1 executes A > > successfuly and FE2 both A and B but not C. You need to make sure things > > are synchronized > [Weiming]I think in broadcast case, we may have to choose to use a simple fail > scheme such as all or nothing, or else, I'm just afraid it may make things much > complex. in the case of 3 above, you may not care (atomic flag = 0). On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > when I think of the two kinds of batching, atomic and non, I make the > distinction that in non-atomic, each goes on and you get a separate > ack/error code back on each of the component messages. With atomic, I > tend to support option 1 above. > > Option 2, the do until fail, would seem to me to be a different sort of > batching and I am not sure how useful, or safe, a variant it is. So should we then have two choices? One with all-or-none when atomic flag is set and the other with try-all mode when atomic flag is not set? If we are going to add the rhird one i think we need an extra flag. On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > I like the summaries. I get confused in the back and forth > conversations and don't really know how to jump in with a response. So > thanks. I have come to the conclusion the reason that discussions keep getting repeated is because theres no good summaries so far i.e insufficient meat. This is my first attempt. I am hoping we make fastr progress with this approach. Who is in charge of writting this section? I could rewrite the details with the provided comments or whoever is in charge of it could. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 09:34:35 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 JAA02946 for ; Mon, 10 May 2004 09:34: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 1BNAu8-0003m7-JS for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 09:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ADXChQ014512 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 09:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAtl-0003ef-5k for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 09:32: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 JAA02865 for ; Mon, 10 May 2004 09:32: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 1BNAtj-0002lG-GH for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:32:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAsg-0002Q2-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:31:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNArZ-0001pL-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 09:30:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAlG-0002IQ-Ei; Mon, 10 May 2004 09: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 1BNAde-0001X3-3z for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 09:16: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 JAA02323 for ; Mon, 10 May 2004 09:16: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 1BNAdc-0005IC-IC for forces-protocol@ietf.org; Mon, 10 May 2004 09:16:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAce-0004x2-00 for forces-protocol@ietf.org; Mon, 10 May 2004 09:15: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 1BNAbj-0004bu-00 for forces-protocol@ietf.org; Mon, 10 May 2004 09:14: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 2004051006175551:12081 ; Mon, 10 May 2004 06:17:55 -0700 Subject: Re: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EF2C15B@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EF2C15B@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084194848.1042.168.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 05/10/2004 06:17:55 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/10/2004 06:17:57 AM, Serialize complete at 05/10/2004 06:17:57 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: 10 May 2004 09: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shall we discuss an agenda? Seems like a) the layout of the doc and b) the common header + message body are two items that should be on the list. Is Avri available to take minutes? cheers, jamal On Mon, 2004-05-10 at 00:07, Khosravi, Hormuzd M wrote: > Hi Team > > Here are the details for the teleconference call > > Dial in # 916-356-2663 > Bridge: 2 > Passcode: 8836206 > > Hope you all will attend, > > regards > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 12:31: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 MAA15181 for ; Mon, 10 May 2004 12:31: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 1BNDXe-00080g-Jm for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 12:22:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AGMAvW030787 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 12:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDOf-0005Hg-4H for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 12:12: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 MAA13992 for ; Mon, 10 May 2004 12:12: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 1BNDOd-0003VH-OZ for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:12:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDNe-00039u-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:11:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNDMi-0002qm-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:10:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BND8L-0001Hz-0u; Mon, 10 May 2004 11: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 1BNCzc-0008N9-CQ for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 11:47: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 LAA12207 for ; Mon, 10 May 2004 11:46: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 1BNCzb-0002WS-8f for forces-protocol@ietf.org; Mon, 10 May 2004 11:46:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCyZ-0002BL-00 for forces-protocol@ietf.org; Mon, 10 May 2004 11:45:57 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNCxe-0001ql-00 for forces-protocol@ietf.org; Mon, 10 May 2004 11:44:59 -0400 Received: from wwm1 (unverified [219.82.171.119]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 10 May 2004 23:57:33 +0800 Message-ID: <002401c436a5$2a6f2f90$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> <1084193665.1043.143.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 10 May 2004 23:40:45 +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 autolearn=no version=2.60 Jamal, I'v just thought of one thing. I think if it may be better to consider the batch and the atomicity as two separate issues. Based on your summary, I describe my thought as follows, 1. Batching PL appearance: msg chains. Flag used: BatchFlag BatchFlag = 1 - used by first msg and all middle msgs in the batch = 0 - used by last of the batch msg, indicating the end of the batch When in non-batch mode, msg is always set to BatchFlag = 0. Default fail mode: to do whatever it can and fail those it cannot. ACK mode: according to ACK flag in individual msg headers. The BatchFlag is actually used as a signal for TML pinepining implementation. TML is responsible for things like MTU check and fragment. I think TML should be also responsible for the check of PL msg boundaries, because it seems in our current msg chain mode for batch, TML is inevitable to check the msg headers. But hornestly, I'm not sure if this is out of the scope of TML or not. 2. Atomicity PL appearance: msg chains. Flag used: AtomicFlag AtomicFlag = 1 - used by first msg and all middle msgs in the atomic = 0 - used by last msg in the atomic, indicating the end of the atomic and also as a signal for a receiver to excecute the atomic. When in non-atomic mode, msg is always set to AtomicFlag = 0 Default fail mode: all or nothing ACK mode: according to ACK flag in individual msg headers. 3. Atomicity in batching Just operate separately in the same way as described above except that the fail mode for atomicity has previlege over that of batching, that is, if in an atomic, fail mode must be all or nothing. A batch may contain more than one atomic. Just want to see if it helps more or less for our discussion. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: "Wang,Weiming" ; Cc: Sent: Monday, May 10, 2004 8:54 PM Subject: Re: [Forces-protocol] topic 4c: Common Header: batching > On Sat, 2004-05-08 at 00:13, Wang,Weiming wrote: > > Jamal, > > > > Thank you for the post, which makes thing much clearer. > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > > > > Ok, I just deleted everything that was said and i am going to summarize > > > with a twist of my opinions. (I hope i read all the discussions > > > correctly). Robert/Weiming please double check. Hopefully, this summary > > > will allow other people to pitch in. > > > > > > Why do we batch? > > > 1) to pipeline and improve throughput > > > 2) to achieve atomic operations spanning multiple packets. > > > > > > Note that #1 may not be necessarily be atomic operation. > > > > > [Weiming]Agreed. Then you mean batch is for 1) or 1)AND 2), right? > > Probably both - 2) is atomic. > > > How about just for 2) then, it will not be called batching? > > Hrm. I would probably still wanna call it batching although it has other > connotations. The simplest standalone atomic transaction is probably a > single packet for a single transaction such as "add route X". Now lets > say such a simple message wont fit in one packet, then you break it into > several messages unified by the atomicity flag. Same applies when you > group a "batch" of such unified transactions across multiple train of > packets. So i would say, for simplicty sake lets just call it a batch. > > > > PL message/transaction exceeding MTU: > > > I think the PL should carefully ensure that the messages going across > > > are each at least going to fit in the MTU size packet. I think if we can > > > avoid fragmentation of a command, then we should. > > > > > [Weiming]I just a little worry if the pipeline and the MTU requirement will have > > some contradiction with each other. > > > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > Yes, in fact some sort of MTU discovery might be in order. I think > > avoiding fragmentation is of positive value. This is probably a TML > > responsibility. > > > > Agreed TML should be responsible. My worry is more when the TML is stream > oriented (such as in the case of TCP) and there are no distinct message > boundaries at the TML level. Someone needs to feed the PL complete PL messages. > For this reason it may be valuable for the PL to be pMTU aware. Thoughts? > > > > > > Types of batching: > > > > > > 1) several PL messages in one TML level PDU. PL level header SOT and EOT > > > indicate start and end of a train of these messages. > > > Is this responsibility of TML or PL to put them in one PDU or that of > > > PL? I feel it is the responsibility of PL. > > > > > [Weiming] I also incline for PL to define the pinelining format. Then, we need > > to have a batch format (not necessarily a batch msg) to be defined in the > > protocol text. Where do you think to put it, in the protocol overviw, common > > header, or in the protocol messages? > > [/Weiming] > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > Well it sort of depends on which entity is responsible for > > non-fragmentations and hence knowing what MTU size to use. It is > > certainly the PL's responsibility to know which msgs are batched and > > especially which are atomically batched. > > > > Ok, shall we say then that if the PL is pMTU aware it will do a better > job? > > > > 2) Within one message several TLVs which require that each "atomic" unit > > > have its own subsequence number (and treat the top header sequence > > > number as a flat transaction number). > > > > > [Weiming]In this case, we need to define a batching msg, which I think should be > > defined by protocol msgs. > > Note, my view is we may not need this approach since it is too complex. > > > > > > My preference is using #1 mostly because now we have to look for a trick > > > to stash a subsequence number. too complex. You can already pack many > > > routes for example in one message - so no need to be clever. > > > Each message will have a unique sequence number. Start of transaction > > > gets marked by SoT and end of transaction gets marked by EoT. And any > > > middle messages probably marked with MoT? > > > > [Weiming]Can we summarize that we may need two flags, one for atomicity, and > > another for pipelining batch? > > 3 flags: > 1. Atomicity > 2. SoT (Start of Transaction) > 3. EoT (End of Transaction) > > A fourth one maybe MoT (Middle of Transaction). Not sure if it is > needed; maybe it can be represented by Sot = 0 and Eot = 0 > A transaction that fits within one message will always have SoT and EoT > set to 1. > A two phase commit will at minimal have two message. Something like: > msg 1 := {Atomic, SoT, EoT} = { 1,1,0} > msg ..:= { 1,0,0} > msg ..:= { 1,0,0} > msg ..:= { 1,0,0} > msg last := {1,0,1} > > > > Weiming points to a concern about the common header introducing > > > ovrehead. My opinion is the overhead is so small that it is irrelevant > > > against the benefits of keeping track of subsequence numbers. > > > > [Weiming]Actually I more inclide to #1 also (pls see my previous reply to > > robert), with the same idea that the header may waste less. Note that in TLV > > mode (#2 mode), we also have to have many in the TLV, such as ACK flag, > > subsequece number, etc. > > Ok. > > > Actually I was trying to propose another approach other than #1 and #2, which is > > mainly for atomicity. The approach is to let a bunch of msgs that need atomicity > > still be separatedly sent via TML instead of pipelining, while only using the > > Atomic flag to trace the start and the end of atomiciy. Do you think we need > > this? Moreover, I was considering how we can support multipul atomicity > > transactions in this case. > > [/Weiming] > > refer > > > > > > > What to do in case of failures? > > > Lets say you sent an atomic batch of A) a del route, B) an add route and > > > C) add route > > > > > > Techniques (listed by Joel Halpern once). > > > > > > 1) All or nothing: > > > if B fails A should also fail; if A was done then you undo > > [Weiming]My understanding of atomicity is just for this. > > > > > > 2) Fail upto: > > > If B fails but A passes, then we just inform CE of Bs failure and dont > > > execute C. > > [Weiming]I'm afraid this fail model may only apply to batching msg(s). > > [Dong Ligang] You actually describe two kind of batching. "Fail upto" can be > > included in the first type. > > The difference is that in 2) you dont have to undo. But they are > probably the same thing. > > > > 3) I cant remember it, but i think there was a third technique > > > > > [Weiming]Is it the most general one, that is, to do whatever it can do, and fail > > whatever it cannt do? > > I think so. > > [Dong Ligang] > > 1) Batched PL messages are obviously in one PL level PDU. However, it is not > > necessary that batched PL messages are in one TML level PDU. > > Refer to my comments above about having TML not aware of message boundaries. > Also to my comment that the PL being aware of the MTU would help. > > > 2) PL level header SOT and EOT are not necessary, as the placement order in > > one PL PDU can implicitly determine the sequence of batched messages. > > What about two phase commits? > > > 3) A field (e.g., BATCH field) in the PL messages header is used to indicate > > whether or not this message contain multiple batchted messages. Also, this field > > can be used to indicate we are batching independent messages or transaction messages. > > Refer to my comments above on {Atomic, SoT, EoT} then lets discuss if you disagree. > > > 4) For batching of independent messages, the responses are also independent; for > > batching of transaction messages, the response is single. > > Yes, this is why it is preferable to have multiple PL level messages because > each has its own sequence number that can be responded to. > > > > I think the most interesting this is what happens if FE1 executes A > > > successfuly and FE2 both A and B but not C. You need to make sure things > > > are synchronized > > [Weiming]I think in broadcast case, we may have to choose to use a simple fail > > scheme such as all or nothing, or else, I'm just afraid it may make things much > > complex. > > in the case of 3 above, you may not care (atomic flag = 0). > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > when I think of the two kinds of batching, atomic and non, I make the > > distinction that in non-atomic, each goes on and you get a separate > > ack/error code back on each of the component messages. With atomic, I > > tend to support option 1 above. > > > > Option 2, the do until fail, would seem to me to be a different sort of > > batching and I am not sure how useful, or safe, a variant it is. > > > So should we then have two choices? One with all-or-none when atomic > flag is set and the other with try-all mode when atomic flag is not set? > If we are going to add the rhird one i think we need an extra flag. > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > I like the summaries. I get confused in the back and forth > > conversations and don't really know how to jump in with a response. So > > thanks. > > I have come to the conclusion the reason that discussions keep getting repeated > is because theres no good summaries so far i.e insufficient meat. This is my first > attempt. I am hoping we make fastr progress with this approach. > Who is in charge of writting this section? I could rewrite the details with the provided > comments or whoever is in charge of it could. > > cheers, > jamal > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 12:37: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 MAA15757 for ; Mon, 10 May 2004 12:37: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 1BNDj7-0001CJ-DV for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 12:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AGY1BO004597 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDa0-00005s-HI for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 12: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 MAA14703 for ; Mon, 10 May 2004 12:24: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 1BNDZy-0007gG-Sq for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDYk-0007GJ-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:23:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNDXX-0006pS-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 12:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDNq-00057W-Ql; Mon, 10 May 2004 12: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 1BNDAU-0002WL-OS for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 11:58: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 LAA12757 for ; Mon, 10 May 2004 11:58: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 1BNDAT-00064f-Gu for forces-protocol@ietf.org; Mon, 10 May 2004 11:58:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BND9b-0005it-00 for forces-protocol@ietf.org; Mon, 10 May 2004 11:57:19 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BND8g-0005Jw-00 for forces-protocol@ietf.org; Mon, 10 May 2004 11:56:23 -0400 Received: from wwm1 (unverified [219.82.171.119]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 11 May 2004 00:08:41 +0800 Message-ID: <002c01c436a6$b9080c80$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> <1084193665.1043.143.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 10 May 2004 23:51: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, > I have come to the conclusion the reason that discussions keep getting repeated > is because theres no good summaries so far i.e insufficient meat. This is my first > attempt. I am hoping we make fastr progress with this approach. > Who is in charge of writting this section? I could rewrite the details with the provided > comments or whoever is in charge of it could. [Weiming]I think it is great if you can write the section. Actually I think Common Header section contains a lot. We may need to subdivide it into subsections like Data format, Batch, Atomicity, and ACK. Thoughts? > > 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 May 10 13:57:36 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 NAA20135 for ; Mon, 10 May 2004 13:57: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 1BNEyi-00060F-4O for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 13:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AHsCpN023070 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 13:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEs2-00055U-Kw for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 13:47: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 NAA19571 for ; Mon, 10 May 2004 13:47: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 1BNEs0-0005If-JO for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 13:47:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEqt-0004wh-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 13:46:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNEq7-0004bv-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 13:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNElx-00041u-MQ; Mon, 10 May 2004 13:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEjx-0003fP-GZ for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 13:38: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 NAA19134 for ; Mon, 10 May 2004 13:38: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 1BNEjv-0002Ui-CE for forces-protocol@ietf.org; Mon, 10 May 2004 13:38:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEj0-00028b-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:37:59 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNEht-0001UC-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:36:50 -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 i4AHareH011081; Mon, 10 May 2004 17:36:53 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 i4AHX4aE003146; Mon, 10 May 2004 17:34:01 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 M2004051010361113562 ; Mon, 10 May 2004 10:36: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); Mon, 10 May 2004 10:36: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] header: flags vs commands Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C4FF@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] header: flags vs commands Thread-Index: AcQ0QHB/NK5DCnKkRnC3EYKd0sJiXgCdEeFw From: "Khosravi, Hormuzd M" To: , "Weiming Wang" Cc: X-OriginalArrivalTime: 10 May 2004 17:36:11.0733 (UTC) FILETIME=[49249050:01C436B5] 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, 10 May 2004 10:36:00 -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, Sorry for the late response. See my reply below. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Let me talk about something related first: My view is we need those flags in the header. It doesnt make sense to be protective of 12 bits (restricting flags to 4 bits). While i am against over zealous future-proof designs, i think at this stage of the game we cant=20 afford to be extreme on the other end of the stick either. So my thoughts: 16 bit flags and 16 bit command. I dont see a big deal of using 20 more bits (come on, guys - some people are preaching XML, imagine the million of bits overhead per second there). Note i dont have a problem using the headers on the T part of things in the=20 message body. However, i think those are very precious(not many bits) and we=20 should use them cautiously. Now to the issue at hand of whether to use more commands or extend commands via flags. Like i said earlier, i am indifferent; however, i have used the second scheme and it worked well (and i know a lot of protocols using it) and for that reason=20 i am biased towards it.=20 Hormuzd, what is it that is attractive to have the use of commands instead of=20 the flags extensions? Is it implementation experience, another protocol you=20 are familiar with, or you just think it is cleaner.=20 [HK] Its implementation experience, more efficient parsing, efficient use of bits and cleaner. I dont think we should stall on this. so lets resolve this and move on. [HK] Sure, I agree. I don't want us to stall on this either. Let us know your thougts ? If you don't agree, we can move forward with what you guys think is best. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 14:12:42 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 OAA20987 for ; Mon, 10 May 2004 14:12: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 1BNFCs-0001yG-8S for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:08:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AI8o38007569 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNF4P-0008Sr-Iv for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 14:00: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 OAA20342 for ; Mon, 10 May 2004 14:00: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 1BNF4N-0001up-90 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:00:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNF3P-0001ap-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 13:59:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNF2t-0001Gu-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 13:58:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNF0U-0006dI-P3; Mon, 10 May 2004 13: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 1BNEuZ-0005OJ-Nu for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 13:49: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 NAA19694 for ; Mon, 10 May 2004 13:49: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 1BNEuX-0006Ih-Dj for forces-protocol@ietf.org; Mon, 10 May 2004 13:49:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEtY-0005y2-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:48:53 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNEsQ-0005IK-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:47:47 -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 i4AHjxTe024607; Mon, 10 May 2004 17:45:59 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 i4AHjOgU006824; Mon, 10 May 2004 17:47:11 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 M2004051010454102314 ; Mon, 10 May 2004 10:45:41 -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, 10 May 2004 10:45: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] Summary : Protocol Messages: topic 3 & 4a Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C52A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a Thread-Index: AcQz9nEwYueB5OT7SzmL/U45jShiBQCvs5Pg From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" X-OriginalArrivalTime: 10 May 2004 17:45:25.0105 (UTC) FILETIME=[92FA6E10:01C436B6] 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, 10 May 2004 10:45: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 Weiming, Sorry for the late reply. Pls see my comments below. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang [WeimingRe] I'm afraid there is a little contradiction here with your idea. To make more use of MsgType field is to have more messages, rights? My original idea was to use the field more fully. E.g., I would prefer to distinguish msgs such as config, query, and event msgs between the LFB config, event, and query from others, because I'm sure the msgs for LFB operations are quite different from others like FE coarse layer operations (as Robert proposed for FE LFB or I proposed for FE slave). This LFB difference is much bigger than the difference of association 'Setup' and 'Teardown'. My idea is If we have decided to use flags in msg body to describe the former difference, we have no reason not to use the msg body flag for the latter description, unless you can present other reasons that the 'setup' and 'teardown' MUST be two msgs other than that the Msg type field is enough. [/Weiming] [HK] I am actually fine with having separate sub-types of FE, LFB in Config/Query msg [WeimingRe] Actually I don't see any differences between the two schemes you proposed, I don't think it is me who have slowed down the progress in this point :) What I just want to know is the reasonable reason (other than making more use of MsgType) why you don't agree the following two schemes, instead to use more complex scheme: 1. to use flags in the msg body to describe the operation of 'setup/resp' 'teardown'. I think Jamal more inclide to this also. 2. to use flags or an FE attribute to describe subscribing/unsubscribing events. I think Jamal more means the subscribe function is important. [/WeimingRe] [HK] I have already pointed out why I don't like flags for describing msg types, pls refer to my previous emails...but I am not religious about this. As regards Suscribe, I think this is fundamentally different from Config, they mean very different things. Unless you say that "Subscribing for Events" is a FE or LFB attribute...?? Anyways we can discuss this in the call. [WeimingRe] Not actually. If you'd like to have the Prefix to make me happy, pls add some for msgs like query, config:). I actually don't care if using FE setup or not, because I have seriously considered your idea that we may need to setup CE in the future. [HK] Thanks for the consideration [WeimingRe] I think I have already given up pushing the prefix for the purpose of our fast progress. I'm not sure why you mention this here again. Do you think it is still the barrier? [/WeimingRe] [HK] No, not from my side atleast. I was thinking this is something that you wanted. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 14:13:12 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 OAA21058 for ; Mon, 10 May 2004 14:13: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 1BNFCx-0001zE-0y for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:08:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AI8sZA007631 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14: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 1BNF6v-0000P3-Ng for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 14:02: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 OAA20427 for ; Mon, 10 May 2004 14:02: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 1BNF6t-0002Zn-HY for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:02:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNF5M-0002FS-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:01:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNF4Z-0001vs-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:00:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNF3N-0007kV-GR; Mon, 10 May 2004 13: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 1BNEza-0006TL-Pd for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 13:55: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 NAA19988 for ; Mon, 10 May 2004 13:55: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 1BNEzY-0000C8-Dy for forces-protocol@ietf.org; Mon, 10 May 2004 13:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEyP-0007eB-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:53:54 -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 1BNExM-00071x-00 for forces-protocol@ietf.org; Mon, 10 May 2004 13:52:49 -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 i4AHqtJu008226; Mon, 10 May 2004 17:52:55 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 i4AHpmgQ012687; Mon, 10 May 2004 17:52:38 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 M2004051010520903715 ; Mon, 10 May 2004 10:52: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); Mon, 10 May 2004 10:51:07 -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] Conference call - Monday 4-6 PM PST - bridgedetails Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C542@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridgedetails Thread-Index: AcQ2kLAvh/eqWnXhSEGHJnvxt4QGIgAJjN3Q From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 10 May 2004 17:51:07.0667 (UTC) FILETIME=[5F293E30:01C436B7] 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, 10 May 2004 10:51:07 -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, These are the topics that you had proposed before. -------- The topics as i see it: 1) It seems to me that the header discussion needs to be completed. I have raised a few points that need to be addressed in relation to the header: - atomicty, transaction definition, windowing, batching, types of replies, configs from FE->CE 2) peering model - discussion active 3) FEM/CEM - missing from your list 4) I would like to add a new one here: message body format. We can go through this and knock down any remaining items along with a) the layout of the doc , that you have proposed below, Let me know if there are any other items to be discussed Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Monday, May 10, 2004 6:14 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridgedetails Shall we discuss an agenda? Seems like a) the layout of the doc=20 and b) the common header + message body=20 are two items that should be on the list. Is Avri available to take minutes? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 14:45: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 OAA23797 for ; Mon, 10 May 2004 14:45: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 1BNFjw-0000TT-Sn for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AIh08s001817 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFhD-0008FS-FU for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 14:40: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 OAA23230 for ; Mon, 10 May 2004 14:40: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 1BNFhA-0000cs-RU for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:40:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFg6-0000Fa-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:39:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNFfE-0007eU-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFUZ-0005U3-C0; Mon, 10 May 2004 14: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 1BNFPe-0004I4-4l for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 14:22: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 OAA21752 for ; Mon, 10 May 2004 14: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 1BNFPb-0001oQ-HV for forces-protocol@ietf.org; Mon, 10 May 2004 14:21:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFOc-0001TQ-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:20:58 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNFNn-0000pU-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:20:07 -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 i4AIKHeH007319; Mon, 10 May 2004 18:20:17 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 i4AIHGZk000474; Mon, 10 May 2004 18:17: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 M2004051011193022453 ; Mon, 10 May 2004 11:19:30 -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, 10 May 2004 11:19: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 4c: Common Header: batching Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C5EC@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: batching Thread-Index: AcQ0ZcLYLYJiJ5sMRw6cRMecymn35gCU3WPA From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: "Robert Haas" , X-OriginalArrivalTime: 10 May 2004 18:19:30.0127 (UTC) FILETIME=[55E805F0:01C436BB] 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, 10 May 2004 11:19: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 Jamal, Thanks for this post. I mostly agree, Pls see my comments inline. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Types of batching: 1) several PL messages in one TML level PDU. PL level header SOT and EOT indicate start and end of a train of these messages. Is this responsibility of TML or PL to put them in one PDU or that of PL? I feel it is the responsibility of PL. 2) Within one message several TLVs which require that each "atomic" unit have its own subsequence number (and treat the top header sequence number as a flat transaction number). My preference is using #1 mostly because now we have to look for a trick to stash a subsequence number.=20 [HK] I agree with using #1, for batching. BTW, we also need #2 when we have atomic operations on different LFBs (command bundling)....do you agree ? So we need both kinds of flags, I think. Weiming points to a concern about the common header introducing ovrehead. [HK] If these are sent as separate msgs then we cant avoid that overhead, for a single msg we should be able to. What to do in case of failures? Lets say you sent an atomic batch of A) a del route, B) an add route and C) add route Techniques (listed by Joel Halpern once). 1) All or nothing: if B fails A should also fail; if A was done then you undo [HK] This is when atomic flag is turned on. 2) Fail upto: If B fails but A passes, then we just inform CE of Bs failure and dont execute C. [HK] This one seems confusing to me. I guess without the atomic flag, the FE should just report the results/responses to the CE and let the CE decide. I think the most interesting this is what happens if FE1 executes A successfuly and FE2 both A and B but not C. You need to make sure things are synchronized [HK] This is something which can be left to the application or the CE controller which is using the ForCES protocol. We give them all the hooks and let them decide how they want to hang stuff. Does that sound fine ?? Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 15:01:21 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 PAA24766 for ; Mon, 10 May 2004 15:01: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 1BNFwl-0002OI-OE for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:56:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AIuFuN009183 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFnw-0001DR-3n for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 14: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 OAA23934 for ; Mon, 10 May 2004 14: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 1BNFnt-0003A0-Gu for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFms-0002oE-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:46:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNFm1-0002T1-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFjy-0000Tw-Tz; Mon, 10 May 2004 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFXK-0005re-Ek for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 14:29: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 OAA22536 for ; Mon, 10 May 2004 14:29: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 1BNFXH-0004pU-PB for forces-protocol@ietf.org; Mon, 10 May 2004 14:29:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFWL-0004V6-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:28:58 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNFVU-0003o2-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:28:04 -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 i4AISFeH012039; Mon, 10 May 2004 18:28: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 i4AIPFZk005330; Mon, 10 May 2004 18:25:15 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 M2004051011272523955 ; Mon, 10 May 2004 11:27: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); Mon, 10 May 2004 11:26: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 4c: Common Header: batching Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C614@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: batching Thread-Index: AcQ0ZcLYLYJiJ5sMRw6cRMecymn35gCVfhiA From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" Cc: "Robert Haas" , X-OriginalArrivalTime: 10 May 2004 18:26:46.0223 (UTC) FILETIME=[59D6FDF0:01C436BC] 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, 10 May 2004 11:26: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 Jamal, One thing I missed in my last reply... -----Original Message----- Why do we batch? 1) to pipeline and improve throughput 2) to achieve atomic operations spanning multiple packets.=20 Note that #1 may not be necessarily be atomic operation. PL message/transaction exceeding MTU: I think the PL should carefully ensure that the messages going across are each at least going to fit in the MTU size packet. I think if we can avoid fragmentation of a command, then we should.=20 Types of batching: 1) several PL messages in one TML level PDU. PL level header SOT and EOT indicate start and end of a train of these messages. Is this responsibility of TML or PL to put them in one PDU or that of PL? I feel it is the responsibility of PL. [HK] I am not sure what MTU you are referring to. But if it's the layer 2 MTU and the PL does this, it might be a layer violation...what do you think ? Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 15:01: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 PAA24801 for ; Mon, 10 May 2004 15:01: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 1BNFwn-0002Q0-4w for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:56:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AIuHHI009291 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 14:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFpA-0001Kl-23 for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 14:48: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 OAA24018 for ; Mon, 10 May 2004 14:48: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 1BNFp7-0003X1-Eq for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFo6-0003Bv-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:47:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNFnY-0002q8-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 14:46:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFk1-0000VP-2z; Mon, 10 May 2004 14: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 1BNFdG-0006wo-8s for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 14:36: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 OAA22782 for ; Mon, 10 May 2004 14:36: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 1BNFdD-0006oz-7X for forces-protocol@ietf.org; Mon, 10 May 2004 14:36:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFcC-0006Rq-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:35:01 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNFbF-0005oB-00 for forces-protocol@ietf.org; Mon, 10 May 2004 14:34:01 -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 i4AIW5Te015722; Mon, 10 May 2004 18:32:06 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 i4AIWQge016470; Mon, 10 May 2004 18:33:30 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 M2004051011325810925 ; Mon, 10 May 2004 11:32: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, 10 May 2004 11:32: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] Summary : Protocol Messages: topic 3 & 4a] Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C62C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a] Thread-Index: AcQ0t30qO06XaUIKTu+1d8rjbq2uNQCBUohw From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , , X-OriginalArrivalTime: 10 May 2004 18:32:58.0746 (UTC) FILETIME=[37E17DA0:01C436BD] 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, 10 May 2004 11:32: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, Jamal, All -----Original Message----- I'm afraid our discussion has come to the same point. Actually my idea is a little different from Robert's in that, i would not call the 'thing' a LFB, because many of its functions actually have to be ready there even before the ForCES protocol begin to run, e.g., the protocol version information, the TML capability. While for a LFB, I more think it should be lunched by our protocol, that is, should work only after the protocol core runs.=20 [HK] This is the dynamic LFB scenario, however the more common scenario is the static LFB topology which everyone agrees is the default and must be supported by the protocol. I agree with Robert in that, we do have such a 'thing' in the protocol, which I'm afraid not included in our current protocol contents. The 'thing' has its attributes, capabilities, evnets, which we need to describe in our protocol text. To be more presie, I just think we need to define some attributes, capabilities, events by ourselves in our protocol, which can not be defined by FE model. [HK] I agree with this sentiment, we need to define this like FE States, etc in the protocol and need to make it extensible. I do have similar concerns as Jamal regarding the naming of this 'thing' :) Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 17:22: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 RAA06637 for ; Mon, 10 May 2004 17:22: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 1BNI4n-0002cg-V1 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 17:12:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ALCfFd010082 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 17:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHRa-0005Z5-7T for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 16: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 QAA01867 for ; Mon, 10 May 2004 16:32: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 1BNHRY-0000ty-E6 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 16:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNHQf-0000Zj-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 16:31:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNHPi-0000FC-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 16:30:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHLd-000422-7l; Mon, 10 May 2004 16:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHBy-0001qj-3C for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 16:16: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 QAA00689 for ; Mon, 10 May 2004 16:15: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 1BNHBw-0002zI-5M for forces-protocol@ietf.org; Mon, 10 May 2004 16:16:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNHAx-0002dn-00 for forces-protocol@ietf.org; Mon, 10 May 2004 16:15:00 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNH9x-0001yV-00 for forces-protocol@ietf.org; Mon, 10 May 2004 16:13:57 -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 i4AKDeKa011338; Mon, 10 May 2004 20:13:41 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 i4AKDjgG003953; Mon, 10 May 2004 20:13:48 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 M2004051013132025517 ; Mon, 10 May 2004 13:13:20 -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, 10 May 2004 13:13: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: [Forces-protocol] topic 4c: Common Header: batching Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C78C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: batching Thread-Index: AcQ2qWK4htbePlouTJmoSnvp6NZp/QAIVfPQ From: "Khosravi, Hormuzd M" To: "Weiming Wang" , , X-OriginalArrivalTime: 10 May 2004 20:13:19.0120 (UTC) FILETIME=[3C4DA900:01C436CB] 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, 10 May 2004 13:13: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 Weiming, Thanks for posting this summary. It sounds very reasonable to me. I think you guys are pretty close to closing this one now. regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang I'v just thought of one thing. I think if it may be better to consider the batch and the atomicity as two separate issues. Based on your summary, I describe my thought as follows, 1. Batching PL appearance: msg chains. Flag used: BatchFlag BatchFlag =3D 1 - used by first msg and all middle msgs in the batch =3D 0 - used by last of the batch msg, indicating the end of = the batch When in non-batch mode, msg is always set to BatchFlag =3D 0. Default fail mode: to do whatever it can and fail those it cannot. ACK mode: according to ACK flag in individual msg headers. The BatchFlag is actually used as a signal for TML pinepining implementation. TML is responsible for things like MTU check and fragment. I think TML should be also responsible for the check of PL msg boundaries, because it seems in our current msg chain mode for batch, TML is inevitable to check the msg headers. But hornestly, I'm not sure if this is out of the scope of TML or not. 2. Atomicity PL appearance: msg chains. Flag used: AtomicFlag AtomicFlag =3D 1 - used by first msg and all middle msgs in the atomic =3D 0 - used by last msg in the atomic, indicating the end of the atomic and also as a signal for a receiver to excecute the atomic. When in non-atomic mode, msg is always set to AtomicFlag =3D 0 Default fail mode: all or nothing ACK mode: according to ACK flag in individual msg headers. 3. Atomicity in batching Just operate separately in the same way as described above except that the fail mode for atomicity has previlege over that of batching, that is, if in an atomic, fail mode must be all or nothing. A batch may contain more than one atomic. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 18:22:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12043 for ; Mon, 10 May 2004 18:22: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 1BNJ4J-0007cU-6y for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 18:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMGFp5029252 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 18:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIt5-0001u9-4U for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 18:04: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 SAA09776 for ; Mon, 10 May 2004 18:04: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 1BNIt2-0002vo-El for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 18:04:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIri-0002Wz-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 18:03:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNIqe-0002Aw-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 18:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIc4-0004Gv-U8; Mon, 10 May 2004 17:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIYP-0002tI-IB for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 17:43: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 RAA08450 for ; Mon, 10 May 2004 17:43: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 1BNIYM-0003Oj-SD for forces-protocol@ietf.org; Mon, 10 May 2004 17:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIXe-00034B-00 for forces-protocol@ietf.org; Mon, 10 May 2004 17:42:31 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNIWv-0002hi-00 for forces-protocol@ietf.org; Mon, 10 May 2004 17:41:45 -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 i4ALfaqP026491 for ; Mon, 10 May 2004 21:41:36 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 i4ALfOI4011428 for ; Mon, 10 May 2004 21:41:35 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 M2004051014410506426 for ; Mon, 10 May 2004 14:41:06 -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, 10 May 2004 14:41:02 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C436D7.7D6E93FC" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details Message-ID: <468F3FDA28AA87429AD807992E22D07EF2C932@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details Thread-Index: AcQz11JhCSlxGjhTQney6OlC89Sb4QCbCFvQACTD8CA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 10 May 2004 21:41:02.0484 (UTC) FILETIME=[7D834540:01C436D7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 10 May 2004 14:41: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.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C436D7.7D6E93FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is some more info on the local phone nos. that can be used to get into the bridge =20 China, Beijing - 8529-8800 and then extension 1112 China, Shanghai - 5048-1818, and then dial 31000 California, Santa Clara 408-765-2663 =20 Sorry I couldn't find any local nos for Canada. =20 Hope this helps, Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Khosravi, Hormuzd M Sent: Sunday, May 09, 2004 9:08 PM To: forces-protocol@ietf.org Subject: [Forces-protocol] Conference call - Monday 4-6 PM PST - bridge details Hi Team =20 Here are the details for the teleconference call =20 Dial in # 916-356-2663 Bridge: 2 Passcode: 8836206 =20 Hope you all will attend, =20 regards Hormuzd ------_=_NextPart_001_01C436D7.7D6E93FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Here=20 is some more info on the local phone nos. that can be used to get into = the=20 bridge
 
China,=20 Beijing - 8529-8800 and then extension=20 1112
China, Shanghai - 5048-1818, = and then=20 dial 31000
California, Santa Clara 408-765-2663
 
Sorry=20 I couldn't find any local nos for Canada.
 
Hope=20 this helps,
Hormuzd
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On=20 Behalf Of Khosravi, Hormuzd M
Sent: Sunday, May 09, 2004 = 9:08=20 PM
To: forces-protocol@ietf.org
Subject: = [Forces-protocol]=20 Conference call - Monday 4-6 PM PST - bridge = details

Hi=20 Team
 
Here=20 are the details for the teleconference call
 
Dial in=20 # 916-356-2663
Bridge: = 2
Passcode:=20 8836206
 
Hope=20 you all will attend,
 
regards
Hormuzd
------_=_NextPart_001_01C436D7.7D6E93FC-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 19:49:17 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 TAA16976 for ; Mon, 10 May 2004 19:49: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 1BNKRN-0003Oz-Ot for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 19:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ANi9eT013072 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 19:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKLn-0002PH-0J for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 19:38: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 TAA16584 for ; Mon, 10 May 2004 19:38: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 1BNKLl-0005BX-8z for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 19:38:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNKKo-0004mK-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 19:37:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNKJV-00045o-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 19:36: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 1BNKEv-0005lU-Fp for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 19:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNK8u-0007p3-77; Mon, 10 May 2004 19:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJzJ-0005l3-K6 for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 19:15: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 TAA15756 for ; Mon, 10 May 2004 19:15: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 1BNJzI-0005CP-00 for forces-protocol@ietf.org; Mon, 10 May 2004 19:15:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJyI-0004rY-00 for forces-protocol@ietf.org; Mon, 10 May 2004 19:14: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 1BNJxH-0004Dt-00 for forces-protocol@ietf.org; Mon, 10 May 2004 19:13:03 -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 i4ANCweH018619; Mon, 10 May 2004 23:12:58 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 i4AN97aU011307; Mon, 10 May 2004 23:10:01 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 M2004051016120808894 ; Mon, 10 May 2004 16:12: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, 10 May 2004 16:12:03 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C436E4.340F2B20" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: [Forces-protocol] Conference call - are any of you having problems getting in ?? Message-ID: <468F3FDA28AA87429AD807992E22D07EF2CAD2@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference call - are any of you having problems getting in ?? Thread-Index: AcQz11JhCSlxGjhTQney6OlC89Sb4QCbCFvQACTD8CAAA1T1sA== From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , "Wang,Weiming" X-OriginalArrivalTime: 10 May 2004 23:12:03.0302 (UTC) FILETIME=[3469F860:01C436E4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 10 May 2004 16:12: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.2 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C436E4.340F2B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have Jamal, Robert, Patrick & myself on the call. Ram, David said they will be joining soon. =20 Avri, Weiming are you guys having problems joining the bridge ?? =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C436E4.340F2B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
We=20 have Jamal, Robert, Patrick & myself on the call. Ram, David said = they will=20 be joining soon.
 
Avri,=20 Weiming are you guys having problems joining the bridge = ??
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C436E4.340F2B20-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 21:20:20 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 VAA20774 for ; Mon, 10 May 2004 21:20: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 1BNLq6-0005Hl-G9 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:13:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1Dkg3020309 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLkq-0004Ys-Vy for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:08: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 VAA20421 for ; Mon, 10 May 2004 21:08: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 1BNLko-0004XU-Gf for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLjx-0004DW-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:07:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNLjQ-0003so-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLhc-0003OL-Gg; Mon, 10 May 2004 21:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLXG-0001LJ-DS for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 20:54: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 UAA19686 for ; Mon, 10 May 2004 20: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 1BNLXD-0007SN-Vq for forces-protocol@ietf.org; Mon, 10 May 2004 20:54:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLWM-00076k-00 for forces-protocol@ietf.org; Mon, 10 May 2004 20:53:22 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNLVU-0006ll-00 for forces-protocol@ietf.org; Mon, 10 May 2004 20:52:29 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 11 May 2004 09:05:04 +0800 Message-ID: <03ae01c436f1$abf895f0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07EF2C78C@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: ACK 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, 11 May 2004 08:48: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, Hormuzd, I'v just suggested to use 2 bits flag for the ACK purpose as: 00 - No any response 01 - only with negative response, no response if successful 10 - only with positive response, no response if unsuccessful 11 - response in any cases Thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 21:38: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 VAA21390 for ; Mon, 10 May 2004 21:38: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 1BNM8P-0000JO-SZ for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:32:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1WfAu001190 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNM3G-0007yx-6d for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:27: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 VAA21061 for ; Mon, 10 May 2004 21:27: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 1BNM3D-00031C-DA for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:27:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNM2G-0002gE-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:26:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNM1T-0002MH-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:25:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLwA-0006ah-M8; Mon, 10 May 2004 21:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLnj-0004y6-IH for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 21:11: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 VAA20507 for ; Mon, 10 May 2004 21:11: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 1BNLng-0005Y0-UJ for forces-protocol@ietf.org; Mon, 10 May 2004 21:11:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLmk-0005Cz-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:10:18 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNLlj-0004Yi-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:09:15 -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 i4B192Oe025246; Tue, 11 May 2004 01:09:02 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 i4B18xI6002273; Tue, 11 May 2004 01:09:10 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 M2004051018084400887 ; Mon, 10 May 2004 18:08:44 -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, 10 May 2004 18:08: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] topic 4c: Common Header: ACK Message-ID: <468F3FDA28AA87429AD807992E22D07EFA0F19@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: ACK Thread-Index: AcQ29EHs0vWnZVuHQt22wFyZ2y9YqgAACtUQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 11 May 2004 01:08:44.0784 (UTC) FILETIME=[819F5700:01C436F4] 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, 10 May 2004 18:08: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 This is fine with us. BTW, are you currently on the call ?? -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Monday, May 10, 2004 5:48 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: ACK Jamal, Hormuzd, I'v just suggested to use 2 bits flag for the ACK purpose as: 00 - No any response 01 - only with negative response, no response if successful 10 - only with positive response, no response if unsuccessful 11 - response in any cases Thank you. 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 May 10 22:02:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22801 for ; Mon, 10 May 2004 22:02: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 1BNMUL-0004td-4t for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1tL62018814 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMNd-0003gO-9S for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:48: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 VAA21816 for ; Mon, 10 May 2004 21:48: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 1BNMNa-0002EW-Dj for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:48:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMMT-0001tZ-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:47:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNMLN-0001Gy-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMJN-0002in-OU; Mon, 10 May 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 1BNMA2-0000c4-0G for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 21: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 VAA21301 for ; Mon, 10 May 2004 21:34: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 1BNM9z-0005Kq-5f for forces-protocol@ietf.org; Mon, 10 May 2004 21:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNM95-00050X-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:33:24 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNM8I-0004g2-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:32:45 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 11 May 2004 09:45:08 +0800 Message-ID: <03db01c436f7$451e4450$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: 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] Re: Notes from ForCES protocol meeting call 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, 11 May 2004 09:28: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Robert, Jamal, et al., Just some comments, for I did not catch up with the call very well. Cheers, Weiming ----- Original Message ----- From: "Putzolu, David" Robert: Is there an example of using batching without atomicity? Why do we use batching in non-atomic cases. Seems like main reason for batching is to provide atomicity. [Weiming] Sometimes may only for pipeline processing as Jamal defined. Jamal: Example of atomicity: Add this route and the NHLFE together - do not add one without the other. Robert: If I send two add route TLVs together I could set atomic flag to make them atomic, or not set atomic and they could succeed/fail independently. Could also use atomic flag to say TLVs across messages need to be atomic together. Example of batching over 4 messages: 1, 2, 3, 4 1&2 need to be atomic together, 3&4 need to be atomic together 1 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #1 is start of xaction) 2 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 1 & 2) 3 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #3 is start of xaction) 4 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 3 & 4) [Weiming] For this example, I suggest to mark the flags as: 1 has Batchflag =1 and Atomicflag =1, indicating the start of batch, and start of atomic 2 has Batchflag =1 and Atomicflag =0, indicating still during the batch, but the end of first atomic 3 has Batchflag =1 and Atomicflag =1, indicating still during the batch, and start of another atomic 4 has Batchflag =0 and Atomicflag =0, indicating end of batch, and end of second atomic [/Weiming] Another example: Adding 1000 routes in a PL message. Are they always atomic? [Weiming] Should be, or it may make things much complex. Robert: NFSv4 example, use same template to respond, replacing route value with OK or FAILED fields for each route. In success case just ACK whole message, only send detailed full message back on partial failures. Weiming: There may be many TLVs in one message. In this case default-atomic is fine - the flags are used for signaling between separate messages. E.g. if you have 100 routes you want to add atomically, send 1 message. If you want them to not be atomic, send separate messages. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 22:03:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22890 for ; Mon, 10 May 2004 22:03: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 1BNMUL-0004tt-85 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1tLwQ018830 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMNe-0003gQ-HE for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:48: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 VAA21829 for ; Mon, 10 May 2004 21:48: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 1BNMNb-0002Eg-P6 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:48:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMMU-0001tp-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:47:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNMLb-0001LC-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:46:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMJN-0002it-SH; Mon, 10 May 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 1BNMA3-0000c6-Gy for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 21: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 VAA21308 for ; Mon, 10 May 2004 21: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 1BNMA0-0005Kz-LW for forces-protocol@ietf.org; Mon, 10 May 2004 21:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNM96-00050n-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:33:25 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BNM8J-0004PM-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:32:36 -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 i4B1W6YO144954 for ; Tue, 11 May 2004 01:32:06 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 i4B1W5RQ224006 for ; Tue, 11 May 2004 03:32:05 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.16.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id DAA50550 for ; Tue, 11 May 2004 03:32:04 +0200 Message-ID: <40A02D12.40306@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: forces-protocol@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] Notes from ForCES protocol meeting call 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, 11 May 2004 03:32:02 +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: 7bit Content-Transfer-Encoding: 7bit I sent this to everybody I heard on the call, feel free to edit and forward to rest of team once it is correct. Administrivia: David Putzolu and Robert Haas taking notes, Jamal was drawing out a diagram of header fields. Participants: David (1st half only), Hormuzd, Jamal, Weiming, Robert, Patrick, Ram (on and off). --- Header fields review 16 bits - question whether 16 bits (64k) is enough if it is bytes? Maybe it should be words? Need to finalize the flags in the header still. --- Message body discussion Jamal: What's in the message body? It is a TLV - what will it look like inside? Example of adding an IPv4 route Common header: Command type = "config" TLV contained would have: Type = "add LFB entry" (could have been delete or modify) Length = (TBD) Value contains: LFB instance ID LFB type ID Flags needed Indicator that it is a IPv4 route being added The new IP route Weiming pointed out we may have messages to a whole FE rather than single LFB, all agreed. Common header: Command type = "config" TLV contained would have Type = "change FE config entry" Length = (TBD) Value contains: Indicator of what you are changing on the FE The parameters of what you are changing on the FE Robert: Do we know how the model team has hinted to configure LFBs? They may have some sort of TLV that we may decide to coordinate with. We should review what the model team comes up with. Jamal: Model team may put TLV within TLV - one big outer TLV for the add route containing a bunch of smaller TLVs within it. Model team may not have been clear - we should come up with this and also see what model team has. We should come up with this because it will affect the common header as well. Robert: When we do batching do we ever put two different command types e.g. a config and a query command into a single message? Probably not so seems OK to keep command type in common header. Some discussion on where LFB type belongs - decided to initially put 16 bits into common header for this. If the LFB type is in the header, and no LFB instance ID is in the TLV, then all LFBs of the given type in a FE are addressed. Some reserved value of LFB type in common header means to look in the TLVs to figure out what specific LFB instances are addressed. Hormuzd volunteered to send out a couple sample drawings of packet drawings for a message to all LFBs on a particular point and another to a specific instance of a LFB. --- Flags discussion & subsequence #s inside TLVs Discussed Weiming's email of Monday 8:40AM that discussed batching & atomicity, Jamal OK with it. Robert: Is there an example of using batching without atomicity? Why do we use batching in non-atomic cases. Seems like main reason for batching is to provide atomicity. Jamal: Example of atomicity: Add this route and the NHLFE together - do not add one without the other. Robert: If I send two add route TLVs together I could set atomic flag to make them atomic, or not set atomic and they could succeed/fail independently. Could also use atomic flag to say TLVs across messages need to be atomic together. Example of batching over 4 messages: 1, 2, 3, 4 1&2 need to be atomic together, 3&4 need to be atomic together 1 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #1 is start of xaction) 2 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 1 & 2) 3 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #3 is start of xaction) 4 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 3 & 4) Another example: Adding 1000 routes in a PL message. Are they always atomic? Robert: NFSv4 example, use same template to respond, replacing route value with OK or FAILED fields for each route. In success case just ACK whole message, only send detailed full message back on partial failures. Weiming: There may be many TLVs in one message. In this case default-atomic is fine - the flags are used for signaling between separate messages. E.g. if you have 100 routes you want to add atomically, send 1 message. If you want them to not be atomic, send separate messages. (Robert continues taking minutes at this point) Hormuzd: NPF can make non-atomic operations (TLVs) in the same message using array of commands in the reply flagged. Weiming: TLVs in the same message should always be treated as atomic. To complex otherwise. 3 bits priority flags, 2 batch bits (start, stop, nothing, middle), 2 ACK bits, 1 atomicity bit. Weiming: what about asking for NACKs, i.e., a response if the operation is unsuccessful only. Use 2 ACK bits instead of a single bit. LFBTypeID 16 bits with a special Opaque type (means look into the message, needed if there are LFBs of multiple types in the same message). Splitting the address space for CE and FE ID will be proposed in te draft text. Weiming: source ID and dest ID are too generic names. Proposes Source Element ID, or Source ForCES Element ID. Weiming: OK to have command types for config-response and query-response. --------------- FE to CE config msg (peering) Jamal: CE must be signaled of config operations performed directly on the FE. It this an event to the CE or a config(-resp) msg ? Hormuzd: This should be an event. Robert: There can be a config-response to whoever sent the config, and an event to whoever subscribed to such events. Jamal: the event can encapsulate the config message for simplicity. ---------------- FEM-CEM Jamal: own FE ID, CE ID and TML configuration information are passed to the FE at boot-up. When a new FE joins the NE, the FEM will indicate the change. The FE FSM can be affected by the assumption whether the FEM remains active after boot-up. Jamal will take the action item and share his experiences. ---------------- Protocol message types: Hormuzd: meaning of subscribe/unsubscribe is different from config. Weiming: use command type "event", and operation type subscribe. Robert: how is the event modeled in the LFB ? Is this like any other LFB attribute ? If yes, it can be acted upon using a config message to subscribe. Below are the three possibilities how event subscription can be specified in a ForCES message. cmd type: the command type in the common header. operation type: the type in the TLV. cmd type operation type CE ----------------------------------> FE subscribe - ----------------------------------> (Hormuzd's preference) event subscribe ----------------------------------> (Weiming+Robert) config event-subscribe ----------------------------------> (Weiming) Note that the event cmd type is also used from the FE to the CE to advertise events. We need to find out which one of the three possibilities above we want to follow. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 22:03:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23023 for ; Mon, 10 May 2004 22:03: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 1BNMUL-0004uA-Fb for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1tL3I018849 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 21:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMNi-0003gU-P2 for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:48: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 VAA21835 for ; Mon, 10 May 2004 21:48: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 1BNMNf-0002FB-SZ for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:48:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMMf-0001vC-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:47:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNMLx-0001b4-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 21:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMKL-0002vw-3G; Mon, 10 May 2004 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMCv-0001It-2W for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 21:37: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 VAA21364 for ; Mon, 10 May 2004 21:37: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 1BNMCs-0006IP-3Z for forces-protocol@ietf.org; Mon, 10 May 2004 21:37:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMBo-0005y8-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:36:13 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNMAq-0005Lh-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:35:13 -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 i4B1YxOe003737 for ; Tue, 11 May 2004 01:34:59 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 i4B1Z6Hw015637 for ; Tue, 11 May 2004 01:35:06 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 M2004051018343903342 for ; Mon, 10 May 2004 18:34:39 -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, 10 May 2004 18:34: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 Message-ID: <468F3FDA28AA87429AD807992E22D07EFA0F28@orsmsx408.jf.intel.com> Thread-Topic: Notes from ForCES protocol meeting call Thread-Index: AcQ27yuEeNTJPBUETMe1eQuzLejsPwACO6yQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 11 May 2004 01:34:39.0366 (UTC) FILETIME=[2039BA60:01C436F8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] FW: Notes from ForCES protocol meeting call 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, 10 May 2004 18:34: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 FYI -----Original Message----- From: Putzolu, David=20 Sent: Monday, May 10, 2004 5:31 PM To: Khosravi, Hormuzd M; hadi@znyx.com; Robert Haas; Ram Gopal (ram.gopal@nokia.com); Weiming; Weiming Wang Subject: Notes from ForCES protocol meeting call I sent this to everybody I heard on the call, feel free to edit and forward to rest of team once it is correct. Administrivia: David Putzolu taking notes, Jamal was=20 drawing out a diagram of header fields. --- Header fields review 16 bits - question whether 16 bits (64k) is enough if it=20 is bytes? Maybe it should be words? Need to finalize the flags in the header still. --- Message body discussion Jamal: What's in the message body? It is a TLV - what will=20 it look like inside? Example of adding an IPv4 route Common header: Command type =3D "config" TLV contained would have: Type =3D "add LFB entry" (could have been delete or modify) Length =3D (TBD) Value contains: LFB instance ID LFB type ID Flags needed Indicator that it is a IPv4 route being added The new IP route =20 Weiming pointed out we may have messages to a whole FE rather than single LFB, all agreed. Common header: Command type =3D "config" TLV contained would have Type =3D "change FE config entry" Length =3D (TBD) Value contains: Indicator of what you are changing on the FE The parameters of what you are changing on the FE Robert: Do we know how the model team has hinted to configure LFBs? They may have some sort of TLV=20 that we may decide to coordinate with. We should review what the model team comes up with. Jamal: Model team may put TLV within TLV - one big outer TLV for the add route containing a bunch of smaller TLVs within it. Model team may not have been clear - we should come up with this and also see what model team has. We should come up with this because it will affect the common header as well. Robert: When we do batching do we ever put two different command types e.g. a config and a query command into a=20 single message? Probably not so seems OK to keep command type in common header. Some discussion on where LFB type belongs - decided to initially put 16 bits into common header for this. If the LFB type is in the header, and no LFB instance ID is in the TLV, then all LFBs of the given type in a FE are addressed. Some reserved value of LFB type in common header means to look in the TLVs to figure out what specific LFB instances are addressed.=09 Hormuzd volunteered to send out a couple sample drawings of packet drawings for a message to all LFBs on a particular point and another to a specific instance of a LFB. --- Flags discussion & subsequence #s inside TLVs Discussed Weiming's email of Monday 8:40AM that discussed batching & atomicity, Jamal OK with it. Robert: Is there an example of using batching without atomicity? Why do we use batching in non-atomic cases. Seems like main reason for batching is to provide atomicity. Jamal: Example of atomicity: Add this route and the NHLFE together - do not add one without the other. Robert: If I send two add route TLVs together I could set atomic flag to make them atomic, or not set atomic and they could succeed/fail independently. Could also use atomic=20 flag to say TLVs across messages need to be atomic together. Example of batching over 4 messages: 1, 2, 3, 4 1&2 need to be atomic together, 3&4 need to be atomic together 1 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #1 is start of xaction) 2 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 1 & 2) 3 has batchflag 1 (start batch), atomicflag 1 (atomic) (FE sees batchflag 1 and atomic 1, knows #3 is start of xaction) 4 has batchflag 0 (end batch), atomicflag 1 (atomic) (FE sees batchflag 0, knows end of atomic op and commits 3 & 4) Another example: Adding 1000 routes in a PL message. Are they always atomic? Robert: NFSv4 example, use same template to respond, replacing route value with OK or FAILED fields for each route. In success case just ACK whole message, only send detailed full message back on partial failures. Weiming: There may be many TLVs in one message. In this case default-atomic is fine - the flags are used for signaling between separate messages. E.g. if you have 100 routes you want to add atomically, send 1 message. If you want them to not be atomic, send separate messages. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 10 22:19:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24189 for ; Mon, 10 May 2004 22:19: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 1BNMpf-0001Fd-QV for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 22:17:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B2HNhg004804 for forces-protocol-archive@odin.ietf.org; Mon, 10 May 2004 22:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMms-0000j6-VZ for forces-protocol-web-archive@optimus.ietf.org; Mon, 10 May 2004 22:14: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 WAA23721 for ; Mon, 10 May 2004 22:14: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 1BNMmp-0003s8-Vs for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 22:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMlx-0003W9-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 22:13:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNMlS-0003Aa-00 for forces-protocol-web-archive@ietf.org; Mon, 10 May 2004 22:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMjW-00085V-4U; Mon, 10 May 2004 22:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMXB-0005b2-Cu for forces-protocol@optimus.ietf.org; Mon, 10 May 2004 21:58: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 VAA22192 for ; Mon, 10 May 2004 21:58: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 1BNMX8-0005Xi-8k for forces-protocol@ietf.org; Mon, 10 May 2004 21:58:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMW9-0005Bl-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:57:14 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNMUw-0004YH-00 for forces-protocol@ietf.org; Mon, 10 May 2004 21:56:05 -0400 Received: from wwm1 (unverified [219.82.191.74]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 11 May 2004 10:08:37 +0800 Message-ID: <009401c436fa$87955050$020aa8c0@wwm1> From: "Weiming Wang" To: "Robert Haas" , References: <40A02D12.40306@zurich.ibm.com> Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call 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, 11 May 2004 09:51:50 +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 autolearn=no version=2.60 Robert, Ligang also attended. Cheers, Weiming ----- Original Message ----- From: "Robert Haas" To: Sent: Tuesday, May 11, 2004 9:32 AM Subject: [Forces-protocol] Notes from ForCES protocol meeting call > I sent this to everybody I heard on the call, feel free > to edit and forward to rest of team once it is correct. > > Administrivia: David Putzolu and Robert Haas taking notes, Jamal was > drawing out a diagram of header fields. > > Participants: David (1st half only), Hormuzd, Jamal, Weiming, Robert, > Patrick, Ram (on and off). > > --- > > Header fields review > > 16 bits - question whether 16 bits (64k) is enough if it > is bytes? Maybe it should be words? > > Need to finalize the flags in the header still. > > --- > > Message body discussion > > Jamal: What's in the message body? It is a TLV - what will > it look like inside? > Example of adding an IPv4 route > > Common header: Command type = "config" > TLV contained would have: > Type = "add LFB entry" (could have been delete or modify) > Length = (TBD) > Value contains: > LFB instance ID > LFB type ID > Flags needed > Indicator that it is a IPv4 route being added > The new IP route > > Weiming pointed out we may have messages to a whole FE > rather than single LFB, all agreed. > > Common header: Command type = "config" > TLV contained would have > Type = "change FE config entry" > Length = (TBD) > Value contains: > Indicator of what you are changing on the FE > The parameters of what you are changing on the FE > > Robert: Do we know how the model team has hinted to > configure LFBs? They may have some sort of TLV > that we may decide to coordinate with. We should review > what the model team comes up with. > > Jamal: Model team may put TLV within TLV - one big outer > TLV for the add route containing a bunch of smaller TLVs > within it. Model team may not have been clear - we > should come up with this and also see what model team > has. We should come up with this because it will affect > the common header as well. > > Robert: When we do batching do we ever put two different > command types e.g. a config and a query command into a > single message? Probably not so seems OK to keep command > type in common header. > > Some discussion on where LFB type belongs - decided > to initially put 16 bits into common header for this. > If the LFB type is in the header, and no LFB instance > ID is in the TLV, then all LFBs of the given type in a > FE are addressed. Some reserved value of LFB type in > common header means to look in the TLVs to figure out > what specific LFB instances are addressed. > > Hormuzd volunteered to send out a couple sample drawings > of packet drawings for a message to all LFBs on a particular > point and another to a specific instance of a LFB. > > --- > > Flags discussion & subsequence #s inside TLVs > > Discussed Weiming's email of Monday 8:40AM that discussed > batching & atomicity, Jamal OK with it. > > Robert: Is there an example of using batching without > atomicity? Why do we use batching in non-atomic cases. > Seems like main reason for batching is to provide > atomicity. > > Jamal: Example of atomicity: Add this route and the NHLFE > together - do not add one without the other. > > Robert: If I send two add route TLVs together I could set > atomic flag to make them atomic, or not set atomic and they > could succeed/fail independently. Could also use atomic > flag to say TLVs across messages need to be atomic together. > > Example of batching over 4 messages: 1, 2, 3, 4 > 1&2 need to be atomic together, 3&4 need to be atomic together > > 1 has batchflag 1 (start batch), atomicflag 1 (atomic) > (FE sees batchflag 1 and atomic 1, knows #1 is start of xaction) > 2 has batchflag 0 (end batch), atomicflag 1 (atomic) > (FE sees batchflag 0, knows end of atomic op and commits 1 & 2) > > 3 has batchflag 1 (start batch), atomicflag 1 (atomic) > (FE sees batchflag 1 and atomic 1, knows #3 is start of xaction) > 4 has batchflag 0 (end batch), atomicflag 1 (atomic) > (FE sees batchflag 0, knows end of atomic op and commits 3 & 4) > > Another example: Adding 1000 routes in a PL message. Are they > always atomic? > > Robert: NFSv4 example, use same template to respond, replacing > route value with OK or FAILED fields for each route. In success > case just ACK whole message, only send detailed full message > back on partial failures. > > Weiming: There may be many TLVs in one message. In this case > default-atomic is fine - the flags are used for signaling > between separate messages. E.g. if you have 100 routes you > want to add atomically, send 1 message. If you want them to > not be atomic, send separate messages. > > (Robert continues taking minutes at this point) > > Hormuzd: NPF can make non-atomic operations (TLVs) in the same message > using array of commands in the reply flagged. > > Weiming: TLVs in the same message should always be treated as atomic. To > complex otherwise. > > 3 bits priority flags, 2 batch bits (start, stop, nothing, middle), 2 > ACK bits, 1 atomicity bit. > > Weiming: what about asking for NACKs, i.e., a response if the operation > is unsuccessful only. Use 2 ACK bits instead of a single bit. > > LFBTypeID 16 bits with a special Opaque type (means look into the > message, needed if there are LFBs of multiple types in the same message). > > Splitting the address space for CE and FE ID will be proposed in te > draft text. > > Weiming: source ID and dest ID are too generic names. Proposes Source > Element ID, or Source ForCES Element ID. > > Weiming: OK to have command types for config-response and query-response. > > --------------- > FE to CE config msg (peering) > > Jamal: CE must be signaled of config operations performed directly on > the FE. It this an event to the CE or a config(-resp) msg ? > > Hormuzd: This should be an event. > > Robert: There can be a config-response to whoever sent the config, and > an event to whoever subscribed to such events. > > Jamal: the event can encapsulate the config message for simplicity. > > ---------------- > FEM-CEM > > Jamal: own FE ID, CE ID and TML configuration information are passed to > the FE at boot-up. When a new FE joins the NE, the FEM will indicate the > change. The FE FSM can be affected by the assumption whether the FEM > remains active after boot-up. > > Jamal will take the action item and share his experiences. > > ---------------- > Protocol message types: > > Hormuzd: meaning of subscribe/unsubscribe is different from config. > Weiming: use command type "event", and operation type subscribe. > Robert: how is the event modeled in the LFB ? Is this like any other LFB > attribute ? If yes, it can be acted upon using a config message to > subscribe. > > Below are the three possibilities how event subscription can be > specified in a ForCES message. > cmd type: the command type in the common header. > operation type: the type in the TLV. > > > cmd type operation type > CE ----------------------------------> FE > > > subscribe - > ----------------------------------> (Hormuzd's preference) > > > event subscribe > ----------------------------------> (Weiming+Robert) > > > config event-subscribe > ----------------------------------> (Weiming) > > > Note that the event cmd type is also used from the FE to the CE to > advertise events. > > We need to find out which one of the three possibilities above we want > to follow. > > > > _______________________________________________ > 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 May 11 13:05:03 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 NAA08821 for ; Tue, 11 May 2004 13:05: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 1BNaYh-0004VK-2o for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 12:56:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BGuliJ017315 for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 12:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaFA-0008UD-Np for forces-protocol-web-archive@optimus.ietf.org; Tue, 11 May 2004 12: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 MAA07181 for ; Tue, 11 May 2004 12:36: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 1BNaF9-0004Ex-1q for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 12:36:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaDq-0003l6-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 12:35:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNaDB-0003LD-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 12:34:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa5v-0006aa-9p; Tue, 11 May 2004 12:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZjq-0001Pt-6W for forces-protocol@optimus.ietf.org; Tue, 11 May 2004 12:04: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 MAA05358 for ; Tue, 11 May 2004 12:04: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 1BNZjo-0006aV-VX for forces-protocol@ietf.org; Tue, 11 May 2004 12:04:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNZiw-00069y-00 for forces-protocol@ietf.org; Tue, 11 May 2004 12:03:20 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNZiA-0005it-00 for forces-protocol@ietf.org; Tue, 11 May 2004 12:02:31 -0400 Received: from wwm1 (unverified [219.82.186.113]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 12 May 2004 00:15:15 +0800 Message-ID: <002701c43770$cc6a2630$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07EE40902@orsmsx408.jf.intel.com> <1083726882.1070.106.camel@jzny.localdomain> <0a0901c43262$4f05cae0$845c21d2@Necom.hzic.edu.cn> <4098AAEE.9030704@zurich.ibm.com> <029201c4332b$dca18640$020aa8c0@wwm1> <409A61EF.2090600@zurich.ibm.com> <000201c43433$80f91340$875c21d2@Necom.hzic.edu.cn> <1083955505.1598.50.camel@jzny.localdomain> <005c01c434b2$c0bef6a0$875c21d2@Necom.hzic.edu.cn> <1084193665.1043.143.camel@jzny.localdomain> <002401c436a5$2a6f2f90$020aa8c0@wwm1> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 11 May 2004 23:58: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Jamal, Robert, Ligang, and Hormuzd, One more thing for batch and atomicity I'v just thought of. Consider a scenario, in which a CE is configuring a FE using batch or atomicity. We used to consider that, during the batch or atomicity process, there might be no other messages except the batch or atomicity messages sent from CE to FE, but I'v just thought of that this may be not always true. For e.g., there may be heartbeat messages sent from CE to FE during the process, because they will be sent automatically and periodically. If we only use flags to indicate the batch or atomicity messages, such heartbeat messages may intervene into the batch or atomicity messages, making the batch or atomicity marked by flags incorrectly understood by CE TML or by FE PL. Therefore, we may need to limit more for batch or atomicity. For e.g., we may need to define that only messages for config, query, and state maintenance are allowed to be batched or atomically executed, that is, messages other than that are automatically excluded from batch or atomicity. A more extended thinking of this is, if we need to support parallel and multipul atomicity at the same time, that is, if we need to allow CE to send messages that interleavingly belong to different atoms? I think Jamal has raised this question before. Cheers, Weiming ----- Original Message ----- From: "Weiming Wang" To: ; Sent: Monday, May 10, 2004 11:40 PM Subject: Re: [Forces-protocol] topic 4c: Common Header: batching > Jamal, > > I'v just thought of one thing. I think if it may be better to consider the batch > and the atomicity as two separate issues. Based on your summary, I describe my > thought as follows, > > 1. Batching > PL appearance: msg chains. > Flag used: BatchFlag > BatchFlag = 1 - used by first msg and all middle msgs in the batch > = 0 - used by last of the batch msg, indicating the end of the batch > When in non-batch mode, msg is always set to BatchFlag = 0. > > Default fail mode: to do whatever it can and fail those it cannot. > > ACK mode: according to ACK flag in individual msg headers. > > The BatchFlag is actually used as a signal for TML pinepining implementation. > TML is responsible for things like MTU check and fragment. I think TML should be > also responsible for the check of PL msg boundaries, because it seems in our > current msg chain mode for batch, TML is inevitable to check the msg headers. > But hornestly, I'm not sure if this is out of the scope of TML or not. > > 2. Atomicity > PL appearance: msg chains. > Flag used: AtomicFlag > AtomicFlag = 1 - used by first msg and all middle msgs in the atomic > = 0 - used by last msg in the atomic, indicating the end of the > atomic and also as a signal for a receiver to excecute the atomic. > When in non-atomic mode, msg is always set to AtomicFlag = 0 > > Default fail mode: all or nothing > > ACK mode: according to ACK flag in individual msg headers. > > 3. Atomicity in batching > Just operate separately in the same way as described above except that the fail > mode for atomicity has previlege over that of batching, that is, if in an > atomic, fail mode must be all or nothing. > A batch may contain more than one atomic. > > > Just want to see if it helps more or less for our discussion. > > Cheers, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: "Wang,Weiming" ; > Cc: > Sent: Monday, May 10, 2004 8:54 PM > Subject: Re: [Forces-protocol] topic 4c: Common Header: batching > > > > On Sat, 2004-05-08 at 00:13, Wang,Weiming wrote: > > > Jamal, > > > > > > Thank you for the post, which makes thing much clearer. > > > > > > ----- Original Message ----- > > > From: "Jamal Hadi Salim" > > > > > > > > > > > > Ok, I just deleted everything that was said and i am going to summarize > > > > with a twist of my opinions. (I hope i read all the discussions > > > > correctly). Robert/Weiming please double check. Hopefully, this summary > > > > will allow other people to pitch in. > > > > > > > > Why do we batch? > > > > 1) to pipeline and improve throughput > > > > 2) to achieve atomic operations spanning multiple packets. > > > > > > > > Note that #1 may not be necessarily be atomic operation. > > > > > > > [Weiming]Agreed. Then you mean batch is for 1) or 1)AND 2), right? > > > > Probably both - 2) is atomic. > > > > > How about just for 2) then, it will not be called batching? > > > > Hrm. I would probably still wanna call it batching although it has other > > connotations. The simplest standalone atomic transaction is probably a > > single packet for a single transaction such as "add route X". Now lets > > say such a simple message wont fit in one packet, then you break it into > > several messages unified by the atomicity flag. Same applies when you > > group a "batch" of such unified transactions across multiple train of > > packets. So i would say, for simplicty sake lets just call it a batch. > > > > > > PL message/transaction exceeding MTU: > > > > I think the PL should carefully ensure that the messages going across > > > > are each at least going to fit in the MTU size packet. I think if we can > > > > avoid fragmentation of a command, then we should. > > > > > > > [Weiming]I just a little worry if the pipeline and the MTU requirement will > have > > > some contradiction with each other. > > > > > > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > > Yes, in fact some sort of MTU discovery might be in order. I think > > > avoiding fragmentation is of positive value. This is probably a TML > > > responsibility. > > > > > > > Agreed TML should be responsible. My worry is more when the TML is stream > > oriented (such as in the case of TCP) and there are no distinct message > > boundaries at the TML level. Someone needs to feed the PL complete PL > messages. > > For this reason it may be valuable for the PL to be pMTU aware. Thoughts? > > > > > > > > > Types of batching: > > > > > > > > 1) several PL messages in one TML level PDU. PL level header SOT and EOT > > > > indicate start and end of a train of these messages. > > > > Is this responsibility of TML or PL to put them in one PDU or that of > > > > PL? I feel it is the responsibility of PL. > > > > > > > [Weiming] I also incline for PL to define the pinelining format. Then, we > need > > > to have a batch format (not necessarily a batch msg) to be defined in the > > > protocol text. Where do you think to put it, in the protocol overviw, common > > > header, or in the protocol messages? > > > [/Weiming] > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > > Well it sort of depends on which entity is responsible for > > > non-fragmentations and hence knowing what MTU size to use. It is > > > certainly the PL's responsibility to know which msgs are batched and > > > especially which are atomically batched. > > > > > > > Ok, shall we say then that if the PL is pMTU aware it will do a better > > job? > > > > > > 2) Within one message several TLVs which require that each "atomic" unit > > > > have its own subsequence number (and treat the top header sequence > > > > number as a flat transaction number). > > > > > > > [Weiming]In this case, we need to define a batching msg, which I think > should be > > > defined by protocol msgs. > > > > Note, my view is we may not need this approach since it is too complex. > > > > > > > > > My preference is using #1 mostly because now we have to look for a trick > > > > to stash a subsequence number. too complex. You can already pack many > > > > routes for example in one message - so no need to be clever. > > > > Each message will have a unique sequence number. Start of transaction > > > > gets marked by SoT and end of transaction gets marked by EoT. And any > > > > middle messages probably marked with MoT? > > > > > > [Weiming]Can we summarize that we may need two flags, one for atomicity, and > > > another for pipelining batch? > > > > 3 flags: > > 1. Atomicity > > 2. SoT (Start of Transaction) > > 3. EoT (End of Transaction) > > > > A fourth one maybe MoT (Middle of Transaction). Not sure if it is > > needed; maybe it can be represented by Sot = 0 and Eot = 0 > > A transaction that fits within one message will always have SoT and EoT > > set to 1. > > A two phase commit will at minimal have two message. Something like: > > msg 1 := {Atomic, SoT, EoT} = { 1,1,0} > > msg ..:= { 1,0,0} > > msg ..:= { 1,0,0} > > msg ..:= { 1,0,0} > > msg last := {1,0,1} > > > > > > Weiming points to a concern about the common header introducing > > > > ovrehead. My opinion is the overhead is so small that it is irrelevant > > > > against the benefits of keeping track of subsequence numbers. > > > > > > [Weiming]Actually I more inclide to #1 also (pls see my previous reply to > > > robert), with the same idea that the header may waste less. Note that in TLV > > > mode (#2 mode), we also have to have many in the TLV, such as ACK flag, > > > subsequece number, etc. > > > > Ok. > > > > > Actually I was trying to propose another approach other than #1 and #2, > which is > > > mainly for atomicity. The approach is to let a bunch of msgs that need > atomicity > > > still be separatedly sent via TML instead of pipelining, while only using > the > > > Atomic flag to trace the start and the end of atomiciy. Do you think we need > > > this? Moreover, I was considering how we can support multipul atomicity > > > transactions in this case. > > > [/Weiming] > > > > refer > > > > > > > > > > What to do in case of failures? > > > > Lets say you sent an atomic batch of A) a del route, B) an add route and > > > > C) add route > > > > > > > > Techniques (listed by Joel Halpern once). > > > > > > > > 1) All or nothing: > > > > if B fails A should also fail; if A was done then you undo > > > [Weiming]My understanding of atomicity is just for this. > > > > > > > > 2) Fail upto: > > > > If B fails but A passes, then we just inform CE of Bs failure and dont > > > > execute C. > > > [Weiming]I'm afraid this fail model may only apply to batching msg(s). > > > [Dong Ligang] You actually describe two kind of batching. "Fail upto" can be > > > included in the first type. > > > > The difference is that in 2) you dont have to undo. But they are > > probably the same thing. > > > > > > 3) I cant remember it, but i think there was a third technique > > > > > > > [Weiming]Is it the most general one, that is, to do whatever it can do, and > fail > > > whatever it cannt do? > > > > I think so. > > > > [Dong Ligang] > > > 1) Batched PL messages are obviously in one PL level PDU. However, it is not > > > necessary that batched PL messages are in one TML level PDU. > > > > Refer to my comments above about having TML not aware of message boundaries. > > Also to my comment that the PL being aware of the MTU would help. > > > > > 2) PL level header SOT and EOT are not necessary, as the placement order in > > > one PL PDU can implicitly determine the sequence of batched messages. > > > > What about two phase commits? > > > > > 3) A field (e.g., BATCH field) in the PL messages header is used to indicate > > > whether or not this message contain multiple batchted messages. Also, this > field > > > can be used to indicate we are batching independent messages or transaction > messages. > > > > Refer to my comments above on {Atomic, SoT, EoT} then lets discuss if you > disagree. > > > > > 4) For batching of independent messages, the responses are also > independent; for > > > batching of transaction messages, the response is single. > > > > Yes, this is why it is preferable to have multiple PL level messages because > > each has its own sequence number that can be responded to. > > > > > > I think the most interesting this is what happens if FE1 executes A > > > > successfuly and FE2 both A and B but not C. You need to make sure things > > > > are synchronized > > > [Weiming]I think in broadcast case, we may have to choose to use a simple > fail > > > scheme such as all or nothing, or else, I'm just afraid it may make things > much > > > complex. > > > > in the case of 3 above, you may not care (atomic flag = 0). > > > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > > when I think of the two kinds of batching, atomic and non, I make the > > > distinction that in non-atomic, each goes on and you get a separate > > > ack/error code back on each of the component messages. With atomic, I > > > tend to support option 1 above. > > > > > > Option 2, the do until fail, would seem to me to be a different sort of > > > batching and I am not sure how useful, or safe, a variant it is. > > > > > > So should we then have two choices? One with all-or-none when atomic > > flag is set and the other with try-all mode when atomic flag is not set? > > If we are going to add the rhird one i think we need an extra flag. > > > > On Sat, 2004-05-08 at 09:10, avri@acm.org wrote: > > > I like the summaries. I get confused in the back and forth > > > conversations and don't really know how to jump in with a response. So > > > thanks. > > > > I have come to the conclusion the reason that discussions keep getting > repeated > > is because theres no good summaries so far i.e insufficient meat. This is my > first > > attempt. I am hoping we make fastr progress with this approach. > > Who is in charge of writting this section? I could rewrite the details with > the provided > > comments or whoever is in charge of it could. > > > > 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 May 11 16:44:47 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 QAA24243 for ; Tue, 11 May 2004 16:44: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 1BNe2x-0006oj-5Z for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 16:40:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BKeFPh026200 for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 16:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdgZ-0008UA-KT for forces-protocol-web-archive@optimus.ietf.org; Tue, 11 May 2004 16:17: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 QAA22290 for ; Tue, 11 May 2004 16:17: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 1BNdgX-0007BX-Up for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 16:17:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdfZ-0006kc-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 16:16:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNdeV-0006AG-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 16:14:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdbh-0007AO-7K; Tue, 11 May 2004 16:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdPE-0004WQ-GR for forces-protocol@optimus.ietf.org; Tue, 11 May 2004 15: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 PAA21404 for ; Tue, 11 May 2004 15: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 1BNdPC-0007Ia-QO for forces-protocol@ietf.org; Tue, 11 May 2004 15:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdOD-0006rq-00 for forces-protocol@ietf.org; Tue, 11 May 2004 15:58:09 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNdNI-000627-00 for forces-protocol@ietf.org; Tue, 11 May 2004 15:57:12 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4BJv5lS030932 for ; Tue, 11 May 2004 19:57:05 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 i4BJv5Os032509 for ; Tue, 11 May 2004 19:57:06 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 M2004051112563630768 for ; Tue, 11 May 2004 12:56:36 -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, 11 May 2004 12:56:36 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43792.100B5656" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07EFA1565@orsmsx408.jf.intel.com> Thread-Topic: Next Conference Call on Thursday (May 13th) Thread-Index: AcQ3kg+YblY64oUATO2VgiaBLkQXSQ== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 11 May 2004 19:56:36.0752 (UTC) FILETIME=[11423100:01C43792] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] Next Conference Call on Thursday (May 13th) 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, 11 May 2004 12:56:34 -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_01C43792.100B5656 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team =20 As we discussed on the call yesterday, I'll arrange for the next conference call on Thursday (May 13th) from 4-6 PM. Hope this will work for all of you. =20 Pls do let us know =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C43792.100B5656 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Team
 
As we = discussed on=20 the call yesterday, I'll arrange for the next conference call on = Thursday (May=20 13th) from 4-6 PM.
Hope = this will work=20 for all of you.
 
Pls do = let us=20 know
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C43792.100B5656-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 11 20:11: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 UAA08517 for ; Tue, 11 May 2004 20:11: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 1BNhEy-0005z9-Ru for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 20:04:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C04qRa023008 for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 20:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh1y-0003C4-26 for forces-protocol-web-archive@optimus.ietf.org; Tue, 11 May 2004 19: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 TAA07250 for ; Tue, 11 May 2004 19:51: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 1BNh1w-0001Qs-9s for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 19:51:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNh10-0000ze-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 19:50:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNh0E-0000Z0-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 19:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgo2-0000MP-DN; Tue, 11 May 2004 19: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 1BNgiU-000788-G2 for forces-protocol@optimus.ietf.org; Tue, 11 May 2004 19: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 TAA06111 for ; Tue, 11 May 2004 19:31: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 1BNgiS-0000HI-LG for forces-protocol@ietf.org; Tue, 11 May 2004 19:31:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNghS-0007ci-00 for forces-protocol@ietf.org; Tue, 11 May 2004 19:30:14 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNggT-0006mr-00 for forces-protocol@ietf.org; Tue, 11 May 2004 19:29:13 -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 i4BNSrNJ027913; Tue, 11 May 2004 23:28:53 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 i4BNSxfm019383; Tue, 11 May 2004 23:28: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 M2004051116283231452 ; Tue, 11 May 2004 16:28: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, 11 May 2004 16:28: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 4c: Common Header: batching Message-ID: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: batching Thread-Index: AcQ3deRskiD2deRSReWROvEu9DiNAwANfuLA From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 11 May 2004 23:28:32.0329 (UTC) FILETIME=[AC554390:01C437AF] 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, 11 May 2004 16:28: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, All You have raised 2 good points. Thanks for giving this more thought. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang One more thing for batch and atomicity I'v just thought of. Consider a scenario, in which a CE is configuring a FE using batch or atomicity. We used to consider that, during the batch or atomicity process, there might be no other messages except the batch or atomicity messages sent from CE to FE, but I'v just thought of that this may be not always true. For e.g., there may be heartbeat messages sent from CE to FE during the process, because they will be sent automatically and periodically. If we only use flags to indicate the batch or atomicity messages, such heartbeat messages may intervene into the batch or atomicity messages, making the batch or atomicity marked by flags incorrectly understood by CE TML or by FE PL. [HK] If we use 2 bits flag for batching, we can easily solve this problem. E.g. 00- means no batch 01 - means start of batch (SoB) 10 - means middle of batch (MoB) 11 - means end of batch (EoB) Therefore, we may need to limit more for batch or atomicity. For e.g., we may need to define that only messages for config, query, and state maintenance are allowed to be batched or atomically executed, that is, messages other than that are automatically excluded from batch or atomicity. [HK] This is another way to further protect against this, I think we should do both (Use 2 bits and specify which msgs cannot be batched)..thoughts ? A more extended thinking of this is, if we need to support parallel and multipul atomicity at the same time, that is, if we need to allow CE to send messages that interleavingly belong to different atoms? I think Jamal has raised this question before. [HK] We can easily solve this using same Sequence No or lets call it Transaction Seq No for all messages belonging to the same batch. That's how its done in a lot of protocols...what do 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 May 11 23:22: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 XAA16821 for ; Tue, 11 May 2004 23:22: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 1BNkI3-0001Yt-RO for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 23:20:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C3KFcV005994 for forces-protocol-archive@odin.ietf.org; Tue, 11 May 2004 23:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNkGH-0001Ii-Dl for forces-protocol-web-archive@optimus.ietf.org; Tue, 11 May 2004 23:18: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 XAA16679 for ; Tue, 11 May 2004 23:18: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 1BNkGF-00062v-JI for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 23:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNkFG-0005aR-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 23:17:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNkEA-0004lx-00 for forces-protocol-web-archive@ietf.org; Tue, 11 May 2004 23:16:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNk4I-0007OL-Pf; Tue, 11 May 2004 23:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNjw8-0005xU-Lx for forces-protocol@optimus.ietf.org; Tue, 11 May 2004 22:57: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 WAA15988 for ; Tue, 11 May 2004 22:57: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 1BNjw5-0005bP-9C for forces-protocol@ietf.org; Tue, 11 May 2004 22:57:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNjvA-0005AN-00 for forces-protocol@ietf.org; Tue, 11 May 2004 22:56:37 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNjug-0004jQ-00 for forces-protocol@ietf.org; Tue, 11 May 2004 22:56:06 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 12 May 2004 11:08:49 +0800 Message-ID: <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 12 May 2004 10:52: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, and all, Thank you for the comments. ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, All You have raised 2 good points. Thanks for giving this more thought. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang One more thing for batch and atomicity I'v just thought of. Consider a scenario, in which a CE is configuring a FE using batch or atomicity. We used to consider that, during the batch or atomicity process, there might be no other messages except the batch or atomicity messages sent from CE to FE, but I'v just thought of that this may be not always true. For e.g., there may be heartbeat messages sent from CE to FE during the process, because they will be sent automatically and periodically. If we only use flags to indicate the batch or atomicity messages, such heartbeat messages may intervene into the batch or atomicity messages, making the batch or atomicity marked by flags incorrectly understood by CE TML or by FE PL. [HK] If we use 2 bits flag for batching, we can easily solve this problem. E.g. 00- means no batch 01 - means start of batch (SoB) 10 - means middle of batch (MoB) 11 - means end of batch (EoB) [Weiming] Seems reasonable. So, we may also need two bits for atomicity. Therefore, we may need to limit more for batch or atomicity. For e.g., we may need to define that only messages for config, query, and state maintenance are allowed to be batched or atomically executed, that is, messages other than that are automatically excluded from batch or atomicity. [HK] This is another way to further protect against this, I think we should do both (Use 2 bits and specify which msgs cannot be batched)..thoughts ? [Weiming]If we use two bits flags, physically we don't need to specify with msgs can or cannot be batched. But I agree it is still of some meaning semantically to do so, that is, e.g., a heartbeat event msg should not be batched. A more extended thinking of this is, if we need to support parallel and multipul atomicity at the same time, that is, if we need to allow CE to send messages that interleavingly belong to different atoms? I think Jamal has raised this question before. [HK] We can easily solve this using same Sequence No or lets call it Transaction Seq No for all messages belonging to the same batch. That's how its done in a lot of protocols...what do you guys think ? [Weiming] Yes, that was also one of my thought (in the discussion with Robert). But I just think purely using the same SN for all batched msgs or atomicity msgs may result in difficulty and ambiguity for responses/ACKs (then we may have several responses/ACSs that have the same SN and make sender at a loss which to which?). As a result, I just think we may need something like a SubSN for batching and atomicity. We may have two schemes to use: 1) With the main SN the same, and with the SubSN different for msgs belong to the same batch or atomicity. In this case, the SubSN should be large enough able to contain allowed max number of batched msgs. I think we may need at least 8 bits for such SubSN. 2) With the main SN incrementally changd as normal, but with the SubSN keeing the same for msgs in the same batch or atomicity while incrementally changed for different batches or atomicities. In this case, the SubSN actually acts as a counter and indicator for different parallel batches or atomicities, therefore, the space for this SubSN need to be as large as the max allowed parallel batch or atomicity numbers. I think we may only need 4 bits for such SubSN, that is, we only allow 16 batches or atomicities parallelly processed. Hope the above schemes make a little sense. But note that, if we decide not to support parallel transactions/batch/atomicity, we may not need to consider the schemes, instead, the 2 bits flags for batch or atomicity as mentioned above is enough. [/Weiming] Regards Hormuzd Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 07:06:40 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 HAA24106 for ; Wed, 12 May 2004 07:06: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 1BNrYF-0007fK-1O for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:05:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CB5RNv029466 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrTz-0006yD-J7 for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 07: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 HAA23899 for ; Wed, 12 May 2004 07:00: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 1BNrTv-00003e-EA for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:00:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrT1-0007LG-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:00:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNrSP-0006oe-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 06:59:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrNA-0005ih-VM; Wed, 12 May 2004 06:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrK5-0005IP-9p for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 06:50: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 GAA23513 for ; Wed, 12 May 2004 06:50: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 1BNrK1-0002i2-6a for forces-protocol@ietf.org; Wed, 12 May 2004 06:50:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrJ1-0002Ct-00 for forces-protocol@ietf.org; Wed, 12 May 2004 06:49:43 -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 1BNrHw-0001R3-00 for forces-protocol@ietf.org; Wed, 12 May 2004 06:48:36 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051203524627:612 ; Wed, 12 May 2004 03:52:46 -0700 Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas , Weiming , Hormuzd M Cc: forces-protocol@ietf.org In-Reply-To: <40A02D12.40306@zurich.ibm.com> References: <40A02D12.40306@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1084358909.1047.17.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 05/12/2004 03:52:46 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/12/2004 03:52:53 AM, Serialize complete at 05/12/2004 03:52:53 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: 12 May 2004 06:48:29 -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-05-10 at 21:32, Robert Haas wrote: > > cmd type operation type > CE ----------------------------------> FE > > > subscribe - > ----------------------------------> (Hormuzd's preference) > > > event subscribe > ----------------------------------> (Weiming+Robert) > > > config event-subscribe > ----------------------------------> (Weiming) > I dont see any difference vetween the last two. They seem cleaner than the first one, but i cant really conclude that until i see how the message body looks like. Seems to me like you need to specify which is/are the event(s) of interest. Also you should be able to subscribe to multiple events in one PL message. Lets also discuss the events being sent from CE->FE while we are talking about this. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 07:20:44 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 HAA24804 for ; Wed, 12 May 2004 07:20: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 1BNrkA-0001e9-Uu for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:17:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CBHkj4006325 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrhO-0001CS-1V for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 07:14: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 HAA24523 for ; Wed, 12 May 2004 07:14: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 1BNrhN-0007RA-Ji for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:14:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrgN-0006rl-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:13:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNrfU-0006M5-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:12:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrcf-0000UZ-IP; Wed, 12 May 2004 07:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrZh-000860-76 for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 07:06: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 HAA24145 for ; Wed, 12 May 2004 07:06: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 1BNrZc-0003By-UW for forces-protocol@ietf.org; Wed, 12 May 2004 07:06:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrYi-0002fT-00 for forces-protocol@ietf.org; Wed, 12 May 2004 07:05: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 1BNrXu-00029e-00 for forces-protocol@ietf.org; Wed, 12 May 2004 07:05:06 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051204092119:621 ; Wed, 12 May 2004 04:09:21 -0700 Subject: Re: [Forces-protocol] Next Conference Call on Thursday (May 13th) From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07EFA1565@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07EFA1565@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084359905.1049.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 05/12/2004 04:09:21 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/12/2004 04:09:23 AM, Serialize complete at 05/12/2004 04:09:23 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: 12 May 2004 07:05: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 I dont think we should hold the meeting if the action items have not be responded to. And it should be a all-or-none mode ;-> Meetings tend to be a waste of time if all they do is pile up action items. Maybe move it to Friday or the weekend. I am going to followup with mine soon after i catch up with all emails. cheers, jamal On Tue, 2004-05-11 at 15:56, Khosravi, Hormuzd M wrote: > Hi Team > > As we discussed on the call yesterday, I'll arrange for the next > conference call on Thursday (May 13th) from 4-6 PM. > Hope this will work for all of you. > > Pls do let us know > > Thanks > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 07:29:56 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 HAA25092 for ; Wed, 12 May 2004 07: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 1BNruF-0003Sa-N7 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:28:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CBSBQo013301 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 07:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrm7-0001u1-W1 for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 07:19: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 HAA24741 for ; Wed, 12 May 2004 07:19: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 1BNrm7-0002FQ-Es for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:19:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrl8-0001jI-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:18:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNrk6-00012w-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 07:17:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNrgX-000150-CL; Wed, 12 May 2004 07: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 1BNreX-0000if-1R for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 07:11: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 HAA24455 for ; Wed, 12 May 2004 07:11: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 1BNreS-0005q2-Gv for forces-protocol@ietf.org; Wed, 12 May 2004 07:11:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNrdc-0005Kb-00 for forces-protocol@ietf.org; Wed, 12 May 2004 07:11: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 1BNrcm-0004or-00 for forces-protocol@ietf.org; Wed, 12 May 2004 07:10:08 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051204142364:627 ; Wed, 12 May 2004 04:14:23 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header: batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Wang,Weiming" Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org In-Reply-To: <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1084360207.1049.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 05/12/2004 04:14:24 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/12/2004 04:14:25 AM, Serialize complete at 05/12/2004 04:14: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: 12 May 2004 07:10: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 Weiming, please take over the text for batching since you are already doing a good job collecting the info. I dont like things that end with flag like batchflag - it is already part of flag, so if you call it batch for example, should be sufficient. Comments on email follow On Tue, 2004-05-11 at 22:52, Wang,Weiming wrote: > Hormuzd, and all, > > Thank you for the comments. > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > Weiming, All > > You have raised 2 good points. Thanks for giving this more thought. > > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang > > One more thing for batch and atomicity I'v just thought of. > Consider a scenario, in which a CE is configuring a FE using batch or atomicity. > We used to consider that, during the batch or atomicity process, there might be > no other messages except the batch or atomicity messages sent from CE to FE, but > I'v just thought of that this may be not always true. For e.g., there may be > heartbeat messages sent from CE to FE during the process, because they will be > sent automatically and periodically. If we only use flags to indicate the batch > or atomicity messages, such heartbeat messages may intervene into the batch or > atomicity messages, making the batch or atomicity marked by flags incorrectly > understood by CE TML or by FE PL. > [HK] If we use 2 bits flag for batching, we can easily solve this problem. > E.g. 00- means no batch > 01 - means start of batch (SoB) > 10 - means middle of batch (MoB) > 11 - means end of batch (EoB) > [Weiming] Seems reasonable. So, we may also need two bits for atomicity. I am trying to see why you need two bits. There are only two pieces of information that need to be sent: atomic start/yes and atomic end/no. You only need one bit for that 1 or 0. > Therefore, we may need to limit more for batch or atomicity. For e.g., we may > need to define that only messages for config, query, and state maintenance are > allowed to be batched or atomically executed, that is, messages other than that > are automatically excluded from batch or atomicity. > [HK] This is another way to further protect against this, I think we should do > both > (Use 2 bits and specify which msgs cannot be batched)..thoughts ? > [Weiming]If we use two bits flags, physically we don't need to specify with msgs > can or cannot be batched. But I agree it is still of some meaning semantically > to do so, that is, e.g., a heartbeat event msg should not be batched. I think if you just set the flag to off, you sould be able to distinguish the atomic scenario easily. > A more extended thinking of this is, if we need to support parallel and multipul > atomicity at the same time, that is, if we need to allow CE to send messages > that interleavingly belong to different atoms? I think Jamal has raised this > question before. > [HK] We can easily solve this using same Sequence No or lets call it > Transaction Seq No for all messages belonging to the same batch. That's > how its done in a lot of protocols...what do you guys think ? > > [Weiming] Yes, that was also one of my thought (in the discussion with Robert). > But I just think purely using the same SN for all batched msgs or atomicity msgs > may result in difficulty and ambiguity for responses/ACKs (then we may have > several responses/ACSs that have the same SN and make sender at a loss which to > which?). As a result, I just think we may need something like a SubSN for > batching and atomicity. Yes, this is the headache-causing part! > We may have two schemes to use: > > 1) With the main SN the same, and with the SubSN different for msgs belong to > the same batch or atomicity. In this case, the SubSN should be large enough able > to contain allowed max number of batched msgs. I think we may need at least 8 > bits for such SubSN. We could steal subSN from the T part of the TLV. > 2) With the main SN incrementally changd as normal, but with the SubSN keeing > the same for msgs in the same batch or atomicity while incrementally changed for > different batches or atomicities. In this case, the SubSN actually acts as a > counter and indicator for different parallel batches or atomicities, therefore, > the space for this SubSN need to be as large as the max allowed parallel batch > or atomicity numbers. I think we may only need 4 bits for such SubSN, that > is, we only allow 16 batches or atomicities parallelly processed. > 16 add route per PL message may not be so good. I am going to go and think about this and say something more meaningful. > Hope the above schemes make a little sense. But note that, if we decide not to > support parallel transactions/batch/atomicity, we may not need to consider the > schemes, instead, the 2 bits flags for batch or atomicity as mentioned above is > enough. Agreed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 09:06: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 JAA29967 for ; Wed, 12 May 2004 09:06: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 1BNtKZ-0003LG-5g for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 08:59:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CCxRxo012847 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 08:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNt9g-0001NL-Jv for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 08:48: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 IAA28835 for ; Wed, 12 May 2004 08:48: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 1BNt9f-0001sS-DS for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 08:48:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNt8n-0001Lq-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 08:47:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNt7o-0000ou-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 08:46:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsxu-0007IU-Rw; Wed, 12 May 2004 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNswH-0006xH-Kd for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 08:34: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 IAA28070 for ; Wed, 12 May 2004 08:34: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 1BNswG-0002La-En for forces-protocol@ietf.org; Wed, 12 May 2004 08:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsvB-0001XK-00 for forces-protocol@ietf.org; Wed, 12 May 2004 08:33: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 1BNstj-0000WF-00 for forces-protocol@ietf.org; Wed, 12 May 2004 08:31:43 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051205355691:704 ; Wed, 12 May 2004 05:35:56 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: forces-protocol@ietf.org Cc: Hormuzd M , Weiming Wang , Robert Haas Organization: ZNYX Networks Message-Id: <1084365100.1047.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 05/12/2004 05:35:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/12/2004 05:35:58 AM, Serialize complete at 05/12/2004 05:35:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] FEM/CEM experiences 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: 12 May 2004 08:31: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 This is to start the discussion on FEM/CEM interface as well as respond to my action item from the concal. The FEM/CEM interface is used for configuration of non-protocol specific parametrization. In our implementation we used it for: 1) a) selecting the number of connections to be used. Example: "use 3 UDP multicast + one TCP connection" b) describing details about each of the connections. Example "for UDP multicast connection 1 use IP address a.b.c.d port x" The above could be seen as TML specific now - i am not sure if that gets rid of the need for xEM. 2) In our case an FE could be issued a set of PIDs which are a 32 bit number with 32 bit mask. This was because there were multiple IDs that could be allocated per FE. In the current thought process we are saying a FE can only have one ID; however, the FE could still obtain its ID via the FEM. Example, in one specific hardware, the FE on bootup could discover the slotID and chassi ID it was on and pass that to the forces s/ware via the FEM. 3) Security parameterization such as keys etc. In order to have the forces s/ware independent, we had decided but never implemented that the security key exchanges will happen elsewehre and the forces s/ware will be notified of the parametrization via FEM. 4) Connection setup parametes Example "send up to 3 association messages each 1 second apart" Vs " send upto 4 association messages with increasing exponential timeout". 5) probably the most important piece we found: controlling the FE s/ware and parametrization throughout the life of the FE s/ware daemon. This is also implies FEM-CEM interface was alive during this phase. a) The FE may get its own paramters localy (such as the ID to use. We however found it useful to have the FEM in continous contact with the CEM because we could dynamically change its parameters (example adding a new connection to scale things). b) As well we could shutdown a FE via its FEM interface etc. Hopefully that captures it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 10:00:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04878 for ; Wed, 12 May 2004 10:00: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 1BNuDP-0001TN-DN for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 09:56:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CDu73s005642 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 09:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtx6-0004Es-NF for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 09:39: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 JAA02401 for ; Wed, 12 May 2004 09:39: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 1BNtx4-0005bi-Vv for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 09:39:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNtvw-00052S-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 09:38:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNtuj-0003zP-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 09:36:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtlJ-0001NI-Mm; Wed, 12 May 2004 09:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNtaf-00073N-K0 for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 09:16: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 JAA00671 for ; Wed, 12 May 2004 09:16: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 1BNtad-0000y9-N4 for forces-protocol@ietf.org; Wed, 12 May 2004 09:16:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNtZe-0000SG-00 for forces-protocol@ietf.org; Wed, 12 May 2004 09:15:03 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BNtXi-0006k4-00 for forces-protocol@ietf.org; Wed, 12 May 2004 09:14:04 -0400 Received: from wwm1 (unverified [219.82.165.39]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Wed, 12 May 2004 21:25:40 +0800 Message-ID: <007f01c43822$447665b0$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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: Wed, 12 May 2004 21:08: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.2 required=5.0 tests=AWL autolearn=no version=2.60 Jamal,and all, I realize now the first thing we may need to decide is if we need to parallelly support multi-transactions of atomicity and batch, because it affects other definitions like the flags and the SN usage. My opinion is, we may need to use parallel atomicity and batch, because they seem useful when we sometimes want to simulteneously configure several LFBs with their attributes. E.g., an CE is adding many routes to a forwarder LFB in a FE, which we set as an atomicity and may last for many messages, therefore may also last for a period of time. During the period, CE may also want to config other LFBs with atomicity. If our protocol does not support multi-atomicity at the same time, we have to let CE have the 'add route' atomicity done before begin another atomicity to configure other LFBs. Jamal, I suppose you tend to use parallel atomicity because you first raise this, but not very sure. How about other guys thoughts? Pls also see some more replies inline. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > Weiming, please take over the text for batching since you are already > doing a good job collecting the info. I dont like things that end with > flag like batchflag - it is already part of flag, so if you call it > batch for example, should be sufficient. > [WeimingRe] How about let's just discuss the techniques first, leaving the writing the last thing to do. I think it is relatively easy thing after we'v resolved all technically. Talking about the flag name, I suppose if we can uniformly use a 3 letter format as the name, just like TCP did, such as names as ACK(or RSP?) for response policy, PRO for priority, BAT(or BTH) for batch, ATM(or ATO) for atomicity)? > Comments on email follow > > On Tue, 2004-05-11 at 22:52, Wang,Weiming wrote: > > Hormuzd, and all, > > > > Thank you for the comments. > > > > ----- Original Message ----- > > From: "Khosravi, Hormuzd M" > > > > Weiming, All > > > > You have raised 2 good points. Thanks for giving this more thought. > > > > -----Original Message----- > > From: forces-protocol-admin@ietf.org > > [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang > > > > One more thing for batch and atomicity I'v just thought of. > > Consider a scenario, in which a CE is configuring a FE using batch or atomicity. > > We used to consider that, during the batch or atomicity process, there might be > > no other messages except the batch or atomicity messages sent from CE to FE, but > > I'v just thought of that this may be not always true. For e.g., there may be > > heartbeat messages sent from CE to FE during the process, because they will be > > sent automatically and periodically. If we only use flags to indicate the batch > > or atomicity messages, such heartbeat messages may intervene into the batch or > > atomicity messages, making the batch or atomicity marked by flags incorrectly > > understood by CE TML or by FE PL. > > [HK] If we use 2 bits flag for batching, we can easily solve this problem. > > E.g. 00- means no batch > > 01 - means start of batch (SoB) > > 10 - means middle of batch (MoB) > > 11 - means end of batch (EoB) > > [Weiming] Seems reasonable. So, we may also need two bits for atomicity. > > I am trying to see why you need two bits. There are only two pieces of > information that need to be sent: atomic start/yes and atomic end/no. > You only need one bit for that 1 or 0. [WeimingRe]I suppose if we decide to support multi-atomicity and batch, and to use something like SubSN, we may not need to use two bits. Only one bit is enough. > > Therefore, we may need to limit more for batch or atomicity. For e.g., we may > > need to define that only messages for config, query, and state maintenance are > > allowed to be batched or atomically executed, that is, messages other than that > > are automatically excluded from batch or atomicity. > > [HK] This is another way to further protect against this, I think we should do > > both > > (Use 2 bits and specify which msgs cannot be batched)..thoughts ? > > [Weiming]If we use two bits flags, physically we don't need to specify with msgs > > can or cannot be batched. But I agree it is still of some meaning semantically > > to do so, that is, e.g., a heartbeat event msg should not be batched. > > I think if you just set the flag to off, you sould be able to > distinguish the atomic scenario easily. > > > A more extended thinking of this is, if we need to support parallel and multipul > > atomicity at the same time, that is, if we need to allow CE to send messages > > that interleavingly belong to different atoms? I think Jamal has raised this > > question before. > > [HK] We can easily solve this using same Sequence No or lets call it > > Transaction Seq No for all messages belonging to the same batch. That's > > how its done in a lot of protocols...what do you guys think ? > > > > [Weiming] Yes, that was also one of my thought (in the discussion with Robert). > > But I just think purely using the same SN for all batched msgs or atomicity msgs > > may result in difficulty and ambiguity for responses/ACKs (then we may have > > several responses/ACSs that have the same SN and make sender at a loss which to > > which?). As a result, I just think we may need something like a SubSN for > > batching and atomicity. > > Yes, this is the headache-causing part! > > > We may have two schemes to use: > > > > 1) With the main SN the same, and with the SubSN different for msgs belong to > > the same batch or atomicity. In this case, the SubSN should be large enough able > > to contain allowed max number of batched msgs. I think we may need at least 8 > > bits for such SubSN. > > We could steal subSN from the T part of the TLV. [WeimingRe]I'm thinking. > > > 2) With the main SN incrementally changd as normal, but with the SubSN keeing > > the same for msgs in the same batch or atomicity while incrementally changed for > > different batches or atomicities. In this case, the SubSN actually acts as a > > counter and indicator for different parallel batches or atomicities, therefore, > > the space for this SubSN need to be as large as the max allowed parallel batch > > or atomicity numbers. I think we may only need 4 bits for such SubSN, that > > is, we only allow 16 batches or atomicities parallelly processed. > > > > 16 add route per PL message may not be so good. I am going to go and > think about this and say something more meaningful. [Weiming]Here the 16 batches actually mean 16 parallel batches the TML can support. Every batch or atomicity may still contain as many messages as we like. So, the allowed routes to be added in a batch is not limited to 16. Here, one more important thing I hope we can make clear. That is, my thought has tent to use message chains for batch, which seems you also tend. I'm not sure when you mention '16 add route per PL message', do you mean we may need to use TLV chains for batch also? > > Hope the above schemes make a little sense. But note that, if we decide not to > > support parallel transactions/batch/atomicity, we may not need to consider the > > schemes, instead, the 2 bits flags for batch or atomicity as mentioned above is > > enough. > > Agreed. > > 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 May 12 12:30: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 MAA23568 for ; Wed, 12 May 2004 12:30: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 1BNwJx-0005mq-SC for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 12:11:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGB1Dm022231 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 12: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 1BNvmq-0005oN-5x for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 11:36: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 LAA18168 for ; Wed, 12 May 2004 11:36: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 1BNvmZ-00030T-9e for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 11:36:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvkN-0001oi-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 11:34:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNvi7-0000xD-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 11:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvOV-00030V-OY; Wed, 12 May 2004 11:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuNZ-0007X7-Cd for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 10:06: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 KAA05872 for ; Wed, 12 May 2004 10:06:34 -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 1BNuNX-0002vy-7A for forces-protocol@ietf.org; Wed, 12 May 2004 10:06:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNuLH-0001wl-00 for forces-protocol@ietf.org; Wed, 12 May 2004 10:04:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BNuIP-0000vf-00 for forces-protocol@ietf.org; Wed, 12 May 2004 10:01:17 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNuIO-0001HA-6I for forces-protocol@ietf.org; Wed, 12 May 2004 14:01:16 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <007f01c43822$447665b0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 12 May 2004 16:01:10 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 12 maj 2004, at 15.08, Weiming Wang wrote: > Jamal, I suppose you tend to use parallel atomicity because you first > raise > this, but not very sure. How about other guys thoughts? > > I would worry about introducing great amounts of complexity to the protocol. While i see value in atomic operations, i think they should be kept to a minimum as opposed to non-atomic batching - which is just for transport convenience and can be used freely as long as there is a sperate status per operation. I thus think that the mechanism should be kept simple. Since each transaction has its own id, i see no reason a heartbeat or other command could not be dealt with separately as it arrived without needing special flags. I also think multiple atomic ops could be dealt with in parallel without special mechanisms - the CE should not send a dependent op until the preceding atomic op has completed successfully. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 13:07:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27079 for ; Wed, 12 May 2004 13:07: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 1BNxAJ-0003GT-Ny for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 13:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CH57a2012549 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 13:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwtH-0006N6-VV for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 12:47: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 MAA25757 for ; Wed, 12 May 2004 12:47: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 1BNwtG-0005d1-Bv for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 12:47:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwsG-00055v-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 12:46:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNwr9-0004Fz-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 12:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwfR-0000Ka-W6; Wed, 12 May 2004 12:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwRX-0000uz-Au for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 12:18: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 MAA22755 for ; Wed, 12 May 2004 12:18: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 1BNwRV-00076w-Jx for forces-protocol@ietf.org; Wed, 12 May 2004 12:18:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwQi-0006Y3-00 for forces-protocol@ietf.org; Wed, 12 May 2004 12:18: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 1BNwNQ-0005RV-00 for forces-protocol@ietf.org; Wed, 12 May 2004 12:14:36 -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 i4CGEkFk016637; Wed, 12 May 2004 16:14:46 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 i4CGE8ta028428; Wed, 12 May 2004 16:14:33 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 M2004051209135926913 ; Wed, 12 May 2004 09:13: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); Wed, 12 May 2004 09:13: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] Next Conference Call on Thursday (May 13th) Message-ID: <468F3FDA28AA87429AD807992E22D07EFA1C7D@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Next Conference Call on Thursday (May 13th) Thread-Index: AcQ4EP2roCCO6tKfS8S9iugynCXQngAKvoBg From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 12 May 2004 16:13:58.0470 (UTC) FILETIME=[2183DE60:01C4383C] 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, 12 May 2004 09:13: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 Jamal, I was planning to post the text today for my action item just like you. Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, May 12, 2004 4:05 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Thursday (May 13th) I dont think we should hold the meeting if the action items have not be responded to. And it should be a all-or-none mode ;-> Meetings tend to be a waste of time if all they do is pile up action items. Maybe move it to Friday or the weekend. I am going to followup with mine soon after i catch up with all emails. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 16:06: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 QAA07928 for ; Wed, 12 May 2004 16:06: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 1BNzwM-0002Xk-K5 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 16:02:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CK2sqo009777 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 16:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzrO-0000qR-ES for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:57: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 PAA07380 for ; Wed, 12 May 2004 15:57: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 1BNzrN-0001gC-0x for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 15:57:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzqL-00018A-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 15:56:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzp9-00008w-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 15:55:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzlq-0007dC-VA; Wed, 12 May 2004 15:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzcA-000503-Dg for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 15:42: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 OAA02796 for ; Wed, 12 May 2004 14:53:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyrI-0007cf-KW for forces-protocol@ietf.org; Wed, 12 May 2004 14:53:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyqJ-00075o-00 for forces-protocol@ietf.org; Wed, 12 May 2004 14:52:35 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BNyp8-00066P-00 for forces-protocol@ietf.org; Wed, 12 May 2004 14:51:22 -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 i4CIpJFk023675; Wed, 12 May 2004 18:51:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i4CIoftc028517; Wed, 12 May 2004 18:51:07 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 M2004051211503022895 ; Wed, 12 May 2004 11:50:30 -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, 12 May 2004 11:50: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: [Forces-protocol] Notes from ForCES protocol meeting call Message-ID: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Notes from ForCES protocol meeting call Thread-Index: AcQ4DrIyvsQOivjoSwGtAhCPAXZ+CgAQeccg From: "Khosravi, Hormuzd M" To: , "Robert Haas" , "Weiming" Cc: X-OriginalArrivalTime: 12 May 2004 18:50:19.0734 (UTC) FILETIME=[F92F2760:01C43851] 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, 12 May 2004 11:50: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 Ok, I am fine with #2 below since it seems to be the preference of most of you guys. I guess our definition of cleaner is very different :) Anyways, we can close on this one for now (atleast from my side) Jamal, to address your last questions...I don't see any events from CE to FE, other than CE State changes which are part of the State Maintenance msgs (I think). So an Event msg from CE to FE is implicitly a Event Subscribe msg, in my opinion. Other thoughts on this ? BTW, have we decided on separate messages for HBs or is it part of events ? If this is part of event then this might be another Event msg from CE to FE. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >=20 > cmd type operation type > CE ----------------------------------> FE >=20 >=20 > subscribe - > ----------------------------------> (Hormuzd's preference) >=20 >=20 > event subscribe > ----------------------------------> (Weiming+Robert) >=20 >=20 > config event-subscribe > ----------------------------------> (Weiming) >=20 I dont see any difference vetween the last two. They seem cleaner than the first one, but i cant really conclude that until i see how the message body looks like.=20 Seems to me like you need to specify which is/are the event(s) of interest. Also you should be able to subscribe to multiple events in one PL message.=20 Lets also discuss the events being sent from CE->FE while we are talking about this. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 12 17:50: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 RAA13643 for ; Wed, 12 May 2004 17:50: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 1BO1YE-0004H7-DG for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 17:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CLk6QQ016433 for forces-protocol-archive@odin.ietf.org; Wed, 12 May 2004 17:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1TB-0002vV-6i for forces-protocol-web-archive@optimus.ietf.org; Wed, 12 May 2004 17: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 RAA13287 for ; Wed, 12 May 2004 17: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 1BO1T8-0007hf-Sh for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 17:40:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1Rp-0006fr-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 17:39:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO1Qg-00066I-00 for forces-protocol-web-archive@ietf.org; Wed, 12 May 2004 17:38:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1NV-0000ap-2T; Wed, 12 May 2004 17: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 1BO1Al-00064a-AL for forces-protocol@optimus.ietf.org; Wed, 12 May 2004 17:21: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 RAA12601 for ; Wed, 12 May 2004 17:21: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 1BO1Ai-0005sN-UF for forces-protocol@ietf.org; Wed, 12 May 2004 17:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO19p-0005NM-00 for forces-protocol@ietf.org; Wed, 12 May 2004 17:20:54 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BO19J-0004tB-00 for forces-protocol@ietf.org; Wed, 12 May 2004 17:20:21 -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 i4CLKWFk019729; Wed, 12 May 2004 21:20:32 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 i4CLGhfD023999; Wed, 12 May 2004 21:17:29 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 M2004051214194715289 ; Wed, 12 May 2004 14:19:47 -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, 12 May 2004 14:19: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] topic 4c: Common Header: batching Message-ID: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] topic 4c: Common Header: batching Thread-Index: AcQ4NkgAQqB7bX/4SYuVGGdn7aT/awAL+SZA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 12 May 2004 21:19:47.0657 (UTC) FILETIME=[DA7B9B90:01C43866] 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, 12 May 2004 14:19: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 All, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > Jamal, I suppose you tend to use parallel atomicity because you first=20 > raise > this, but not very sure. How about other guys thoughts? > I would worry about introducing great amounts of complexity to the=20 protocol. While i see value in atomic operations, i think they should be kept to=20 a minimum as opposed to non-atomic batching - which is just for=20 transport convenience and can be used freely as long as there is a=20 sperate status per operation. I thus think that the mechanism should=20 be kept simple. [HK] I agree with Avri's view on this. From our implementation experience and customer requirements, non-atomic transactions has been the most common case (infact we rarely use atomic transactions). I don't think we should be introducing too much complexity (sub-SeqN) into the protocol, unless we think its absolutely necessary to support that functionality. I also think multiple atomic ops could be dealt=20 with in parallel without special mechanisms - the CE should not send a=20 dependent op until the preceding atomic op has completed successfully. [HK] Sounds reasonable to me. Thanks for commenting, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 02:55: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 CAA22830 for ; Thu, 13 May 2004 02:55: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 1BOA75-0002pN-Hc for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 02:54:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D6sdQ1010865 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 02:54:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA6I-0002VS-0u for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 02:53: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 CAA22759 for ; Thu, 13 May 2004 02:53: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 1BOA6E-0002jq-8I for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 02:53:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOA5E-0002FM-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 02:52:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOA4a-0001lc-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 02:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOA1d-0001Vq-Qt; Thu, 13 May 2004 02: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 1BO9yR-00012P-Ho for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 02:45: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 CAA22144 for ; Thu, 13 May 2004 02: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 1BO9yN-0006R6-Ld for forces-protocol@ietf.org; Thu, 13 May 2004 02:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO9xK-0005wM-00 for forces-protocol@ietf.org; Thu, 13 May 2004 02:44: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 1BO9wA-000508-00 for forces-protocol@ietf.org; Thu, 13 May 2004 02:43:22 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i4D6fpfd021420; Thu, 13 May 2004 06:41:51 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 i4D6eFMW008857; Thu, 13 May 2004 06:40:15 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 M2004051223423400470 ; Wed, 12 May 2004 23:42:34 -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, 12 May 2004 23:41: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E01013E56@orsmsx408.jf.intel.com> Thread-Topic: Add Route Example Thread-Index: AcQ4HRdBBMjzNYM7Th+/t32kYQP9MgAkMKXw From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , "Robert Haas" X-OriginalArrivalTime: 13 May 2004 06:41:47.0483 (UTC) FILETIME=[5D10BAB0:01C438B5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Add Route Example 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, 12 May 2004 23:41: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 Here are some examples for what our ForCES msg might look like... Here is a TLV... (16 bits for T, 16 bits for L & variable len V) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 \ \=20 / Value /=20 \ \=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add Route Msg.... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 | Common Header fields... |=20 | Command Type =3D Config | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DLFB(or FE)attrs | Length | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Operation=3DAdd(Del,DelAll,Update| Flags | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID=3DIPv4 Fwdr | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Array of route entries |=20 . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The array of route entries will be defined by the FE Model team. Actually I suspect, they will define an IPv4 Prefix and IPv4 NextHop LFB and this msg will carry an array of prefixes and Nexthops. For a reference example of the actual route structs, look at http://www.npforum.org/techinfo/IPv4_IA.pdf I will also try to find some more examples looking at our code here, Hope this helps, Let me know what you guys think ? Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 10:36:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16226 for ; Thu, 13 May 2004 10:36: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 1BOHEF-00040j-O2 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:30:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEUVjK015417 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOH8w-0002KR-HH for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 10:25: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 KAA15490 for ; Thu, 13 May 2004 10:24: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 1BOH8u-0001PS-DU for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:25:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOH7t-0000ou-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:23:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOH6g-0007X6-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGyL-0007Ce-5U; Thu, 13 May 2004 10:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGsa-0004BE-Mh for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 10:08: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 KAA14018 for ; Thu, 13 May 2004 10:08: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 1BOGsY-0007dJ-DH for forces-protocol@ietf.org; Thu, 13 May 2004 10:08:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGrl-000758-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:07:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOGqw-0006Tf-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:06:27 -0400 Received: from wwm1 (unverified [219.82.177.217]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Thu, 13 May 2004 22:18:59 +0800 Message-ID: <005b01c438f2$e08e9be0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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: Thu, 13 May 2004 22:02:02 +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, Hormuzd, Thank you very much for both your comments. Although I think it is not so difficult in the protocol PDU to support multiple atomic ops (I think just defining a 4 bit sth like AtomicCouter is enough to solve it), I also a litltle doubt the wide use of it. Jamal, Robert, and Ligang, could you give your ideas at your convenience ? Sorry to push it, just hope to move forward more quickly. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: ; Sent: Thursday, May 13, 2004 5:19 AM Subject: RE: [Forces-protocol] topic 4c: Common Header: batching All, -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > Jamal, I suppose you tend to use parallel atomicity because you first > raise > this, but not very sure. How about other guys thoughts? > I would worry about introducing great amounts of complexity to the protocol. While i see value in atomic operations, i think they should be kept to a minimum as opposed to non-atomic batching - which is just for transport convenience and can be used freely as long as there is a sperate status per operation. I thus think that the mechanism should be kept simple. [HK] I agree with Avri's view on this. From our implementation experience and customer requirements, non-atomic transactions has been the most common case (infact we rarely use atomic transactions). I don't think we should be introducing too much complexity (sub-SeqN) into the protocol, unless we think its absolutely necessary to support that functionality. I also think multiple atomic ops could be dealt with in parallel without special mechanisms - the CE should not send a dependent op until the preceding atomic op has completed successfully. [HK] Sounds reasonable to me. Thanks for commenting, 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 May 13 10:47:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16904 for ; Thu, 13 May 2004 10:47: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 1BOHQ7-0007Ex-T7 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:42:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEglnW027832 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHMj-0005xj-0i for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 10:39: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 KAA16418 for ; Thu, 13 May 2004 10:39: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 1BOHMg-0001QF-Q5 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:39:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHLg-0000rp-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:38:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOHKz-0000Jq-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:37:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHEl-0004Ab-Bc; Thu, 13 May 2004 10: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 1BOH8J-0002FR-Fv for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 10:24: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 KAA15440 for ; Thu, 13 May 2004 10:24: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 1BOH8H-0000s4-6E for forces-protocol@ietf.org; Thu, 13 May 2004 10:24:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOH7J-0000Il-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:23:22 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOH6Y-0007VQ-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:22:37 -0400 Received: from wwm1 (unverified [219.82.177.217]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 13 May 2004 22:35:07 +0800 Message-ID: <006901c438f5$21b29070$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <1084365100.1047.119.camel@jzny.localdomain> Subject: Re: [Forces-protocol] FEM/CEM experiences 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: Thu, 13 May 2004 22:18:10 +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 Jamal, Just one comment inline. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > This is to start the discussion on FEM/CEM interface as well as respond > to my action item from the concal. > > The FEM/CEM interface is used for configuration of non-protocol > specific parametrization. > In our implementation we used it for: > > 1) > a) selecting the number of connections to be used. Example: > "use 3 UDP multicast + one TCP connection" > b) describing details about each of the connections. Example > "for UDP multicast connection 1 use IP address a.b.c.d port x" > > The above could be seen as TML specific now - i am not sure if that gets > rid of the need for xEM. [Weiming]Can we think the relation between xEM and TML as a father(xEM) and his child(TML)? Father starts something, the child mainly use them, but in some cases, may also change them more or less. They are not easy to be separated, and even more hard to get rid of each other. > > 2) In our case an FE could be issued a set of PIDs which are > a 32 bit number with 32 bit mask. This was because there were multiple > IDs that could be allocated per FE. In the current thought process we > are saying a FE can only have one ID; however, the FE could still obtain > its ID via the FEM. Example, in one specific hardware, the FE on bootup > could discover the slotID and chassi ID it was on and pass that to the > forces s/ware via the FEM. > > 3) Security parameterization such as keys etc. In order to have the > forces s/ware independent, we had decided but never implemented that the > security key exchanges will happen elsewehre and the forces s/ware will > be notified of the parametrization via FEM. > > 4) Connection setup parametes > > Example "send up to 3 association messages each 1 second apart" Vs > " send upto 4 association messages with increasing exponential timeout". > > 5) probably the most important piece we found: > > controlling the FE s/ware and parametrization throughout the life of the > FE s/ware daemon. This is also implies FEM-CEM interface was alive > during this phase. > > a) The FE may get its own paramters localy (such as the ID to use. We > however found it useful to have the FEM in continous contact with the > CEM because we could dynamically change its parameters > (example adding a new connection to scale things). > b) As well we could shutdown a FE via its FEM interface etc. > > > Hopefully that captures it. > > 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 Thu May 13 11:00:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17507 for ; Thu, 13 May 2004 11:00:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHfh-0002S1-O6 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:58:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEwrNK009411 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 10:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHWW-0000C6-Kt for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 10:49: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 KAA17053 for ; Thu, 13 May 2004 10:49: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 1BOHWU-00073m-7k for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:49:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHVP-0006Ue-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:48:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOHUs-0005wI-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 10:47:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHQL-0007FW-8n; Thu, 13 May 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 1BOHLX-0005V0-JI for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 10: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 KAA16318 for ; Thu, 13 May 2004 10:37: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 1BOHLV-0000q5-3i for forces-protocol@ietf.org; Thu, 13 May 2004 10:38:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHKX-0000IM-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:37:02 -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 1BOHJX-0007Xk-00 for forces-protocol@ietf.org; Thu, 13 May 2004 10:35:59 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051307400856:2168 ; Thu, 13 May 2004 07:40:08 -0700 Subject: More summary WAS(RE: [Forces-protocol] topic 4c: Common Header: batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, avri@acm.org, Robert Haas , Weiming In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> Organization: Znyx Networks Message-Id: <1084458947.1022.37.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 05/13/2004 07:40:08 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 07:40:13 AM, Serialize complete at 05/13/2004 07:40:13 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: 13 May 2004 10:35: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 This is the last email on this thread - so let me jump to it; Earlier i proposed for a definition of transaction - i should have posted one. I may go a little academic, so i apologize in advance (with a warning that i am no expert). I think we may need an expert on this subject if we are to get it right (not sure if Weiming or Ligang are) Transaction Definition: A transaction is a sequence of operations that is guaranteed to be _atomic_ in the presence of any failures by the CEs or FEs. Note: Atomic is part of the definition - i just added the CE/FE portion to be specific to ForCES. So having atomicity is not just for fun, it is what defines a transaction. What the definition implies is clear on recovery from error: Atomicity implies an all-or-none operation. So _absolutely_ no question whatsoever on what a failure reaction is in atomic operations. All operations which are atomic (whether carried by one or multiple PL messages) are executed serially to ensure consistency across multiple FEs[1]. What is the scope of a transaction? In other words how small is a unit transaction? We have introduced a flag to turn off atomicity. In such a case i believe that each operation (part of msg body) in the PL message becomes a standalone _transaction_. So to take it one more step: Each of those transactions(in the message body) can be atomic. Lets pick an example to clarify: A config PL msg with "route-add A B,C:route-del X" operations CASE I: decide that they both need to go together in which case an atomic flag in the main header with the sequence number should suffice to provide the semantics. CASE II: decide are independent atomic config operations in which case i can put the atomic flag for route-add of A,B,C and another one for X in their respective operation headers. What you should note from the above is that in both case the transactions are still _atomic_, only thing is granularity is different. Clearly what we need to achieve case II is: a) to allow for the atomic flag to also be within the operation headers and b)to have a subsequence number to separate the success or failure of "route-add of A,B,C" vs "route-del of X". Case II allows for higher concurency which is what i think Weiming is refering to. I am torn apart because i see the value in it as a way to further pipeline (fill that 100Gige pipe) but i dont see a clean way in the responses which are not going to impose on the general message. I believe we shouldnt give up on it yet. Weiming maybe you can think of some clever way to do it? I think the confusion we are faced with has been a result of lumping atomicity and concurency/parallelization in one. Concurency is to allow us to improve the Forces computational capability. We want to fill the pipe with transactions so as to maximize the throughput. In other words, if you are provided with a 100Gige pipe to submit transactions through, Forces protocol MUST not be the bottleneck. The 100Gige could, of course. Unfortunately (or fortunately) pipelining mechanisms such as batching is also helpful in achieving atomicity if your transaction spans multiple PL messages. Ok, i probably spent over 30 minutes typing this - need to do real work. cheers, jamal [1]A classical paper published on this subject (unfortunatley i am not an ACM member so i cant retrieve it from their database) is " T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983)" My dusty high school book refers to the ACID properties of a transactions as defined in that paper (I am sure there are a lot of better papers than that which came after). ACID is a mnemonic which translates to (some of the wording is mine): -> A for Atomicity ("a transaction is all or nothing") -> C for Consitency ("A transaction moves the NE/FE from one consistent state to another"); Example if a packet treatment such as a route goes across multiple FEs then you better make sure that the all those multiple FEs are updated at the same time, otherwise things will go wrong. -> I for isolation; essentially seriliazation of operations -> D for Durability; an FE or CE crashing or a transaction failure should be survivable. On Wed, 2004-05-12 at 17:19, Khosravi, Hormuzd M wrote: > All, > --Original Message-- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > > Jamal, I suppose you tend to use parallel atomicity because you first > > raise > > this, but not very sure. How about other guys thoughts? > > > > I would worry about introducing great amounts of complexity to the > protocol. > > While i see value in atomic operations, i think they should be kept to > a minimum as opposed to non-atomic batching - which is just for > transport convenience and can be used freely as long as there is a > sperate status per operation. I thus think that the mechanism should > be kept simple. > > [HK] I agree with Avri's view on this. From our implementation > experience and customer requirements, non-atomic transactions has been > the most common case (infact we rarely use atomic transactions). I don't > think we should be introducing too much complexity (sub-SeqN) into the > protocol, unless we think its absolutely necessary to support that > functionality. > > I also think multiple atomic ops could be dealt > with in parallel without special mechanisms - the CE should not send a > dependent op until the preceding atomic op has completed successfully. > > [HK] Sounds reasonable to me. > > Thanks for commenting, > 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 May 13 11:52:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19899 for ; Thu, 13 May 2004 11:52: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 1BOIQv-0004eH-NN for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 11:47:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DFlfSp017864 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 11:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOIJs-0003Qx-QI for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 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 LAA19185 for ; Thu, 13 May 2004 11:40: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 1BOIJr-0002nb-LG for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 11:40:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOIIl-0002Bh-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 11:39:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOIHP-00017Q-01 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 11:37:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOI8t-0004Wh-G8 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 11:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOI7t-0000fz-7K; Thu, 13 May 2004 11: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 1BOHyC-0006Vb-M3 for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 11:18: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 LAA18186 for ; Thu, 13 May 2004 11:17: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 1BOHyB-0006Vc-Ne for forces-protocol@ietf.org; Thu, 13 May 2004 11:17:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHwA-0005lW-00 for forces-protocol@ietf.org; Thu, 13 May 2004 11:15:54 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOHuK-0004fe-00 for forces-protocol@ietf.org; Thu, 13 May 2004 11:14:01 -0400 Received: from wwm1 (unverified [219.82.177.217]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 13 May 2004 23:26:42 +0800 Message-ID: <009c01c438fc$567615f0$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , , References: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call 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: Thu, 13 May 2004 23:09:45 +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, Jamal as well, Comments inline. Thank you. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Ok, I am fine with #2 below since it seems to be the preference of most of you guys. I guess our definition of cleaner is very different :) Anyways, we can close on this one for now (atleast from my side) [Weiming]Sure. Jamal, to address your last questions...I don't see any events from CE to FE, other than CE State changes which are part of the State Maintenance msgs (I think). So an Event msg from CE to FE is implicitly a Event Subscribe msg, in my opinion. Other thoughts on this ? BTW, have we decided on separate messages for HBs or is it part of events ? If this is part of event then this might be another Event msg from CE to FE. [Weiming] I suggest to treat HB as an event. In this way, we then can start (by subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set parameters to the HB such as the HB interval. Talking about this, I actually have another thought that, HB is not the only event that need to setup parameters before we start them, therefore, apart from 'subscribe' and unsubscribe' for events, we may also need operations such as 'config'. Pls allow me to use PDU to explain this more, and also try to response to Jamal on the possible event msg format ask. EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ... : TLV TLV = Type : Length : Value Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config' EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID : EventDescription Value (with EventFlag = 'NonLFBEvent') = EventDescription EventDescription for 'Subscribe' / 'Unsubscribe' = EventType(XML or ID, to be decided?) EventDescription for 'Report' = EventType : [Length] : EventValue(XML?) EventDescription for 'Config' = EventType : [Length] : EventParameterDescription(XML?) Hope it helps to get to know each other's thoughts more. [/Weiming] Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > cmd type operation type > CE ----------------------------------> FE > > > subscribe - > ----------------------------------> (Hormuzd's preference) > > > event subscribe > ----------------------------------> (Weiming+Robert) > > > config event-subscribe > ----------------------------------> (Weiming) > I dont see any difference vetween the last two. They seem cleaner than the first one, but i cant really conclude that until i see how the message body looks like. Seems to me like you need to specify which is/are the event(s) of interest. Also you should be able to subscribe to multiple events in one PL message. Lets also discuss the events being sent from CE->FE while we are talking about this. 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 Thu May 13 17:38: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 RAA17879 for ; Thu, 13 May 2004 17:38: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 1BONm6-0004sj-M5 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 17:29:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLTsLB018756 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 17:29:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONgf-0001YI-Gd for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:24: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 RAA15915 for ; Thu, 13 May 2004 17:24: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 1BONgd-0001J4-3s for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 17:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONdn-0007mj-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 17:21:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BONcP-00076P-01 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 17:19:53 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BONVB-0000vx-Jy for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 17:12:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMlQ-0005CT-4U; Thu, 13 May 2004 16:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMKa-0007X8-Lb for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 15:57: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 PAA09799 for ; Thu, 13 May 2004 15:57: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 1BOMKY-0007Wv-Vv for forces-protocol@ietf.org; Thu, 13 May 2004 15:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOMJf-0006zu-00 for forces-protocol@ietf.org; Thu, 13 May 2004 15:56: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 1BOMIr-0006Hx-00 for forces-protocol@ietf.org; Thu, 13 May 2004 15:55:37 -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 i4DJtiv6004539; Thu, 13 May 2004 19:55: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 i4DJqFMa008992; Thu, 13 May 2004 19:52: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 M2004051312544822877 ; Thu, 13 May 2004 12:54: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); Thu, 13 May 2004 12:54: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E010143E4@orsmsx408.jf.intel.com> Thread-Topic: FEM/CEM experiences Thread-Index: AcQ4HRdBBMjzNYM7Th+/t32kYQP9MgBBW5qw From: "Khosravi, Hormuzd M" To: , Cc: "Weiming Wang" , "Robert Haas" X-OriginalArrivalTime: 13 May 2004 19:54:48.0582 (UTC) FILETIME=[259C4260:01C43924] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] RE: FEM/CEM experiences 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, 13 May 2004 12:54:48 -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 sharing your experiences on FEM/CEM. I think this very useful info. We had similar experiences. We definitely still need #2, #3 below for FEM/CEM (Configuration of FE, CEIDs, Addrs, Security Keys,). #4 seems implementation specific, this could be part of FEM/CEM or implementation guidance in the protocol ? I am not so sure about #5, 5a looks similar to #2, 5b we can do using the PL itself. For #1, as you said this belongs to TML, so it should be standardized by the TML team. Once we have some TML draft out, we will have a better idea about it.=20 Anyways overall, this looks pretty good. May be you could just summarize it based on the comments you receive ? Hopefully we shouldn't need to spend too much time on this. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 This is to start the discussion on FEM/CEM interface as well as respond to my action item from the concal. The FEM/CEM interface is used for configuration of non-protocol specific parametrization. In our implementation we used it for: 1)=20 a) selecting the number of connections to be used. Example: "use 3 UDP multicast + one TCP connection" b) describing details about each of the connections. Example=20 "for UDP multicast connection 1 use IP address a.b.c.d port x" The above could be seen as TML specific now - i am not sure if that gets rid of the need for xEM. 2) In our case an FE could be issued a set of PIDs which are a 32 bit number with 32 bit mask. This was because there were multiple IDs that could be allocated per FE. In the current thought process we are saying a FE can only have one ID; however, the FE could still obtain its ID via the FEM. Example, in one specific hardware, the FE on bootup could discover the slotID and chassi ID it was on and pass that to the forces s/ware via the FEM. 3) Security parameterization such as keys etc. In order to have the forces s/ware independent, we had decided but never implemented that the security key exchanges will happen elsewehre and the forces s/ware will be notified of the parametrization via FEM. 4) Connection setup parametes Example "send up to 3 association messages each 1 second apart" Vs " send upto 4 association messages with increasing exponential timeout". 5) probably the most important piece we found: controlling the FE s/ware and parametrization throughout the life of the FE s/ware daemon. This is also implies FEM-CEM interface was alive during this phase. a) The FE may get its own paramters localy (such as the ID to use. We however found it useful to have the FEM in continous contact with the CEM because we could dynamically change its parameters (example adding a new connection to scale things). b) As well we could shutdown a FE via its FEM interface etc. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 19:19:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24220 for ; Thu, 13 May 2004 19:19: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 1BOPTR-00012d-0d for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:18:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DNIipr004003 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPSb-0000hF-DE for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 19:17: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 TAA23962 for ; Thu, 13 May 2004 19:17: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 1BOPSZ-0004vY-VY for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:17:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPQh-0004FB-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:15:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOPOh-00030r-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:13:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPLx-0007D6-Ux; Thu, 13 May 2004 19: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 1BOPGt-0005T6-AL for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 19:05: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 TAA23027 for ; Thu, 13 May 2004 19: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 1BOPGq-0006Og-1H for forces-protocol@ietf.org; Thu, 13 May 2004 19:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPFk-0005s9-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:04:37 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BOPF5-0005K9-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:03:55 -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 i4DN3LYO105966; Thu, 13 May 2004 23:03:21 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 i4DN3Kd2282880; Fri, 14 May 2004 01:03:20 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.21.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA49574; Fri, 14 May 2004 01:03:19 +0200 Message-ID: <40A3FEB6.8050301@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: avri@acm.org CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: batching References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate5.de.ibm.com id i4DN3LYO105966 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, 14 May 2004 01:03:18 +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 I finally see a justification for plain batching (that is, batching=20 without atomicity): a batch will result in a single status: OK if all=20 commands in the batch failed, and notOK if some of them failed (and=20 probably we should stop processing commands after the first failure). Is this a semantics that would be acceptable to everyone ? -Robert avri@acm.org wrote: > > On 12 maj 2004, at 15.08, Weiming Wang wrote: > >> Jamal, I suppose you tend to use parallel atomicity because you first=20 >> raise >> this, but not very sure. How about other guys thoughts? >> >> > > I would worry about introducing great amounts of complexity to the=20 > protocol. > > While i see value in atomic operations, i think they should be kept to=20 > a minimum as opposed to non-atomic batching - which is just for=20 > transport convenience and can be used freely as long as there is a=20 > sperate status per operation. I thus think that the mechanism should=20 > be kept simple. > > Since each transaction has its own id, i see no reason a heartbeat or=20 > other command could not be dealt with separately as it arrived without=20 > needing special flags. I also think multiple atomic ops could be=20 > dealt with in parallel without special mechanisms - the CE should not=20 > send a dependent op until the preceding atomic op has completed=20 > successfully. > > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > --=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 Thu May 13 19:20:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24242 for ; Thu, 13 May 2004 19:20: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 1BOPTS-00013T-6p for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:18:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DNIkfO004051 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:18:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPSz-0000iE-7p for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 19:18: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 TAA24035 for ; Thu, 13 May 2004 19:18: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 1BOPSx-000567-Io for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:18:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPRB-0004K1-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:16:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOPPI-0003QI-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:14:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPMu-0007F6-DB; Thu, 13 May 2004 19:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPHb-0005gc-BT for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 19:06: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 TAA23038 for ; Thu, 13 May 2004 19:06: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 1BOPHY-0006uY-1Q for forces-protocol@ietf.org; Thu, 13 May 2004 19:06:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPGb-0006NP-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:05:29 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1BOPFX-0005L9-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:04:23 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4DN3rMp107764; Thu, 13 May 2004 23:03:53 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4DN3q5h152594; Fri, 14 May 2004 01:03:52 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.21.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA29442; Fri, 14 May 2004 01:03:51 +0200 Message-ID: <40A3FED6.7020809@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: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call References: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01013842@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 mtagate6.de.ibm.com id i4DN3rMp107764 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, 14 May 2004 01:03:50 +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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hormuzd, >BTW, have we decided on separate messages for HBs or is it part of >events ? If this is part of event then this might be another Event msg >from CE to FE. > =20 > I would regards this as an event also. -Robert --=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 Thu May 13 19:23:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24451 for ; Thu, 13 May 2004 19:23: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 1BOPU9-0001M7-CY for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:19:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DNJTwQ005204 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 19:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPT2-0000iu-Bm for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 19:18: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 TAA24050 for ; Thu, 13 May 2004 19:18: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 1BOPT0-00058l-MC for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPRG-0004Kf-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:16:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOPPR-0003Ye-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 19:14:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPMu-0007FC-Gg; Thu, 13 May 2004 19:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPIU-0005pd-0F for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 19:07: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 TAA23049 for ; Thu, 13 May 2004 19: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 1BOPIQ-0007Qc-JR for forces-protocol@ietf.org; Thu, 13 May 2004 19:07:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPHQ-0006tZ-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:06:21 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BOPGH-0005sN-00 for forces-protocol@ietf.org; Thu, 13 May 2004 19:05:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4DN4UfV048868; Thu, 13 May 2004 23:04:30 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4DN4T5h114092; Fri, 14 May 2004 01:04:29 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.21.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id BAA24770; Fri, 14 May 2004 01:04:28 +0200 Message-ID: <40A3FEFB.90708@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: batching References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> <005b01c438f2$e08e9be0$020aa8c0@wwm1> In-Reply-To: <005b01c438f2$e08e9be0$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------090806000705030208090601" 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, 14 May 2004 01:04:27 +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. --------------090806000705030208090601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id i4DN4UfV048868 Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: >Hi Avri, Hormuzd, > >Thank you very much for both your comments. Although I think it is not = so >difficult in the protocol PDU to support multiple atomic ops (I think ju= st >defining a 4 bit sth like AtomicCouter is enough to solve it), I also a = litltle >doubt the wide use of it. Jamal, Robert, and Ligang, could you give you= r ideas >at your convenience ? > I personally don't see a high need for interleaved independent atomic=20 transactions. The pathological case that one could think of is an atomic=20 batch of a very very large number of routes that postpones a=20 high-priority message. The heartbeat is a bad example because the FE=20 should not think that the CE disappeared if it is still receiving routes=20 from it. Can someone think of a case in which the pathological scenario could=20 result in a real problem ? -Robert >Sorry to push it, just hope to move forward more quickly. > >Thank you. >Weiming > >----- Original Message ----- >From: "Khosravi, Hormuzd M" >To: ; >Sent: Thursday, May 13, 2004 5:19 AM >Subject: RE: [Forces-protocol] topic 4c: Common Header: batching > > >All, >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > =20 > >>Jamal, I suppose you tend to use parallel atomicity because you first >>raise >>this, but not very sure. How about other guys thoughts? >> >> =20 >> > >I would worry about introducing great amounts of complexity to the >protocol. > >While i see value in atomic operations, i think they should be kept to >a minimum as opposed to non-atomic batching - which is just for >transport convenience and can be used freely as long as there is a >sperate status per operation. I thus think that the mechanism should >be kept simple. > >[HK] I agree with Avri's view on this. From our implementation >experience and customer requirements, non-atomic transactions has been >the most common case (infact we rarely use atomic transactions). I don't >think we should be introducing too much complexity (sub-SeqN) into the >protocol, unless we think its absolutely necessary to support that >functionality. > >I also think multiple atomic ops could be dealt >with in parallel without special mechanisms - the CE should not send a >dependent op until the preceding atomic op has completed successfully. > >[HK] Sounds reasonable to me. > >Thanks for commenting, >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 > > > =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 --------------090806000705030208090601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,

Weiming Wang wrote:
Hi Avri, Hormuzd,

Thank you very much for both your comments.  Although I think it is not  so
difficult in the protocol PDU to support multiple atomic ops (I think just
defining a 4 bit sth like AtomicCouter is enough to solve it), I also a litltle
doubt the wide use of it.  Jamal, Robert, and Ligang, could you give your ideas
at your convenience ?
I personally don't see a high need for interleaved independent atomic transactions. The pathological case that one could think of is an atomic batch of a very very large number of routes that postpones a high-priority message. The heartbeat is a bad example because the FE should not think that the CE disappeared if it is still receiving routes from it.

Can someone think of a case in which the pathological scenario could result in a real problem ?

-Robert

Sorry to push it,  just hope to move forward more quickly.

Thank you.
Weiming

----- Original Message -----
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
To: <forces-protocol@ietf.org>; <avri@acm.org>
Sent: Thursday, May 13, 2004 5:19 AM
Subject: RE: [Forces-protocol] topic 4c: Common Header: batching


All,
-----Original Message-----
From: forces-protocol-admin@ietf.org
[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org

  
Jamal, I suppose you tend to use parallel atomicity because you first
raise
this, but not very sure. How about other guys thoughts?

    

I would worry about introducing great amounts of complexity to the
protocol.

While i see value in atomic operations, i think they should be kept to
a minimum as opposed to non-atomic batching - which is just for
transport convenience and can be used freely as long as there is a
sperate status per operation.  I thus think that the mechanism should
be kept simple.

[HK] I agree with Avri's view on this. From our implementation
experience and customer requirements, non-atomic transactions has been
the most common case (infact we rarely use atomic transactions). I don't
think we should be introducing too much complexity (sub-SeqN) into the
protocol, unless we think its absolutely necessary to support that
functionality.

I also think multiple atomic ops could be dealt
with in parallel without special mechanisms - the CE should not send a
dependent op until the preceding atomic op has completed successfully.

[HK] Sounds reasonable to me.

Thanks for commenting,
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


  

-- 
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
--------------090806000705030208090601-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 20:24: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 UAA27162 for ; Thu, 13 May 2004 20:24: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 1BOQOv-0007Nb-3L for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20:18:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E0I9VG028363 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQMN-0006pq-BK for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 20:15: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 UAA26838 for ; Thu, 13 May 2004 20:15: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 1BOQML-0004qB-Av for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQLN-0004JZ-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:14:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOQKR-0003mX-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:13:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQIy-0005ig-8l; Thu, 13 May 2004 20:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQAr-0003wE-5y for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 20:03: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 UAA26391 for ; Thu, 13 May 2004 20:03: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 1BOQAp-0006OO-AJ for forces-protocol@ietf.org; Thu, 13 May 2004 20:03:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQA6-0005rv-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:02:51 -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 1BOQ9M-0005Ki-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:02: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 2004051317061738:2926 ; Thu, 13 May 2004 17:06:17 -0700 Subject: Re: [Forces-protocol] Add Route Example From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, "Wang,Weiming" , Robert Haas In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01013E56@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01013E56@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084492880.1038.12.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 05/13/2004 05:06:17 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 05:06:19 PM, Serialize complete at 05/13/2004 05:06:19 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: 13 May 2004 20:01: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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hormuzd, Thanks for posting this. some comments below. On Thu, 2004-05-13 at 02:41, Khosravi, Hormuzd M wrote: > Here are some examples for what our ForCES msg might look like... > > Here is a TLV... (16 bits for T, 16 bits for L & variable len V) > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ \ > / Value / > \ \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Add Route Msg.... > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Common Header fields... | > | Command Type = Config | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=LFB(or FE)attrs | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Operation=Add(Del,DelAll,Update| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Type ID=IPv4 Fwdr | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Array of route entries | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LFB Type ID, Type and even the operation should probably be the same field (eg "addroute"). Best place maybe the T(ype) portion of the TLV Although you may argue 16 bit may not be sufficient. Also maybe a version field may be valuable to have. The main header version is for the protocol and the version on TLV is for the LFB. > The array of route entries will be defined by the FE Model team. > Actually I suspect, they will define an IPv4 Prefix and IPv4 NextHop LFB > and this msg will carry an array of prefixes and Nexthops. > I hope the model team is not the driver for this. Agreed probably an array of prefixes would suffice with nexthop indicess. I would see the nexthops as attributes described by TLVs but i dont wanna digress because its an unrelated topic. > For a reference example of the actual route structs, look at > http://www.npforum.org/techinfo/IPv4_IA.pdf Thanks for posting this. I will scan and read it. I have my own opinions of what the route messages should look like so i will want to see how much in sync this is. > I will also try to find some more examples looking at our code here, > > Hope this helps, > Let me know what you guys think ? I think in general it looks good. It doesnt matter how the route message looks like as long as we can define the surrounding things. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 20:28: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 UAA27398 for ; Thu, 13 May 2004 20:28: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 1BOQY1-00026K-34 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20:27:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E0RXif008072 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQQD-0007x6-3U for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 20:19: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 UAA26940 for ; Thu, 13 May 2004 20:19: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 1BOQQB-0006vl-5C for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQPF-0006O1-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:18:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOQOJ-0005sY-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:17:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQJx-0006Bh-Gc; Thu, 13 May 2004 20:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQBg-00041m-Ek for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 20:04: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 UAA26406 for ; Thu, 13 May 2004 20:04: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 1BOQBe-0006tt-Em for forces-protocol@ietf.org; Thu, 13 May 2004 20:04:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQAc-0006Me-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:03: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 1BOQ9U-0005W5-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:02:12 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051317062571:2927 ; Thu, 13 May 2004 17:06:25 -0700 Subject: RE: [Forces-protocol] Notes from ForCES protocol meeting call From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Robert Haas , Weiming , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084492916.1039.14.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 05/13/2004 05:06:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 05:06:27 PM, Serialize complete at 05/13/2004 05:06:27 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: 13 May 2004 20:02: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 On Wed, 2004-05-12 at 14:50, Khosravi, Hormuzd M wrote: > Ok, I am fine with #2 below since it seems to be the preference of most > of you guys. > I guess our definition of cleaner is very different :) We can always revisit later if we find what you propose makes more sense The hard part is since the message types etc are not available sometimes it is hard to visualize the benefits of a proposal. > Anyways, we can close on this one for now (atleast from my side) > > Jamal, to address your last questions...I don't see any events from CE > to FE, other than CE State changes which are part of the State > Maintenance msgs (I think). So an Event msg from CE to FE is implicitly > a Event Subscribe msg, in my opinion. Other thoughts on this ? Sorry, typo. I meant FE->CE. In other words can the response actually be exactly the same message as that was sent from CE->FE and if so whether it becomes an event or a config from FE->CE being intepreted as an event? We touched briefly on this. > BTW, have we decided on separate messages for HBs or is it part of > events ? If this is part of event then this might be another Event msg > from CE to FE. It does seem to make sense to have heartbeat a a separate message. But let me read on to see both arguements. cheers, jamal > Regards > Hormuzd > > --Original Message-- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > > cmd type operation type > > CE --> FE > > > > > > subscribe - > > --> (Hormuzd's preference) > > > > > > event subscribe > > --> (Weiming+Robert) > > > > > > config event-subscribe > > --> (Weiming) > > > > I dont see any difference vetween the last two. They seem cleaner than > the first one, but i cant really conclude that until i see how the > message body looks like. > Seems to me like you need to specify which is/are the event(s) of > interest. Also you should be able to subscribe to multiple events in one > PL message. > > Lets also discuss the events being sent from CE->FE while we are talking > about this. > > cheers, > jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 20: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 UAA27964 for ; Thu, 13 May 2004 20: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 1BOQiA-0004jF-PM for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E0c2Nq018173 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 20: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 1BOQff-0003o6-50 for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 20:35: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 UAA27822 for ; Thu, 13 May 2004 20:35: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 1BOQfc-0007mL-V6 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:35:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQed-0007FH-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:34:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOQdT-0006MF-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 20:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOQbM-0002xG-KB; Thu, 13 May 2004 20: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 1BOQYv-0002OV-Oi for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 20:28: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 UAA27373 for ; Thu, 13 May 2004 20:28: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 1BOQYt-00041h-Ip for forces-protocol@ietf.org; Thu, 13 May 2004 20:28:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQXr-0003TU-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:27:24 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BOQWj-0002PT-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:26:13 -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 i4DNMQfd014977; Thu, 13 May 2004 23:22:26 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 i4DNMoNh018661; Thu, 13 May 2004 23:23:53 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 M2004051316231625570 ; Thu, 13 May 2004 16:23:16 -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, 13 May 2004 16:23:16 -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] Next Conference Call on Friday or Monday ? Message-ID: <468F3FDA28AA87429AD807992E22D07E01014769@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Next Conference Call on Friday or Monday ? Thread-Index: AcQ4EP2roCCO6tKfS8S9iugynCXQngBMCAoQ From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 13 May 2004 23:23:17.0022 (UTC) FILETIME=[4538BBE0:01C43941] 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, 13 May 2004 16:23: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 Hi Team Let me know if you would like me to arrange a call for Friday or Monday (next week) ?? Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:14:51 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 VAA29744 for ; Thu, 13 May 2004 21:14: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 1BORET-000519-PB for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:11:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1BPoH019278 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORBu-0004A1-AM for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:08: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 VAA29528 for ; Thu, 13 May 2004 21:08: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 1BORBr-0002Do-Q3 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:08:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORAu-0001gv-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:07:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORAF-000190-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOR3V-0001Tn-6n; Thu, 13 May 2004 21: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 1BOQxf-0008SD-5F for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 20:54: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 UAA28715 for ; Thu, 13 May 2004 20: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 1BOQxc-0001qX-Nt for forces-protocol@ietf.org; Thu, 13 May 2004 20:54:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOQwY-0001HV-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:52:55 -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 1BOQvh-0000jQ-00 for forces-protocol@ietf.org; Thu, 13 May 2004 20:52:01 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051317561497:2971 ; Thu, 13 May 2004 17:56:14 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, Weiming Wang , Robert Haas In-Reply-To: <468F3FDA28AA87429AD807992E22D07E010143E4@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E010143E4@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084495919.1039.51.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 05/13/2004 05:56:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 05:56:16 PM, Serialize complete at 05/13/2004 05:56:16 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] RE: FEM/CEM experiences 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: 13 May 2004 20:51: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 I dont think we should spend a lot of time on this. Just wanted to get it out so we could have something to talk about and maybe use for draft write up. I have no strong disagreements with Weinings or Hormuzds comments below. cheers, jamal On Thu, 2004-05-13 at 15:54, Khosravi, Hormuzd M wrote: > Jamal, > > Thanks for sharing your experiences on FEM/CEM. I think this very useful > info. > > We had similar experiences. We definitely still need #2, #3 below for > FEM/CEM (Configuration of FE, CEIDs, Addrs, Security Keys,). #4 seems > implementation specific, this could be part of FEM/CEM or implementation > guidance in the protocol ? I am not so sure about #5, 5a looks similar > to #2, 5b we can do using the PL itself. For #1, as you said this > belongs to TML, so it should be standardized by the TML team. Once we > have some TML draft out, we will have a better idea about it. > > Anyways overall, this looks pretty good. May be you could just summarize > it based on the comments you receive ? Hopefully we shouldn't need to > spend too much time on this. > > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > This is to start the discussion on FEM/CEM interface as well as respond > to my action item from the concal. > > The FEM/CEM interface is used for configuration of non-protocol > specific parametrization. > In our implementation we used it for: > > 1) > a) selecting the number of connections to be used. Example: > "use 3 UDP multicast + one TCP connection" > b) describing details about each of the connections. Example > "for UDP multicast connection 1 use IP address a.b.c.d port x" > > The above could be seen as TML specific now - i am not sure if that gets > rid of the need for xEM. > > 2) In our case an FE could be issued a set of PIDs which are > a 32 bit number with 32 bit mask. This was because there were multiple > IDs that could be allocated per FE. In the current thought process we > are saying a FE can only have one ID; however, the FE could still obtain > its ID via the FEM. Example, in one specific hardware, the FE on bootup > could discover the slotID and chassi ID it was on and pass that to the > forces s/ware via the FEM. > > 3) Security parameterization such as keys etc. In order to have the > forces s/ware independent, we had decided but never implemented that the > security key exchanges will happen elsewehre and the forces s/ware will > be notified of the parametrization via FEM. > > 4) Connection setup parametes > > Example "send up to 3 association messages each 1 second apart" Vs > " send upto 4 association messages with increasing exponential timeout". > > 5) probably the most important piece we found: > > controlling the FE s/ware and parametrization throughout the life of the > FE s/ware daemon. This is also implies FEM-CEM interface was alive > during this phase. > > a) The FE may get its own paramters localy (such as the ID to use. We > however found it useful to have the FEM in continous contact with the > CEM because we could dynamically change its parameters > (example adding a new connection to scale things). > b) As well we could shutdown a FE via its FEM interface etc. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:19:52 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 VAA29957 for ; Thu, 13 May 2004 21:19: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 1BORLL-0006eY-BK for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:18:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1IVVH025558 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORJp-0006D4-Kp for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:16: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 VAA29825 for ; Thu, 13 May 2004 21: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 1BORJn-0006WX-5Z for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:16:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORIk-0005xk-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:15:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORI5-0005Pg-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORF4-000532-D9; Thu, 13 May 2004 21: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 1BORBl-00047S-H0 for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 21:08: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 VAA29502 for ; Thu, 13 May 2004 21:08: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 1BORBi-0002Cl-WD for forces-protocol@ietf.org; Thu, 13 May 2004 21:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORAi-0001f3-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:07:33 -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 1BOR9f-00017m-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:06:27 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051318104049:2984 ; Thu, 13 May 2004 18:10:40 -0700 Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org In-Reply-To: <009c01c438fc$567615f0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> <009c01c438fc$567615f0$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1084496779.1038.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 05/13/2004 06:10:40 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 06:10:42 PM, Serialize complete at 05/13/2004 06:10: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: 13 May 2004 21:06:19 -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-05-13 at 11:09, Weiming Wang wrote: > ----- Original Message ----- > [Weiming] I suggest to treat HB as an event. In this way, we then can start (by > subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set > parameters to the HB such as the HB interval. Talking about this, I actually > have another thought that, HB is not the only event that need to setup > parameters before we start them, therefore, apart from 'subscribe' and > unsubscribe' for events, we may also need operations such as 'config'. Pls allow > me to use PDU to explain this more, and also try to response to Jamal on the > possible event msg format ask. i think theres value in HB being able to be subscribed and unsubcribed for; not sure though if it fits here in general. What if CE wants to "ping"/hearbeat a LFB or FE? You seem to indicate direction is FE->CE > > EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ... : TLV > TLV = Type : Length : Value > Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config' > EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' Hormuzd posted some extra flags field in the TLV in the message body. Should we shoot for consistency or do you think flags belong in the T part? > Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID : > EventDescription > Value (with EventFlag = 'NonLFBEvent') = EventDescription > EventDescription for 'Subscribe' / 'Unsubscribe' = EventType(XML or ID, to be > decided?) > EventDescription for 'Report' = EventType : [Length] : EventValue(XML?) > EventDescription for 'Config' = EventType : [Length] : > EventParameterDescription(XML?) So what is the event value for config? Is it a config message that was sent by CE to FE? I think you have a good start above. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:20:23 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 VAA29975 for ; Thu, 13 May 2004 21:20: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 1BORLW-0006g2-E9 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:18:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1Ig6c025661 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORKi-0006EJ-9C for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:17: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 VAA29854 for ; Thu, 13 May 2004 21:17: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 1BORKf-00075C-Mw for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:17:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORJl-0006WM-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:16:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORIj-0005xT-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORF5-00053I-2W; Thu, 13 May 2004 21:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORBt-00049j-Lk for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 21:08: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 VAA29525 for ; Thu, 13 May 2004 21:08: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 1BORBr-0002Dj-43 for forces-protocol@ietf.org; Thu, 13 May 2004 21:08:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORAt-0001gn-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:07:43 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BORAF-00018P-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:07:03 -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 i4E16lPo001158; Fri, 14 May 2004 01:06:48 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 i4E16cHd025189; Fri, 14 May 2004 01:06: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 M2004051318062411284 ; Thu, 13 May 2004 18:06: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, 13 May 2004 18:05: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] Notes from ForCES protocol meeting call Message-ID: <468F3FDA28AA87429AD807992E22D07E0108CF88@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Notes from ForCES protocol meeting call Thread-Index: AcQ4/Pet2HGu23PDQxWjTkwZ39f2vwAUOhOw From: "Khosravi, Hormuzd M" To: "Weiming Wang" , , X-OriginalArrivalTime: 14 May 2004 01:05:53.0029 (UTC) FILETIME=[9A7CDB50:01C4394F] 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, 13 May 2004 18:05: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 Weiming, All, Thanks for this posting. Describing the message format in this detail makes it easy to understand and is useful. One clarification, Event Flag is part of the V in TLV, right ? Couple of other questions... What does Event 'Config' msg mean ? What direction is this msg CE-FE ?? I am a little confused about this. What does Event 'Report' mean? I think this is a Event Notification from FE->CE, correct ? One good technical point that I just thought of (after reading your msg format below :)), is that we don't want to have Responses for Event msgs. They are asynchronous messages to notify events for the most part. But we do need Responses for HBs and Subscribe/Unsubscribe. So how do you address that issue if you make HBs, Subscribe, etc part of Event msg. This might be a good reason to have them as separate msgs, but I would like to know your thoughts on this ? Thanks Hormuzd -----Original Message----- From: Weiming Wang [mailto:wmwang@mail.hzic.edu.cn]=20 BTW, have we decided on separate messages for HBs or is it part of events ? If this is part of event then this might be another Event msg from CE to FE. [Weiming] I suggest to treat HB as an event. In this way, we then can start (by subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set parameters to the HB such as the HB interval. Talking about this, I actually have another thought that, HB is not the only event that need to setup parameters before we start them, therefore, apart from 'subscribe' and unsubscribe' for events, we may also need operations such as 'config'. Pls allow me to use PDU to explain this more, and also try to response to Jamal on the possible event msg format ask. EventMsg =3D CommonHeader(MsgType =3D 'Event') : TLV : TLV : ... : TLV TLV =3D Type : Length : Value Type =3D EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config' EventFlag =3D 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' Value (with EventFlag =3D 'LFBEvent') =3D LFBtypeID : LFBInstanceID : EventDescription Value (with EventFlag =3D 'NonLFBEvent') =3D EventDescription EventDescription for 'Subscribe' / 'Unsubscribe' =3D EventType(XML or = ID, to be decided?) EventDescription for 'Report' =3D EventType : [Length] : = EventValue(XML?) EventDescription for 'Config' =3D EventType : [Length] : EventParameterDescription(XML?) _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:29: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 VAA00436 for ; Thu, 13 May 2004 21:29: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 1BORUw-0000WU-GM for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:28:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1SQ0F002005 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:28:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORUE-0000Ir-F3 for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:27: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 VAA00341 for ; Thu, 13 May 2004 21:27: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 1BORUB-0004hv-P4 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:27:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORTF-0004Ad-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:26:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORSN-0003dv-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORQh-0007qu-PE; Thu, 13 May 2004 21:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORNh-0007AU-O6 for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 21:20: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 VAA00054 for ; Thu, 13 May 2004 21:20: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 1BORNf-0000wS-3I for forces-protocol@ietf.org; Thu, 13 May 2004 21:20:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORMb-0000OU-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:19:50 -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 1BORLo-0007dt-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:19:00 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051318231335:3002 ; Thu, 13 May 2004 18:23:13 -0700 Subject: Re: [Forces-protocol] topic 4c: Common Header: batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <40A3FEFB.90708@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> <005b01c438f2$e08e9be0$020aa8c0@wwm1> <40A3FEFB.90708@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1084497519.1037.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 05/13/2004 06:23:13 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 06:23:15 PM, Serialize complete at 05/13/2004 06:23:15 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: 13 May 2004 21:18: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 Thu, 2004-05-13 at 19:04, Robert Haas wrote: > I personally don't see a high need for interleaved independent atomic > transactions. The pathological case that one could think of is an > atomic batch of a very very large number of routes that postpones a > high-priority message. The heartbeat is a bad example because the FE > should not think that the CE disappeared if it is still receiving > routes from it. > > Can someone think of a case in which the pathological scenario could > result in a real problem ? As long as you have indepedent operations (eg add route and a get route) i think interleaving should be fine. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:30:28 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 VAA00460 for ; Thu, 13 May 2004 21:30: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 1BORUw-0000Wg-IJ for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:28:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1SQnv002018 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:28:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORUF-0000It-PQ for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:27: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 VAA00344 for ; Thu, 13 May 2004 21:27: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 1BORUD-0004iA-3t for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:27:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORTG-0004Al-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:26:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORSd-0003dz-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORQh-0007r2-UP; Thu, 13 May 2004 21:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORON-0007NW-18 for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 21:21: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 VAA00067 for ; Thu, 13 May 2004 21:21:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOROK-0001T0-Cd for forces-protocol@ietf.org; Thu, 13 May 2004 21:21:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORNL-0000uH-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:20:35 -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 1BORM8-0000Au-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:19:20 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051318233377:3003 ; Thu, 13 May 2004 18:23:33 -0700 Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday ? From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01014769@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01014769@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084497541.1037.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 05/13/2004 06:23:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 06:23:35 PM, Serialize complete at 05/13/2004 06:23: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: 13 May 2004 21:19: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 Monday is fine with me. cheers, jamal On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote: > Hi Team > > Let me know if you would like me to arrange a call for Friday or Monday > (next week) ?? > > Thanks > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 13 21:46: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 VAA01163 for ; Thu, 13 May 2004 21: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 1BORf4-00030y-0j for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:38:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E1crAc011589 for forces-protocol-archive@odin.ietf.org; Thu, 13 May 2004 21:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORas-0001yS-Q2 for forces-protocol-web-archive@optimus.ietf.org; Thu, 13 May 2004 21:34: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 VAA00705 for ; Thu, 13 May 2004 21:34: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 1BORap-0000kb-VN for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:34:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORZn-0000AQ-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:33:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BORYb-0006xg-00 for forces-protocol-web-archive@ietf.org; Thu, 13 May 2004 21:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BORXR-0001Gk-2o; Thu, 13 May 2004 21: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 1BORWH-00010O-Ha for forces-protocol@optimus.ietf.org; Thu, 13 May 2004 21:29: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 VAA00434 for ; Thu, 13 May 2004 21:29: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 1BORWE-0005p7-Qa for forces-protocol@ietf.org; Thu, 13 May 2004 21:29:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BORVS-0005I5-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:28: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 1BORUb-0004k6-00 for forces-protocol@ietf.org; Thu, 13 May 2004 21:28: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 2004051318321927:3013 ; Thu, 13 May 2004 18:32:19 -0700 Subject: RE: [Forces-protocol] Notes from ForCES protocol meeting call From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: Weiming Wang , forces-protocol@ietf.org In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108CF88@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108CF88@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084498078.1038.79.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 05/13/2004 06:32:19 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/13/2004 06:32:20 PM, Serialize complete at 05/13/2004 06:32:20 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: 13 May 2004 21:27:58 -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, Strange but we raised the same questions asynchronously ;-> It is semantically cleaner to see HB as synchronous as opposed to async - which is closely mapped to events. So it may make sense to have them as separate. The subscribe unsucribe is very valuable to have even if the messages are separate. cheers, jamal On Thu, 2004-05-13 at 21:05, Khosravi, Hormuzd M wrote: > Weiming, All, > > Thanks for this posting. Describing the message format in this detail > makes it easy to understand and is useful. One clarification, Event Flag > is part of the V in TLV, right ? > > Couple of other questions... > What does Event 'Config' msg mean ? What direction is this msg CE-FE ?? > I am a little confused about this. > What does Event 'Report' mean? I think this is a Event Notification from > FE->CE, correct ? > > One good technical point that I just thought of (after reading your msg > format below :)), is that we don't want to have Responses for Event > msgs. They are asynchronous messages to notify events for the most part. > But we do need Responses for HBs and Subscribe/Unsubscribe. So how do > you address that issue if you make HBs, Subscribe, etc part of Event > msg. This might be a good reason to have them as separate msgs, but I > would like to know your thoughts on this ? > > > Thanks > Hormuzd > > -----Original Message----- > From: Weiming Wang [mailto:wmwang@mail.hzic.edu.cn] > > BTW, have we decided on separate messages for HBs or is it part of > events ? If this is part of event then this might be another Event msg > from CE to FE. > > [Weiming] I suggest to treat HB as an event. In this way, we then can > start (by > subscribe) or stop (unsubscribe) it very easily. And moreover, we may > even set > parameters to the HB such as the HB interval. Talking about this, I > actually > have another thought that, HB is not the only event that need to setup > parameters before we start them, therefore, apart from 'subscribe' and > unsubscribe' for events, we may also need operations such as 'config'. > Pls allow > me to use PDU to explain this more, and also try to response to Jamal > on the > possible event msg format ask. > > EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ... : TLV > TLV = Type : Length : Value > Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | > 'Config' > EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' > Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID : > EventDescription > Value (with EventFlag = 'NonLFBEvent') = EventDescription > EventDescription for 'Subscribe' / 'Unsubscribe' = EventType(XML or ID, > to be > decided?) > EventDescription for 'Report' = EventType : [Length] : EventValue(XML?) > EventDescription for 'Config' = EventType : [Length] : > EventParameterDescription(XML?) _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 03:38: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 DAA03750 for ; Fri, 14 May 2004 03:38: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 1BOXFI-0000qc-GD for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:36:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7aetR003259 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:36:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXDA-0000Lx-3i for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:34: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 DAA03411 for ; Fri, 14 May 2004 03:34: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 1BOXD7-0003JK-Pe for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:34:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXBb-0002bz-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:32:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOXAa-00025b-03 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:31: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 1BOX8g-00026p-9Y for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:29:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX7t-0007bK-Ta; Fri, 14 May 2004 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX4b-0006pf-58 for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 03:25: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 DAA02807 for ; Fri, 14 May 2004 03:25: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 1BOX4Y-00060h-Sy for forces-protocol@ietf.org; Fri, 14 May 2004 03:25:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX2y-0005DT-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:23:57 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOX0p-0003h1-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:21:45 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 14 May 2004 15:33:41 +0800 Message-ID: <05ed01c43983$faeab000$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <468F3FDA28AA87429AD807992E22D07E01013842@orsmsx408.jf.intel.com> <009c01c438fc$567615f0$020aa8c0@wwm1> <1084496779.1038.68.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call 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, 14 May 2004 15:20:48 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, Hormuzd as well, Thanks for the comments. ----- Original Message ----- From: "Jamal Hadi Salim" > On Thu, 2004-05-13 at 11:09, Weiming Wang wrote: > > > ----- Original Message ----- > > > [Weiming] I suggest to treat HB as an event. In this way, we then can start (by > > subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set > > parameters to the HB such as the HB interval. Talking about this, I actually > > have another thought that, HB is not the only event that need to setup > > parameters before we start them, therefore, apart from 'subscribe' and > > unsubscribe' for events, we may also need operations such as 'config'. Pls allow > > me to use PDU to explain this more, and also try to response to Jamal on the > > possible event msg format ask. > > i think theres value in HB being able to be subscribed and unsubcribed > for; not sure though if it fits here in general. What if CE wants to > "ping"/hearbeat a LFB or FE? > You seem to indicate direction is FE->CE > [Weiming]I'm actually quite sure HB can be fit in the general Event Msg, even for the case that you mentioned for LFB HB. First, I should say the direction for Event Msg can be either FE->CE, CE->FE, just as you and Hormuzd earlier proposed to indicate it by protocol text. The possible description for direction may be as: For Sub/Unsub ops, usually the event is from CE->FE For Report(or Notification), either direction is possible. For Configure parameters, the direction is CE->FE. To subscribe an HB in a LFB, we just treat the HB as an event in a LFB, and follow the general LFBEvent subscription ops. > > > > EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ... : TLV > > TLV = Type : Length : Value > > Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config' > > EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' > > Hormuzd posted some extra flags field in the TLV in the message body. > Should we shoot for consistency or do you think flags belong in the T > part? > [Weiming]After I posted this, I realized that it may result in some confusion. Here I set the EventFlag(1bit) in the Type field is only for the classification of the Types, because I just realize there may be mainly two kind of Types here, one for LFB ops, another for non LFB (or called FE (coarse layer) Event) ops. We need to classify them because the followed Value format for them are quite different. To summarize, we may need not to use the EventFlag, instead, just have following Types: Type = 'LFBEventSub' | 'LFBEventUnsub' | 'LFBEventReport' | 'LFBEventConfig' | 'FEEventSub' | 'FEEventUnsub' | 'FEEventReport' | 'FEEventConfig'; Of course, the flag to indicate the LFB ops and NonLFB ops can also be put in the TLV's V part, I'm also trying to see which is more precise in description. Moreover, I think msgs like Query, Config, State maintenance as well as Event msgs all have the problems to distinguish the ops between LFBs and NonLFBs(FE Coarse layer), therefore, I agree we need to have a consistency between these msgs regarding the description. I'm also going to make a comments on Hormuzd's config msg format, where I try to explain more of my thoughts on other extra flags there. So could you follow my more reply there? [/Weming] > > Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID : > > EventDescription > > Value (with EventFlag = 'NonLFBEvent') = EventDescription > > EventDescription for 'Subscribe' / 'Unsubscribe' = EventType(XML or ID, to be > > decided?) > > EventDescription for 'Report' = EventType : [Length] : EventValue(XML?) > > EventDescription for 'Config' = EventType : [Length] : > > EventParameterDescription(XML?) > > So what is the event value for config? Is it a config message that was > sent by CE to FE? > > I think you have a good start above. > > 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 Fri May 14 03:44: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 DAA04091 for ; Fri, 14 May 2004 03:44: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 1BOXH8-0001YK-74 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:38:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7cYNe005964 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXFd-0000v2-Bb for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:37: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 DAA03695 for ; Fri, 14 May 2004 03:36: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 1BOXFa-00051I-Rj for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:36:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXEi-0004T3-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:36:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOXDV-0003em-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:34:49 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOXDX-0002Fz-Je for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:34:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX7u-0007ba-Md; Fri, 14 May 2004 03:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX4n-0006qA-12 for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 03:25: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 DAA02829 for ; Fri, 14 May 2004 03:25: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 1BOX4k-00067s-N6 for forces-protocol@ietf.org; Fri, 14 May 2004 03:25:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX3C-0005FW-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:24:10 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOX1I-0004JM-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:22:13 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 14 May 2004 15:33:48 +0800 Message-ID: <05ee01c43983$ff821270$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , "Jamal Hadi Salim" , References: <468F3FDA28AA87429AD807992E22D07E01013E56@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Add Route Example 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, 14 May 2004 15:20: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, and Jamal, I'm glad you post the msg format, which is helpful for our progress. ----- Original Message ----- From: "Khosravi, Hormuzd M" Here are some examples for what our ForCES msg might look like... Here is a TLV... (16 bits for T, 16 bits for L & variable len V) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add Route Msg.... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Common Header fields... | | Command Type = Config | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=LFB(or FE)attrs | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Operation=Add(Del,DelAll,Update| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID=IPv4 Fwdr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Array of route entries | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Weiming] I suggest to let the Operation field as the TLV's Type field, that is, to let Type = Add/Del/DelAll/Update/... instead of the LFB(or FE) attributes. And as I also mentioned in the Event msg, I even suggest to separate the FE attributes and LFB attributes in the Type, because the followed PDU format are so different for both them. The reason not to use the LFB attributes as the Type are: 1) The 16bits Type space may be not enough for all LFB attributes, just imaging we'v left 16bits space for LFB type ID and LFB instance ID, hence, we can reasonably assume the LFB attibute number will exceed the 16bits space very easily. 2) I think there is a possibility in FE model to use XML or plain text instead of IDs to describe the LFB attributes or FE attributes. In this case, we may not be able to use them as the type IDs. [/Weiming] The array of route entries will be defined by the FE Model team. Actually I suspect, they will define an IPv4 Prefix and IPv4 NextHop LFB and this msg will carry an array of prefixes and Nexthops. For a reference example of the actual route structs, look at http://www.npforum.org/techinfo/IPv4_IA.pdf I will also try to find some more examples looking at our code here, [Weiming]I also suggest you present a format for FE attribute op if it convenient to you. For I think we may see more via the two formats then. Thank you. Hope this helps, Let me know what you guys think ? Thanks Hormuzd Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 03:46:21 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 DAA04175 for ; Fri, 14 May 2004 03:46: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 1BOXJx-0002F7-E8 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:41:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E7fTGg008566 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 03:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXFi-0000wU-3J for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:37: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 DAA03725 for ; Fri, 14 May 2004 03:37: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 1BOXFf-00051p-Nz for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:37:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXEs-0004UR-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:36:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOXE3-0003ua-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:35:23 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOXE5-0002HK-BX for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 03:35:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX7v-0007bg-0W; Fri, 14 May 2004 03:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOX4u-0006qG-NP for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 03:25: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 DAA02835 for ; Fri, 14 May 2004 03:25: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 1BOX4s-0006BU-EB for forces-protocol@ietf.org; Fri, 14 May 2004 03:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOX3I-0005GX-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:24:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOX1R-0004JM-00 for forces-protocol@ietf.org; Fri, 14 May 2004 03:22:24 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Fri, 14 May 2004 15:33:56 +0800 Message-ID: <05ef01c43984$03db8180$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E0108CF88@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Notes from ForCES protocol meeting call 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, 14 May 2004 15:21: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Hormuzd, and Jamal as well, ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, All, Thanks for this posting. Describing the message format in this detail makes it easy to understand and is useful. One clarification, Event Flag is part of the V in TLV, right ? [Weimig]I'v made a clarification on this flag in my reply to Jamal, could you see there for my thought? Couple of other questions... What does Event 'Config' msg mean ? What direction is this msg CE-FE ?? I am a little confused about this. [Weiming] I actually have mentioned this a little in the last post. My original thought was some events may need to setup some parameters (may be called Event attributes) before they can act. E.g., the HB event, it may be told the time interval to send the HB signals before it can actually be used, therefore, the Event config op is used to set up the time interval for the HB. The direction is surely be from CE->FE. Of course, this event attributes can also be configured by Config msg, owing to the same reason for Sub/Unsub ops, we may also put it in Event msg. We may need to discuss it more on which is better? [/Weiming] What does Event 'Report' mean? I think this is a Event Notification from FE->CE, correct ? [Weiming] Yes. I may change it, just a little unaccustomed to the name :). One good technical point that I just thought of (after reading your msg format below :)), is that we don't want to have Responses for Event msgs. They are asynchronous messages to notify events for the most part. But we do need Responses for HBs and Subscribe/Unsubscribe. So how do you address that issue if you make HBs, Subscribe, etc part of Event msg. This might be a good reason to have them as separate msgs, but I would like to know your thoughts on this ? [Weiming] You'v raised one important thing I missed, that is, we need to have Event Response msg. By using the ACK flags in the common header, we are very flexible to accommedate the cases you mentioned above. E.g., For Event Sub/Unsub/Config ops, usually we need the responses, therefore, the msgs are set to request ACKs. For Event Notification(Report), we may in most cases do not need the responses, but whenever we need it, just set the ACK flags. Actually, I think we may quite possibly have other event notifications as well as HBs that need responses, e.g., a capability change event notification may be very willing to be ACKed that the CE has surely received the msg. [/Weiming] Thanks Hormuzd -----Original Message----- From: Weiming Wang [mailto:wmwang@mail.hzic.edu.cn] BTW, have we decided on separate messages for HBs or is it part of events ? If this is part of event then this might be another Event msg from CE to FE. [Weiming] I suggest to treat HB as an event. In this way, we then can start (by subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set parameters to the HB such as the HB interval. Talking about this, I actually have another thought that, HB is not the only event that need to setup parameters before we start them, therefore, apart from 'subscribe' and unsubscribe' for events, we may also need operations such as 'config'. Pls allow me to use PDU to explain this more, and also try to response to Jamal on the possible event msg format ask. EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ... : TLV TLV = Type : Length : Value Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config' EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) ' Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID : EventDescription Value (with EventFlag = 'NonLFBEvent') = EventDescription EventDescription for 'Subscribe' / 'Unsubscribe' = EventType(XML or ID, to be decided?) EventDescription for 'Report' = EventType : [Length] : EventValue(XML?) EventDescription for 'Config' = EventType : [Length] : EventParameterDescription(XML?) _______________________________________________ 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 May 14 09:59:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23163 for ; Fri, 14 May 2004 09:59: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 1BOdB3-0001gZ-9S for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 09:56:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EDufut006475 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 09:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOd9R-0001LU-O1 for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 09:55: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 JAA22967 for ; Fri, 14 May 2004 09:54: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 1BOd9P-0003XD-OP for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 09:54:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOd8W-00032S-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 09:54:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOd7K-0002K1-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 09:52:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOd3d-0000Q6-Az; Fri, 14 May 2004 09: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 1BOd1l-0008JG-E0 for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 09:47: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 JAA22693 for ; Fri, 14 May 2004 09:47:01 -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 1BOd1j-0007Jb-2C for forces-protocol@ietf.org; Fri, 14 May 2004 09:47:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOd0m-0006nu-00 for forces-protocol@ietf.org; Fri, 14 May 2004 09:46:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BOczi-0006JK-00 for forces-protocol@ietf.org; Fri, 14 May 2004 09:44:59 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOczg-000BET-Tj for forces-protocol@ietf.org; Fri, 14 May 2004 13:44:57 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <40A3FEB6.8050301@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> <40A3FEB6.8050301@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 14 May 2004 15:44:47 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 14 maj 2004, at 01.03, Robert Haas wrote: > I finally see a justification for plain batching (that is, batching > without atomicity): a batch will result in a single status: [ad] Actually I have found that problematic. What i have found is that I need a error per command. the overall error indicator can be used to indicate that one or more of the commands failed, but each command probably needs its own error indicated. > OK if all commands in the batch failed, and notOK if some of them > failed (and probably we should stop processing commands after the > first failure). I think that is a different type of command, the do until error batch. > > Is this a semantics that would be acceptable to everyone ? I guess I don't think so. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 17:18:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28279 for ; Fri, 14 May 2004 17: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 1BOjtF-0003Xh-P8 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 17:06:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EL6j8s013618 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 17:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOji5-0008BD-3U for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 16:55: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 QAA25836 for ; Fri, 14 May 2004 16:55: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 1BOji3-0003vd-2X for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 16:55:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOjgd-0003CQ-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 16:53:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOjeU-0002G5-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 16:51:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjRr-0008JD-5b; Fri, 14 May 2004 16:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOir7-0000Le-PA for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 16:00: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 QAA19526 for ; Fri, 14 May 2004 16:00: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 1BOir6-000410-31 for forces-protocol@ietf.org; Fri, 14 May 2004 16:00:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOiq5-0003Te-00 for forces-protocol@ietf.org; Fri, 14 May 2004 15:59:26 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BOip2-0002Sr-00 for forces-protocol@ietf.org; Fri, 14 May 2004 15:58:20 -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 i4EJwbEM026445; Fri, 14 May 2004 19:58: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 i4EJtN5A011726; Fri, 14 May 2004 19:55: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 M2004051412574831163 ; Fri, 14 May 2004 12:57: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); Fri, 14 May 2004 12:57: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] Next Conference Call on Monday 5 PM PST? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D501@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Next Conference Call on Monday 5 PM PST? Thread-Index: AcQ5UX4aQDFvXCbsReC8KK9mfNJRqgAm/o1A From: "Khosravi, Hormuzd M" To: Cc: X-OriginalArrivalTime: 14 May 2004 19:57:47.0252 (UTC) FILETIME=[BA84E340:01C439ED] 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, 14 May 2004 12:57: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 Ram called me and said he is currently traveling but might be able to make it on Monday. Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ?? Pls do let me know Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, May 13, 2004 6:19 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday ? Monday is fine with me. cheers, jamal On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote: > Hi Team >=20 > Let me know if you would like me to arrange a call for Friday or Monday > (next week) ?? >=20 > Thanks > Hormuzd >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 18:00:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01207 for ; Fri, 14 May 2004 18:00: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 1BOkhN-00024u-Qb for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 17:58:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ELwX6t007983 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 17:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkah-0000l6-14 for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 17:51: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 RAA00620 for ; Fri, 14 May 2004 17: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 1BOkae-0007WO-BA for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 17:51:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkZf-0006zt-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 17:50:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOkYf-0006U2-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 17:49:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkQg-00072w-2G; Fri, 14 May 2004 17:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkNX-0005t5-10 for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 17:38: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 RAA29473 for ; Fri, 14 May 2004 17:37: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 1BOkNU-00001Y-BI for forces-protocol@ietf.org; Fri, 14 May 2004 17:38:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkM6-0007E7-00 for forces-protocol@ietf.org; Fri, 14 May 2004 17:36:35 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BOkLU-0006hB-00 for forces-protocol@ietf.org; Fri, 14 May 2004 17:35:56 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4ELZNlg028624; Fri, 14 May 2004 21:35:23 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 i4ELZJBu251308; Fri, 14 May 2004 23:35:19 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.21.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA75874; Fri, 14 May 2004 23:35:17 +0200 Message-ID: <40A53B93.1090104@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, forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? References: <468F3FDA28AA87429AD807992E22D07E0108D501@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D501@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------010508030608020200010607" 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, 14 May 2004 23:35:15 +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.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------010508030608020200010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i4ELZNlg028624 Content-Transfer-Encoding: quoted-printable Actually this time it is not very convenient for me as I will be in=20 Zurich, and that will be 2 AM ... The only two possible schedules between are: PST 10 pm Zurich 7 am China 1 pm (probably not OK for the East Coast if anyone joins from there). or PST 7 am Zurich 4 pm China 10 pm The good thing about such early/late calls is that it should not=20 interfere with other meetings ... I personally don't mind the late calls=20 at 10 pm. The whole of next week is OK with me. -Robert Khosravi, Hormuzd M wrote: >Ram called me and said he is currently traveling but might be able to >make it on Monday. > >Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ?? >Pls do let me know > > >Thanks >Hormuzd > >-----Original Message----- >From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >Sent: Thursday, May 13, 2004 6:19 PM >To: Khosravi, Hormuzd M >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday >? > > >Monday is fine with me. > >cheers, >jamal > >On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote: > =20 > >>Hi Team >> >>Let me know if you would like me to arrange a call for Friday or >> =20 >> >Monday > =20 > >>(next week) ?? >> >>Thanks >>Hormuzd >> >> =20 >> > > >_______________________________________________ >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 --------------010508030608020200010607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Actually this time it is not very convenient for me as I will be in Zurich, and that will be 2 AM ...

The only two possible schedules  between are:

PST 10 pm
Zurich 7 am
China 1 pm
(probably not OK for the East Coast if anyone joins from there).

or

PST 7 am
Zurich 4 pm
China 10 pm


The good thing about such early/late calls is that it should not interfere with other meetings ... I personally don't mind the late calls at 10 pm. The whole of next week is OK with me.

-Robert

Khosravi, Hormuzd M wrote:
Ram called me and said he is currently traveling but might be able to
make it on Monday.

Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ??
Pls do let me know


Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] 
Sent: Thursday, May 13, 2004 6:19 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday
?


Monday is fine with me.

cheers,
jamal

On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote:
  
Hi Team

Let me know if you would like me to arrange a call for Friday or
    
Monday
  
(next week) ??

Thanks
Hormuzd

    


_______________________________________________
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
--------------010508030608020200010607-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 18:11:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02329 for ; Fri, 14 May 2004 18:11: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 1BOkpQ-0006ai-6x for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 18:06:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EM6qwU025335 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 18:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkjW-0002xK-2I for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 18:00: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 SAA01175 for ; Fri, 14 May 2004 18:00: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 1BOkjT-0004H6-Dr for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 18:00:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkiY-0003lC-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 17:59:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOkhW-0003FI-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 17:58:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkb3-0000lX-3y; Fri, 14 May 2004 17: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 1BOkVj-0008FQ-5U for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 17:46: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 RAA00320 for ; Fri, 14 May 2004 17:46: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 1BOkVg-0004wl-Fj for forces-protocol@ietf.org; Fri, 14 May 2004 17:46:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkUo-0004RD-00 for forces-protocol@ietf.org; Fri, 14 May 2004 17:45: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 1BOkU1-0003kN-00 for forces-protocol@ietf.org; Fri, 14 May 2004 17:44:45 -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 i4ELiU0f014656; Fri, 14 May 2004 21:44:30 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 i4ELhrdN028003; Fri, 14 May 2004 21:44:38 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 M2004051414440915965 ; Fri, 14 May 2004 14:44: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, 14 May 2004 14:44:09 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C439FC.963DC606" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Next Conference Call on Monday 5 PM PST? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D6D3@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Next Conference Call on Monday 5 PM PST? Thread-Index: AcQ5+3wnGR+bqxudSmmKRMn0be+fEAAAL0nA From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: , X-OriginalArrivalTime: 14 May 2004 21:44:09.0208 (UTC) FILETIME=[96761780:01C439FC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 14 May 2004 14:44:08 -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_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C439FC.963DC606 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We can go with 7 am PST on Monday. (10 pm PST will be 1 am for Jamal :)) =20 Weiming, Avri hope this will work for you guys ? -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, May 14, 2004 2:35 PM To: Khosravi, Hormuzd M Cc: hadi@znyx.com; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? Actually this time it is not very convenient for me as I will be in = Zurich, and that will be 2 AM ...=20 The only two possible schedules between are: PST 10 pm Zurich 7 am China 1 pm=20 (probably not OK for the East Coast if anyone joins from there). or PST 7 am Zurich 4 pm China 10 pm The good thing about such early/late calls is that it should not = interfere with other meetings ... I personally don't mind the late calls = at 10 pm. The whole of next week is OK with me. -Robert Khosravi, Hormuzd M wrote: Ram called me and said he is currently traveling but might be able to make it on Monday. Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ?? Pls do let me know Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, May 13, 2004 6:19 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday ? Monday is fine with me. cheers, jamal On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote: =20 Hi Team Let me know if you would like me to arrange a call for Friday or =20 Monday =20 (next week) ?? Thanks Hormuzd =20 _______________________________________________ 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 ------_=_NextPart_001_01C439FC.963DC606 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
We=20 can go with 7 am PST on Monday. (10 pm PST will be 1 am for Jamal=20 :))
 
Weiming, Avri hope this will work for you guys = ?
-----Original Message-----
From: = Robert Haas=20 [mailto:rha@zurich.ibm.com]
Sent: Friday, May 14, 2004 2:35 = PM
To: Khosravi, Hormuzd M
Cc: hadi@znyx.com;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Next = Conference Call on Monday 5 PM PST?

Actually this = time it=20 is not very convenient for me as I will be in Zurich, and that will be = 2 AM=20 ...

The only two possible schedules  between = are:

PST 10=20 pm
Zurich 7 am
China 1 pm
(probably not OK for the East = Coast if=20 anyone joins from there).

or

PST 7 am
Zurich 4 = pm
China 10=20 pm


The good thing about such early/late calls is that it = should not=20 interfere with other meetings ... I personally don't mind the late = calls at 10=20 pm. The whole of next week is OK with = me.

-Robert

Khosravi,=20 Hormuzd M wrote:
Ram called me and said he is currently =
traveling but might be able to
make it on Monday.

Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ??
Pls do let me know


Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20
Sent: Thursday, May 13, 2004 6:19 PM
To: Khosravi, Hormuzd M
Cc: forces-protocol@ietf.org
Subject: Re: [Forces-protocol] Next Conference Call on Friday or Monday
?


Monday is fine with me.

cheers,
jamal

On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote:
  
Hi Team

Let me know if you would like me to arrange a call for Friday or
    
Monday
  
(next week) ??

Thanks
Hormuzd

    


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


  

--=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
------_=_NextPart_001_01C439FC.963DC606-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 18:29:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03626 for ; Fri, 14 May 2004 18:29: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 1BOl7X-0006Xb-HJ for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 18:25:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EMPZBJ025144 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 18:25:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOl6T-00062f-BE for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 18:24: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 SAA03380 for ; Fri, 14 May 2004 18:24: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 1BOl6Q-0000fp-DW for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 18:24:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOl5g-0000Bp-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 18:23:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOl4p-0007UX-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 18:22:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOkwL-0002E3-Dy; Fri, 14 May 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 1BOkpx-0006xL-0H for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 18:07: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 SAA01815 for ; Fri, 14 May 2004 18: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 1BOkpu-0007jy-6h for forces-protocol@ietf.org; Fri, 14 May 2004 18:07:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOkow-0007Eq-00 for forces-protocol@ietf.org; Fri, 14 May 2004 18:06:23 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BOkns-0005nc-00 for forces-protocol@ietf.org; Fri, 14 May 2004 18:05:16 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4EM4jfV050022 for ; Fri, 14 May 2004 22:04:45 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 i4EM4jBu215858 for ; Sat, 15 May 2004 00:04:45 +0200 Received: from zurich.ibm.com (CASTRO.almaden.ibm.com [9.1.21.137]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA42400 for ; Sat, 15 May 2004 00:04:44 +0200 Message-ID: <40A5427A.2000101@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: forces-protocol@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id i4EM4jfV050022 Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] action item: NFS compound commands 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, 15 May 2004 00:04:42 +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 Here are some clarifications about NFSv4 compound commands. NFSv4 introduces the notion of a compound command that groups a serie of=20 operations not executed atomically. Execution stops at the first failed=20 operation. Status report is returned up to (and including) the failed=20 operation. Most interestingly, compound commands allow results of intermediate=20 operations to be stored and reused on subsequent operations in the same=20 compound. In ForCES, you could imagine using this feature for instance to do the=20 following in one shot (a compound commands composed of 2 operations): operation 1: read the rate r at which flow x is currently sending. operation 2: set the same rate r for the policing of a new flow y. (the=20 result of the first operation is reused here) We can debate whether this is desirable in ForCES or not. This feature=20 was introduced in NFSv4 for performance reasons. CHeers, -Robert Below are excerpts of the NFSv4 paper on the justification for compound=20 commands: Another structural difference between NFS Version 4 and its predecessors is the introduction of a COMPOUND RPC procedure that allows the client to group traditional file operations into a single request to send to the server. In NFS Versions 2 and 3, all actions were RPC procedures. NFS Version 4 is no longer a =93simple=94 RPC-based distributed application. In NFS Version 4, work is accomplished via operations. An operation is a file system action that forms part of a COMPOUND procedure. NFS Version 4 operations correspond functionally to RPC procedures in former versions of NFS. The server in turn groups the operation replies into a single response. Error handling is simple on the server =96 evaluation proceeds until the first error or last operation whereupon the server returns a reply for all evaluated operations. We introduced the COMPOUND procedure to reduce network round trip latency for related operations, which can be costly over a WAN (for example, the Internet). [...] 4.1. An example The following denotations represent NFS transactions in this paper. We represent a simple client RPC request in NFS Versions 2 and 3 by: -> LOOKUP We represent a simple server RPC response by: <- LOOKUP OK We represent a COMPOUND client RPC request in NFS Version 4, which contains one or more operations, by: -> PUTROOTFH LOOKUP GETFH We represent a COMPOUND server RPC response in NFS Version 4, which contains one or more replies to previous operations, by: <- PUTROOTFH OK LOOKUP OK GETFH OK Note the direction of the arrows in each example. [...] The set of operations in a COMPOUND procedure is not atomic. That is, no assumptions can be made as to whether conflicting operations occurred to file system objects referenced in a COMPOUND procedure between successive operations. Error handling is simple on the server. If an operation fails in a COMPOUND procedure, evaluation halts and the remaining operations are not processed. Replies are returned to the client up to and including the error reply for the failed operation. The full paper is at: http://www.nluug.nl/events/sane2000/papers/pawlowski.pdf --=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 Fri May 14 21:50:52 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 VAA11375 for ; Fri, 14 May 2004 21:50: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 1BOoJ5-0006hg-Gu for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 21:49:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F1nhE3025766 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 21:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoIP-0006Rj-6l for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 21:49: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 VAA11282 for ; Fri, 14 May 2004 21:48: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 1BOoIM-0006yB-Bj for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:48:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoHE-0006Sl-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:47:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOoGY-0005yQ-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoAf-00058p-J9; Fri, 14 May 2004 21:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOo7s-0004Vp-PC for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 21:38: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 VAA10560 for ; Fri, 14 May 2004 21:38: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 1BOo7p-0001Sw-Sj for forces-protocol@ietf.org; Fri, 14 May 2004 21:38:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOo6b-0000rr-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:36:49 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BOo54-0007VI-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:35:14 -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 i4F1Yv0f017820; Sat, 15 May 2004 01:34:57 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 i4F1YvJ0018981; Sat, 15 May 2004 01:35:04 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 M2004051418343207885 ; Fri, 14 May 2004 18:34: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); Fri, 14 May 2004 18:34: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D8FC@orsmsx408.jf.intel.com> Thread-Topic: HB msgs ? Thread-Index: AcQ5UrnioR6Zxd8SSzyzYgSQO5LoSwAyOuIw From: "Khosravi, Hormuzd M" To: Cc: "Weiming Wang" , X-OriginalArrivalTime: 15 May 2004 01:34:32.0792 (UTC) FILETIME=[C5F59D80:01C43A1C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] HB msgs ? 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, 14 May 2004 18:34:32 -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 you. However, Weiming (Robert ?) have different views on this. How do we resolve this ? I don't want us to be stuck on this. I guess the key question that I would ask is if we want Event msg to symbolize asynchronous events or we want to mix the semantics with synchronous msgs as well ? I think keeping the 2 separate is cleaner, but I am open to other views as well. Avri, could you share your opinion on this ? Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Hormuzd, Strange but we raised the same questions asynchronously ;-> It is semantically cleaner to see HB as synchronous as opposed to=20 async - which is closely mapped to events. So it may make sense to have them as separate. The subscribe unsucribe is very valuable to have even if the messages are separate. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:01:51 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 WAA11939 for ; Fri, 14 May 2004 22:01: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 1BOoTY-00006r-Ih for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:00:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F20WsJ000417 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:00:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoRd-00081s-Aj for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 21:58: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 VAA11836 for ; Fri, 14 May 2004 21:58: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 1BOoRa-0003yE-FS for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:58:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoQl-0003W2-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:57:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOoQG-000335-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 21:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoKM-0006zp-97; Fri, 14 May 2004 21: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 1BOoJ6-0006hk-4e for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 21:49: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 VAA11334 for ; Fri, 14 May 2004 21:49: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 1BOoJ3-0007SR-7o for forces-protocol@ietf.org; Fri, 14 May 2004 21:49:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoIJ-0006xh-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:48: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 1BOoHC-000618-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:47:46 -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 i4F1kNL9013336; Sat, 15 May 2004 01:46:23 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 i4F1iO5M014671; Sat, 15 May 2004 01:44:47 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 M2004051418471218794 ; Fri, 14 May 2004 18:47:12 -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, 14 May 2004 18:47:12 -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: <468F3FDA28AA87429AD807992E22D07E0108D8FE@orsmsx408.jf.intel.com> Thread-Topic: Event attributes Thread-Index: AcQ5hCr3Y3pnkiobRKSmOeP/83z0YQAmO83w From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 15 May 2004 01:47:12.0551 (UTC) FILETIME=[8ACFA370:01C43A1E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Event attributes 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, 14 May 2004 18:47: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, All -----Original Message----- Couple of other questions... What does Event 'Config' msg mean ? What direction is this msg CE-FE ?? I am a little confused about this. [Weiming] I actually have mentioned this a little in the last post. My original thought was some events may need to setup some parameters (may be called Event attributes) before they can act. E.g., the HB event, it may be told the time interval to send the HB signals before it can actually be used, therefore, the Event config op is used to set up the time interval for the HB. The direction is surely be from CE->FE. Of course, this event attributes can also be configured by Config msg, owing to the same reason for Sub/Unsub ops, we may also put it in Event msg. We may need to discuss it more on which is better? [/Weiming] I see what you mean now. The question I would ask is, do we really need configuration of event attributes ? and if so at what time ? In our current implementation, we do setup of HB interval at Join or Association setup time before we actually start sending HBs. Most protocols I know either have this as a default value or do this at start-up time. Changing this in the middle can make the implementation tricky. Do you guys do this currently ? Also, are there any other Event attributes that one might want to configure ? I cannot think of any right now. Once we answer the basic questions, we can decide if this should be part of Event or Config or some other msg. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:12: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 WAA12456 for ; Fri, 14 May 2004 22:12: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 1BOodx-0002Fq-8v for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:11:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F2BHTA008660 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22: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 1BOoXd-0000jc-5z for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 22:04: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 WAA12221 for ; Fri, 14 May 2004 22:04: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 1BOoXa-00070W-5B for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:04:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoWY-0006Ua-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:03:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOoVR-0005w7-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:02:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoUy-0000JG-9N; Fri, 14 May 2004 22:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoSe-0008Fy-A1 for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 21:59: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 VAA11843 for ; Fri, 14 May 2004 21:59: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 1BOoSb-0004Qv-9Y for forces-protocol@ietf.org; Fri, 14 May 2004 21:59:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoRX-0003xr-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:58: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 1BOoQN-00032w-00 for forces-protocol@ietf.org; Fri, 14 May 2004 21:57:15 -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 i4F1tjc1028437; Sat, 15 May 2004 01:55:45 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 i4F1vEJ0027728; Sat, 15 May 2004 01:57:15 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 M2004051418564309298 ; Fri, 14 May 2004 18:56: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); Fri, 14 May 2004 18:56: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] Add Route Example Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D900@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Add Route Example Thread-Index: AcQ5hAf1f2wwDJL8TV+AXV/IhwSgDgAmx5PA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , "Jamal Hadi Salim" , X-OriginalArrivalTime: 15 May 2004 01:56:43.0715 (UTC) FILETIME=[DF405930:01C43A1F] 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, 14 May 2004 18:56: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, Thanks for your comments. It seems like you misunderstood, see my clarification below. -----Original Message----- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Common Header fields... | | Command Type =3D Config | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DLFB(or FE)attrs | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Operation=3DAdd(Del,DelAll,Update| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID=3DIPv4 Fwdr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Array of route entries | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Weiming] I suggest to let the Operation field as the TLV's Type field, that is, to let Type =3D Add/Del/DelAll/Update/... instead of the LFB(or FE) attributes. And as I also mentioned in the Event msg, I even suggest to separate the FE attributes and LFB attributes in the Type, because the followed PDU format are so different for both them. The reason not to use the LFB attributes as the Type are: 1) The 16bits Type space may be not enough for all LFB attributes, just imaging we'v left 16bits space for LFB type ID and LFB instance ID, hence, we can reasonably assume the LFB attibute number will exceed the 16bits space very easily. 2) I think there is a possibility in FE model to use XML or plain text instead of IDs to describe the LFB attributes or FE attributes. In this case, we may not be able to use them as the type IDs. [/Weiming] [HK] By LFB or FE attrs in the Type of TLV, I mean the Type of the message can either be Config LFB attributes or Config FE Attributes. Since we only have Config in the Command Type in the Common header, we need to distinguish between these 2 (as you had suggested before). So there can only be 2 Types (FE, LFB) in the current T field of TLV. Does that help clarify my intent ? It seems like you misunderstood this. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:18: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 WAA12685 for ; Fri, 14 May 2004 22:18: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 1BOojk-0003FY-Tg for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:17:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F2HGpD012488 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOogO-0002ha-Cy for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 22:13: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 WAA12526 for ; Fri, 14 May 2004 22:13: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 1BOogL-0003VM-AS for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:13:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOofL-00031h-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:12:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOoeX-0002YG-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:11:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOodk-00020i-84; Fri, 14 May 2004 22: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 1BOoX0-0000iM-RP for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 22:04: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 WAA12170 for ; Fri, 14 May 2004 22:04: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 1BOoWx-0006Xd-K7 for forces-protocol@ietf.org; Fri, 14 May 2004 22:04:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoVz-00060o-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:03: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 1BOoUq-0005BM-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:01:52 -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 i4F20TL9018441; Sat, 15 May 2004 02:00:29 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 i4F1wp5A019316; Sat, 15 May 2004 01:58:51 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 M2004051419011719904 ; Fri, 14 May 2004 19:01:17 -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, 14 May 2004 19:01:16 -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] Add Route Example Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D902@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Add Route Example Thread-Index: AcQ5Rr1hW0TsUYW1SbiLr/IulneyIQA2VJlQ From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , "Robert Haas" X-OriginalArrivalTime: 15 May 2004 02:01:16.0235 (UTC) FILETIME=[81AF99B0:01C43A20] 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, 14 May 2004 19:01:15 -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. Pls see my replies below. -----Original Message----- > Add Route Msg.... >=20 >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Common Header fields... | > | Command Type =3D Config = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=3DLFB(or FE)attrs | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Operation=3DAdd(Del,DelAll,Update| Flags = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Type ID=3DIPv4 Fwdr = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Array of route entries | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LFB Type ID, Type and even the operation should probably be the same field (eg "addroute"). Best place maybe the T(ype) portion of the TLV Although you may argue 16 bit may not be sufficient. Also maybe a version field may be valuable to have. The main header version is for the protocol and the version on TLV is for the LFB. [HK] Yes 16 bits might be insufficient for this. However, I could combine LFB Type (16 bits, including version no), Operation (8 bits), Flags (8 Bits) into a 32-bit field. Does that sound good ? Let me know Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:33: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 WAA13223 for ; Fri, 14 May 2004 22:33: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 1BOorV-0004bg-7y for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:25:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F2PHlM017704 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOom0-0003lv-9o for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 22:19: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 WAA12732 for ; Fri, 14 May 2004 22:19: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 1BOolx-0006Lx-3b for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOol2-0005sZ-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:18:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOojw-0005PL-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:17:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOojU-00035d-G3; Fri, 14 May 2004 22:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOofI-0002aO-9M for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 22:12: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 WAA12443 for ; Fri, 14 May 2004 22:12:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOofF-00030e-5V for forces-protocol@ietf.org; Fri, 14 May 2004 22:12:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoe8-0002Wg-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:11: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 1BOod4-0001ab-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:10:22 -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 i4F2AdEM015884 for ; Sat, 15 May 2004 02:10:40 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 i4F27J5E022855 for ; Sat, 15 May 2004 02:07:24 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 M2004051419095020638 for ; Fri, 14 May 2004 19:09:50 -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, 14 May 2004 19:09:50 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43A21.B44D9912" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D907@orsmsx408.jf.intel.com> Thread-Topic: T in TLV ? Thread-Index: AcQ6IbP2z9Wg37uORo2SKzVS70zicA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 May 2004 02:09:50.0817 (UTC) FILETIME=[B4669510:01C43A21] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] T in TLV ? 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, 14 May 2004 19:09:50 -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_01C43A21.B44D9912 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team, =20 One question that Jamal raised, do we want to have global scope for T in the TLV across all messages ? i.e. Type 0x1 means something for Association Setup msg and Type 0x32 means something for Config msg. =20 The other option is local scope i.e. Type 0x1 means something for Association Setup msg and=20 Type 0x1 means something else in Config msg. =20 I agree with Jamal that uniform semantics and global scope would be cleaner,=20 however let us know what you all think ?? =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C43A21.B44D9912 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Team,
 
One = question that=20 Jamal raised, do we want to have global scope for T in the TLV = across=20 all messages ?
i.e. = Type 0x1=20 means something for Association Setup msg and Type 0x32 means something = for=20 Config msg.
 
The = other option is=20 local scope i.e. Type 0x1 means something for Association Setup msg and=20
Type = 0x1 means=20 something else in Config msg.
 
I = agree with Jamal=20 that uniform semantics and global scope would be cleaner, =
however let us know=20 what you all think ??
 
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C43A21.B44D9912-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:43: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 WAA13747 for ; Fri, 14 May 2004 22:43: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 1BOp7G-0007Xw-4H for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:41:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F2fYjH028978 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOp1f-0006Kg-Bw for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 22:35: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 WAA13330 for ; Fri, 14 May 2004 22:35: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 1BOp1c-0006AC-1W for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:35:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOp0Y-0005gI-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:34:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOozx-0005DL-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOosF-0004eH-8F; Fri, 14 May 2004 22:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOooq-0004Bz-Au for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 22:22: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 WAA12806 for ; Fri, 14 May 2004 22:22: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 1BOoom-0007mO-UY for forces-protocol@ietf.org; Fri, 14 May 2004 22:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOono-0007Ip-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:21:28 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOomZ-0006NT-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:20:20 -0400 Received: from wwm1 (unverified [219.82.175.137]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Sat, 15 May 2004 10:32:53 +0800 Message-ID: <007101c43a22$8f069990$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E0108D6D3@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C43A65.984AE6D0" 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, 15 May 2004 10:15:49 +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_006E_01C43A65.984AE6D0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZVRoYXQncyBvayB0byBtZS4NCg0KV2VpbWluZw0KICAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICBUbzogUm9iZXJ0IEhh YXMgDQogIENjOiBoYWRpQHpueXguY29tIDsgZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBT ZW50OiBTYXR1cmRheSwgTWF5IDE1LCAyMDA0IDU6NDQgQU0NCiAgU3ViamVjdDogUkU6IFtGb3Jj ZXMtcHJvdG9jb2xdIE5leHQgQ29uZmVyZW5jZSBDYWxsIG9uIE1vbmRheSA1IFBNIFBTVD8NCg0K DQogIFdlIGNhbiBnbyB3aXRoIDcgYW0gUFNUIG9uIE1vbmRheS4gKDEwIHBtIFBTVCB3aWxsIGJl IDEgYW0gZm9yIEphbWFsIDopKQ0KDQogIFdlaW1pbmcsIEF2cmkgaG9wZSB0aGlzIHdpbGwgd29y ayBmb3IgeW91IGd1eXMgPw0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJv bTogUm9iZXJ0IEhhYXMgW21haWx0bzpyaGFAenVyaWNoLmlibS5jb21dIA0KICAgIFNlbnQ6IEZy aWRheSwgTWF5IDE0LCAyMDA0IDI6MzUgUE0NCiAgICBUbzogS2hvc3JhdmksIEhvcm11emQgTQ0K ICAgIENjOiBoYWRpQHpueXguY29tOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCiAgICBTdWJq ZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gTmV4dCBDb25mZXJlbmNlIENhbGwgb24gTW9uZGF5 IDUgUE0gUFNUPw0KDQoNCiAgICBBY3R1YWxseSB0aGlzIHRpbWUgaXQgaXMgbm90IHZlcnkgY29u dmVuaWVudCBmb3IgbWUgYXMgSSB3aWxsIGJlIGluIFp1cmljaCwgYW5kIHRoYXQgd2lsbCBiZSAy IEFNIC4uLiANCg0KICAgIFRoZSBvbmx5IHR3byBwb3NzaWJsZSBzY2hlZHVsZXMgIGJldHdlZW4g YXJlOg0KDQogICAgUFNUIDEwIHBtDQogICAgWnVyaWNoIDcgYW0NCiAgICBDaGluYSAxIHBtIA0K ICAgIChwcm9iYWJseSBub3QgT0sgZm9yIHRoZSBFYXN0IENvYXN0IGlmIGFueW9uZSBqb2lucyBm cm9tIHRoZXJlKS4NCg0KICAgIG9yDQoNCiAgICBQU1QgNyBhbQ0KICAgIFp1cmljaCA0IHBtDQog ICAgQ2hpbmEgMTAgcG0NCg0KDQogICAgVGhlIGdvb2QgdGhpbmcgYWJvdXQgc3VjaCBlYXJseS9s YXRlIGNhbGxzIGlzIHRoYXQgaXQgc2hvdWxkIG5vdCBpbnRlcmZlcmUgd2l0aCBvdGhlciBtZWV0 aW5ncyAuLi4gSSBwZXJzb25hbGx5IGRvbid0IG1pbmQgdGhlIGxhdGUgY2FsbHMgYXQgMTAgcG0u IFRoZSB3aG9sZSBvZiBuZXh0IHdlZWsgaXMgT0sgd2l0aCBtZS4NCg0KICAgIC1Sb2JlcnQNCg0K ICAgIEtob3NyYXZpLCBIb3JtdXpkIE0gd3JvdGU6DQoNClJhbSBjYWxsZWQgbWUgYW5kIHNhaWQg aGUgaXMgY3VycmVudGx5IHRyYXZlbGluZyBidXQgbWlnaHQgYmUgYWJsZSB0bw0KbWFrZSBpdCBv biBNb25kYXkuDQoNCldlaW1pbmcsIEF2cmksIFJvYmVydCwgb3RoZXJzIGlzIE1vbmRheSA1IFBN IFBTVCBmaW5lIGZvciBhIGNhbGwgPz8NClBscyBkbyBsZXQgbWUga25vdw0KDQoNClRoYW5rcw0K SG9ybXV6ZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFtYWwgSGFkaSBT YWxpbSBbbWFpbHRvOmhhZGlAem55eC5jb21dIA0KU2VudDogVGh1cnNkYXksIE1heSAxMywgMjAw NCA2OjE5IFBNDQpUbzogS2hvc3JhdmksIEhvcm11emQgTQ0KQ2M6IGZvcmNlcy1wcm90b2NvbEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIE5leHQgQ29uZmVyZW5jZSBD YWxsIG9uIEZyaWRheSBvciBNb25kYXkNCj8NCg0KDQpNb25kYXkgaXMgZmluZSB3aXRoIG1lLg0K DQpjaGVlcnMsDQpqYW1hbA0KDQpPbiBUaHUsIDIwMDQtMDUtMTMgYXQgMTk6MjMsIEtob3NyYXZp LCBIb3JtdXpkIE0gd3JvdGU6DQogIEhpIFRlYW0NCg0KTGV0IG1lIGtub3cgaWYgeW91IHdvdWxk IGxpa2UgbWUgdG8gYXJyYW5nZSBhIGNhbGwgZm9yIEZyaWRheSBvcg0KICAgIE1vbmRheQ0KICAo bmV4dCB3ZWVrKSA/Pw0KDQpUaGFua3MNCkhvcm11emQNCg0KICAgIA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRm9yY2VzLXByb3RvY29sIG1haWxp bmcgbGlzdA0KRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wNCg0KDQogIA0KDQotLSANClJvYmVydCBI YWFzDQpJQk0gWnVyaWNoIFJlc2VhcmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2UgNA0KQ0gt ODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0 MS0xLTcyNC04NTc4ICBodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGE= ------=_NextPart_000_006E_01C43A65.984AE6D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHRleHQ9IzAwMDAwMCBiZ0NvbG9yPSNmZmZm ZmY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+VGhhdCdzIG9rIHRv IG1lLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+V2VpbWluZzwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0i UEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsg Qk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05U OiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiAN CiAgPEEgdGl0bGU9aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgaHJlZj0ibWFpbHRv Omhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20iPktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9C PiA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gDQogIGhyZWY9Im1haWx0bzpyaGFAenVyaWNo LmlibS5jb20iPlJvYmVydCBIYWFzPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9aGFkaUB6bnl4LmNvbSANCiAg aHJlZj0ibWFpbHRvOmhhZGlAem55eC5jb20iPmhhZGlAem55eC5jb208L0E+IDsgPEEgDQogIHRp dGxlPWZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90 b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBTYXR1cmRh eSwgTWF5IDE1LCAyMDA0IDU6NDQgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gTmV4 dCANCiAgQ29uZmVyZW5jZSBDYWxsIG9uIE1vbmRheSA1IFBNIFBTVD88L0RJVj4NCiAgPERJVj48 QlI+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9OTE4MzI0MTIxLTE0MDUyMDA0PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+V2UgDQogIGNhbiZuYnNwO2dvIHdpdGggNyBh bSBQU1Qgb24gTW9uZGF5LiAoMTAgcG0gUFNUIHdpbGwgYmUgMSBhbSBmb3IgSmFtYWwgDQogIDop KTwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9OTE4MzI0MTIxLTE0MDUy MDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQ QU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9OTE4MzI0MTIxLTE0MDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPldlaW1pbmcsIEF2cmkgaG9w ZSB0aGlzIHdpbGwgd29yayBmb3IgeW91IGd1eXMgPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxC TE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWPjwv RElWPg0KICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9 bHRyIGFsaWduPWxlZnQ+PEZPTlQgDQogICAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBSb2JlcnQgSGFhcyANCiAgICBbbWFpbHRv OnJoYUB6dXJpY2guaWJtLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBGcmlkYXksIE1heSAxNCwgMjAw NCAyOjM1IA0KICAgIFBNPEJSPjxCPlRvOjwvQj4gS2hvc3JhdmksIEhvcm11emQgTTxCUj48Qj5D Yzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5oYWRpQHpueXguY29t PC9BPjsgPEEgDQogICAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9y Y2VzLXByb3RvY29sQGlldGYub3JnPC9BPjxCUj48Qj5TdWJqZWN0OjwvQj4gDQogICAgUmU6IFtG b3JjZXMtcHJvdG9jb2xdIE5leHQgQ29uZmVyZW5jZSBDYWxsIG9uIE1vbmRheSA1IFBNIA0KICAg IFBTVD88QlI+PEJSPjwvRk9OVD48L0RJVj5BY3R1YWxseSB0aGlzIHRpbWUgaXQgaXMgbm90IHZl cnkgY29udmVuaWVudCBmb3IgbWUgDQogICAgYXMgSSB3aWxsIGJlIGluIFp1cmljaCwgYW5kIHRo YXQgd2lsbCBiZSAyIEFNIC4uLiA8QlI+PEJSPlRoZSBvbmx5IHR3byANCiAgICBwb3NzaWJsZSBz Y2hlZHVsZXMmbmJzcDsgYmV0d2VlbiBhcmU6PEJSPjxCUj5QU1QgMTAgcG08QlI+WnVyaWNoIDcg DQogICAgYW08QlI+Q2hpbmEgMSBwbSA8QlI+KHByb2JhYmx5IG5vdCBPSyBmb3IgdGhlIEVhc3Qg Q29hc3QgaWYgYW55b25lIGpvaW5zIA0KICAgIGZyb20gdGhlcmUpLjxCUj48QlI+b3I8QlI+PEJS PlBTVCA3IGFtPEJSPlp1cmljaCA0IHBtPEJSPkNoaW5hIDEwIA0KICAgIHBtPEJSPjxCUj48QlI+ VGhlIGdvb2QgdGhpbmcgYWJvdXQgc3VjaCBlYXJseS9sYXRlIGNhbGxzIGlzIHRoYXQgaXQgc2hv dWxkIA0KICAgIG5vdCBpbnRlcmZlcmUgd2l0aCBvdGhlciBtZWV0aW5ncyAuLi4gSSBwZXJzb25h bGx5IGRvbid0IG1pbmQgdGhlIGxhdGUgY2FsbHMgDQogICAgYXQgMTAgcG0uIFRoZSB3aG9sZSBv ZiBuZXh0IHdlZWsgaXMgT0sgd2l0aCANCiAgICBtZS48QlI+PEJSPi1Sb2JlcnQ8QlI+PEJSPkto b3NyYXZpLCBIb3JtdXpkIE0gd3JvdGU6PEJSPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIGNpdGU9 bWlkNDY4RjNGREEyOEFBODc0MjlBRDgwNzk5MkUyMkQwN0UwMTA4RDUwMUBvcnNtc3g0MDguamYu aW50ZWwuY29tIA0KICAgIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj5SYW0gY2FsbGVkIG1lIGFu ZCBzYWlkIGhlIGlzIGN1cnJlbnRseSB0cmF2ZWxpbmcgYnV0IG1pZ2h0IGJlIGFibGUgdG8NCm1h a2UgaXQgb24gTW9uZGF5Lg0KDQpXZWltaW5nLCBBdnJpLCBSb2JlcnQsIG90aGVycyBpcyBNb25k YXkgNSBQTSBQU1QgZmluZSBmb3IgYSBjYWxsID8/DQpQbHMgZG8gbGV0IG1lIGtub3cNCg0KDQpU aGFua3MNCkhvcm11emQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEphbWFs IEhhZGkgU2FsaW0gWzxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJtYWlsdG86 aGFkaUB6bnl4LmNvbSI+bWFpbHRvOmhhZGlAem55eC5jb208L0E+XSANClNlbnQ6IFRodXJzZGF5 LCBNYXkgMTMsIDIwMDQgNjoxOSBQTQ0KVG86IEtob3NyYXZpLCBIb3JtdXpkIE0NCkNjOiA8QSBj bGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2Nv bEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPg0KU3ViamVjdDogUmU6IFtG b3JjZXMtcHJvdG9jb2xdIE5leHQgQ29uZmVyZW5jZSBDYWxsIG9uIEZyaWRheSBvciBNb25kYXkN Cj8NCg0KDQpNb25kYXkgaXMgZmluZSB3aXRoIG1lLg0KDQpjaGVlcnMsDQpqYW1hbA0KDQpPbiBU aHUsIDIwMDQtMDUtMTMgYXQgMTk6MjMsIEtob3NyYXZpLCBIb3JtdXpkIE0gd3JvdGU6DQogIDwv UFJFPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPkhpIFRlYW0N Cg0KTGV0IG1lIGtub3cgaWYgeW91IHdvdWxkIGxpa2UgbWUgdG8gYXJyYW5nZSBhIGNhbGwgZm9y IEZyaWRheSBvcg0KICAgIDwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPk1v bmRheQ0KICA8L1BSRT4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0i Ij4obmV4dCB3ZWVrKSA/Pw0KDQpUaGFua3MNCkhvcm11emQNCg0KICAgIDwvUFJFPjwvQkxPQ0tR VU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPEEgY2xh c3M9bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIGhyZWY9Im1haWx0bzpGb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmciPkZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4NCjxBIGNsYXNzPW1vei10eHQt bGluay1mcmVldGV4dCBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mb3JjZXMtcHJvdG9jb2wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZvcmNlcy1wcm90b2NvbDwvQT4NCg0KDQogIDwvUFJFPjwvQkxPQ0tRVU9URT48QlI+PFBSRSBj bGFzcz1tb3otc2lnbmF0dXJlIGNvbHM9IjcyIj4tLSANClJvYmVydCBIYWFzDQpJQk0gWnVyaWNo IFJlc2VhcmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2UgNA0KQ0gtODgwMyBS/HNjaGxpa29u L1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICA8 QSBjbGFzcz1tb3otdHh0LWxpbmstZnJlZXRleHQgaHJlZj0iaHR0cDovL3d3dy56dXJpY2guaWJt LmNvbS9+cmhhIj5odHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGE8L0E+PC9QUkU+PC9CTE9D S1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_006E_01C43A65.984AE6D0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 22:44: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 WAA13767 for ; Fri, 14 May 2004 22:44: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 1BOp7I-0007ZM-CI for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:41:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F2faUk029088 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 22:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOp4n-00072T-0Q for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 22:39: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 WAA13424 for ; Fri, 14 May 2004 22:38: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 1BOp4j-0007es-NG for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOp3d-000794-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:37:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOp2k-0006fJ-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 22:36:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOp0w-00069h-9Y; Fri, 14 May 2004 22:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOouh-000521-Cw for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 22:28: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 WAA12978 for ; Fri, 14 May 2004 22:28: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 1BOoue-0002oN-0k for forces-protocol@ietf.org; Fri, 14 May 2004 22:28:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOotc-0002K8-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:27:29 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BOosW-0001PC-00 for forces-protocol@ietf.org; Fri, 14 May 2004 22:26:20 -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 i4F2Q90f004940 for ; Sat, 15 May 2004 02:26:09 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 i4F2QEJ0006548 for ; Sat, 15 May 2004 02:26: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 M2004051419254811618 for ; Fri, 14 May 2004 19:25:48 -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, 14 May 2004 19:25: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: [Forces-protocol] draft text - summary of volunteers Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D90A@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] draft text - summary of volunteers Thread-Index: AcQx3VLGid4GPZZ9T2i/8IuCQuX3+AAVufqAAfvMRxA= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 May 2004 02:25:48.0487 (UTC) FILETIME=[EF376D70:01C43A23] 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, 14 May 2004 19:25:48 -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 2 sections that we missed in the summary below, I think... HA & CEM/FEM Interface. These can be after #7 below. I already posted summary for HA, I will be happy to write it if Weiming can help out more with Protocol Messages. Jamal, could you post a short summary for CEM/FEM ? we can probably use it directly for that section. Thanks Hormuzd -----Original Message----- Based on the volunteers so far here is a list of draft sections and volunteers for writing it. Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang (Jamal/Robert) 6. Protocol Messages - Hormuzd, Weiming 7. Protocol Scenarios - Hormuzd, Ram 8. Security Considerations - Ram 9. References - Avri 10. Acknowledgments - All Appendix A. Implementation Notes - All? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 23:36: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 XAA15888 for ; Fri, 14 May 2004 23:36: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 1BOpvp-00085l-T9 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 23:33:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F3XnEN031106 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 23:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOpoR-0006uZ-Fv for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 23:26: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 XAA15482 for ; Fri, 14 May 2004 23:26: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 1BOpoP-0005kI-HF for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:26:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOpn7-0005Ez-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:24:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOplo-0004V9-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:23:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOpjU-0005rl-Cs; Fri, 14 May 2004 23:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOpbs-0004g3-Ng for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 23:13: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 XAA14851 for ; Fri, 14 May 2004 23:13: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 1BOpbq-0007jO-0b for forces-protocol@ietf.org; Fri, 14 May 2004 23:13:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOpZr-0006kw-00 for forces-protocol@ietf.org; Fri, 14 May 2004 23:11:08 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOpXW-000600-00 for forces-protocol@ietf.org; Fri, 14 May 2004 23:08:43 -0400 Received: from wwm1 (unverified [219.82.175.137]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 15 May 2004 11:21:28 +0800 Message-ID: <00e501c43a29$585ee260$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E0108D8FE@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Event attributes 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, 15 May 2004 11:04: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=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi Weiming, All -----Original Message----- Couple of other questions... What does Event 'Config' msg mean ? What direction is this msg CE-FE ?? I am a little confused about this. [Weiming] I actually have mentioned this a little in the last post. My original thought was some events may need to setup some parameters (may be called Event attributes) before they can act. E.g., the HB event, it may be told the time interval to send the HB signals before it can actually be used, therefore, the Event config op is used to set up the time interval for the HB. The direction is surely be from CE->FE. Of course, this event attributes can also be configured by Config msg, owing to the same reason for Sub/Unsub ops, we may also put it in Event msg. We may need to discuss it more on which is better? [/Weiming] I see what you mean now. The question I would ask is, do we really need configuration of event attributes ? and if so at what time ? In our current implementation, we do setup of HB interval at Join or Association setup time before we actually start sending HBs. Most protocols I know either have this as a default value or do this at start-up time. Changing this in the middle can make the implementation tricky. Do you guys do this currently ? Also, are there any other Event attributes that one might want to configure ? I cannot think of any right now. [WeimingRe] I don't quite agree to have the HB interval set at the association time, because firstly I think this parameter is not important enough that should be treated during the association time, secondly, to put it in association msg also means this parmater is static, and can not be changed, which I think reduce the flexibility. I'm not very sure the harm (tricky) you mentioned for such change, could you explain more? Once we answer the basic questions, we can decide if this should be part of Event or Config or some other msg. [WeimingRe] Actually I'm not sticky to 'Event config', but I think we may need to have a careful check of at least FE model to see if such config is needed. Another way is just to leave this aside currently, and later if we think it is needed I think it is easy to be added, do you agree? Thanks Hormuzd Thanks, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 14 23:57: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 XAA16744 for ; Fri, 14 May 2004 23:57: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 1BOqHg-00042s-NA for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 23:56:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F3uOW4015548 for forces-protocol-archive@odin.ietf.org; Fri, 14 May 2004 23:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOqGh-0003hs-DZ for forces-protocol-web-archive@optimus.ietf.org; Fri, 14 May 2004 23:55: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 XAA16627 for ; Fri, 14 May 2004 23:55: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 1BOqGd-0001bz-US for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:55:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOqDE-0000Js-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:51:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOqAB-00075z-00 for forces-protocol-web-archive@ietf.org; Fri, 14 May 2004 23:48:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOq8e-0002Bs-2O; Fri, 14 May 2004 23:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOq0U-0000oK-Lo for forces-protocol@optimus.ietf.org; Fri, 14 May 2004 23: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 XAA15993 for ; Fri, 14 May 2004 23:38:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOq0R-0003OZ-Fl for forces-protocol@ietf.org; Fri, 14 May 2004 23:38:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOpyZ-0002dJ-00 for forces-protocol@ietf.org; Fri, 14 May 2004 23:36:41 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOpwi-0001Js-00 for forces-protocol@ietf.org; Fri, 14 May 2004 23:34:45 -0400 Received: from wwm1 (unverified [219.82.175.137]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 15 May 2004 11:46:39 +0800 Message-ID: <00f301c43a2c$dd14b3b0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E0108D8FC@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] HB msgs ? 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, 15 May 2004 11:29:36 +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, Jamal, and all, ----- Original Message ----- From: "Khosravi, Hormuzd M" Jamal, I agree with you. However, Weiming (Robert ?) have different views on this. How do we resolve this ? I don't want us to be stuck on this. [Weiming] One more thing we should note is, we have totally only arround 10 message types for our protocol, to have another 2 to 4 msgs specifically for HB looks really biased and makes it more or less ugly in the appearance of our protocol. I even more prefer to the scheme to treat HB as an LFB (I remember Jamal mentioned this), than to have separate msgs for them. [/Weiming] I guess the key question that I would ask is if we want Event msg to symbolize asynchronous events or we want to mix the semantics with synchronous msgs as well ? I think keeping the 2 separate is cleaner, but I am open to other views as well. [Weiming] I don't think we may need to distinguish semantically the syn. and asyn. msgs in our protocol, because they have no principal difference in our scope. We can say an event notification is asyncronous, but we can also say any query or config from CE to FE is also asyncronous. Actually I just think it makes little sense to distinguish them. Avri, could you share your opinion on this ? Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com] Hormuzd, Strange but we raised the same questions asynchronously ;-> It is semantically cleaner to see HB as synchronous as opposed to async - which is closely mapped to events. So it may make sense to have them as separate. The subscribe unsucribe is very valuable to have even if the messages are separate. 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 Sat May 15 05:53:39 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 FAA13810 for ; Sat, 15 May 2004 05:53: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 1BOvqR-0004hf-HU for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 05:52:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F9qd3u018079 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 05:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOvnu-0004Ia-C2 for forces-protocol-web-archive@optimus.ietf.org; Sat, 15 May 2004 05:50: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 FAA13723 for ; Sat, 15 May 2004 05:49: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 1BOvnq-0007jL-Nm for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:49:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOvmq-0007HK-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:48:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOvmG-0006q4-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:48:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOvZN-0002ar-DG; Sat, 15 May 2004 05: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 1BOvYE-0002T8-RE for forces-protocol@optimus.ietf.org; Sat, 15 May 2004 05:33: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 FAA13248 for ; Sat, 15 May 2004 05:33: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 1BOvYB-0000Uj-DA for forces-protocol@ietf.org; Sat, 15 May 2004 05:33:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOvXB-00002O-00 for forces-protocol@ietf.org; Sat, 15 May 2004 05:32:46 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOvW9-0006Vz-00 for forces-protocol@ietf.org; Sat, 15 May 2004 05:31:42 -0400 Received: from wwm1 (unverified [219.82.175.137]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 15 May 2004 17:42:50 +0800 Message-ID: <013d01c43a5e$9ead4970$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E0108D907@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] T in TLV ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01C43AA1.A9F4B9B0" 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, 15 May 2004 17:25:48 +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_013A_01C43AA1.A9F4B9B0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIGFsbCwNCg0KSSdtIG9rIHRvIGhhdmUgVCB3aXRoIGdsb2JhbCBtZWFuaW5nLCB0 aG91Z2ggSSB0aGluayBpdCBhY3R1YWxseSBtYWtlIGxpdHRsZSBzZW5zZSwgYmVjYXVzZSB0aGUg bXNnIHR5cGUgaGFzIHF1aXRlIGxpbWl0ZWQgdGhlIGdsb2JhbCB1c2Ugb2YgdGhlIFRMVnMuIEFj dHVhbGx5IHRpbGwgbm93LCBJIHN0aWxsIGhhdmUgbm90IG5vdGljZWQgb25lIFRMViB0aGF0IGNh biBiZSB1c2VkIGFjcm9zcyBkaWZmZXJlbnQgbXNncy4gT25lIGFkdmFudGFnZSBmb3IgbG9jYWwg VCBpcyB0aGF0IGl0IG1heSBzdXBwbHkgbW9yZSBzcGFjZSwgYnV0IGFjdHVhbGx5IEkgdGhpbmsg Y3VycmVudGx5IHdlIGFyZSBub3Qgc2hvcnQgb2YgdGhlIHNwYWNlLiANCg0KQXMgYSBzdW1tYXJ5 LCAgbXkgb3BpbmlvbiBpcyBib3RoIGFyZSBvayB0byBtZS4NCg0KQ2hlZXJzLA0KV2VpbWluZw0K DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6 ZCBNIA0KICBUbzogZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBTZW50OiBTYXR1cmRheSwg TWF5IDE1LCAyMDA0IDEwOjA5IEFNDQogIFN1YmplY3Q6IFtGb3JjZXMtcHJvdG9jb2xdIFQgaW4g VExWID8NCg0KDQogIEhpIFRlYW0sDQoNCiAgT25lIHF1ZXN0aW9uIHRoYXQgSmFtYWwgcmFpc2Vk LCBkbyB3ZSB3YW50IHRvIGhhdmUgZ2xvYmFsIHNjb3BlIGZvciBUIGluIHRoZSBUTFYgYWNyb3Nz IGFsbCBtZXNzYWdlcyA/DQogIGkuZS4gVHlwZSAweDEgbWVhbnMgc29tZXRoaW5nIGZvciBBc3Nv Y2lhdGlvbiBTZXR1cCBtc2cgYW5kIFR5cGUgMHgzMiBtZWFucyBzb21ldGhpbmcgZm9yIENvbmZp ZyBtc2cuDQoNCiAgVGhlIG90aGVyIG9wdGlvbiBpcyBsb2NhbCBzY29wZSBpLmUuIFR5cGUgMHgx IG1lYW5zIHNvbWV0aGluZyBmb3IgQXNzb2NpYXRpb24gU2V0dXAgbXNnIGFuZCANCiAgVHlwZSAw eDEgbWVhbnMgc29tZXRoaW5nIGVsc2UgaW4gQ29uZmlnIG1zZy4NCg0KICBJIGFncmVlIHdpdGgg SmFtYWwgdGhhdCB1bmlmb3JtIHNlbWFudGljcyBhbmQgZ2xvYmFsIHNjb3BlIHdvdWxkIGJlIGNs ZWFuZXIsIA0KICBob3dldmVyIGxldCB1cyBrbm93IHdoYXQgeW91IGFsbCB0aGluayA/Pw0KDQoN CiAgVGhhbmtzDQogIEhvcm11emQNCg== ------=_NextPart_000_013A_01C43AA1.A9F4B9B0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaSBhbGwsPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5J J20gb2sgdG8gaGF2ZSBUIHdpdGggZ2xvYmFsIG1lYW5pbmcsIHRob3VnaCBJIHRoaW5rIA0KaXQg YWN0dWFsbHkgbWFrZSBsaXR0bGUgc2Vuc2UsJm5ic3A7YmVjYXVzZSB0aGUgbXNnIHR5cGUgaGFz IHF1aXRlIGxpbWl0ZWQgdGhlIA0KZ2xvYmFsIHVzZSBvZiB0aGUgVExWcy4gQWN0dWFsbHkgdGls bCBub3csIEkgc3RpbGwgaGF2ZSBub3Qgbm90aWNlZCBvbmUgVExWIHRoYXQgDQpjYW4gYmUgdXNl ZCBhY3Jvc3MgZGlmZmVyZW50IG1zZ3MuIE9uZSBhZHZhbnRhZ2UgZm9yIGxvY2FsIFQmbmJzcDtp cyB0aGF0IGl0IG1heSANCnN1cHBseSBtb3JlIHNwYWNlLCBidXQgYWN0dWFsbHkgSSB0aGluayBj dXJyZW50bHkgd2UgYXJlIG5vdCBzaG9ydCBvZiB0aGUgc3BhY2UuIA0KPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5BcyBhIHN1bW1hcnks ICZuYnNwO215IG9waW5pb24gaXMgYm90aCBhcmUgb2sgdG8gDQptZS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkNoZWVycyw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+V2VpbWluZzwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+ DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElO Ry1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBz b2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl NGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZy b206PC9CPiANCiAgPEEgdGl0bGU9aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgaHJl Zj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20iPktob3NyYXZpLCBIb3JtdXpk IE08L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+ PEI+VG86PC9CPiA8QSB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1h aWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwv QT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5T ZW50OjwvQj4gU2F0dXJkYXksIE1heSAxNSwgMjAwNCAxMDowOSBBTTwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFtGb3JjZXMt cHJvdG9jb2xdIFQgaW4gVExWID88L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwv Rk9OVD48QlI+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIA0KICBUZWFtLDwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQog IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3 NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5PbmUgcXVlc3Rpb24gdGhh dCANCiAgSmFtYWwgcmFpc2VkLCBkbyB3ZSB3YW50IHRvIGhhdmUmbmJzcDtnbG9iYWwmbmJzcDtz Y29wZSBmb3IgVCBpbiB0aGUgVExWIA0KICBhY3Jvc3MgYWxsIG1lc3NhZ2VzID88L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj5pLmUuIFR5cGUmbmJzcDsweDEgDQogIG1lYW5zIHNvbWV0aGluZyBm b3IgQXNzb2NpYXRpb24gU2V0dXAgbXNnIGFuZCBUeXBlIDB4MzIgbWVhbnMgc29tZXRoaW5nIGZv ciANCiAgQ29uZmlnIG1zZy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNz PTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0xNzQzNTAzMDItMTUwNTIwMDQ+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGhlIG90aGVyIG9wdGlvbiANCiAgaXMgbG9jYWwgc2Nv cGUgaS5lLiBUeXBlIDB4MSBtZWFucyBzb21ldGhpbmcgZm9yIEFzc29jaWF0aW9uIFNldHVwIG1z ZyBhbmQgDQogIDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUw MzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlR5cGUgMHgxIG1lYW5zIA0KICBz b21ldGhpbmcgZWxzZSBpbiBDb25maWcgbXNnLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+ PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMw Mi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JIGFncmVlIHdpdGggSmFtYWwgDQog IHRoYXQgdW5pZm9ybSBzZW1hbnRpY3MgYW5kIGdsb2JhbCBzY29wZSB3b3VsZCBiZSBjbGVhbmVy LCA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1 MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5ob3dldmVyIGxldCB1cyANCiAga25vdyB3aGF0 IHlvdSBhbGwgdGhpbmsgPz88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNz PTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0xNzQzNTAzMDItMTUwNTIwMDQ+ PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQog IHNpemU9Mj5UaGFua3M8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3 NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+SG9ybXV6ZDwvRk9O VD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjwvQkxP Q0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_013A_01C43AA1.A9F4B9B0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat May 15 05:56:48 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 FAA13995 for ; Sat, 15 May 2004 05:56: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 1BOvtP-00053Q-03 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 05:55:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F9tg72019423 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 05:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOvs1-0004vw-Tw for forces-protocol-web-archive@optimus.ietf.org; Sat, 15 May 2004 05: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 FAA13861 for ; Sat, 15 May 2004 05:54: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 1BOvry-0001my-8l for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:54:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOvr5-0001JP-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:53:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOvqD-0000qK-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 05:52:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOvmw-0004AD-Hg; Sat, 15 May 2004 05:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOvf4-0003Ej-J6 for forces-protocol@optimus.ietf.org; Sat, 15 May 2004 05:40: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 FAA13485 for ; Sat, 15 May 2004 05:40: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 1BOvf1-0003ns-60 for forces-protocol@ietf.org; Sat, 15 May 2004 05:40:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOve5-0003NO-00 for forces-protocol@ietf.org; Sat, 15 May 2004 05:39:54 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BOvdQ-0002wt-00 for forces-protocol@ietf.org; Sat, 15 May 2004 05:39:13 -0400 Received: from wwm1 (unverified [219.82.175.137]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Sat, 15 May 2004 17:52:06 +0800 Message-ID: <014b01c43a5f$e98072f0$020aa8c0@wwm1> From: "Weiming Wang" To: Subject: Fw: [Forces-protocol] T in TLV ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0148_01C43AA2.F2FDF8A0" 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, 15 May 2004 17:35:00 +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_0148_01C43AA2.F2FDF8A0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhvcm11emQsDQoNCk9uZSBtb3JlIHRoaW5nIEkgaGF2ZSB0byBtZW50aW9uIGlzLCB0 aGUgc2NoZW1lIHlvdSB1c2VkIGluIHRoZSBhZGQgcm91dGUgZXhhbXBsZSBmb3IgVCAoVD0gTEZC YXR0ciAvIEZFYXR0cmkgKSB3aWxsIHJlc3VsdCBpbiBsb2NhbCBtZWFuaW5nLCB3aGlsZSB0aGUg cGxhbiBJIHByb3Bvc2VkICggVD1BZGQvRGVsL1VwZGF0ZS4uLisgTEZCYXR0ci9GRWF0dHJpICkg YWN0dWFsbHkgY2FuIGhhdmUgZ2xvYmFsIG1lYW5pbmcuIDogLSkNCg0KQ2hlZXJzLA0KV2VpbWlu Zw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogV2VpbWluZyBXYW5nIA0K DQoNCkhpIGFsbCwNCg0KSSdtIG9rIHRvIGhhdmUgVCB3aXRoIGdsb2JhbCBtZWFuaW5nLCB0aG91 Z2ggSSB0aGluayBpdCBhY3R1YWxseSBtYWtlIGxpdHRsZSBzZW5zZSwgYmVjYXVzZSB0aGUgbXNn IHR5cGUgaGFzIHF1aXRlIGxpbWl0ZWQgdGhlIGdsb2JhbCB1c2Ugb2YgdGhlIFRMVnMuIEFjdHVh bGx5IHRpbGwgbm93LCBJIHN0aWxsIGhhdmUgbm90IG5vdGljZWQgb25lIFRMViB0aGF0IGNhbiBi ZSB1c2VkIGFjcm9zcyBkaWZmZXJlbnQgbXNncy4gT25lIGFkdmFudGFnZSBmb3IgbG9jYWwgVCBp cyB0aGF0IGl0IG1heSBzdXBwbHkgbW9yZSBzcGFjZSwgYnV0IGFjdHVhbGx5IEkgdGhpbmsgY3Vy cmVudGx5IHdlIGFyZSBub3Qgc2hvcnQgb2YgdGhlIHNwYWNlLiANCg0KQXMgYSBzdW1tYXJ5LCAg bXkgb3BpbmlvbiBpcyBib3RoIGFyZSBvayB0byBtZS4NCg0KQ2hlZXJzLA0KV2VpbWluZw0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBN IA0KICBUbzogZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBTZW50OiBTYXR1cmRheSwgTWF5 IDE1LCAyMDA0IDEwOjA5IEFNDQogIFN1YmplY3Q6IFtGb3JjZXMtcHJvdG9jb2xdIFQgaW4gVExW ID8NCg0KDQogIEhpIFRlYW0sDQoNCiAgT25lIHF1ZXN0aW9uIHRoYXQgSmFtYWwgcmFpc2VkLCBk byB3ZSB3YW50IHRvIGhhdmUgZ2xvYmFsIHNjb3BlIGZvciBUIGluIHRoZSBUTFYgYWNyb3NzIGFs bCBtZXNzYWdlcyA/DQogIGkuZS4gVHlwZSAweDEgbWVhbnMgc29tZXRoaW5nIGZvciBBc3NvY2lh dGlvbiBTZXR1cCBtc2cgYW5kIFR5cGUgMHgzMiBtZWFucyBzb21ldGhpbmcgZm9yIENvbmZpZyBt c2cuDQoNCiAgVGhlIG90aGVyIG9wdGlvbiBpcyBsb2NhbCBzY29wZSBpLmUuIFR5cGUgMHgxIG1l YW5zIHNvbWV0aGluZyBmb3IgQXNzb2NpYXRpb24gU2V0dXAgbXNnIGFuZCANCiAgVHlwZSAweDEg bWVhbnMgc29tZXRoaW5nIGVsc2UgaW4gQ29uZmlnIG1zZy4NCg0KICBJIGFncmVlIHdpdGggSmFt YWwgdGhhdCB1bmlmb3JtIHNlbWFudGljcyBhbmQgZ2xvYmFsIHNjb3BlIHdvdWxkIGJlIGNsZWFu ZXIsIA0KICBob3dldmVyIGxldCB1cyBrbm93IHdoYXQgeW91IGFsbCB0aGluayA/Pw0KDQoNCiAg VGhhbmtzDQogIEhvcm11emQNCg== ------=_NextPart_000_0148_01C43AA2.F2FDF8A0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5Ib3JtdXpkLDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+T25lIG1vcmUgdGhpbmcg SSBoYXZlIHRvIG1lbnRpb24gaXMsJm5ic3A7dGhlIHNjaGVtZSANCnlvdSB1c2VkIGluIHRoZSBh ZGQgcm91dGUgZXhhbXBsZSBmb3IgVCAoVD0gTEZCYXR0ciAvIEZFYXR0cmkgKSB3aWxsIHJlc3Vs dCBpbiANCmxvY2FsIG1lYW5pbmcsIHdoaWxlIHRoZSBwbGFuIEkgcHJvcG9zZWQgKCBUPUFkZC9E ZWwvVXBkYXRlLi4uKyBMRkJhdHRyL0ZFYXR0cmkgDQopIGFjdHVhbGx5IGNhbiBoYXZlIGdsb2Jh bCBtZWFuaW5nLiA6IC0pPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj5DaGVlcnMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQo8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+ PEI+RnJvbTo8L0I+IDxBIA0KdGl0bGU9d213YW5nQG1haWwuaHppYy5lZHUuY24gaHJlZj0ibWFp bHRvOndtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIj5XZWltaW5nIA0KV2FuZzwvQT4gPC9ESVY+PC9E SVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mj5IaSBhbGwsPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5JJ20gb2sgdG8gaGF2ZSBUIHdpdGggZ2xvYmFs IG1lYW5pbmcsIHRob3VnaCBJIHRoaW5rIA0KaXQgYWN0dWFsbHkgbWFrZSBsaXR0bGUgc2Vuc2Us Jm5ic3A7YmVjYXVzZSB0aGUgbXNnIHR5cGUgaGFzIHF1aXRlIGxpbWl0ZWQgdGhlIA0KZ2xvYmFs IHVzZSBvZiB0aGUgVExWcy4gQWN0dWFsbHkgdGlsbCBub3csIEkgc3RpbGwgaGF2ZSBub3Qgbm90 aWNlZCBvbmUgVExWIHRoYXQgDQpjYW4gYmUgdXNlZCBhY3Jvc3MgZGlmZmVyZW50IG1zZ3MuIE9u ZSBhZHZhbnRhZ2UgZm9yIGxvY2FsIFQmbmJzcDtpcyB0aGF0IGl0IG1heSANCnN1cHBseSBtb3Jl IHNwYWNlLCBidXQgYWN0dWFsbHkgSSB0aGluayBjdXJyZW50bHkgd2UgYXJlIG5vdCBzaG9ydCBv ZiB0aGUgc3BhY2UuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj5BcyBhIHN1bW1hcnksICZuYnNwO215IG9waW5pb24gaXMgYm90aCBh cmUgb2sgdG8gDQptZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzsgc2l6ZT0yPkNoZWVycyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+V2VpbWluZzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5 bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1 cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0K ICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9aG9ybXV6 ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2 aUBpbnRlbC5jb20iPktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1mb3JjZXMt cHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gU2F0dXJkYXksIE1heSAxNSwg MjAwNCAxMDowOSBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OyI+PEI+U3ViamVjdDo8L0I+IFtGb3JjZXMtcHJvdG9jb2xdIFQgaW4gVExWID88L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PFNQ QU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIA0K ICBUZWFtLDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAy LTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5PbmUgcXVlc3Rpb24gdGhhdCANCiAgSmFtYWwgcmFpc2VkLCBkbyB3ZSB3 YW50IHRvIGhhdmUmbmJzcDtnbG9iYWwmbmJzcDtzY29wZSBmb3IgVCBpbiB0aGUgVExWIA0KICBh Y3Jvc3MgYWxsIG1lc3NhZ2VzID88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNs YXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5pLmUuIFR5cGUm bmJzcDsweDEgDQogIG1lYW5zIHNvbWV0aGluZyBmb3IgQXNzb2NpYXRpb24gU2V0dXAgbXNnIGFu ZCBUeXBlIDB4MzIgbWVhbnMgc29tZXRoaW5nIGZvciANCiAgQ29uZmlnIG1zZy48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBm YWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48 U1BBTiBjbGFzcz0xNzQzNTAzMDItMTUwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGhl IG90aGVyIG9wdGlvbiANCiAgaXMgbG9jYWwgc2NvcGUgaS5lLiBUeXBlIDB4MSBtZWFucyBzb21l dGhpbmcgZm9yIEFzc29jaWF0aW9uIFNldHVwIG1zZyBhbmQgDQogIDwvRk9OVD48L1NQQU4+PC9E SVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPlR5cGUgMHgxIG1lYW5zIA0KICBzb21ldGhpbmcgZWxzZSBpbiBDb25maWcgbXNn LjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUy MDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5JIGFncmVlIHdpdGggSmFtYWwgDQogIHRoYXQgdW5pZm9ybSBzZW1hbnRpY3MgYW5k IGdsb2JhbCBzY29wZSB3b3VsZCBiZSBjbGVhbmVyLCA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8 RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5ob3dldmVyIGxldCB1cyANCiAga25vdyB3aGF0IHlvdSBhbGwgdGhpbmsgPz88L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBm YWNlPUFyaWFsIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48 U1BBTiBjbGFzcz0xNzQzNTAzMDItMTUwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MTc0MzUwMzAy LTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5UaGFua3M8L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTE3NDM1MDMwMi0xNTA1MjAwND48Rk9OVCBmYWNl PUFyaWFsIA0KICBzaXplPTI+SG9ybXV6ZDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQ QU4gY2xhc3M9MTc0MzUwMzAyLTE1MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0148_01C43AA2.F2FDF8A0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat May 15 06:16: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 GAA14811 for ; Sat, 15 May 2004 06:16: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 1BOwBI-00081N-Gj for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 06:14:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FAECbp030829 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 06:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOwB3-0007sr-At for forces-protocol-web-archive@optimus.ietf.org; Sat, 15 May 2004 06:13: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 GAA14715 for ; Sat, 15 May 2004 06:13: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 1BOwAz-0002om-Jx for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 06:13:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOw9y-0002NG-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 06:12:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOw90-0001wK-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 06:11:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOw7I-0006lN-Gk; Sat, 15 May 2004 06:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOw1M-0005tY-Ta for forces-protocol@optimus.ietf.org; Sat, 15 May 2004 06:03: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 GAA14389 for ; Sat, 15 May 2004 06:03:53 -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 1BOw1J-0006Gf-7e for forces-protocol@ietf.org; Sat, 15 May 2004 06:03:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOw0b-0005ql-00 for forces-protocol@ietf.org; Sat, 15 May 2004 06:03:10 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BOvzp-0005Od-00 for forces-protocol@ietf.org; Sat, 15 May 2004 06:02:21 -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 i4FA1Bep007329 for ; Sat, 15 May 2004 12:01:13 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D8FC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108D8FC@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] HB msgs ? 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, 15 May 2004 12:02:16 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have seen both situations, where people want to force acknowledgment of Event messages and where they don't and thus have resorted to use a config message options and flags that indicated whether, and which, event messages required acks. the messages themselves can also contains flags indicating whether an ack was required. I tend to think of the behavior of event messages as being special enough to require their own semantics and configuration options. Not sure this helps. a. On 15 maj 2004, at 03.34, Khosravi, Hormuzd M wrote: > Jamal, > > I agree with you. However, Weiming (Robert ?) have different views on > this. > How do we resolve this ? I don't want us to be stuck on this. > > I guess the key question that I would ask is if we want Event msg to > symbolize asynchronous events or we want to mix the semantics with > synchronous msgs as well ? I think keeping the 2 separate is cleaner, > but I am open to other views as well. > > Avri, could you share your opinion on this ? > > > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > Hormuzd, > Strange but we raised the same questions asynchronously ;-> > It is semantically cleaner to see HB as synchronous as opposed to > async - which is closely mapped to events. So it may make sense > to have them as separate. The subscribe unsucribe is very valuable to > have even if the messages are separate. > > 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 Sat May 15 08:02: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 IAA18210 for ; Sat, 15 May 2004 08:02: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 1BOxnt-0003Zp-Us for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 07:58:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FBw9co013745 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 07:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxnk-0003Tb-9m for forces-protocol-web-archive@optimus.ietf.org; Sat, 15 May 2004 07:58: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 HAA18090 for ; Sat, 15 May 2004 07:57: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 1BOxnj-0000vU-FV for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 07:57:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOxmp-0000Vu-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 07:57:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOxmN-00005u-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 07:56:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxjt-000344-Ln; Sat, 15 May 2004 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxhr-0002qp-75 for forces-protocol@optimus.ietf.org; Sat, 15 May 2004 07:51: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 HAA17966 for ; Sat, 15 May 2004 07:51:54 -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 1BOxhq-00069E-Cu for forces-protocol@ietf.org; Sat, 15 May 2004 07:51:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOxgr-0005jL-00 for forces-protocol@ietf.org; Sat, 15 May 2004 07:50:54 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BOxfn-0004yb-00 for forces-protocol@ietf.org; Sat, 15 May 2004 07:49:47 -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 i4FBmXep007450 for ; Sat, 15 May 2004 13:48:33 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D907@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108D907@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Subject: Re: [Forces-protocol] T in TLV ? To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) 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, 15 May 2004 13:49:40 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On 15 maj 2004, at 04.09, Khosravi, Hormuzd M wrote: > Hi Team, > =A0 > One question that Jamal raised, do we want to have=A0global=A0scope = for T=20 > in the TLV across all messages ? > i.e. Type=A00x1 means something for Association Setup msg and Type = 0x32=20 > means something for Config msg. > =A0 > The other option is local scope i.e. Type 0x1 means something for=20 > Association Setup msg and > Type 0x1 means something else in Config msg. > =A0 > I agree with Jamal that uniform semantics and global scope would be=20 > cleaner, > however let us know what you all think ?? I agree that having a single global T space of TLVs is preferable. I am not sure what you mean by uniform semantics. I think each TLV=20 should allowed to vary according to type, but would expect the the TL=20 and fields, and possible a status and flags field to be uniform. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sat May 15 08:04:19 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18252 for ; Sat, 15 May 2004 08:04: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 1BOxsF-0003xS-7g for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 08:02:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FC2dpq015207 for forces-protocol-archive@odin.ietf.org; Sat, 15 May 2004 08:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxpi-0003c3-Fx for forces-protocol-web-archive@optimus.ietf.org; Sat, 15 May 2004 08:00: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 IAA18133 for ; Sat, 15 May 2004 08:00: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 1BOxph-0001lo-Kn for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 08:00:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOxoh-0001Lb-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 07:59:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOxo5-0000w8-00 for forces-protocol-web-archive@ietf.org; Sat, 15 May 2004 07:58:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxnl-0003Tj-3x; Sat, 15 May 2004 07: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 1BOxmj-0003MV-Ra for forces-protocol@optimus.ietf.org; Sat, 15 May 2004 07:56: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 HAA18066 for ; Sat, 15 May 2004 07:56:56 -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 1BOxmi-0000Uq-PK for forces-protocol@ietf.org; Sat, 15 May 2004 07:56:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOxlj-00004x-00 for forces-protocol@ietf.org; Sat, 15 May 2004 07:55:56 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BOxkw-0007Sp-00 for forces-protocol@ietf.org; Sat, 15 May 2004 07:55:06 -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 i4FBruep007456 for ; Sat, 15 May 2004 13:53:57 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <007101c43a22$8f069990$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E0108D6D3@orsmsx408.jf.intel.com> <007101c43a22$8f069990$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) 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, 15 May 2004 13:55:03 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, At 7 am PST/16.00 CET on Monday (is that still the target?), I will be=20= a plane flying from one part of Sweden to another part of Sweden. a. On 15 maj 2004, at 04.15, Weiming Wang wrote: > That's ok to me. > =A0 > Weiming > ----- Original Message ----- > From: Khosravi, Hormuzd M > To: Robert Haas > Cc: hadi@znyx.com ; forces-protocol@ietf.org > Sent: Saturday, May 15, 2004 5:44 AM > Subject: RE: [Forces-protocol] Next Conference Call on Monday 5 PM = PST? > > We can=A0go with 7 am PST on Monday. (10 pm PST will be 1 am for Jamal=20= > :)) > =A0 > Weiming, Avri hope this will work for you guys ? > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, May 14, 2004 2:35 PM > To: Khosravi, Hormuzd M > Cc: hadi@znyx.com; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM = PST? > > Actually this time it is not very convenient for me as I will be in=20 > Zurich, and that will be 2 AM ... > > The only two possible schedules=A0 between are: > > PST 10 pm > Zurich 7 am > China 1 pm > (probably not OK for the East Coast if anyone joins from there). > > or > > PST 7 am > Zurich 4 pm > China 10 pm > > > The good thing about such early/late calls is that it should not=20 > interfere with other meetings ... I personally don't mind the late=20 > calls at 10 pm. The whole of next week is OK with me. > > -Robert > > Khosravi, Hormuzd M wrote: > > Ram called me and said he is currently traveling but might be able to > make it on Monday. > > Weiming, Avri, Robert, others is Monday 5 PM PST fine for a call ?? > Pls do let me know > > > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Thursday, May 13, 2004 6:19 PM > To: Khosravi, Hormuzd M > Cc: forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Next Conference Call on Friday or = Monday > ? > > > Monday is fine with me. > > cheers, > jamal > > On Thu, 2004-05-13 at 19:23, Khosravi, Hormuzd M wrote: > > Hi Team > > Let me know if you would like me to arrange a call for Friday or > > Monday > > (next week) ?? > > Thanks > Hormuzd > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > --=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 =20 > 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 Sun May 16 23:00: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 XAA08690 for ; Sun, 16 May 2004 23:00: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 1BPYHu-0006SK-PD for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 22:55:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H2tYuS024816 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 22:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYAR-0005mL-Bd for forces-protocol-web-archive@optimus.ietf.org; Sun, 16 May 2004 22:47: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 WAA08220 for ; Sun, 16 May 2004 22:47: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 1BPYAN-0004z9-UC for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:47:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPY9L-0004eC-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:46:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPY8X-0004LL-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:45:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPY5m-0005NX-A4; Sun, 16 May 2004 22:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPY1t-0004VU-8o for forces-protocol@optimus.ietf.org; Sun, 16 May 2004 22:39: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 WAA07820 for ; Sun, 16 May 2004 22:38: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 1BPY1p-00029W-OV for forces-protocol@ietf.org; Sun, 16 May 2004 22:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPY15-0001ob-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:38: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 1BPY02-0001Oh-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:37: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 i4H2bJK4009910; Mon, 17 May 2004 02:37:19 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 i4H2XLOO019712; Mon, 17 May 2004 02:33:54 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 M2004051619362717231 ; Sun, 16 May 2004 19:36:27 -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, 16 May 2004 19:36:27 -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] Next Conference Call on Tuesday 7 AM PST ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D9EB@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Next Conference Call on Tuesday 7 AM PST ? Thread-Index: AcQ6c+wO+imeG8KSQqCDheizIWcmsABQ6GgA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 17 May 2004 02:36:27.0911 (UTC) FILETIME=[C12B4970:01C43BB7] 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, 16 May 2004 19:36:27 -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 Ok, since we havent heard from Jamal either, lets keep this on Tuesday at 7 AM PST. Is that fine with everyone ?? Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Saturday, May 15, 2004 4:55 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? Hi, At 7 am PST/16.00 CET on Monday (is that still the target?), I will be=20 a plane flying from one part of Sweden to another part of Sweden. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 16 23:07: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 XAA09006 for ; Sun, 16 May 2004 23:07: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 1BPYMu-000711-U4 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:00:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H30iOp026960 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYJ1-0006Yh-Ce for forces-protocol-web-archive@optimus.ietf.org; Sun, 16 May 2004 22:56: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 WAA08562 for ; Sun, 16 May 2004 22: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 1BPYIx-0007gr-Vp for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:56:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYI7-0007OL-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:55:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPYHY-000755-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 22:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPY9c-0005lH-Bv; Sun, 16 May 2004 22:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPY6E-0005OV-5W for forces-protocol@optimus.ietf.org; Sun, 16 May 2004 22:43: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 WAA08012 for ; Sun, 16 May 2004 22:43: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 1BPY6A-0003gE-Pd for forces-protocol@ietf.org; Sun, 16 May 2004 22:43:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPY5B-0003N1-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:42:26 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPY4B-0002mp-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:41:24 -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 i4H2fdK4011873; Mon, 17 May 2004 02:41:39 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 i4H2c5OC021619; Mon, 17 May 2004 02:38:14 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 M2004051619404717625 ; Sun, 16 May 2004 19:40:47 -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, 16 May 2004 19:40: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] HB msgs ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D9F0@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] HB msgs ? Thread-Index: AcQ6ZQtE22Eohe0aTWOhtoAtWXTOZwBUvjow From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 17 May 2004 02:40:47.0376 (UTC) FILETIME=[5BD28100:01C43BB8] 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, 16 May 2004 19:40: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 Avri, This is helpful. So what would your preference be, have HBs are separate msgs or part of Event msgs ?? Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Sent: Saturday, May 15, 2004 3:02 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] HB msgs ? Hi, I have seen both situations, where people want to force acknowledgment=20 of Event messages and where they don't and thus have resorted to use a=20 config message options and flags that indicated whether, and which,=20 event messages required acks. the messages themselves can also contains=20 flags indicating whether an ack was required. I tend to think of the behavior of event messages as being special=20 enough to require their own semantics and configuration options. Not sure this helps. a. On 15 maj 2004, at 03.34, Khosravi, Hormuzd M wrote: > Jamal, > > I agree with you. However, Weiming (Robert ?) have different views on > this. > How do we resolve this ? I don't want us to be stuck on this. > > I guess the key question that I would ask is if we want Event msg to > symbolize asynchronous events or we want to mix the semantics with > synchronous msgs as well ? I think keeping the 2 separate is cleaner, > but I am open to other views as well. > > Avri, could you share your opinion on this ? > > > Thanks > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 16 23:09: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 XAA09056 for ; Sun, 16 May 2004 23:09: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 1BPYU3-00080u-Jw for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:08:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H387LI030784 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYSO-0007T8-VB for forces-protocol-web-archive@optimus.ietf.org; Sun, 16 May 2004 23:06: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 XAA08921 for ; Sun, 16 May 2004 23:06: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 1BPYSK-00025b-0l for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:06:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYOf-0001Qx-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:02:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPYMi-0000mc-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:00:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYIN-0006YP-Sa; Sun, 16 May 2004 22:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYD5-00060Y-3w for forces-protocol@optimus.ietf.org; Sun, 16 May 2004 22:50: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 WAA08353 for ; Sun, 16 May 2004 22:50: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 1BPYD1-0005so-Ki for forces-protocol@ietf.org; Sun, 16 May 2004 22:50:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYCB-0005bF-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:49:40 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPYBT-0005Eh-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:48:55 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4H2mkm6016400; Mon, 17 May 2004 02:48:46 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 i4H2lXuK029591; Mon, 17 May 2004 02:48: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 M2004051619481530239 ; Sun, 16 May 2004 19:48:15 -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, 16 May 2004 19:48:16 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43BB9.6714E948" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] T in TLV ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D9F7@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV ? Thread-Index: AcQ6YcK8qZqLTPCkTD2v/lyNFtiLeABV48CA From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 17 May 2004 02:48:16.0163 (UTC) FILETIME=[6751F730:01C43BB9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 16 May 2004 19:48:15 -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_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43BB9.6714E948 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiming, =20 Thanks for your prompt reply. This is helpful. =20 Regards Hormuzd =20 _____ =20 From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Sent: Saturday, May 15, 2004 2:26 AM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] T in TLV ? =20 Hi all, =20 I'm ok to have T with global meaning, though I think it actually make little sense, because the msg type has quite limited the global use of the TLVs. Actually till now, I still have not noticed one TLV that can be used across different msgs. One advantage for local T is that it may supply more space, but actually I think currently we are not short of the space.=20 =20 As a summary, my opinion is both are ok to me. =20 Cheers, Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M To: forces-protocol@ietf.org=20 Sent: Saturday, May 15, 2004 10:09 AM Subject: [Forces-protocol] T in TLV ? =20 Hi Team, =20 One question that Jamal raised, do we want to have global scope for T in the TLV across all messages ? i.e. Type 0x1 means something for Association Setup msg and Type 0x32 means something for Config msg. =20 The other option is local scope i.e. Type 0x1 means something for Association Setup msg and=20 Type 0x1 means something else in Config msg. =20 I agree with Jamal that uniform semantics and global scope would be cleaner,=20 however let us know what you all think ?? =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C43BB9.6714E948 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Weiming,

 

Thanks for your prompt reply. This = is helpful.

 

Regards

Hormuzd

 

From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On Behalf Of Weiming Wang
Sent: Saturday, May 15, = 2004 2:26 AM
To: = forces-protocol@ietf.org
Subject: Re: = [Forces-protocol] T in TLV ?

 

Hi all,

 

I'm ok to have T with global meaning, though I think = it actually make little sense, because the msg type has quite limited = the global use of the TLVs. Actually till now, I still have not noticed one = TLV that can be used across different msgs. One advantage for local = T is that it may supply more space, but actually I think currently we are not = short of the space.

 

As a summary,  my opinion is both are ok to = me.

 

Cheers,

Weiming

 

----- Original Message -----

Sent: = Saturday, May 15, 2004 10:09 AM

Subject: = [Forces-protocol] T in TLV ?

 

Hi Team,

 

One question that Jamal raised, do we want to have global scope for T in the TLV across all messages = ?

i.e. Type 0x1 means something for Association = Setup msg and Type 0x32 means something for Config msg.

 

The other option is local scope i.e. Type 0x1 means something for Association Setup msg and

Type 0x1 means something else in Config = msg.

 

I agree with Jamal that uniform semantics and global = scope would be cleaner,

however let us know what you all think = ??

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C43BB9.6714E948-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 16 23:21: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 XAA09666 for ; Sun, 16 May 2004 23:21: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 1BPYdg-0000dL-63 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H3I4ZO002431 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYYz-0000Ee-Np for forces-protocol-web-archive@optimus.ietf.org; Sun, 16 May 2004 23:13: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 XAA09232 for ; Sun, 16 May 2004 23:13: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 1BPYYx-0003JV-V7 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:13:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYVh-0002mG-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:09:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPYSx-00027p-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYMI-0006uS-EJ; Sun, 16 May 2004 23:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYHG-0006PB-RR for forces-protocol@optimus.ietf.org; Sun, 16 May 2004 22:54: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 WAA08475 for ; Sun, 16 May 2004 22:54: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 1BPYHD-00074A-7m for forces-protocol@ietf.org; Sun, 16 May 2004 22:54:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYG8-0006k0-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:53: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 1BPYFB-0006AS-00 for forces-protocol@ietf.org; Sun, 16 May 2004 22:52:45 -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 i4H2r5Jp024024; Mon, 17 May 2004 02:53:05 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 i4H2qItw031939; Mon, 17 May 2004 02:52: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 M2004051619521530576 ; Sun, 16 May 2004 19:52:15 -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, 16 May 2004 19:52: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] Event attributes Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D9F8@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Event attributes Thread-Index: AcQ6K/5D/x2q0PKzRRK+kvWkJaRbIwBjZXXw From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 17 May 2004 02:52:15.0182 (UTC) FILETIME=[F5C95EE0:01C43BB9] 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, 16 May 2004 19:52:14 -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----- [WeimingRe] I don't quite agree to have the HB interval set at the association time, because firstly I think this parameter is not important enough that should be treated during the association time, secondly, to put it in association msg also means this parmater is static, and can not be changed, which I think reduce the flexibility. I'm not very sure the harm (tricky) you mentioned for such change, could you explain more? [HK] I will have to get into implementation details here, but my second answer (below) might satisfy you for now :) Once we answer the basic questions, we can decide if this should be part of Event or Config or some other msg. [WeimingRe] Actually I'm not sticky to 'Event config', but I think we may need to have a careful check of at least FE model to see if such config is needed. Another way is just to leave this aside currently, and later if we think it is needed I think it is easy to be added, do you agree? [HK] Yes that sounds very reasonable. Lets leave it aside for now, we can add it later if need be. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 16 23:23: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 XAA09783 for ; Sun, 16 May 2004 23:23: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 1BPYg3-0000wK-IY for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:20:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H3KV9h003608 for forces-protocol-archive@odin.ietf.org; Sun, 16 May 2004 23:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYcS-0000U1-14 for forces-protocol-web-archive@optimus.ietf.org; Sun, 16 May 2004 23:16: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 XAA09447 for ; Sun, 16 May 2004 23:16: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 1BPYcQ-0004Qe-9j for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:16:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYbb-00046g-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:15:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPYaI-0003ZX-00 for forces-protocol-web-archive@ietf.org; Sun, 16 May 2004 23:14:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYV9-0008Fo-1S; Sun, 16 May 2004 23:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPYSK-0007T6-RV for forces-protocol@optimus.ietf.org; Sun, 16 May 2004 23:06: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 XAA08915 for ; Sun, 16 May 2004 23:06: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 1BPYSF-00025S-NC for forces-protocol@ietf.org; Sun, 16 May 2004 23:06:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPYOd-0001Qh-00 for forces-protocol@ietf.org; Sun, 16 May 2004 23:02:32 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPYMg-0000lq-00 for forces-protocol@ietf.org; Sun, 16 May 2004 23:00:30 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4H30Wn3027961; Mon, 17 May 2004 03:00:32 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 i4H30Wtc002883; Mon, 17 May 2004 03:00:32 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 M2004051619595731231 ; Sun, 16 May 2004 19:59:57 -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, 16 May 2004 19:59: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] HB msgs ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108D9FC@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] HB msgs ? Thread-Index: AcQ6L4MsAJCUT4yeSi6QDLT7vAFqzgBivslQ From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 17 May 2004 02:59:58.0076 (UTC) FILETIME=[09B163C0:01C43BBB] 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, 16 May 2004 19:59: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 Weiming, You make a good point. I was just thinking 2 msgs for HB, HB Resp/Ack...4 msgs will be a bit too much. Anyways I am not religious about this one, neither is Jamal, I think. We are just stating our preferences. Lets see what Avri prefers. I am fine with whatever the majority decides. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang [Weiming] One more thing we should note is, we have totally only arround 10 message types for our protocol, to have another 2 to 4 msgs specifically for HB looks really biased and makes it more or less ugly in the appearance of our protocol. I even more prefer to the scheme to treat HB as an LFB (I remember Jamal mentioned this), than to have separate msgs for them. [/Weiming] I guess the key question that I would ask is if we want Event msg to symbolize asynchronous events or we want to mix the semantics with synchronous msgs as well ? I think keeping the 2 separate is cleaner, but I am open to other views as well. [Weiming] I don't think we may need to distinguish semantically the syn. and asyn. msgs in our protocol, because they have no principal difference in our scope. We can say an event notification is asyncronous, but we can also say any query or config from CE to FE is also asyncronous. Actually I just think it makes little sense to distinguish them. Avri, could you share your opinion on this ? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 08:41:30 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 IAA18996 for ; Mon, 17 May 2004 08:41: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 1BPhIY-0005ci-24 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 08:32:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HCWobw021616 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 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 1BPh70-0003qx-DO for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:20: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 IAA18105 for ; Mon, 17 May 2004 08:20: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 1BPh6z-0001XT-CM for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:20:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPh5z-0001E9-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:19:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPh51-0000u4-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:18:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgyR-0002dz-8g; Mon, 17 May 2004 08:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgwL-0002Fz-4m for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 08: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 IAA17156 for ; Mon, 17 May 2004 08:09: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 1BPgwK-0005Sx-4L for forces-protocol@ietf.org; Mon, 17 May 2004 08:09:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgvL-00058Q-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:08:51 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BPguO-0004gJ-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:07:52 -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 i4HC6Lep010205 for ; Mon, 17 May 2004 14:06:21 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D9F0@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108D9F0@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] HB msgs ? 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, 17 May 2004 14:07:45 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 17 maj 2004, at 04.40, Khosravi, Hormuzd M wrote: > Avri, > > This is helpful. So what would your preference be, have HBs are > separate > msgs or part of Event msgs ?? I think my inclination is to keep them separate and minimalist - just the header with the heartbeat message number should do. They certainly don't need to be acked and the only configuration option might be the interval/frequency. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 08:41:46 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 IAA19013 for ; Mon, 17 May 2004 08:41: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 1BPhJs-0005sL-RN for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 08:34:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HCYCCW022579 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 08:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhC3-0004NO-EV for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:26: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 IAA18315 for ; Mon, 17 May 2004 08: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 1BPhC2-0003A2-BQ for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:26:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhB1-0002qB-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:25:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPhAA-0002W2-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh6A-0003iv-Se; Mon, 17 May 2004 08:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh1S-00031Y-Km for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 08:15: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 IAA17769 for ; Mon, 17 May 2004 08:15:09 -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 1BPh1R-0007O0-C5 for forces-protocol@ietf.org; Mon, 17 May 2004 08:15:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgzC-0006T7-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:12:50 -0400 Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx with esmtp (Exim 4.12) id 1BPgxH-0005cI-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:10:51 -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 i4HC9Pep010211 for ; Mon, 17 May 2004 14:09:25 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D9FC@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108D9FC@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3BCBA640-A7FB-11D8-8F60-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] HB msgs ? 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, 17 May 2004 14:10:48 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 17 maj 2004, at 04.59, Khosravi, Hormuzd M wrote: > I was just thinking 2 msgs for HB, HB > Resp/Ack... i am not sure I understand why a HB needs an ack as everyone should be sending them on a similar interval (though in some network environments, hopefully not synchronized) a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 08:54:23 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 IAA19769 for ; Mon, 17 May 2004 08:54: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 1BPhcd-00009O-EF for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 08:53:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HCrZQ6000573 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 08:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhYT-0008AZ-BV for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:49: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 IAA19418 for ; Mon, 17 May 2004 08:49: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 1BPhYR-0002dQ-Tu for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:49:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhWf-0001yt-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:47:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPhVM-0001bd-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 08:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhSX-0007JA-5P; Mon, 17 May 2004 08:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhPV-0006hV-Qt for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 08: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 IAA18976 for ; Mon, 17 May 2004 08:40: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 1BPhPU-0007S7-HY for forces-protocol@ietf.org; Mon, 17 May 2004 08:40:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhOg-00079R-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:39:11 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BPhNv-0006nK-00 for forces-protocol@ietf.org; Mon, 17 May 2004 08:38:23 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4HCbpGP052692; Mon, 17 May 2004 12:37:51 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 i4HCbotL270612; Mon, 17 May 2004 14:37:51 +0200 Received: from zurich.ibm.com (dhcp69-162.zurich.ibm.com [9.4.69.162]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA62196; Mon, 17 May 2004 14:37:48 +0200 Message-ID: <40A8B21D.3050405@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: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Next Conference Call on Tuesday 7 AM PST ? References: <468F3FDA28AA87429AD807992E22D07E0108D9EB@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D9EB@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 mtagate1.de.ibm.com id i4HCbpGP052692 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, 17 May 2004 14:37:49 +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 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Tuesday 7 am PST (4 pm Zurich time) is fine with me. I assume we should=20 reserve 2 hours. -Robert Khosravi, Hormuzd M wrote: >Ok, since we havent heard from Jamal either, lets keep this on Tuesday >at 7 AM PST. Is that fine with everyone ?? > >Thanks >Hormuzd > >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org >Sent: Saturday, May 15, 2004 4:55 AM >To: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? > >Hi, > >At 7 am PST/16.00 CET on Monday (is that still the target?), I will be=20 >a plane flying from one part of Sweden to another part of Sweden. >a. > > > >_______________________________________________ >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 Mon May 17 09:42: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 JAA21928 for ; Mon, 17 May 2004 09:42: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 1BPiCh-0005It-II for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 09:30:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HDUpHk020388 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 09:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi9a-0004pC-Gf for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 09:27: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 JAA21380 for ; Mon, 17 May 2004 09:27:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPi9Y-0007Vq-QU for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:27:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPi8B-00079e-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:26:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPi7F-0006om-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi2C-0003ve-3D; Mon, 17 May 2004 09:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhzW-0003V2-PQ for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 09:17: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 JAA20894 for ; Mon, 17 May 2004 09:17: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 1BPhzU-0004C2-V9 for forces-protocol@ietf.org; Mon, 17 May 2004 09:17:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhyP-0003rv-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:16: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 1BPhxZ-0003YE-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:15: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 2004051706192182:5840 ; Mon, 17 May 2004 06:19:21 -0700 Subject: Consistent body TLV? WAS( RE: [Forces-protocol] Add Route Example From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "Khosravi, Hormuzd M" Cc: forces-protocol@ietf.org, "Wang,Weiming" , Robert Haas In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D902@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E0108D902@orsmsx408.jf.intel.com> Organization: ZNYX Networks Message-Id: <1084799709.1098.3079.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 05/17/2004 06:19:22 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/17/2004 06:19:24 AM, Serialize complete at 05/17/2004 06:19: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: 17 May 2004 09:15:09 -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-05-14 at 22:01, Khosravi, Hormuzd M wrote: > [HK] Yes 16 bits might be insufficient for this. However, I could > combine LFB Type (16 bits, including version no), Operation (8 bits), > Flags (8 Bits) into a 32-bit field. Does that sound good ? Let me know >From your comments to Weiming i now understand the meaning of type. 16 bits is a little too much for that. So having it as: TYPE := ATTR_TYPE(4 bits max): VERSION (4 bits): OPERATION(8 bits) i think should suffice. 4 bits are overkill for ATTR_TYPE since you only have it belonging to either an FE or LFB. On the topic of consistency, what i was asking Weiming is whether the TLV you posted should suffice or not. Also: I dont think it would make much of a difference whether the T in TLV is global or per message. Infact on second thought I think that it may make sense to have it as local as proposed by Weiming since it gives us more room. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 09:42: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 JAA21945 for ; Mon, 17 May 2004 09:42: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 1BPiCh-0005JJ-V4 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 09:30:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HDUpDk020409 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 09:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi9x-0004vA-K4 for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 09:28: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 JAA21413 for ; Mon, 17 May 2004 09:27: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 1BPi9v-0007cw-Pj for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:27:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPi8Q-0007Bo-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:26:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPi7k-0006qR-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:25:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi3A-000439-PA; Mon, 17 May 2004 09:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPi0K-0003bR-MR for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 09:18: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 JAA20925 for ; Mon, 17 May 2004 09:18: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 1BPi0J-0004VS-04 for forces-protocol@ietf.org; Mon, 17 May 2004 09:18:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhzT-0004Bl-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:17:11 -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 1BPhyP-0003rp-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:16: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 2004051706201530:5841 ; Mon, 17 May 2004 06:20:15 -0700 Subject: Re: [Forces-protocol] Next Conference Call on Tuesday 7 AM PST ? From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org In-Reply-To: <40A8B21D.3050405@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E0108D9EB@orsmsx408.jf.intel.com> <40A8B21D.3050405@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1084799762.1087.3083.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 05/17/2004 06:20:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/17/2004 06:20:16 AM, Serialize complete at 05/17/2004 06:20:16 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 May 2004 09:16: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 I apologize i didnt ACK back. Tuesdayt is fine with me as well. I will try to catchup with the rest of email trail later today. cheers, jamal On Mon, 2004-05-17 at 08:37, Robert Haas wrote: > Tuesday 7 am PST (4 pm Zurich time) is fine with me. I assume we should > reserve 2 hours. > -Robert > > Khosravi, Hormuzd M wrote: > > >Ok, since we havent heard from Jamal either, lets keep this on Tuesday > >at 7 AM PST. Is that fine with everyone ?? > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: forces-protocol-admin@ietf.org > >[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > >Sent: Saturday, May 15, 2004 4:55 AM > >To: forces-protocol@ietf.org > >Subject: Re: [Forces-protocol] Next Conference Call on Monday 5 PM PST? > > > >Hi, > > > >At 7 am PST/16.00 CET on Monday (is that still the target?), I will be > >a plane flying from one part of Sweden to another part of Sweden. > >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 Mon May 17 10: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 KAA23134 for ; Mon, 17 May 2004 10: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 1BPifp-0001kP-PF for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10:00:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HE0vn0006712 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPif2-0001DJ-0g for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 10:00: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 KAA22948 for ; Mon, 17 May 2004 10:00: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 1BPiez-0002jZ-2x for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:00:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPie8-0002Of-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09:59:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPidA-00023u-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 09: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 1BPic1-0000qn-Ak; Mon, 17 May 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 1BPib3-0000he-2A for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 09: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 JAA22645 for ; Mon, 17 May 2004 09:55: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 1BPib1-0001Kq-34 for forces-protocol@ietf.org; Mon, 17 May 2004 09:55:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPia1-00010B-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:54:58 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPiZ2-0000N9-00 for forces-protocol@ietf.org; Mon, 17 May 2004 09:53:56 -0400 Received: from wwm1 (unverified [219.82.162.7]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 17 May 2004 22:06:39 +0800 Message-ID: <009301c43c15$cb5c7370$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> <1084458947.1022.37.camel@jzny.localdomain> Subject: Re: More summary WAS(RE: [Forces-protocol] topic 4c: Common Header:batching 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, 17 May 2004 21:49: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jamal, I appreciate the (academic :-) )summary that you took so much time on. ----- Original Message ----- From: "Jamal Hadi Salim" > > This is the last email on this thread - so let me jump to it; > Earlier i proposed for a definition of transaction - i should have > posted one. > I may go a little academic, so i apologize in advance (with a warning > that i am no expert). I think we may need an expert on this subject if > we are to get it right (not sure if Weiming or Ligang are) > > Transaction Definition: > A transaction is a sequence of operations that is guaranteed to be > _atomic_ in the presence of any failures by the CEs or FEs. > > Note: Atomic is part of the definition - i just added the CE/FE portion > to be specific to ForCES. > So having atomicity is not just for fun, it is what defines a > transaction. > What the definition implies is clear on recovery from error: Atomicity > implies an all-or-none operation. So _absolutely_ no question whatsoever > on what a failure reaction is in atomic operations. All operations which > are atomic (whether carried by one or multiple PL messages) are executed > serially to ensure consistency across multiple FEs[1]. > [Weiming]No doubt on the above summary. > What is the scope of a transaction? > In other words how small is a unit transaction? > We have introduced a flag to turn off atomicity. In such a case i > believe that each operation (part of msg body) in the PL message becomes a > standalone _transaction_. So to take it one more step: Each of those > transactions(in the message body) can be atomic. [Weiming]I agree that we can take every op in one msg body (mostly with a TLV format) as one transaction. Moreover, academically, we can take any contiguous ops in the msg body (like TLV1:TLV2:...TLVn) as one transaction, but this has made things much complex i practice. Therefore, I made a proposal in our last meeting that we may better to limit the freedom more or less. I just proposed that we may just define one msg as only one transaction/atomic. I think in most cases to take all ops in one same msg as one atomic is reasonable and practical, and with the help of multi-msgs of batching with free atomic/nonatomic selection, protocol flexibility will not be limited. > Lets pick an example to > clarify: > > A config PL msg with "route-add A B,C:route-del X" operations > > CASE I: decide that they both need to go together in which case an > atomic flag in the main header with the sequence number should suffice > to provide the semantics. > [Weiming]When using above proposal, we just put the ops of 'route-add A,B,C' and 'route-del X' in only one msg, while without any other flags to indicate the transaction. > CASE II: decide are independent atomic config operations in which case i > can put the atomic flag for route-add of A,B,C and another one for X in > their respective operation headers. [Weiming]We may just use two msgs with two transactions, one for 'route-add A,B,C' and one for 'route-del X', still without any flags to indicate the transactions. > > What you should note from the above is that in both case the > transactions are still _atomic_, only thing is granularity is different. > Clearly what we need to achieve case II is: > a) to allow for the atomic flag to also be within the operation headers > and b)to have a subsequence number to separate the success or failure of > "route-add of A,B,C" vs "route-del of X". > > Case II allows for higher concurency which is what i think Weiming is > refering to. I am torn apart because i see the value in it as a way to > further pipeline (fill that 100Gige pipe) but i dont see a clean way in > the responses which are not going to impose on the general message. I > believe we shouldnt give up on it yet. Weiming maybe you can think of > some clever way to do it? > [Weiming]My thinking of the case above is to use two msgs for the ops, then we can have separate responses for the msgs. Actually I'm not very sure if I have cought what you mean or not? If you mean the 'route-add A,B,C' are three ops that are put in three different msgs, then my scheme is as follows: First, pls let me explain the flags I used again: Atomic flag: 1 - indicating the begin or middle of the atomicity(transaction) 0 - indicating the end and the execution of the atomicity Atomic counter: to inidicate which transactions the msg belongs in a concurrent transaction case. (a 4 bit counter can support 16 concurrent transactions). Then my scheme is as follows: mark 4 msgs as: msg(add A), msg(add B), msg(add C), msg(del X) set atomic flag as: 1 1 0 0 set AtomCounter as: 1 1 1 2 (that means the msg(add A), msg(add B), msg(add C) belongs to the #1 concurrent transaction, while msg (del X) belongs to #2 concurrent transaction) After above setup, the 4 msgs can be sent to FE in any order, e.g., msg(add A):msg(add B):msg(del X):msg(add C), or msg(add A):msg(del X):msg(add B):msg(add C). We can further use a Batch flag to let above msg chains batchingly transmitted to FE. At the FE side, by using the atomic flag and the Atomic counter, we can easily recover the transactions. There may be only two responses for above 4 msgs (with 2 transactions), one for msg(add C), one for msg(del X), but note that we should carefully define the response msg format so that the response to a transaction end msg like the msg(add C) should be able to include all information about the transaction. I think something like a TLVforSummaryResponse in the end of the response msg can do this well. [/Weiming] > I think the confusion we are faced with has been a result of lumping > atomicity and concurency/parallelization in one. > Concurency is to allow us to improve the Forces computational > capability. We want to fill the pipe with transactions so as to maximize > the throughput. In other words, if you are provided with a 100Gige pipe > to submit transactions through, Forces protocol MUST not be the > bottleneck. The 100Gige could, of course. > Unfortunately (or fortunately) pipelining mechanisms such as batching is > also helpful in achieving atomicity if your transaction spans multiple > PL messages. [Weiming]Agreed completely. > > Ok, i probably spent over 30 minutes typing this - need to do real work. > > cheers, > jamal > > [1]A classical paper published on this subject (unfortunatley i am not > an ACM member so i cant retrieve it from their database) is > " T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database > Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983)" > My dusty high school book refers to the ACID properties of a > transactions as defined in that paper (I am sure there are a lot of > better papers than that which came after). > ACID is a mnemonic which translates to (some of the wording is mine): > > -> A for Atomicity ("a transaction is all or nothing") > -> C for Consitency ("A transaction moves the NE/FE from one consistent > state to another"); Example if a packet treatment such as a route goes > across multiple FEs then you better make sure that the all those > multiple FEs are updated at the same time, otherwise things will go > wrong. > -> I for isolation; essentially seriliazation of operations > -> D for Durability; an FE or CE crashing or a transaction failure > should be survivable. > Cheers, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 10:49:49 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 KAA26447 for ; Mon, 17 May 2004 10:49: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 1BPjQ6-0007MF-01 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10:48:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HEmj58028284 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjEz-00060z-Ku for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 10:37: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 KAA25904 for ; Mon, 17 May 2004 10:37: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 1BPjEx-0006sq-Bg for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:37:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjDz-0006Xp-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:36:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPjDT-0006DI-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:35:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPj81-0004y3-EZ; Mon, 17 May 2004 10:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPj1F-00045i-Lx for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 10:23: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 KAA25176 for ; Mon, 17 May 2004 10:23: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 1BPj1D-0002D3-Fb for forces-protocol@ietf.org; Mon, 17 May 2004 10:23:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPj0K-0001tx-00 for forces-protocol@ietf.org; Mon, 17 May 2004 10:22:09 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPizY-0001Zt-00 for forces-protocol@ietf.org; Mon, 17 May 2004 10:21:21 -0400 Received: from wwm1 (unverified [219.82.162.7]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 17 May 2004 22:34:05 +0800 Message-ID: <010301c43c19$a06cf280$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07E0108D902@orsmsx408.jf.intel.com> <1084799709.1098.3079.camel@jzny.localdomain> Subject: Re: Consistent body TLV? WAS( RE: [Forces-protocol] Add Route Example 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, 17 May 2004 22:16:55 +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 autolearn=no version=2.60 Jamal,Hormuzd as well, ----- Original Message ----- From: "Jamal Hadi Salim" > On Fri, 2004-05-14 at 22:01, Khosravi, Hormuzd M wrote: > > > [HK] Yes 16 bits might be insufficient for this. However, I could > > combine LFB Type (16 bits, including version no), Operation (8 bits), > > Flags (8 Bits) into a 32-bit field. Does that sound good ? Let me know > > From your comments to Weiming i now understand the meaning of type. > 16 bits is a little too much for that. So having it as: > > TYPE := ATTR_TYPE(4 bits max): VERSION (4 bits): OPERATION(8 bits) > i think should suffice. > [Weiming]I'm quite with this format, only with the VERSION here, I'm not sure if we can have it put in the V place. Also I'm not very sure if it is the version for an attribute or for operation here. Moreover, if we need the version in the end, I suppose if we can put it at the beginning of T, that is, VERSION:ATTR_TYPE:OP. > 4 bits are overkill for ATTR_TYPE since you only have it belonging > to either an FE or LFB. > [Weiming]I suppose if we can define an ATTR_TYPE as 'Vendor' for vendor support here. Anyway, 2 bits is enough. we may leave 2 bits as reserved. > On the topic of consistency, what i was asking Weiming is whether the > TLV you posted should suffice or not. > > Also: I dont think it would make much of a difference whether the T in > TLV is global or per message. Infact on second thought I think that > it may make sense to have it as local as proposed by Weiming since it > gives us more room. > > 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 May 17 11:00:27 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 LAA27128 for ; Mon, 17 May 2004 11:00: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 1BPjZ0-0008Vz-4z for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HEvw25032727 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 10: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 1BPjRW-0007gS-Fm for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 10:50: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 KAA26520 for ; Mon, 17 May 2004 10:50: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 1BPjRU-0003N4-2u for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjQZ-00032y-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:49:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPjQ2-0002iF-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 10:48:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPjEl-0005z7-Nm; Mon, 17 May 2004 10: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 1BPjCy-0005hn-0W for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 10:35: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 KAA25771 for ; Mon, 17 May 2004 10:35: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 1BPjCv-0006Ca-Ks for forces-protocol@ietf.org; Mon, 17 May 2004 10:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPjC4-0005sO-00 for forces-protocol@ietf.org; Mon, 17 May 2004 10:34:17 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPjBN-0005Xx-00 for forces-protocol@ietf.org; Mon, 17 May 2004 10:33:34 -0400 Received: from wwm1 (unverified [219.82.162.7]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 17 May 2004 22:46:24 +0800 Message-ID: <011101c43c1b$5903eeb0$020aa8c0@wwm1> From: "Weiming Wang" To: , References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> <40A3FEB6.8050301@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching 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, 17 May 2004 22:29:17 +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 autolearn=no version=2.60 Hi Avri, ----- Original Message ----- From: > On 14 maj 2004, at 01.03, Robert Haas wrote: > > > I finally see a justification for plain batching (that is, batching > > without atomicity): a batch will result in a single status: > > [ad] Actually I have found that problematic. What i have found is > that I need a error per command. the overall error indicator can be > used to indicate that one or more of the commands failed, but each > command probably needs its own error indicated. > [Weiming] I agreed. I suppose if following scheme can meet the requirement: Taking a Config msg with the format as: CommonHeader(ConfigType): TLVforOP1:TLVforOP2:...TLVforOPn as an example. We may allow two format of ACK/Response. Verbose mode - the response is, CommonHeader(ConfigReType): TLVforReOP1:TLVforReOP2:TLVforReOPn:TLVforReSUM. Precise mode - the response is, CommonHeader(ConfigReType): TLVforReSUM The TLVforReSUM includes a summary for the transaction excution. I also suggest (as in my recent reply to Jamal's summary ans also in the meeting minutes), we may better to treat a msg as a transaction, that is, all ops(commands) inside one msg should have the meaning of 'all or nothing', so as to simplify our protocol definition. Could you give some comments on the thought? > > OK if all commands in the batch failed, and notOK if some of them > > failed (and probably we should stop processing commands after the > > first failure). > > I think that is a different type of command, the do until error batch. > > > > > Is this a semantics that would be acceptable to everyone ? > > I guess I don't think so. > > a. > Thank you very much. BR Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 12:01: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 MAA00948 for ; Mon, 17 May 2004 12:01: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 1BPkTO-0007kg-FA for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 11:56:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HFuE4H029796 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 11:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkOb-0006nC-Oc for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 11:51: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 LAA00173 for ; Mon, 17 May 2004 11:51: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 1BPkOa-0000gt-NW for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 11:51:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkNo-0000Me-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 11:50:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPkN7-00000t-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 11:49:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkCm-0005Tt-MZ; Mon, 17 May 2004 11:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPk3E-0003lT-Lm for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 11:29: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 LAA28379 for ; Mon, 17 May 2004 11:29:10 -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 1BPk3D-0000r1-LT for forces-protocol@ietf.org; Mon, 17 May 2004 11:29:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPk2N-0000Wh-00 for forces-protocol@ietf.org; Mon, 17 May 2004 11:28:19 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BPk1P-0000Cb-00 for forces-protocol@ietf.org; Mon, 17 May 2004 11:27:19 -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 i4HFQsH25283; Mon, 17 May 2004 18:26:56 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 18:26:12 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4HFQChr027273; Mon, 17 May 2004 18:26:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00rgSEkX; Mon, 17 May 2004 18:26:10 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 i4HFQ9H03080; Mon, 17 May 2004 18:26:09 +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, 17 May 2004 10:25:26 -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] Next Conference Call on Tuesday 7 AM PST ? Message-ID: Thread-Topic: [Forces-protocol] Next Conference Call on Tuesday 7 AM PST ? Thread-Index: AcQ8GEIfWryXCfLbR5q890Ra5JqonwACtRKQ To: , Cc: , X-OriginalArrivalTime: 17 May 2004 15:25:26.0672 (UTC) FILETIME=[2E038100:01C43C23] 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, 17 May 2004 11:25: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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hell all, I came back to boston and catching up with emails... Tuesday is fine = with me. regards ramg > -----Original Message----- > From: forces-protocol-admin@ietf.org > [mailto:forces-protocol-admin@ietf.org]On Behalf Of ext Jamal=20 > Hadi Salim > Sent: Monday, May 17, 2004 9:16 AM > To: Robert Haas > Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] Next Conference Call on=20 > Tuesday 7 AM PST > ? >=20 >=20 >=20 > I apologize i didnt ACK back. Tuesdayt is fine with me as well. I will > try to catchup with the rest of email trail later today. >=20 > cheers, > jamal >=20 >=20 > On Mon, 2004-05-17 at 08:37, Robert Haas wrote: > > Tuesday 7 am PST (4 pm Zurich time) is fine with me. I=20 > assume we should=20 > > reserve 2 hours. > > -Robert > >=20 > > Khosravi, Hormuzd M wrote: > >=20 > > >Ok, since we havent heard from Jamal either, lets keep=20 > this on Tuesday > > >at 7 AM PST. Is that fine with everyone ?? > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > >From: forces-protocol-admin@ietf.org > > >[mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > > >Sent: Saturday, May 15, 2004 4:55 AM > > >To: forces-protocol@ietf.org > > >Subject: Re: [Forces-protocol] Next Conference Call on=20 > Monday 5 PM PST? > > > > > >Hi, > > > > > >At 7 am PST/16.00 CET on Monday (is that still the=20 > target?), I will be=20 > > >a plane flying from one part of Sweden to another part of Sweden. > > >a. > > > > > > > > > > > >_______________________________________________ > > >Forces-protocol mailing list > > >Forces-protocol@ietf.org > > >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > > > > > > =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 May 17 13:03:05 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 NAA05243 for ; Mon, 17 May 2004 13:03:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlGf-0001MX-3y for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 12:47:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGl9jv005237 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 12:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPl7C-0007q6-5l for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 12:37: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 MAA03646 for ; Mon, 17 May 2004 12:37: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 1BPl7A-0001T7-K3 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 12:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPl5w-00016M-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 12:36:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPl4v-0000iu-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 12:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPky8-0006Bg-PD; Mon, 17 May 2004 12: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 1BPkhw-0001mi-DS for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 12:11: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 MAA01628 for ; Mon, 17 May 2004 12:11: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 1BPkhv-0007bQ-34 for forces-protocol@ietf.org; Mon, 17 May 2004 12:11:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkh2-0007G2-00 for forces-protocol@ietf.org; Mon, 17 May 2004 12:10:21 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BPkgG-0006qp-00 for forces-protocol@ietf.org; Mon, 17 May 2004 12:09:32 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4HG91GP065454; Mon, 17 May 2004 16:09:01 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4HG90OT027466; Mon, 17 May 2004 18:09:00 +0200 Received: from zurich.ibm.com (dhcp69-162.zurich.ibm.com [9.4.69.162]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA41974; Mon, 17 May 2004 18:09:00 +0200 Message-ID: <40A8E39B.7020809@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: Weiming Wang , forces-protocol@ietf.org Subject: Re: [Forces-protocol] HB msgs ? References: <468F3FDA28AA87429AD807992E22D07E0108D9FC@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0108D9FC@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 mtagate1.de.ibm.com id i4HG91GP065454 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, 17 May 2004 18:08:59 +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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, We should assess the tradeoff for HB (and potentially other=20 protocol-specific messages) being treated as: a) an Event (of a meta LFB representing the FE), or b) as its own specific Message Type (i.e., in the Common Header). To me, the most important is that: a) has a cleaner unified design: protocol-specific messages such as HB=20 are treated as LFB messages, but b) has a simpler parsing when doing traffic analysis: protocol-specific=20 messages are easier to spot in the flow of LFB messages: no need to look=20 into the body of the message to find out that it is a HB. Anyone has other arguments in favor of one or the other ? Let's then=20 judge which one is more suitable. -Robert Khosravi, Hormuzd M wrote: >Weiming, > >You make a good point. I was just thinking 2 msgs for HB, HB >Resp/Ack...4 msgs will be a bit too much. Anyways I am not religious >about this one, neither is Jamal, I think. We are just stating our >preferences. > >Lets see what Avri prefers. I am fine with whatever the majority >decides. > >Regards >Hormuzd >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang > >[Weiming] One more thing we should note is, we have totally only arround >10 >message types for our protocol, to have another 2 to 4 msgs specifically >for HB >looks really biased and makes it more or less ugly in the appearance of >our >protocol. >I even more prefer to the scheme to treat HB as an LFB (I remember Jamal >mentioned this), than to have separate msgs for them. >[/Weiming] > >I guess the key question that I would ask is if we want Event msg to >symbolize asynchronous events or we want to mix the semantics with >synchronous msgs as well ? I think keeping the 2 separate is cleaner, >but I am open to other views as well. >[Weiming] I don't think we may need to distinguish semantically the syn. >and >asyn. msgs in our protocol, because they have no principal difference in >our >scope. We can say an event notification is asyncronous, but we can also >say any >query or config from CE to FE is also asyncronous. Actually I just think >it >makes little sense to distinguish them. > >Avri, could you share your opinion on this ? > > > >_______________________________________________ >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 Mon May 17 14:07:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09153 for ; Mon, 17 May 2004 14:07: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 1BPmFc-0002Hw-Gq for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 13:50:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHo8bn008794 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 13:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm9s-0001Bi-Fi for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:44: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 NAA07918 for ; Mon, 17 May 2004 13:44: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 1BPm9q-0001NM-CC for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:44:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPm8o-00010e-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:43:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPm7o-0000cV-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm14-0008N5-BL; Mon, 17 May 2004 13:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlsf-0006rW-Pv for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 13:26: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 NAA06670 for ; Mon, 17 May 2004 13:26: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 1BPlsd-0002tI-M5 for forces-protocol@ietf.org; Mon, 17 May 2004 13:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlrg-0002Yq-00 for forces-protocol@ietf.org; Mon, 17 May 2004 13:25:25 -0400 Received: from fmr10.intel.com ([192.55.52.30] helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPlr4-0002Cx-00 for forces-protocol@ietf.org; Mon, 17 May 2004 13:24:46 -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 i4HHM8HV022742; Mon, 17 May 2004 17:22:10 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 i4HHMgFD002136; Mon, 17 May 2004 17:23:39 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 M2004051710225926447 ; Mon, 17 May 2004 10:22: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); Mon, 17 May 2004 10:22: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] HB msgs ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108DE24@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] HB msgs ? Thread-Index: AcQ8CdtsnzLvsToxTcO2nkTB0l3KzwAKRPFA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 17 May 2004 17:22:59.0528 (UTC) FILETIME=[99D7EC80:01C43C33] 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, 17 May 2004 10:22: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 Avri, Thanks for providing your input. I am fine with just a single HB msg as well, I believe both approaches (HB, HB/HB Ack) will work fine. This might also address Weiming's concern regarding too many msgs for HBs.=20 So after this tie-breaker vote (if I may say so :)), is the team fine with this compromise (Avri's suggestion) for now ? Thanks Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org > I was just thinking 2 msgs for HB, HB > Resp/Ack... i am not sure I understand why a HB needs an ack as everyone should be=20 sending them on a similar interval (though in some network=20 environments, hopefully not synchronized) a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 14:07:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09204 for ; Mon, 17 May 2004 14:07: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 1BPmFg-0002Jd-7J for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 13:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHoCeg008896 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 13:50:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmB8-0001Qc-QC for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:45: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 NAA08019 for ; Mon, 17 May 2004 13:45: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 1BPmB6-0001lH-PG for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:45:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmAG-0001QI-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:44:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPm9X-00014J-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 13:43:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm1x-0008VG-H3; Mon, 17 May 2004 13: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 1BPlxG-0007g3-0h for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 13: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 NAA07013 for ; Mon, 17 May 2004 13:31: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 1BPlxD-0004b6-PH for forces-protocol@ietf.org; Mon, 17 May 2004 13:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlwG-0004FA-00 for forces-protocol@ietf.org; Mon, 17 May 2004 13:30:08 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPlvG-0003QI-00 for forces-protocol@ietf.org; Mon, 17 May 2004 13:29:06 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4HHStkc001129; Mon, 17 May 2004 17:28:55 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 i4HHSEFF006809; Mon, 17 May 2004 17:29:07 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 M2004051710283127318 ; Mon, 17 May 2004 10:28:31 -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, 17 May 2004 10:28: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] HB msgs ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0108DE47@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] HB msgs ? Thread-Index: AcQ8KWLSJN3tshRhTpigKtYVeN4piQACkP1Q From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: "Weiming Wang" , X-OriginalArrivalTime: 17 May 2004 17:28:31.0985 (UTC) FILETIME=[6000D610:01C43C34] 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, 17 May 2004 10:28: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 Robert, You have articulated the tradeoff logic well below, Thanks for this. Just one point, I don't believe HB is related with LFB in anyways, its purely a protocol characteristic to determine association aliveness or connectivity between the CEs, FEs. regards Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 All, We should assess the tradeoff for HB (and potentially other=20 protocol-specific messages) being treated as: a) an Event (of a meta LFB representing the FE), or b) as its own specific Message Type (i.e., in the Common Header). To me, the most important is that: a) has a cleaner unified design: protocol-specific messages such as HB=20 are treated as LFB messages, but b) has a simpler parsing when doing traffic analysis: protocol-specific=20 messages are easier to spot in the flow of LFB messages: no need to look into the body of the message to find out that it is a HB. Anyone has other arguments in favor of one or the other ? Let's then=20 judge which one is more suitable. -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 15:48: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 PAA19454 for ; Mon, 17 May 2004 15:48: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 1BPnqJ-0002fW-WD for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 15:32:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HJW7lO010259 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 15:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnZK-0004wi-NV for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 15:14: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 PAA16492 for ; Mon, 17 May 2004 15:14: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 1BPnZJ-000367-Cq for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 15:14:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPnYQ-0002iZ-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 15:13:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPnXa-0002LK-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 15:12:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnDh-0005Jv-Ld; Mon, 17 May 2004 14:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPn89-0003zH-74 for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 14:46: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 OAA13795 for ; Mon, 17 May 2004 14:46: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 1BPn86-0000ne-BN for forces-protocol@ietf.org; Mon, 17 May 2004 14:46:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPn72-0000Mc-00 for forces-protocol@ietf.org; Mon, 17 May 2004 14:45: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 1BPn5l-0007Ih-00 for forces-protocol@ietf.org; Mon, 17 May 2004 14:44:01 -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 i4HIhivU014386; Mon, 17 May 2004 18:43:44 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 i4HIhGUo021043; Mon, 17 May 2004 18:43:28 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 M2004051711424817248 ; Mon, 17 May 2004 11:42:48 -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, 17 May 2004 11:42: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: [Forces-protocol] Conference Call on Tuesday (May 18) 7 AM PST -details below Message-ID: <468F3FDA28AA87429AD807992E22D07E01108C10@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Conference Call on Tuesday (May 18) 7 AM PST -details below Thread-Index: AcQ8GEIfWryXCfLbR5q890Ra5JqonwACtRKQAAbJMLA= From: "Khosravi, Hormuzd M" To: Cc: , , , , "Weiming Wang" X-OriginalArrivalTime: 17 May 2004 18:42:48.0136 (UTC) FILETIME=[C0138480:01C43C3E] 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, 17 May 2004 11:42: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 Here are the details for the conference call.. Start: May 18, 2004 07:00 Pacific Time End: May 18, 2004 09:00 Pacific Time Phone Number: 916-356-2663 Reservation #: 2 Passcode: 5889108 Hope to chat with all of you tomorrow, Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 21:51:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20919 for ; Mon, 17 May 2004 21:51: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 1BPtfW-0004w5-PM for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 21:45:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I1jMKh018972 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 21:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtc6-0003yh-1l for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 21:41: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 VAA20468 for ; Mon, 17 May 2004 21:41: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 1BPtc3-00060q-8T for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:41:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPtb5-0005eE-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:40:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPtaS-0005Ho-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtSf-00012Y-81; Mon, 17 May 2004 21:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtJf-0005Fq-Fr for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 21:22: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 VAA19439 for ; Mon, 17 May 2004 21:22: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 1BPtJc-0006dT-TC for forces-protocol@ietf.org; Mon, 17 May 2004 21:22:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPtIh-0006HG-00 for forces-protocol@ietf.org; Mon, 17 May 2004 21:21:48 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPtI8-0005s7-00 for forces-protocol@ietf.org; Mon, 17 May 2004 21:21:12 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4I1L01o009216 for ; Tue, 18 May 2004 01:21: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 i4I1LBCk021763 for ; Tue, 18 May 2004 01:21:11 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 M2004051718203500577 for ; Mon, 17 May 2004 18:20:35 -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, 17 May 2004 18:20:25 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C76.4C47F535" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <468F3FDA28AA87429AD807992E22D07E01109258@orsmsx408.jf.intel.com> Thread-Topic: T in TLV, another thought Thread-Index: AcQ8dkv8R5Y9AqmGRqGditp/5MKcdg== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 18 May 2004 01:20:25.0758 (UTC) FILETIME=[4C53BBE0:01C43C76] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Forces-protocol] T in TLV, another thought 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, 17 May 2004 18: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.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_01C43C76.4C47F535 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team =20 Thanks for the comments on the Global vs local scope for T in TLV. =20 Another design principle that I would like to share and get your thoughts on is... How do we choose semantics for T ? The basic principle is that a different T should mean a different V, essentially T defines V. To give you an example... in the Config message format that I had sent out, I used T to mean either FE or LFB attributes. This is cause I see the V in case of T=3DLAB attributes having fields = such as LAB Type, LAB Instance ID. In case T=3DFE attributes, we probably = wont have these 2 fields. Does that help understand the logic for defining T ? =20 Do you guys think this is a good design principle ? =20 Let me know, =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C43C76.4C47F535 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Team
 
Thanks = for the=20 comments on the Global vs local scope for T in TLV.
 
Another design=20 principle that I would like to share and get your thoughts on=20 is...
How do = we choose=20 semantics for T ? The basic principle is that a different T = should=20 mean a different V, essentially T defines V.
To = give you an=20 example... in the Config message format that I had sent out, I used T to = mean=20 either FE or LFB attributes.
This = is cause I see=20 the V in case of T=3DLAB attributes having fields such as LAB Type, LAB = Instance=20 ID. In case T=3DFE attributes, we probably wont have these 2 fields. = Does that=20 help understand the logic for defining T ?
 
Do you = guys think=20 this is a good design principle ?
 
Let me = know,
 
Thanks
Hormuzd
 
------_=_NextPart_001_01C43C76.4C47F535-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 21:51:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20964 for ; Mon, 17 May 2004 21:51: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 1BPtfW-0004wT-V7 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 21:45:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I1jMPe018992 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 21:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtck-0003yt-B8 for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 21:42: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 VAA20472 for ; Mon, 17 May 2004 21:42: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 1BPtch-0006M3-Ht for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPtbi-0005yi-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:41:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPtac-0005KB-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 21:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtSf-00012g-GZ; Mon, 17 May 2004 21:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPtMS-0005QU-Ku for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 21:25: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 VAA19518 for ; Mon, 17 May 2004 21:25: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 1BPtMP-0007gT-QS for forces-protocol@ietf.org; Mon, 17 May 2004 21:25:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPtLQ-0007Km-00 for forces-protocol@ietf.org; Mon, 17 May 2004 21:24:37 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPtKP-0006dm-00 for forces-protocol@ietf.org; Mon, 17 May 2004 21:23:33 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4I1NR1o010271; Tue, 18 May 2004 01:23:27 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 i4I1NOCq023199; Tue, 18 May 2004 01:23:35 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 M2004051718225700959 ; Mon, 17 May 2004 18:22: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); Mon, 17 May 2004 18:22:57 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C76.A6A64E07" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] T in TLV ? Message-ID: <468F3FDA28AA87429AD807992E22D07E0110925C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV ? Thread-Index: AcQ6YlRCCl8uAToUQzuPmS+jDWTJ4ACFBK+w From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 18 May 2004 01:22:57.0561 (UTC) FILETIME=[A6CF0890:01C43C76] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 17 May 2004 18:22: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.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43C76.A6A64E07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiming =20 I have tried to answer your comment below in another email that I just sent out regarding defining T in TLV. I hope that helps. Let me know if you have any other questions. =20 regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Sent: Saturday, May 15, 2004 2:35 AM To: forces-protocol@ietf.org Subject: Fw: [Forces-protocol] T in TLV ? Hormuzd, =20 One more thing I have to mention is, the scheme you used in the add route example for T (T=3D LFBattr / FEattri ) will result in local meaning, while the plan I proposed ( T=3DAdd/Del/Update...+ LFBattr/FEattri ) actually can have global meaning. : -) =20 Cheers, Weiming =20 ------_=_NextPart_001_01C43C76.A6A64E07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Weiming
 
I have=20 tried to answer your comment below in another email that I just sent out = regarding defining T in TLV.
I hope=20 that helps. Let me know if you have any other = questions.
 
regards
Hormuzd
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On=20 Behalf Of Weiming Wang
Sent: Saturday, May 15, 2004 2:35 = AM
To: forces-protocol@ietf.org
Subject: Fw:=20 [Forces-protocol] T in TLV ?

Hormuzd,
 
One more thing I have to = mention is, the scheme=20 you used in the add route example for T (T=3D LFBattr / FEattri ) will = result in=20 local meaning, while the plan I proposed ( T=3DAdd/Del/Update...+=20 LFBattr/FEattri ) actually can have global meaning. : -)
 
Cheers,
Weiming
 
------_=_NextPart_001_01C43C76.A6A64E07-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 22:23:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22224 for ; Mon, 17 May 2004 22:23: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 1BPuEo-0006DS-Fl for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:21:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I2Lomx023889 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuDp-0005wd-Dk for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 22: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 WAA22154 for ; Mon, 17 May 2004 22:20: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 1BPuDm-0004cc-8i for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:20:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuD0-0004GD-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:19:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPuCK-0003so-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuB7-00052I-8g; Mon, 17 May 2004 22: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 1BPu5A-0003P2-PN for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 22:11: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 WAA21870 for ; Mon, 17 May 2004 22:11: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 1BPu57-0001OK-Jz for forces-protocol@ietf.org; Mon, 17 May 2004 22:11:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPu48-000119-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:10:48 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPu3F-0000dr-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:09:53 -0400 Received: from wwm1 (unverified [219.82.186.197]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 18 May 2004 10:22:45 +0800 Message-ID: <007a01c43c7c$9f6871d0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E01109258@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] T in TLV, another thought MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C43CBF.AC345F30" 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, 18 May 2004 10:05: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=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_0077_01C43CBF.AC345F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEhvcm11emQsDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAg RnJvbTogS2hvc3JhdmksIEhvcm11emQgTSANCiAgVG86IGZvcmNlcy1wcm90b2NvbEBpZXRmLm9y ZyANCiAgU2VudDogVHVlc2RheSwgTWF5IDE4LCAyMDA0IDk6MjAgQU0NCiAgU3ViamVjdDogW0Zv cmNlcy1wcm90b2NvbF0gVCBpbiBUTFYsIGFub3RoZXIgdGhvdWdodA0KDQoNCiAgSGkgVGVhbQ0K DQogIFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIG9uIHRoZSBHbG9iYWwgdnMgbG9jYWwgc2NvcGUg Zm9yIFQgaW4gVExWLg0KDQogIEFub3RoZXIgZGVzaWduIHByaW5jaXBsZSB0aGF0IEkgd291bGQg bGlrZSB0byBzaGFyZSBhbmQgZ2V0IHlvdXIgdGhvdWdodHMgb24gaXMuLi4NCiAgSG93IGRvIHdl IGNob29zZSBzZW1hbnRpY3MgZm9yIFQgPyBUaGUgYmFzaWMgcHJpbmNpcGxlIGlzIHRoYXQgYSBk aWZmZXJlbnQgVCBzaG91bGQgbWVhbiBhIGRpZmZlcmVudCBWLCBlc3NlbnRpYWxseSBUIGRlZmlu ZXMgVi4NCiAgVG8gZ2l2ZSB5b3UgYW4gZXhhbXBsZS4uLiBpbiB0aGUgQ29uZmlnIG1lc3NhZ2Ug Zm9ybWF0IHRoYXQgSSBoYWQgc2VudCBvdXQsIEkgdXNlZCBUIHRvIG1lYW4gZWl0aGVyIEZFIG9y IExGQiBhdHRyaWJ1dGVzLg0KICBUaGlzIGlzIGNhdXNlIEkgc2VlIHRoZSBWIGluIGNhc2Ugb2Yg VD1MQUIgYXR0cmlidXRlcyBoYXZpbmcgZmllbGRzIHN1Y2ggYXMgTEFCIFR5cGUsIExBQiBJbnN0 YW5jZSBJRC4gSW4gY2FzZSBUPUZFIGF0dHJpYnV0ZXMsIHdlIHByb2JhYmx5IHdvbnQgaGF2ZSB0 aGVzZSAyIGZpZWxkcy4gRG9lcyB0aGF0IGhlbHAgdW5kZXJzdGFuZCB0aGUgbG9naWMgZm9yIGRl ZmluaW5nIFQgPw0KICBbV2VpbWluZ10gSSB0aGluayBJIChKYW1hbCBhcyB3ZWxsKSBoYXZlIGFs cmVhZHkgcHJlc2VudGVkIHRoZSBpZGVhIG9uIHRoZSBWYWx1ZSBmb3JtYXQgZGlmZmVyZW5jZSBv ZiBMRkIgYXR0cmlidXRlL2V2ZW50IGFuZCBGRSBhdHRyaWJ1dGUvZXZlbnQgKGluIG15IGVtYWwg b24gZXZlbnQgbXNnIGZvcm1hdCBhbmQgYWxzbyBpbiB0aGUgcmVwbHkgdG8geW91ciBlbWFsKS4g SSBqdXN0IHRoaW5rIG9ubHkgbWVudGlvbmluZyB0aGUgRkUgb3IgTEZCIGluIFQgaXMgbm90IGVu b3VnaCB0byBoYXZlIGdsb2JhbCBtZWFuaW5nLCBlLmcuLCBMRkIgcXVlcnkgYW5kIExGQiBjb25m aWcgbWF5IGhhdmUgcXVpdGUgZGlmZmVyZW50IFBEVSBmb3JtYXQuIFdlIHNob3VsZCBpbmNsdWRl IG9wZXJhdGlvbiBjb2RlIGluIHRoZSBUIChhcyBJIGFuZCBKYW1hbCBwcm9wb3NlZCkuICBIb3Bl IHdlIGNhbiBiZSBtb3JlIHN5bmNocm9ub3VzIG9uIHRoaXMgaXNzdWUgOiAtKS4gDQoNCiAgRG8g eW91IGd1eXMgdGhpbmsgdGhpcyBpcyBhIGdvb2QgZGVzaWduIHByaW5jaXBsZSA/DQoNCiAgTGV0 IG1lIGtub3csDQoNCiAgVGhhbmtzDQogIEhvcm11emQNCg0KICBDaGVlcnMsDQogIFdlaW1pbmcN Cg== ------=_NextPart_000_0077_01C43CBF.AC345F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaSBIb3JtdXpkLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IDwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VO RDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNr Ij48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20g DQogIGhyZWY9Im1haWx0bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwg SG9ybXV6ZCBNPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBo cmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+PEI+U2VudDo8L0I+IFR1ZXNkYXksIE1heSAxOCwgMjAwNCA5OjIwIEFNPC9ESVY+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gW0Zv cmNlcy1wcm90b2NvbF0gVCBpbiBUTFYsIGFub3RoZXIgDQogIHRob3VnaHQ8L0RJVj4NCiAgPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48QlI+PC9ESVY+DQog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUy MDA0PkhpIA0KICBUZWFtPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjwvU1BBTj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xh c3M9NTQ0MTUxMjAxLTE4MDUyMDA0PlRoYW5rcyBmb3IgdGhlIA0KICBjb21tZW50cyBvbiB0aGUg R2xvYmFsIHZzIGxvY2FsIHNjb3BlIGZvciBUIGluIFRMVi48L1NQQU4+PC9GT05UPjwvRElWPg0K ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01NDQxNTEyMDEt MTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+QW5vdGhlciBkZXNpZ24g DQogIHByaW5jaXBsZSB0aGF0IEkgd291bGQgbGlrZSB0byBzaGFyZSBhbmQgZ2V0IHlvdXIgdGhv dWdodHMgb24gDQogIGlzLi4uPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+SG93IGRvIHdlIGNo b29zZSANCiAgc2VtYW50aWNzJm5ic3A7Zm9yJm5ic3A7VCA/IFRoZSBiYXNpYyBwcmluY2lwbGUg aXMgdGhhdCBhIGRpZmZlcmVudCBUIHNob3VsZCANCiAgbWVhbiBhIGRpZmZlcmVudCBWLCBlc3Nl bnRpYWxseSBUIGRlZmluZXMgVi48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND5UbyBnaXZlIHlv dSBhbiANCiAgZXhhbXBsZS4uLiBpbiB0aGUgQ29uZmlnIG1lc3NhZ2UgZm9ybWF0IHRoYXQgSSBo YWQgc2VudCBvdXQsIEkgdXNlZCBUIHRvIG1lYW4gDQogIGVpdGhlciBGRSBvciBMRkIgYXR0cmli dXRlcy48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND5UaGlzIGlzIGNhdXNlIEkgDQogIHNlZSB0 aGUgViBpbiBjYXNlIG9mIFQ9TEFCIGF0dHJpYnV0ZXMgaGF2aW5nIGZpZWxkcyBzdWNoIGFzIExB QiBUeXBlLCBMQUIgDQogIEluc3RhbmNlIElELiBJbiBjYXNlIFQ9RkUgYXR0cmlidXRlcywgd2Ug cHJvYmFibHkgd29udCBoYXZlIHRoZXNlIDIgZmllbGRzLiANCiAgRG9lcyB0aGF0IGhlbHAgdW5k ZXJzdGFuZCB0aGUgbG9naWMgZm9yIGRlZmluaW5nIFQmbmJzcDs/PC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDQxNTEyMDEt MTgwNTIwMDQ+W1dlaW1pbmddIEkgdGhpbmsgDQogIEkgKEphbWFsIGFzIHdlbGwpIGhhdmUgYWxy ZWFkeSBwcmVzZW50ZWQmbmJzcDt0aGUgaWRlYSBvbiB0aGUgVmFsdWUgZm9ybWF0IA0KICBkaWZm ZXJlbmNlIG9mIExGQiBhdHRyaWJ1dGUvZXZlbnQgYW5kIEZFIGF0dHJpYnV0ZS9ldmVudCAoaW4g bXkgZW1hbCBvbiBldmVudCANCiAgbXNnIGZvcm1hdCBhbmQgYWxzbyBpbiB0aGUgcmVwbHkgdG8g eW91ciBlbWFsKS4gSSBqdXN0IHRoaW5rIG9ubHkgbWVudGlvbmluZyANCiAgdGhlIEZFIG9yIExG QiBpbiBUIGlzIG5vdCBlbm91Z2ggdG8gaGF2ZSZuYnNwO2dsb2JhbCBtZWFuaW5nLCBlLmcuLCBM RkIgDQogIHF1ZXJ5Jm5ic3A7YW5kIExGQiBjb25maWcgbWF5IGhhdmUgcXVpdGUgZGlmZmVyZW50 IFBEVSBmb3JtYXQuIFdlIHNob3VsZCANCiAgaW5jbHVkZSBvcGVyYXRpb24gY29kZSBpbiB0aGUg VCAoYXMgSSBhbmQgSmFtYWwgDQogIHByb3Bvc2VkKS4mbmJzcDsmbmJzcDtIb3BlJm5ic3A7d2Ug Y2FuIGJlIG1vcmUgc3luY2hyb25vdXMgb24gdGhpcyBpc3N1ZSA6IC0pLiANCiAgPC9TUEFOPjwv Rk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xh c3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PkRv IHlvdSBndXlzIHRoaW5rIA0KICB0aGlzIGlzIGEgZ29vZCBkZXNpZ24gcHJpbmNpcGxlID88L1NQ QU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0K ICBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIw MDQ+TGV0IG1lIA0KICBrbm93LDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48L1NQQU4+ PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KICBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+VGhhbmtzPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTQ0MTUxMjAx LTE4MDUyMDA0Pkhvcm11emQ8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiAN CiAgY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PkNoZWVycyw8L1NQQU4+PC9GT05UPjwvRElWPg0K ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01NDQxNTEyMDEt MTgwNTIwMDQ+V2VpbWluZzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0077_01C43CBF.AC345F30-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 22:52:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23664 for ; Mon, 17 May 2004 22:52: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 1BPugV-0004uH-Sk for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:50:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I2oRST018861 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPucz-0003hX-CS for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 22: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 WAA23375 for ; Mon, 17 May 2004 22:46: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 1BPucv-0006R8-VQ for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:46:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPucO-00063n-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:46:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPubH-0005es-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuVQ-0000ZO-F5; Mon, 17 May 2004 22:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuJc-0007QK-2V for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 22:26: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 WAA22341 for ; Mon, 17 May 2004 22:26: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 1BPuJY-0006sr-Nk for forces-protocol@ietf.org; Mon, 17 May 2004 22:26:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuIo-0006WI-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:25:58 -0400 Received: from fmr11.intel.com ([192.55.52.31] helo=fmsfmr004.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BPuIA-00067P-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:25:18 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4I2OAXS018900; Tue, 18 May 2004 02:24:11 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 i4I2O7Co028064; Tue, 18 May 2004 02:24: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 M2004051719233408297 ; Mon, 17 May 2004 19:23: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); Mon, 17 May 2004 19:23: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: Consistent body TLV? WAS( RE: [Forces-protocol] Add Route Example Message-ID: <468F3FDA28AA87429AD807992E22D07E01109276@orsmsx408.jf.intel.com> Thread-Topic: Consistent body TLV? WAS( RE: [Forces-protocol] Add Route Example Thread-Index: AcQ8EP4ORhFaIvtgQmS+6NxSRpk2nQAbOaSQ From: "Khosravi, Hormuzd M" To: Cc: , "Wang,Weiming" , "Robert Haas" X-OriginalArrivalTime: 18 May 2004 02:23:34.0592 (UTC) FILETIME=[1EA5EC00:01C43C7F] 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, 17 May 2004 19:23:34 -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. My comments below. -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > [HK] Yes 16 bits might be insufficient for this. However, I could > combine LFB Type (16 bits, including version no), Operation (8 bits), > Flags (8 Bits) into a 32-bit field. Does that sound good ? Let me know >From your comments to Weiming i now understand the meaning of type. 16 bits is a little too much for that. So having it as: TYPE :=3D ATTR_TYPE(4 bits max): VERSION (4 bits): OPERATION(8 bits) i think should suffice. [HK] I think Version for LFB is valuable. Is that what you mean by Version ? Regarding having this as part of Type, I have sent an email describing the design principle for Type in TLV that I have used, let me know what you think about that ? Also: I dont think it would make much of a difference whether the T in TLV is global or per message. Infact on second thought I think that it may make sense to have it as local as proposed by Weiming since it gives us more room. [HK] I agree that having local scope will give more room. Anyways my email on TLV will describe my reasoning better. Let me know if that makes sense to you ? regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 22:57:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24140 for ; Mon, 17 May 2004 22:57: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 1BPuhq-0005Nl-Eg for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:51:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I2povP020685 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPue0-0003uM-VM for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 22:47: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 WAA23415 for ; Mon, 17 May 2004 22:47: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 1BPudx-0006nw-JA for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPucq-0006Q3-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:46:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPucB-00062Z-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuaG-0002R9-UO; Mon, 17 May 2004 22:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPuNK-0008Ce-Es for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 22:30: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 WAA22472 for ; Mon, 17 May 2004 22:30: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 1BPuNH-0000Z7-94 for forces-protocol@ietf.org; Mon, 17 May 2004 22:30:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuMH-0000Ar-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:29:34 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPuKt-0007GA-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:28:08 -0400 Received: from wwm1 (unverified [219.82.186.197]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 18 May 2004 10:40:58 +0800 Message-ID: <007b01c43c7f$2b102cd0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E0108D9FC@orsmsx408.jf.intel.com> <40A8E39B.7020809@zurich.ibm.com> Subject: Re: [Forces-protocol] HB msgs ? 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, 18 May 2004 10:23: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.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi all, I quite agree to assess the HB msg. To do this, I think we may need to assess the importance of HB first. My thought is, although HB is a very good mechanism for detecting aliveness of elements, it is only one of the ways for the purpose. I cannot see any reason the HB should be as a MUST item in our protocol. Note that, HB consumes quite a lot resourses, while sometimes customers may prefer to use something like a simple query instead of the HB to see the aliveness of elements, especially when the system is short of resourses. As a result, HB should be able to be started or stopped by our protocol freely, that is, the operation to be able to subscribe/unsubscribe an HB should not be missed in our protocol (I suppose Jamal also proposed this idea). This also means that if we use specific msgs for HBs, we surely need more than two msgs (HB, HB config(including sub/unsub), HB response). One more thing is, HB should be very flexible to use, e.g., its interval should be flexible to be changed on the fly. In this way, system may be able to adjust the interval according to its current resourse state, so as to slow down the HB if the resourse is not enough. Anyway, HB acts more like a supplimentary tool instead as a vital one during the system running. I noticed Jamal and Robert have mentioned the effectiveness for HB msg. Yes, I agree a precise HB format is much better, because number of HB msgs will be huge. After comparing the two possible format, I just found that using a HB event msg for HB may only consume 32bit more and one step more parse, compared with a specific HB msg. Therefore, I still prefer to use HB as event. Cheers, Weiming ----- Original Message ----- From: "Robert Haas" All, We should assess the tradeoff for HB (and potentially other protocol-specific messages) being treated as: a) an Event (of a meta LFB representing the FE), or b) as its own specific Message Type (i.e., in the Common Header). To me, the most important is that: a) has a cleaner unified design: protocol-specific messages such as HB are treated as LFB messages, but b) has a simpler parsing when doing traffic analysis: protocol-specific messages are easier to spot in the flow of LFB messages: no need to look into the body of the message to find out that it is a HB. Anyone has other arguments in favor of one or the other ? Let's then judge which one is more suitable. -Robert Khosravi, Hormuzd M wrote: >Weiming, > >You make a good point. I was just thinking 2 msgs for HB, HB >Resp/Ack...4 msgs will be a bit too much. Anyways I am not religious >about this one, neither is Jamal, I think. We are just stating our >preferences. > >Lets see what Avri prefers. I am fine with whatever the majority >decides. > >Regards >Hormuzd >-----Original Message----- >From: forces-protocol-admin@ietf.org >[mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang > >[Weiming] One more thing we should note is, we have totally only arround 10 >message types for our protocol, to have another 2 to 4 msgs specifically for HB >looks really biased and makes it more or less ugly in the appearance of our >protocol. >I even more prefer to the scheme to treat HB as an LFB (I remember Jamal >mentioned this), than to have separate msgs for them. >[/Weiming] > >I guess the key question that I would ask is if we want Event msg to >symbolize asynchronous events or we want to mix the semantics with >synchronous msgs as well ? I think keeping the 2 separate is cleaner, >but I am open to other views as well. >[Weiming] I don't think we may need to distinguish semantically the syn. and >asyn. msgs in our protocol, because they have no principal difference in our >scope. We can say an event notification is asyncronous, but we can also say any >query or config from CE to FE is also asyncronous. Actually I just think it >makes little sense to distinguish them. > >Avri, could you share your opinion on this ? > > > >_______________________________________________ >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 _______________________________________________ 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 May 17 22:58: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 WAA24260 for ; Mon, 17 May 2004 22:58: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 1BPumr-0006SJ-8d for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I2v1gl024810 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22: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 1BPuhs-0005Ok-Nn for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 22:51: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 WAA23630 for ; Mon, 17 May 2004 22:51: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 1BPuhp-0000bz-9l for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:51:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPugn-0000Cq-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:50:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPug5-0007bW-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPubI-0003AT-V3; Mon, 17 May 2004 22: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 1BPuT6-00006C-KY for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 22: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 WAA22814 for ; Mon, 17 May 2004 22: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 1BPuT3-0002md-7u for forces-protocol@ietf.org; Mon, 17 May 2004 22:36:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuS6-0002Qh-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:35:35 -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 1BPuRN-00025R-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:34:49 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051719385689:6762 ; Mon, 17 May 2004 19:38:56 -0700 Subject: Re: More summary WAS(RE: [Forces-protocol] topic 4c: Common Header:batching From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Weiming Wang Cc: forces-protocol@ietf.org In-Reply-To: <009301c43c15$cb5c7370$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E01013A97@orsmsx408.jf.intel.com> <1084458947.1022.37.camel@jzny.localdomain> <009301c43c15$cb5c7370$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1084847684.1038.287.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 05/17/2004 07:38:57 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/17/2004 07:39:02 PM, Serialize complete at 05/17/2004 07:39:02 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: 17 May 2004 22:34: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 Weiming, On Mon, 2004-05-17 at 09:49, Weiming Wang wrote: [Deleted above because discussion below covers it] > > Lets pick an example to > > clarify: > > > > A config PL msg with "route-add A B,C:route-del X" operations > > > > CASE I: decide that they both need to go together in which case an > > atomic flag in the main header with the sequence number should suffice > > to provide the semantics. > > > [Weiming]When using above proposal, we just put the ops of 'route-add A,B,C' and > 'route-del X' in only one msg, while without any other flags to indicate the > transaction. That would work if you want to define everything in one message is always atomic i.e from above example route-add and route-del have all or none relationship. > > > CASE II: decide are independent atomic config operations in which case i > > can put the atomic flag for route-add of A,B,C and another one for X in > > their respective operation headers. > [Weiming]We may just use two msgs with two transactions, one for 'route-add > A,B,C' and one for 'route-del X', still without any flags to indicate the > transactions. This would also work with a caveat: your goodput may not be good. Example in the case of route-del being a separate message the overhead of the common header + TL and some of the common fileds in the V will be much higher than the route-del itself. > [Weiming]My thinking of the case above is to use two msgs for the ops, then we > can have separate responses for the msgs. > Actually I'm not very sure if I have cought what you mean or not? If you mean > the 'route-add A,B,C' are three ops that are put in three different msgs, I meant they could be aggragated in one message. > then > my scheme is as follows: > > First, pls let me explain the flags I used again: > > Atomic flag: 1 - indicating the begin or middle of the atomicity(transaction) > 0 - indicating the end and the execution of the atomicity > Atomic counter: to inidicate which transactions the msg belongs in a concurrent > transaction case. (a 4 bit counter can support 16 concurrent transactions). > > Then my scheme is as follows: > > mark 4 msgs as: msg(add A), msg(add B), msg(add C), msg(del X) > set atomic flag as: 1 1 0 0 > set AtomCounter as: 1 1 1 2 > (that means the msg(add A), msg(add B), msg(add C) belongs to the #1 concurrent > transaction, while msg (del X) belongs to #2 concurrent transaction) What i see is a need to a subseqeunce number (what you call atomic counter) per TLV. In such a case if you can fit routes A, B, and C in one message (example array of routes) then it becomes an all or nothing operation. i.e. they either all get added or all fail. You could then have a del-route as a separate TLV with its own counter. You probably need startatomic and endatomic to make this work. Also, as i mentioned earlier we should be able to use atomicstart/end on either the whole message (which means all in the message is atomic) or on a per TLV. On failure or success each atomic message should probably get its own ack/nack with proper sequence number. In other words, you may get several messages with the same sequence number. Not sure if i am clear. > After above setup, the 4 msgs can be sent to FE in any order, e.g., msg(add > A):msg(add B):msg(del X):msg(add C), or msg(add A):msg(del X):msg(add B):msg(add > C). If you want to split them the counter should still apply - although i think that each PDU should have its own unique seq number. > We can further use a Batch flag to let above msg chains batchingly transmitted > to FE. At the FE side, by using the atomic flag and the Atomic counter, we can > easily recover the transactions. Consider the atomic start/end flags. > There may be only two responses for above 4 msgs (with 2 transactions), one for > msg(add C), one for msg(del X), but note that we should carefully define the > response msg format so that the response to a transaction end msg like the > msg(add C) should be able to include all information about the transaction. I > think something like a TLVforSummaryResponse in the end of the response msg can > do this well. Refer to what i said earlier above. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 22:59:02 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24352 for ; Mon, 17 May 2004 22:59: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 1BPun0-0006UZ-6O for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22:57:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I2vAG1024949 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 22: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 1BPui5-0005QH-Ng for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 22:52: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 WAA23662 for ; Mon, 17 May 2004 22:52: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 1BPui2-0000dp-8Y for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:52:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuh6-0000F6-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:51:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPugN-0007dc-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 22:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPucD-0003b4-Qb; Mon, 17 May 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 1BPuXt-0000ix-HL for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 22:41: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 WAA23028 for ; Mon, 17 May 2004 22:41: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 1BPuXq-0004XW-2w for forces-protocol@ietf.org; Mon, 17 May 2004 22:41:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPuWs-0004CE-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:40: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 1BPuVy-0003Vf-00 for forces-protocol@ietf.org; Mon, 17 May 2004 22:39:34 -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 i4I2cI5a021782; Tue, 18 May 2004 02:38:18 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 i4I2diaw015238; Tue, 18 May 2004 02:39:45 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 M2004051719390429589 ; Mon, 17 May 2004 19:39:04 -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, 17 May 2004 19:39:04 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43C81.48A16F59" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] T in TLV, another thought Message-ID: <468F3FDA28AA87429AD807992E22D07E01109279@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV, another thought Thread-Index: AcQ8fohMl+sO/r4IRVyAdlTIsP1W8wAAJjfQ From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 18 May 2004 02:39:04.0242 (UTC) FILETIME=[48C34120:01C43C81] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 17 May 2004 19:39:04 -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_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43C81.48A16F59 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Weiming, =20 Thanks a lot for the prompt response! Pls see my clarification below. -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Weiming Wang Thanks for the comments on the Global vs local scope for T in TLV. =20 Another design principle that I would like to share and get your thoughts on is... How do we choose semantics for T ? The basic principle is that a different T should mean a different V, essentially T defines V. To give you an example... in the Config message format that I had sent out, I used T to mean either FE or LFB attributes. This is cause I see the V in case of T=3DLAB attributes having fields = such as LAB Type, LAB Instance ID. In case T=3DFE attributes, we probably = wont have these 2 fields. Does that help understand the logic for defining T ? [Weiming] I think I (Jamal as well) have already presented the idea on the Value format difference of LFB attribute/event and FE attribute/event (in my emal on event msg format and also in the reply to your emal). I just think only mentioning the FE or LFB in T is not enough to have global meaning, e.g., LFB query and LFB config may have quite different PDU format. =20 =20 [HK] Sure I agree. It seems like you have misunderstood. When I say global scope, e.g., T=3D0x32 might mean LFB attr type TLV for Query msg (i.e. LFB Query acc to your terminology) and T=3D0x28 might mean LFB = attr type for Config msg (i.e. LFB Config acc to your terminology) and both these will define different types of TLV (or PDU) i.e. different fields in the V for the TLV. So the 16 bits for T will be used to globally define different TLVs across all different msgs. =20 Hope that helps clarify my idea, anyways we can discuss this further on the call tomorrow (hope you will attend) =20 Thanks again Hormuzd =20 p.s. To further clarify, it would make sense to have Operation (Add, Del, etc) part of T if we would define different TLV or PDU for different Operations. I don't think that is the case, but do you think the PDU will be different for each Operation ?? =20 ------_=_NextPart_001_01C43C81.48A16F59 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Weiming,
 
Thanks=20 a lot for the prompt response! Pls see my clarification=20 below.
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On=20 Behalf Of Weiming Wang
Thanks for the=20 comments on the Global vs local scope for T in = TLV.
 
Another design=20 principle that I would like to share and get your thoughts on=20 is...
How do we choose=20 semantics for T ? The basic principle is that a different = T should=20 mean a different V, essentially T defines V.
To = give you an=20 example... in the Config message format that I had sent out, I used = T to=20 mean either FE or LFB attributes.
This is cause I=20 see the V in case of T=3DLAB attributes having fields such as LAB = Type, LAB=20 Instance ID. In case T=3DFE attributes, we probably wont have these = 2 fields.=20 Does that help understand the logic for defining=20 T ?
[Weiming]=20 I think I (Jamal as well) have already presented the idea on = the Value=20 format difference of LFB attribute/event and FE attribute/event (in = my emal=20 on event msg format and also in the reply to your emal). I just = think only=20 mentioning the FE or LFB in T is not enough to have global = meaning,=20 e.g., LFB query and LFB config may have quite different PDU=20 format.  
 
[HK] Sure I agree. = It seems=20 like you have misunderstood. When I say global = scope, e.g.,=20 T=3D0x32 might mean LFB attr type TLV for Query msg (i.e. = LFB Query=20 acc to your terminology) and T=3D0x28 might mean LFB attr type for = Config msg=20 (i.e. LFB Config acc to your terminology) and both these will define = different types of TLV (or PDU) i.e. different fields in the V for = the TLV.=20 So the 16 bits for T will be used to globally define different=20 TLVs across all different=20 msgs.
 
Hope that helps clarify my = idea,
anyways we can discuss = this further on=20 the call tomorrow (hope you will = attend)
 
Thanks=20 again
Hormuzd
 
p.s. To further clarify, = it would make=20 sense to have Operation (Add, Del, etc) part of T if we would define = different TLV or PDU for different Operations. I don't think that is = the=20 case, but do you think the PDU will be different for each Operation=20 ??
 
------_=_NextPart_001_01C43C81.48A16F59-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 17 23:37:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26356 for ; Mon, 17 May 2004 23:37: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 1BPvKX-0007Jy-Nv for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 23:32:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I3VntG028143 for forces-protocol-archive@odin.ietf.org; Mon, 17 May 2004 23:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvH3-0006Jl-5p for forces-protocol-web-archive@optimus.ietf.org; Mon, 17 May 2004 23:28: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 XAA25812 for ; Mon, 17 May 2004 23:28: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 1BPvH1-0005hV-8M for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 23:28:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPvGB-0005Hw-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 23:27:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPvF5-0004qY-00 for forces-protocol-web-archive@ietf.org; Mon, 17 May 2004 23:26:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvDx-0005jQ-Nm; Mon, 17 May 2004 23:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPvBZ-0004ic-TE for forces-protocol@optimus.ietf.org; Mon, 17 May 2004 23:22: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 XAA25431 for ; Mon, 17 May 2004 23:22: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 1BPvBX-0003a9-VV for forces-protocol@ietf.org; Mon, 17 May 2004 23:22:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPvAZ-0003B0-00 for forces-protocol@ietf.org; Mon, 17 May 2004 23:21:32 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BPv95-0002L3-00 for forces-protocol@ietf.org; Mon, 17 May 2004 23:20:00 -0400 Received: from wwm1 (unverified [219.82.186.197]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Tue, 18 May 2004 11:32:42 +0800 Message-ID: <00af01c43c86$652c41e0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E01109279@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] T in TLV, another thought MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C43CC9.728999D0" 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, 18 May 2004 11:15: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=2.0 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_00AC_01C43CC9.728999D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEhvcm11emQsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXNzaWZpY2F0aW9uLg0K DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6 ZCBNIA0KDQogIEhpIFdlaW1pbmcsDQoNCiAgVGhhbmtzIGEgbG90IGZvciB0aGUgcHJvbXB0IHJl c3BvbnNlISBQbHMgc2VlIG15IGNsYXJpZmljYXRpb24gYmVsb3cuDQogICAgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBmb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmcg W21haWx0bzpmb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXZWlt aW5nIFdhbmcNCg0KICAgICAgVGhhbmtzIGZvciB0aGUgY29tbWVudHMgb24gdGhlIEdsb2JhbCB2 cyBsb2NhbCBzY29wZSBmb3IgVCBpbiBUTFYuDQoNCiAgICAgIEFub3RoZXIgZGVzaWduIHByaW5j aXBsZSB0aGF0IEkgd291bGQgbGlrZSB0byBzaGFyZSBhbmQgZ2V0IHlvdXIgdGhvdWdodHMgb24g aXMuLi4NCiAgICAgIEhvdyBkbyB3ZSBjaG9vc2Ugc2VtYW50aWNzIGZvciBUID8gVGhlIGJhc2lj IHByaW5jaXBsZSBpcyB0aGF0IGEgZGlmZmVyZW50IFQgc2hvdWxkIG1lYW4gYSBkaWZmZXJlbnQg ViwgZXNzZW50aWFsbHkgVCBkZWZpbmVzIFYuDQogICAgICBUbyBnaXZlIHlvdSBhbiBleGFtcGxl Li4uIGluIHRoZSBDb25maWcgbWVzc2FnZSBmb3JtYXQgdGhhdCBJIGhhZCBzZW50IG91dCwgSSB1 c2VkIFQgdG8gbWVhbiBlaXRoZXIgRkUgb3IgTEZCIGF0dHJpYnV0ZXMuDQogICAgICBUaGlzIGlz IGNhdXNlIEkgc2VlIHRoZSBWIGluIGNhc2Ugb2YgVD1MQUIgYXR0cmlidXRlcyBoYXZpbmcgZmll bGRzIHN1Y2ggYXMgTEFCIFR5cGUsIExBQiBJbnN0YW5jZSBJRC4gSW4gY2FzZSBUPUZFIGF0dHJp YnV0ZXMsIHdlIHByb2JhYmx5IHdvbnQgaGF2ZSB0aGVzZSAyIGZpZWxkcy4gRG9lcyB0aGF0IGhl bHAgdW5kZXJzdGFuZCB0aGUgbG9naWMgZm9yIGRlZmluaW5nIFQgPw0KICAgICAgW1dlaW1pbmdd IEkgdGhpbmsgSSAoSmFtYWwgYXMgd2VsbCkgaGF2ZSBhbHJlYWR5IHByZXNlbnRlZCB0aGUgaWRl YSBvbiB0aGUgVmFsdWUgZm9ybWF0IGRpZmZlcmVuY2Ugb2YgTEZCIGF0dHJpYnV0ZS9ldmVudCBh bmQgRkUgYXR0cmlidXRlL2V2ZW50IChpbiBteSBlbWFsIG9uIGV2ZW50IG1zZyBmb3JtYXQgYW5k IGFsc28gaW4gdGhlIHJlcGx5IHRvIHlvdXIgZW1hbCkuIEkganVzdCB0aGluayBvbmx5IG1lbnRp b25pbmcgdGhlIEZFIG9yIExGQiBpbiBUIGlzIG5vdCBlbm91Z2ggdG8gaGF2ZSBnbG9iYWwgbWVh bmluZywgZS5nLiwgTEZCIHF1ZXJ5IGFuZCBMRkIgY29uZmlnIG1heSBoYXZlIHF1aXRlIGRpZmZl cmVudCBQRFUgZm9ybWF0LiAgDQoNCiAgICAgIFtIS10gU3VyZSBJIGFncmVlLiBJdCBzZWVtcyBs aWtlIHlvdSBoYXZlIG1pc3VuZGVyc3Rvb2QuIFdoZW4gSSBzYXkgZ2xvYmFsIHNjb3BlLCBlLmcu LCBUPTB4MzIgbWlnaHQgbWVhbiBMRkIgYXR0ciB0eXBlIFRMViBmb3IgUXVlcnkgbXNnIChpLmUu IExGQiBRdWVyeSBhY2MgdG8geW91ciB0ZXJtaW5vbG9neSkgYW5kIFQ9MHgyOCBtaWdodCBtZWFu IExGQiBhdHRyIHR5cGUgZm9yIENvbmZpZyBtc2cgKGkuZS4gTEZCIENvbmZpZyBhY2MgdG8geW91 ciB0ZXJtaW5vbG9neSkgYW5kIGJvdGggdGhlc2Ugd2lsbCBkZWZpbmUgZGlmZmVyZW50IHR5cGVz IG9mIFRMViAob3IgUERVKSBpLmUuIGRpZmZlcmVudCBmaWVsZHMgaW4gdGhlIFYgZm9yIHRoZSBU TFYuIFNvIHRoZSAxNiBiaXRzIGZvciBUIHdpbGwgYmUgdXNlZCB0byBnbG9iYWxseSBkZWZpbmUg ZGlmZmVyZW50IFRMVnMgYWNyb3NzIGFsbCBkaWZmZXJlbnQgbXNncy4NCiAgICAgIFtXZWltaW5n XU15IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBUIHNjaGVtZSBpcywgeW91IGhhdmUgY29uZGVuc2Vk ICB0aGUgb3BlcmF0aW9ucyBhcyB0aGluZ3MgbGlrZSAncXVlcnknICdjb25maWcnLCBldGMuIEkn bSBqdXN0IGEgbGl0dGxlIGFmcmFpZCBpdCBpcyBub3QgZW5vdWdoLiBQbHMgc2VlIG1vcmUgaW4g bXkgZm9sbG93aW5nIHJlcGx5Lg0KDQogICAgICBIb3BlIHRoYXQgaGVscHMgY2xhcmlmeSBteSBp ZGVhLA0KICAgICAgYW55d2F5cyB3ZSBjYW4gZGlzY3VzcyB0aGlzIGZ1cnRoZXIgb24gdGhlIGNh bGwgdG9tb3Jyb3cgKGhvcGUgeW91IHdpbGwgYXR0ZW5kKQ0KDQogICAgICBUaGFua3MgYWdhaW4N CiAgICAgIEhvcm11emQNCg0KICAgICAgcC5zLiBUbyBmdXJ0aGVyIGNsYXJpZnksIGl0IHdvdWxk IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBPcGVyYXRpb24gKEFkZCwgRGVsLCBldGMpIHBhcnQgb2YgVCBp ZiB3ZSB3b3VsZCBkZWZpbmUgZGlmZmVyZW50IFRMViBvciBQRFUgZm9yIGRpZmZlcmVudCBPcGVy YXRpb25zLiBJIGRvbid0IHRoaW5rIHRoYXQgaXMgdGhlIGNhc2UsIGJ1dCBkbyB5b3UgdGhpbmsg dGhlIFBEVSB3aWxsIGJlIGRpZmZlcmVudCBmb3IgZWFjaCBPcGVyYXRpb24gPz8NCiAgICAgIFtX ZWltaW5nXVllcywgdGhlIFBEVSBmb3IgZGlmZmVyZW50IG9wcyB3aWxsIGJlIHF1aXRlIGRpZmZl cmVudC4gRS5nLiwgdG8gYWRkIGEgcm91dGUsIHdlIG5lZWQgdG8gdGVsbCB0aGUgcm91dGUgdmFs dWUsIHRvIHVwZGF0ZSBhIHJvdXRlLCB3ZSBuZWVkIHRvIGtub3cgdGhlIG9sZCByb3V0ZSB2YWx1 ZSBhbmQgdG8gdGVsbCB0aGUgbmV3IHZhbHVlLiBGb3IgZXZlbnQgbXNncywgdGhlIFBEVSBmb3Ig ZGlmZmVyZW50IGV2ZW50IG9wcyBhcmUgYWxzbyBxdWl0ZSBkaWZmZXJlbnQsIGUuZy4sIHN1Yi91 bnN1YiBkaWZmZXIgZXZlbnQgbm90aWZpY2F0aW9uIGZvcm1hdC4NCg0KICAgICAgVGhhbmsgeW91 Lg0KICAgICAgV2VpbWluZw0KDQo= ------=_NextPart_000_00AC_01C43CC9.728999D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI4MDAuMTI3NiIgbmFtZT1HRU5FUkFUT1I+DQo8 U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaSBIb3JtdXpkLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+VGhhbmsgeW91IGZv ciB0aGUgY2xhc3NpZmljYXRpb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFE RElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBm b250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1ob3JtdXpkLm0ua2hv c3JhdmlAaW50ZWwuY29tIA0KICBocmVmPSJtYWlsdG86aG9ybXV6ZC5tLmtob3NyYXZpQGludGVs LmNvbSI+S2hvc3JhdmksIEhvcm11emQgTTwvQT4gPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+ DQogIDxESVY+PFNQQU4gY2xhc3M9ODE4MzgyMzAyLTE4MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiBzaXplPTI+SGkgDQogIFdlaW1pbmcsPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgPERJVj48U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJ Vj48U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICBzaXplPTI+VGhhbmtzIGEgbG90IGZvciB0aGUgcHJvbXB0IHJlc3BvbnNlISBQ bHMgc2VlIG15IGNsYXJpZmljYXRpb24gDQogIGJlbG93LjwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElW PjwvRElWPg0KICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBk aXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgDQogICAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiA8QSANCiAgICBocmVmPSJtYWlsdG86 Zm9yY2VzLXByb3RvY29sLWFkbWluQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2wtYWRtaW5AaWV0 Zi5vcmc8L0E+IA0KICAgIFttYWlsdG86Zm9yY2VzLXByb3RvY29sLWFkbWluQGlldGYub3JnXSA8 Qj5PbiBCZWhhbGYgT2YgPC9CPldlaW1pbmcgDQogICAgV2FuZzxCUj48L0ZPTlQ+PC9ESVY+DQog ICAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQ QURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND5UaGFua3MgZm9yIHRoZSAN CiAgICAgIGNvbW1lbnRzIG9uIHRoZSBHbG9iYWwgdnMgbG9jYWwgc2NvcGUgZm9yIFQgaW4gVExW LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIA0KICAgICAgY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNz PTU0NDE1MTIwMS0xODA1MjAwND5Bbm90aGVyIGRlc2lnbiANCiAgICAgIHByaW5jaXBsZSB0aGF0 IEkgd291bGQgbGlrZSB0byBzaGFyZSBhbmQgZ2V0IHlvdXIgdGhvdWdodHMgb24gDQogICAgICBp cy4uLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND5Ib3cgZG8gd2UgDQogICAgICBjaG9v c2Ugc2VtYW50aWNzJm5ic3A7Zm9yJm5ic3A7VCA/IFRoZSBiYXNpYyBwcmluY2lwbGUgaXMgdGhh dCBhIGRpZmZlcmVudCANCiAgICAgIFQgc2hvdWxkIG1lYW4gYSBkaWZmZXJlbnQgViwgZXNzZW50 aWFsbHkgVCBkZWZpbmVzIFYuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PlRvIGdpdmUg eW91IGFuIA0KICAgICAgZXhhbXBsZS4uLiBpbiB0aGUgQ29uZmlnIG1lc3NhZ2UgZm9ybWF0IHRo YXQgSSBoYWQgc2VudCBvdXQsIEkgdXNlZCBUIHRvIA0KICAgICAgbWVhbiBlaXRoZXIgRkUgb3Ig TEZCIGF0dHJpYnV0ZXMuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PlRoaXMgaXMgY2F1 c2UgDQogICAgICBJIHNlZSB0aGUgViBpbiBjYXNlIG9mIFQ9TEFCIGF0dHJpYnV0ZXMgaGF2aW5n IGZpZWxkcyBzdWNoIGFzIExBQiBUeXBlLCANCiAgICAgIExBQiBJbnN0YW5jZSBJRC4gSW4gY2Fz ZSBUPUZFIGF0dHJpYnV0ZXMsIHdlIHByb2JhYmx5IHdvbnQgaGF2ZSB0aGVzZSAyIA0KICAgICAg ZmllbGRzLiBEb2VzIHRoYXQgaGVscCB1bmRlcnN0YW5kIHRoZSBsb2dpYyBmb3IgZGVmaW5pbmcg DQogICAgICBUJm5ic3A7PzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNs YXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgc2l6 ZT0yPltXZWltaW5nXSBJIHRoaW5rIEkgKEphbWFsIGFzIHdlbGwpIGhhdmUgYWxyZWFkeSBwcmVz ZW50ZWQmbmJzcDt0aGUgDQogICAgICBpZGVhIG9uIHRoZSBWYWx1ZSBmb3JtYXQgZGlmZmVyZW5j ZSBvZiBMRkIgYXR0cmlidXRlL2V2ZW50IGFuZCBGRSANCiAgICAgIGF0dHJpYnV0ZS9ldmVudCAo aW4gbXkgZW1hbCBvbiBldmVudCBtc2cgZm9ybWF0IGFuZCBhbHNvIGluIHRoZSByZXBseSB0byAN CiAgICAgIHlvdXIgZW1hbCkuIEkganVzdCB0aGluayBvbmx5IG1lbnRpb25pbmcgdGhlIEZFIG9y IExGQiBpbiBUIGlzIG5vdCBlbm91Z2ggDQogICAgICB0byBoYXZlJm5ic3A7Z2xvYmFsIG1lYW5p bmcsIGUuZy4sIExGQiBxdWVyeSZuYnNwO2FuZCBMRkIgY29uZmlnIG1heSBoYXZlIA0KICAgICAg cXVpdGUgZGlmZmVyZW50IFBEVSBmb3JtYXQuJm5ic3A7PFNQQU4gY2xhc3M9ODE4MzgyMzAyLTE4 MDUyMDA0PjxGT05UIA0KICAgICAgY29sb3I9IzAwMDBmZj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv Rk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEy MDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgICBj bGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQg ZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgICBjbGFzcz04MTgzODIzMDItMTgw NTIwMDQ+PEZPTlQgY29sb3I9IzAwMDBmZj5bSEtdIFN1cmUgSSBhZ3JlZS4gSXQgc2VlbXMgDQog ICAgICBsaWtlIHlvdSBoYXZlIG1pc3VuZGVyc3Rvb2QuIFdoZW4gSSBzYXkmbmJzcDtnbG9iYWwg c2NvcGUsJm5ic3A7ZS5nLiwgDQogICAgICBUPTB4MzImbmJzcDttaWdodCBtZWFuJm5ic3A7TEZC IGF0dHIgdHlwZSBUTFYgZm9yIFF1ZXJ5IG1zZyAoaS5lLiBMRkIgDQogICAgICBRdWVyeSBhY2Mg dG8geW91ciB0ZXJtaW5vbG9neSkgYW5kIFQ9MHgyOCBtaWdodCBtZWFuIExGQiBhdHRyIHR5cGUg Zm9yIA0KICAgICAgQ29uZmlnIG1zZyAoaS5lLiBMRkIgQ29uZmlnIGFjYyB0byB5b3VyIHRlcm1p bm9sb2d5KSBhbmQgYm90aCB0aGVzZSB3aWxsIA0KICAgICAgZGVmaW5lIGRpZmZlcmVudCB0eXBl cyBvZiBUTFYgKG9yIFBEVSkgaS5lLiBkaWZmZXJlbnQgZmllbGRzIGluIHRoZSBWIGZvciANCiAg ICAgIHRoZSBUTFYuIFNvIHRoZSAxNiBiaXRzIGZvciBUIHdpbGwgYmUgdXNlZCB0byBnbG9iYWxs eSBkZWZpbmUgZGlmZmVyZW50IA0KICAgICAgVExWcyZuYnNwO2Fjcm9zcyBhbGwgZGlmZmVyZW50 IA0KICAgICAgbXNncy48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0K ICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1Bcmlh bD48Rk9OVCBjb2xvcj0jZmYwMDAwIA0KICAgICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4MjMw Mi0xODA1MjAwND5bV2VpbWluZ11NeSB1bmRlcnN0YW5kaW5nIG9mIHlvdXIgVCANCiAgICAgIHNj aGVtZSBpcywgeW91IGhhdmUmbmJzcDtjb25kZW5zZWQgJm5ic3A7dGhlIG9wZXJhdGlvbnMgYXMg dGhpbmdzIGxpa2UgDQogICAgICAncXVlcnknICdjb25maWcnLCBldGMuIEknbSBqdXN0IGEgbGl0 dGxlIGFmcmFpZCBpdCBpcyBub3QgZW5vdWdoLiBQbHMgc2VlIA0KICAgICAgbW9yZSBpbiBteSBm b2xsb3dpbmcgcmVwbHkuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAg PERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9O VCBjb2xvcj0jZmYwMDAwIA0KICAgICAgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9ODE4Mzgy MzAyLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAg ICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj48U1BBTiBjbGFzcz04MTgzODIzMDIt MTgwNTIwMDQ+SG9wZSB0aGF0IGhlbHBzIGNsYXJpZnkgbXkgDQogICAgICBpZGVhLDwvU1BBTj48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUx MjAxLTE4MDUyMDA0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgICAg IHNpemU9Mj48U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+YW55d2F5cyB3ZSBjYW4gZGlz Y3VzcyB0aGlzIGZ1cnRoZXIgDQogICAgICBvbiB0aGUgY2FsbCB0b21vcnJvdyAoaG9wZSB5b3Ug d2lsbCANCiAgICAgIGF0dGVuZCk8L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQog ICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFs PjxGT05UIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXplPTI+PFNQQU4gDQogICAgICBjbGFzcz04 MTgzODIzMDItMTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElW Pg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1B cmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4 MjMwMi0xODA1MjAwND5UaGFua3MgDQogICAgICBhZ2FpbjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj48U1BBTiAN CiAgICAgIGNsYXNzPTgxODM4MjMwMi0xODA1MjAwND5Ib3JtdXpkPC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIw MDQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPjxT UEFOIA0KICAgICAgY2xhc3M9ODE4MzgyMzAyLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4 MDUyMDA0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9 Mj48U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+cC5zLiBUbyBmdXJ0aGVyIGNsYXJpZnks IGl0IHdvdWxkIA0KICAgICAgbWFrZSBzZW5zZSB0byBoYXZlIE9wZXJhdGlvbiAoQWRkLCBEZWws IGV0YykgcGFydCBvZiBUIGlmIHdlIHdvdWxkIGRlZmluZSANCiAgICAgIGRpZmZlcmVudCBUTFYg b3IgUERVIGZvciBkaWZmZXJlbnQgT3BlcmF0aW9ucy4gSSBkb24ndCB0aGluayB0aGF0IGlzIHRo ZSANCiAgICAgIGNhc2UsIGJ1dCBkbyB5b3UgdGhpbmsgdGhlIFBEVSB3aWxsIGJlIGRpZmZlcmVu dCBmb3IgZWFjaCBPcGVyYXRpb24gDQogICAgICA/PzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxGT05U IGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9I2ZmMDAwMCANCiAgICAgIHNpemU9Mj48U1BBTiBjbGFz cz04MTgzODIzMDItMTgwNTIwMDQ+W1dlaW1pbmddWWVzLCB0aGUgUERVIGZvciBkaWZmZXJlbnQg DQogICAgICBvcHMgd2lsbCBiZSBxdWl0ZSBkaWZmZXJlbnQuIEUuZy4sIHRvIGFkZCBhIHJvdXRl LCB3ZSBuZWVkIHRvIHRlbGwgdGhlIA0KICAgICAgcm91dGUgdmFsdWUsIHRvIHVwZGF0ZSBhIHJv dXRlLCB3ZSBuZWVkIHRvIGtub3cgdGhlIG9sZCByb3V0ZSB2YWx1ZSBhbmQgdG8gDQogICAgICB0 ZWxsIHRoZSBuZXcgdmFsdWUuIEZvciBldmVudCBtc2dzLCB0aGUgUERVIGZvciBkaWZmZXJlbnQg ZXZlbnQgb3BzIGFyZSANCiAgICAgIGFsc28gcXVpdGUgZGlmZmVyZW50LCBlLmcuLCBzdWIvdW5z dWIgZGlmZmVyIGV2ZW50IG5vdGlmaWNhdGlvbiANCiAgICAgIGZvcm1hdC48L1NQQU4+PC9GT05U PjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0x ODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSNmZjAwMDAgDQogICAgICBzaXpl PTI+PFNQQU4gDQogICAgICBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEy MDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgICBj bGFzcz04MTgzODIzMDItMTgwNTIwMDQ+VGhhbmsgeW91LjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9ODE4MzgyMzAy LTE4MDUyMDA0PldlaW1pbmc8L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAg ICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsPjxG T05UIGNvbG9yPSNmZjAwMDAgDQogICAgICBzaXplPTI+PFNQQU4gDQogICAgICBjbGFzcz04MTgz ODIzMDItMTgwNTIwMDQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K ICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1Bcmlh bD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9 ODE4MzgyMzAyLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00AC_01C43CC9.728999D0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 04:29:58 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 EAA23628 for ; Tue, 18 May 2004 04:29: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 1BPzwI-0002rL-Dj for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 04:27:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8R6A2010992 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 04:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzu8-0002GB-3U for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 04:24: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 EAA23448 for ; Tue, 18 May 2004 04:24: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 1BPzu5-0003Ej-Ay for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:24:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPztB-0002rB-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:23:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzsA-0002Sr-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:22:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPznW-0000xB-44; Tue, 18 May 2004 04:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzlb-0000aw-Fe for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 04:16: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 EAA22865 for ; Tue, 18 May 2004 04:16:01 -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 1BPzlY-0007IS-NV for forces-protocol@ietf.org; Tue, 18 May 2004 04:16:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzkT-0006pf-00 for forces-protocol@ietf.org; Tue, 18 May 2004 04:14:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BPzjO-0005iB-00 for forces-protocol@ietf.org; Tue, 18 May 2004 04:13:46 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPzih-0000dp-Nu for forces-protocol@ietf.org; Tue, 18 May 2004 08:13:03 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01109258@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01109258@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2DA49D8D-A8A3-11D8-A757-000393CC2112@acm.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Forces-protocol] T in TLV, another thought To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.613) 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, 18 May 2004 10:13:00 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In general I agree with the principle that the type (T) defines the=20 value (V). The only exception I might favor is that we talk about=20 TfLV, where the f is a standard small set of flags that indicates some=20= general properties about how the tlv is handled. this is not to say=20 the the TLV cannot also have an specific set of flags inside the V. a. On 18 maj 2004, at 03.20, Khosravi, Hormuzd M wrote: > Hi Team > =A0 > Thanks for the comments on the Global vs local scope for T in TLV. > =A0 > Another design principle that I would like to share and get your=20 > thoughts on is... > How do we choose semantics=A0for=A0T ? The basic principle is that a=20= > different T should mean a different V, essentially T defines V. > To give you an example... in the Config message format that I had sent=20= > out, I used T to mean either FE or LFB attributes. > This is cause I see the V in case of T=3DLAB attributes having fields=20= > such as LAB Type, LAB Instance ID. In case T=3DFE attributes, we=20 > probably wont have these 2 fields. Does that help understand the logic=20= > for defining T=A0? > =A0 > Do you guys think this is a good design principle ? > =A0 > Let me know, > =A0 > Thanks > Hormuzd > =A0 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 04:30:28 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 EAA23676 for ; Tue, 18 May 2004 04:30: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 1BPzwI-0002rf-L9 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 04:27:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I8R6HC011006 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 04:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzuA-0002JG-VN for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 04:24: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 EAA23451 for ; Tue, 18 May 2004 04:24: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 1BPzu8-0003FB-6w for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:24:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPztG-0002rk-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:23:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPzsP-0002U2-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 04:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPznW-0000xI-PA; Tue, 18 May 2004 04:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzm5-0000cS-RV for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 04:16: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 EAA22960 for ; Tue, 18 May 2004 04:16:31 -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 1BPzm3-0007MS-4I for forces-protocol@ietf.org; Tue, 18 May 2004 04:16:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzks-0006t4-00 for forces-protocol@ietf.org; Tue, 18 May 2004 04:15:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BPzjp-0006Rv-00 for forces-protocol@ietf.org; Tue, 18 May 2004 04:14:14 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPzjq-0000qg-UW for forces-protocol@ietf.org; Tue, 18 May 2004 08:14:15 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01108C10@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E01108C10@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58425B88-A8A3-11D8-A757-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Conference Call on Tuesday (May 18) 7 AM PST -details below 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, 18 May 2004 10:14:12 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Assuming my SIP phone is working correctly (it does as of this moment, but line noise sometimes makes it stop working properly) I will be there. a. On 17 maj 2004, at 20.42, Khosravi, Hormuzd M wrote: > Here are the details for the conference call.. > > Start: May 18, 2004 07:00 Pacific Time > End: May 18, 2004 09:00 Pacific Time > Phone Number: 916-356-2663 > Reservation #: 2 > Passcode: 5889108 > > Hope to chat with all of you tomorrow, > > 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 May 18 08:59:12 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 IAA11702 for ; Tue, 18 May 2004 08:59: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 1BQ49r-0008Sh-BA for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 08:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ICvN4i032521 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 08:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3w1-0003Qi-QG for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 08:43: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 IAA10791 for ; Tue, 18 May 2004 08:43: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 1BQ3w0-00014q-I1 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 08:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3vA-0000hy-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 08:42:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ3uM-0000Kc-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 08:41:22 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQ3uJ-0004o4-5Y for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 08:41:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3oJ-00014k-R0; Tue, 18 May 2004 08:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3Zg-0001n7-Ky for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 08:20: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 IAA08509 for ; Tue, 18 May 2004 08:19: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 1BQ3Zf-0006am-Kp for forces-protocol@ietf.org; Tue, 18 May 2004 08:19:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3Yd-0006BU-00 for forces-protocol@ietf.org; Tue, 18 May 2004 08:18:57 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BQ3XY-0005RF-00 for forces-protocol@ietf.org; Tue, 18 May 2004 08:17:48 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4ICHHAN071928 for ; Tue, 18 May 2004 12:17:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4ICHG9a159842 for ; Tue, 18 May 2004 14:17:16 +0200 Received: from zurich.ibm.com (dhcp222-74.zurich.ibm.com [9.4.222.74]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA47722; Tue, 18 May 2004 14:15:51 +0200 Message-ID: <40A9FE77.8020404@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: Weiming Wang CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] topic 4c: Common Header: batching References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> <40A3FEB6.8050301@zurich.ibm.com> <011101c43c1b$5903eeb0$020aa8c0@wwm1> In-Reply-To: <011101c43c1b$5903eeb0$020aa8c0@wwm1> Content-Type: multipart/alternative; boundary="------------070600090606030007020705" 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, 18 May 2004 14:15: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.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070600090606030007020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i4ICHHAN071928 Content-Transfer-Encoding: quoted-printable Weiming, I'd prefer not to enforce that all commands in the same message must be=20 treated as a single atomic transaction. As Jamal noted, treating a few=20 1000s of commands as a single atomic operation in the FE will require=20 much more resources and more complex processing path. I'd like to be=20 able to treat this 1000s of commands in the same message one after the=20 other, without having to remember the results and cache them until all=20 1000s have succeeded, in case roll-back is needed. My proposal regarding atomicity would hence be: 2 flags, AtomicStart (AS) and AtomicEnd (AE) in the Common Header: if AS=3DAE=3D1: the (multiple) commands in the message must be treated a= s=20 atomic. if AS=3DAE=3D0: the (multiple) commands in the message must be treated a= s a=20 sequence of independent commands. if AS=3D1 and AE=3D0: start of atomic transaction that can span multiple= =20 messages until a message with AS=3D0, AE=3D1, arrives. if AS=3DAE=3D0: either the middle of an atomic transaction, or no atomic= =20 transaction at all. For clarity, a redundant AtomicMiddle (AM) flag=20 could be used. We need to identify implications on batching. Regards, -Robert Weiming Wang wrote: >Hi Avri, > >----- Original Message ----- >From: > =20 > >>On 14 maj 2004, at 01.03, Robert Haas wrote: >> >> =20 >> >>>I finally see a justification for plain batching (that is, batching >>>without atomicity): a batch will result in a single status: >>> =20 >>> >>[ad] Actually I have found that problematic. What i have found is >>that I need a error per command. the overall error indicator can be >>used to indicate that one or more of the commands failed, but each >>command probably needs its own error indicated. >> >> =20 >> >[Weiming] I agreed. I suppose if following scheme can meet the requireme= nt: > >Taking a Config msg with the format as: > > CommonHeader(ConfigType): TLVforOP1:TLVforOP2:...TLVforOPn > >as an example. We may allow two format of ACK/Response. > >Verbose mode - the response is, >CommonHeader(ConfigReType): TLVforReOP1:TLVforReOP2:TLVforReOPn:TLVforRe= SUM. > >Precise mode - the response is, >CommonHeader(ConfigReType): TLVforReSUM > >The TLVforReSUM includes a summary for the transaction excution. > >I also suggest (as in my recent reply to Jamal's summary ans also in the= meeting >minutes), we may better to treat a msg as a transaction, that is, all >ops(commands) inside one msg should have the meaning of 'all or nothing'= , so as >to simplify our protocol definition. Could you give some comments on the >thought? > > =20 > >>>OK if all commands in the batch failed, and notOK if some of them >>>failed (and probably we should stop processing commands after the >>>first failure). >>> =20 >>> >>I think that is a different type of command, the do until error batch. >> >> =20 >> >>>Is this a semantics that would be acceptable to everyone ? >>> =20 >>> >>I guess I don't think so. >> >>a. >> >> =20 >> >Thank you very much. > >BR >Weiming > > > >_______________________________________________ >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 --------------070600090606030007020705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,

I'd prefer not to enforce that all commands in the same message must be treated as a single atomic transaction. As Jamal noted, treating a few 1000s of commands as a single atomic operation in the FE will require much more resources and more complex processing path. I'd like to be able to treat this 1000s of commands in the same message one after the other, without having to remember the results and cache them until all 1000s have succeeded, in case roll-back is needed.

My proposal regarding atomicity would hence be:

 2 flags, AtomicStart (AS) and AtomicEnd (AE) in the Common Header:

 if AS=AE=1: the (multiple) commands in the message must be treated as atomic.

 if AS=AE=0: the (multiple) commands in the message must be treated as a sequence of independent commands.

 if AS=1 and AE=0: start of atomic transaction that can span multiple messages until a message with AS=0, AE=1, arrives.

 if AS=AE=0: either the middle of an atomic transaction, or no atomic transaction at all. For clarity, a redundant  AtomicMiddle (AM) flag could be used.

We need to identify implications on batching.

Regards,
-Robert

Weiming Wang wrote:
Hi Avri,

----- Original Message -----
From: <avri@acm.org>
  
On 14 maj 2004, at 01.03, Robert Haas wrote:

    
I finally see a justification for plain batching (that is, batching
without atomicity): a batch will result in a single status:
      
[ad]  Actually I have found that problematic.  What i have found is
that I need a error per command.  the overall error indicator can be
used to indicate that one or more of the commands failed, but each
command probably needs its own error indicated.

    
[Weiming] I agreed. I suppose if following scheme can meet the requirement:

Taking a Config msg with the format as:

 CommonHeader(ConfigType): TLVforOP1:TLVforOP2:...TLVforOPn

as an example. We may allow two format of ACK/Response.

Verbose mode - the response is,
CommonHeader(ConfigReType): TLVforReOP1:TLVforReOP2:TLVforReOPn:TLVforReSUM.

Precise mode - the response is,
CommonHeader(ConfigReType): TLVforReSUM

The TLVforReSUM includes a summary for the transaction excution.

I also suggest (as in my recent reply to Jamal's summary ans also in the meeting
minutes), we may better to treat a msg as a transaction, that is, all
ops(commands) inside one msg should have the meaning of 'all or nothing', so as
to simplify our protocol definition. Could you give some comments on the
thought?

  
OK if all commands in the batch failed, and notOK if some of them
failed (and probably we should stop processing commands after the
first failure).
      
I think that is a different type of command, the do until error batch.

    
Is this a semantics that would be acceptable to everyone ?
      
I guess I don't think so.

a.

    
Thank you very much.

BR
Weiming



_______________________________________________
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
--------------070600090606030007020705-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 10:51:31 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 KAA20645 for ; Tue, 18 May 2004 10:51: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 1BQ5sa-0007a0-Oe for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 10:48:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEleUw029121 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 10:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5er-0002Oh-QW for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 10:33: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 KAA19203 for ; Tue, 18 May 2004 10:33: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 1BQ5ep-0005ms-GF for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 10:33:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5dh-0005KF-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 10:32:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5cK-0004VD-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 10:30:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Yb-0000TM-DK; Tue, 18 May 2004 10: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 1BQ5ES-0007WR-JS for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 10: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 KAA15853 for ; Tue, 18 May 2004 10:06: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 1BQ5EQ-0002e1-FF for forces-protocol@ietf.org; Tue, 18 May 2004 10:06:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5DI-0002E9-00 for forces-protocol@ietf.org; Tue, 18 May 2004 10:05:01 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BQ5CB-0001T8-00 for forces-protocol@ietf.org; Tue, 18 May 2004 10:03:52 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Tue, 18 May 2004 22:16:25 +0800 Message-ID: <077701c43ce0$df1bf9f0$875c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07EFA191B@orsmsx408.jf.intel.com> <045c01c437cc$1d77c0e0$875c21d2@Necom.hzic.edu.cn> <1084360207.1049.45.camel@jzny.localdomain> <007f01c43822$447665b0$020aa8c0@wwm1> <40A3FEB6.8050301@zurich.ibm.com> <011101c43c1b$5903eeb0$020aa8c0@wwm1> <40A9FE77.8020404@zurich.ibm.com> Subject: Re: [Forces-protocol] topic 4c: Common Header: batching MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0774_01C43D23.ED22B140" 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, 18 May 2004 22:03:18 +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.8 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_0774_01C43D23.ED22B140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpZZXMsIEkgYWxzbyBub3RpY2VkIHRoYXQgdG8gdHJlYXQgYSBtc2cgYXMgb25l IHRyYW5zYWN0aW9uIG1heSBiZSBub3QgZWZmaWNpZW50IGVub3VnaCBmb3IgbXVsaXRwbGUgdGlu eSBpbmRlcGVuZGVudCB0cmFuc2FjdGlvbnMuIEkgc2VlIHRoYXQgeW91ciBzY2hlbWUgaXMgdG8g dHJlYXQgb25lIG1zZyBlaXRoZXIgYXMgb25lIHRyYW5zYWN0aW9uIG9yIGFzIGEgc2VxdWVuY2Ug b2YgaW5kZXBlbmRlbnQgdHJhbnNhY3Rpb25zLiBJIGFncmVlIHdpdGggdGhpcyBzY2hlbWUgd2Vs bCwgYmVjYXVzZSBpdCBpcyBhY3R1YWxseSBzdGlsbCBzaW1wbGUgb25lLCB3aXRoIEkgdGhpbmsg b25seSBvbmUgbW9yZSBiaXQgb2YgZmxhZyB0byBpbmRpY2F0ZSBpdCAoYWxzbyBhcyB0aGUgZmxh Z3MgeW91IG1lbnRpb25lZCkuIE5vdyB3ZSBuZWVkIHRvIGRpc2N1c3MgbW9yZSBpcyBpZiB3ZSBu ZWVkIHRvIHN1cHBvcnQgdGhlIHNjaGVtZSB3aGVyZSB0aGVyZSBhcmUgaW5kZXBlbmRlbnQgdHJh bnNhY3Rpb25zIGFzIHdlbGwgYXMgc2V2ZXJhbCBhdG9taWMgdHJhbnNhY3Rpb25zIGluc2lkZSBv bmUgbXNnLCB3aGljaCBJIHRoaW5rIGlzIGFsc28gd2hhdCBKYW1hbCBtZWFucy4gVGhpcyB0cnVs eSBtYWtlcyB0aGluZ3MgcXVpdGUgY29tcGxleC4gSSdsIGp1c3Qgc3RvcCBoZXJlLiBJIHRoaW5r IHlvdSBhcmUgYWxyZWFkeSBvbiB0aGUgcGhvbmUuDQoNClNlZSB5b3UuDQpXZWltaW5nDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFJvYmVydCBIYWFzIA0KDQogIFdl aW1pbmcsDQoNCiAgSSdkIHByZWZlciBub3QgdG8gZW5mb3JjZSB0aGF0IGFsbCBjb21tYW5kcyBp biB0aGUgc2FtZSBtZXNzYWdlIG11c3QgYmUgdHJlYXRlZCBhcyBhIHNpbmdsZSBhdG9taWMgdHJh bnNhY3Rpb24uIEFzIEphbWFsIG5vdGVkLCB0cmVhdGluZyBhIGZldyAxMDAwcyBvZiBjb21tYW5k cyBhcyBhIHNpbmdsZSBhdG9taWMgb3BlcmF0aW9uIGluIHRoZSBGRSB3aWxsIHJlcXVpcmUgbXVj aCBtb3JlIHJlc291cmNlcyBhbmQgbW9yZSBjb21wbGV4IHByb2Nlc3NpbmcgcGF0aC4gSSdkIGxp a2UgdG8gYmUgYWJsZSB0byB0cmVhdCB0aGlzIDEwMDBzIG9mIGNvbW1hbmRzIGluIHRoZSBzYW1l IG1lc3NhZ2Ugb25lIGFmdGVyIHRoZSBvdGhlciwgd2l0aG91dCBoYXZpbmcgdG8gcmVtZW1iZXIg dGhlIHJlc3VsdHMgYW5kIGNhY2hlIHRoZW0gdW50aWwgYWxsIDEwMDBzIGhhdmUgc3VjY2VlZGVk LCBpbiBjYXNlIHJvbGwtYmFjayBpcyBuZWVkZWQuDQoNCiAgTXkgcHJvcG9zYWwgcmVnYXJkaW5n IGF0b21pY2l0eSB3b3VsZCBoZW5jZSBiZToNCg0KICAgMiBmbGFncywgQXRvbWljU3RhcnQgKEFT KSBhbmQgQXRvbWljRW5kIChBRSkgaW4gdGhlIENvbW1vbiBIZWFkZXI6DQoNCiAgIGlmIEFTPUFF PTE6IHRoZSAobXVsdGlwbGUpIGNvbW1hbmRzIGluIHRoZSBtZXNzYWdlIG11c3QgYmUgdHJlYXRl ZCBhcyBhdG9taWMuDQoNCiAgIGlmIEFTPUFFPTA6IHRoZSAobXVsdGlwbGUpIGNvbW1hbmRzIGlu IHRoZSBtZXNzYWdlIG11c3QgYmUgdHJlYXRlZCBhcyBhIHNlcXVlbmNlIG9mIGluZGVwZW5kZW50 IGNvbW1hbmRzLg0KDQogICBpZiBBUz0xIGFuZCBBRT0wOiBzdGFydCBvZiBhdG9taWMgdHJhbnNh Y3Rpb24gdGhhdCBjYW4gc3BhbiBtdWx0aXBsZSBtZXNzYWdlcyB1bnRpbCBhIG1lc3NhZ2Ugd2l0 aCBBUz0wLCBBRT0xLCBhcnJpdmVzLg0KDQogICBpZiBBUz1BRT0wOiBlaXRoZXIgdGhlIG1pZGRs ZSBvZiBhbiBhdG9taWMgdHJhbnNhY3Rpb24sIG9yIG5vIGF0b21pYyB0cmFuc2FjdGlvbiBhdCBh bGwuIEZvciBjbGFyaXR5LCBhIHJlZHVuZGFudCAgQXRvbWljTWlkZGxlIChBTSkgZmxhZyBjb3Vs ZCBiZSB1c2VkLg0KDQogIFdlIG5lZWQgdG8gaWRlbnRpZnkgaW1wbGljYXRpb25zIG9uIGJhdGNo aW5nLg0KDQogIFJlZ2FyZHMsDQogIC1Sb2JlcnQNCg0KICBXZWltaW5nIFdhbmcgd3JvdGU6DQoN CkhpIEF2cmksDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IDxhdnJpQGFj bS5vcmc+DQogIA0KT24gMTQgbWFqIDIwMDQsIGF0IDAxLjAzLCBSb2JlcnQgSGFhcyB3cm90ZToN Cg0KICAgIA0KSSBmaW5hbGx5IHNlZSBhIGp1c3RpZmljYXRpb24gZm9yIHBsYWluIGJhdGNoaW5n ICh0aGF0IGlzLCBiYXRjaGluZw0Kd2l0aG91dCBhdG9taWNpdHkpOiBhIGJhdGNoIHdpbGwgcmVz dWx0IGluIGEgc2luZ2xlIHN0YXR1czoNCiAgICAgIA0KW2FkXSAgQWN0dWFsbHkgSSBoYXZlIGZv dW5kIHRoYXQgcHJvYmxlbWF0aWMuICBXaGF0IGkgaGF2ZSBmb3VuZCBpcw0KdGhhdCBJIG5lZWQg YSBlcnJvciBwZXIgY29tbWFuZC4gIHRoZSBvdmVyYWxsIGVycm9yIGluZGljYXRvciBjYW4gYmUN CnVzZWQgdG8gaW5kaWNhdGUgdGhhdCBvbmUgb3IgbW9yZSBvZiB0aGUgY29tbWFuZHMgZmFpbGVk LCBidXQgZWFjaA0KY29tbWFuZCBwcm9iYWJseSBuZWVkcyBpdHMgb3duIGVycm9yIGluZGljYXRl ZC4NCg0KICAgIA0KW1dlaW1pbmddIEkgYWdyZWVkLiBJIHN1cHBvc2UgaWYgZm9sbG93aW5nIHNj aGVtZSBjYW4gbWVldCB0aGUgcmVxdWlyZW1lbnQ6DQoNClRha2luZyBhIENvbmZpZyBtc2cgd2l0 aCB0aGUgZm9ybWF0IGFzOg0KDQogQ29tbW9uSGVhZGVyKENvbmZpZ1R5cGUpOiBUTFZmb3JPUDE6 VExWZm9yT1AyOi4uLlRMVmZvck9Qbg0KDQphcyBhbiBleGFtcGxlLiBXZSBtYXkgYWxsb3cgdHdv IGZvcm1hdCBvZiBBQ0svUmVzcG9uc2UuDQoNClZlcmJvc2UgbW9kZSAtIHRoZSByZXNwb25zZSBp cywNCkNvbW1vbkhlYWRlcihDb25maWdSZVR5cGUpOiBUTFZmb3JSZU9QMTpUTFZmb3JSZU9QMjpU TFZmb3JSZU9QbjpUTFZmb3JSZVNVTS4NCg0KUHJlY2lzZSBtb2RlIC0gdGhlIHJlc3BvbnNlIGlz LA0KQ29tbW9uSGVhZGVyKENvbmZpZ1JlVHlwZSk6IFRMVmZvclJlU1VNDQoNClRoZSBUTFZmb3JS ZVNVTSBpbmNsdWRlcyBhIHN1bW1hcnkgZm9yIHRoZSB0cmFuc2FjdGlvbiBleGN1dGlvbi4NCg0K SSBhbHNvIHN1Z2dlc3QgKGFzIGluIG15IHJlY2VudCByZXBseSB0byBKYW1hbCdzIHN1bW1hcnkg YW5zIGFsc28gaW4gdGhlIG1lZXRpbmcNCm1pbnV0ZXMpLCB3ZSBtYXkgYmV0dGVyIHRvIHRyZWF0 IGEgbXNnIGFzIGEgdHJhbnNhY3Rpb24sIHRoYXQgaXMsIGFsbA0Kb3BzKGNvbW1hbmRzKSBpbnNp ZGUgb25lIG1zZyBzaG91bGQgaGF2ZSB0aGUgbWVhbmluZyBvZiAnYWxsIG9yIG5vdGhpbmcnLCBz byBhcw0KdG8gc2ltcGxpZnkgb3VyIHByb3RvY29sIGRlZmluaXRpb24uIENvdWxkIHlvdSBnaXZl IHNvbWUgY29tbWVudHMgb24gdGhlDQp0aG91Z2h0Pw0KDQogIA0KT0sgaWYgYWxsIGNvbW1hbmRz IGluIHRoZSBiYXRjaCBmYWlsZWQsIGFuZCBub3RPSyBpZiBzb21lIG9mIHRoZW0NCmZhaWxlZCAo YW5kIHByb2JhYmx5IHdlIHNob3VsZCBzdG9wIHByb2Nlc3NpbmcgY29tbWFuZHMgYWZ0ZXIgdGhl DQpmaXJzdCBmYWlsdXJlKS4NCiAgICAgIA0KSSB0aGluayB0aGF0IGlzIGEgZGlmZmVyZW50IHR5 cGUgb2YgY29tbWFuZCwgdGhlIGRvIHVudGlsIGVycm9yIGJhdGNoLg0KDQogICAgDQpJcyB0aGlz IGEgc2VtYW50aWNzIHRoYXQgd291bGQgYmUgYWNjZXB0YWJsZSB0byBldmVyeW9uZSA/DQogICAg ICANCkkgZ3Vlc3MgSSBkb24ndCB0aGluayBzby4NCg0KYS4NCg0KICAgIA0KVGhhbmsgeW91IHZl cnkgbXVjaC4NCg0KQlINCldlaW1pbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQpGb3Jj ZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ZvcmNlcy1wcm90b2NvbA0KDQoNCiAgDQoNCg0KLS0gDQpSb2JlcnQgSGFhcw0KSUJNIFp1 cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNILTg4MDMgUvxzY2hs aWtvbi9Td2l0emVybGFuZA0KcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3 OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoNCg== ------=_NextPart_000_0774_01C43D23.ED22B140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+Um9iZXJ0LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5ZZXMsIEkgYWxzbyBub3RpY2VkIHRoYXQgdG8gdHJlYXQgYSBtc2cgYXMgb25lIA0K dHJhbnNhY3Rpb24gbWF5IGJlIG5vdCBlZmZpY2llbnQgZW5vdWdoIGZvciBtdWxpdHBsZSB0aW55 IGluZGVwZW5kZW50IA0KdHJhbnNhY3Rpb25zLiBJIHNlZSB0aGF0IHlvdXIgc2NoZW1lIGlzIHRv IHRyZWF0IG9uZSBtc2cgZWl0aGVyIGFzIG9uZSANCnRyYW5zYWN0aW9uIG9yIGFzIGEgc2VxdWVu Y2Ugb2YgaW5kZXBlbmRlbnQgdHJhbnNhY3Rpb25zLiBJIGFncmVlIHdpdGggdGhpcyANCnNjaGVt ZSB3ZWxsLCBiZWNhdXNlIGl0IGlzIGFjdHVhbGx5IHN0aWxsIHNpbXBsZSBvbmUsIHdpdGggSSB0 aGluayBvbmx5IG9uZSBtb3JlIA0KYml0IG9mIGZsYWcgdG8gaW5kaWNhdGUgaXQgKGFsc28gYXMg dGhlIGZsYWdzIHlvdSBtZW50aW9uZWQpLiBOb3cgd2UgbmVlZCB0byANCmRpc2N1c3MgbW9yZSBp cyBpZiB3ZSBuZWVkIHRvIHN1cHBvcnQgdGhlIHNjaGVtZSB3aGVyZSB0aGVyZSBhcmUgaW5kZXBl bmRlbnQgDQp0cmFuc2FjdGlvbnMgYXMgd2VsbCBhcyBzZXZlcmFsIGF0b21pYyB0cmFuc2FjdGlv bnMgaW5zaWRlIG9uZSBtc2csIHdoaWNoIEkgDQp0aGluayBpcyBhbHNvIHdoYXQgSmFtYWwgbWVh bnMuIFRoaXMgdHJ1bHkgbWFrZXMgdGhpbmdzIHF1aXRlIGNvbXBsZXguIEknbCBqdXN0IA0Kc3Rv cCBoZXJlLiBJIHRoaW5rIHlvdSBhcmUgYWxyZWFkeSBvbiB0aGUgcGhvbmUuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlNlZSB5b3UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj5XZWltaW5nPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCjxCTE9DS1FVT1RF IGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsg TUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4t UklHSFQ6IDBweCI+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05U OiAxMHB0IGFyaWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRs ZT1yaGFAenVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbSI+Um9i ZXJ0IEhhYXM8L0E+IA0KICA8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj5XZWltaW5nLDxCUj48 QlI+SSdkIHByZWZlciBub3QgdG8gZW5mb3JjZSB0aGF0IGFsbCBjb21tYW5kcyANCiAgaW4gdGhl IHNhbWUgbWVzc2FnZSBtdXN0IGJlIHRyZWF0ZWQgYXMgYSBzaW5nbGUgYXRvbWljIHRyYW5zYWN0 aW9uLiBBcyBKYW1hbCANCiAgbm90ZWQsIHRyZWF0aW5nIGEgZmV3IDEwMDBzIG9mIGNvbW1hbmRz IGFzIGEgc2luZ2xlIGF0b21pYyBvcGVyYXRpb24gaW4gdGhlIEZFIA0KICB3aWxsIHJlcXVpcmUg bXVjaCBtb3JlIHJlc291cmNlcyBhbmQgbW9yZSBjb21wbGV4IHByb2Nlc3NpbmcgcGF0aC4gSSdk IGxpa2UgdG8gDQogIGJlIGFibGUgdG8gdHJlYXQgdGhpcyAxMDAwcyBvZiBjb21tYW5kcyBpbiB0 aGUgc2FtZSBtZXNzYWdlIG9uZSBhZnRlciB0aGUgDQogIG90aGVyLCB3aXRob3V0IGhhdmluZyB0 byByZW1lbWJlciB0aGUgcmVzdWx0cyBhbmQgY2FjaGUgdGhlbSB1bnRpbCBhbGwgMTAwMHMgDQog IGhhdmUgc3VjY2VlZGVkLCBpbiBjYXNlIHJvbGwtYmFjayBpcyBuZWVkZWQuPEJSPjxCUj5NeSBw cm9wb3NhbCByZWdhcmRpbmcgDQogIGF0b21pY2l0eSB3b3VsZCBoZW5jZSBiZTo8QlI+PEJSPiZu YnNwOzIgZmxhZ3MsIEF0b21pY1N0YXJ0IChBUykgYW5kIEF0b21pY0VuZCANCiAgKEFFKSBpbiB0 aGUgQ29tbW9uIEhlYWRlcjo8QlI+PEJSPiZuYnNwO2lmIEFTPUFFPTE6IHRoZSAobXVsdGlwbGUp IGNvbW1hbmRzIGluIA0KICB0aGUgbWVzc2FnZSBtdXN0IGJlIHRyZWF0ZWQgYXMgYXRvbWljLjxC Uj48QlI+Jm5ic3A7aWYgQVM9QUU9MDogdGhlIChtdWx0aXBsZSkgDQogIGNvbW1hbmRzIGluIHRo ZSBtZXNzYWdlIG11c3QgYmUgdHJlYXRlZCBhcyBhIHNlcXVlbmNlIG9mIGluZGVwZW5kZW50IA0K ICBjb21tYW5kcy48QlI+PEJSPiZuYnNwO2lmIEFTPTEgYW5kIEFFPTA6IHN0YXJ0IG9mIGF0b21p YyB0cmFuc2FjdGlvbiB0aGF0IGNhbiANCiAgc3BhbiBtdWx0aXBsZSBtZXNzYWdlcyB1bnRpbCBh IG1lc3NhZ2Ugd2l0aCBBUz0wLCBBRT0xLCANCiAgYXJyaXZlcy48QlI+PEJSPiZuYnNwO2lmIEFT PUFFPTA6IGVpdGhlciB0aGUgbWlkZGxlIG9mIGFuIGF0b21pYyB0cmFuc2FjdGlvbiwgDQogIG9y IG5vIGF0b21pYyB0cmFuc2FjdGlvbiBhdCBhbGwuIEZvciBjbGFyaXR5LCBhIHJlZHVuZGFudCZu YnNwOyBBdG9taWNNaWRkbGUgDQogIChBTSkgZmxhZyBjb3VsZCBiZSB1c2VkLjxCUj48QlI+V2Ug bmVlZCB0byBpZGVudGlmeSBpbXBsaWNhdGlvbnMgb24gDQogIGJhdGNoaW5nLjxCUj48QlI+UmVn YXJkcyw8QlI+LVJvYmVydDxCUj48QlI+V2VpbWluZyBXYW5nIHdyb3RlOjxCUj4NCiAgPEJMT0NL UVVPVEUgY2l0ZT1taWQwMTExMDFjNDNjMWIkNTkwM2VlYjAkMDIwYWE4YzBAd3dtMSB0eXBlPSJj aXRlIj48UFJFIHdyYXA9IiI+SGkgQXZyaSwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQ0KRnJvbTogPEEgY2xhc3M9bW96LXR4dC1saW5rLXJmYzIzOTZFIGhyZWY9Im1haWx0bzphdnJp QGFjbS5vcmciPiZsdDthdnJpQGFjbS5vcmcmZ3Q7PC9BPg0KICA8L1BSRT4NCiAgICA8QkxPQ0tR VU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+T24gMTQgbWFqIDIwMDQsIGF0IDAxLjAzLCBS b2JlcnQgSGFhcyB3cm90ZToNCg0KICAgIDwvUFJFPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+PFBSRSB3cmFwPSIiPkkgZmluYWxseSBzZWUgYSBqdXN0aWZpY2F0aW9uIGZvciBwbGFp biBiYXRjaGluZyAodGhhdCBpcywgYmF0Y2hpbmcNCndpdGhvdXQgYXRvbWljaXR5KTogYSBiYXRj aCB3aWxsIHJlc3VsdCBpbiBhIHNpbmdsZSBzdGF0dXM6DQogICAgICA8L1BSRT48L0JMT0NLUVVP VEU+PFBSRSB3cmFwPSIiPlthZF0gIEFjdHVhbGx5IEkgaGF2ZSBmb3VuZCB0aGF0IHByb2JsZW1h dGljLiAgV2hhdCBpIGhhdmUgZm91bmQgaXMNCnRoYXQgSSBuZWVkIGEgZXJyb3IgcGVyIGNvbW1h bmQuICB0aGUgb3ZlcmFsbCBlcnJvciBpbmRpY2F0b3IgY2FuIGJlDQp1c2VkIHRvIGluZGljYXRl IHRoYXQgb25lIG9yIG1vcmUgb2YgdGhlIGNvbW1hbmRzIGZhaWxlZCwgYnV0IGVhY2gNCmNvbW1h bmQgcHJvYmFibHkgbmVlZHMgaXRzIG93biBlcnJvciBpbmRpY2F0ZWQuDQoNCiAgICA8L1BSRT48 L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwhLS0tLT5bV2VpbWluZ10gSSBhZ3JlZWQuIEkgc3Vw cG9zZSBpZiBmb2xsb3dpbmcgc2NoZW1lIGNhbiBtZWV0IHRoZSByZXF1aXJlbWVudDoNCg0KVGFr aW5nIGEgQ29uZmlnIG1zZyB3aXRoIHRoZSBmb3JtYXQgYXM6DQoNCiBDb21tb25IZWFkZXIoQ29u ZmlnVHlwZSk6IFRMVmZvck9QMTpUTFZmb3JPUDI6Li4uVExWZm9yT1BuDQoNCmFzIGFuIGV4YW1w bGUuIFdlIG1heSBhbGxvdyB0d28gZm9ybWF0IG9mIEFDSy9SZXNwb25zZS4NCg0KVmVyYm9zZSBt b2RlIC0gdGhlIHJlc3BvbnNlIGlzLA0KQ29tbW9uSGVhZGVyKENvbmZpZ1JlVHlwZSk6IFRMVmZv clJlT1AxOlRMVmZvclJlT1AyOlRMVmZvclJlT1BuOlRMVmZvclJlU1VNLg0KDQpQcmVjaXNlIG1v ZGUgLSB0aGUgcmVzcG9uc2UgaXMsDQpDb21tb25IZWFkZXIoQ29uZmlnUmVUeXBlKTogVExWZm9y UmVTVU0NCg0KVGhlIFRMVmZvclJlU1VNIGluY2x1ZGVzIGEgc3VtbWFyeSBmb3IgdGhlIHRyYW5z YWN0aW9uIGV4Y3V0aW9uLg0KDQpJIGFsc28gc3VnZ2VzdCAoYXMgaW4gbXkgcmVjZW50IHJlcGx5 IHRvIEphbWFsJ3Mgc3VtbWFyeSBhbnMgYWxzbyBpbiB0aGUgbWVldGluZw0KbWludXRlcyksIHdl IG1heSBiZXR0ZXIgdG8gdHJlYXQgYSBtc2cgYXMgYSB0cmFuc2FjdGlvbiwgdGhhdCBpcywgYWxs DQpvcHMoY29tbWFuZHMpIGluc2lkZSBvbmUgbXNnIHNob3VsZCBoYXZlIHRoZSBtZWFuaW5nIG9m ICdhbGwgb3Igbm90aGluZycsIHNvIGFzDQp0byBzaW1wbGlmeSBvdXIgcHJvdG9jb2wgZGVmaW5p dGlvbi4gQ291bGQgeW91IGdpdmUgc29tZSBjb21tZW50cyBvbiB0aGUNCnRob3VnaHQ/DQoNCiAg PC9QUkU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICA8QkxPQ0tRVU9URSB0 eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+T0sgaWYgYWxsIGNvbW1hbmRzIGluIHRoZSBiYXRjaCBm YWlsZWQsIGFuZCBub3RPSyBpZiBzb21lIG9mIHRoZW0NCmZhaWxlZCAoYW5kIHByb2JhYmx5IHdl IHNob3VsZCBzdG9wIHByb2Nlc3NpbmcgY29tbWFuZHMgYWZ0ZXIgdGhlDQpmaXJzdCBmYWlsdXJl KS4NCiAgICAgIDwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+SSB0aGluayB0aGF0IGlz IGEgZGlmZmVyZW50IHR5cGUgb2YgY29tbWFuZCwgdGhlIGRvIHVudGlsIGVycm9yIGJhdGNoLg0K DQogICAgPC9QUkU+DQogICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+ SXMgdGhpcyBhIHNlbWFudGljcyB0aGF0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8gZXZlcnlvbmUg Pw0KICAgICAgPC9QUkU+PC9CTE9DS1FVT1RFPjxQUkUgd3JhcD0iIj5JIGd1ZXNzIEkgZG9uJ3Qg dGhpbmsgc28uDQoNCmEuDQoNCiAgICA8L1BSRT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwh LS0tLT5UaGFuayB5b3UgdmVyeSBtdWNoLg0KDQpCUg0KV2VpbWluZw0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcy1wcm90b2NvbCBt YWlsaW5nIGxpc3QNCjxBIGNsYXNzPW1vei10eHQtbGluay1hYmJyZXZpYXRlZCBocmVmPSJtYWls dG86Rm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5Gb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+ DQo8QSBjbGFzcz1tb3otdHh0LWxpbmstZnJlZXRleHQgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3RvY29sIj5odHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2w8L0E+DQoNCg0KICA8L1BSRT48L0JM T0NLUVVPVEU+PEJSPjxQUkUgY2xhc3M9bW96LXNpZ25hdHVyZSBjb2xzPSI3MiI+LS0gDQpSb2Jl cnQgSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQN CkNILTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0KcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZh eCArNDEtMS03MjQtODU3OCAgPEEgY2xhc3M9bW96LXR4dC1saW5rLWZyZWV0ZXh0IGhyZWY9Imh0 dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYSI+aHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+ cmhhPC9BPjwvUFJFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0774_01C43D23.ED22B140-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 13:33: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 NAA29508 for ; Tue, 18 May 2004 13:33: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 1BQ8Kl-0003c4-Iq for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 13:24:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IHOtwq013888 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 13:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8GH-0002Qo-Om for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 13:20: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 NAA28621 for ; Tue, 18 May 2004 13:20: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 1BQ8GF-0000k9-NV for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8FM-0000gF-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:19:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ8Es-0000c0-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:18:51 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BQ8Ek-0008Qs-Qt for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:18:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7zl-00061W-3d; Tue, 18 May 2004 13:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ7vg-0004wr-NO for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 12:59: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 MAA27309 for ; Tue, 18 May 2004 12: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 1BQ7ve-00078s-Vu for forces-protocol@ietf.org; Tue, 18 May 2004 12:58:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ7uh-00074z-00 for forces-protocol@ietf.org; Tue, 18 May 2004 12:58:00 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BQ7ts-0006yZ-00 for forces-protocol@ietf.org; Tue, 18 May 2004 12:57:09 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4IGucGP058808 for ; Tue, 18 May 2004 16:56:38 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 i4IGubXs285152 for ; Tue, 18 May 2004 18:56:37 +0200 Received: from zurich.ibm.com (dhcp222-74.zurich.ibm.com [9.4.222.74]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA06022 for ; Tue, 18 May 2004 18:56:37 +0200 Message-ID: <40AA4044.7080806@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: forces-protocol@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id i4IGucGP058808 Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Minutes of ForCES design team phone call #2, May 18 2004. 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, 18 May 2004 18:56:36 +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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, Here are the minutes from today. I tried to condense the discussions,=20 let me know if you have additions to be made. There may be one or more=20 Action-Items that are of importance to you, take a look. Thanks, -Robert Participants: Hormuzd, Robert, Ram, Avri, Weiming, Jamal. Robert is taking minutes. 1) Common Header. Hormuzd describes the current situation: Version + subversion 4 b Source ID 32 b Dest ID 32 b Transaction Seq number 32 length 16 b cmd type 8 b flags 16 b (priority, batching, atomicity, (n)ack) LFB type 16 b Jamal: is 16 bits enough for length ? Cannot be smaller than the TLV leng= th. Ram: count the length in multiple of 4 bytes. Avri: message must aligned on double-words (32 bits) Hormuzd: LFB type 16 bits can be too small. May need to increase to 32 bi= ts. 2) LFB Type. Robert: used to address LFBs by type instead of by address. Avri: we should keep a small common header. Only FEs know which LFB=20 types they have. So CE must sent the message to all FEs. No LFB Type=20 needed in the Common Header, except if all inner TLVs must have it. Jamal: used for easy debugging purposes. Hormuzd: LFB Type mcast not suitable for mutliple independent IPv4 LFBs=20 instances in same FE. Weiming: proposes an additional flag to indicate if Dest ID is an FE ID=20 or an LFB ID. Might not be possible. Jamal: virtual instance LFB ID for virtual routers. Avri, Hormuzd: need to have a picture of the header to discuss. Action Item: Robert+Jamal+Weiming will finalize the addressing scheme in=20 a section, exchanges will be made on the list. Use of LFB Type in the=20 Common Header will be reassessed later. 3) HB (heart beat): Hormuzd: Common Header cmd types defined: setup, event, query, config,=20 state maintenance (i.e., active FE, move CE) (all with their=20 responses), packet redirect. Avri: HB should be as short as possible. Jamal: should allow a HB for LFB instances (if LFB software crashes). Robert+Avri: LFBs crashing on the FE should trigger an event to the CE=20 (status or alarm message). Use subscribe/unsusbcribe on specific LFBs=20 for their livelness attribute. Avri: a health-check LFB that fires events when LFBs fail, and send a HB=20 liveliness status for a specified list of LFBs. HB is only basic FE and=20 CE liveliness. Robert: HB is a short header message, but should be configurable through=20 the FE LFB. Agreement: HB signal is a separate message type. How to configure it=20 (i.e., using the FE LFB or new PDUs) remains open. Preferrably using the=20 same logic as for other LFBs (Robert and Weiming's preference, to be=20 further discussed). 4) Batching and Atomicity: Ram: 2-phase commit can be done over two different FEs. Avri: transactions are made of TLV and are either atomic, or batch, or=20 do-until. Avri left. Action-Item: Ram will clarify the relation between atomicity, 2-phase=20 commit, when issuing commands to the same FE or two different FEs.=20 Diagrams of transactions. Weiming: If 3 routes are added with a single TLV, then should we ensure=20 atomicity if needed. Ram left. Weiming: interleaving commands/TLVs in the same message, some are=20 atomic, some not. Jamal: add subsequence numbers to identifiy independent transactions in=20 the same message. Use of window of 1 for PL messages, and use 16 bits=20 for 16 subsequence numbers within a PL message for 16 parallelized=20 uncorrelated transactions (TLVs). Action-Item: Hormuzd will post some scenarios and associated diagrams. Robert: iSCSI (RFC3720) supports a cmd window, so that multiple=20 uncorrelated transactions can be sent together without overflowing the=20 FE. This could avoid using the subsequence number. Jamal: a cmd window is tricky with mcast to multiple FEs as they must=20 coordinate cmd windows. No resolution yet on how deep atomicity should go (within TLVs). 5) General Action-Item: everyone must start writing their section and post a draft=20 on the protocol list by May 24th. after 2 hours 45 min, the conf call ended. --=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 May 18 14:12:52 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 OAA02805 for ; Tue, 18 May 2004 14:12: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 1BQ92l-0003kZ-Sc for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 14:10:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIANOY014410 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 14:10:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8t2-0001Py-SG for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:00: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 OAA01757 for ; Tue, 18 May 2004 14:00: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 1BQ8t0-0003S0-I3 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 14:00:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8rz-0003Of-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:59:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8rD-0003LV-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 13:58:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8k4-0008WO-MA; Tue, 18 May 2004 13:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8dJ-00074f-Kn for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 13:44: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 NAA00049 for ; Tue, 18 May 2004 13:44: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 1BQ8dH-00023b-AP for forces-protocol@ietf.org; Tue, 18 May 2004 13:44:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8cI-00020x-00 for forces-protocol@ietf.org; Tue, 18 May 2004 13:43: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 1BQ8bT-0001wa-00 for forces-protocol@ietf.org; Tue, 18 May 2004 13:42:11 -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 i4IHcosD005265 for ; Tue, 18 May 2004 17:42:35 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i4IH5RSZ026995 for ; Tue, 18 May 2004 17:05:30 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 M2004051810080614009 for ; Tue, 18 May 2004 10:08:06 -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, 18 May 2004 10:08: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 Message-ID: <468F3FDA28AA87429AD807992E22D07E011096B8@orsmsx408.jf.intel.com> Thread-Topic: Summary of Protocol Messages (Command Types) Thread-Index: AcQu13pyG9hN34TgQ9yUhtzPMx+30gOIXjMw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 18 May 2004 17:08:04.0941 (UTC) FILETIME=[AF0A87D0:01C43CFA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Forces-protocol] Summary of Protocol Messages (Command Types) 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, 18 May 2004 10:08:04 -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 summary of the Protocol Messages (Command Types) 1. Association Setup msg/ Setup Resp/=20 Association Teardown (using a flag or just msg type? - Weiming pls confirm) =20 2. Query / Query resp msg - includes FE capability query, LFB Topology as well as Inter-FE Topology query 3. Config / Config resp msg 4. State Maintenance msg/ State Maintenance Resp - includes Activate FE, Deactivate FE, Move Primary CE 5. Event msg / Event Resp - includes Subscribe, Unsubscribe, Report/Notification 6. Packet Redirect msg - includes FE->CE redirect packet as well as CE->FE forward packet 7. Heart Beat msg Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 15:04:35 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 PAA06069 for ; Tue, 18 May 2004 15:04: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 1BQ9oC-0005ah-00 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 14:59:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIxNV4021491 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 14:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9jD-0004qE-G9 for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:54: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 OAA05445 for ; Tue, 18 May 2004 14:54: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 1BQ9jA-00072p-RZ for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 14:54:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9iH-00070T-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 14:53:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9hr-0006xX-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 14:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9aM-0003Rl-N4; Tue, 18 May 2004 14: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 1BQ9Rf-0001oI-Rt for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 14:36: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 OAA04365 for ; Tue, 18 May 2004 14:36: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 1BQ9Rd-0005t9-4n for forces-protocol@ietf.org; Tue, 18 May 2004 14:36:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9Qj-0005qF-00 for forces-protocol@ietf.org; Tue, 18 May 2004 14:35:10 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Py-0005m3-00 for forces-protocol@ietf.org; Tue, 18 May 2004 14:34:22 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4IIXqGP103012; Tue, 18 May 2004 18:33:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4IIXp9a030718; Tue, 18 May 2004 20:33:51 +0200 Received: from zurich.ibm.com (dhcp222-74.zurich.ibm.com [9.4.222.74]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA72340; Tue, 18 May 2004 20:33:50 +0200 Message-ID: <40AA570E.20209@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: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) References: <468F3FDA28AA87429AD807992E22D07E011096B8@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E011096B8@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 mtagate1.de.ibm.com id i4IIXqGP103012 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, 18 May 2004 20:33:50 +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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hormuzd, Thanks for the summary. Some comments below: Khosravi, Hormuzd M wrote: >Hi All, > >Here is the summary of the Protocol Messages (Command Types) > >1. Association Setup msg/ Setup Resp/=20 > Association Teardown (using a flag or just msg type? - Weiming pls >confirm) > =20 >2. Query / Query resp msg > - includes FE capability query, LFB Topology as well as Inter-FE >Topology query > >3. Config / Config resp msg > >4. State Maintenance msg/ State Maintenance Resp > - includes Activate FE, Deactivate FE, Move Primary CE > I'd rather avoid creating new messages for each State Maintenance action=20 (especially since we don't know all of them yet). Instead, one could=20 make use of an FE LFB with attributes sfor each of these actions, and=20 use the standard Config messages to act on these attributes. Adding new=20 actions will simply translate into new versions of the FE LFB, instead=20 of new protocol message types. > >5. Event msg / Event Resp > - includes Subscribe, Unsubscribe, Report/Notification > >6. Packet Redirect msg > - includes FE->CE redirect packet as well as CE->FE forward packet > >7. Heart Beat msg > =20 > I want to make sure that we all understand the implications of choosing=20 such message types: For instance, this means that it is not possible to mix in the same PL=20 message a Config action as well as an Event Subscribe action for the=20 same LFB instance. I find this annoying especially becauseI don't=20 understand why we need to differentiate at the Common-Header level=20 between a Config and an Event Subscribe, as both are destined to an LFB=20 anyway, as opposed to Association Setup or HB messages. Regards, -Robert > >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 May 18 15:32:42 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 PAA09210 for ; Tue, 18 May 2004 15:32: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 1BQAD6-0000WZ-La for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:25:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJP8Vi002010 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA5S-00053F-Dw for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:17: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 PAA07812 for ; Tue, 18 May 2004 15:17: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 1BQA5R-0000U2-8t for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:17:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA4X-0000Rd-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:16:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQA42-0000P3-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:15:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9ub-0003PB-DF; Tue, 18 May 2004 15: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 1BQ9p0-0005h7-0w for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 15:00: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 PAA05759 for ; Tue, 18 May 2004 15:00: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 1BQ9ow-0007Mb-Bg for forces-protocol@ietf.org; Tue, 18 May 2004 15:00:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9o4-0007KR-00 for forces-protocol@ietf.org; Tue, 18 May 2004 14:59:17 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ9ni-0007HA-00 for forces-protocol@ietf.org; Tue, 18 May 2004 14:58:54 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) 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 i4IIwlWj007997; Tue, 18 May 2004 18:58:47 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 i4IIvDSn012870; Tue, 18 May 2004 18:58:59 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 M2004051811582223904 ; Tue, 18 May 2004 11:58:22 -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, 18 May 2004 11:58: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] Summary of Protocol Messages (Command Types) Message-ID: <468F3FDA28AA87429AD807992E22D07E011098DB@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary of Protocol Messages (Command Types) Thread-Index: AcQ9BsNrGyFH6vK6T2WMwQ00btiixAAAUPKw From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: X-OriginalArrivalTime: 18 May 2004 18:58:20.0624 (UTC) FILETIME=[164BA500:01C43D0A] 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, 18 May 2004 11:58:20 -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, I believe we already agreed on these messages. Infact, having Subscribe part of the Event message was your preference (from the last meetings minute notes, if you remember). I don't see any scenarios in which both these have to be combined. Event subscribe will most likely happen as part of some initialization code on the CE, before you start configuring the LFB. Also, I think your idea of FE LFB will still work fine with State Maintenance msgs. At this point, I think it will be wiser for us to put some text on paper as we decided on the call, start writing the sections and we can always revisit them once we have something concrete (I believe we allocated 10 days to reviewing the sections).=20 Weiming and myself will be happy to get your input on Protocol Messages so as to accommodate your idea (FE LFB). Hope that helps, regards Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 > >Here is the summary of the Protocol Messages (Command Types) > >1. Association Setup msg/ Setup Resp/=20 > Association Teardown (using a flag or just msg type? - Weiming pls >confirm) > =20 >2. Query / Query resp msg > - includes FE capability query, LFB Topology as well as Inter-FE >Topology query > >3. Config / Config resp msg > >4. State Maintenance msg/ State Maintenance Resp > - includes Activate FE, Deactivate FE, Move Primary CE > I'd rather avoid creating new messages for each State Maintenance action (especially since we don't know all of them yet). Instead, one could=20 make use of an FE LFB with attributes sfor each of these actions, and=20 use the standard Config messages to act on these attributes. Adding new=20 actions will simply translate into new versions of the FE LFB, instead=20 of new protocol message types. > >5. Event msg / Event Resp > - includes Subscribe, Unsubscribe, Report/Notification > >6. Packet Redirect msg > - includes FE->CE redirect packet as well as CE->FE forward packet > >7. Heart Beat msg > =20 > I want to make sure that we all understand the implications of choosing=20 such message types: For instance, this means that it is not possible to mix in the same PL=20 message a Config action as well as an Event Subscribe action for the=20 same LFB instance. I find this annoying especially becauseI don't=20 understand why we need to differentiate at the Common-Header level=20 between a Config and an Event Subscribe, as both are destined to an LFB=20 anyway, as opposed to Association Setup or HB messages. Regards, -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 15:33:31 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 PAA09259 for ; Tue, 18 May 2004 15:33: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 1BQADy-0000lO-Uq for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJQ24K002929 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQA7L-0007VP-Ec for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 15: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 PAA08060 for ; Tue, 18 May 2004 15:19: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 1BQA7J-0000cK-Vj for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:19:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA6P-0000Xr-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:18:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQA5c-0000VP-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:17:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9wg-00054e-A3; Tue, 18 May 2004 15:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9rn-0001QH-9k for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 15:03: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 PAA05887 for ; Tue, 18 May 2004 15:03: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 1BQ9rk-0007Un-CS for forces-protocol@ietf.org; Tue, 18 May 2004 15:03:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9qt-0007T0-00 for forces-protocol@ietf.org; Tue, 18 May 2004 15:02:11 -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 1BQ9qO-0007Pe-00 for forces-protocol@ietf.org; Tue, 18 May 2004 15:01:40 -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 i4IJ1qoD016499; Tue, 18 May 2004 19:01:52 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 i4IJ1ISH016062; Tue, 18 May 2004 19:01:35 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 M2004051812005824283 ; Tue, 18 May 2004 12:00: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); Tue, 18 May 2004 12:00:58 -0700 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] T in TLV, another thought Message-ID: <468F3FDA28AA87429AD807992E22D07E011098E6@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV, another thought Thread-Index: AcQ8sUvplBFViGO+RCeCRN8sDcvFyQAWNniA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 18 May 2004 19:00:58.0525 (UTC) FILETIME=[74696CD0:01C43D0A] 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, 18 May 2004 12:00: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 Avri, I like this idea of common flags for TLV. I think this can be part of = the Type, 8 bits for the actual Type and 8 bits for Flags. How does that = sound ? This might also accommodate any flags such as the ones that = Jamal, Weiming were suggesting in todays call. Regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org = [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org In general I agree with the principle that the type (T) defines the=20 value (V). The only exception I might favor is that we talk about=20 TfLV, where the f is a standard small set of flags that indicates some=20 general properties about how the tlv is handled. this is not to say=20 the the TLV cannot also have an specific set of flags inside the V. a. On 18 maj 2004, at 03.20, Khosravi, Hormuzd M wrote: > =A0 > Thanks for the comments on the Global vs local scope for T in TLV. > =A0 > Another design principle that I would like to share and get your=20 > thoughts on is... > How do we choose semantics=A0for=A0T ? The basic principle is that a=20 > different T should mean a different V, essentially T defines V. > To give you an example... in the Config message format that I had sent = > out, I used T to mean either FE or LFB attributes. > This is cause I see the V in case of T=3DLAB attributes having fields=20 > such as LAB Type, LAB Instance ID. In case T=3DFE attributes, we=20 > probably wont have these 2 fields. Does that help understand the logic = > for defining T=A0? > =A0 > Do you guys think this is a good design principle ? > =A0 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Tue May 18 16:28: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 QAA14198 for ; Tue, 18 May 2004 16:28: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 1BQAT2-0006f1-HD for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:42:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJfaD5025598 for forces-protocol-archive@odin.ietf.org; Tue, 18 May 2004 15:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAOe-000419-Pp for forces-protocol-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:37: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 PAA09544 for ; Tue, 18 May 2004 15:37: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 1BQAOd-0001iy-IE for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:37:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQANj-0001gh-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:36:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQAN0-0001f2-00 for forces-protocol-web-archive@ietf.org; Tue, 18 May 2004 15:35:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAEv-0000r6-75; Tue, 18 May 2004 15: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 1BQA7J-0007VG-7I for forces-protocol@optimus.ietf.org; Tue, 18 May 2004 15:19: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 PAA08049 for ; Tue, 18 May 2004 15: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 1BQA7H-0000c2-CS for forces-protocol@ietf.org; Tue, 18 May 2004 15:19:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQA6K-0000XD-00 for forces-protocol@ietf.org; Tue, 18 May 2004 15:18: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 1BQA5V-0000Ub-00 for forces-protocol@ietf.org; Tue, 18 May 2004 15:17:17 -0400 Received: from [10.0.0.21] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004051812212310:7710 ; Tue, 18 May 2004 12:21:23 -0700 From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Robert Haas , Weiming Cc: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1084907831.1022.6.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 05/18/2004 12:21:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/18/2004 12:21:28 PM, Serialize complete at 05/18/2004 12:21:28 PM Content-Type: multipart/mixed; boundary="=-NVPscKSC/2e2MojQFGUS" Subject: [Forces-protocol] msg layout 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: 18 May 2004 15:17: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 --=-NVPscKSC/2e2MojQFGUS Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached is the begginings of message layout work Robert, Weiming and myself are supposed to put out. Modus operandi: Comments will be incorporated in the text when agreed to and changes will be mailed back to list. Although 3 people are involved in putting out text, all can participate if they want (but you can wait till final text if you are busy). I will be version controlling and if possible post diffs when i make changes. cheers, jamal --=-NVPscKSC/2e2MojQFGUS Content-Disposition: attachment; filename=msghdr.txt Content-Type: text/plain; name=msghdr.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MAIN HEADER ----------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | vers | resvd | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | typeid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message is 32 bit aligned. command (8 bits): The currently identified commands that will be seen on the wire are: - Config Typically used for Setting attributes (which are FE or LFB specific). Partially discussed in Hormuzds email on add route example. More discussion below. - Config Reply Not yet discussed. - State maintanance Not yet discussed other than some operations have been mentioned: Activate FE, Deactivate FE, Move Primary CE. Any conflict with meta-FE LFB here??? - State maintainance reply Not yet discussed. - query Not yet discussed. - query reply Not yet discussed. - Association setup - Association Teardown Some initial discussion on whether we should go into using flags (Weiming) - Event - Event reply - heartbeat - heartbeat response Weiming posted something; however, theres still confusion on whether heartbeat and events belong together or are separate. - Packet redirect Not yet discussed other than it could be a FE->CE redirect packet or a CE->FE forward packet. vers (4 bit): Version resvd (4 bits): unused at this point Source ID (32 bit): Dest ID (32 bit): - Above are 32 bit IDs which recognize the termination point. Ideas discussed so far are desire to recognize if ID belongs to FE or CE by inspection. Suggestions for achieving this involves partitioning of the ID allocation. Another alternative maybe to use flags to indicate direction (this avoids partition). - IDs will allow multi/broad/unicast Addressing to be discussed by Robert. Sequence (32 bits) unique to a PDU. Discussion: There may be impact on the effect of subsequence numbers. length (16 bits): length of header + the rest of the message in DWORDS (4 byte increments). Flags(16 bits): Identified so far: - ACK (1 bit) - NACK (1 bit) - Priority (3 bits) unknown/undecided. -Throttle flag? - batch (2 bits) - Atomicity (1 or 2 bits) TypeID (16 bit): - This may end up being removed. There are two reasons behind its existence at this point 1) A LFB b/mcast (Robert). 2) To recognize by inspection for debugging purposes where the message is destined within an FE/CE(Jamal). 3) Perhaps its an optimization to have this field if we do indeed find that all TLVs need this field (mentioned by Avri in concal). Main header issues TBD: ---------------------- 1) Parallelization of PL Windowing/subsequence Someone to look into ISCSI 2) events and replies and relation to peer to peer vs master slave Message body: --------------- All message bodies will be TLVs. 16 bits for T, 16 bits for L & variable len V 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Config Message -------------- This message is sent when theres a desire to set an attribute. Modified sample of what was provided by Hormuzd 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = operation + attrs | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Reserved | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | single or Array LFB specific entries | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): operations on attributes ("set attribute"). So far recognized attributes are LFB and FE. Some operations mentioned so far are: ADD, DEL, REPLACE, Update/replace - Discussion so far has been on whether weType should be of a gloabal or local nature. Consensus seems to be around global with no need to split the type into bits (??). ie TYPE = 0x32 could mean ADDLFBATTR whereas 0x31 could mean DELLFBATTR etc Length (16 bits): Length of the entire message includiung the T and the L in bytes. LFB Type ID (32 bits): This will be a unique number which recognizes the LFB type. LFB Instance ID (32 bits): Recognizes the partition or tableid being addressed (Think virtual routers for example). Theres a question whether partitions need to be addressed with an LFB instance id here or there should be a unique dst ID for it in the main header. single or Array LFB specific entries (variable sized) This will carry LFB specific data. $Log: msghdr.txt,v $ Revision 1.1 2004/05/18 19:15:56 hadi Initial revision --=-NVPscKSC/2e2MojQFGUS-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 06:05:05 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 GAA27007 for ; Wed, 19 May 2004 06:05:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNmK-00014S-3q for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 05:54:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9sOGC004104 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 05:54:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNgO-0007O6-RN for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:48: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 FAA25667 for ; Wed, 19 May 2004 05:48: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 1BQNgG-0006IQ-6Z for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:48:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNfZ-00065j-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:47:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNeN-0005rs-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7y-0007ue-F4; Wed, 19 May 2004 05:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMuH-00065H-LJ for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 04:58: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 EAA22409 for ; Wed, 19 May 2004 04:58: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 1BQMuE-0005cO-Fc for forces-protocol@ietf.org; Wed, 19 May 2004 04:58:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMtK-0005Sz-00 for forces-protocol@ietf.org; Wed, 19 May 2004 04:57:34 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BQMsN-00052n-00 for forces-protocol@ietf.org; Wed, 19 May 2004 04:56:36 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Wed, 19 May 2004 17:07:31 +0800 Message-ID: <014b01c43d7e$e07f76c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E011096B8@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) 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, 19 May 2004 16:54:21 +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, ----- Original Message ----- From: "Khosravi, Hormuzd M" Hi All, Here is the summary of the Protocol Messages (Command Types) 1. Association Setup msg/ Setup Resp/ Association Teardown (using a flag or just msg type? - Weiming pls confirm) [Weimig] I still prefer the flag method : - ) . Thank you. Weiming 2. Query / Query resp msg - includes FE capability query, LFB Topology as well as Inter-FE Topology query 3. Config / Config resp msg 4. State Maintenance msg/ State Maintenance Resp - includes Activate FE, Deactivate FE, Move Primary CE 5. Event msg / Event Resp - includes Subscribe, Unsubscribe, Report/Notification 6. Packet Redirect msg - includes FE->CE redirect packet as well as CE->FE forward packet 7. Heart Beat msg Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 06:05: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 GAA27024 for ; Wed, 19 May 2004 06:05: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 1BQNmP-00016e-Tr for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 05:54:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9sTMe004229 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 05:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNgm-0007Uc-Se for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:48: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 FAA25688 for ; Wed, 19 May 2004 05:48: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 1BQNgj-0006Qe-AI for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:48:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNff-000677-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:47:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNea-0005s9-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 05:46:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN7z-0007uy-V7; Wed, 19 May 2004 05:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQMzB-0006ck-4k for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 05:03: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 FAA22521 for ; Wed, 19 May 2004 05:03: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 1BQMz7-0006Gk-Nv for forces-protocol@ietf.org; Wed, 19 May 2004 05:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQMyC-00068S-00 for forces-protocol@ietf.org; Wed, 19 May 2004 05:02:38 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BQMxK-0005tJ-00 for forces-protocol@ietf.org; Wed, 19 May 2004 05:01:42 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4J91CAN103780; Wed, 19 May 2004 09:01:12 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4J91BWQ152222; Wed, 19 May 2004 11:01:12 +0200 Received: from zurich.ibm.com (dhcp222-74.zurich.ibm.com [9.4.222.74]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA36102; Wed, 19 May 2004 11:01:09 +0200 Message-ID: <40AB2254.9070501@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: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) References: <468F3FDA28AA87429AD807992E22D07E011098DB@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E011098DB@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------030100050108080307030302" 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, 19 May 2004 11:01:08 +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.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030100050108080307030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i4J91CAN103780 Content-Transfer-Encoding: quoted-printable Hi Hormuzd, Khosravi, Hormuzd M wrote: >Hi Robert, > >I believe we already agreed on these messages. > I was questioning the current thinking only for the sake of a having a=20 solid design. I think the current agreement did not consider the issue I=20 raised. I do not necessarily mean that we need to change what we have=20 now, but at least think of good reasons why we should keep it as is. > Infact, having Subscribe >part of the Event message was your preference (from the last meetings >minute notes, if you remember). > True. Further thinking caused me to question this that's why I wanted to=20 have the list's opinion. > I don't see any scenarios in which both >these have to be combined. Event subscribe will most likely happen as >part of some initialization code on the CE, before you start configuring >the LFB. > Here is another example in which I think we may need to dynamically=20 subscribe to events: The CE adds a filtering rule, and at the same time requires event to be=20 fired whenever a packet matches this rule. This can be for the purpose=20 of DoS detection, for instance. Let me know if this is a convincing example. > Also, I think your idea of FE LFB will still work fine with >State Maintenance msgs. > >At this point, I think it will be wiser for us to put some text on paper >as we decided on the call, start writing the sections and we can always >revisit them once we have something concrete (I believe we allocated 10 >days to reviewing the sections).=20 >Weiming and myself will be happy to get your input on Protocol Messages >so as to accommodate your idea (FE LFB). > Thanks, -Robert > >Hope that helps, > >regards >Hormuzd > >-----Original Message----- >From: Robert Haas [mailto:rha@zurich.ibm.com]=20 > > =20 > >>Here is the summary of the Protocol Messages (Command Types) >> >>1. Association Setup msg/ Setup Resp/=20 >> Association Teardown (using a flag or just msg type? - Weiming pls >>confirm) >> =20 >>2. Query / Query resp msg >> - includes FE capability query, LFB Topology as well as Inter-FE >>Topology query >> >>3. Config / Config resp msg >> >>4. State Maintenance msg/ State Maintenance Resp >> - includes Activate FE, Deactivate FE, Move Primary CE >> >> =20 >> >I'd rather avoid creating new messages for each State Maintenance action > >(especially since we don't know all of them yet). Instead, one could=20 >make use of an FE LFB with attributes sfor each of these actions, and=20 >use the standard Config messages to act on these attributes. Adding new=20 >actions will simply translate into new versions of the FE LFB, instead=20 >of new protocol message types. > > =20 > >>5. Event msg / Event Resp >> - includes Subscribe, Unsubscribe, Report/Notification >> >>6. Packet Redirect msg >> - includes FE->CE redirect packet as well as CE->FE forward packet >> >>7. Heart Beat msg >>=20 >> >> =20 >> > >I want to make sure that we all understand the implications of choosing=20 >such message types: > >For instance, this means that it is not possible to mix in the same PL=20 >message a Config action as well as an Event Subscribe action for the=20 >same LFB instance. I find this annoying especially becauseI don't=20 >understand why we need to differentiate at the Common-Header level=20 >between a Config and an Event Subscribe, as both are destined to an LFB=20 >anyway, as opposed to Association Setup or HB messages. > >Regards, >-Robert > > > =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 --------------030100050108080307030302 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,

Khosravi, Hormuzd M wrote:
Hi Robert,

I believe we already agreed on these messages.
I was questioning the current thinking only for the sake of a having a solid design. I think the current agreement did not consider the issue I raised. I do not necessarily mean that we need to change what we have now, but at least think of good reasons why we should keep it as is.

 Infact, having Subscribe
part of the Event message was your preference (from the last meetings
minute notes, if you remember).
True. Further thinking caused me to question this that's why I wanted to have the list's opinion.
 I don't see any scenarios in which both
these have to be combined. Event subscribe will most likely happen as
part of some initialization code on the CE, before you start configuring
the LFB.
Here is another example in which I think we may need to dynamically subscribe to events:

The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance.

Let me know if this is a convincing example.
 Also, I think your idea of FE LFB will still work fine with
State Maintenance msgs.

At this point, I think it will be wiser for us to put some text on paper
as we decided on the call, start writing the sections and we can always
revisit them once we have something concrete (I believe we allocated 10
days to reviewing the sections). 
Weiming and myself will be happy to get your input on Protocol Messages
so as to accommodate your idea (FE LFB).

Thanks,
-Robert

Hope that helps,

regards
Hormuzd

-----Original Message-----
From: Robert Haas [mailto:rha@zurich.ibm.com] 

  
Here is the summary of the Protocol Messages (Command Types)

1.  Association Setup msg/ Setup Resp/ 
   Association Teardown (using a flag or just msg type? - Weiming pls
confirm)
   
2. Query / Query resp msg
   - includes FE capability query, LFB Topology as well as Inter-FE
Topology query

3. Config / Config resp msg

4. State Maintenance msg/ State Maintenance Resp
   - includes Activate FE, Deactivate FE, Move Primary CE

    
I'd rather avoid creating new messages for each State Maintenance action

(especially since we don't know all of them yet). Instead, one could 
make use of an FE LFB with attributes sfor each of these actions, and 
use the standard Config messages to act on these attributes. Adding new 
actions will simply translate into new versions of the FE LFB, instead 
of new protocol message types.

  
5. Event msg / Event Resp
   - includes Subscribe, Unsubscribe, Report/Notification

6. Packet Redirect msg
   - includes FE->CE redirect packet as well as CE->FE forward packet

7. Heart Beat msg
 

    

I want to make sure that we all understand the implications of choosing 
such message types:

For instance, this means that it is not possible to mix in the same PL 
message a Config action as well as an Event Subscribe action for the 
same LFB instance. I find this annoying especially becauseI don't 
understand why we need to differentiate at the Common-Header level 
between a Config and an Event Subscribe, as both are destined to an LFB 
anyway, as opposed to Association Setup or HB messages.

Regards,
-Robert


  

-- 
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
--------------030100050108080307030302-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 21:36:07 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 VAA04278 for ; Wed, 19 May 2004 21:36: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 1BQcPR-00061J-1T for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 21:32:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K1VjFm023142 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 21:31:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcKG-0004oR-Lk for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:26: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 VAA03766 for ; Wed, 19 May 2004 21:26: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 1BQcKD-0001tc-UQ for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:26:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcJ9-0001l1-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:25:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQcIV-0001dX-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:24:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQc7J-0002GQ-7y; Wed, 19 May 2004 21:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQc26-0000gk-KI for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 21:07: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 VAA03027 for ; Wed, 19 May 2004 21:07: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 1BQc23-0007G8-RX for forces-protocol@ietf.org; Wed, 19 May 2004 21:07:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQc0y-00074U-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:06:28 -0400 Received: from fmr09.intel.com ([192.52.57.35] helo=hermes.hd.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1BQbzq-0006hy-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:05:18 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4K14Y8d026104; Thu, 20 May 2004 01:04:34 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4K143ZE004795; Thu, 20 May 2004 01:04: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 M2004051918042714736 ; Wed, 19 May 2004 18:04:27 -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, 19 May 2004 18:04:27 -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] msg layout Message-ID: <468F3FDA28AA87429AD807992E22D07E01164E19@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] msg layout Thread-Index: AcQ9ESfRrHl9UqyHRuaxU00vNQYBBAA9NGZw From: "Khosravi, Hormuzd M" To: , "Robert Haas" , "Weiming" Cc: X-OriginalArrivalTime: 20 May 2004 01:04:27.0778 (UTC) FILETIME=[66271620:01C43E06] 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, 19 May 2004 18:04:27 -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, This looks like a very good start to me. Weiming and myself are starting work on the Protocol Messages, we'll post some text once we have discussed, completed it. One minor suggestion on the header, you might want to start with the version field. Hope you don't mind such nits :) regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Jamal Hadi Salim Attached is the begginings of message layout work Robert, Weiming and myself are supposed to put out. Modus operandi: Comments will be incorporated in the text when agreed to and changes=20 will be mailed back to list. Although 3 people are involved in putting out text, all can participate if they want (but you can wait till final text if you are busy). I will be version controlling and if possible post diffs when i make changes. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 21:36:42 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 VAA04343 for ; Wed, 19 May 2004 21:36: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 1BQcRD-0006FC-U2 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 21:33:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K1XZTj023989 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 21:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcNt-0005bD-On for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:30: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 VAA03867 for ; Wed, 19 May 2004 21:30: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 1BQcNq-0002QK-VZ for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:30:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcMt-0002HE-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:29:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQcLw-00029d-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 21:28:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcJ4-0004XA-1o; Wed, 19 May 2004 21: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 1BQc9U-0002T4-GK for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 21:15: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 VAA03312 for ; Wed, 19 May 2004 21:15: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 1BQc9R-0000TR-QX for forces-protocol@ietf.org; Wed, 19 May 2004 21:15:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQc8b-0000MD-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:14:21 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQc84-0000DG-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:13:48 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4K1DI9w004687; Thu, 20 May 2004 01:13:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4K1DMIq000977; Thu, 20 May 2004 01:13:47 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 M2004051918131319281 ; Wed, 19 May 2004 18:13: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); Wed, 19 May 2004 18:13:13 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43E07.9F2DA08C" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Message-ID: <468F3FDA28AA87429AD807992E22D07E01164E22@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary of Protocol Messages (Command Types) Thread-Index: AcQ9f+7Yd8w58BGWTTKQbbIAqp6b2AAhovuA From: "Khosravi, Hormuzd M" To: "Robert Haas" Cc: X-OriginalArrivalTime: 20 May 2004 01:13:13.0219 (UTC) FILETIME=[9F570530:01C43E07] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 19 May 2004 18:13: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.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43E07.9F2DA08C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, -----Original Message----- Here is another example in which I think we may need to dynamically subscribe to events: The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance. Let me know if this is a convincing example.=20 =20 [HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported. regards Hormuzd=20 =20 ------_=_NextPart_001_01C43E07.9F2DA08C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Robert,
-----Original Message-----
Here is another example in which I think we may need to = dynamically=20 subscribe to events:

The CE adds a filtering rule, and at the = same time=20 requires event to be fired whenever a packet matches this rule. This = can be=20 for the purpose of DoS detection, for instance.

Let me know if = this is=20 a convincing example. 
 
[HK] I don't think we=20 will be subscribing to events at this level of granularity. From = my=20 little experience at the NPF and what I have seen from the Model team, = events=20 will be defined on per LFB basis. The example that you have given here = is a=20 lot more granular, i.e. per entry basis in a LFB table. I dont think = this=20 level of granularity will be supported.
regards
Hormuzd 
 
------_=_NextPart_001_01C43E07.9F2DA08C-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 22:26:17 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 WAA06440 for ; Wed, 19 May 2004 22:26: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 1BQdCI-0000aG-P8 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 22:22:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K2MEs6002244 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 22:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdBL-0000D8-Lh for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 22:21: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 WAA06156 for ; Wed, 19 May 2004 22:21: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 1BQdBI-0001ls-ET for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 22:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQdAV-0001e2-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 22:20:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQd9a-0001W8-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 22:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcrp-0003z9-W6; Wed, 19 May 2004 22:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcmD-0002P8-Eb for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 21:55: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 VAA04987 for ; Wed, 19 May 2004 21:55: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 1BQcmA-0005wH-8i for forces-protocol@ietf.org; Wed, 19 May 2004 21:55:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQclK-0005oJ-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:54:22 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQckQ-0005Yh-00 for forces-protocol@ietf.org; Wed, 19 May 2004 21:53:26 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4K1qv9w014587 for ; Thu, 20 May 2004 01:52:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4K1r6Im011033; Thu, 20 May 2004 01:53:29 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 M2004051918523525684 ; Wed, 19 May 2004 18:52: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); Wed, 19 May 2004 18:52:35 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43E0D.1F0EAED0" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] T in TLV, another thought Message-ID: <468F3FDA28AA87429AD807992E22D07E01164E4B@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV, another thought Thread-Index: AcQ8h96jh7RZWl2XTuGuPIjH7jlX9gBf/Y0Q From: "Khosravi, Hormuzd M" To: "Weiming Wang" , X-OriginalArrivalTime: 20 May 2004 01:52:35.0379 (UTC) FILETIME=[1F4C0830:01C43E0D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 19 May 2004 18:52:34 -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.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43E0D.1F0EAED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiming, =20 Thanks for your comments. -----Original Message----- p.s. To further clarify, it would make sense to have Operation (Add, Del, etc) part of T if we would define different TLV or PDU for different Operations. I don't think that is the case, but do you think the PDU will be different for each Operation ?? [Weiming]Yes, the PDU for different ops will be quite different. E.g., to add a route, we need to tell the route value, to update a route, we need to know the old route value and to tell the new value. For event msgs, the PDU for different event ops are also quite different, e.g., sub/unsub differ event notification format. =20 [HK] I see where the confusion is, since the actual route information is a variable length field which is kind of opaque to the rest of the TLV. Anyways i will go with your suggestion for now although i believe we might want to revisit later.=20 =20 BTW, what did you think about Avri's suggestion of TfLV ? It looks like a neat idea to me if we decide to have some common flags, =20 regards Hormuzd ------_=_NextPart_001_01C43E0D.1F0EAED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Weiming,
 
Thanks=20 for your comments.
-----Original Message-----
p.s. To further = clarify, it would=20 make sense to have Operation (Add, Del, etc) part of T if we = would=20 define different TLV or PDU for different Operations. I don't = think that=20 is the case, but do you think the PDU will be different for each = Operation ??
[Weiming]Yes, the PDU = for=20 different ops will be quite different. E.g., to add a route, we = need to=20 tell the route value, to update a route, we need to know the old = route=20 value and to tell the new value. For event msgs, the PDU for = different=20 event ops are also quite different, e.g., sub/unsub differ event = notification format.
 
[HK] I see where the confusion is, = since the=20 actual route information is a variable length field which is = kind of=20 opaque to the rest of the TLV. Anyways i will go with your = suggestion=20 for now although i believe we might want to revisit later.=20
 
BTW, what did you think about Avri's = suggestion=20 of TfLV ? It looks like a neat idea to me if we decide to have = some=20 common flags,
 
regards
Hormuzd
------_=_NextPart_001_01C43E0D.1F0EAED0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Wed May 19 23:35: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 XAA10106 for ; Wed, 19 May 2004 23:35: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 1BQeJa-00080e-1H for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 23:33:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K3Xoei030789 for forces-protocol-archive@odin.ietf.org; Wed, 19 May 2004 23:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeGB-0007Mf-Nv for forces-protocol-web-archive@optimus.ietf.org; Wed, 19 May 2004 23:30: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 XAA09807 for ; Wed, 19 May 2004 23:30: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 1BQeG9-0004PL-Rh for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 23:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQeFG-0004FW-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 23:29:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQeEJ-000471-00 for forces-protocol-web-archive@ietf.org; Wed, 19 May 2004 23:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeAA-00064Q-11; Wed, 19 May 2004 23:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQe54-0004oD-VC for forces-protocol@optimus.ietf.org; Wed, 19 May 2004 23:18: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 XAA08978 for ; Wed, 19 May 2004 23:18: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 1BQe52-0002Rg-W1 for forces-protocol@ietf.org; Wed, 19 May 2004 23:18:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQe35-00021V-00 for forces-protocol@ietf.org; Wed, 19 May 2004 23:16:48 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BQe0u-0001g5-00 for forces-protocol@ietf.org; Wed, 19 May 2004 23:14:33 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Thu, 20 May 2004 11:27:27 +0800 Message-ID: <01a301c43e18$889c7a30$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E01164E4B@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] T in TLV, another thought MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01C43E5B.96972390" 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, 20 May 2004 11:14: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=1.8 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_01A0_01C43E5B.96972390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEhvcm11emQsDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAg RnJvbTogS2hvc3JhdmksIEhvcm11emQgTSANCiAgVG86IFdlaW1pbmcgV2FuZyA7IGZvcmNlcy1w cm90b2NvbEBpZXRmLm9yZyANCiAgU2VudDogVGh1cnNkYXksIE1heSAyMCwgMjAwNCA5OjUyIEFN DQogIFN1YmplY3Q6IFJFOiBbRm9yY2VzLXByb3RvY29sXSBUIGluIFRMViwgYW5vdGhlciB0aG91 Z2h0DQoNCg0KICBXZWltaW5nLA0KDQogIFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCiAgICAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgICAgICAgcC5zLiBUbyBmdXJ0aGVyIGNs YXJpZnksIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2ZSBPcGVyYXRpb24gKEFkZCwgRGVsLCBl dGMpIHBhcnQgb2YgVCBpZiB3ZSB3b3VsZCBkZWZpbmUgZGlmZmVyZW50IFRMViBvciBQRFUgZm9y IGRpZmZlcmVudCBPcGVyYXRpb25zLiBJIGRvbid0IHRoaW5rIHRoYXQgaXMgdGhlIGNhc2UsIGJ1 dCBkbyB5b3UgdGhpbmsgdGhlIFBEVSB3aWxsIGJlIGRpZmZlcmVudCBmb3IgZWFjaCBPcGVyYXRp b24gPz8NCiAgICAgICAgICBbV2VpbWluZ11ZZXMsIHRoZSBQRFUgZm9yIGRpZmZlcmVudCBvcHMg d2lsbCBiZSBxdWl0ZSBkaWZmZXJlbnQuIEUuZy4sIHRvIGFkZCBhIHJvdXRlLCB3ZSBuZWVkIHRv IHRlbGwgdGhlIHJvdXRlIHZhbHVlLCB0byB1cGRhdGUgYSByb3V0ZSwgd2UgbmVlZCB0byBrbm93 IHRoZSBvbGQgcm91dGUgdmFsdWUgYW5kIHRvIHRlbGwgdGhlIG5ldyB2YWx1ZS4gRm9yIGV2ZW50 IG1zZ3MsIHRoZSBQRFUgZm9yIGRpZmZlcmVudCBldmVudCBvcHMgYXJlIGFsc28gcXVpdGUgZGlm ZmVyZW50LCBlLmcuLCBzdWIvdW5zdWIgZGlmZmVyIGV2ZW50IG5vdGlmaWNhdGlvbiBmb3JtYXQu DQoNCiAgICAgICAgICBbSEtdIEkgc2VlIHdoZXJlIHRoZSBjb25mdXNpb24gaXMsIHNpbmNlIHRo ZSBhY3R1YWwgcm91dGUgaW5mb3JtYXRpb24gaXMgYSB2YXJpYWJsZSBsZW5ndGggZmllbGQgd2hp Y2ggaXMga2luZCBvZiBvcGFxdWUgdG8gdGhlIHJlc3Qgb2YgdGhlIFRMVi4gQW55d2F5cyBpIHdp bGwgZ28gd2l0aCB5b3VyIHN1Z2dlc3Rpb24gZm9yIG5vdyBhbHRob3VnaCBpIGJlbGlldmUgd2Ug bWlnaHQgd2FudCB0byByZXZpc2l0IGxhdGVyLiANCiAgICAgICAgICBbV2VpbWluZ11JJ20gYWxz byB0aGlua2luZyBvZiB0aGlzLCB0aGF0IGlzLCBob3cgdG8gcmVwcmVzZW50IGFuIGF0dHJpYnV0 ZSB2YWx1ZSBkZXNjcmliZWQgYnkgRkUgbW9kZWwuIEknbCBzZW5kIHlvdSBhbnkgdGhvdWdodHMg d2hlbiBJIGhhdmUgc29tZSB2aWV3IG9uIGl0LiANCg0KICAgICAgICAgIEJUVywgd2hhdCBkaWQg eW91IHRoaW5rIGFib3V0IEF2cmkncyBzdWdnZXN0aW9uIG9mIFRmTFYgPyBJdCBsb29rcyBsaWtl IGEgbmVhdCBpZGVhIHRvIG1lIGlmIHdlIGRlY2lkZSB0byBoYXZlIHNvbWUgY29tbW9uIGZsYWdz LA0KDQogICAgICAgICAgW1dlaW1pbmddIFRoYXQncyBhIGdvb2Qgc3VnZ2VzdGlvbi4gTWF5YmUg dGhlIGZsYWcgZm9yICdGRSBhdHRyL0xGQiBhdHRyaScgY2FuIGJlIGFzIGEgY29tbW9uIGZsYWcs IGJlY2F1c2UgMyBtc2dzKHF1ZXJ5LCBjb25maWcsIGV2ZW50KSBtYXkgYWxsIHVzZSBpdC4gQmVz aWRlcyB0aGlzLCBjdXJyZW50bHkgSSBoYXZlIG5vdCB5ZXQgZm91bmQgbW9yZSwgYnV0IHdlIG1h eSBrZWVwIGFuIGV5ZSBvbiBpdC4NCiAgICAgICAgICAgDQogICAgICAgICAgcmVnYXJkcw0KICAg ICAgICAgIEhvcm11emQNCg0KICAgICAgICAgIENoZWVycywNCiAgICAgICAgICBXZWltaW5nDQoN Cg== ------=_NextPart_000_01A0_01C43E5B.96972390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZ TEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+SGkgSG9ybXV6ZCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIg DQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF RlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBw eCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBG T05UOiAxMHB0IGFyaWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0 aXRsZT1ob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIA0KICBocmVmPSJtYWlsdG86aG9ybXV6 ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+S2hvc3JhdmksIEhvcm11emQgTTwvQT4gPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgdGl0bGU9d213YW5n QG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5j biI+V2VpbWluZyBXYW5nPC9BPiA7IDxBIA0KICB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90 b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi PjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgTWF5IDIwLCAyMDA0IDk6NTIgDQpBTTwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TdWJqZWN0OjwvQj4gUkU6IFtGb3JjZXMt cHJvdG9jb2xdIFQgaW4gVExWLCANCiAgYW5vdGhlciB0aG91Z2h0PC9ESVY+DQogIDxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFz cz05OTc0MjE0MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBz aXplPTI+V2VpbWluZyw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTk5 NzQyMTQwMS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTk5NzQyMTQw MS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5UaGFu a3MgZm9yIHlvdXIgY29tbWVudHMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPEJMT0NLUVVPVEUg ZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgIDxESVY+PC9ESVY+DQogICAg PERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249 bGVmdD48Rk9OVCANCiAgICBmYWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08QlI+PC9GT05UPjxTUEFOIA0KICAgIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNz PTgxODM4MjMwMi0xODA1MjAwND48L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQog ICAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQ QURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8QkxPQ0tRVU9URSBkaXI9bHRy IHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICAgIDxCTE9DS1FVT1RFIGRpcj1sdHIg DQogICAgICAgIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBN QVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAw ND48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxTUEFOIGNsYXNzPTgxODM4MjMwMi0xODA1MjAwND5wLnMuIFRvIGZ1cnRoZXIgDQogICAgICAg ICAgY2xhcmlmeSwgaXQgd291bGQgbWFrZSBzZW5zZSB0byBoYXZlIE9wZXJhdGlvbiAoQWRkLCBE ZWwsIGV0YykgcGFydCBvZiANCiAgICAgICAgICBUIGlmIHdlIHdvdWxkIGRlZmluZSBkaWZmZXJl bnQgVExWIG9yIFBEVSBmb3IgZGlmZmVyZW50IE9wZXJhdGlvbnMuIEkgDQogICAgICAgICAgZG9u J3QgdGhpbmsgdGhhdCBpcyB0aGUgY2FzZSwgYnV0IGRvIHlvdSB0aGluayB0aGUgUERVIHdpbGwg YmUgDQogICAgICAgICAgZGlmZmVyZW50IGZvciBlYWNoIE9wZXJhdGlvbiA/PzwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1 MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgICAgIGNvbG9yPSNm ZjAwMDAgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4MjMwMi0xODA1MjAwND5bV2VpbWluZ11ZZXMs IHRoZSANCiAgICAgICAgICBQRFUgZm9yIGRpZmZlcmVudCBvcHMgd2lsbCBiZSBxdWl0ZSBkaWZm ZXJlbnQuIEUuZy4sIHRvIGFkZCBhIHJvdXRlLCANCiAgICAgICAgICB3ZSBuZWVkIHRvIHRlbGwg dGhlIHJvdXRlIHZhbHVlLCB0byB1cGRhdGUgYSByb3V0ZSwgd2UgbmVlZCB0byBrbm93IA0KICAg ICAgICAgIHRoZSBvbGQgcm91dGUgdmFsdWUgYW5kIHRvIHRlbGwgdGhlIG5ldyB2YWx1ZS4gRm9y IGV2ZW50IG1zZ3MsIHRoZSBQRFUgDQogICAgICAgICAgZm9yIGRpZmZlcmVudCBldmVudCBvcHMg YXJlIGFsc28gcXVpdGUgZGlmZmVyZW50LCBlLmcuLCBzdWIvdW5zdWIgDQogICAgICAgICAgZGlm ZmVyIGV2ZW50IG5vdGlmaWNhdGlvbiBmb3JtYXQuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICAgICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gDQogICAgICAgICAgY2xhc3M9ODE4MzgyMzAyLTE4MDUyMDA0PjwvU1BBTj48L0ZPTlQ+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1 MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgICAg c2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4MjMwMi0xODA1MjAwND48U1BBTiANCiAgICAgICAgICBj bGFzcz05OTc0MjE0MDEtMjAwNTIwMDQ+W0hLXSBJIHNlZSB3aGVyZSB0aGUgY29uZnVzaW9uIGlz LCBzaW5jZSB0aGUgDQogICAgICAgICAgYWN0dWFsIHJvdXRlIGluZm9ybWF0aW9uIGlzIGEgdmFy aWFibGUgbGVuZ3RoIGZpZWxkIHdoaWNoIGlzIGtpbmQgb2YgDQogICAgICAgICAgb3BhcXVlIHRv IHRoZSByZXN0IG9mIHRoZSBUTFYuIEFueXdheXMgaSB3aWxsIGdvIHdpdGggeW91ciBzdWdnZXN0 aW9uIA0KICAgICAgICAgIGZvciBub3cgYWx0aG91Z2ggaSBiZWxpZXZlIHdlIG1pZ2h0IHdhbnQg dG8gcmV2aXNpdCBsYXRlci4gDQogICAgICAgICAgPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KICAgICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgICBzaXplPTI+PFNQQU4gY2xh c3M9ODE4MzgyMzAyLTE4MDUyMDA0PjxTUEFOIA0KICAgICAgICAgIGNsYXNzPTk5NzQyMTQwMS0y MDA1MjAwND5bV2VpbWluZ11JJ20gYWxzbyB0aGlua2luZyBvZiB0aGlzLCB0aGF0IGlzLCANCiAg ICAgICAgICBob3cgdG8gcmVwcmVzZW50IGFuIGF0dHJpYnV0ZSB2YWx1ZSBkZXNjcmliZWQgYnkg RkUgbW9kZWwuIEknbCBzZW5kIA0KICAgICAgICAgIHlvdSBhbnkgdGhvdWdodHMgd2hlbiBJIGhh dmUgc29tZSB2aWV3IG9uIGl0LiANCiAgICAgICAgICA8L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICAgIHNpemU9Mj48U1BBTiBj bGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PFNQQU4gDQogICAgICAgICAgY2xhc3M9OTk3NDIxNDAx LTIwMDUyMDA0PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAg ICAgICA8RElWPjxTUEFOIGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgDQogICAgICAgICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4MjMwMi0x ODA1MjAwND48U1BBTiANCiAgICAgICAgICBjbGFzcz05OTc0MjE0MDEtMjAwNTIwMDQ+QlRXLCB3 aGF0IGRpZCB5b3UgdGhpbmsgYWJvdXQgQXZyaSdzIA0KICAgICAgICAgIHN1Z2dlc3Rpb24gb2Yg VGZMViA/IEl0IGxvb2tzIGxpa2UgYSBuZWF0IGlkZWEgdG8gbWUgaWYgd2UgZGVjaWRlIHRvIA0K ICAgICAgICAgIGhhdmUgc29tZSBjb21tb24gZmxhZ3MsPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICAgICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgICBzaXplPTI+PFNQQU4g Y2xhc3M9ODE4MzgyMzAyLTE4MDUyMDA0PjxTUEFOIA0KICAgICAgICAgIGNsYXNzPTk5NzQyMTQw MS0yMDA1MjAwND48L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAg ICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICAgIHNpemU9Mj48U1BBTiBjbGFzcz04MTgzODIzMDIt MTgwNTIwMDQ+PFNQQU4gDQogICAgICAgICAgY2xhc3M9OTk3NDIxNDAxLTIwMDUyMDA0PltXZWlt aW5nXSBUaGF0J3MgYSBnb29kIHN1Z2dlc3Rpb24uIE1heWJlIHRoZSANCiAgICAgICAgICBmbGFn IGZvciAnRkUgYXR0ci9MRkIgYXR0cmknIGNhbiBiZSBhcyBhIGNvbW1vbiBmbGFnLCBiZWNhdXNl IDMgDQogICAgICAgICAgbXNncyhxdWVyeSwgY29uZmlnLCBldmVudCkgbWF5IGFsbCB1c2UgaXQu Jm5ic3A7QmVzaWRlcyB0aGlzLCANCiAgICAgICAgICBjdXJyZW50bHkgSSBoYXZlIG5vdCZuYnNw O3lldCBmb3VuZCBtb3JlLCBidXQgd2UgbWF5IGtlZXAgYW4gZXllIG9uIA0KICAgICAgICAgIGl0 LjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgICA8RElWPjxTUEFO IGNsYXNzPTU0NDE1MTIwMS0xODA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQogICAgICAgICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTgxODM4MjMwMi0xODA1MjAwND48U1BBTiAN CiAgICAgICAgICBjbGFzcz05OTc0MjE0MDEtMjAwNTIwMDQ+Jm5ic3A7PC9TUEFOPjwvU1BBTj48 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAx LTE4MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgICBzaXpl PTI+PFNQQU4gY2xhc3M9ODE4MzgyMzAyLTE4MDUyMDA0PjxTUEFOIA0KICAgICAgICAgIGNsYXNz PTk5NzQyMTQwMS0yMDA1MjAwND5yZWdhcmRzPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgICBzaXplPTI+PFNQQU4gY2xhc3M9 ODE4MzgyMzAyLTE4MDUyMDA0PjxTUEFOIA0KICAgICAgICAgIGNsYXNzPTk5NzQyMTQwMS0yMDA1 MjAwND5Ib3JtdXpkPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICAg IDxESVY+PFNQQU4gY2xhc3M9NTQ0MTUxMjAxLTE4MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiANCiAgICAgICAgICBzaXplPTI+PFNQQU4gY2xhc3M9ODE4MzgyMzAyLTE4MDUy MDA0PjxTUEFOIA0KICAgICAgICAgIGNsYXNzPTk5NzQyMTQwMS0yMDA1MjAwND48L1NQQU4+PC9T UEFOPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICAgICAgPERJVj48U1BBTiBjbGFz cz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAg ICAgICAgIHNpemU9Mj48U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PFNQQU4gDQogICAg ICAgICAgY2xhc3M9OTk3NDIxNDAxLTIwMDUyMDA0PkNoZWVycyw8L1NQQU4+PC9TUEFOPjwvRk9O VD48L1NQQU4+PC9ESVY+DQogICAgICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgw NTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICAgIHNpemU9Mj48 U1BBTiBjbGFzcz04MTgzODIzMDItMTgwNTIwMDQ+PFNQQU4gDQogICAgICAgICAgY2xhc3M9OTk3 NDIxNDAxLTIwMDUyMDA0PldlaW1pbmc8L1NQQU4+PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+ DQogICAgICAgICAgPERJVj48U1BBTiBjbGFzcz01NDQxNTEyMDEtMTgwNTIwMDQ+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICAgIHNpemU9Mj48U1BBTiBjbGFzcz04MTgz ODIzMDItMTgwNTIwMDQ+PFNQQU4gDQogICAgICAgICAgY2xhc3M9OTk3NDIxNDAxLTIwMDUyMDA0 PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj48L0JMT0NLUVVPVEU+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_01A0_01C43E5B.96972390-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 20 03:10: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 DAA01854 for ; Thu, 20 May 2004 03:10: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 1BQhff-00059B-Qd for forces-protocol-archive@odin.ietf.org; Thu, 20 May 2004 03:08:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K78ppB019783 for forces-protocol-archive@odin.ietf.org; Thu, 20 May 2004 03:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQhdT-0004Ry-Kg for forces-protocol-web-archive@optimus.ietf.org; Thu, 20 May 2004 03:06: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 DAA01760 for ; Thu, 20 May 2004 03:06: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 1BQhdP-0006lV-MU for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 03:06:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQhcP-0006c0-00 for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 03:05:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQhbd-0006Sj-00 for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 03:04:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQha0-0003s0-OI; Thu, 20 May 2004 03:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQhWY-0003D1-U1 for forces-protocol@optimus.ietf.org; Thu, 20 May 2004 02:59: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 CAA01525 for ; Thu, 20 May 2004 02:59: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 1BQhWU-0005eH-T1 for forces-protocol@ietf.org; Thu, 20 May 2004 02:59:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQhVY-0005VQ-00 for forces-protocol@ietf.org; Thu, 20 May 2004 02:58:25 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQhUg-0005Cx-00 for forces-protocol@ietf.org; Thu, 20 May 2004 02:57:30 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4K6v06G011042 for ; Thu, 20 May 2004 06:57:00 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4K6vBI3014073 for ; Thu, 20 May 2004 06:57:32 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 M2004051923565801549 for ; Wed, 19 May 2004 23:56: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); Wed, 19 May 2004 23:56: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: [Forces-protocol] draft text - summary of volunteers Message-ID: <468F3FDA28AA87429AD807992E22D07E011C7D70@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] draft text - summary of volunteers Thread-Index: AcQx3VLGid4GPZZ9T2i/8IuCQuX3+AAVufqAAfvMRxABBOUcEA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 20 May 2004 06:56:58.0707 (UTC) FILETIME=[A516BA30:01C43E37] 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, 19 May 2004 23:56: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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is the summary of volunteers again for reference (added 2 sections on HA, CEM/FEM) Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang, Jamal, Robert 6. Protocol Messages - Hormuzd, Weiming 7. Protocol Scenarios - Hormuzd, Ram 8. High Availability Support - Hormuzd 9. Architectural Considerations, CEM/FEM - Jamal 10. Security Considerations - Ram 11. References - Avri 12. Acknowledgments - All Appendix A. Implementation Notes - All? We decided on the last call to send the text out on our respective sections by Monday May 24th Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Thu May 20 15:07:31 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 PAA12765 for ; Thu, 20 May 2004 15:07: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 1BQspi-000708-41 for forces-protocol-archive@odin.ietf.org; Thu, 20 May 2004 15:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJ3wXM026913 for forces-protocol-archive@odin.ietf.org; Thu, 20 May 2004 15:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsjy-00018J-E5 for forces-protocol-web-archive@optimus.ietf.org; Thu, 20 May 2004 14: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 OAA11816 for ; Thu, 20 May 2004 14:57: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 1BQsjv-0002qr-Hg for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 14:57:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsit-0002mR-00 for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 14:56:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQshw-0002ii-00 for forces-protocol-web-archive@ietf.org; Thu, 20 May 2004 14:55:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUj-0005lu-E7; Thu, 20 May 2004 14:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsOa-0001uP-0o for forces-protocol@optimus.ietf.org; Thu, 20 May 2004 14:35: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 OAA10155 for ; Thu, 20 May 2004 14: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 1BQsOX-0000rp-5x for forces-protocol@ietf.org; Thu, 20 May 2004 14:35:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsNZ-0000oC-00 for forces-protocol@ietf.org; Thu, 20 May 2004 14:34:54 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQsNB-0000kU-00 for forces-protocol@ietf.org; Thu, 20 May 2004 14:34:29 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4KIXs6G019381; Thu, 20 May 2004 18:33:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4KIXvI9023980; Thu, 20 May 2004 18:34:26 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 M2004052011335204316 ; Thu, 20 May 2004 11:33: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, 20 May 2004 11:33:52 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43E98.FFAD0642" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] T in TLV, another thought Message-ID: <468F3FDA28AA87429AD807992E22D07E011C82CE@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] T in TLV, another thought Thread-Index: AcQ+GJsJLEPGfgxxRIOnQH1Lv2WnUAAgBIWg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 20 May 2004 18:33:52.0384 (UTC) FILETIME=[FFFB8000:01C43E98] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 20 May 2004 11:33: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.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43E98.FFAD0642 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Weiming, -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 =20 BTW, what did you think about Avri's suggestion of TfLV ? It looks like a neat idea to me if we decide to have some common flags, =20 [Weiming] That's a good suggestion. Maybe the flag for 'FE attr/LFB attri' can be as a common flag, because 3 msgs(query, config, event) may all use it. Besides this, currently I have not yet found more, but we may keep an eye on it. =20 [HK] I wouldnt consider FE attr/LFB attr as flags. I was thinking more along the lines of an Atomic flag for TLVs that you guys were discussing on the call. (If that makes sense to have) =20 regards Hormuzd ------_=_NextPart_001_01C43E98.FFAD0642 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Weiming,
-----Original Message-----
From: = Wang,Weiming=20 [mailto:wmwang@mail.hzic.edu.cn]
 
BTW, what did you think about = Avri's=20 suggestion of TfLV ? It looks like a neat idea to me if we = decide to=20 have some common flags,
 
[Weiming] That's a good = suggestion. Maybe=20 the flag for 'FE attr/LFB attri' can be as a common flag, = because 3=20 msgs(query, config, event) may all use it. Besides = this,=20 currently I have not yet found more, but we may keep an = eye on=20 it.
 
[HK] I=20 wouldnt consider FE attr/LFB attr as flags. I was thinking = more=20 along the lines of an Atomic flag for TLVs that you guys = were=20 discussing on the call. (If that makes sense to=20 have)
 
regards
Hormuzd
------_=_NextPart_001_01C43E98.FFAD0642-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 21 05:00: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 FAA16674 for ; Fri, 21 May 2004 05:00: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 1BR5pP-0005ur-RA for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 04:56:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8uVma022729 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 04:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5Ys-0001JB-Qm for forces-protocol-web-archive@optimus.ietf.org; Fri, 21 May 2004 04:39: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 EAA15175 for ; Fri, 21 May 2004 04:39: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 1BR5Yp-0006q9-Re for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 04:39:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5Xr-0006h6-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 04:38:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR5XY-0006ZZ-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 04:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5Pk-0007S9-Vp; Fri, 21 May 2004 04:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5FO-0004sN-TX for forces-protocol@optimus.ietf.org; Fri, 21 May 2004 04:19: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 EAA13984 for ; Fri, 21 May 2004 04:19:16 -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 1BR5FM-0003rs-4G for forces-protocol@ietf.org; Fri, 21 May 2004 04:19:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5EO-0003fy-00 for forces-protocol@ietf.org; Fri, 21 May 2004 04:18:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BR5DT-0003X8-00 for forces-protocol@ietf.org; Fri, 21 May 2004 04:17:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5DU-000OXj-2Z for forces-protocol@ietf.org; Fri, 21 May 2004 08:17:20 +0000 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <468F3FDA28AA87429AD807992E22D07E011C7D70@orsmsx408.jf.intel.com> References: <468F3FDA28AA87429AD807992E22D07E011C7D70@orsmsx408.jf.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4656A84C-AAFF-11D8-8A8D-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] draft text - summary of volunteers 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, 21 May 2004 10:17:18 +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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, So, do folks want to write in XML from the start or do you want to write text and have me xmlify it? For those who want to start out in XML, I can probably put together an example of some basics, though of course Marshall's RFC source, available at xml.resources.org (though you need to get the entire distribution to get the source. I can send the source of rfc2629 to anyone who wants) is all you really need - it is what I used. I could zip up the files I have now, plus a trivial example and send it out to folks if that is the preference. Also, on the introduction and abstract, if no one minds, I will wait until after much of the other material is written to do these - so I will not make the 24th deadline. a. On 20 maj 2004, at 08.56, Khosravi, Hormuzd M wrote: > Here is the summary of volunteers again for reference (added 2 sections > on HA, CEM/FEM) > > Abstract - Avri > 1. Introduction - Avri > 2. Definitions - Weiming > 3. Protocol Overview - Jamal > 4. TML Requirements - Jamal > 5. Common Header - Weiming, Ligang, Jamal, Robert > 6. Protocol Messages - Hormuzd, Weiming > 7. Protocol Scenarios - Hormuzd, Ram > 8. High Availability Support - Hormuzd > 9. Architectural Considerations, CEM/FEM - Jamal > 10. Security Considerations - Ram > 11. References - Avri > 12. Acknowledgments - All > Appendix > A. Implementation Notes - All? > > We decided on the last call to send the text out on our respective > sections by Monday May 24th > > 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 May 21 09:07: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 JAA29196 for ; Fri, 21 May 2004 09:07: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 1BR9RA-0005Og-CM for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 08:47:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LCliPc020746 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 08:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9PK-0004dD-Ha for forces-protocol-web-archive@optimus.ietf.org; Fri, 21 May 2004 08:45: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 IAA27847 for ; Fri, 21 May 2004 08:45: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 1BR9PJ-0002nl-AI for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 08:45:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9OT-0002YN-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 08:44:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR9NU-0002J8-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 08:43:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR94e-0007aE-Ui; Fri, 21 May 2004 08:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR8lM-00035O-9z for forces-protocol@optimus.ietf.org; Fri, 21 May 2004 08: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 IAA26094 for ; Fri, 21 May 2004 08:04: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 1BR8lL-0002nU-6s for forces-protocol@ietf.org; Fri, 21 May 2004 08:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR8kO-0002cz-00 for forces-protocol@ietf.org; Fri, 21 May 2004 08:03:32 -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 1BR8jV-0002Sl-00 for forces-protocol@ietf.org; Fri, 21 May 2004 08:02: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 2004052105064077:11316 ; Fri, 21 May 2004 05:06:40 -0700 Subject: Re: [Forces-protocol] draft text - summary of volunteers From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: avri@acm.org Cc: forces-protocol@ietf.org In-Reply-To: <4656A84C-AAFF-11D8-8A8D-000393CC2112@acm.org> References: <468F3FDA28AA87429AD807992E22D07E011C7D70@orsmsx408.jf.intel.com> <4656A84C-AAFF-11D8-8A8D-000393CC2112@acm.org> Organization: ZNYX Networks Message-Id: <1085140949.1040.3.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 05/21/2004 05:06:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 05/21/2004 05:06:46 AM, Serialize complete at 05/21/2004 05:06: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: 21 May 2004 08:02:29 -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 Lets defer the xml to the end. It may be even something we can pass on to you. BTW, i have used Marshalls templates in 2-3 drafts in the past but never as multifiles so wouldnt mind an example with multifiles. cheers, jamal On Fri, 2004-05-21 at 04:17, avri@acm.org wrote: > Hi, > > So, do folks want to write in XML from the start or do you want to > write text and have me xmlify it? For those who want to start out in > XML, I can probably put together an example of some basics, though of > course Marshall's RFC source, available at xml.resources.org (though > you need to get the entire distribution to get the source. I can send > the source of rfc2629 to anyone who wants) is all you really need - it > is what I used. I could zip up the files I have now, plus a trivial > example and send it out to folks if that is the preference. > > Also, on the introduction and abstract, if no one minds, I will wait > until after much of the other material is written to do these - so I > will not make the 24th deadline. > > a. > > > > On 20 maj 2004, at 08.56, Khosravi, Hormuzd M wrote: > > > Here is the summary of volunteers again for reference (added 2 sections > > on HA, CEM/FEM) > > > > Abstract - Avri > > 1. Introduction - Avri > > 2. Definitions - Weiming > > 3. Protocol Overview - Jamal > > 4. TML Requirements - Jamal > > 5. Common Header - Weiming, Ligang, Jamal, Robert > > 6. Protocol Messages - Hormuzd, Weiming > > 7. Protocol Scenarios - Hormuzd, Ram > > 8. High Availability Support - Hormuzd > > 9. Architectural Considerations, CEM/FEM - Jamal > > 10. Security Considerations - Ram > > 11. References - Avri > > 12. Acknowledgments - All > > Appendix > > A. Implementation Notes - All? > > > > We decided on the last call to send the text out on our respective > > sections by Monday May 24th > > > > 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 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 21 15:08: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 PAA22680 for ; Fri, 21 May 2004 15:08: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 1BRFKl-0005jM-90 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 15:05:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LJ5VBH021893 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 15:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRF7M-0002kS-OJ for forces-protocol-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:51: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 OAA21290 for ; Fri, 21 May 2004 14:51: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 1BRF7K-0004WP-1F for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 14:51:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRF6P-0004RE-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 14:50:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRF5X-0004Mt-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 14:49:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRF01-00010I-5Y; Fri, 21 May 2004 14:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREni-0006ZZ-Hh for forces-protocol@optimus.ietf.org; Fri, 21 May 2004 14:31: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 OAA20100 for ; Fri, 21 May 2004 14: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 1BREnf-0002y5-PM for forces-protocol@ietf.org; Fri, 21 May 2004 14:31:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRElg-0002pG-00 for forces-protocol@ietf.org; Fri, 21 May 2004 14:29:16 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BREjb-0002fz-00 for forces-protocol@ietf.org; Fri, 21 May 2004 14:27:07 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4LIQXqM024433; Fri, 21 May 2004 18:26:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4LIQM2N012715; Fri, 21 May 2004 18:27:07 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 M2004052111263231334 ; Fri, 21 May 2004 11:26: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); Fri, 21 May 2004 11:26: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] draft text - summary of volunteers Message-ID: <468F3FDA28AA87429AD807992E22D07E0122EE38@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] draft text - summary of volunteers Thread-Index: AcQ/DujmvoleOwMhRlyWhjDqjqQX1wAUgitw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 21 May 2004 18:26:32.0348 (UTC) FILETIME=[241D15C0:01C43F61] 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, 21 May 2004 11:26: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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Avri, I would prefer to write my sections in text and pass it on to you for xmlification (if that word exists :)) Hope that is fine with you. Thanks again Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of avri@acm.org Hi, So, do folks want to write in XML from the start or do you want to=20 write text and have me xmlify it? For those who want to start out in=20 XML, I can probably put together an example of some basics, though of=20 course Marshall's RFC source, available at xml.resources.org (though=20 you need to get the entire distribution to get the source. I can send=20 the source of rfc2629 to anyone who wants) is all you really need - it=20 is what I used. I could zip up the files I have now, plus a trivial=20 example and send it out to folks if that is the preference. Also, on the introduction and abstract, if no one minds, I will wait=20 until after much of the other material is written to do these - so I=20 will not make the 24th deadline. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 21 15:57: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 PAA25862 for ; Fri, 21 May 2004 15:57: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 1BRG7Y-0006vl-2b for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 15:55:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LJtuHu026639 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 15:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFzK-0005eh-Tz for forces-protocol-web-archive@optimus.ietf.org; Fri, 21 May 2004 15:47: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 PAA25073 for ; Fri, 21 May 2004 15:47: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 1BRFzJ-0000zP-5f for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 15:47:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFwp-0000Xx-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 15:44:52 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRFug-000080-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 15:42: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 1BRFgL-00045P-Qi for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 15:27:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFdn-0001JD-CC; Fri, 21 May 2004 15:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFP4-0007F9-PL for forces-protocol@optimus.ietf.org; Fri, 21 May 2004 15:09: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 PAA22906 for ; Fri, 21 May 2004 15:09: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 1BRFP1-00064N-NF for forces-protocol@ietf.org; Fri, 21 May 2004 15:09:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFO9-000601-00 for forces-protocol@ietf.org; Fri, 21 May 2004 15:09:02 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BRFNc-0005u1-00 for forces-protocol@ietf.org; Fri, 21 May 2004 15:08:28 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4LJ7vlg077768; Fri, 21 May 2004 19:07:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4LJ7umo154248; Fri, 21 May 2004 21:07:57 +0200 Received: from zurich.ibm.com (dhcp69-221.zurich.ibm.com [9.4.69.221]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA64328; Fri, 21 May 2004 21:07:56 +0200 Message-ID: <40AE538C.4040606@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: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) References: <468F3FDA28AA87429AD807992E22D07E01164E22@orsmsx408.jf.intel.com> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E01164E22@orsmsx408.jf.intel.com> Content-Type: multipart/alternative; boundary="------------000102050402060406090008" 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, 21 May 2004 21:07:56 +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.8 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000102050402060406090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i4LJ7vlg077768 Content-Transfer-Encoding: quoted-printable Hi Hormuzd (and others interested in the way events are supported in the=20 protocol and model), Khosravi, Hormuzd M wrote: > Hi Robert, > > -----Original Message----- > Here is another example in which I think we may need to > dynamically subscribe to events: > > The CE adds a filtering rule, and at the same time requires event > to be fired whenever a packet matches this rule. This can be for > the purpose of DoS detection, for instance. > > Let me know if this is a convincing example.=20 > =20 > [HK] I don't think we will be subscribing to events at this level > of granularity. From my little experience at the NPF and what I > have seen from the Model team, events will be defined on per LFB > basis. The example that you have given here is a lot more > granular, i.e. per entry basis in a LFB table. I dont think this > level of granularity will be supported. > I won't argue against the fact that is is unscalable to let every=20 firewalling rule fire up an event. Nevertheless, this can be useful for=20 some of the firewalling rules (intrusion detection is another example). I hope that the model will not only allow per-LFB events or I would=20 consider this a bad design. We should design our protocol so that it=20 can be used in such cases (i.e., adding a rule and subscribing to an=20 event of that rule). I note that having a "Config" or "Event" message type in the common=20 header forces us to send two separate messages to the same LFB. Not a=20 great thing, especially since fundamentally, there is little value to=20 separate the Config and Event types at the Common-Header level. Maybe others have opinion on this too ? Regards, -Robert > regards > Hormuzd=20 > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------000102050402060406090008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd (and others interested in the way events are supported in the protocol and model),

Khosravi, Hormuzd M wrote:
Message
Hi Robert,
-----Original Message-----
Here is another example in which I think we may need to dynamically subscribe to events:

The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance.

Let me know if this is a convincing example. 
 
[HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported.
I won't argue against the fact that is is unscalable to let every firewalling rule fire up an event. Nevertheless, this can be useful for some of the firewalling rules (intrusion detection is another example).

I hope that the model will not only allow per-LFB events or I would consider this a bad design.  We should design our protocol so that it can be used in such cases (i.e., adding a rule and subscribing to an event of that rule).

I note that having a "Config" or "Event" message type in the common header forces us to send two separate messages to the same LFB. Not a great thing, especially since fundamentally, there is little value to separate the Config and Event types at the Common-Header level.

Maybe others have opinion on this too ?

Regards,
-Robert

regards
Hormuzd 
 

-- 
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
--------------000102050402060406090008-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Fri May 21 19:20: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 TAA12147 for ; Fri, 21 May 2004 19:20: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 1BRJDF-00021F-P2 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 19:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LNE1iI007758 for forces-protocol-archive@odin.ietf.org; Fri, 21 May 2004 19: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 1BRJ8C-0000Zx-Nb for forces-protocol-web-archive@optimus.ietf.org; Fri, 21 May 2004 19:08: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 TAA11682 for ; Fri, 21 May 2004 19:08: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 1BRJ89-0000Ot-89 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 19:08:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJ7F-0000JN-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 19:07:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRJ6f-0000Da-00 for forces-protocol-web-archive@ietf.org; Fri, 21 May 2004 19:07:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIwn-0006dM-8m; Fri, 21 May 2004 18: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 1BRIsf-0005JT-FJ for forces-protocol@optimus.ietf.org; Fri, 21 May 2004 18: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 SAA10747 for ; Fri, 21 May 2004 18:52: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 1BRIsc-0006Zu-2a for forces-protocol@ietf.org; Fri, 21 May 2004 18:52:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRIrd-0006VJ-00 for forces-protocol@ietf.org; Fri, 21 May 2004 18:51:42 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BRIqh-0006Na-00 for forces-protocol@ietf.org; Fri, 21 May 2004 18:50:43 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4LMo5qM026615; Fri, 21 May 2004 22:50:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4LMoY2B008034; Fri, 21 May 2004 22:50: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 M2004052115500307804 ; Fri, 21 May 2004 15:50: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); Fri, 21 May 2004 15:50:03 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43F85.F4105983" x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Message-ID: <468F3FDA28AA87429AD807992E22D07E0122F1C7@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary of Protocol Messages (Command Types) Thread-Index: AcQ/ZwKg/pbB+CbXTz+tf90hg70t5AAHOSCw From: "Khosravi, Hormuzd M" To: "Robert Haas" , "Wang,Weiming" Cc: X-OriginalArrivalTime: 21 May 2004 22:50:03.0660 (UTC) FILETIME=[F463D4C0:01C43F85] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 21 May 2004 15:50: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.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43F85.F4105983 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 The basic reason for having an Event Msg is to report Asynchronous events from FE -> CE. We extended this use to accommodate Subscribe/Unsubscribe functions based on Your and Weiming's preferences. It seems like you are having different thoughts on this now, which is fine. I think you would like is to have Subscribe/Unsubscribe as part of Config rather than Event msg. This is fine by me, and I think Weiming will also be fine to accommodate this since this was one of the options that he had stated before.=20 =20 Weiming, let us know what you think about this ? If we go with this approach, we will probably not need Response for Event msgs. =20 Thanks Hormuzd -----Original Message----- Here is another example in which I think we may need to dynamically subscribe to events: The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance. Let me know if this is a convincing example.=20 =20 [HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported. I won't argue against the fact that is is unscalable to let every firewalling rule fire up an event. Nevertheless, this can be useful for some of the firewalling rules (intrusion detection is another example). I hope that the model will not only allow per-LFB events or I would consider this a bad design. We should design our protocol so that it can be used in such cases (i.e., adding a rule and subscribing to an event of that rule). I note that having a "Config" or "Event" message type in the common header forces us to send two separate messages to the same LFB. Not a great thing, especially since fundamentally, there is little value to separate the Config and Event types at the Common-Header level.=20 Maybe others have opinion on this too ? Regards, -Robert=20 ------_=_NextPart_001_01C43F85.F4105983 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Robert,
 
The=20 basic reason for having an Event Msg is to report Asynchronous events = from FE=20 -> CE. We extended this use to accommodate Subscribe/Unsubscribe = functions=20 based on Your and Weiming's preferences. It seems like you = are having=20 different thoughts on this now, which is fine. I think you would = like is to=20 have Subscribe/Unsubscribe as part of Config rather than Event msg. This = is fine=20 by me, and I think Weiming will also be fine to accommodate this since = this was=20 one of the options that he had stated before.
 
Weiming, let us know what you think about this ? If we go with = this=20 approach, we will probably not need Response for Event = msgs.
 
Thanks
Hormuzd
-----Original Message-----
Here is another example in which I think we may need to = dynamically=20 subscribe to events:

The CE adds a filtering rule, and at = the same=20 time requires event to be fired whenever a packet matches this = rule. This=20 can be for the purpose of DoS detection, for instance.

Let = me know=20 if this is a convincing example. 
 
[HK] I don't=20 think we will be subscribing to events at this level = of granularity.=20 From my little experience at the NPF and what I have seen from the = Model=20 team, events will be defined on per LFB basis. The example that = you have=20 given here is a lot more granular, i.e. per entry basis in a LFB = table. I=20 dont think this level of granularity will be=20 supported.
I won't = argue against=20 the fact that is is unscalable to let every firewalling rule fire up = an event.=20 Nevertheless, this can be useful for some of the firewalling rules = (intrusion=20 detection is another example).

I hope that the model will not = only=20 allow per-LFB events or I would consider this a bad design.  We = should=20 design our protocol so that it can be used in such cases (i.e., adding = a rule=20 and subscribing to an event of that rule).

I note that having a = "Config" or "Event" message type in the common header forces us to = send two=20 separate messages to the same LFB. Not a great thing, especially since = fundamentally, there is little value to separate the Config and Event = types at=20 the Common-Header level.

Maybe others have opinion on this too = ?

Regards,
-Robert 
------_=_NextPart_001_01C43F85.F4105983-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Sun May 23 23:47:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24314 for ; Sun, 23 May 2004 23:47: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 1BS6Pj-00030m-F2 for forces-protocol-archive@odin.ietf.org; Sun, 23 May 2004 23:46:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O3kBMq011572 for forces-protocol-archive@odin.ietf.org; Sun, 23 May 2004 23: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 1BS6Il-0002GG-Iz for forces-protocol-web-archive@optimus.ietf.org; Sun, 23 May 2004 23:38: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 XAA24060 for ; Sun, 23 May 2004 23:38: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 1BS6Ij-00026p-CZ for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6Hj-0001qA-00 for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23:37:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS6Gi-0001MW-00 for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6Dx-0001GJ-3h; Sun, 23 May 2004 23:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6C0-0000ve-EL for forces-protocol@optimus.ietf.org; Sun, 23 May 2004 23:32: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 XAA23424 for ; Sun, 23 May 2004 23:31: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 1BS6By-0007ZX-Bs for forces-protocol@ietf.org; Sun, 23 May 2004 23:31:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6Aw-0007ID-00 for forces-protocol@ietf.org; Sun, 23 May 2004 23:30:55 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BS69c-0006mZ-00 for forces-protocol@ietf.org; Sun, 23 May 2004 23:29:37 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id for ; Mon, 24 May 2004 11:42:12 +0800 Message-ID: <04b201c4413f$3979df90$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E0122F1C7@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AF_01C44182.47879BC0" 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, 24 May 2004 11:28: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=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_04AF_01C44182.47879BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEhvcm11emQsIFJvYmVydCwgYW5kIGFsbCwNCg0KU29ycnkgcmVwbHkgdG8geW91 IHZlcnkgbGF0ZSwgZm9yIEkgd2FzIHZlcnkgYnVzeSBsYXN0IHdlZWtkYXlzIGZvciB1bml2LiBi dXNpbmVzcyBhbmQgYnVzeSB3cml0aW5nIG15IGRyYWZ0IHBhcnQgZHVyaW5nIHRoZSB3ZWVrZW5k LiANCg0KSSBhZ3JlZSB0byBsZXQgY29uZmlnIG1zZyBkbyB0aGUgc3ViL3Vuc3ViIG9mIGV2ZW50 cy4gQWN0dWFsbHkgaW4gdGhpcyBjYXNlLCB0aGUgJ0V2ZW50Q29uZmcnIGFzIEkgbWVudGlvbmVk IGVhbGllciBjYW4gYWxzbyBiZSBwdXQgaW4gdGhlICdDb25maWcnIG1zZywgbGVhdmluZyB0aGUg ZXZlbnQgbXNnIG9ubHkgZm9yICdldmVudCByZXBvcnQnIGFuZCAnZXZlbnQgcmVzcG9uc2UnLiBJ IHRoaW5rIGV2ZW50IHJlc3BvbnNlIGFzIGEgbWVzc2FnZSBzaG91bGQgYmUgcHV0IHRoZXJlLCB3 aGV0aGVyIGN1c3RvbWVycyB1c2UgaXQgd2lsbCBiZSBkZWNpZGVkIGJ5IHRoZSBSZXNwb25zZSBm bGFnIGluIHRoZSBoZWFkZXIuIA0KDQpUaGFuayB5b3UuDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEtob3NyYXZpLCBIb3JtdXpkIE0gDQogIFRvOiBS b2JlcnQgSGFhcyA7IFdhbmcsV2VpbWluZyANCiAgQ2M6IGZvcmNlcy1wcm90b2NvbEBpZXRmLm9y ZyANCiAgU2VudDogU2F0dXJkYXksIE1heSAyMiwgMjAwNCA2OjUwIEFNDQogIFN1YmplY3Q6IFJF OiBbRm9yY2VzLXByb3RvY29sXSBTdW1tYXJ5IG9mIFByb3RvY29sIE1lc3NhZ2VzIChDb21tYW5k IFR5cGVzKQ0KDQoNCiAgSGkgUm9iZXJ0LA0KDQogIFRoZSBiYXNpYyByZWFzb24gZm9yIGhhdmlu ZyBhbiBFdmVudCBNc2cgaXMgdG8gcmVwb3J0IEFzeW5jaHJvbm91cyBldmVudHMgZnJvbSBGRSAt PiBDRS4gV2UgZXh0ZW5kZWQgdGhpcyB1c2UgdG8gYWNjb21tb2RhdGUgU3Vic2NyaWJlL1Vuc3Vi c2NyaWJlIGZ1bmN0aW9ucyBiYXNlZCBvbiBZb3VyIGFuZCBXZWltaW5nJ3MgcHJlZmVyZW5jZXMu IEl0IHNlZW1zIGxpa2UgeW91IGFyZSBoYXZpbmcgZGlmZmVyZW50IHRob3VnaHRzIG9uIHRoaXMg bm93LCB3aGljaCBpcyBmaW5lLiBJIHRoaW5rIHlvdSB3b3VsZCBsaWtlIGlzIHRvIGhhdmUgU3Vi c2NyaWJlL1Vuc3Vic2NyaWJlIGFzIHBhcnQgb2YgQ29uZmlnIHJhdGhlciB0aGFuIEV2ZW50IG1z Zy4gVGhpcyBpcyBmaW5lIGJ5IG1lLCBhbmQgSSB0aGluayBXZWltaW5nIHdpbGwgYWxzbyBiZSBm aW5lIHRvIGFjY29tbW9kYXRlIHRoaXMgc2luY2UgdGhpcyB3YXMgb25lIG9mIHRoZSBvcHRpb25z IHRoYXQgaGUgaGFkIHN0YXRlZCBiZWZvcmUuIA0KDQogIFdlaW1pbmcsIGxldCB1cyBrbm93IHdo YXQgeW91IHRoaW5rIGFib3V0IHRoaXMgPyBJZiB3ZSBnbyB3aXRoIHRoaXMgYXBwcm9hY2gsIHdl IHdpbGwgcHJvYmFibHkgbm90IG5lZWQgUmVzcG9uc2UgZm9yIEV2ZW50IG1zZ3MuDQoNCiAgVGhh bmtzDQogIEhvcm11emQNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICBI ZXJlIGlzIGFub3RoZXIgZXhhbXBsZSBpbiB3aGljaCBJIHRoaW5rIHdlIG1heSBuZWVkIHRvIGR5 bmFtaWNhbGx5IHN1YnNjcmliZSB0byBldmVudHM6DQoNCiAgICAgICAgVGhlIENFIGFkZHMgYSBm aWx0ZXJpbmcgcnVsZSwgYW5kIGF0IHRoZSBzYW1lIHRpbWUgcmVxdWlyZXMgZXZlbnQgdG8gYmUg ZmlyZWQgd2hlbmV2ZXIgYSBwYWNrZXQgbWF0Y2hlcyB0aGlzIHJ1bGUuIFRoaXMgY2FuIGJlIGZv ciB0aGUgcHVycG9zZSBvZiBEb1MgZGV0ZWN0aW9uLCBmb3IgaW5zdGFuY2UuDQoNCiAgICAgICAg TGV0IG1lIGtub3cgaWYgdGhpcyBpcyBhIGNvbnZpbmNpbmcgZXhhbXBsZS4gDQoNCiAgICAgICAg W0hLXSBJIGRvbid0IHRoaW5rIHdlIHdpbGwgYmUgc3Vic2NyaWJpbmcgdG8gZXZlbnRzIGF0IHRo aXMgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIEZyb20gbXkgbGl0dGxlIGV4cGVyaWVuY2UgYXQgdGhl IE5QRiBhbmQgd2hhdCBJIGhhdmUgc2VlbiBmcm9tIHRoZSBNb2RlbCB0ZWFtLCBldmVudHMgd2ls bCBiZSBkZWZpbmVkIG9uIHBlciBMRkIgYmFzaXMuIFRoZSBleGFtcGxlIHRoYXQgeW91IGhhdmUg Z2l2ZW4gaGVyZSBpcyBhIGxvdCBtb3JlIGdyYW51bGFyLCBpLmUuIHBlciBlbnRyeSBiYXNpcyBp biBhIExGQiB0YWJsZS4gSSBkb250IHRoaW5rIHRoaXMgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgd2ls bCBiZSBzdXBwb3J0ZWQuDQogICAgSSB3b24ndCBhcmd1ZSBhZ2FpbnN0IHRoZSBmYWN0IHRoYXQg aXMgaXMgdW5zY2FsYWJsZSB0byBsZXQgZXZlcnkgZmlyZXdhbGxpbmcgcnVsZSBmaXJlIHVwIGFu IGV2ZW50LiBOZXZlcnRoZWxlc3MsIHRoaXMgY2FuIGJlIHVzZWZ1bCBmb3Igc29tZSBvZiB0aGUg ZmlyZXdhbGxpbmcgcnVsZXMgKGludHJ1c2lvbiBkZXRlY3Rpb24gaXMgYW5vdGhlciBleGFtcGxl KS4NCg0KICAgIEkgaG9wZSB0aGF0IHRoZSBtb2RlbCB3aWxsIG5vdCBvbmx5IGFsbG93IHBlci1M RkIgZXZlbnRzIG9yIEkgd291bGQgY29uc2lkZXIgdGhpcyBhIGJhZCBkZXNpZ24uICBXZSBzaG91 bGQgZGVzaWduIG91ciBwcm90b2NvbCBzbyB0aGF0IGl0IGNhbiBiZSB1c2VkIGluIHN1Y2ggY2Fz ZXMgKGkuZS4sIGFkZGluZyBhIHJ1bGUgYW5kIHN1YnNjcmliaW5nIHRvIGFuIGV2ZW50IG9mIHRo YXQgcnVsZSkuDQoNCiAgICBJIG5vdGUgdGhhdCBoYXZpbmcgYSAiQ29uZmlnIiBvciAiRXZlbnQi IG1lc3NhZ2UgdHlwZSBpbiB0aGUgY29tbW9uIGhlYWRlciBmb3JjZXMgdXMgdG8gc2VuZCB0d28g c2VwYXJhdGUgbWVzc2FnZXMgdG8gdGhlIHNhbWUgTEZCLiBOb3QgYSBncmVhdCB0aGluZywgZXNw ZWNpYWxseSBzaW5jZSBmdW5kYW1lbnRhbGx5LCB0aGVyZSBpcyBsaXR0bGUgdmFsdWUgdG8gc2Vw YXJhdGUgdGhlIENvbmZpZyBhbmQgRXZlbnQgdHlwZXMgYXQgdGhlIENvbW1vbi1IZWFkZXIgbGV2 ZWwuIA0KDQogICAgTWF5YmUgb3RoZXJzIGhhdmUgb3BpbmlvbiBvbiB0aGlzIHRvbyA/DQoNCiAg ICBSZWdhcmRzLA0KICAgIC1Sb2JlcnQgDQo= ------=_NextPart_000_04AF_01C44182.47879BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZ TEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHRleHQ9IzAwMDAwMCBiZ0NvbG9yPSNmZmZmZmY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIEhvcm11emQsIFJvYmVydCwgYW5kIGFs bCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+U29ycnkgcmVwbHkgdG8geW91 IHZlcnkgbGF0ZSwgZm9yIEkgd2FzIHZlcnkgYnVzeSANCmxhc3Qgd2Vla2RheXMgZm9yIHVuaXYu IGJ1c2luZXNzIGFuZCBidXN5IHdyaXRpbmcgbXkgZHJhZnQgcGFydCBkdXJpbmcgdGhlIA0Kd2Vl a2VuZC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgYWdyZWUgdG8gbGV0 IGNvbmZpZyBtc2cgZG8gdGhlIHN1Yi91bnN1YiBvZiANCmV2ZW50cy4gQWN0dWFsbHkgaW4gdGhp cyBjYXNlLCB0aGUgJ0V2ZW50Q29uZmcnIGFzIEkgbWVudGlvbmVkIGVhbGllciBjYW4gYWxzbyAN CmJlIHB1dCBpbiB0aGUgJ0NvbmZpZycgbXNnLCBsZWF2aW5nIHRoZSBldmVudCBtc2cgb25seSBm b3IgJ2V2ZW50IHJlcG9ydCcgYW5kIA0KJ2V2ZW50IHJlc3BvbnNlJy4gSSB0aGluayBldmVudCBy ZXNwb25zZSBhcyBhIG1lc3NhZ2Ugc2hvdWxkIGJlIHB1dCB0aGVyZSwgDQp3aGV0aGVyIGN1c3Rv bWVycyB1c2UgaXQgd2lsbCBiZSBkZWNpZGVkIGJ5IHRoZSBSZXNwb25zZSBmbGFnIGluIHRoZSBo ZWFkZXIuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5rIHlvdS48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIDwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAw cHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAw MDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViANCiAgc3R5bGU9IkJB Q0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48 Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20gDQog IGhyZWY9Im1haWx0bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwgSG9y bXV6ZCBNPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+VG86 PC9CPiA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gDQogIGhyZWY9Im1haWx0bzpyaGFAenVy aWNoLmlibS5jb20iPlJvYmVydCBIYWFzPC9BPiA7IDxBIA0KICB0aXRsZT13bXdhbmdAbWFpbC5o emljLmVkdS5jbiANCiAgaHJlZj0ibWFpbHRvOndtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIj5XYW5n LFdlaW1pbmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5D Yzo8L0I+IDxBIHRpdGxlPWZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRv OmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPiA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U2VudDo8L0I+IFNhdHVy ZGF5LCBNYXkgMjIsIDIwMDQgNjo1MCANCkFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEw cHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gU3VtbWFyeSBv ZiANCiAgUHJvdG9jb2wgTWVzc2FnZXMgKENvbW1hbmQgVHlwZXMpPC9ESVY+DQogIDxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFz cz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5IaSANCiAgUm9iZXJ0LDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 NDUwMjIzNTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NDUwMjIz NTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhlIA0K ICBiYXNpYyByZWFzb24gZm9yIGhhdmluZyBhbiBFdmVudCBNc2cgaXMgdG8gcmVwb3J0IEFzeW5j aHJvbm91cyBldmVudHMgZnJvbSBGRSANCiAgLSZndDsgQ0UuIFdlIGV4dGVuZGVkIHRoaXMgdXNl IHRvIGFjY29tbW9kYXRlIFN1YnNjcmliZS9VbnN1YnNjcmliZSBmdW5jdGlvbnMgDQogIGJhc2Vk IG9uIFlvdXIgYW5kIFdlaW1pbmcncyBwcmVmZXJlbmNlcy4gSXQgc2VlbXMgbGlrZSB5b3UgYXJl Jm5ic3A7aGF2aW5nIA0KICBkaWZmZXJlbnQgdGhvdWdodHMgb24gdGhpcyBub3csIHdoaWNoIGlz IGZpbmUuIEkgdGhpbmsmbmJzcDt5b3Ugd291bGQgbGlrZSBpcyANCiAgdG8gaGF2ZSBTdWJzY3Jp YmUvVW5zdWJzY3JpYmUgYXMgcGFydCBvZiBDb25maWcgcmF0aGVyIHRoYW4gRXZlbnQgbXNnLiBU aGlzIGlzIA0KICBmaW5lIGJ5IG1lLCBhbmQgSSB0aGluayBXZWltaW5nIHdpbGwgYWxzbyBiZSBm aW5lIHRvIGFjY29tbW9kYXRlIHRoaXMgc2luY2UgDQogIHRoaXMgd2FzIG9uZSBvZiB0aGUgb3B0 aW9ucyB0aGF0IGhlIGhhZCBzdGF0ZWQgYmVmb3JlLiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8 RElWPjxTUEFOIGNsYXNzPTQ1MDIyMzUyMi0yMTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxT UEFOIGNsYXNzPTQ1MDIyMzUyMi0yMTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgDQogIHNpemU9Mj5XZWltaW5nLCBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluayBhYm91dCB0 aGlzID8gSWYgd2UgZ28gd2l0aCB0aGlzIA0KICBhcHByb2FjaCwgd2Ugd2lsbCBwcm9iYWJseSBu b3QgbmVlZCBSZXNwb25zZSBmb3IgRXZlbnQgDQogIG1zZ3MuPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgPERJVj48U1BBTiBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJ Vj48U1BBTiBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICBzaXplPTI+VGhhbmtzPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0KICBzaXplPTI+SG9ybXV6ZDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGRp cj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWPjwvRElWPg0KICAgIDxE SVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxl ZnQ+PEZPTlQgDQogICAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPC9GT05UPjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIGNpdGU9bWlkNDY4RjNGREEy OEFBODc0MjlBRDgwNzk5MkUyMkQwN0UwMTE2NEUyMkBvcnNtc3g0MDguamYuaW50ZWwuY29tIA0K ICAgIHR5cGU9ImNpdGUiPg0KICAgICAgPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lO LVJJR0hUOiAwcHgiPg0KICAgICAgICA8RElWPkhlcmUgaXMgYW5vdGhlciBleGFtcGxlIGluIHdo aWNoIEkgdGhpbmsgd2UgbWF5IG5lZWQgdG8gZHluYW1pY2FsbHkgDQogICAgICAgIHN1YnNjcmli ZSB0byBldmVudHM6PEJSPjxCUj5UaGUgQ0UgYWRkcyBhIGZpbHRlcmluZyBydWxlLCBhbmQgYXQg dGhlIA0KICAgICAgICBzYW1lIHRpbWUgcmVxdWlyZXMgZXZlbnQgdG8gYmUgZmlyZWQgd2hlbmV2 ZXIgYSBwYWNrZXQgbWF0Y2hlcyB0aGlzIA0KICAgICAgICBydWxlLiBUaGlzIGNhbiBiZSBmb3Ig dGhlIHB1cnBvc2Ugb2YgRG9TIGRldGVjdGlvbiwgZm9yIA0KICAgICAgICBpbnN0YW5jZS48QlI+ PEJSPkxldCBtZSBrbm93IGlmIHRoaXMgaXMgYSBjb252aW5jaW5nIGV4YW1wbGUuPFNQQU4gDQog ICAgICAgIGNsYXNzPTQwMzAyMDUwMS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQogICAgICAgIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAg ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAg ICAgPERJVj48U1BBTiBjbGFzcz00MDMwMjA1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIA0KICAgICAgICBzaXplPTI+W0hLXTwvRk9OVD4mbmJzcDs8Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkkgZG9uJ3QgDQogICAgICAgIHRoaW5rIHdlIHdp bGwgYmUgc3Vic2NyaWJpbmcgdG8gZXZlbnRzIGF0IHRoaXMgbGV2ZWwgDQogICAgICAgIG9mJm5i c3A7Z3JhbnVsYXJpdHkuIEZyb20gbXkgbGl0dGxlIGV4cGVyaWVuY2UgYXQgdGhlIE5QRiBhbmQg d2hhdCBJIA0KICAgICAgICBoYXZlIHNlZW4gZnJvbSB0aGUgTW9kZWwgdGVhbSwgZXZlbnRzIHdp bGwgYmUgZGVmaW5lZCBvbiBwZXIgTEZCIGJhc2lzLiANCiAgICAgICAgVGhlIGV4YW1wbGUgdGhh dCB5b3UgaGF2ZSBnaXZlbiBoZXJlIGlzIGEgbG90IG1vcmUgZ3JhbnVsYXIsIGkuZS4gcGVyIA0K ICAgICAgICBlbnRyeSBiYXNpcyBpbiBhIExGQiB0YWJsZS4gSSBkb250IHRoaW5rIHRoaXMgbGV2 ZWwgb2YmbmJzcDtncmFudWxhcml0eSANCiAgICAgICAgd2lsbCBiZSBzdXBwb3J0ZWQuPC9GT05U PjwvU1BBTj48L0RJVj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPkkgd29uJ3QgDQogICAgYXJn dWUgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IGlzIGlzIHVuc2NhbGFibGUgdG8gbGV0IGV2ZXJ5IGZp cmV3YWxsaW5nIHJ1bGUgDQogICAgZmlyZSB1cCBhbiBldmVudC4gTmV2ZXJ0aGVsZXNzLCB0aGlz IGNhbiBiZSB1c2VmdWwgZm9yIHNvbWUgb2YgdGhlIA0KICAgIGZpcmV3YWxsaW5nIHJ1bGVzIChp bnRydXNpb24gZGV0ZWN0aW9uIGlzIGFub3RoZXIgZXhhbXBsZSkuPEJSPjxCUj5JIGhvcGUgDQog ICAgdGhhdCB0aGUgbW9kZWwgd2lsbCBub3Qgb25seSBhbGxvdyBwZXItTEZCIGV2ZW50cyBvciBJ IHdvdWxkIGNvbnNpZGVyIHRoaXMgYSANCiAgICBiYWQgZGVzaWduLiZuYnNwOyBXZSBzaG91bGQg ZGVzaWduIG91ciBwcm90b2NvbCBzbyB0aGF0IGl0IGNhbiBiZSB1c2VkIGluIA0KICAgIHN1Y2gg Y2FzZXMgKGkuZS4sIGFkZGluZyBhIHJ1bGUgYW5kIHN1YnNjcmliaW5nIHRvIGFuIGV2ZW50IG9m IHRoYXQgDQogICAgcnVsZSkuPEJSPjxCUj5JIG5vdGUgdGhhdCBoYXZpbmcgYSAiQ29uZmlnIiBv ciAiRXZlbnQiIG1lc3NhZ2UgdHlwZSBpbiB0aGUgDQogICAgY29tbW9uIGhlYWRlciBmb3JjZXMg dXMgdG8gc2VuZCB0d28gc2VwYXJhdGUgbWVzc2FnZXMgdG8gdGhlIHNhbWUgTEZCLiBOb3QgYSAN CiAgICBncmVhdCB0aGluZywgZXNwZWNpYWxseSBzaW5jZSBmdW5kYW1lbnRhbGx5LCB0aGVyZSBp cyBsaXR0bGUgdmFsdWUgdG8gDQogICAgc2VwYXJhdGUgdGhlIENvbmZpZyBhbmQgRXZlbnQgdHlw ZXMgYXQgdGhlIENvbW1vbi1IZWFkZXIgbGV2ZWwuIA0KICAgIDxCUj48QlI+TWF5YmUgb3RoZXJz IGhhdmUgb3BpbmlvbiBvbiB0aGlzIHRvbyANCiAgICA/PEJSPjxCUj5SZWdhcmRzLDxCUj4tUm9i ZXJ0PFNQQU4gY2xhc3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogICAg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvQkxPQ0tRVU9URT48 L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_04AF_01C44182.47879BC0-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 24 00:06: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 AAA24857 for ; Mon, 24 May 2004 00: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 1BS6aD-0004Rm-Kq for forces-protocol-archive@odin.ietf.org; Sun, 23 May 2004 23:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O3v1Dv017082 for forces-protocol-archive@odin.ietf.org; Sun, 23 May 2004 23: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 1BS6YJ-00045m-1Y for forces-protocol-web-archive@optimus.ietf.org; Sun, 23 May 2004 23:55: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 XAA24591 for ; Sun, 23 May 2004 23:54: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 1BS6YG-0006PW-Ml for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6XN-000699-00 for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23:54:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS6Wm-0005se-00 for forces-protocol-web-archive@ietf.org; Sun, 23 May 2004 23: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 1BS6QW-0003Fy-7G; Sun, 23 May 2004 23:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6Mm-0002eF-Pk for forces-protocol@optimus.ietf.org; Sun, 23 May 2004 23:43: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 XAA24185 for ; Sun, 23 May 2004 23:43: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 1BS6Mk-0003Ah-Lj for forces-protocol@ietf.org; Sun, 23 May 2004 23:43:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6Lj-0002uT-00 for forces-protocol@ietf.org; Sun, 23 May 2004 23:42:05 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BS6LO-0002e1-00 for forces-protocol@ietf.org; Sun, 23 May 2004 23:41:42 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4O3f9Ng030668; Mon, 24 May 2004 03:41:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4O3fVwS010536; Mon, 24 May 2004 03:41:45 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 M2004052320410609916 ; Sun, 23 May 2004 20:41:06 -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, 23 May 2004 20:40:30 -0700 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_01C44140.DBEFF227" Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Message-ID: <468F3FDA28AA87429AD807992E22D07E0122F42C@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary of Protocol Messages (Command Types) Thread-Index: AcRBQFq0hLf6YNVWQTu8qSjNWzGSgwAAFuKg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 24 May 2004 03:40:30.0073 (UTC) FILETIME=[DC2AEE90:01C44140] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 23 May 2004 20:40: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.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C44140.DBEFF227 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Weiming, for your reply. This is helpful since I am writing up the Config msg. =20 regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Sunday, May 23, 2004 8:29 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) Hi Hormuzd, Robert, and all, =20 Sorry reply to you very late, for I was very busy last weekdays for univ. business and busy writing my draft part during the weekend.=20 =20 I agree to let config msg do the sub/unsub of events. Actually in this case, the 'EventConfg' as I mentioned ealier can also be put in the 'Config' msg, leaving the event msg only for 'event report' and 'event response'. I think event response as a message should be put there, whether customers use it will be decided by the Response flag in the header.=20 =20 Thank you. Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Robert Haas ; Wang,Weiming =20 Cc: forces-protocol@ietf.org=20 Sent: Saturday, May 22, 2004 6:50 AM Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Hi Robert, =20 The basic reason for having an Event Msg is to report Asynchronous events from FE -> CE. We extended this use to accommodate Subscribe/Unsubscribe functions based on Your and Weiming's preferences. It seems like you are having different thoughts on this now, which is fine. I think you would like is to have Subscribe/Unsubscribe as part of Config rather than Event msg. This is fine by me, and I think Weiming will also be fine to accommodate this since this was one of the options that he had stated before.=20 =20 Weiming, let us know what you think about this ? If we go with this approach, we will probably not need Response for Event msgs. =20 Thanks Hormuzd -----Original Message----- Here is another example in which I think we may need to dynamically subscribe to events: The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance. Let me know if this is a convincing example.=20 =20 [HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported. I won't argue against the fact that is is unscalable to let every firewalling rule fire up an event. Nevertheless, this can be useful for some of the firewalling rules (intrusion detection is another example). I hope that the model will not only allow per-LFB events or I would consider this a bad design. We should design our protocol so that it can be used in such cases (i.e., adding a rule and subscribing to an event of that rule). I note that having a "Config" or "Event" message type in the common header forces us to send two separate messages to the same LFB. Not a great thing, especially since fundamentally, there is little value to separate the Config and Event types at the Common-Header level.=20 Maybe others have opinion on this too ? Regards, -Robert=20 ------_=_NextPart_001_01C44140.DBEFF227 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks=20 Weiming, for your reply. This is helpful since I am writing up the = Config=20 msg.
 
regards
Hormuzd
-----Original Message-----
From:=20 forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] = On=20 Behalf Of Wang,Weiming
Sent: Sunday, May 23, 2004 8:29=20 PM
To: forces-protocol@ietf.org
Subject: Re:=20 [Forces-protocol] Summary of Protocol Messages (Command=20 Types)

Hi Hormuzd, Robert, and = all,
 
Sorry reply to you very late, for I = was very busy=20 last weekdays for univ. business and busy writing my draft part during = the=20 weekend.
 
I agree to let config msg do the = sub/unsub of=20 events. Actually in this case, the 'EventConfg' as I mentioned ealier = can also=20 be put in the 'Config' msg, leaving the event msg only for 'event = report' and=20 'event response'. I think event response as a message should be put = there,=20 whether customers use it will be decided by the Response flag in the = header.=20
 
Thank you.
Weiming
 
----- Original Message -----
From:=20 Khosravi, Hormuzd M =
To: Robert Haas ; Wang,Weiming
Sent: Saturday, May 22, 2004 = 6:50=20 AM
Subject: RE: = [Forces-protocol] Summary=20 of Protocol Messages (Command Types)

Hi=20 Robert,
 
The basic reason for having an Event Msg is to report = Asynchronous=20 events from FE -> CE. We extended this use to accommodate=20 Subscribe/Unsubscribe functions based on Your and Weiming's = preferences. It=20 seems like you are having different thoughts on this now, which = is=20 fine. I think you would like is to have Subscribe/Unsubscribe = as part=20 of Config rather than Event msg. This is fine by me, and I think = Weiming=20 will also be fine to accommodate this since this was one of the = options that=20 he had stated before.
 
Weiming, let us know what you think about this ? If we go = with this=20 approach, we will probably not need Response for Event=20 msgs.
 
Thanks
Hormuzd
-----Original Message-----
Here is another example in which I think we may need to=20 dynamically subscribe to events:

The CE adds a = filtering rule,=20 and at the same time requires event to be fired whenever a = packet=20 matches this rule. This can be for the purpose of DoS = detection, for=20 instance.

Let me know if this is a convincing = example. 
 
[HK] I don't=20 think we will be subscribing to events at this level=20 of granularity. From my little experience at the NPF and = what I=20 have seen from the Model team, events will be defined on per = LFB=20 basis. The example that you have given here is a lot more = granular,=20 i.e. per entry basis in a LFB table. I dont think this level=20 of granularity will be=20 supported.
I won't = argue=20 against the fact that is is unscalable to let every firewalling = rule fire=20 up an event. Nevertheless, this can be useful for some of the = firewalling=20 rules (intrusion detection is another example).

I hope that = the=20 model will not only allow per-LFB events or I would consider this = a bad=20 design.  We should design our protocol so that it can be used = in such=20 cases (i.e., adding a rule and subscribing to an event of that=20 rule).

I note that having a "Config" or "Event" message = type in the=20 common header forces us to send two separate messages to the same = LFB. Not=20 a great thing, especially since fundamentally, there is little = value to=20 separate the Config and Event types at the Common-Header level.=20

Maybe others have opinion on this too=20 ?

Regards,
-Robert 
------_=_NextPart_001_01C44140.DBEFF227-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 24 00:27:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25513 for ; Mon, 24 May 2004 00:27: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 1BS71h-00009n-Nm for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 00:25:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O4PPqA000596 for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 00:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6yO-00088T-Cx for forces-protocol-web-archive@optimus.ietf.org; Mon, 24 May 2004 00:22: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 AAA25346 for ; Mon, 24 May 2004 00:21: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 1BS6yL-0005qm-KG for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:21:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6xM-0005aY-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:20:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS6wL-0005Cc-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:19:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6vV-0007ex-5Q; Mon, 24 May 2004 00: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 1BS6sa-0007Gc-0M for forces-protocol@optimus.ietf.org; Mon, 24 May 2004 00:16: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 AAA25160 for ; Mon, 24 May 2004 00:15: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 1BS6sX-0004Ee-K7 for forces-protocol@ietf.org; Mon, 24 May 2004 00:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6rY-0003xX-00 for forces-protocol@ietf.org; Mon, 24 May 2004 00:14:57 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BS6qK-0003Rl-00 for forces-protocol@ietf.org; Mon, 24 May 2004 00:13:40 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 24 May 2004 12:26:38 +0800 Message-ID: <04ea01c44145$6e24f080$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E0122F42C@orsmsx408.jf.intel.com> Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E7_01C44188.7BFBE540" 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, 24 May 2004 12:13: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=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_04E7_01C44188.7BFBE540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 TWVzc2FnZUhpIEhvcm11emQsDQoNCk9uZSBtb3JlIHRoaW5nIGlzIGFib3V0IHRoZSBUZkxWLiAg SSBhZ3JlZSB0aGF0IHNvbWUgZmxhZ3MgcmVsYXRlZCB0byBhdG9taWMgb3BzIGNhbiBiZSBhcyBm bGFncy4gVGhlIG9ubHkgdGhpbmcgaXMsIEkgdGhpbmsgYXRvbWljIG9wcyB3aWxsIG1haW5seSBo YXBwZW5zIGluIGNvbmZpZyBtc2dzLiAodGhvdWdoIG5vdCB2ZXJ5IHN1cmUpLiB0aGVyZWZvcmUs IGluIHRoZSBtc2dzIHRoYXQgaSdtIHRvIHB1dCwgdGhlIGZsYWdzIHN0aWxsIGhhdmUgbm90IGJl ZW4gY29uc2lkZXJlZC4gQnV0IEkgdGhpbmsgaXQgY2FuIGJlIG1vZGlmaWVkIGVhc2lseSBsYXRl ciBpZiBuZWVkZWQuDQoNCkNoZWVycywNCldlaW1pbmcNCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICBUbzogV2FuZyxXZWlt aW5nIDsgZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBTZW50OiBNb25kYXksIE1heSAyNCwg MjAwNCAxMTo0MCBBTQ0KICBTdWJqZWN0OiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gU3VtbWFyeSBv ZiBQcm90b2NvbCBNZXNzYWdlcyAoQ29tbWFuZCBUeXBlcykNCg0KDQogIFRoYW5rcyBXZWltaW5n LCBmb3IgeW91ciByZXBseS4gVGhpcyBpcyBoZWxwZnVsIHNpbmNlIEkgYW0gd3JpdGluZyB1cCB0 aGUgQ29uZmlnIG1zZy4NCg0KICByZWdhcmRzDQogIEhvcm11emQNCiAgICAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IGZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZyBb bWFpbHRvOmZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdhbmcs V2VpbWluZw0KICAgIFNlbnQ6IFN1bmRheSwgTWF5IDIzLCAyMDA0IDg6MjkgUE0NCiAgICBUbzog Zm9yY2VzLXByb3RvY29sQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9j b2xdIFN1bW1hcnkgb2YgUHJvdG9jb2wgTWVzc2FnZXMgKENvbW1hbmQgVHlwZXMpDQoNCg0KICAg IEhpIEhvcm11emQsIFJvYmVydCwgYW5kIGFsbCwNCg0KICAgIFNvcnJ5IHJlcGx5IHRvIHlvdSB2 ZXJ5IGxhdGUsIGZvciBJIHdhcyB2ZXJ5IGJ1c3kgbGFzdCB3ZWVrZGF5cyBmb3IgdW5pdi4gYnVz aW5lc3MgYW5kIGJ1c3kgd3JpdGluZyBteSBkcmFmdCBwYXJ0IGR1cmluZyB0aGUgd2Vla2VuZC4g DQoNCiAgICBJIGFncmVlIHRvIGxldCBjb25maWcgbXNnIGRvIHRoZSBzdWIvdW5zdWIgb2YgZXZl bnRzLiBBY3R1YWxseSBpbiB0aGlzIGNhc2UsIHRoZSAnRXZlbnRDb25mZycgYXMgSSBtZW50aW9u ZWQgZWFsaWVyIGNhbiBhbHNvIGJlIHB1dCBpbiB0aGUgJ0NvbmZpZycgbXNnLCBsZWF2aW5nIHRo ZSBldmVudCBtc2cgb25seSBmb3IgJ2V2ZW50IHJlcG9ydCcgYW5kICdldmVudCByZXNwb25zZScu IEkgdGhpbmsgZXZlbnQgcmVzcG9uc2UgYXMgYSBtZXNzYWdlIHNob3VsZCBiZSBwdXQgdGhlcmUs IHdoZXRoZXIgY3VzdG9tZXJzIHVzZSBpdCB3aWxsIGJlIGRlY2lkZWQgYnkgdGhlIFJlc3BvbnNl IGZsYWcgaW4gdGhlIGhlYWRlci4gDQoNCiAgICBUaGFuayB5b3UuDQogICAgV2VpbWluZw0KDQog ICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICAgIEZyb206IEtob3NyYXZpLCBI b3JtdXpkIE0gDQogICAgICBUbzogUm9iZXJ0IEhhYXMgOyBXYW5nLFdlaW1pbmcgDQogICAgICBD YzogZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICAgICAgU2VudDogU2F0dXJkYXksIE1heSAy MiwgMjAwNCA2OjUwIEFNDQogICAgICBTdWJqZWN0OiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gU3Vt bWFyeSBvZiBQcm90b2NvbCBNZXNzYWdlcyAoQ29tbWFuZCBUeXBlcykNCg0KDQogICAgICBIaSBS b2JlcnQsDQoNCiAgICAgIFRoZSBiYXNpYyByZWFzb24gZm9yIGhhdmluZyBhbiBFdmVudCBNc2cg aXMgdG8gcmVwb3J0IEFzeW5jaHJvbm91cyBldmVudHMgZnJvbSBGRSAtPiBDRS4gV2UgZXh0ZW5k ZWQgdGhpcyB1c2UgdG8gYWNjb21tb2RhdGUgU3Vic2NyaWJlL1Vuc3Vic2NyaWJlIGZ1bmN0aW9u cyBiYXNlZCBvbiBZb3VyIGFuZCBXZWltaW5nJ3MgcHJlZmVyZW5jZXMuIEl0IHNlZW1zIGxpa2Ug eW91IGFyZSBoYXZpbmcgZGlmZmVyZW50IHRob3VnaHRzIG9uIHRoaXMgbm93LCB3aGljaCBpcyBm aW5lLiBJIHRoaW5rIHlvdSB3b3VsZCBsaWtlIGlzIHRvIGhhdmUgU3Vic2NyaWJlL1Vuc3Vic2Ny aWJlIGFzIHBhcnQgb2YgQ29uZmlnIHJhdGhlciB0aGFuIEV2ZW50IG1zZy4gVGhpcyBpcyBmaW5l IGJ5IG1lLCBhbmQgSSB0aGluayBXZWltaW5nIHdpbGwgYWxzbyBiZSBmaW5lIHRvIGFjY29tbW9k YXRlIHRoaXMgc2luY2UgdGhpcyB3YXMgb25lIG9mIHRoZSBvcHRpb25zIHRoYXQgaGUgaGFkIHN0 YXRlZCBiZWZvcmUuIA0KDQogICAgICBXZWltaW5nLCBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGlu ayBhYm91dCB0aGlzID8gSWYgd2UgZ28gd2l0aCB0aGlzIGFwcHJvYWNoLCB3ZSB3aWxsIHByb2Jh Ymx5IG5vdCBuZWVkIFJlc3BvbnNlIGZvciBFdmVudCBtc2dzLg0KDQogICAgICBUaGFua3MNCiAg ICAgIEhvcm11emQNCiAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICAgICAg ICAgIEhlcmUgaXMgYW5vdGhlciBleGFtcGxlIGluIHdoaWNoIEkgdGhpbmsgd2UgbWF5IG5lZWQg dG8gZHluYW1pY2FsbHkgc3Vic2NyaWJlIHRvIGV2ZW50czoNCg0KICAgICAgICAgICAgVGhlIENF IGFkZHMgYSBmaWx0ZXJpbmcgcnVsZSwgYW5kIGF0IHRoZSBzYW1lIHRpbWUgcmVxdWlyZXMgZXZl bnQgdG8gYmUgZmlyZWQgd2hlbmV2ZXIgYSBwYWNrZXQgbWF0Y2hlcyB0aGlzIHJ1bGUuIFRoaXMg Y2FuIGJlIGZvciB0aGUgcHVycG9zZSBvZiBEb1MgZGV0ZWN0aW9uLCBmb3IgaW5zdGFuY2UuDQoN CiAgICAgICAgICAgIExldCBtZSBrbm93IGlmIHRoaXMgaXMgYSBjb252aW5jaW5nIGV4YW1wbGUu IA0KDQogICAgICAgICAgICBbSEtdIEkgZG9uJ3QgdGhpbmsgd2Ugd2lsbCBiZSBzdWJzY3JpYmlu ZyB0byBldmVudHMgYXQgdGhpcyBsZXZlbCBvZiBncmFudWxhcml0eS4gRnJvbSBteSBsaXR0bGUg ZXhwZXJpZW5jZSBhdCB0aGUgTlBGIGFuZCB3aGF0IEkgaGF2ZSBzZWVuIGZyb20gdGhlIE1vZGVs IHRlYW0sIGV2ZW50cyB3aWxsIGJlIGRlZmluZWQgb24gcGVyIExGQiBiYXNpcy4gVGhlIGV4YW1w bGUgdGhhdCB5b3UgaGF2ZSBnaXZlbiBoZXJlIGlzIGEgbG90IG1vcmUgZ3JhbnVsYXIsIGkuZS4g cGVyIGVudHJ5IGJhc2lzIGluIGEgTEZCIHRhYmxlLiBJIGRvbnQgdGhpbmsgdGhpcyBsZXZlbCBv ZiBncmFudWxhcml0eSB3aWxsIGJlIHN1cHBvcnRlZC4NCiAgICAgICAgSSB3b24ndCBhcmd1ZSBh Z2FpbnN0IHRoZSBmYWN0IHRoYXQgaXMgaXMgdW5zY2FsYWJsZSB0byBsZXQgZXZlcnkgZmlyZXdh bGxpbmcgcnVsZSBmaXJlIHVwIGFuIGV2ZW50LiBOZXZlcnRoZWxlc3MsIHRoaXMgY2FuIGJlIHVz ZWZ1bCBmb3Igc29tZSBvZiB0aGUgZmlyZXdhbGxpbmcgcnVsZXMgKGludHJ1c2lvbiBkZXRlY3Rp b24gaXMgYW5vdGhlciBleGFtcGxlKS4NCg0KICAgICAgICBJIGhvcGUgdGhhdCB0aGUgbW9kZWwg d2lsbCBub3Qgb25seSBhbGxvdyBwZXItTEZCIGV2ZW50cyBvciBJIHdvdWxkIGNvbnNpZGVyIHRo aXMgYSBiYWQgZGVzaWduLiAgV2Ugc2hvdWxkIGRlc2lnbiBvdXIgcHJvdG9jb2wgc28gdGhhdCBp dCBjYW4gYmUgdXNlZCBpbiBzdWNoIGNhc2VzIChpLmUuLCBhZGRpbmcgYSBydWxlIGFuZCBzdWJz Y3JpYmluZyB0byBhbiBldmVudCBvZiB0aGF0IHJ1bGUpLg0KDQogICAgICAgIEkgbm90ZSB0aGF0 IGhhdmluZyBhICJDb25maWciIG9yICJFdmVudCIgbWVzc2FnZSB0eXBlIGluIHRoZSBjb21tb24g aGVhZGVyIGZvcmNlcyB1cyB0byBzZW5kIHR3byBzZXBhcmF0ZSBtZXNzYWdlcyB0byB0aGUgc2Ft ZSBMRkIuIE5vdCBhIGdyZWF0IHRoaW5nLCBlc3BlY2lhbGx5IHNpbmNlIGZ1bmRhbWVudGFsbHks IHRoZXJlIGlzIGxpdHRsZSB2YWx1ZSB0byBzZXBhcmF0ZSB0aGUgQ29uZmlnIGFuZCBFdmVudCB0 eXBlcyBhdCB0aGUgQ29tbW9uLUhlYWRlciBsZXZlbC4gDQoNCiAgICAgICAgTWF5YmUgb3RoZXJz IGhhdmUgb3BpbmlvbiBvbiB0aGlzIHRvbyA/DQoNCiAgICAgICAgUmVnYXJkcywNCiAgICAgICAg LVJvYmVydCANCg== ------=_NextPart_000_04E7_01C44188.7BFBE540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZ TEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHRleHQ9IzAwMDAwMCBiZ0NvbG9yPSNmZmZmZmY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpIEhvcm11emQsPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPk9uZSBtb3JlIHRoaW5nIGlzIGFib3V0IHRoZSBUZkxWLiZu YnNwOyBJIGFncmVlIA0KdGhhdCBzb21lIGZsYWdzIHJlbGF0ZWQgdG8gYXRvbWljIG9wcyBjYW4g YmUgYXMgZmxhZ3MuIFRoZSBvbmx5IHRoaW5nIGlzLCBJIA0KdGhpbmsgYXRvbWljIG9wcyB3aWxs IG1haW5seSBoYXBwZW5zIGluIGNvbmZpZyBtc2dzLiAodGhvdWdoIG5vdCB2ZXJ5IHN1cmUpLiAN CnRoZXJlZm9yZSwgaW4gdGhlIG1zZ3MgdGhhdCBpJ20gdG8gcHV0LCB0aGUgZmxhZ3Mgc3RpbGwg aGF2ZSBub3QgYmVlbiANCmNvbnNpZGVyZWQuIEJ1dCBJIHRoaW5rIGl0IGNhbiBiZSBtb2RpZmll ZCBlYXNpbHkgbGF0ZXIgaWYgbmVlZGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5DaGVlcnMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5X ZWltaW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6 IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAj MDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05U OiAxMHB0IGFyaWFsIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElW IA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9aG9ybXV6ZC5tLmtob3NyYXZp QGludGVsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20i Pktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0 IGFyaWFsIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIA0KICBo cmVmPSJtYWlsdG86d213YW5nQG1haWwuaHppYy5lZHUuY24iPldhbmcsV2VpbWluZzwvQT4gOyA8 QSANCiAgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Zm9y Y2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5TZW50OjwvQj4gTW9uZGF5LCBN YXkgMjQsIDIwMDQgMTE6NDAgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlh bCI+PEI+U3ViamVjdDo8L0I+IFJFOiBbRm9yY2VzLXByb3RvY29sXSBTdW1tYXJ5IG9mIA0KICBQ cm90b2NvbCBNZXNzYWdlcyAoQ29tbWFuZCBUeXBlcyk8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ DQogIDxESVY+PFNQQU4gY2xhc3M9NjA5MjYzOTAzLTI0MDUyMDA0PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPlRoYW5rcyBXZWltaW5nLCBmb3IgeW91ciByZXBseS4g VGhpcyBpcyBoZWxwZnVsIHNpbmNlIEkgYW0gd3JpdGluZyB1cCANCiAgdGhlIENvbmZpZyBtc2cu PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz02MDkyNjM5MDMtMjQwNTIw MDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz02MDkyNjM5MDMtMjQwNTIwMDQ+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+cmVnYXJkczwvRk9OVD48L1NQ QU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NjA5MjYzOTAzLTI0MDUyMDA0PjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPkhvcm11emQ8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICA8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQog ICAgPERJVj48L0RJVj4NCiAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9 ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIA0KICAgIGZhY2U9VGFob21hIHNpemU9Mj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gPEEgDQogICAgaHJlZj0i bWFpbHRvOmZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sLWFk bWluQGlldGYub3JnPC9BPiANCiAgICBbbWFpbHRvOmZvcmNlcy1wcm90b2NvbC1hZG1pbkBpZXRm Lm9yZ10gPEI+T24gQmVoYWxmIE9mIA0KICAgIDwvQj5XYW5nLFdlaW1pbmc8QlI+PEI+U2VudDo8 L0I+IFN1bmRheSwgTWF5IDIzLCAyMDA0IDg6MjkgUE08QlI+PEI+VG86PC9CPiANCiAgICA8QSAN CiAgICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9j b2xAaWV0Zi5vcmc8L0E+PEJSPjxCPlN1YmplY3Q6PC9CPiANCiAgICBSZTogW0ZvcmNlcy1wcm90 b2NvbF0gU3VtbWFyeSBvZiBQcm90b2NvbCBNZXNzYWdlcyAoQ29tbWFuZCANCiAgICBUeXBlcyk8 QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhp IEhvcm11emQsIFJvYmVydCwgYW5kIGFsbCw8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5Tb3JyeSByZXBseSB0byB5b3UgdmVyeSBsYXRlLCBmb3IgSSB3YXMgdmVy eSANCiAgICBidXN5IGxhc3Qgd2Vla2RheXMgZm9yIHVuaXYuIGJ1c2luZXNzIGFuZCBidXN5IHdy aXRpbmcgbXkgZHJhZnQgcGFydCBkdXJpbmcgDQogICAgdGhlIHdlZWtlbmQuIDwvRk9OVD48L0RJ Vj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgYWdyZWUgdG8gbGV0IGNvbmZpZyBt c2cgZG8gdGhlIHN1Yi91bnN1YiBvZiANCiAgICBldmVudHMuIEFjdHVhbGx5IGluIHRoaXMgY2Fz ZSwgdGhlICdFdmVudENvbmZnJyBhcyBJIG1lbnRpb25lZCBlYWxpZXIgY2FuIA0KICAgIGFsc28g YmUgcHV0IGluIHRoZSAnQ29uZmlnJyBtc2csIGxlYXZpbmcgdGhlIGV2ZW50IG1zZyBvbmx5IGZv ciAnZXZlbnQgDQogICAgcmVwb3J0JyBhbmQgJ2V2ZW50IHJlc3BvbnNlJy4gSSB0aGluayBldmVu dCByZXNwb25zZSBhcyBhIG1lc3NhZ2Ugc2hvdWxkIGJlIA0KICAgIHB1dCB0aGVyZSwgd2hldGhl ciBjdXN0b21lcnMgdXNlIGl0IHdpbGwgYmUgZGVjaWRlZCBieSB0aGUgUmVzcG9uc2UgZmxhZyBp biANCiAgICB0aGUgaGVhZGVyLiA8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj5UaGFuayB5b3UuPC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+V2VpbWluZzwvRk9OVD48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAg IDxESVY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgICA8QkxPQ0tRVU9U RSBkaXI9bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDog NXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1B UkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iQkFDS0dST1VORDog I2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9C PiANCiAgICAgIDxBIHRpdGxlPWhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20gDQogICAgICBo cmVmPSJtYWlsdG86aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+S2hvc3JhdmksIEhvcm11 emQgTTwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5U bzo8L0I+IDxBIHRpdGxlPXJoYUB6dXJpY2guaWJtLmNvbSANCiAgICAgIGhyZWY9Im1haWx0bzpy aGFAenVyaWNoLmlibS5jb20iPlJvYmVydCBIYWFzPC9BPiA7IDxBIA0KICAgICAgdGl0bGU9d213 YW5nQG1haWwuaHppYy5lZHUuY24gDQogICAgICBocmVmPSJtYWlsdG86d213YW5nQG1haWwuaHpp Yy5lZHUuY24iPldhbmcsV2VpbWluZzwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05U OiAxMHB0IGFyaWFsIj48Qj5DYzo8L0I+IDxBIHRpdGxlPWZvcmNlcy1wcm90b2NvbEBpZXRmLm9y ZyANCiAgICAgIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1w cm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiAxMHB0 IGFyaWFsIj48Qj5TZW50OjwvQj4gU2F0dXJkYXksIE1heSAyMiwgMjAwNCA2OjUwIA0KICAgICAg QU08L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6 PC9CPiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gDQogICAgICBTdW1tYXJ5IG9mIFByb3RvY29sIE1l c3NhZ2VzIChDb21tYW5kIFR5cGVzKTwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48L0ZPTlQ+PEJSPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz00NTAyMjM1 MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0y PkhpIFJvYmVydCw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz00 NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNz PTQ1MDIyMzUyMi0yMTA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAg ICBzaXplPTI+VGhlIGJhc2ljIHJlYXNvbiBmb3IgaGF2aW5nIGFuIEV2ZW50IE1zZyBpcyB0byBy ZXBvcnQgQXN5bmNocm9ub3VzIA0KICAgICAgZXZlbnRzIGZyb20gRkUgLSZndDsgQ0UuIFdlIGV4 dGVuZGVkIHRoaXMgdXNlIHRvIGFjY29tbW9kYXRlIA0KICAgICAgU3Vic2NyaWJlL1Vuc3Vic2Ny aWJlIGZ1bmN0aW9ucyBiYXNlZCBvbiBZb3VyIGFuZCBXZWltaW5nJ3MgcHJlZmVyZW5jZXMuIA0K ICAgICAgSXQgc2VlbXMgbGlrZSB5b3UgYXJlJm5ic3A7aGF2aW5nIGRpZmZlcmVudCB0aG91Z2h0 cyBvbiB0aGlzIG5vdywgd2hpY2ggaXMgDQogICAgICBmaW5lLiBJIHRoaW5rJm5ic3A7eW91IHdv dWxkIGxpa2UgaXMgdG8gaGF2ZSBTdWJzY3JpYmUvVW5zdWJzY3JpYmUgYXMgcGFydCANCiAgICAg IG9mIENvbmZpZyByYXRoZXIgdGhhbiBFdmVudCBtc2cuIFRoaXMgaXMgZmluZSBieSBtZSwgYW5k IEkgdGhpbmsgV2VpbWluZyANCiAgICAgIHdpbGwgYWxzbyBiZSBmaW5lIHRvIGFjY29tbW9kYXRl IHRoaXMgc2luY2UgdGhpcyB3YXMgb25lIG9mIHRoZSBvcHRpb25zIA0KICAgICAgdGhhdCBoZSBo YWQgc3RhdGVkIGJlZm9yZS4gPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgIDxESVY+PFNQQU4g Y2xhc3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CiAgICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BB TiBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0KICAgICAgc2l6ZT0yPldlaW1pbmcsIGxldCB1cyBrbm93IHdoYXQgeW91IHRoaW5rIGFib3V0 IHRoaXMgPyBJZiB3ZSBnbyB3aXRoIHRoaXMgDQogICAgICBhcHByb2FjaCwgd2Ugd2lsbCBwcm9i YWJseSBub3QgbmVlZCBSZXNwb25zZSBmb3IgRXZlbnQgDQogICAgICBtc2dzLjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNzPTQ1MDIyMzUyMi0yMTA1MjAwND48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj5UaGFua3M8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPkhvcm11emQ8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lO LVJJR0hUOiAwcHgiPg0KICAgICAgICA8RElWPjwvRElWPg0KICAgICAgICA8RElWIGNsYXNzPU91 dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIA0K ICAgICAgICBmYWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZP TlQ+PC9ESVY+DQogICAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgICBjaXRlPW1pZDQ2OEYzRkRB MjhBQTg3NDI5QUQ4MDc5OTJFMjJEMDdFMDExNjRFMjJAb3JzbXN4NDA4LmpmLmludGVsLmNvbSAN CiAgICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHls ZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgICAgICAgPERJVj5IZXJlIGlzIGFub3RoZXIg ZXhhbXBsZSBpbiB3aGljaCBJIHRoaW5rIHdlIG1heSBuZWVkIHRvIA0KICAgICAgICAgICAgZHlu YW1pY2FsbHkgc3Vic2NyaWJlIHRvIGV2ZW50czo8QlI+PEJSPlRoZSBDRSBhZGRzIGEgZmlsdGVy aW5nIA0KICAgICAgICAgICAgcnVsZSwgYW5kIGF0IHRoZSBzYW1lIHRpbWUgcmVxdWlyZXMgZXZl bnQgdG8gYmUgZmlyZWQgd2hlbmV2ZXIgYSANCiAgICAgICAgICAgIHBhY2tldCBtYXRjaGVzIHRo aXMgcnVsZS4gVGhpcyBjYW4gYmUgZm9yIHRoZSBwdXJwb3NlIG9mIERvUyANCiAgICAgICAgICAg IGRldGVjdGlvbiwgZm9yIGluc3RhbmNlLjxCUj48QlI+TGV0IG1lIGtub3cgaWYgdGhpcyBpcyBh IGNvbnZpbmNpbmcgDQogICAgICAgICAgICBleGFtcGxlLjxTUEFOIGNsYXNzPTQwMzAyMDUwMS0y MDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICAgICAgY29sb3I9IzAwMDBmZiBzaXpl PTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgICAgIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgICAgICAgPERJVj48U1BB TiBjbGFzcz00MDMwMjA1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0KICAgICAgICAgICAgc2l6ZT0yPltIS108L0ZPTlQ+Jm5ic3A7PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj5JIA0KICAgICAgICAgICAgZG9uJ3QgdGhpbmsgd2Ugd2lsbCBi ZSBzdWJzY3JpYmluZyB0byBldmVudHMgYXQgdGhpcyBsZXZlbCANCiAgICAgICAgICAgIG9mJm5i c3A7Z3JhbnVsYXJpdHkuIEZyb20gbXkgbGl0dGxlIGV4cGVyaWVuY2UgYXQgdGhlIE5QRiBhbmQg d2hhdCBJIA0KICAgICAgICAgICAgaGF2ZSBzZWVuIGZyb20gdGhlIE1vZGVsIHRlYW0sIGV2ZW50 cyB3aWxsIGJlIGRlZmluZWQgb24gcGVyIExGQiANCiAgICAgICAgICAgIGJhc2lzLiBUaGUgZXhh bXBsZSB0aGF0IHlvdSBoYXZlIGdpdmVuIGhlcmUgaXMgYSBsb3QgbW9yZSBncmFudWxhciwgDQog ICAgICAgICAgICBpLmUuIHBlciBlbnRyeSBiYXNpcyBpbiBhIExGQiB0YWJsZS4gSSBkb250IHRo aW5rIHRoaXMgbGV2ZWwgDQogICAgICAgICAgICBvZiZuYnNwO2dyYW51bGFyaXR5IHdpbGwgYmUg DQogICAgICAgIHN1cHBvcnRlZC48L0ZPTlQ+PC9TUEFOPjwvRElWPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+SSB3b24ndCBhcmd1ZSANCiAgICAgICAgYWdhaW5zdCB0aGUgZmFjdCB0aGF0IGlz IGlzIHVuc2NhbGFibGUgdG8gbGV0IGV2ZXJ5IGZpcmV3YWxsaW5nIHJ1bGUgDQogICAgICAgIGZp cmUgdXAgYW4gZXZlbnQuIE5ldmVydGhlbGVzcywgdGhpcyBjYW4gYmUgdXNlZnVsIGZvciBzb21l IG9mIHRoZSANCiAgICAgICAgZmlyZXdhbGxpbmcgcnVsZXMgKGludHJ1c2lvbiBkZXRlY3Rpb24g aXMgYW5vdGhlciBleGFtcGxlKS48QlI+PEJSPkkgDQogICAgICAgIGhvcGUgdGhhdCB0aGUgbW9k ZWwgd2lsbCBub3Qgb25seSBhbGxvdyBwZXItTEZCIGV2ZW50cyBvciBJIHdvdWxkIA0KICAgICAg ICBjb25zaWRlciB0aGlzIGEgYmFkIGRlc2lnbi4mbmJzcDsgV2Ugc2hvdWxkIGRlc2lnbiBvdXIg cHJvdG9jb2wgc28gdGhhdCANCiAgICAgICAgaXQgY2FuIGJlIHVzZWQgaW4gc3VjaCBjYXNlcyAo aS5lLiwgYWRkaW5nIGEgcnVsZSBhbmQgc3Vic2NyaWJpbmcgdG8gYW4gDQogICAgICAgIGV2ZW50 IG9mIHRoYXQgcnVsZSkuPEJSPjxCUj5JIG5vdGUgdGhhdCBoYXZpbmcgYSAiQ29uZmlnIiBvciAi RXZlbnQiIA0KICAgICAgICBtZXNzYWdlIHR5cGUgaW4gdGhlIGNvbW1vbiBoZWFkZXIgZm9yY2Vz IHVzIHRvIHNlbmQgdHdvIHNlcGFyYXRlIA0KICAgICAgICBtZXNzYWdlcyB0byB0aGUgc2FtZSBM RkIuIE5vdCBhIGdyZWF0IHRoaW5nLCBlc3BlY2lhbGx5IHNpbmNlIA0KICAgICAgICBmdW5kYW1l bnRhbGx5LCB0aGVyZSBpcyBsaXR0bGUgdmFsdWUgdG8gc2VwYXJhdGUgdGhlIENvbmZpZyBhbmQg RXZlbnQgDQogICAgICAgIHR5cGVzIGF0IHRoZSBDb21tb24tSGVhZGVyIGxldmVsLiA8QlI+PEJS Pk1heWJlIG90aGVycyBoYXZlIG9waW5pb24gb24gDQogICAgICAgIHRoaXMgdG9vID88QlI+PEJS PlJlZ2FyZHMsPEJSPi1Sb2JlcnQ8U1BBTiANCiAgICAgICAgY2xhc3M9NDUwMjIzNTIyLTIxMDUy MDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgc2l6ZT0yPiZuYnNw OzwvRk9OVD48L1NQQU4+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_04E7_01C44188.7BFBE540-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 24 00:35:27 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 AAA25924 for ; Mon, 24 May 2004 00:35: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 1BS76n-0000uF-Ca for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 00:30:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O4UfjT003479 for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 00:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS76G-0000ma-Sg for forces-protocol-web-archive@optimus.ietf.org; Mon, 24 May 2004 00: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 AAA25638 for ; Mon, 24 May 2004 00:30: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 1BS76E-0000Jo-Ap for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:30:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS75H-0007nJ-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:29:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS74H-0007WH-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 00:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS72G-0000Gx-CT; Mon, 24 May 2004 00: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 1BS6wU-0007oI-Fm for forces-protocol@optimus.ietf.org; Mon, 24 May 2004 00:20: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 AAA25283 for ; Mon, 24 May 2004 00:19: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 1BS6wR-0005Jz-VP for forces-protocol@ietf.org; Mon, 24 May 2004 00:20:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6vV-000537-00 for forces-protocol@ietf.org; Mon, 24 May 2004 00:19:03 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1BS6uZ-0004Wr-00 for forces-protocol@ietf.org; Mon, 24 May 2004 00:18:03 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i4O4HY6F006058; Mon, 24 May 2004 04:17:34 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i4O4HU8d019978; Mon, 24 May 2004 04:18:10 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 M2004052321173213255 ; Sun, 23 May 2004 21:17:32 -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, 23 May 2004 21:17:32 -0700 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_01C44146.08B65E01" Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Message-ID: <468F3FDA28AA87429AD807992E22D07E0122F436@orsmsx408.jf.intel.com> Thread-Topic: [Forces-protocol] Summary of Protocol Messages (Command Types) Thread-Index: AcRBRZI8F13t6Ac5SWuKEpgrsUQ60QAAC5PA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 24 May 2004 04:17:32.0728 (UTC) FILETIME=[08F92B80:01C44146] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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, 23 May 2004 21:17:32 -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.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C44146.08B65E01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree, that makes sense.=20 We can see if something makes sense for the Flags later. =20 regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Sunday, May 23, 2004 9:13 PM To: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) Hi Hormuzd, =20 One more thing is about the TfLV. I agree that some flags related to atomic ops can be as flags. The only thing is, I think atomic ops will mainly happens in config msgs. (though not very sure). therefore, in the msgs that i'm to put, the flags still have not been considered. But I think it can be modified easily later if needed. =20 Cheers, Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Wang,Weiming ; forces-protocol@ietf.org=20 Sent: Monday, May 24, 2004 11:40 AM Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Thanks Weiming, for your reply. This is helpful since I am writing up the Config msg. =20 regards Hormuzd -----Original Message----- From: forces-protocol-admin@ietf.org [mailto:forces-protocol-admin@ietf.org] On Behalf Of Wang,Weiming Sent: Sunday, May 23, 2004 8:29 PM To: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) Hi Hormuzd, Robert, and all, =20 Sorry reply to you very late, for I was very busy last weekdays for univ. business and busy writing my draft part during the weekend.=20 =20 I agree to let config msg do the sub/unsub of events. Actually in this case, the 'EventConfg' as I mentioned ealier can also be put in the 'Config' msg, leaving the event msg only for 'event report' and 'event response'. I think event response as a message should be put there, whether customers use it will be decided by the Response flag in the header.=20 =20 Thank you. Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Robert Haas ; Wang,Weiming =20 Cc: forces-protocol@ietf.org=20 Sent: Saturday, May 22, 2004 6:50 AM Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types) Hi Robert, =20 The basic reason for having an Event Msg is to report Asynchronous events from FE -> CE. We extended this use to accommodate Subscribe/Unsubscribe functions based on Your and Weiming's preferences. It seems like you are having different thoughts on this now, which is fine. I think you would like is to have Subscribe/Unsubscribe as part of Config rather than Event msg. This is fine by me, and I think Weiming will also be fine to accommodate this since this was one of the options that he had stated before.=20 =20 Weiming, let us know what you think about this ? If we go with this approach, we will probably not need Response for Event msgs. =20 Thanks Hormuzd -----Original Message----- Here is another example in which I think we may need to dynamically subscribe to events: The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance. Let me know if this is a convincing example.=20 =20 [HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported. I won't argue against the fact that is is unscalable to let every firewalling rule fire up an event. Nevertheless, this can be useful for some of the firewalling rules (intrusion detection is another example). I hope that the model will not only allow per-LFB events or I would consider this a bad design. We should design our protocol so that it can be used in such cases (i.e., adding a rule and subscribing to an event of that rule). I note that having a "Config" or "Event" message type in the common header forces us to send two separate messages to the same LFB. Not a great thing, especially since fundamentally, there is little value to separate the Config and Event types at the Common-Header level.=20 Maybe others have opinion on this too ? Regards, -Robert=20 ------_=_NextPart_001_01C44146.08B65E01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 agree, that makes sense.
We can=20 see if something makes sense for the Flags later.
 
regards
Hormuzd
-----Original Message-----
From: = Wang,Weiming=20 [mailto:wmwang@mail.hzic.edu.cn]
Sent: Sunday, May 23, 2004 = 9:13=20 PM
To: Khosravi, Hormuzd M;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] = Summary of=20 Protocol Messages (Command Types)

Hi Hormuzd,
 
One more thing is about the = TfLV.  I agree=20 that some flags related to atomic ops can be as flags. The only thing = is, I=20 think atomic ops will mainly happens in config msgs. (though not very = sure).=20 therefore, in the msgs that i'm to put, the flags still have not been=20 considered. But I think it can be modified easily later if=20 needed.
 
Cheers,
Weiming
 
----- Original Message -----
From:=20 Khosravi, Hormuzd M =
To: Wang,Weiming ; forces-protocol@ietf.org =
Sent: Monday, May 24, 2004 = 11:40=20 AM
Subject: RE: = [Forces-protocol] Summary=20 of Protocol Messages (Command Types)

Thanks Weiming, for your reply. This is helpful since I am = writing up=20 the Config msg.
 
regards
Hormuzd
-----Original Message-----
From: = forces-protocol-admin@ietf= .org=20 [mailto:forces-protocol-admin@ietf.org] On Behalf Of=20 Wang,Weiming
Sent: Sunday, May 23, 2004 8:29=20 PM
To: forces-protocol@ietf.org
= Subject:=20 Re: [Forces-protocol] Summary of Protocol Messages (Command=20 Types)

Hi Hormuzd, Robert, and = all,
 
Sorry reply to you very late, for = I was very=20 busy last weekdays for univ. business and busy writing my draft = part=20 during the weekend.
 
I agree to let config msg do the = sub/unsub of=20 events. Actually in this case, the 'EventConfg' as I mentioned = ealier can=20 also be put in the 'Config' msg, leaving the event msg only for = 'event=20 report' and 'event response'. I think event response as a message = should=20 be put there, whether customers use it will be decided by the = Response=20 flag in the header.
 
Thank you.
Weiming
 
----- Original Message -----
From:=20 Khosravi, Hormuzd = M=20
To: Robert Haas ; Wang,Weiming
Cc: forces-protocol@ietf.org=20
Sent: Saturday, May 22, = 2004 6:50=20 AM
Subject: RE: = [Forces-protocol]=20 Summary of Protocol Messages (Command Types)

Hi Robert,
 
The basic reason for having an Event Msg is to report=20 Asynchronous events from FE -> CE. We extended this use to=20 accommodate Subscribe/Unsubscribe functions based on Your and = Weiming's=20 preferences. It seems like you are having different = thoughts on=20 this now, which is fine. I think you would like is to have=20 Subscribe/Unsubscribe as part of Config rather than Event msg. = This is=20 fine by me, and I think Weiming will also be fine to accommodate = this=20 since this was one of the options that he had stated before.=20
 
Weiming, let us know what you think about this ? If we = go with=20 this approach, we will probably not need Response for Event=20 msgs.
 
Thanks
Hormuzd
-----Original Message-----
Here is another example in which I think we may need = to=20 dynamically subscribe to events:

The CE adds a = filtering=20 rule, and at the same time requires event to be fired = whenever a=20 packet matches this rule. This can be for the purpose of = DoS=20 detection, for instance.

Let me know if this is a=20 convincing example. 
 
[HK] I=20 don't think we will be subscribing to events at this level = of granularity. From my little experience at the NPF = and what=20 I have seen from the Model team, events will be defined on = per LFB=20 basis. The example that you have given here is a lot more=20 granular, i.e. per entry basis in a LFB table. I dont = think this=20 level of granularity will be=20 supported.
I = won't argue=20 against the fact that is is unscalable to let every = firewalling rule=20 fire up an event. Nevertheless, this can be useful for some of = the=20 firewalling rules (intrusion detection is another = example).

I=20 hope that the model will not only allow per-LFB events or I = would=20 consider this a bad design.  We should design our = protocol so=20 that it can be used in such cases (i.e., adding a rule and = subscribing=20 to an event of that rule).

I note that having a = "Config" or=20 "Event" message type in the common header forces us to send = two=20 separate messages to the same LFB. Not a great thing, = especially since=20 fundamentally, there is little value to separate the Config = and Event=20 types at the Common-Header level.

Maybe others have = opinion on=20 this too ?

Regards,
-Robert 
------_=_NextPart_001_01C44146.08B65E01-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 24 04:27:38 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 EAA19860 for ; Mon, 24 May 2004 04:27: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 1BSAjX-0000Ez-TF for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 04:22:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O8Mtfe000926 for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 04:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAf1-00087s-5L for forces-protocol-web-archive@optimus.ietf.org; Mon, 24 May 2004 04:18: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 EAA19443 for ; Mon, 24 May 2004 04:18: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 1BSAey-00033w-7J for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:18:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAe4-0002nJ-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:17:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSAdj-0002WM-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:16:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BSAdl-00036L-Ud for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAZ4-0007Rv-8Y; Mon, 24 May 2004 04:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAVM-0006g7-JU for forces-protocol@optimus.ietf.org; Mon, 24 May 2004 04:08: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 EAA18894 for ; Mon, 24 May 2004 04:08: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 1BSAVJ-0007kJ-NT for forces-protocol@ietf.org; Mon, 24 May 2004 04:08:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAUO-0007TB-00 for forces-protocol@ietf.org; Mon, 24 May 2004 04:07:17 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BSATh-00070F-00 for forces-protocol@ietf.org; Mon, 24 May 2004 04:06:33 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4O85xAN077612; Mon, 24 May 2004 08:05:59 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4O85w6M121258; Mon, 24 May 2004 10:05:59 +0200 Received: from zurich.ibm.com (dhcp69-221.zurich.ibm.com [9.4.69.221]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA24978; Mon, 24 May 2004 10:05:58 +0200 Message-ID: <40B1ACE6.5020403@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: "Wang,Weiming" CC: forces-protocol@ietf.org Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) References: <468F3FDA28AA87429AD807992E22D07E0122F1C7@orsmsx408.jf.intel.com> <04b201c4413f$3979df90$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <04b201c4413f$3979df90$845c21d2@Necom.hzic.edu.cn> Content-Type: multipart/alternative; boundary="------------060707030902080500050009" 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, 24 May 2004 10:05:58 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060707030902080500050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i4O85xAN077612 Content-Transfer-Encoding: quoted-printable Hi Weiming, I think we achieve indeed a cleaner design by merging the "Config" and=20 "Event" message types, so that actions of those types can be placed in=20 the same PL message. Now, for the EventResponse, I am not sure whether this should be a=20 message of its own, or be merged into the ConfigResponse as well for=20 consistency. What is the reason you think we should have a separate=20 ConfigResponse ? But I understand that EventReport should be a separate message. Regards, -Robert Wang,Weiming wrote: > Hi Hormuzd, Robert, and all, > =20 > Sorry reply to you very late, for I was very busy last weekdays for=20 > univ. business and busy writing my draft part during the weekend. > =20 > I agree to let config msg do the sub/unsub of events. Actually in this=20 > case, the 'EventConfg' as I mentioned ealier can also be put in the=20 > 'Config' msg, leaving the event msg only for 'event report' and 'event=20 > response'. I think event response as a message should be put there,=20 > whether customers use it will be decided by the Response flag in the=20 > header. > =20 > Thank you. > Weiming > =20 > ----- Original Message ----- > > From: Khosravi, Hormuzd M > To: Robert Haas ; Wang,Weiming > > Cc: forces-protocol@ietf.org > Sent: Saturday, May 22, 2004 6:50 AM > Subject: RE: [Forces-protocol] Summary of Protocol Messages > (Command Types) > > Hi Robert, > =20 > The basic reason for having an Event Msg is to report Asynchronous > events from FE -> CE. We extended this use to accommodate > Subscribe/Unsubscribe functions based on Your and Weiming's > preferences. It seems like you are having different thoughts on > this now, which is fine. I think you would like is to have > Subscribe/Unsubscribe as part of Config rather than Event msg. > This is fine by me, and I think Weiming will also be fine to > accommodate this since this was one of the options that he had > stated before. > =20 > Weiming, let us know what you think about this ? If we go with > this approach, we will probably not need Response for Event msgs. > =20 > Thanks > Hormuzd > > -----Original Message----- > >> Here is another example in which I think we may need to >> dynamically subscribe to events: >> >> The CE adds a filtering rule, and at the same time >> requires event to be fired whenever a packet matches this >> rule. This can be for the purpose of DoS detection, for >> instance. >> >> Let me know if this is a convincing example.=20 >> =20 >> [HK] I don't think we will be subscribing to events at >> this level of granularity. From my little experience at >> the NPF and what I have seen from the Model team, events >> will be defined on per LFB basis. The example that you >> have given here is a lot more granular, i.e. per entry >> basis in a LFB table. I dont think this level >> of granularity will be supported. >> > I won't argue against the fact that is is unscalable to let > every firewalling rule fire up an event. Nevertheless, this > can be useful for some of the firewalling rules (intrusion > detection is another example). > > I hope that the model will not only allow per-LFB events or I > would consider this a bad design. We should design our > protocol so that it can be used in such cases (i.e., adding a > rule and subscribing to an event of that rule). > > I note that having a "Config" or "Event" message type in the > common header forces us to send two separate messages to the > same LFB. Not a great thing, especially since fundamentally, > there is little value to separate the Config and Event types > at the Common-Header level. > > Maybe others have opinion on this too ? > > Regards, > -Robert=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 --------------060707030902080500050009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Weiming,
I think we achieve indeed a cleaner design by merging the "Config" and "Event" message types, so that actions of those types can be placed in the same PL message.

Now, for the EventResponse, I am not sure whether this should be a message of its own, or be merged into the ConfigResponse as well for consistency. What is the reason you think we should have a separate ConfigResponse ?

But I understand that EventReport should be a separate message.

Regards,
-Robert



Wang,Weiming wrote:
Message
Hi Hormuzd, Robert, and all,
 
Sorry reply to you very late, for I was very busy last weekdays for univ. business and busy writing my draft part during the weekend.
 
I agree to let config msg do the sub/unsub of events. Actually in this case, the 'EventConfg' as I mentioned ealier can also be put in the 'Config' msg, leaving the event msg only for 'event report' and 'event response'. I think event response as a message should be put there, whether customers use it will be decided by the Response flag in the header.
 
Thank you.
Weiming
 
----- Original Message -----
Sent: Saturday, May 22, 2004 6:50 AM
Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

Hi Robert,
 
The basic reason for having an Event Msg is to report Asynchronous events from FE -> CE. We extended this use to accommodate Subscribe/Unsubscribe functions based on Your and Weiming's preferences. It seems like you are having different thoughts on this now, which is fine. I think you would like is to have Subscribe/Unsubscribe as part of Config rather than Event msg. This is fine by me, and I think Weiming will also be fine to accommodate this since this was one of the options that he had stated before.
 
Weiming, let us know what you think about this ? If we go with this approach, we will probably not need Response for Event msgs.
 
Thanks
Hormuzd
-----Original Message-----
Here is another example in which I think we may need to dynamically subscribe to events:

The CE adds a filtering rule, and at the same time requires event to be fired whenever a packet matches this rule. This can be for the purpose of DoS detection, for instance.

Let me know if this is a convincing example. 
 
[HK] I don't think we will be subscribing to events at this level of granularity. From my little experience at the NPF and what I have seen from the Model team, events will be defined on per LFB basis. The example that you have given here is a lot more granular, i.e. per entry basis in a LFB table. I dont think this level of granularity will be supported.
I won't argue against the fact that is is unscalable to let every firewalling rule fire up an event. Nevertheless, this can be useful for some of the firewalling rules (intrusion detection is another example).

I hope that the model will not only allow per-LFB events or I would consider this a bad design.  We should design our protocol so that it can be used in such cases (i.e., adding a rule and subscribing to an event of that rule).

I note that having a "Config" or "Event" message type in the common header forces us to send two separate messages to the same LFB. Not a great thing, especially since fundamentally, there is little value to separate the Config and Event types at the Common-Header level.

Maybe others have opinion on this too ?

Regards,
-Robert 

-- 
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
--------------060707030902080500050009-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From exim@www1.ietf.org Mon May 24 04:53: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 EAA20905 for ; Mon, 24 May 2004 04:53: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 1BSB80-0003No-Um for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 04:48:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O8mCIB013004 for forces-protocol-archive@odin.ietf.org; Mon, 24 May 2004 04:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSB3D-0002kF-CU for forces-protocol-web-archive@optimus.ietf.org; Mon, 24 May 2004 04:43: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 EAA20570 for ; Mon, 24 May 2004 04:43:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSB3A-0002iX-5i for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:43:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSB2E-0002P7-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:42:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSB1H-00024v-00 for forces-protocol-web-archive@ietf.org; Mon, 24 May 2004 04:41:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAvM-0001Xn-BY; Mon, 24 May 2004 04:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSApc-0000rx-De for forces-protocol@optimus.ietf.org; Mon, 24 May 2004 04:29: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 EAA19915 for ; Mon, 24 May 2004 04:29: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 1BSApZ-0006IZ-Jv for forces-protocol@ietf.org; Mon, 24 May 2004 04:29:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAof-00060X-00 for forces-protocol@ietf.org; Mon, 24 May 2004 04:28:14 -0400 Received: from [202.96.99.59] (helo=ns1.hzic.net) by ietf-mx with esmtp (Exim 4.12) id 1BSAnh-0005fL-00 for forces-protocol@ietf.org; Mon, 24 May 2004 04:27:24 -0400 Received: from WWM (unverified [202.96.99.60]) by ns1.hzic.net (Rockliffe SMTPRA 4.5.6) with ESMTP id ; Mon, 24 May 2004 16:40:15 +0800 Message-ID: <055801c44168$dc46d3d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E0122F1C7@orsmsx408.jf.intel.com> <04b201c4413f$3979df90$845c21d2@Necom.hzic.edu.cn> <40B1ACE6.5020403@zurich.ibm.com> Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0555_01C441AB.E3834320" 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, 24 May 2004 16:26: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=2.0 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_0555_01C441AB.E3834320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpNeSB0aG91Z2h0IG9mIHRoZSB1c2UgZm9yIEV2ZW50UmVzcG9uc2UgaXMs ICBmb3Igc29tZSBvZiB0aGUgZXZlbnRzLCB0aGUgc2VuZGVyIChzYXkgRkUpIG1heSB2ZXJ5IG11 Y2ggY2FyZSBpZiB0aGUgcmVjZWl2ZXIgKENFKSBoYXMgcmVjZWl2ZWQgdGhlIGluZm8gZm9yIGl0 IHRoaW5rcyAgdGhlIGV2ZW50IGluZm8gaXMgdml0YWwuIEluIHRoaXMgY2FzZSwgYSByZXNwb25z ZSBhY3RpbmcgYXMgYW4gYWNrbm93bGVkZ2UgaXMgdXNlZnVsLiBOb3RlIHRoYXQsIG91ciBjdXJy ZW50IHNjaGVtZSBoYXMgaW5jb3JwYXJhdGVkIHRoZSBBQ0sgaW4gdGhlIHJlc3BvbnNlcywgdGhh dCBtZWFucyB3ZSB3aWxsIG5vdCBoYXZlIG90aGVyIG1lYW5zIHRvIEFDSyB0aGUgZXZlbnQgdHJh bnNwb3J0IGlmIHdlIGRvIG5vdCBkZWZpbmUgYSByZXNwb25zZSBmb3IgaXQuIE9mIGNvdXJzZSwg YSB1c2VyIHN0aWxsIGNhbiBoYXZlIHRoZSBmbGV4aWJpbGl0eSBieSB1c2luZyB0aGUgQUNLIGZs YWcgaW4gdGhlIGhlYWRlciBub3QgdG8gYXNrIHRoZSByZXNwb25zZS4gIFRoZXJlZm9yZSwgSSBq dXN0IHRoaW5rIGl0IG1heSBpbmhhbmNlIHRoZSBmbGV4aWJpbGl0eSBhbnl3YXkuDQoNClRoYW5r IHlvdS4NCldlaW1pbmcNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTog Um9iZXJ0IEhhYXMgDQogIFRvOiBXYW5nLFdlaW1pbmcgDQogIENjOiBmb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmcgDQogIFNlbnQ6IE1vbmRheSwgTWF5IDI0LCAyMDA0IDQ6MDUgUE0NCiAgU3ViamVj dDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFN1bW1hcnkgb2YgUHJvdG9jb2wgTWVzc2FnZXMgKENv bW1hbmQgVHlwZXMpDQoNCg0KICBIaSBXZWltaW5nLA0KICBJIHRoaW5rIHdlIGFjaGlldmUgaW5k ZWVkIGEgY2xlYW5lciBkZXNpZ24gYnkgbWVyZ2luZyB0aGUgIkNvbmZpZyIgYW5kICJFdmVudCIg bWVzc2FnZSB0eXBlcywgc28gdGhhdCBhY3Rpb25zIG9mIHRob3NlIHR5cGVzIGNhbiBiZSBwbGFj ZWQgaW4gdGhlIHNhbWUgUEwgbWVzc2FnZS4NCg0KICBOb3csIGZvciB0aGUgRXZlbnRSZXNwb25z ZSwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlIGEgbWVzc2FnZSBvZiBpdHMg b3duLCBvciBiZSBtZXJnZWQgaW50byB0aGUgQ29uZmlnUmVzcG9uc2UgYXMgd2VsbCBmb3IgY29u c2lzdGVuY3kuIFdoYXQgaXMgdGhlIHJlYXNvbiB5b3UgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBz ZXBhcmF0ZSBDb25maWdSZXNwb25zZSA/DQoNCiAgQnV0IEkgdW5kZXJzdGFuZCB0aGF0IEV2ZW50 UmVwb3J0IHNob3VsZCBiZSBhIHNlcGFyYXRlIG1lc3NhZ2UuDQoNCiAgUmVnYXJkcywNCiAgLVJv YmVydA0KDQoNCg0KICBXYW5nLFdlaW1pbmcgd3JvdGU6DQoNCiAgICBIaSBIb3JtdXpkLCBSb2Jl cnQsIGFuZCBhbGwsDQoNCiAgICBTb3JyeSByZXBseSB0byB5b3UgdmVyeSBsYXRlLCBmb3IgSSB3 YXMgdmVyeSBidXN5IGxhc3Qgd2Vla2RheXMgZm9yIHVuaXYuIGJ1c2luZXNzIGFuZCBidXN5IHdy aXRpbmcgbXkgZHJhZnQgcGFydCBkdXJpbmcgdGhlIHdlZWtlbmQuIA0KDQogICAgSSBhZ3JlZSB0 byBsZXQgY29uZmlnIG1zZyBkbyB0aGUgc3ViL3Vuc3ViIG9mIGV2ZW50cy4gQWN0dWFsbHkgaW4g dGhpcyBjYXNlLCB0aGUgJ0V2ZW50Q29uZmcnIGFzIEkgbWVudGlvbmVkIGVhbGllciBjYW4gYWxz byBiZSBwdXQgaW4gdGhlICdDb25maWcnIG1zZywgbGVhdmluZyB0aGUgZXZlbnQgbXNnIG9ubHkg Zm9yICdldmVudCByZXBvcnQnIGFuZCAnZXZlbnQgcmVzcG9uc2UnLiBJIHRoaW5rIGV2ZW50IHJl c3BvbnNlIGFzIGEgbWVzc2FnZSBzaG91bGQgYmUgcHV0IHRoZXJlLCB3aGV0aGVyIGN1c3RvbWVy cyB1c2UgaXQgd2lsbCBiZSBkZWNpZGVkIGJ5IHRoZSBSZXNwb25zZSBmbGFnIGluIHRoZSBoZWFk ZXIuIA0KDQogICAgVGhhbmsgeW91Lg0KICAgIFdlaW1pbmcNCg0KICAgIC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQogICAgICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICAgICAg VG86IFJvYmVydCBIYWFzIDsgV2FuZyxXZWltaW5nIA0KICAgICAgQ2M6IGZvcmNlcy1wcm90b2Nv bEBpZXRmLm9yZyANCiAgICAgIFNlbnQ6IFNhdHVyZGF5LCBNYXkgMjIsIDIwMDQgNjo1MCBBTQ0K ICAgICAgU3ViamVjdDogUkU6IFtGb3JjZXMtcHJvdG9jb2xdIFN1bW1hcnkgb2YgUHJvdG9jb2wg TWVzc2FnZXMgKENvbW1hbmQgVHlwZXMpDQoNCg0KICAgICAgSGkgUm9iZXJ0LA0KDQogICAgICBU aGUgYmFzaWMgcmVhc29uIGZvciBoYXZpbmcgYW4gRXZlbnQgTXNnIGlzIHRvIHJlcG9ydCBBc3lu Y2hyb25vdXMgZXZlbnRzIGZyb20gRkUgLT4gQ0UuIFdlIGV4dGVuZGVkIHRoaXMgdXNlIHRvIGFj Y29tbW9kYXRlIFN1YnNjcmliZS9VbnN1YnNjcmliZSBmdW5jdGlvbnMgYmFzZWQgb24gWW91ciBh bmQgV2VpbWluZydzIHByZWZlcmVuY2VzLiBJdCBzZWVtcyBsaWtlIHlvdSBhcmUgaGF2aW5nIGRp ZmZlcmVudCB0aG91Z2h0cyBvbiB0aGlzIG5vdywgd2hpY2ggaXMgZmluZS4gSSB0aGluayB5b3Ug d291bGQgbGlrZSBpcyB0byBoYXZlIFN1YnNjcmliZS9VbnN1YnNjcmliZSBhcyBwYXJ0IG9mIENv bmZpZyByYXRoZXIgdGhhbiBFdmVudCBtc2cuIFRoaXMgaXMgZmluZSBieSBtZSwgYW5kIEkgdGhp bmsgV2VpbWluZyB3aWxsIGFsc28gYmUgZmluZSB0byBhY2NvbW1vZGF0ZSB0aGlzIHNpbmNlIHRo aXMgd2FzIG9uZSBvZiB0aGUgb3B0aW9ucyB0aGF0IGhlIGhhZCBzdGF0ZWQgYmVmb3JlLiANCg0K ICAgICAgV2VpbWluZywgbGV0IHVzIGtub3cgd2hhdCB5b3UgdGhpbmsgYWJvdXQgdGhpcyA/IElm IHdlIGdvIHdpdGggdGhpcyBhcHByb2FjaCwgd2Ugd2lsbCBwcm9iYWJseSBub3QgbmVlZCBSZXNw b25zZSBmb3IgRXZlbnQgbXNncy4NCg0KICAgICAgVGhhbmtzDQogICAgICBIb3JtdXpkDQogICAg ICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAgICAgICBIZXJlIGlzIGFub3Ro ZXIgZXhhbXBsZSBpbiB3aGljaCBJIHRoaW5rIHdlIG1heSBuZWVkIHRvIGR5bmFtaWNhbGx5IHN1 YnNjcmliZSB0byBldmVudHM6DQoNCiAgICAgICAgICAgIFRoZSBDRSBhZGRzIGEgZmlsdGVyaW5n IHJ1bGUsIGFuZCBhdCB0aGUgc2FtZSB0aW1lIHJlcXVpcmVzIGV2ZW50IHRvIGJlIGZpcmVkIHdo ZW5ldmVyIGEgcGFja2V0IG1hdGNoZXMgdGhpcyBydWxlLiBUaGlzIGNhbiBiZSBmb3IgdGhlIHB1 cnBvc2Ugb2YgRG9TIGRldGVjdGlvbiwgZm9yIGluc3RhbmNlLg0KDQogICAgICAgICAgICBMZXQg bWUga25vdyBpZiB0aGlzIGlzIGEgY29udmluY2luZyBleGFtcGxlLiANCg0KICAgICAgICAgICAg W0hLXSBJIGRvbid0IHRoaW5rIHdlIHdpbGwgYmUgc3Vic2NyaWJpbmcgdG8gZXZlbnRzIGF0IHRo aXMgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIEZyb20gbXkgbGl0dGxlIGV4cGVyaWVuY2UgYXQgdGhl IE5QRiBhbmQgd2hhdCBJIGhhdmUgc2VlbiBmcm9tIHRoZSBNb2RlbCB0ZWFtLCBldmVudHMgd2ls bCBiZSBkZWZpbmVkIG9uIHBlciBMRkIgYmFzaXMuIFRoZSBleGFtcGxlIHRoYXQgeW91IGhhdmUg Z2l2ZW4gaGVyZSBpcyBhIGxvdCBtb3JlIGdyYW51bGFyLCBpLmUuIHBlciBlbnRyeSBiYXNpcyBp biBhIExGQiB0YWJsZS4gSSBkb250IHRoaW5rIHRoaXMgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgd2ls bCBiZSBzdXBwb3J0ZWQuDQogICAgICAgIEkgd29uJ3QgYXJndWUgYWdhaW5zdCB0aGUgZmFjdCB0 aGF0IGlzIGlzIHVuc2NhbGFibGUgdG8gbGV0IGV2ZXJ5IGZpcmV3YWxsaW5nIHJ1bGUgZmlyZSB1 cCBhbiBldmVudC4gTmV2ZXJ0aGVsZXNzLCB0aGlzIGNhbiBiZSB1c2VmdWwgZm9yIHNvbWUgb2Yg dGhlIGZpcmV3YWxsaW5nIHJ1bGVzIChpbnRydXNpb24gZGV0ZWN0aW9uIGlzIGFub3RoZXIgZXhh bXBsZSkuDQoNCiAgICAgICAgSSBob3BlIHRoYXQgdGhlIG1vZGVsIHdpbGwgbm90IG9ubHkgYWxs b3cgcGVyLUxGQiBldmVudHMgb3IgSSB3b3VsZCBjb25zaWRlciB0aGlzIGEgYmFkIGRlc2lnbi4g IFdlIHNob3VsZCBkZXNpZ24gb3VyIHByb3RvY29sIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgaW4g c3VjaCBjYXNlcyAoaS5lLiwgYWRkaW5nIGEgcnVsZSBhbmQgc3Vic2NyaWJpbmcgdG8gYW4gZXZl bnQgb2YgdGhhdCBydWxlKS4NCg0KICAgICAgICBJIG5vdGUgdGhhdCBoYXZpbmcgYSAiQ29uZmln IiBvciAiRXZlbnQiIG1lc3NhZ2UgdHlwZSBpbiB0aGUgY29tbW9uIGhlYWRlciBmb3JjZXMgdXMg dG8gc2VuZCB0d28gc2VwYXJhdGUgbWVzc2FnZXMgdG8gdGhlIHNhbWUgTEZCLiBOb3QgYSBncmVh dCB0aGluZywgZXNwZWNpYWxseSBzaW5jZSBmdW5kYW1lbnRhbGx5LCB0aGVyZSBpcyBsaXR0bGUg dmFsdWUgdG8gc2VwYXJhdGUgdGhlIENvbmZpZyBhbmQgRXZlbnQgdHlwZXMgYXQgdGhlIENvbW1v bi1IZWFkZXIgbGV2ZWwuIA0KDQogICAgICAgIE1heWJlIG90aGVycyBoYXZlIG9waW5pb24gb24g dGhpcyB0b28gPw0KDQogICAgICAgIFJlZ2FyZHMsDQogICAgICAgIC1Sb2JlcnQgDQoNCg0KLS0g DQpSb2JlcnQgSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpT5HVtZXJzdHJh c3NlIDQNCkNILTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0KcGhvbmUgKzQxLTEtNzI0LTg2 OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoN Cg== ------=_NextPart_000_0555_01C441AB.E3834320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSB0 ZXh0PSMwMDAwMDAgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5IaSBSb2JlcnQsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPk15IHRob3Vn aHQgb2YgdGhlIHVzZSBmb3IgRXZlbnRSZXNwb25zZSBpcywgDQombmJzcDtmb3Igc29tZSBvZiB0 aGUgZXZlbnRzLCB0aGUgc2VuZGVyIChzYXkgRkUpJm5ic3A7bWF5IHZlcnkgbXVjaCBjYXJlIGlm IHRoZSANCnJlY2VpdmVyIChDRSkgaGFzIHJlY2VpdmVkIHRoZSBpbmZvIGZvciZuYnNwO2l0IHRo aW5rcyAmbmJzcDt0aGUgZXZlbnQgaW5mbyBpcyANCnZpdGFsLiBJbiB0aGlzIGNhc2UsIGEgcmVz cG9uc2UgYWN0aW5nIGFzIGFuIGFja25vd2xlZGdlIGlzIHVzZWZ1bC4gTm90ZSB0aGF0LCANCm91 ciBjdXJyZW50IHNjaGVtZSBoYXMgaW5jb3JwYXJhdGVkIHRoZSBBQ0sgaW4gdGhlIHJlc3BvbnNl cywgdGhhdCBtZWFucyB3ZSB3aWxsIA0Kbm90IGhhdmUgb3RoZXIgbWVhbnMgdG8gQUNLIHRoZSBl dmVudCB0cmFuc3BvcnQgaWYgd2UgZG8gbm90IGRlZmluZSBhIHJlc3BvbnNlIA0KZm9yIGl0LiBP ZiBjb3Vyc2UsIGEgdXNlciBzdGlsbCBjYW4gaGF2ZSB0aGUgZmxleGliaWxpdHkgYnkgdXNpbmcg dGhlIEFDSyBmbGFnIA0KaW4gdGhlIGhlYWRlciBub3QgdG8mbmJzcDthc2sgdGhlIHJlc3BvbnNl LiZuYnNwOyBUaGVyZWZvcmUsIEkganVzdCB0aGluayBpdCBtYXkgDQppbmhhbmNlIHRoZSBmbGV4 aWJpbGl0eSBhbnl3YXkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5r IHlvdS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPldlaW1pbmc8 L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6 IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAj MDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05U OiAxMHB0IGFyaWFsIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElW IA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cmhhQHp1cmljaC5pYm0uY29t IGhyZWY9Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPlJvYmVydCBIYWFzPC9BPiANCiAgPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgdGl0bGU9 d213YW5nQG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemlj LmVkdS5jbiI+V2FuZyxXZWltaW5nPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCBhcmlhbCI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQog IGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90b2NvbEBp ZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlNl bnQ6PC9CPiBNb25kYXksIE1heSAyNCwgMjAwNCA0OjA1IFBNPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6PC9CPiBSZTogW0ZvcmNlcy1wcm90b2NvbF0g U3VtbWFyeSBvZiANCiAgUHJvdG9jb2wgTWVzc2FnZXMgKENvbW1hbmQgVHlwZXMpPC9ESVY+DQog IDxESVY+PEJSPjwvRElWPkhpIFdlaW1pbmcsPEJSPkkgdGhpbmsgd2UgYWNoaWV2ZSBpbmRlZWQg YSBjbGVhbmVyIGRlc2lnbiBieSANCiAgbWVyZ2luZyB0aGUgIkNvbmZpZyIgYW5kICJFdmVudCIg bWVzc2FnZSB0eXBlcywgc28gdGhhdCBhY3Rpb25zIG9mIHRob3NlIHR5cGVzIA0KICBjYW4gYmUg cGxhY2VkIGluIHRoZSBzYW1lIFBMIG1lc3NhZ2UuPEJSPjxCUj5Ob3csIGZvciB0aGUgRXZlbnRS ZXNwb25zZSwgSSBhbSANCiAgbm90IHN1cmUgd2hldGhlciB0aGlzIHNob3VsZCBiZSBhIG1lc3Nh Z2Ugb2YgaXRzIG93biwgb3IgYmUgbWVyZ2VkIGludG8gdGhlIA0KICBDb25maWdSZXNwb25zZSBh cyB3ZWxsIGZvciBjb25zaXN0ZW5jeS4gV2hhdCBpcyB0aGUgcmVhc29uIHlvdSB0aGluayB3ZSBz aG91bGQgDQogIGhhdmUgYSBzZXBhcmF0ZSBDb25maWdSZXNwb25zZSA/PEJSPjxCUj5CdXQgSSB1 bmRlcnN0YW5kIHRoYXQgRXZlbnRSZXBvcnQgDQogIHNob3VsZCBiZSBhIHNlcGFyYXRlIA0KICBt ZXNzYWdlLjxCUj48QlI+UmVnYXJkcyw8QlI+LVJvYmVydDxCUj48QlI+PEJSPjxCUj5XYW5nLFdl aW1pbmcgd3JvdGU6PEJSPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDA0YjIwMWM0NDEzZiQzOTc5 ZGY5MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+DQogICAgPE1F VEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCiAgICA8U1RZ TEU+PC9TVFlMRT4NCg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SGkgSG9ybXV6 ZCwgUm9iZXJ0LCBhbmQgYWxsLDwvRk9OVD48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+U29ycnkgcmVwbHkgdG8geW91IHZlcnkg bGF0ZSwgZm9yIEkgd2FzIHZlcnkgDQogICAgYnVzeSBsYXN0IHdlZWtkYXlzIGZvciB1bml2LiBi dXNpbmVzcyBhbmQgYnVzeSB3cml0aW5nIG15IGRyYWZ0IHBhcnQgZHVyaW5nIA0KICAgIHRoZSB3 ZWVrZW5kLiA8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgYWdyZWUgdG8gbGV0IGNvbmZpZyBtc2cgZG8gdGhlIHN1 Yi91bnN1YiBvZiANCiAgICBldmVudHMuIEFjdHVhbGx5IGluIHRoaXMgY2FzZSwgdGhlICdFdmVu dENvbmZnJyBhcyBJIG1lbnRpb25lZCBlYWxpZXIgY2FuIA0KICAgIGFsc28gYmUgcHV0IGluIHRo ZSAnQ29uZmlnJyBtc2csIGxlYXZpbmcgdGhlIGV2ZW50IG1zZyBvbmx5IGZvciAnZXZlbnQgDQog ICAgcmVwb3J0JyBhbmQgJ2V2ZW50IHJlc3BvbnNlJy4gSSB0aGluayBldmVudCByZXNwb25zZSBh cyBhIG1lc3NhZ2Ugc2hvdWxkIGJlIA0KICAgIHB1dCB0aGVyZSwgd2hldGhlciBjdXN0b21lcnMg dXNlIGl0IHdpbGwgYmUgZGVjaWRlZCBieSB0aGUgUmVzcG9uc2UgZmxhZyBpbiANCiAgICB0aGUg aGVhZGVyLiA8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5rIHlvdS48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5XZWltaW5nPC9GT05UPjwvRElWPg0KICAgIDxESVY+Jm5i c3A7PC9ESVY+DQogICAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0K ICAgIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsg UEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiByZ2IoMCww LDApIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgPERJViANCiAgICAgIHN0 eWxlPSJCQUNLR1JPVU5EOiByZ2IoMjI4LDIyOCwyMjgpIDAlIDUwJTsgRk9OVDogMTBwdCBhcmlh bDsgbW96LWJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgbW96LWJhY2tncm91bmQtaW5saW5lLXBv bGljeTogaW5pdGlhbDsgbW96LWJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBmb250LXN0cmV0 Y2g6IG5vcm1hbDsgZm9udC1zaXplLWFkanVzdDogbm9uZSI+PEI+RnJvbTo8L0I+IA0KICAgICAg PEEgdGl0bGU9aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgICAgIGhyZWY9Im1haWx0 bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwgSG9ybXV6ZCBNPC9BPiA8 L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbDsgZm9udC1z dHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmUiPjxCPlRvOjwvQj4gDQogICAg ICA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRvOnJoYUB6dXJpY2guaWJt LmNvbSI+Um9iZXJ0IA0KICAgICAgSGFhczwvQT4gOyA8QSB0aXRsZT13bXdhbmdAbWFpbC5oemlj LmVkdS5jbiANCiAgICAgIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2Fu ZyxXZWltaW5nPC9BPiA8L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDogMTBw dCBhcmlhbDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmUiPjxC PkNjOjwvQj4gDQogICAgICA8QSB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogICAg ICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xA aWV0Zi5vcmc8L0E+IDwvRElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJGT05UOiAxMHB0 IGFyaWFsOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplLWFkanVzdDogbm9uZSI+PEI+ U2VudDo8L0I+IA0KICAgICAgU2F0dXJkYXksIE1heSAyMiwgMjAwNCA2OjUwIEFNPC9ESVY+DQog ICAgICA8RElWIA0KICAgICAgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtc3RyZXRjaDog bm9ybWFsOyBmb250LXNpemUtYWRqdXN0OiBub25lIj48Qj5TdWJqZWN0OjwvQj4gDQogICAgICBS RTogW0ZvcmNlcy1wcm90b2NvbF0gU3VtbWFyeSBvZiBQcm90b2NvbCBNZXNzYWdlcyAoQ29tbWFu ZCBUeXBlcyk8L0RJVj4NCiAgICAgIDxESVY+PEJSPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBj bGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K ICAgICAgc2l6ZT0yPkhpIFJvYmVydCw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICAgIHNpemU9Mj5UaGUgYmFzaWMgcmVh c29uIGZvciBoYXZpbmcgYW4gRXZlbnQgTXNnIGlzIHRvIHJlcG9ydCBBc3luY2hyb25vdXMgDQog ICAgICBldmVudHMgZnJvbSBGRSAtJmd0OyBDRS4gV2UgZXh0ZW5kZWQgdGhpcyB1c2UgdG8gYWNj b21tb2RhdGUgDQogICAgICBTdWJzY3JpYmUvVW5zdWJzY3JpYmUgZnVuY3Rpb25zIGJhc2VkIG9u IFlvdXIgYW5kIFdlaW1pbmcncyBwcmVmZXJlbmNlcy4gDQogICAgICBJdCBzZWVtcyBsaWtlIHlv dSBhcmUmbmJzcDtoYXZpbmcgZGlmZmVyZW50IHRob3VnaHRzIG9uIHRoaXMgbm93LCB3aGljaCBp cyANCiAgICAgIGZpbmUuIEkgdGhpbmsmbmJzcDt5b3Ugd291bGQgbGlrZSBpcyB0byBoYXZlIFN1 YnNjcmliZS9VbnN1YnNjcmliZSBhcyBwYXJ0IA0KICAgICAgb2YgQ29uZmlnIHJhdGhlciB0aGFu IEV2ZW50IG1zZy4gVGhpcyBpcyBmaW5lIGJ5IG1lLCBhbmQgSSB0aGluayBXZWltaW5nIA0KICAg ICAgd2lsbCBhbHNvIGJlIGZpbmUgdG8gYWNjb21tb2RhdGUgdGhpcyBzaW5jZSB0aGlzIHdhcyBv bmUgb2YgdGhlIG9wdGlvbnMgDQogICAgICB0aGF0IGhlIGhhZCBzdGF0ZWQgYmVmb3JlLiA8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQ QU4gY2xhc3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiANCiAgICAgIHNpemU9Mj5XZWltaW5nLCBsZXQgdXMga25vdyB3aGF0IHlvdSB0aGluayBhYm91 dCB0aGlzID8gSWYgd2UgZ28gd2l0aCB0aGlzIA0KICAgICAgYXBwcm9hY2gsIHdlIHdpbGwgcHJv YmFibHkgbm90IG5lZWQgUmVzcG9uc2UgZm9yIEV2ZW50IA0KICAgICAgbXNncy48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PFNQQU4gY2xh c3M9NDUwMjIzNTIyLTIxMDUyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAg ICAgIHNpemU9Mj5UaGFua3M8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBj bGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K ICAgICAgc2l6ZT0yPkhvcm11emQ8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPEJMT0NLUVVP VEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgICA8RElWIGNsYXNz PU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05U IA0KICAgICAgICBmYWNlPVRhaG9tYSBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgICBjaXRlPW1pZDQ2OEYz RkRBMjhBQTg3NDI5QUQ4MDc5OTJFMjJEMDdFMDExNjRFMjJAb3JzbXN4NDA4LmpmLmludGVsLmNv bSANCiAgICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgPEJMT0NLUVVPVEUgZGlyPWx0ciBz dHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgICAgICAgPERJVj5IZXJlIGlzIGFub3Ro ZXIgZXhhbXBsZSBpbiB3aGljaCBJIHRoaW5rIHdlIG1heSBuZWVkIHRvIA0KICAgICAgICAgICAg ZHluYW1pY2FsbHkgc3Vic2NyaWJlIHRvIGV2ZW50czo8QlI+PEJSPlRoZSBDRSBhZGRzIGEgZmls dGVyaW5nIA0KICAgICAgICAgICAgcnVsZSwgYW5kIGF0IHRoZSBzYW1lIHRpbWUgcmVxdWlyZXMg ZXZlbnQgdG8gYmUgZmlyZWQgd2hlbmV2ZXIgYSANCiAgICAgICAgICAgIHBhY2tldCBtYXRjaGVz IHRoaXMgcnVsZS4gVGhpcyBjYW4gYmUgZm9yIHRoZSBwdXJwb3NlIG9mIERvUyANCiAgICAgICAg ICAgIGRldGVjdGlvbiwgZm9yIGluc3RhbmNlLjxCUj48QlI+TGV0IG1lIGtub3cgaWYgdGhpcyBp cyBhIGNvbnZpbmNpbmcgDQogICAgICAgICAgICBleGFtcGxlLjxTUEFOIGNsYXNzPTQwMzAyMDUw MS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICAgICAgY29sb3I9IzAwMDBmZiBz aXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgICAgIDxESVY+Jm5ic3A7 PC9ESVY+DQogICAgICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTQwMzAyMDUwMS0yMDA1MjAwND48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgICAgICBzaXplPTI+W0hLXTwv Rk9OVD4mbmJzcDs8Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkkgDQogICAg ICAgICAgICBkb24ndCB0aGluayB3ZSB3aWxsIGJlIHN1YnNjcmliaW5nIHRvIGV2ZW50cyBhdCB0 aGlzIGxldmVsIA0KICAgICAgICAgICAgb2YmbmJzcDtncmFudWxhcml0eS4gRnJvbSBteSBsaXR0 bGUgZXhwZXJpZW5jZSBhdCB0aGUgTlBGIGFuZCB3aGF0IEkgDQogICAgICAgICAgICBoYXZlIHNl ZW4gZnJvbSB0aGUgTW9kZWwgdGVhbSwgZXZlbnRzIHdpbGwgYmUgZGVmaW5lZCBvbiBwZXIgTEZC IA0KICAgICAgICAgICAgYmFzaXMuIFRoZSBleGFtcGxlIHRoYXQgeW91IGhhdmUgZ2l2ZW4gaGVy ZSBpcyBhIGxvdCBtb3JlIGdyYW51bGFyLCANCiAgICAgICAgICAgIGkuZS4gcGVyIGVudHJ5IGJh c2lzIGluIGEgTEZCIHRhYmxlLiBJIGRvbnQgdGhpbmsgdGhpcyBsZXZlbCANCiAgICAgICAgICAg IG9mJm5ic3A7Z3JhbnVsYXJpdHkgd2lsbCBiZSANCiAgICAgICAgc3VwcG9ydGVkLjwvRk9OVD48 L1NQQU4+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT5JIHdvbid0IGFyZ3VlIA0KICAg ICAgICBhZ2FpbnN0IHRoZSBmYWN0IHRoYXQgaXMgaXMgdW5zY2FsYWJsZSB0byBsZXQgZXZlcnkg ZmlyZXdhbGxpbmcgcnVsZSANCiAgICAgICAgZmlyZSB1cCBhbiBldmVudC4gTmV2ZXJ0aGVsZXNz LCB0aGlzIGNhbiBiZSB1c2VmdWwgZm9yIHNvbWUgb2YgdGhlIA0KICAgICAgICBmaXJld2FsbGlu ZyBydWxlcyAoaW50cnVzaW9uIGRldGVjdGlvbiBpcyBhbm90aGVyIGV4YW1wbGUpLjxCUj48QlI+ SSANCiAgICAgICAgaG9wZSB0aGF0IHRoZSBtb2RlbCB3aWxsIG5vdCBvbmx5IGFsbG93IHBlci1M RkIgZXZlbnRzIG9yIEkgd291bGQgDQogICAgICAgIGNvbnNpZGVyIHRoaXMgYSBiYWQgZGVzaWdu LiZuYnNwOyBXZSBzaG91bGQgZGVzaWduIG91ciBwcm90b2NvbCBzbyB0aGF0IA0KICAgICAgICBp dCBjYW4gYmUgdXNlZCBpbiBzdWNoIGNhc2VzIChpLmUuLCBhZGRpbmcgYSBydWxlIGFuZCBzdWJz Y3JpYmluZyB0byBhbiANCiAgICAgICAgZXZlbnQgb2YgdGhhdCBydWxlKS48QlI+PEJSPkkgbm90 ZSB0aGF0IGhhdmluZyBhICJDb25maWciIG9yICJFdmVudCIgDQogICAgICAgIG1lc3NhZ2UgdHlw ZSBpbiB0aGUgY29tbW9uIGhlYWRlciBmb3JjZXMgdXMgdG8gc2VuZCB0d28gc2VwYXJhdGUgDQog ICAgICAgIG1lc3NhZ2VzIHRvIHRoZSBzYW1lIExGQi4gTm90IGEgZ3JlYXQgdGhpbmcsIGVzcGVj aWFsbHkgc2luY2UgDQogICAgICAgIGZ1bmRhbWVudGFsbHksIHRoZXJlIGlzIGxpdHRsZSB2YWx1 ZSB0byBzZXBhcmF0ZSB0aGUgQ29uZmlnIGFuZCBFdmVudCANCiAgICAgICAgdHlwZXMgYXQgdGhl IENvbW1vbi1IZWFkZXIgbGV2ZWwuIDxCUj48QlI+TWF5YmUgb3RoZXJzIGhhdmUgb3BpbmlvbiBv biANCiAgICAgICAgdGhpcyB0b28gPzxCUj48QlI+UmVnYXJkcyw8QlI+LVJvYmVydDxTUEFOIA0K ICAgICAgICBjbGFzcz00NTAyMjM1MjItMjEwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICAgICAgICBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0JMT0NLUVVPVEU+ PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48QlI+PFBSRSBjbGFzcz1tb3otc2lnbmF0dXJlIGNv bHM9IjcyIj4tLSANClJvYmVydCBIYWFzDQpJQk0gWnVyaWNoIFJlc2VhcmNoIExhYm9yYXRvcnkN ClPkdW1lcnN0cmFzc2UgNA0KQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQpwaG9uZSAr NDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICA8QSBjbGFzcz1tb3otdHh0LWxpbmst ZnJlZXRleHQgaHJlZj0iaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhIj5odHRwOi8vd3d3 Lnp1cmljaC5pYm0uY29tL35yaGE8L0E+PC9QUkU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_000_0555_01C441AB.E3834320-- _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol