From mailnull@www1.ietf.org Wed Jun 11 07:53:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03635 for ; Wed, 11 Jun 2003 07:53:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BBqiL32143 for gsmp-archive@odin.ietf.org; Wed, 11 Jun 2003 07:52:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBqiB32140 for ; Wed, 11 Jun 2003 07:52: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 HAA03620 for ; Wed, 11 Jun 2003 07:52:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q47i-0006qp-00 for gsmp-web-archive@ietf.org; Wed, 11 Jun 2003 07:50:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q47h-0006ql-00 for gsmp-web-archive@ietf.org; Wed, 11 Jun 2003 07:50:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBqWB32131; Wed, 11 Jun 2003 07:52:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBpVB32097 for ; Wed, 11 Jun 2003 07:51: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 HAA03608 for ; Wed, 11 Jun 2003 07:51:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q46X-0006qZ-00 for gsmp@ietf.org; Wed, 11 Jun 2003 07:49:25 -0400 Received: from h42s128a211n47.user.nortelnetworks.com ([47.211.128.42] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19Q46W-0006qN-00 for gsmp@ietf.org; Wed, 11 Jun 2003 07:49:25 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BBov600660; Wed, 11 Jun 2003 12:50:57 +0100 (BST) Received: from zctfc002.europe.nortel.com ([47.164.129.43]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLZRAVA; Wed, 11 Jun 2003 13:50:56 +0200 Received: from nortelnetworks.com (ksundell-1.europe.nortel.com [47.167.132.215]) by zctfc002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MNLRQ2XC; Wed, 11 Jun 2003 13:50:57 +0200 Message-ID: <3EE718B0.1070404@nortelnetworks.com> Date: Wed, 11 Jun 2003 13:55:28 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: Kenneth Sundell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: gsmp CC: avri Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [GSMP] Cut-off dates for Vienna Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, here follows a reminder of the internet-draft cut-off dates. Please be sure that you submit in a timely fashion so we have time to discuss the i-d's on the list before the meeting. Also if someone is planning to submit an initial draft (-00 version) please notify myself or avri as soon as possible. June 23, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET June 30, Monday - Internet Draft final submission cut-off at 09:00 ET cheers, ken _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From mailnull@www1.ietf.org Fri Jun 13 10:08:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06274 for ; Fri, 13 Jun 2003 10:08:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DE7xC14363 for gsmp-archive@odin.ietf.org; Fri, 13 Jun 2003 10:07:59 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DE7xm14360 for ; Fri, 13 Jun 2003 10:07: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 KAA06181 for ; Fri, 13 Jun 2003 10:07:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpBc-0005Z9-00 for gsmp-web-archive@ietf.org; Fri, 13 Jun 2003 10:05:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QpBb-0005Z5-00 for gsmp-web-archive@ietf.org; Fri, 13 Jun 2003 10:05:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBp1a01878; Fri, 13 Jun 2003 07:51:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBoLm01852 for ; Fri, 13 Jun 2003 07:50:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28878; Fri, 13 Jun 2003 07:50:19 -0400 (EDT) Message-Id: <200306131150.HAA28878@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: gsmp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Jun 2003 07:50:19 -0400 Subject: [GSMP] I-D ACTION:draft-ietf-gsmp-reqs-06.txt Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : Requirements For Adding Optical Support To GSMPv3 Author(s) : H. Khosravi et al. Filename : draft-ietf-gsmp-reqs-06.txt Pages : 15 Date : 2003-6-12 This memo provides requirements for adding of optical switching support to the General Switch Management (GSMP) protocol. It also contains clarifications and suggested changes to the GSMP v3 specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-reqs-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-gsmp-reqs-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-reqs-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-12132125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-reqs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132125.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From mailnull@www1.ietf.org Mon Jun 16 00:38:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18936 for ; Mon, 16 Jun 2003 00:38:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G4bpk20926 for gsmp-archive@odin.ietf.org; Mon, 16 Jun 2003 00:37:51 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G4bgm20923 for ; Mon, 16 Jun 2003 00:37: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 AAA18911 for ; Mon, 16 Jun 2003 00:37:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RliH-0006zM-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 00:35:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RliH-0006zI-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 00:35:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G3RQa16517; Sun, 15 Jun 2003 23:27:26 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G3Q6m16491 for ; Sun, 15 Jun 2003 23:26: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 XAA17914 for ; Sun, 15 Jun 2003 23:26:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rkax-0006mh-00 for gsmp@ietf.org; Sun, 15 Jun 2003 23:23:47 -0400 Received: from apocalypse.org ([192.48.232.17] ident=[ESDZVHv/30HPif9lUrsOjN5myWZbTAPL]) by ietf-mx with esmtp (Exim 4.12) id 19Rkax-0006me-00 for gsmp@ietf.org; Sun, 15 Jun 2003 23:23:47 -0400 Received: from acm.org (IDENT:s1Pp0zbFddxDj8ZLOmDEt4N0kDgQuJOv@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5G3Pxd00697 for ; Sun, 15 Jun 2003 23:25:59 -0400 Date: Mon, 16 Jun 2003 12:25:54 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3CF1566A-9FAA-11D7-8727-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] GSMP header too large? Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For at least application in optical burst switching, the GSMP headers are thought to be too large. In some ways this reminds me of discussion we had in the past over ATM cell size and GSMP message size. But there are considerations, perhaps, that make the discussion different in this case and therefore worth re-opening. There has been a suggestion of adding header compression. e.g. if a number of reservations are set up for burst switching, and the control wants the ability to add branches as required, a short Id could be used to trigger the add branch. I am still thinking about: - whether I believe we should do this - the best way to do it. I would like to see some list discussion on the topic: - should there be header compression or is there another solution to the need for burst add branch triggering? - if header compression is needed, is it only needed for add branch messages? - recommendations for ways to do it! a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From mailnull@www1.ietf.org Mon Jun 16 02:08:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29291 for ; Mon, 16 Jun 2003 02:08:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G67kn30278 for gsmp-archive@odin.ietf.org; Mon, 16 Jun 2003 02:07:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G67km30275 for ; Mon, 16 Jun 2003 02:07: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 CAA28777 for ; Mon, 16 Jun 2003 02:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rn7S-0007Z8-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 02:05:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Rn7R-0007Z5-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 02:05:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G3HJa16282; Sun, 15 Jun 2003 23:17:19 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G3GDm16263 for ; Sun, 15 Jun 2003 23: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 XAA17848 for ; Sun, 15 Jun 2003 23:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RkRR-0006ld-00 for gsmp@ietf.org; Sun, 15 Jun 2003 23:13:57 -0400 Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx with esmtp (Exim 4.12) id 19RkRQ-0006lZ-00 for gsmp@ietf.org; Sun, 15 Jun 2003 23:13:56 -0400 Received: from apocalypse.org (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAHCFNLM; Mon, 16 Jun 2003 12:16:12 +0900 Date: Mon, 16 Jun 2003 12:15:59 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] upcoming changes to specs Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I recommend that anyone who is planning to submit a draft by the deadline, submit a note discussing the changes they are making in the document this week. Of course if it is a new document (e.g. a mib or pib on partitioning - anyone? or maybe the tdm spec?) then an abstract would help. We are scheduling for an hour so we want to plan. And as an author who is planing to submit an update before the deadline (barely) i will go first. ---- changes to draft-ietf-gsmp-v3-base-spec After some discussions withe the team working on the Optical draft, it was determined that I had not yet generalized enough of the messages; i.e. that a lot of message content was still very packet switch oriented. I am therefore in the process of doing more generalization. Specifically: - event flags - a notation that 8 event flags (8-15) are reserved for technology specific definition - addition of a technology specific block to msg 64 (switch configuration message) -msg 65 - the porttype specific data needs generalization. -msf 67 capability set definition needs generalization - i am not sure if i will have a chance to do some of the required changes in the optical reqs spec which has just been submitted to the iesg. - there has been an issue concerning the size of the gsmp message header brought up by the folks working on optical burst switching - i will send a specific message to the list on this issue. -I have had some discussions with Jonathan Sadler on the best way to designate the port specific adaptations. We have tentatively decided to add a block to the port configuration message. Jonathan is, hopefully, going to be putting out a doc on this issue. I don't know if I will get this in on this pass. So, for all the folks who spoken to me in the privately, I have two requests; - correct me if i left out one of the changes i agreed to make - please discuss issues on the list so more people can voice their opinions. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From mailnull@www1.ietf.org Mon Jun 16 23:53:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15317 for ; Mon, 16 Jun 2003 23:53:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3qfU00775 for gsmp-archive@odin.ietf.org; Mon, 16 Jun 2003 23:52:41 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3qbm00772 for ; Mon, 16 Jun 2003 23:52: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 XAA15301 for ; Mon, 16 Jun 2003 23:52:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S7UA-0002Cc-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 23:50:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S7UA-0002CZ-00 for gsmp-web-archive@ietf.org; Mon, 16 Jun 2003 23:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEA1a05958; Mon, 16 Jun 2003 10:10:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GE9Tm05916 for ; Mon, 16 Jun 2003 10:09:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14854 for ; Mon, 16 Jun 2003 10:09:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rudc-0002rC-00 for gsmp@ietf.org; Mon, 16 Jun 2003 10:07:12 -0400 Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx with esmtp (Exim 4.12) id 19Rudb-0002r0-00 for gsmp@ietf.org; Mon, 16 Jun 2003 10:07:11 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GE8f425175; Mon, 16 Jun 2003 16:08:42 +0200 (MEST) Received: from zctfc002.europe.nortel.com ([47.164.129.43]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M6QQ37CZ; Mon, 16 Jun 2003 16:08:40 +0200 Received: from nortelnetworks.com (ksundell-1.europe.nortel.com [47.167.132.215]) by zctfc002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MNLRQNXA; Mon, 16 Jun 2003 16:08:41 +0200 Message-ID: <3EEDD07A.6020609@nortelnetworks.com> Date: Mon, 16 Jun 2003 16:13:14 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: Kenneth Sundell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: gsmp CC: avri Content-Type: multipart/alternative; boundary="------------050601010305090106000105" Subject: [GSMP] IETF57: GSMP WG Agenda items Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , --------------050601010305090106000105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, the GSMP WG has been assigned an hour timeslot at the next IETF meeting in Vienna (Wednesday 1545-1645). The WG will focus this time on the drafts that are in Standards Track: draft-ietf-gsmp-v3-base-spec-01.txt draft-ietf-gsmp-packet-spec-00.txt draft-ietf-gsmp-optical-spec-01.txt these are expected to be updated before the IETF57. If you have any additional agenda item, please be sure to notify myself or Avri. The draft cutoff dates and procedures for submitting initial drafts are attached below. Cheers, Ken -- NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html --------------050601010305090106000105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,

the GSMP WG has been assigned an hour timeslot at the next IETF meeting in Vienna (Wednesday 1545-1645). The WG will focus this time on the drafts that are in Standards Track:

draft-ietf-gsmp-v3-base-spec-01.txt
draft-ietf-gsmp-packet-spec-00.txt
draft-ietf-gsmp-optical-spec-01.txt

these are expected to be updated before the IETF57.

If you have any additional agenda item, please be sure to notify myself or Avri. The draft cutoff dates and procedures for submitting initial drafts are attached below.

Cheers,
Ken

--
NOTE: There are two (2) Internet-Draft Cutoff dates

June 23rd: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, June 23rd, 
at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.

 
As before, all initial submissions (-00.txt) with a filename beginning
with a draft-ietf MUST be approved by the appropriate WG Chair prior to
processing and announcing. WG Chair approval must be received by
Monday, June 16th.

 Please do NOT wait until the last minute to submit.

Be advised: NO placeholders. Updates to initial submissions received
            the week of June 23rd will NOT be accepted.

June 30st: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Monday,
June 30st, 2003 at 09:00 ET.  Internet-Drafts received after this
time will NOT be announced NOR made available in the Int
ernet-Drafts
Directories.

We will begin accepting Internet-Draft submissions the week of the
meeting, though announcements will NOT be sent until the IETF meeting
is over.

Thank you for your understanding and cooperation. Please do not hesitate
to contact us if you have any questions or concenrs.

FYI: These and other significant dates can be found at
      http://www.ietf.org/meetings/cutoff_dates_57.html
 
--------------050601010305090106000105-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 19 23:04:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01147 for ; Thu, 19 Jun 2003 23:04:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K343F25098 for gsmp-archive@odin.ietf.org; Thu, 19 Jun 2003 23: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 19TCC3-0006Wj-KP for gsmp-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 23:04: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 XAA01127 for ; Thu, 19 Jun 2003 23:03:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TC9j-000669-00 for gsmp-web-archive@ietf.org; Thu, 19 Jun 2003 23:01:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TC9i-000665-00 for gsmp-web-archive@ietf.org; Thu, 19 Jun 2003 23:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TCC1-0006WK-Iq; Thu, 19 Jun 2003 23: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 19TCBm-0006Vx-KE for gsmp@optimus.ietf.org; Thu, 19 Jun 2003 23:03: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 XAA01084 for ; Thu, 19 Jun 2003 23:03:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TC9S-00065I-00 for gsmp@ietf.org; Thu, 19 Jun 2003 23:01:22 -0400 Received: from apocalypse.org ([192.48.232.17] ident=[of83yUOknr8m7wEcHHhT1CMWBQlJx9ba]) by ietf-mx with esmtp (Exim 4.12) id 19TC9R-000658-00 for gsmp@ietf.org; Thu, 19 Jun 2003 23:01:21 -0400 Received: from apocalypse.org (IDENT:fG/LH7y0x9gLcYRTRSOrwmPxgrQeAYN1@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5K33eG12566 for ; Thu, 19 Jun 2003 23:03:40 -0400 Date: Fri, 20 Jun 2003 12:03:36 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] Shorter msg for add reservations Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As promised a specific message on header compression. On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: > > > - there has been an issue concerning the size of the gsmp > message header brought up by the folks working on > optical burst switching - i will send a specific message to the > list on this issue. > So, what do people think? Should there be a general mechanism inserted similar to the short headers we removed over 2 years ago? Some new sort of header compression? Should there be a new mechanism related solely to reservations. I.e. a new add-reservation message is created that includes only [vers, sub, msg type, result, code] [partition id, transaction id] [reservation id] [I, submsg, length] or is this needed - though we may be able to use a bulk mechanism for other add-resv uses anything else? and is this still too big? And does the reservation message need to changed to allow for these complete reservations. What, if anything needs to be added to the reservation message? Opinions? suggestions? Please, speak up. As an editor, I am am working on the update for the upcoming meeting at the moment, and need guidance. As a co-chair, I would like to know if there is consensus on making such a change. I encourage the Optical draft team to discuss their rationale and needs on the list in response to this message. a. note: since i am functioning as a co-chair and editor, any process issues that may arise from this dual role will be handled by the other co-chair _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Fri Jun 20 08:17:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02179 for ; Fri, 20 Jun 2003 08:17:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KCHHu02029 for gsmp-archive@odin.ietf.org; Fri, 20 Jun 2003 08:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKpR-0000We-3E for gsmp-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 08:17: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 IAA02103 for ; Fri, 20 Jun 2003 08:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TKn5-00035m-00 for gsmp-web-archive@ietf.org; Fri, 20 Jun 2003 08:14:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TKn4-00035j-00 for gsmp-web-archive@ietf.org; Fri, 20 Jun 2003 08:14:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKpA-0000WJ-Lf; Fri, 20 Jun 2003 08: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 19TKoE-0000Jn-8h for gsmp@optimus.ietf.org; Fri, 20 Jun 2003 08: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 IAA01924 for ; Fri, 20 Jun 2003 08:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TKls-000320-00 for gsmp@ietf.org; Fri, 20 Jun 2003 08:13:36 -0400 Received: from apocalypse.org ([192.48.232.17] ident=[J0Npwd17HFiRIES5Xa9TkC8EIqwawDTg]) by ietf-mx with esmtp (Exim 4.12) id 19TKlm-00031g-00 for gsmp@ietf.org; Fri, 20 Jun 2003 08:13:32 -0400 Received: from apocalypse.org (IDENT:2YvQgkiOd1QhfEv9gxy/lCP9E21mYZB5@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5KCFjG19220 for ; Fri, 20 Jun 2003 08:15:45 -0400 Date: Fri, 20 Jun 2003 21:15:44 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] Opinion requested: Restoration functionality Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Section 2.8 of draft-ietf-gsmp-reqs-06 references OXC restoration capabilities. I am finally working on the update of the base spec. Is the restoration info specific to optical technology or would it be useful as a general part of the base spec. i.e. are technologies outside of optical likely to use the protection mechanisms? Answers to the list please. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Fri Jun 20 09:31:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05758 for ; Fri, 20 Jun 2003 09:31:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KDV4w20152 for gsmp-archive@odin.ietf.org; Fri, 20 Jun 2003 09:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLyq-0005Ex-I8 for gsmp-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 09:31: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 JAA05739 for ; Fri, 20 Jun 2003 09:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLyo-0003zo-00 for gsmp-web-archive@ietf.org; Fri, 20 Jun 2003 09:31:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TLyo-0003zl-00 for gsmp-web-archive@ietf.org; Fri, 20 Jun 2003 09:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLyn-0005Ec-1S; Fri, 20 Jun 2003 09: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 19TLyX-0005E7-BB for gsmp@optimus.ietf.org; Fri, 20 Jun 2003 09:30: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 JAA05727 for ; Fri, 20 Jun 2003 09:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLyV-0003zi-00 for gsmp@ietf.org; Fri, 20 Jun 2003 09:30:43 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19TLyU-0003ze-00 for gsmp@ietf.org; Fri, 20 Jun 2003 09:30:42 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KDTuP01889; Fri, 20 Jun 2003 09:29:56 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 09:29:56 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343EC3@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: "'avri'" , gsmp@ietf.org Subject: RE: [GSMP] Opinion requested: Restoration functionality Date: Fri, 20 Jun 2003 09:29:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33730.09835C2C" Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33730.09835C2C Content-Type: text/plain Protection functions are not exclusively found in transport switches. For example, ITU-T recommendation I.630 defines ATM protection. One could also consider backup next hops in an IP forwarding table a form of restoration. In transport architecture there is a difference between protection and restoration. Generally speaking, protection involves the repair of a link connection without affecting the endpoint of the circuit. Restoration involves the repair of a circuit that includes changing the endpoint (like a dropped telephone call followed by redialing). The draft only addresses protection. Protection mechanisms can apply to circuit based switches (TDM, SDH, etc.). I don't think they are fully applicable to packet based switches (IP, ATM). For example, in 1+1 protection the source switch sends traffic down both working and protection paths. I don't know of any packet service that does this between the same source and destination. So, I think that protection has some general and some specific technology application. It doesn't not seem to apply though to packet switching. -----Original Message----- From: avri [mailto:avri@apocalypse.org] Sent: Friday, June 20, 2003 08:16 To: gsmp@ietf.org Subject: [GSMP] Opinion requested: Restoration functionality Section 2.8 of draft-ietf-gsmp-reqs-06 references OXC restoration capabilities. I am finally working on the update of the base spec. Is the restoration info specific to optical technology or would it be useful as a general part of the base spec. i.e. are technologies outside of optical likely to use the protection mechanisms? Answers to the list please. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp ------_=_NextPart_001_01C33730.09835C2C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [GSMP] Opinion requested: Restoration functionality

Protection functions are not exclusively found in = transport switches.  For example, ITU-T recommendation I.630 = defines ATM protection.  One could also consider backup next hops = in an IP forwarding table a form of restoration.

In transport architecture there is a difference = between protection and restoration. Generally speaking, protection = involves the repair of a link connection without affecting the endpoint = of the circuit.  Restoration involves the repair of a circuit that = includes changing the endpoint (like a dropped telephone call followed = by redialing).  The draft only addresses protection.

Protection mechanisms can apply to circuit based = switches (TDM, SDH, etc.).  I don't think they are fully = applicable to packet based switches (IP, ATM).  For example, in = 1+1 protection the source switch sends traffic down both working and = protection paths.  I don't know of any packet service that does = this between the same source and destination.

So, I think that protection has some general and some = specific technology application.  It doesn't not seem to apply = though to packet switching.


-----Original Message-----
From: avri [mailto:avri@apocalypse.org] =
Sent: Friday, June 20, 2003 08:16
To: gsmp@ietf.org
Subject: [GSMP] Opinion requested: Restoration = functionality


Section 2.8 of draft-ietf-gsmp-reqs-06 = references
OXC restoration capabilities.  I am finally = working
on the update of the base spec.

Is the restoration info specific to optical = technology or
would it be useful as a general part of the base = spec.

i.e. are technologies outside of optical likely to = use
the protection mechanisms?

Answers to the list please.

thanks

a.


_______________________________________________
GSMP mailing list
GSMP@ietf.org
https://www1.ietf.org/mailman/listinfo/gsmp=

------_=_NextPart_001_01C33730.09835C2C-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Jun 23 08:04:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17456 for ; Mon, 23 Jun 2003 08:04:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NC4Dm22684 for gsmp-archive@odin.ietf.org; Mon, 23 Jun 2003 08:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQ3R-0005tn-70 for gsmp-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 08:04: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 IAA17442 for ; Mon, 23 Jun 2003 08:04:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQ3Q-0001fh-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:04:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UQ3K-0001fc-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQ3F-0005rf-Hc; Mon, 23 Jun 2003 08: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 19UQ2S-0005rE-UU for gsmp@optimus.ietf.org; Mon, 23 Jun 2003 08: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 IAA17394 for ; Mon, 23 Jun 2003 08:02:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQ2D-0001fP-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:02:57 -0400 Received: from h42s128a211n47.user.nortelnetworks.com ([47.211.128.42] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19UQ22-0001fE-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:02:46 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NC1mC07168; Mon, 23 Jun 2003 13:01:48 +0100 (BST) Received: from zctfc002.europe.nortel.com ([47.164.129.43]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NB6M8SM4; Mon, 23 Jun 2003 14:01:44 +0200 Received: from nortelnetworks.com (ksundell-1.europe.nortel.com [47.167.132.215]) by zctfc002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MNLRQ4QJ; Mon, 23 Jun 2003 14:01:45 +0200 Message-ID: <3EF6ED4A.1080308@nortelnetworks.com> Date: Mon, 23 Jun 2003 14:06:34 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: Kenneth Sundell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: avri CC: gsmp@ietf.org Subject: Re: [GSMP] Shorter msg for add reservations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi avri, comments are inline. avri wrote: > As promised a specific message on header compression. > > On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: > >> >> >> - there has been an issue concerning the size of the gsmp >> message header brought up by the folks working on >> optical burst switching - i will send a specific message to the >> list on this issue. >> > > So, what do people think? > > Should there be a general mechanism inserted similar to the > short headers we removed over 2 years ago? Some new sort > of header compression? > > Should there be a new mechanism related solely to reservations. > I.e. a new add-reservation message is created that includes only > > [vers, sub, msg type, result, code] > [partition id, transaction id] > [reservation id] > [I, submsg, length] or is this needed - though we may be able to > use a bulk mechanism for other add-resv > uses I think it makes sence. I would prefer not to change existing messages for two reasons; existing implementations are using the messages and secondly, there is no room for additional flags in the headers. I would suggest to add a message type for the purpose. If the new message type is believed to be usable for other switch types as well i would propose putting it into the base spec. > > anything else? and is this still too big? I can't see how to make it smaller if we should keep using the general headers. > > And does the reservation message need to changed > to allow for these complete reservations. What, if anything needs > to be added to the reservation message? The reservation management message is specified to allow reservation of resources before the labels (to be coupled to the resources) are known, e.g. in the case of MPLS downstream on demand label distribution. I think that message type serves its purpose already and doesn't need to be modified. I think a new msg type should be added. > > Opinions? suggestions? > > Please, speak up. As an editor, I am am working on the > update for the upcoming meeting at the moment, and need > guidance. > > As a co-chair, I would like to know if there is consensus on making > such a change. > > I encourage the Optical draft team to discuss their rationale and needs > on the list in response to this message. Will this change be helpful to the optical design team? I would be interested in hearing their opinion. Cheers, Ken > > > a. > > note: since i am functioning as a co-chair and editor, any process > issues that may arise from this dual role will be handled by the other > co-chair > > > > _______________________________________________ > GSMP mailing list > GSMP@ietf.org > https://www1.ietf.org/mailman/listinfo/gsmp > _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Jun 23 08:40:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18281 for ; Mon, 23 Jun 2003 08:40:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NCe8C28002 for gsmp-archive@odin.ietf.org; Mon, 23 Jun 2003 08:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQcC-0007HZ-0C for gsmp-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 08:40: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 IAA18275 for ; Mon, 23 Jun 2003 08:40:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQcA-0001qE-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UQc5-0001qB-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQc5-0007F8-NX; Mon, 23 Jun 2003 08: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 19UQbr-0007Eb-1r for gsmp@optimus.ietf.org; Mon, 23 Jun 2003 08:39: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 IAA18262 for ; Mon, 23 Jun 2003 08:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQbp-0001pz-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:39:45 -0400 Received: from relay5.kornet.net ([211.48.62.165]) by ietf-mx with esmtp (Exim 4.12) id 19UQbf-0001pK-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:39:35 -0400 Received: from [220.89.170.14] (avri@apocalypse.org) by relay5.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062321:38:20:071118.11462.21 for ; Mon, 23 Jun 2003 21:38:19 +0900 (KST) Date: Mon, 23 Jun 2003 21:38:21 +0900 Subject: Re: [GSMP] Shorter msg for add reservations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: gsmp@ietf.org Content-Transfer-Encoding: quoted-printable In-Reply-To: <3EF6ED4A.1080308@nortelnetworks.com> Message-Id: <92A35AA1-A577-11D7-9101-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable i definitely think any new msg. should be in the base spec. so this could be a trigger reservations msg. it would only work for triggering reservations that had been made with full label info etc.. (i.e. non 0 value for label) btw, i go the msg wrong in my previous msg., i left out the port session id. msg: triggered add [vers, sub, msg type, result, code] [partition id, transaction id] [I, submsg, length] [port session id] [reservation id] codes would include one for rejecting the trigger if the reservation was not complete. opinions? is it useful in general? does it satisfy the burst switch requirements? btw, on the subject of changing messages. there will be several changes, perhaps not for this problem, but with adding support for protection. i am still trying to figure out the minimum possible change that will support the variety of possibilities. email on this tomorrow - i hope. . On m=E5ndag, jun 23, 2003, at 21:06 Asia/Seoul, Kenneth Sundell wrote: > > hi avri, > comments are inline. > > avri wrote: > >> As promised a specific message on header compression. >> >> On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: >> >>> >>> >>> - there has been an issue concerning the size of the gsmp >>> message header brought up by the folks working on >>> optical burst switching - i will send a specific message to the >>> list on this issue. >>> >> >> So, what do people think? >> >> Should there be a general mechanism inserted similar to the >> short headers we removed over 2 years ago? Some new sort >> of header compression? >> >> Should there be a new mechanism related solely to reservations. >> I.e. a new add-reservation message is created that includes only >> >> [vers, sub, msg type, result, code] >> [partition id, transaction id] >> [reservation id] >> [I, submsg, length] or is this needed - though we may be able to >> use a bulk mechanism for other=20 >> add-resv uses > > I think it makes sence. I would prefer not to change existing messages=20= > for two reasons; existing implementations are using the messages and=20= > secondly, there is no room for additional flags in the headers. I=20 > would suggest to add a message type for the purpose. If the new=20 > message type is believed to be usable for other switch types as well i=20= > would propose putting it into the base spec. > >> >> anything else? and is this still too big? > > I can't see how to make it smaller if we should keep using the general=20= > headers. > >> >> And does the reservation message need to changed >> to allow for these complete reservations. What, if anything needs >> to be added to the reservation message? > > The reservation management message is specified to allow reservation=20= > of resources before the labels (to be coupled to the resources) are=20 > known, e.g. in the case of MPLS downstream on demand label=20 > distribution. I think that message type serves its purpose already and=20= > doesn't need to be modified. I think a new msg type should be added. > >> >> Opinions? suggestions? >> >> Please, speak up. As an editor, I am am working on the >> update for the upcoming meeting at the moment, and need >> guidance. >> >> As a co-chair, I would like to know if there is consensus on making >> such a change. >> >> I encourage the Optical draft team to discuss their rationale and=20 >> needs >> on the list in response to this message. > > Will this change be helpful to the optical design team? I would be=20 > interested in hearing their opinion. > > Cheers, > Ken > >> >> >> a. >> >> note: since i am functioning as a co-chair and editor, any process >> issues that may arise from this dual role will be handled by the = other >> co-chair >> >> >> >> _______________________________________________ >> GSMP mailing list >> GSMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/gsmp >> > > _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Jun 23 10:27:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22622 for ; Mon, 23 Jun 2003 10:27:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NER8G12216 for gsmp-archive@odin.ietf.org; Mon, 23 Jun 2003 10:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USHk-0003Ax-NV for gsmp-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 10:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22595 for ; Mon, 23 Jun 2003 10:27:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USHi-0002X9-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 10:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19USHc-0002X5-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 10:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19USHd-00039V-Cw; Mon, 23 Jun 2003 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 19USGn-00035v-Ez for gsmp@optimus.ietf.org; Mon, 23 Jun 2003 10:26: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 KAA22565 for ; Mon, 23 Jun 2003 10:26:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USGl-0002Wl-00 for gsmp@ietf.org; Mon, 23 Jun 2003 10:26:07 -0400 Received: from relay2.kornet.net ([211.48.62.162]) by ietf-mx with esmtp (Exim 4.12) id 19USGa-0002Vz-00 for gsmp@ietf.org; Mon, 23 Jun 2003 10:25:56 -0400 Received: from [220.89.170.14] (avri@apocalypse.org) by relay2.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062323:24:24:491978.11561.11 for ; Mon, 23 Jun 2003 23:24:24 +0900 (KST) Date: Mon, 23 Jun 2003 23:24:24 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <63B4D448-A586-11D7-9101-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] capability sets Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit the one in the base spec now, is technology specific, so it will need to be moved to the packet based spec. 2 questions: -should each technology have a specific capability set definition. i think so, but am interested in hearing other opinions. -can it remain the fixed size? [capset id, traffic flags] [tech specific] [tech specific] the capset id would be subdivided to allow each technology its own range. or should it be variable? i.e. [capset id, length] [flags, tech specific] . . [tech specific] opinions please? i tend toward the fixed option, but if there is a good reason for a variable length block, please let me know. i am especially interested in hearing from the tech specific design teams. thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Wed Jun 25 12:19:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19739 for ; Wed, 25 Jun 2003 12:19:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGJDr08488 for gsmp-archive@odin.ietf.org; Wed, 25 Jun 2003 12:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCzJ-0002Cp-P9 for gsmp-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:19: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 MAA19718 for ; Wed, 25 Jun 2003 12:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCzJ-00056G-00 for gsmp-web-archive@ietf.org; Wed, 25 Jun 2003 12:19:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCzD-00056B-00 for gsmp-web-archive@ietf.org; Wed, 25 Jun 2003 12:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCz7-0002Ab-88; Wed, 25 Jun 2003 12: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 19VCyq-0002AD-Mj for gsmp@optimus.ietf.org; Wed, 25 Jun 2003 12:18: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 MAA19678 for ; Wed, 25 Jun 2003 12:18:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCyb-00055z-00 for gsmp@ietf.org; Wed, 25 Jun 2003 12:18:29 -0400 Received: from dsl092-074-154.bos1.dsl.speakeasy.net ([66.92.74.154] helo=fsbsd.thefsb.org) by ietf-mx with smtp (Exim 4.12) id 19VCyP-0004zb-00 for gsmp@ietf.org; Wed, 25 Jun 2003 12:18:18 -0400 Received: (qmail 98618 invoked from network); 25 Jun 2003 16:03:59 -0000 Received: from unknown (HELO ?66.92.74.156?) (66.92.74.156) by dsl092-074-154.bos1.dsl.speakeasy.net with SMTP; 25 Jun 2003 16:03:59 -0000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 25 Jun 2003 12:03:58 -0400 Subject: Re: [GSMP] Shorter msg for add reservations From: tom worster To: gsmp list Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit on 6/19/03 11:03 PM, "avri" wrote: > As promised a specific message on header compression. > > On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: > >> - there has been an issue concerning the size of the gsmp >> message header brought up by the folks working on >> optical burst switching - i will send a specific message to the >> list on this issue. > > So, what do people think? can someone perhaps explain the problem as the optical burst switching people see it? i'm not sure that i understand why gsmp packets in particular, as opposed to all the other long packets in the world, need to be made shorter. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 07:15:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15407 for ; Thu, 26 Jun 2003 07:15:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QBF8t15932 for gsmp-archive@odin.ietf.org; Thu, 26 Jun 2003 07:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUia-00048W-1u for gsmp-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 07:15: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 HAA15403 for ; Thu, 26 Jun 2003 07:15:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUiZ-0007V5-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 07:15:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VUiU-0007V2-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 07:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUiT-00045Q-85; Thu, 26 Jun 2003 07: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 19VUiA-00044r-FI for gsmp@optimus.ietf.org; Thu, 26 Jun 2003 07:14: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 HAA15384 for ; Thu, 26 Jun 2003 07:14:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUhu-0007Ug-00 for gsmp@ietf.org; Thu, 26 Jun 2003 07:14:26 -0400 Received: from relay5.kornet.net ([211.48.62.165]) by ietf-mx with esmtp (Exim 4.12) id 19VUhf-0007UT-00 for gsmp@ietf.org; Thu, 26 Jun 2003 07:14:11 -0400 Received: from [220.89.169.82] (avri@apocalypse.org) by relay5.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062620:12:44:455019.11462.3488 for ; Thu, 26 Jun 2003 20:12:44 +0900 (KST) Date: Thu, 26 Jun 2003 20:12:44 +0900 Content-Type: multipart/alternative; boundary=Apple-Mail-41-1009352878 Mime-Version: 1.0 (Apple Message framework v552) From: avri To: gsmp@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E604343ED1@zcard0ke.ca.nortel.com> Message-Id: <1C0D62EE-A7C7-11D7-946F-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: [GSMP] Bulk Transactions Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-41-1009352878 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable This mention of bulk messages reminded me that there was a requirement: 2.7.2. Bulk Transactions in the requirements draft. I have a question about these. not about their importance, but about their atomicity. Currently we have only one error code in a message. So, do we consider a bulk message a single action? this would mean that if even one of the transactions failed, the entire command would fail. in order for state to be determinate, this would mean the switch would be responsible for undoing any transaction that had been completed. Or are we saying that we need for each transaction to be an atom it is own right and thus each one will need its own error code. I tend toward the former, thus placing the burden of being able to guarantee to undo any changes on the switch. And if the switch is not equipped to do so, it should reject bulk transactions. Another questions i have: - Do we modify existing messages to support bulk transactions or do we create new messages. - and if so what needs to be bulk enabled: - add is obvious - reservation - or is the triggered add i wrote about sufficient if it has the bulk transaction capability, with an individual reservation message needed prior to each transaction. I tend toward the third possibility. Comments on both issues please! a. On tisdag, jun 24, 2003, at 01:25 Asia/Seoul, Stephen Shew wrote: > I'm not familiar with the short header work and can't judge its=20 > usefulness for burst switching.=A0 Can they be used in a bulk message=20= > (multiple adds for example)? > > -----Original Message----- > From: avri [mailto:avri@apocalypse.org] > Sent: Thursday, June 19, 2003 23:04 > To: gsmp@ietf.org > Subject: [GSMP] Shorter msg for add reservations > > > As promised a specific message on header compression. > > On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: > > > > > > > - there has been an issue concerning the size of the gsmp message > > header brought up by the folks working on optical burst switching - = i > > will send a specific message to the list on this issue. > > > > So, what do people think? > > Should there be a general mechanism inserted similar to the short=20 > headers we removed over 2 years ago?=A0 Some new sort of header=20 > compression? > > Should there be a new mechanism related solely to reservations. I.e. a=20= > new add-reservation message is created that includes only > > [vers, sub, msg type, result, code] > [partition id, transaction id] > [reservation id] > [I, submsg, length]=A0 or is this needed - though we may be able to > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 use a bulk mechanism for other add-resv > uses > > anything else?=A0=A0 and is this still too big? > > And does the reservation message need to=A0 changed > to allow for these complete reservations.=A0 What, if anything needs = to=20 > be added to the reservation message? > > Opinions?=A0 suggestions? > > Please, speak up. As an editor, I am am working on the > update for the upcoming meeting at the moment, and need guidance. > > As a co-chair, I would like to know if there is consensus on making=20 > such a change. > > I encourage the Optical draft team to discuss their rationale and=20 > needs on the list in response to this message. > > > a. > > note: since i am functioning as a co-chair and editor, any process=20 > issues that may arise from this dual role will be handled by the other=20= > co-chair > > > > _______________________________________________ > GSMP mailing list > GSMP@ietf.org > https://www1.ietf.org/mailman/listinfo/gsmp > --Apple-Mail-41-1009352878 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This mention of bulk messages reminded me that there was a requirement: 2.7.2. Bulk Transactions in the requirements draft. I have a question about these. =20 not about their importance, but about their atomicity. Currently we have only one error code in a message. So, do we consider a bulk message a single action? this would mean that if even one of the transactions failed, the entire command would fail. in order for state to be determinate, this would mean the=20 switch would be responsible for undoing any transaction that had been completed. Or are we saying that we need for each transaction to be an atom it is own right and thus each one will need its own error code. I tend toward the former, thus placing the burden of being able to guarantee to undo any changes on the switch. And if the=20 switch is not equipped to do so, it should reject bulk transactions. Another questions i have: - Do we modify existing messages to support bulk transactions or do we create new messages. - and if so what needs to be bulk enabled: - add is obvious - reservation - or is the triggered add i wrote about sufficient if it has the bulk transaction capability, with an=20 individual reservation message needed prior to each transaction. I tend toward the third possibility. Comments on both issues please! a. On tisdag, jun 24, 2003, at 01:25 Asia/Seoul, Stephen Shew wrote: I'm not familiar with the short header work and can't judge its usefulness for burst switching.=A0 Can they be used in a bulk message (multiple adds for example)? -----Original Message----- From: avri = [1998,1998,FFFEmailto:avri@apocalypse.org= ] Sent: Thursday, June 19, 2003 23:04 To: gsmp@ietf.org Subject: [GSMP] Shorter msg for add reservations As promised a specific message on header compression. On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri = wrote: > > > - there has been an issue concerning the size of the gsmp message > header brought up by the folks working on optical burst switching - i > will send a specific message to the list on this issue. > So, what do people think? Should there be a general mechanism inserted similar to the short headers we removed over 2 years ago?=A0 Some new sort of header compression? Should there be a new mechanism related solely to reservations. I.e. a new add-reservation message is created that includes only [vers, sub, msg type, result, code] [partition id, transaction id] [reservation id] [I, submsg, length]=A0 or is this needed - though we may be able to =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 use a bulk mechanism for other add-resv uses anything else?=A0=A0 and is this still too big? And does the reservation message need to=A0 changed to allow for these complete reservations.=A0 What, if anything needs to be added to the reservation message? Opinions?=A0 suggestions? Please, speak up. As an editor, I am am working on the update for the upcoming meeting at the moment, and need = guidance. As a co-chair, I would like to know if there is consensus on making such a change. I encourage the Optical draft team to discuss their rationale and needs on the list in response to this message. a. note: since i am functioning as a co-chair and editor, any process issues that may arise from this dual role will be handled by the other co-chair _______________________________________________ GSMP mailing list GSMP@ietf.org = 1998,1998,FFFEhttps://www1.ietf.org/mailm= an/listinfo/gsmp = --Apple-Mail-41-1009352878-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 07:52:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16102 for ; Thu, 26 Jun 2003 07:52:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QBq9Z26656 for gsmp-archive@odin.ietf.org; Thu, 26 Jun 2003 07:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVIP-0006vr-Ey for gsmp-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 07:52: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 HAA16091 for ; Thu, 26 Jun 2003 07:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VVIO-0007eP-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 07:52:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VVIJ-0007eM-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 07:52:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVIG-0006tT-Vp; Thu, 26 Jun 2003 07:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVHc-0006qj-OR for gsmp@optimus.ietf.org; Thu, 26 Jun 2003 07:51: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 HAA16081 for ; Thu, 26 Jun 2003 07:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VVHb-0007e9-00 for gsmp@ietf.org; Thu, 26 Jun 2003 07:51:19 -0400 Received: from relay5.kornet.net ([211.48.62.165]) by ietf-mx with esmtp (Exim 4.12) id 19VVHR-0007dy-00 for gsmp@ietf.org; Thu, 26 Jun 2003 07:51:09 -0400 Received: from [220.89.169.82] (avri@apocalypse.org) by relay5.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062620:46:36:056588.11462.7 for ; Thu, 26 Jun 2003 20:46:35 +0900 (KST) Date: Thu, 26 Jun 2003 20:46:34 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] Agenda Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is that time again. I am proposing doing something slightly different with our hour this time. Instead of doing the standard status report on each of the working group documents, I propose that this be done on line by each of the editors at least a week before the meeting (i.e. sometime shortly after the submission deadline). We can devote a short time at the end of the meeting for any questions people have on the status - no more then 5 mins for all of them together. What I propose is that we take each of the open issues and devote some time to discussing them. In order to be included on the agenda, the issue must have at least been introduced on the list, must relate to one of the wg documents and hopefully should have been discussed somewhat on the list beforehand. Each discussion should consist of a short recap of the issue - 1-2 slides max and then discussion. So far, I have the following topics on the list: - Triggered Add msg and burst switch requirements - Bulk Transactions - Capability sets - Restoration generalized For other issues (and I think there may be - for example how we handle adaptations) please send a brief explanation of the problem to the list and let me know you need a slot on the agenda. Finally, if anyone intends to submit a draft to the group that is not currently a wg draft, please send a brief description to the list with a note on why it is, or should be, relevant to the charter. Thanks a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 12:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08871 for ; Thu, 26 Jun 2003 12:52:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QGqDW27267 for gsmp-archive@odin.ietf.org; Thu, 26 Jun 2003 12: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 19VZyn-00075i-Au for gsmp-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 12:52: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 MAA08832 for ; Thu, 26 Jun 2003 12:52:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VZyl-0003mf-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 12:52:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VZyf-0003mR-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 12: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 19VZyb-000745-9U; Thu, 26 Jun 2003 12: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 19VZxO-00072i-Up for gsmp@optimus.ietf.org; Thu, 26 Jun 2003 12:51: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 MAA08709 for ; Thu, 26 Jun 2003 12:50:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VZx8-0003lK-00 for gsmp@ietf.org; Thu, 26 Jun 2003 12:50:30 -0400 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19VZwv-0003l7-00 for gsmp@ietf.org; Thu, 26 Jun 2003 12:50:17 -0400 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5QGff901858 for ; Thu, 26 Jun 2003 16:41:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5QGgs326850 for ; Thu, 26 Jun 2003 16:42:54 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003062609412710837 ; Thu, 26 Jun 2003 09:41:27 -0700 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:41:05 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33C01.BC273652" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [GSMP] Bulk Transactions Date: Thu, 26 Jun 2003 09:41:04 -0700 Message-ID: Thread-Topic: [GSMP] Bulk Transactions Thread-Index: AcM71Dfh0QG6z2IdQ4uUmFCubZOhqgALUYoA From: "Anderson, Todd A" To: "avri" , X-OriginalArrivalTime: 26 Jun 2003 16:41:05.0217 (UTC) FILETIME=[BC880310:01C33C01] Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C33C01.BC273652 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At least in the ForCES work, the general consensus is that the = controller needs to be able to say whether a bulk message requires atomicity or not. In = either case, I think per sub-message error codes are needed. If atomicity is = required you'd like to know which submessage caused the transaction to fail. If = atomicity is not required, then you need to know which sub-messages succeeded and which = failed. =20 Todd -----Original Message----- From: avri [mailto:avri@apocalypse.org] Sent: Thursday, June 26, 2003 4:13 AM To: gsmp@ietf.org Subject: [GSMP] Bulk Transactions This mention of bulk messages reminded me that there=20 was a requirement:=20 2.7.2. Bulk Transactions=20 in the requirements draft.=20 I have a question about these.=20 not about their importance, but about their atomicity.=20 Currently we have only one error code in a message.=20 So, do we consider a bulk message a single action?=20 this would mean that if even one of the transactions failed,=20 the entire command would fail.=20 in order for state to be determinate, this would mean the=20 switch would be responsible for undoing any transaction=20 that had been completed.=20 Or are we saying that we need for each transaction to be=20 an atom it is own right and thus each one will need its own=20 error code.=20 I tend toward the former, thus placing the burden of being able=20 to guarantee to undo any changes on the switch. And if the=20 switch is not equipped to do so, it should reject bulk transactions.=20 Another questions i have:=20 - Do we modify existing messages to support=20 bulk transactions or do we create new messages.=20 - and if so what needs to be bulk enabled:=20 - add is obvious=20 - reservation=20 - or is the triggered add i wrote about sufficient if=20 it has the bulk transaction capability, with an=20 individual reservation message needed prior=20 to each transaction.=20 I tend toward the third possibility.=20 Comments on both issues please!=20 a.=20 On tisdag, jun 24, 2003, at 01:25 Asia/Seoul, Stephen Shew wrote:=20 I'm not familiar with the short header work and can't judge its = usefulness for burst switching. Can they be used in a bulk message = (multiple adds for example)?=20 -----Original Message-----=20 From: avri [mailto:avri@apocalypse.org]=20 Sent: Thursday, June 19, 2003 23:04=20 To: gsmp@ietf.org=20 Subject: [GSMP] Shorter msg for add reservations=20 As promised a specific message on header compression.=20 On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote:=20 >=20 >=20 > - there has been an issue concerning the size of the gsmp message=20 > header brought up by the folks working on optical burst switching - i=20 > will send a specific message to the list on this issue.=20 >=20 So, what do people think?=20 Should there be a general mechanism inserted similar to the short = headers we removed over 2 years ago? Some new sort of header = compression?=20 Should there be a new mechanism related solely to reservations. I.e. a = new add-reservation message is created that includes only=20 [vers, sub, msg type, result, code]=20 [partition id, transaction id]=20 [reservation id]=20 [I, submsg, length] or is this needed - though we may be able to=20 use a bulk mechanism for other add-resv=20 uses=20 anything else? and is this still too big?=20 And does the reservation message need to changed=20 to allow for these complete reservations. What, if anything needs to be = added to the reservation message?=20 Opinions? suggestions?=20 Please, speak up. As an editor, I am am working on the=20 update for the upcoming meeting at the moment, and need guidance.=20 As a co-chair, I would like to know if there is consensus on making such = a change.=20 I encourage the Optical draft team to discuss their rationale and needs = on the list in response to this message.=20 a.=20 note: since i am functioning as a co-chair and editor, any process = issues that may arise from this dual role will be handled by the other = co-chair=20 _______________________________________________=20 GSMP mailing list=20 GSMP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/gsmp=20 ------_=_NextPart_001_01C33C01.BC273652 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At=20 least in the ForCES work, the general consensus is that the controller = needs=20 to
be=20 able to say whether a bulk message requires atomicity or not.  In = either=20 case,
I=20 think per sub-message error codes are needed.  If atomicity is = required=20 you'd
like=20 to know which submessage caused the transaction to fail.  If = atomicity is=20 not
required, then you need to know which sub-messages succeeded = and which=20 failed.
 
Todd
-----Original Message-----
From: avri=20 [mailto:avri@apocalypse.org]
Sent: Thursday, June 26, 2003 = 4:13=20 AM
To: gsmp@ietf.org
Subject: [GSMP] Bulk=20 Transactions



This mention of bulk messages reminded me that there

was a requirement:

2.7.2. Bulk Transactions

in the requirements draft.


I have a question about these.

not about their importance, but about their atomicity.


Currently we have only one error code in a message.


So, do we consider a bulk message a single action?

this would mean that if even one of the transactions failed,

the entire command would fail.

in order for state to be determinate, this would mean the

switch would be responsible for undoing any transaction

that had been completed.


Or are we saying that we need for each transaction to be

an atom it is own right and thus each one will need its own

error code.


I tend toward the former, thus placing the burden of being able =

to guarantee to undo any changes on the switch. And if the

switch is not equipped to do so, it should reject bulk = transactions.=20


Another questions i have:


- Do we modify existing messages to support

bulk transactions or do we create new messages.

- and if so what needs to be bulk enabled:

- add is obvious

- reservation

- or is the triggered add i wrote about sufficient if

it has the bulk transaction capability, with an

individual reservation message needed prior

to each transaction.


I tend toward the third possibility.


Comments on both issues please!


a.





On tisdag, jun 24, 2003, at 01:25 Asia/Seoul, Stephen Shew wrote: =


I'm not familiar with the short header work and = can't judge=20 its usefulness for burst switching.  Can they be used in a bulk = message=20 (multiple adds for example)?


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

From: avri [mailto:avri@apocalypse.org] =

Sent: Thursday, June 19, 2003 23:04

To: gsmp@ietf.org

Subject: [GSMP] Shorter msg for add = reservations=20



As promised a specific message on header = compression.=20


On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri=20 wrote:


>

>

> - there has been an issue concerning the size = of the gsmp=20 message

> header brought up by the folks working on = optical burst=20 switching - i

> will send a specific message to the list on = this issue.=20

>


So, what do people think?


Should there be a general mechanism inserted similar = to the=20 short headers we removed over 2 years ago?  Some new sort of = header=20 compression?


Should there be a new mechanism related solely to=20 reservations. I.e. a new add-reservation message is created that = includes=20 only


[vers, sub, msg type, result, code]

[partition id, transaction id]

[reservation id]

[I, submsg, length]  or is this needed - though = we may be=20 able to

          &nbs= p;            = ;        =20 use a bulk mechanism for other add-resv

uses


anything else?   and is this still too = big?=20


And does the reservation message need to  = changed=20

to allow for these complete reservations.  = What, if=20 anything needs to be added to the reservation message?


Opinions?  suggestions?


Please, speak up. As an editor, I am am working on = the=20

update for the upcoming meeting at the moment, and = need=20 guidance.


As a co-chair, I would like to know if there is = consensus on=20 making such a change.


I encourage the Optical draft team to discuss their = rationale=20 and needs on the list in response to this message.



a.


note: since i am functioning as a co-chair and = editor, any=20 process issues that may arise from this dual role will be handled by = the other=20 co-chair




_______________________________________________ =

GSMP mailing list

GSMP@ietf.org

https://www1.ietf.org/mailman/listinfo/gsmp =


------_=_NextPart_001_01C33C01.BC273652-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 14:29:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13473 for ; Thu, 26 Jun 2003 14:29:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFf3v15242 for gsmp-archive@odin.ietf.org; Wed, 25 Jun 2003 11: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 19VCOL-0003x1-4E for gsmp-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:41:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16638 for ; Wed, 25 Jun 2003 11:40: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 19VCJP-0001pk-Lv; Wed, 25 Jun 2003 11:35:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxh-0008AG-AO for gsmp@optimus.ietf.org; Wed, 25 Jun 2003 11: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 EAA04550 for ; Wed, 25 Jun 2003 04:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V5Uw-0002lQ-00 for gsmp@ietf.org; Wed, 25 Jun 2003 04:19:22 -0400 Received: from h42s128a211n47.user.nortelnetworks.com ([47.211.128.42] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19V5Ul-0002kx-00 for gsmp@ietf.org; Wed, 25 Jun 2003 04:19:11 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5P8HxK06845; Wed, 25 Jun 2003 09:17:59 +0100 (BST) Received: from zctfc002.europe.nortel.com ([47.164.129.43]) by zctfc040.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NB6M9HFS; Wed, 25 Jun 2003 10:17:51 +0200 Received: from nortelnetworks.com (ksundell-1.europe.nortel.com [47.167.132.215]) by zctfc002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MNLRQWQC; Wed, 25 Jun 2003 10:17:53 +0200 Message-ID: <3EF95BDC.1020007@nortelnetworks.com> Date: Wed, 25 Jun 2003 10:22:52 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: Kenneth Sundell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: avri CC: gsmp@ietf.org Subject: Re: [GSMP] capability sets References: <63B4D448-A586-11D7-9101-000393CC2112@apocalypse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, avri wrote: > the one in the base spec now, is technology specific, so it will > need to be moved to the packet based spec. > > 2 questions: > > -should each technology have a specific capability > set definition. i think so, but am interested in hearing other opinions. agree. i support the move to the packet spec. > > -can it remain the fixed size? > [capset id, traffic flags] > [tech specific] > [tech specific] > > the capset id would be subdivided to allow each technology > its own range. > > or should it be variable? > i.e. > [capset id, length] > [flags, tech specific] > . > . > [tech specific] > > opinions please? i tend toward the fixed option, > but if there is a good reason for a variable length > block, please let me know. > > i am especially interested in hearing from the > tech specific design teams. speaking for the packet spec team, the fixed format should be fine. anyone seeing a need for further parameters in the capability sets should speak up at this point, it would justify adding the variable length option. otherwise i will just leave it as is stands. i guess the base spec wouldn't be impacted in either case since it won't define the capability set record format in the next revision (after the move to the packet spec). cheers, ken > > thanks > a. > > > > _______________________________________________ > GSMP mailing list > GSMP@ietf.org > https://www1.ietf.org/mailman/listinfo/gsmp > -- Kenneth Sundell Sr. Protocols Architect CTO/ATI Strategic Protocols Nortel Networks (Sweden) ESN 521-3538, Ext IAC+46 8 5088-3538 _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 14:52:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14776 for ; Thu, 26 Jun 2003 14:52:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGS9u03081 for gsmp-archive@odin.ietf.org; Mon, 23 Jun 2003 12:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUAr-0000nc-3n for gsmp-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 12:28: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 MAA27562 for ; Mon, 23 Jun 2003 12:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUAp-0003aP-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 12:28:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UUAj-0003aM-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 12:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUAj-0000mE-Ge; Mon, 23 Jun 2003 12: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 19UUA8-0000lO-Uz for gsmp@optimus.ietf.org; Mon, 23 Jun 2003 12:27: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 MAA27513 for ; Mon, 23 Jun 2003 12:27:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUA7-0003ZU-00 for gsmp@ietf.org; Mon, 23 Jun 2003 12:27:23 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19UU9w-0003Z2-00 for gsmp@ietf.org; Mon, 23 Jun 2003 12:27:12 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NGPmK23079 for ; Mon, 23 Jun 2003 12:25:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 12:25:48 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343ED1@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: gsmp@ietf.org Subject: RE: [GSMP] Shorter msg for add reservations Date: Mon, 23 Jun 2003 12:25:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C339A3.CEF544BE" Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C339A3.CEF544BE Content-Type: text/plain I'm not familiar with the short header work and can't judge its usefulness for burst switching. Can they be used in a bulk message (multiple adds for example)? -----Original Message----- From: avri [mailto:avri@apocalypse.org] Sent: Thursday, June 19, 2003 23:04 To: gsmp@ietf.org Subject: [GSMP] Shorter msg for add reservations As promised a specific message on header compression. On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote: > > > - there has been an issue concerning the size of the gsmp message > header brought up by the folks working on optical burst switching - i > will send a specific message to the list on this issue. > So, what do people think? Should there be a general mechanism inserted similar to the short headers we removed over 2 years ago? Some new sort of header compression? Should there be a new mechanism related solely to reservations. I.e. a new add-reservation message is created that includes only [vers, sub, msg type, result, code] [partition id, transaction id] [reservation id] [I, submsg, length] or is this needed - though we may be able to use a bulk mechanism for other add-resv uses anything else? and is this still too big? And does the reservation message need to changed to allow for these complete reservations. What, if anything needs to be added to the reservation message? Opinions? suggestions? Please, speak up. As an editor, I am am working on the update for the upcoming meeting at the moment, and need guidance. As a co-chair, I would like to know if there is consensus on making such a change. I encourage the Optical draft team to discuss their rationale and needs on the list in response to this message. a. note: since i am functioning as a co-chair and editor, any process issues that may arise from this dual role will be handled by the other co-chair _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp ------_=_NextPart_001_01C339A3.CEF544BE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [GSMP] Shorter msg for add reservations

I'm not familiar with the short header work and can't = judge its usefulness for burst switching.  Can they be used in a = bulk message (multiple adds for example)?

-----Original Message-----
From: avri [mailto:avri@apocalypse.org] =
Sent: Thursday, June 19, 2003 23:04
To: gsmp@ietf.org
Subject: [GSMP] Shorter msg for add = reservations


As promised a specific message on header = compression.

On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri = wrote:

>
>
> - there has been an issue concerning the size = of the gsmp message
> header brought up by the folks working on = optical burst switching - i
> will send a specific message to the list on = this issue.
>

So, what do people think?

Should there be a general mechanism inserted similar = to the short headers we removed over 2 years ago?  Some new sort = of header compression?

Should there be a new mechanism related solely to = reservations. I.e. a new add-reservation message is created that = includes only

[vers, sub, msg type, result, code]
[partition id, transaction id]
[reservation id]
[I, submsg, length]  or is this needed - though = we may be able to
          &nb= sp;           &nb= sp;         use a bulk = mechanism for other add-resv
uses

anything else?   and is this still too = big?

And does the reservation message need to  = changed
to allow for these complete reservations.  = What, if anything needs to be added to the reservation message?

Opinions?  suggestions?

Please, speak up. As an editor, I am am working on = the
update for the upcoming meeting at the moment, and = need guidance.

As a co-chair, I would like to know if there is = consensus on making such a change.

I encourage the Optical draft team to discuss their = rationale and needs on the list in response to this message.


a.

note: since i am functioning as a co-chair and = editor, any process issues that may arise from this dual role will be = handled by the other co-chair



_______________________________________________
GSMP mailing list
GSMP@ietf.org
https://www1.ietf.org/mailman/listinfo/gsmp=

------_=_NextPart_001_01C339A3.CEF544BE-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Thu Jun 26 16:22:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19921 for ; Thu, 26 Jun 2003 16:22:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QKMAA11392 for gsmp-archive@odin.ietf.org; Thu, 26 Jun 2003 16: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 19VdFy-0002xf-F3 for gsmp-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 16:22: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 QAA19892 for ; Thu, 26 Jun 2003 16:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VdFw-0005dn-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 16:22:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VdFr-0005dk-00 for gsmp-web-archive@ietf.org; Thu, 26 Jun 2003 16: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 19VdFp-0002pP-Je; Thu, 26 Jun 2003 16: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 19VdEy-0002oi-Cg for gsmp@optimus.ietf.org; Thu, 26 Jun 2003 16:21: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 QAA19846 for ; Thu, 26 Jun 2003 16:20:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VdEh-0005dQ-00 for gsmp@ietf.org; Thu, 26 Jun 2003 16:20:51 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19VdEW-0005c9-00 for gsmp@ietf.org; Thu, 26 Jun 2003 16:20:40 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5QKJM801502 for ; Thu, 26 Jun 2003 16:19:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 16:19:22 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E604343EF7@zcard0ke.ca.nortel.com> From: "Stephen Shew" To: gsmp@ietf.org Subject: RE: [GSMP] Bulk Transactions Date: Thu, 26 Jun 2003 16:19:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33C20.3AFCA322" Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33C20.3AFCA322 Content-Type: text/plain I support the atomicity requirement since commands in the bulk message aren't dependent on each other. If there are commands that are dependent on each other then they should be packaged together in some way. As far as reporting the results, the single message reply could contain individual replies for each of the commands. One reason for the bulk message is to improve performance while still being subject to the serial transaction model. Here, I don't have any dependencies between multiple commands, but want to send them all at once without having to wait for the response before sending the next one. I don't have an opinion on the 2nd issue of message design. -----Original Message----- From: avri [mailto:avri@apocalypse.org] Sent: Thursday, June 26, 2003 07:13 To: gsmp@ietf.org Subject: [GSMP] Bulk Transactions This mention of bulk messages reminded me that there was a requirement: 2.7.2. Bulk Transactions in the requirements draft. I have a question about these. not about their importance, but about their atomicity. Currently we have only one error code in a message. So, do we consider a bulk message a single action? this would mean that if even one of the transactions failed, the entire command would fail. in order for state to be determinate, this would mean the switch would be responsible for undoing any transaction that had been completed. Or are we saying that we need for each transaction to be an atom it is own right and thus each one will need its own error code. I tend toward the former, thus placing the burden of being able to guarantee to undo any changes on the switch. And if the switch is not equipped to do so, it should reject bulk transactions. Another questions i have: - Do we modify existing messages to support bulk transactions or do we create new messages. - and if so what needs to be bulk enabled: - add is obvious - reservation - or is the triggered add i wrote about sufficient if it has the bulk transaction capability, with an individual reservation message needed prior to each transaction. I tend toward the third possibility. Comments on both issues please! a. ------_=_NextPart_001_01C33C20.3AFCA322 Content-Type: text/html Message
I support the atomicity requirement since commands in the bulk message aren't dependent on each other.  If there are commands that are dependent on each other then they should be packaged together in some way.  As far as reporting the results, the single message reply could contain individual replies for each of the commands.  One reason for the bulk message is to improve performance while still being subject to the serial transaction model.  Here, I don't have any dependencies between multiple commands, but want to send them all at once without having to wait for the response before sending the next one.
 
I don't have an opinion on the 2nd issue of message design.
-----Original Message-----
From: avri [mailto:avri@apocalypse.org]
Sent: Thursday, June 26, 2003 07:13
To: gsmp@ietf.org
Subject: [GSMP] Bulk Transactions



This mention of bulk messages reminded me that there

was a requirement:

2.7.2. Bulk Transactions

in the requirements draft.


I have a question about these.

not about their importance, but about their atomicity.


Currently we have only one error code in a message.


So, do we consider a bulk message a single action?

this would mean that if even one of the transactions failed,

the entire command would fail.

in order for state to be determinate, this would mean the

switch would be responsible for undoing any transaction

that had been completed.


Or are we saying that we need for each transaction to be

an atom it is own right and thus each one will need its own

error code.


I tend toward the former, thus placing the burden of being able

to guarantee to undo any changes on the switch. And if the

switch is not equipped to do so, it should reject bulk transactions.


Another questions i have:


- Do we modify existing messages to support

bulk transactions or do we create new messages.

- and if so what needs to be bulk enabled:

- add is obvious

- reservation

- or is the triggered add i wrote about sufficient if

it has the bulk transaction capability, with an

individual reservation message needed prior

to each transaction.


I tend toward the third possibility.


Comments on both issues please!


a.


------_=_NextPart_001_01C33C20.3AFCA322-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Fri Jun 27 12:33:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06771 for ; Fri, 27 Jun 2003 12:33:10 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RGWh132346 for gsmp-archive@odin.ietf.org; Fri, 27 Jun 2003 12:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vw9T-0008Pd-L8 for gsmp-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 12:32: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 MAA06718 for ; Fri, 27 Jun 2003 12:32:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vw8x-0004VB-00 for gsmp-web-archive@ietf.org; Fri, 27 Jun 2003 12:32:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Vw8s-0004V8-00 for gsmp-web-archive@ietf.org; Fri, 27 Jun 2003 12: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 19Vw8p-0008J9-Ki; Fri, 27 Jun 2003 12:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vn1i-00062R-Av for gsmp@optimus.ietf.org; Fri, 27 Jun 2003 02:48: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 CAA19344 for ; Fri, 27 Jun 2003 02:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vn1P-0001q2-00 for gsmp@ietf.org; Fri, 27 Jun 2003 02:47:47 -0400 Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx with esmtp (Exim 4.12) id 19Vn1E-0001pw-00 for gsmp@ietf.org; Fri, 27 Jun 2003 02:47:37 -0400 Received: from apocalypse.org (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAHCTMSV; Fri, 27 Jun 2003 15:47:17 +0900 Date: Fri, 27 Jun 2003 15:47:21 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: gsmp@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <33BB01EC-A86B-11D7-9F47-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [GSMP] question on size of reservation id Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit do we really need 32 bits of reservation id? would 16 bits suffice? since reservation ids are a global resource as opposed to a port resource, i am concerned that it might be too small a value. but the concern for parsimony dictate that i should at least ask. the questions comes in the context adding a (result,code) byte to every transaction in a bulk msg. assuming that bulk msgs would only be supported when there was a prexisitng complete reservation, that would give a trigger msd of [header] x 3 [port session id] [reservation id, result, code] and a bulk msg [header] x 3 [port session id] [reservation id, result, code] . . . [port session id] [reservation id, result, code] that is, of course assuming that a bulk msg can support transactions on multiple ports. we could also define it to support msgs on on single port per bulk message. would anyone who has implemented already object to such a change? a. _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp From exim@www1.ietf.org Mon Jun 30 07:38:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11032 for ; Mon, 30 Jun 2003 07:38:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBcGN05141 for gsmp-archive@odin.ietf.org; Mon, 30 Jun 2003 07:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwz9-0001Kq-UZ for gsmp-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07: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 HAA10903 for ; Mon, 30 Jun 2003 07:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wwz9-0005yw-00 for gsmp-web-archive@ietf.org; Mon, 30 Jun 2003 07:38:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wwz3-0005yo-00 for gsmp-web-archive@ietf.org; Mon, 30 Jun 2003 07:38:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwyv-0001B1-NO; Mon, 30 Jun 2003 07: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 19Wwyn-0001AN-Qn for gsmp@optimus.ietf.org; Mon, 30 Jun 2003 07:37:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10797; Mon, 30 Jun 2003 07:37:53 -0400 (EDT) Message-Id: <200306301137.HAA10797@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: gsmp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 30 Jun 2003 07:37:52 -0400 Subject: [GSMP] I-D ACTION:draft-ietf-gsmp-packet-spec-01.txt Sender: gsmp-admin@ietf.org Errors-To: gsmp-admin@ietf.org X-BeenThere: gsmp@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: General Switch Management Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the General Switch Management Protocol Working Group of the IETF. Title : GSMPv3 Packet Capable Switch Support Author(s) : K. Sundell Filename : draft-ietf-gsmp-packet-spec-01.txt Pages : 43 Date : 2003-6-27 The General Switch Management Protocol version 3 (GSMPv3) has been divided into a base specification (describing the semantics of the protocol) together with a set of documents describing protocol extensions to the base. Such extension could be to support switches capable for optical transport. This document adds extensions to the base GSMPv3 specification for controlling MPLS, ATM and Frame Relay capable switches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-gsmp-packet-spec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-gsmp-packet-spec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-gsmp-packet-spec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-gsmp-packet-spec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-gsmp-packet-spec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150140.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ GSMP mailing list GSMP@ietf.org https://www1.ietf.org/mailman/listinfo/gsmp