From owner-gsmp@psyton.com Tue Aug 1 14:22:10 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16942 for ; Tue, 1 Aug 2000 14:22:09 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id NAA01349 for gsmp-list; Tue, 1 Aug 2000 13:57:49 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id NAA01346 for ; Tue, 1 Aug 2000 13:57:48 -0400 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Tue, 1 Aug 2000 12:32:33 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QBFJ7TT9; Tue, 1 Aug 2000 10:32:27 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.176]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QBFL79GQ; Tue, 1 Aug 2000 13:32:26 -0400 Message-ID: <398709A4.F4BA65E2@nortelnetworks.com> Date: Tue, 01 Aug 2000 13:32:20 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Draft of the proposed new charter for GSMP Content-Type: multipart/mixed; boundary="------------F9742B41A250A410F4D3ABAE" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com This is a multi-part message in MIME format. --------------F9742B41A250A410F4D3ABAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have attached a copy of the charter changes which are being proposed for submission to the ADs. A discussion of these is scheduled for Friday's WG meeting. As you will notice, there are currently three primary subject areas that are being proposed for further work: support for switch partitioning support of optical switches support of IP packet switches If there any issues with the subject areas being proposed, please let the list know, and/or come to the meeting for the discussion. Also, if there are any other areas that anyone thinks should be included, please let the list know as soon as possible. Regards a. -- Avri Doria +1 401 663 5024 --------------F9742B41A250A410F4D3ABAE Content-Type: text/plain; charset=us-ascii; name="re-charter3.txt" Content-Disposition: inline; filename="re-charter3.txt" Content-Transfer-Encoding: 7bit GSMP WG Re-Charter The base General Switch Management Protocol(GSMPv3) protocol has been completed and is about to enter the standards process. The GSMP protocol provides switch configuration control and reporting, port management, connection control, QoS and traffic engineering control and the reporting of statistics and asynchronous events for label switch devices. The working group is responsible for completing the standardization of the GSMP protocol. The working group is now defining mechanisms for control of specific additional switch capabilities and types. Current plans for further work include: defining mechanisms for switch partitioning, adding support for optical switching, and defining mechanisms for control of IP packet switches. Since GSMP can be used as an adjunct to the MPLS protocol, the group will continue to co-ordinate with the MPLS group to make sure that the primitives required by a MPLS controller are available in the protocol. Additionally there will cooperation with the IP over Optical WG. Milestones (need projected dates): - Document requirements for switch partitioning - Document requirements for control of optical switches - Document requirements for control of IP packet switches - Produce GSMP extensions, MIBs, and PIBs to support the requirements - Update base GSMPv3 as implementation experience mandates --------------F9742B41A250A410F4D3ABAE-- From owner-gsmp@psyton.com Sun Aug 6 13:12:06 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26449 for ; Sun, 6 Aug 2000 13:11:58 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id MAA20384 for gsmp-list; Sun, 6 Aug 2000 12:41:19 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id MAA20381 for ; Sun, 6 Aug 2000 12:41:17 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Sun, 6 Aug 2000 12:32:22 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QHJPX033; Sun, 6 Aug 2000 09:32:20 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.138]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QG9ZGKAN; Sun, 6 Aug 2000 12:32:18 -0400 Message-ID: <398D930B.86FA034B@nortelnetworks.com> Date: Sun, 06 Aug 2000 12:32:11 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: GSMP@psyton.com Subject: Last Call ending on 18 August Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, As was discussed duirng the recent IETF meeting, the last call for the GSMP docs is scheduled to end on 18 August. The affected documents are: draft-ietf-gsmp-06.txt draft-ietf-gsmp-encaps-02.txt draft-ietf-gsmp-mib-02.txt draft-ietf-gsmp-applicabilty-01.txt All list members are encourage to review and comment before that date. Regards and Thanks for comments already received, a. -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Mon Aug 7 17:16:35 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09317 for ; Mon, 7 Aug 2000 17:16:33 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id RAA24777 for gsmp-list; Mon, 7 Aug 2000 17:01:16 -0400 Received: from mail.cs.umn.edu (root@mail.cs.umn.edu [128.101.33.100]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id RAA24774 for ; Mon, 7 Aug 2000 17:01:15 -0400 Received: from myria.cs.umn.edu (tsang@myria.cs.umn.edu [128.101.35.174]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id QAA07727 for ; Mon, 7 Aug 2000 16:01:07 -0500 (CDT) From: Rose Tsang Received: (from tsang@localhost) by myria.cs.umn.edu (8.9.1/8.9.0) id QAA29407 for gsmp@revnetworks.com; Mon, 7 Aug 2000 16:01:06 -0500 (CDT) Message-Id: <200008072101.QAA29407@myria.cs.umn.edu> Subject: public implementations? To: gsmp@psyton.com Date: Mon, 7 Aug 2000 16:01:06 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi all, Are there any publicly available source distributions for GSMP (any version, but preferably the latest - v3)? Do you have any idea whether support for IP forwarding will be integrated into GSMP soon? Thanks, Rose Tsang From owner-gsmp@psyton.com Tue Aug 8 17:48:14 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07207 for ; Tue, 8 Aug 2000 17:48:05 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id RAA28573 for gsmp-list; Tue, 8 Aug 2000 17:27:14 -0400 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id RAA28570 for ; Tue, 8 Aug 2000 17:27:14 -0400 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id RAA32120 for ; Tue, 8 Aug 2000 17:27:13 -0400 Date: Tue, 8 Aug 2000 17:27:13 -0400 (EDT) From: ad To: gsmp@psyton.com Subject: names in gsmp spec and mib Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, This message has been bouncing becuase Hasse is sumitting it from an address that is not subscribed to the list. To prevent spam, I have closed the list to non-member submissions. Apologies for the inconvenience. a. ps. response later. ---------- Forwarded message ---------- Subject: names in gsmp spec and mib Date: Tue, 8 Aug 2000 22:02:47 +0200 From: Hans Sjostrand Hi, I have a question about names, which kind of goes back to the mib. Is the switch name in the switch configuration message the same as the sender name in the adjacency message? In that case, why is it sent in duplicate? The sender name is already known at the time of the switch configuration message. If not, are the sender name in the adjacency mesage bound by the same type restriction that it should have the 24 most significant bits set to an OUI? And is it possible to think that atleast in most cases they are hte same. translated to mib terms this could mean that we take away the switch name object (if the two are the same) or atleast set the default of the switch name object to the value of VseId. Also, I propose to take out the VsceName which I belive was a misunderstanding from my part because of a writing error in the gsmp spec; I belive that the text "The Switch Configuration message has the following format" on page 83 should be "The Switch Configuration success response message has the following format". Regards /// Hasse From owner-gsmp@psyton.com Tue Aug 8 21:31:34 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26593 for ; Tue, 8 Aug 2000 21:31:33 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id VAA29172 for gsmp-list; Tue, 8 Aug 2000 21:18:20 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id VAA29169 for ; Tue, 8 Aug 2000 21:18:16 -0400 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Tue, 8 Aug 2000 20:14:06 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QHJP83B6; Tue, 8 Aug 2000 18:13:58 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.149]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QG9ZGNNH; Tue, 8 Aug 2000 21:13:56 -0400 Message-ID: <3990B051.24CEE005@nortelnetworks.com> Date: Tue, 08 Aug 2000 21:13:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com, Rose Tsang Subject: Re: public implementations? References: <200008072101.QAA29407@myria.cs.umn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, I don't know of any public source available, though someone on this list spoke of doing a Linux implementation a while back. Hopefully they will respond to your request. As far as the IP forwarding integration goes, this is currently being discussed as a possible future work item. Do you think it is something that should be done? Thanks a. Rose Tsang wrote: > > Hi all, > > Are there any publicly available source distributions for GSMP (any > version, but preferably the latest - v3)? Do you have any idea whether > support for IP forwarding will be integrated into GSMP soon? > > Thanks, > Rose Tsang -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Wed Aug 9 08:43:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15934 for ; Wed, 9 Aug 2000 08:43:24 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id HAA30555 for gsmp-list; Wed, 9 Aug 2000 07:31:56 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id HAA30552 for ; Wed, 9 Aug 2000 07:31:55 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Wed, 9 Aug 2000 07:29:47 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QHJP9A8C; Wed, 9 Aug 2000 04:29:45 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.141]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QG9ZGNPV; Wed, 9 Aug 2000 07:29:44 -0400 Message-ID: <399140A3.EBDEE753@nortelnetworks.com> Date: Wed, 09 Aug 2000 07:29:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: names in gsmp spec and mib References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit > ---------- Forwarded message ---------- > Subject: names in gsmp spec and mib > Date: Tue, 8 Aug 2000 22:02:47 +0200 > From: Hans Sjostrand > > Hi, > > I have a question about names, which kind of goes back to the mib. > > Is the switch name in the switch configuration message the same as the > sender name in the adjacency message? Yes I think they are the same in the case of the switch entity. The VSCE uses its name when it is the sender. > In that case, why is it sent in > duplicate? The sender name is already known at the time of the switch > configuration message. It is needed in the adjacency message to identify the two entities involved in the adjacency. It the switch configuration it might be redundant, but given the funtion of the Switch Configuration message, the redundnacy is probably warranted. > If not, are the sender name in the adjacency mesage > bound by the same type restriction that it should have the 24 most > significant bits set to an OUI? This is a historical restriction. I am not sure that it is is absolutely necessary, but it strongly advised. The wording between the two should probably be clarified and made consistent. > And is it possible to think that atleast > in most cases they are hte same. translated to mib terms this could mean > that we take away the switch name object (if the two are the same) or > atleast set the default of the switch name object to the value of VseId. > > Also, I propose to take out the VsceName which I belive was a > misunderstanding from my part because of a writing error in the gsmp spec; Seems reasonable to me. I can't think of a reason for including both the VsceId and VsceName. > > I belive that the text "The Switch Configuration message has the following > format" on page 83 should be "The Switch Configuration success response > message has the following format". > I don't think so. This is one of the artifacts of GSMP - identical request/response messages. Regards, a. -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Wed Aug 9 14:43:07 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15936 for ; Wed, 9 Aug 2000 14:43:06 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA31663 for gsmp-list; Wed, 9 Aug 2000 14:31:29 -0400 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id OAA31660 for ; Wed, 9 Aug 2000 14:31:28 -0400 Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id LAA21487 for ; Wed, 9 Aug 2000 11:30:54 -0700 (PDT) From: "David Oran" To: Subject: RE: names in gsmp spec and mib Date: Wed, 9 Aug 2000 14:30:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit What, precisely, do you mean by "closing the list"? If it means that postings from non-members are diverted to the moderator for screening, that's fine. If it means rejecting posts explicitly with a note to send to the moderator to request posting to the list, that's less fine but probably ok. If it means simply rejecting messages with no instructions on how to get it posted, or even worse silently dropping it on the floor, that is NOT fine and does not meet the open-ness criteria for IETF WG email lists. Dave. > -----Original Message----- > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > ad > Sent: Tuesday, August 08, 2000 5:27 PM > To: gsmp@psyton.com > Subject: names in gsmp spec and mib > > > Hi, > > This message has been bouncing becuase Hasse is sumitting it from an > address that is not subscribed to the list. To prevent spam, I have > closed the list to non-member submissions. Apologies for the > inconvenience. > > a. > > ps. response later. > > ---------- Forwarded message ---------- > Subject: names in gsmp spec and mib > Date: Tue, 8 Aug 2000 22:02:47 +0200 > From: Hans Sjostrand > > Hi, > > I have a question about names, which kind of goes back to the mib. > > Is the switch name in the switch configuration message the same as the > sender name in the adjacency message? In that case, why is it sent in > duplicate? The sender name is already known at the time of the switch > configuration message. If not, are the sender name in the adjacency mesage > bound by the same type restriction that it should have the 24 most > significant bits set to an OUI? And is it possible to think that atleast > in most cases they are hte same. translated to mib terms this could mean > that we take away the switch name object (if the two are the same) or > atleast set the default of the switch name object to the value of VseId. > > Also, I propose to take out the VsceName which I belive was a > misunderstanding from my part because of a writing error in the gsmp spec; > > I belive that the text "The Switch Configuration message has the following > format" on page 83 should be "The Switch Configuration success response > message has the following format". > > Regards > /// Hasse > > > > > > > > > From owner-gsmp@psyton.com Wed Aug 9 15:11:14 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16818 for ; Wed, 9 Aug 2000 15:11:14 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA31812 for gsmp-list; Wed, 9 Aug 2000 14:58:29 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id OAA31809 for ; Wed, 9 Aug 2000 14:58:28 -0400 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Wed, 9 Aug 2000 13:50:41 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QHJP0GGL; Wed, 9 Aug 2000 11:50:19 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.190]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QG9ZG347; Wed, 9 Aug 2000 14:49:29 -0400 Message-ID: <3991A7BE.C58814E3@nortelnetworks.com> Date: Wed, 09 Aug 2000 14:49:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: names in gsmp spec and mib References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, As the list moderator, I get all rejected mailings becasue when they are from non-list members. Those that aren't SPAM, I pass on within a day. I assumed that this extra activity on my part made the list a little easier for the participants of the list. I have NEVER excluded a non SPAM message from the list. I apologize for doing this in a manual manner, and I hope that it is fine. If it is not, I will stop being a filter for SPAM becasue I don't have another method readily at my disposal. Thanks a. David Oran wrote: > > What, precisely, do you mean by "closing the list"? If it means that > postings from non-members are diverted to the moderator for screening, > that's fine. If it means rejecting posts explicitly with a note to send to > the moderator to request posting to the list, that's less fine but probably > ok. > > If it means simply rejecting messages with no instructions on how to get it > posted, or even worse silently dropping it on the floor, that is NOT fine > and does not meet the open-ness criteria for IETF WG email lists. > > Dave. > > > -----Original Message----- > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > > ad > > Sent: Tuesday, August 08, 2000 5:27 PM > > To: gsmp@psyton.com > > Subject: names in gsmp spec and mib > > > > > > Hi, > > > > This message has been bouncing becuase Hasse is sumitting it from an > > address that is not subscribed to the list. To prevent spam, I have > > closed the list to non-member submissions. Apologies for the > > inconvenience. > > > > a. > > > > ps. response later. > > > > ---------- Forwarded message ---------- > > Subject: names in gsmp spec and mib > > Date: Tue, 8 Aug 2000 22:02:47 +0200 > > From: Hans Sjostrand > > > > Hi, > > > > I have a question about names, which kind of goes back to the mib. > > > > Is the switch name in the switch configuration message the same as the > > sender name in the adjacency message? In that case, why is it sent in > > duplicate? The sender name is already known at the time of the switch > > configuration message. If not, are the sender name in the adjacency mesage > > bound by the same type restriction that it should have the 24 most > > significant bits set to an OUI? And is it possible to think that atleast > > in most cases they are hte same. translated to mib terms this could mean > > that we take away the switch name object (if the two are the same) or > > atleast set the default of the switch name object to the value of VseId. > > > > Also, I propose to take out the VsceName which I belive was a > > misunderstanding from my part because of a writing error in the gsmp spec; > > > > I belive that the text "The Switch Configuration message has the following > > format" on page 83 should be "The Switch Configuration success response > > message has the following format". > > > > Regards > > /// Hasse > > > > > > > > > > > > > > > > > > -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Wed Aug 9 17:08:16 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20464 for ; Wed, 9 Aug 2000 17:08:16 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA32222 for gsmp-list; Wed, 9 Aug 2000 16:57:41 -0400 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id QAA32219 for ; Wed, 9 Aug 2000 16:57:41 -0400 Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id NAA18754 for ; Wed, 9 Aug 2000 13:57:07 -0700 (PDT) From: "David Oran" To: Subject: RE: names in gsmp spec and mib Date: Wed, 9 Aug 2000 16:57:06 -0400 Keywords: IETF Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3991A7BE.C58814E3@nortelnetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Manual screening by the moderator is quite acceptible IETF open-ness practice. I raised the issue because the original message implied the list was "closed to non-members" which is not the case here. I am sensitive to this becuase I myself got blackholed recently by a list which just discarded messages from non-members without even a reject, let alone a divert to the moderator. (Don't ask which - it's being fixed). Thanks for the clarification. Dave. > -----Original Message----- > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Avri Doria > Sent: Wednesday, August 09, 2000 2:50 PM > To: gsmp@psyton.com > Subject: Re: names in gsmp spec and mib > > > Hi, > > As the list moderator, I get all rejected mailings becasue when they are > from non-list members. Those that aren't SPAM, I pass on within a day. > I assumed that this extra activity on my part made the list a little > easier > for the participants of the list. I have NEVER excluded a non SPAM > message from the list. > > I apologize for doing this in a manual manner, and I hope that it is > fine. > If it is not, I will stop being a filter for SPAM becasue I don't have > another method readily at my disposal. > > Thanks > a. > > David Oran wrote: > > > > What, precisely, do you mean by "closing the list"? If it means that > > postings from non-members are diverted to the moderator for screening, > > that's fine. If it means rejecting posts explicitly with a note > to send to > > the moderator to request posting to the list, that's less fine > but probably > > ok. > > > > If it means simply rejecting messages with no instructions on > how to get it > > posted, or even worse silently dropping it on the floor, that > is NOT fine > > and does not meet the open-ness criteria for IETF WG email lists. > > > > Dave. > > > > > -----Original Message----- > > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > > > ad > > > Sent: Tuesday, August 08, 2000 5:27 PM > > > To: gsmp@psyton.com > > > Subject: names in gsmp spec and mib > > > > > > > > > Hi, > > > > > > This message has been bouncing becuase Hasse is sumitting it from an > > > address that is not subscribed to the list. To prevent spam, I have > > > closed the list to non-member submissions. Apologies for the > > > inconvenience. > > > > > > a. > > > > > > ps. response later. > > > > > > ---------- Forwarded message ---------- > > > Subject: names in gsmp spec and mib > > > Date: Tue, 8 Aug 2000 22:02:47 +0200 > > > From: Hans Sjostrand > > > > > > Hi, > > > > > > I have a question about names, which kind of goes back to the mib. > > > > > > Is the switch name in the switch configuration message the same as the > > > sender name in the adjacency message? In that case, why is it sent in > > > duplicate? The sender name is already known at the time of the switch > > > configuration message. If not, are the sender name in the > adjacency mesage > > > bound by the same type restriction that it should have the 24 most > > > significant bits set to an OUI? And is it possible to think > that atleast > > > in most cases they are hte same. translated to mib terms this > could mean > > > that we take away the switch name object (if the two are the same) or > > > atleast set the default of the switch name object to the > value of VseId. > > > > > > Also, I propose to take out the VsceName which I belive was a > > > misunderstanding from my part because of a writing error in > the gsmp spec; > > > > > > I belive that the text "The Switch Configuration message has > the following > > > format" on page 83 should be "The Switch Configuration > success response > > > message has the following format". > > > > > > Regards > > > /// Hasse > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Avri Doria > +1 401 663 5024 > > From owner-gsmp@psyton.com Thu Aug 10 01:09:42 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29981 for ; Thu, 10 Aug 2000 01:09:40 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id AAA00938 for gsmp-list; Thu, 10 Aug 2000 00:54:26 -0400 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id AAA00935 for ; Thu, 10 Aug 2000 00:54:24 -0400 Received: from fwd01.sul.t-online.com by mailout06.sul.t-online.com with smtp id 13MkMI-0001ae-00; Thu, 10 Aug 2000 06:54:22 +0200 Received: from t-online.de (06103921725-0001@[62.155.177.141]) by fwd01.sul.t-online.com with esmtp id 13MkM9-0eXc3sC; Thu, 10 Aug 2000 06:54:13 +0200 Message-ID: <39924355.CD4FF294@t-online.de> Date: Thu, 10 Aug 2000 06:53:25 +0100 From: Joachim.Buerkle@t-online.de (Joachim Buerkle) X-Mailer: Mozilla 4.51 [de]C-CCK-MCD DT (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: names in gsmp spec and mib References: <3991A7BE.C58814E3@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 06103921725-0001@t-dialin.net Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, as a active participant on the list and in the IETF WG meetings since the WG was founded I want to thank you Avri for preventing us from SPAM. I also NEVER heard that somebody (IETF meeting participants, P1520, MSF, ...) has problems with this way. I really prefer it in this way, since there is already enough SPAM on the IETF Mailinglists. I think that the FTPEXT-WG (ftp-wg@hethmon.com) has the list with most SPAM (its really the worse). Joachim - - - - - - - - - - - - - - - - - - - - - - - - - - - Avri Doria schrieb: > Hi, > > As the list moderator, I get all rejected mailings becasue when they are > from non-list members. Those that aren't SPAM, I pass on within a day. > I assumed that this extra activity on my part made the list a little > easier > for the participants of the list. I have NEVER excluded a non SPAM > message from the list. > > I apologize for doing this in a manual manner, and I hope that it is > fine. > If it is not, I will stop being a filter for SPAM becasue I don't have > another method readily at my disposal. > > Thanks > a. > > David Oran wrote: > > > > What, precisely, do you mean by "closing the list"? If it means that > > postings from non-members are diverted to the moderator for screening, > > that's fine. If it means rejecting posts explicitly with a note to send to > > the moderator to request posting to the list, that's less fine but probably > > ok. > > > > If it means simply rejecting messages with no instructions on how to get it > > posted, or even worse silently dropping it on the floor, that is NOT fine > > and does not meet the open-ness criteria for IETF WG email lists. > > > > Dave. > > > > > -----Original Message----- > > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > > > ad > > > Sent: Tuesday, August 08, 2000 5:27 PM > > > To: gsmp@psyton.com > > > Subject: names in gsmp spec and mib > > > > > > > > > Hi, > > > > > > This message has been bouncing becuase Hasse is sumitting it from an > > > address that is not subscribed to the list. To prevent spam, I have > > > closed the list to non-member submissions. Apologies for the > > > inconvenience. > > > > > > a. > > > > > > ps. response later. > > > > > > ---------- Forwarded message ---------- > > > Subject: names in gsmp spec and mib > > > Date: Tue, 8 Aug 2000 22:02:47 +0200 > > > From: Hans Sjostrand > > > > > > Hi, > > > > > > I have a question about names, which kind of goes back to the mib. > > > > > > Is the switch name in the switch configuration message the same as the > > > sender name in the adjacency message? In that case, why is it sent in > > > duplicate? The sender name is already known at the time of the switch > > > configuration message. If not, are the sender name in the adjacency mesage > > > bound by the same type restriction that it should have the 24 most > > > significant bits set to an OUI? And is it possible to think that atleast > > > in most cases they are hte same. translated to mib terms this could mean > > > that we take away the switch name object (if the two are the same) or > > > atleast set the default of the switch name object to the value of VseId. > > > > > > Also, I propose to take out the VsceName which I belive was a > > > misunderstanding from my part because of a writing error in the gsmp spec; > > > > > > I belive that the text "The Switch Configuration message has the following > > > format" on page 83 should be "The Switch Configuration success response > > > message has the following format". > > > > > > Regards > > > /// Hasse > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Avri Doria > +1 401 663 5024 From owner-gsmp@psyton.com Thu Aug 10 08:45:16 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18748 for ; Thu, 10 Aug 2000 08:45:15 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id IAA02015 for gsmp-list; Thu, 10 Aug 2000 08:33:59 -0400 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id IAA02012 for ; Thu, 10 Aug 2000 08:33:57 -0400 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7ACXuw18846 for ; Thu, 10 Aug 2000 14:33:56 +0200 (MEST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FZ200101TKIXB@mbb1.ericsson.se> for gsmp@psyton.com; Thu, 10 Aug 2000 14:33:55 +0200 (MET DST) Received: from etx.ericsson.se (avc073.etxb.ericsson.se [130.100.180.231]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FZ200COBTKIYN@mbb1.ericsson.se> for gsmp@psyton.com; Thu, 10 Aug 2000 14:33:54 +0200 (MET DST) Date: Thu, 10 Aug 2000 14:33:54 +0200 From: Hans =?iso-8859-1?Q?Sj=F6strand?= Subject: Re: names in gsmp spec and mib (really) To: gsmp@psyton.com Message-id: <3992A131.C84E5823@etx.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <399140A3.EBDEE753@nortelnetworks.com> Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit So, the spec is kind of untouched but the mib will have some small changes due to this - The gsmpVsceName object in the gsmpVsceTable will be removed. - The gsmpVseName object in gsmpVseTable I propose to retain. I would think that it's most often the same so I'll define the default value to be set to the same as the ID if it's not separatle specified. Or is it redundant altogether and should be removed? They'll be regarded as last call comments. Regards /// Hasse ps. I do think it's ok to manually filter non member messages but it would be nice to have a autoreply indicating that fact if it's not to much of a trouble. ds. Avri Doria wrote: > > > ---------- Forwarded message ---------- > > Subject: names in gsmp spec and mib > > Date: Tue, 8 Aug 2000 22:02:47 +0200 > > From: Hans Sjostrand > > > > Hi, > > > > I have a question about names, which kind of goes back to the mib. > > > > Is the switch name in the switch configuration message the same as the > > sender name in the adjacency message? > > Yes I think they are the same in the case of the switch entity. The > VSCE > uses its name when it is the sender. > > > In that case, why is it sent in > > duplicate? The sender name is already known at the time of the switch > > configuration message. > > It is needed in the adjacency message to identify the two entities > involved in the adjacency. It the switch configuration it might be > redundant, but given the funtion of the Switch Configuration message, > the redundnacy is probably warranted. > > > If not, are the sender name in the adjacency mesage > > bound by the same type restriction that it should have the 24 most > > significant bits set to an OUI? > > This is a historical restriction. I am not sure that it is is > absolutely > necessary, but it strongly advised. The wording between the two should > probably be clarified and made consistent. > > > And is it possible to think that atleast > > in most cases they are hte same. translated to mib terms this could mean > > that we take away the switch name object (if the two are the same) or > > atleast set the default of the switch name object to the value of VseId. > > > > Also, I propose to take out the VsceName which I belive was a > > misunderstanding from my part because of a writing error in the gsmp spec; > > Seems reasonable to me. I can't think of a reason for including both > the > VsceId and VsceName. > > > > > I belive that the text "The Switch Configuration message has the following > > format" on page 83 should be "The Switch Configuration success response > > message has the following format". > > > > I don't think so. This is one of the artifacts of GSMP - identical > request/response messages. > > Regards, > a. > > -- > > Avri Doria > +1 401 663 5024 From owner-gsmp@psyton.com Wed Aug 16 06:48:23 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21508 for ; Wed, 16 Aug 2000 06:48:23 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id GAA22476 for gsmp-list; Wed, 16 Aug 2000 06:20:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id GAA22473 for ; Wed, 16 Aug 2000 06:20:16 -0400 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7GAK9w12239 for ; Wed, 16 Aug 2000 12:20:10 +0200 (MEST) Received: from esealnt409 ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 16 Aug 2000 12:19:38 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt409 (NAVIEG 2.1 bld 61) with SMTP id M2000081612193820614 ; Wed, 16 Aug 2000 12:19:38 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 16 Aug 2000 11:50:20 +0200 Message-ID: <21A2BDF7A29CD3118B000008C75D087302703E44@esealnt127> From: =?iso-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?= To: "'gsmp@psyton.com'" Subject: small last comments on GSMP spec Date: Wed, 16 Aug 2000 11:50:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Aug 2000 10:19:38.0703 (UTC) FILETIME=[7BD81DF0:01C0076B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nighthawk.psyton.com id GAA22474 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Hi, Here's some small comments (kind of editorial) that I come across while reading the GSMP spec. * 17-bit DLCIs are no longer supported by the Frame Relay Forum. All MPLS documentation has been changed and I propose to change GSMP aswell. It goes into section 3.1.3.1.2 , 6.2.1.2 and 8.2.1.2 Len This field specifies the number of bits of the DLCI. The following values are supported: Len DLCI bits 0 10 2 23 Len values 1 and 3 are reserved for future use. * ref [5] is outdated by http://www.isi.edu/in-notes/iana/assignments/address-family-numbers Should be used instead I think. * pdftotext sometimes misinterprets - for ¡ Don't ask me why, but do a search repace on those. From owner-gsmp@psyton.com Wed Aug 16 08:15:12 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23070 for ; Wed, 16 Aug 2000 08:15:12 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id HAA22755 for gsmp-list; Wed, 16 Aug 2000 07:58:15 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id HAA22752 for ; Wed, 16 Aug 2000 07:58:14 -0400 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Wed, 16 Aug 2000 06:58:34 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QY5NCB0V; Wed, 16 Aug 2000 04:57:57 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.127]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QY5XWK1P; Wed, 16 Aug 2000 07:57:05 -0400 Message-ID: <399A8195.A7000186@nortelnetworks.com> Date: Wed, 16 Aug 2000 07:57:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: small last comments on GSMP spec References: <21A2BDF7A29CD3118B000008C75D087302703E44@esealnt127> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Hi, Thanks for these comments. a. Hans Sjöstrand (ETX) wrote: > > Hi, > > Here's some small comments (kind of editorial) that I come across while reading the GSMP spec. > > * 17-bit DLCIs are no longer supported by the Frame Relay Forum. All MPLS documentation has been changed and I propose to change GSMP aswell. It goes into section 3.1.3.1.2 , 6.2.1.2 and 8.2.1.2 > > Len > This field specifies the number of bits of the DLCI. The following > values are supported: > > Len DLCI bits > > 0 10 > 2 23 > > Len values 1 and 3 are reserved for future use. > > * ref [5] is outdated by http://www.isi.edu/in-notes/iana/assignments/address-family-numbers Should be used instead I think. > > * pdftotext sometimes misinterprets - for ¡ Don't ask me why, but do a search repace on those. -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Thu Aug 17 04:04:32 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22222 for ; Thu, 17 Aug 2000 04:04:32 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id DAA26542 for gsmp-list; Thu, 17 Aug 2000 03:50:30 -0400 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id DAA26539 for ; Thu, 17 Aug 2000 03:50:28 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7H7oRw26255 for ; Thu, 17 Aug 2000 09:50:27 +0200 (MEST) Received: from esealnt406.al.sw.ericsson.se ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2195.1600); Thu, 17 Aug 2000 09:50:26 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt406.al.sw.ericsson.se (NAVIEG 2.1 bld 61) with SMTP id M2000081709502620138 for ; Thu, 17 Aug 2000 09:50:26 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 17 Aug 2000 09:50:26 +0200 Message-ID: <21A2BDF7A29CD3118B000008C75D087302703E48@esealnt127> From: =?iso-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?= To: "'GSMP list '" Subject: draft IETF48 GSMP WG minutes Date: Thu, 17 Aug 2000 09:50:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Aug 2000 07:50:26.0816 (UTC) FILETIME=[CE845000:01C0081F] Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com below is the draft WG minutes from Pittsburg. Regards /// Hasse ---- The GSMP working group held a meeting at IETF48. The meeting was chaired by Kenneth Sundell, and notes were taken by Hans Sjostrand and by Avri Doria. There were 2 main areas of discussion and 2 technical I-Ds presented. -Last Call documents: Last call was initiated on 21 July and is scheduled to terminate on 18 August. The reason the last call was made longer then the required 2 weeks was to accomodate folks attending the IETF who did not have time to review the material. Additionally the MSF is doing its 'WG last call' equivalent on the same documents at the moment. Their review is also slated to end on 18 August. After that the documents will be recycled to handle all the editorial issues, and if there are no new substantive issues, will be passed along to the IESG for the continuing process. If there are technical issues, the affected docs will go through another WG last call. All 4 documents will be passed on as a set. Avri Doria did a review of: draft-ietf-gsmp-06.txt There were two substantive changes made between -05 and -6. The first was the additon of the replace flag in the add branch command. This flag was added to accomodate some traditional telephony switching systems. The second change was the removal of Diff Serv support from the service model chapter. This was removed becasue there were no suggestion on how this would be used. Support for Diff Serv service model can be added to GSMP at a latter time in a separate document. draft-ietf-gsmp-encaps-02.txt Changes between -01 and -02 were all editorial in nature. draft-ietf-gsmp-applicability-01.txt Changes between -00 and -01 were all editorial in nature. Hans Sjostrand did a review of draft-ietf-gsmp-mib-02.txt Quite a few changes were made between -01 and 02. These consisted primarily of: a new structure where VSCE, VSE and session data was separated, encap got theis own MIB groups and 10 notifications were added. The new object structure was presented to the WG. There is a problem with notification object as described in the draft. The proposed solution is to add extra notification objects. No comments from the floor on this issue. There where some last call comments, from people that had experience with getting mibs through IESG. Ipv4 specific stuff has to be generalized to support Ipv6 and storage type has to be clarified. The mib will be updated with the last call comments in a -03 version which will be out in a few weeks time. During the discussion, Hans noted that the GSMP archive is not fully working, i.e. it's not possible to retrieve the August file. Avri promised to check up on that. - New charter discussion. Avri presented a proposal, which has been sent out to the list. With the submission of the current WG docs to the IESG the WG milestones will be met. There are two alternatives: - The group goes dormant until it is either shut down or awakened due to operational experience. - The Charter is updated. The discuyssion for the re-charter included: -- Support for Optical switches. This was discussed in the group and there is very strong interest in seeing it done. The primary argument for doing the work concerned the fact that some optical switch vendors are putting so much focus into the optical layer that they don't really have the resources necessary to add the IP superstructure into their products. It may also not be apprpriate to do so in all cases. Using GSMP to do this seems reasonable. Avri mentioned that she had spoken to Jim Luciani (one of the co-chairs of the proposed IPO group) about this and indicated that he is agreement with the GSMP WG taking on this work. Statement from the floor; GSMP is today only of interest for the vendors who doing both HW and SW, the small optical startups have no clue of SW, so it should be boosted by them. Avri responded that the carriers are also picking up some interest and that GSMP is used within MSF which architecture corresponds to GSMPs. But that she agreed that this should be of interst to Optical vendors. -- Support for Switch Partitioning There has been a call from some service providers and vendors for GSMP to support switch partitioning. This could be done either within the GSMP protocol or a-priori by a MIB or PIB. In either case to make switch partitioning dynamic would require GSMP support. It was mentioned that if this task is approved as a GSMP work item it will require cooperation with the VPN BoF/WG to understand the requirements. Question from the floor: There was a proposal to use PIBS which are carried by COPS for partioning. It was therefore unclear which protocol the group wanted to use? David Putxolu responded that the authors wanted to raise the interest for the area, we made a pib. This could be adjusted. Hans commented that the switch partition work item has the character of bottom-up work, and that the GSMP wg should focus on the GSMP and related issues, and avoid become an architectural group to deal with all issues of switch - controller separation. Avri responded that this was true and that the architectural issues would need to be resolved with the cooperation of other groups working on issues of VPN control. Avri also mentioned that the MSF was interested in the problem of switch partitioning and could be counted on to request changes to GSMP to support switch partitioning. -- Support for IP forwarding devices There is a proposal to add suppurt for IP forwarding devices. MSF is adding IP support in their next version, and HW implementations are going to become available. In his presentation David Putzolu argued that this work is best suited for IETF Routing area and that the specific expertise needed currently existed in the GSMP WG. --Other work items In additon to the items mentioned above that were part of the formal proposal, several items were suggested by wg members. These consisted of suggestions for other switch support, e.g. SDH/Sonet. These will be added to the re-charter application since there was concensus on doing this. Some discussion will occur on the list to develop the list of device types that should be supported. There was one comment from the floor that the group should focus on support for Optical Switching alone since this was the biggest opportunity for deployment of GSMP. This was generally not supported, especially by those who suggested that GSMP be extended to support other switch types. --Milestones Avri presented some proposed milestones, - Document requirements for switch partitioning - Document requirements for optical switching - Document requirements for IP packet switches - Produce extensions, MIBs and PIBs consitent with the requirements - Update base gsmpv3 due to implementation experience Avri asked if there was consensus in the group with proceeding on all the proposed areas. Handraising and humming indicated approval for proceeding on all, with no opposition indicated. A new charter will be created and posted to the list. First draft on requirement will be introduced into next IETF. The group agreed on that six month for requirements and a year for the extensions were reasonable targets. Operational implementation is coming in due time. Avri also asked for information about the different implementations. If this information was not confidential it should be posted to the list, otherwise, if it was confidential it could be privately posted to the chairs. This would then be relayed to the IESG, which could be expected to maintain the confidentiality. -I-Ds Presented Two PIBS were presented; one on switch partitioning and one on IP forwarding. There was some discussion on accepting them as WG work items, but this was put off pending the approval of a new charter. IP Forwarding PIB < draft-khosravi-ip-fwd-pib-00.txt> - Hormuzd Khosravi The purpose of the presentation was not to go into the discussion of mibs and pibs, but to guage the interest in GSMP WG. The motivation is offloading the routing protocol computation e.g. on a network processor. Also, MSF will require support for IP. COPS may be useful. The pibs fits well with the gsmp framework. The actual model is based on the IP forwarding table rfc2096. But stripped to only contain the parts necessary to configure the device to do the forwarding decision. Open issues are IPv6, Multicast and multipath forwarding. Proposal to accept this as a WG item. Avri responded that even if the group is supportive to the idea, it can't be made a WG item before the recharter. Multiple Virtual Router Partitioning Policy Information Base - Todd Andersen The work is derived and is largely based on a MSF mib written by the co-authors. The motivation is that MSF is adopting GSMP as reference point, but standard mechanisms to define virtual switches do not exist but are required. NBVPN uses MVR. It was reiterated that the transport mechanism is not important, it's the data model itself that was the focus of the work. Partitioned resources is bandwidth, buffer space, label space, routing table space, IP addresses. Open issues are: Virtual ports between the VRs. It's also an open issue whether this work should be done in GSMP WG or the potential NBVPN WG. Avri responded that it is most likely well suited as joint work. There being no more comments or issues, the meeting adjourned by Kenneth. From owner-gsmp@psyton.com Fri Aug 18 02:29:41 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24102 for ; Fri, 18 Aug 2000 02:29:41 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id CAA29955 for gsmp-list; Fri, 18 Aug 2000 02:15:15 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id CAA29952 for ; Fri, 18 Aug 2000 02:15:11 -0400 Received: (qmail 8161 invoked from network); 18 Aug 2000 04:55:12 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 18 Aug 2000 04:55:12 -0000 Received: (qmail 11878 invoked from network); 18 Aug 2000 06:14:55 -0000 Received: from unknown (HELO cplane.com) (unknown) by unknown with SMTP; 18 Aug 2000 06:14:55 -0000 Message-ID: <399CD3B4.53B09EA3@cplane.com> Date: Thu, 17 Aug 2000 23:12:05 -0700 From: Jaroslaw Sydir Organization: CPlane Inc. X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: gsmp@psyton.com Subject: Last Minute Last Call Comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit These comments apply to the GSMP spec. Editorial comments: 1) In section 3.1.1 in the description of Result, the word "State" is spelled "Sate" 2) In section 4.1 in the description of the O flag, the description should read "The opaque flag indicates whether the adaptation FIELD is opaque..." 3) In section 6.1 in the description of the Reset Input Port field, the statement "All connections that arrive at the specified input port" is misleading in that "arrive" implies dynamic behavior that is not intended. It would read better if the word "arrive" was replaced with "originate". 4) In section 7.1 in the description of the TC Block Length the word "field" is mistyped (it is "filed" in the text). 5) In section 7.3 the line "x: Unused" can probably be deleted. 6) In section 8.1 in the description of MType in the list of mtypes, the first two line have funky characters instead of dashes. Technical Comment: The response to the Statistics Messages include cell count fields which are specific to ATM. This breaks with the rest of the document where technology specific field are identified as such. Is it the case that for a non ATM port these fields are not used? If so this should be stated in the document. From owner-gsmp@psyton.com Fri Aug 18 03:01:49 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24477 for ; Fri, 18 Aug 2000 03:01:48 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id CAA30115 for gsmp-list; Fri, 18 Aug 2000 02:53:35 -0400 Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id CAA30112 for ; Fri, 18 Aug 2000 02:53:33 -0400 Received: from zhard00d.europe.nortel.com (actually zhard00d) by qhars002.nortel.com; Fri, 18 Aug 2000 07:52:47 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00d.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Q8VVMNM6; Fri, 18 Aug 2000 07:52:48 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.199]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Q83PAZL0; Fri, 18 Aug 2000 08:52:46 +0200 Message-ID: <399CDD7B.B701409D@europem01.nt.com> Date: Fri, 18 Aug 2000 08:53:47 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Kenneth Sundell" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: Last Minute Last Call Comments References: <399CD3B4.53B09EA3@cplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi Jerry, thanks for your input. the authors will get together and reply to your comments shortly. regards, ken Jaroslaw Sydir wrote: > These comments apply to the GSMP spec. > > Editorial comments: > > 1) In section 3.1.1 in the description of Result, the word "State" is > spelled "Sate" > > 2) In section 4.1 in the description of the O flag, the description > should read "The opaque flag indicates whether the adaptation FIELD is > opaque..." > > 3) In section 6.1 in the description of the Reset Input Port field, the > statement "All connections that arrive at the specified input port" is > misleading in that "arrive" implies dynamic behavior that is not > intended. It would read better if the word "arrive" was replaced with > "originate". > > 4) In section 7.1 in the description of the TC Block Length the word > "field" is mistyped (it is "filed" in the text). > > 5) In section 7.3 the line "x: Unused" can probably be deleted. > > 6) In section 8.1 in the description of MType in the list of mtypes, the > first two line have funky characters instead of dashes. > > Technical Comment: The response to the Statistics Messages include cell > count fields which are specific to ATM. This breaks with the rest of the > document where technology specific field are identified as such. Is it > the case that for a non ATM port these fields are not used? If so this > should be stated in the document. -- Kenneth Sundell Routing Architecture Lab, Nortel Networks Sweden phone: +46 8 5088-3538, mobile +46 70 665-7838 From owner-gsmp@psyton.com Fri Aug 18 16:42:07 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07338 for ; Fri, 18 Aug 2000 16:42:06 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id QAA32612 for gsmp-list; Fri, 18 Aug 2000 16:24:50 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id QAA32609 for ; Fri, 18 Aug 2000 16:24:48 -0400 Received: (qmail 11210 invoked from network); 18 Aug 2000 19:04:59 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 18 Aug 2000 19:04:59 -0000 Received: (qmail 17044 invoked from network); 18 Aug 2000 20:24:44 -0000 Received: from unknown (HELO cplane.com) (unknown) by unknown with SMTP; 18 Aug 2000 20:24:44 -0000 Message-ID: <399D9B8C.DCD7BC77@cplane.com> Date: Fri, 18 Aug 2000 13:24:44 -0700 From: Jaroslaw Sydir Organization: CPlane Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: One last last call comment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit I have a comment concerning document organization of the GSMP spec. The GSMP document combines the definitions of the generic and technology-dependent parts of the protocol. Besides making the spec very large, this means that either, the spec gets revised every time that GSMP is applied to a new technology, or that some technologies are dealt with in the main spec and some are dealt with in addendums. This would probably be more manageable if the spec dealt only with the generic parts and there were separate documents for each of the technologies. This is basically an editorial change, albeit a big one. Jerry Sydir From owner-gsmp@psyton.com Fri Aug 18 17:25:21 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08804 for ; Fri, 18 Aug 2000 17:25:21 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id RAA00410 for gsmp-list; Fri, 18 Aug 2000 17:14:40 -0400 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id RAA00404 for ; Fri, 18 Aug 2000 17:14:38 -0400 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id VAA27997 for ; Fri, 18 Aug 2000 21:15:30 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 18 Aug 2000 21:14:31 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Aug 2000 14:14:30 -0700 Message-ID: From: "Khosravi, Hormuzd M" To: "'gsmp@psyton.com'" Subject: RE: One last last call comment Date: Fri, 18 Aug 2000 14:14:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com I had a very similar comment on the GSMP spec. I was wondering if the Service Model Definition could be part of a separate draft instead of the GSMP spec. This would help reducing the size of the GSMP spec and make it easy to extend the Service Model at a later time. Regards, Hormuzd. -----Original Message----- From: Jaroslaw Sydir [mailto:sydir@cplane.com] Sent: Friday, August 18, 2000 1:25 PM To: gsmp@psyton.com Subject: One last last call comment I have a comment concerning document organization of the GSMP spec. The GSMP document combines the definitions of the generic and technology-dependent parts of the protocol. Besides making the spec very large, this means that either, the spec gets revised every time that GSMP is applied to a new technology, or that some technologies are dealt with in the main spec and some are dealt with in addendums. This would probably be more manageable if the spec dealt only with the generic parts and there were separate documents for each of the technologies. This is basically an editorial change, albeit a big one. Jerry Sydir From owner-gsmp@psyton.com Fri Aug 18 18:06:27 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09384 for ; Fri, 18 Aug 2000 18:06:27 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id RAA00639 for gsmp-list; Fri, 18 Aug 2000 17:57:10 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id RAA00636 for ; Fri, 18 Aug 2000 17:57:09 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Fri, 18 Aug 2000 17:53:04 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RDYRRR7K; Fri, 18 Aug 2000 14:53:02 -0700 Received: from nortelnetworks.com (archt10kj.us.nortel.com [47.102.155.191]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QY5XW3WG; Fri, 18 Aug 2000 17:52:10 -0400 Message-ID: <399DB021.57692FBA@nortelnetworks.com> Date: Fri, 18 Aug 2000 17:52:33 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: One last last call comment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, I too have been somewhat troubled by the size and complexity of the specification and will definately look at trying to separate it into smaller, more focused drafts. As Jerry says this is largely an editorial exercise, but such an extensive one that it would demand (in my opinion) a renewed WG last call. It will also take several weeks to get done because it is a huge task. On the service model issue. Some of the service model is generic, and I would be inclined to leave it in the general spec. And part of the model pertains to specific technologies and probably belongs in the protocol domain sp;ecific docs, i.e. ATM service models with ATM info, FR service models with FR models. I think that putting them all into a service models draft would have the same update risk as the full specification currently has. Before actually embarking on this task, I would like to hear some more feedback from the WG. Incidentally, making this change would also require significant changes to the applicability draft and therefore this would probably also be submitted to a renewed last call. a. "Khosravi, Hormuzd M" wrote: > > I had a very similar comment on the GSMP spec. I was wondering if > the Service Model Definition could be part of a separate draft > instead of the GSMP spec. This would help reducing the size of > the GSMP spec and make it easy to extend the Service Model at a > later time. > > Regards, > Hormuzd. > > -----Original Message----- > From: Jaroslaw Sydir [mailto:sydir@cplane.com] > Sent: Friday, August 18, 2000 1:25 PM > To: gsmp@psyton.com > Subject: One last last call comment > > I have a comment concerning document organization of the GSMP spec. The > GSMP document > combines the definitions of the generic and technology-dependent parts > of the > protocol. Besides making the spec very large, this means that either, > the spec gets revised every time that GSMP is applied to a new > technology, or that some technologies are dealt with in the main spec > and some are dealt with in addendums. This would probably be more > manageable if the > spec dealt only with the generic parts and there were separate documents > for each of the technologies. This is basically an editorial change, > albeit a big > one. > > Jerry Sydir -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Fri Aug 18 18:45:16 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09796 for ; Fri, 18 Aug 2000 18:45:16 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id SAA00841 for gsmp-list; Fri, 18 Aug 2000 18:37:16 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id SAA00838 for ; Fri, 18 Aug 2000 18:37:15 -0400 Received: (qmail 1867 invoked from network); 18 Aug 2000 21:32:57 -0000 Received: from unknown (HELO tworster) (192.168.64.102) by d83b22c8.dsl.flashcom.net with SMTP; 18 Aug 2000 21:32:57 -0000 From: "tom worster" To: Subject: last call comments Date: Fri, 18 Aug 2000 18:38:07 -0400 Message-ID: <001801c00964$fb9bb880$6640a8c0@thefsb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit "and now the votes from the scottish jury. norway -- nul points..." c u fsb gsmp spec: general: the "specification langue" is incosistent. e.g. sometimes "must" is upper case, sometimes not and sometimes "shall" is used. i suggest including the standard paragraph defining the meanings of must and should etc. and using these terms consistently. (m$ w0rd's "search and replace" should make this job fairly easy) pg6pa7: external -> externally? pg12: under "Length" text is a little imprecise. suggest: "Length of the GSMP message including its header fields." pg13pa1: TLV abbreviation not explained. pg14: under "frame relay labels," fields "Res" and "x" are not explained. suggest moving 3.1.3.4 to the top of this section. also in the spec both "unused" and "reserved" are used. what is the difference. perhaps its better to use only one version. and since "x" and "reserved" are defined here we can remove the subsequent definitions of fields marked thus throught the spec. pg15: tlv labels for atm, fr and mpls. i don't think it makes sense to support two different encodings for these labels. this poses a complexity burden on the spec and on implementations and doesn't seem to have any associated benefit. if there is a need for two different encodings then it is not apparent. as far as i can see, none of the label types supported have variable length value (i.e. the v in tlv) fields so is seems unnecessary to distinguish between short and tlv labels. and since the length field is redundant, a uniform label encoding using type discriminators would appear to suffice. so i think we should go for: 1) only tlv labels, or 2) a uniform encoding without a length field, or 3) drop the tlv versions of atm, fr and mpls. pg16: under Label Length suggest: "A 16 bit field indicating the length of the Lavel Value field in bytes." ... after that the Label Value field should be described, e.g. " Label Value (new para) A variable length field that is an integer number of 32 bit words long. The value field is interpreted according to the Label Type as described in the following sections." pg17: there is an unspecified field to the left of Res under fr labels. sould also be Res? pg17: there is an unspecified field to the left of MPLS label under mpls labels. should be Res? pg17: fec labels. is it intended to only support one fec element per connection? if so then the mpls support is severly limited. pg18 and throughout the spec: the ds3/e3/... labels are inadequately defined. it is completely unclear to me what a channel id is and i cannot understand how the time slots field is encoded. it seems that reference must be made to the sandards that specify the multiplex structure of these signals and the semantics of the fields specified in the gsmp be related unambiguously to those standards. also, since we are doing channelised ds1, ds3 etc it seems only reasonable to also do channelised sts3 and stm1. the deployment of channelised sts3 and stm1 in access networks is very is widespread and increasing rapidly. pg19: under Time Slots (and in equivalent places below) the reference to padding is superfluous if my above suggestion for "Label Value" is used. p22sec3.1.3.4: move to (near) the top of chapter 3. p25 last para (and throughout the spec): the "IQS/OQS=" terminology is unclear. does the / mean AND or OR or DIVIDE? if it's AND then i suggest "IQS=x and OQS=x" etc. p26: under IQS, OQS, 1st para, last sentence: suggest "The values of IQS and OQS determine respectively the interpretation of the Input Service Selector and Output Service Selector fields as shown:" the word Model in the first row of the table appears to be in the wrong column. under B Flag there is a cross reference missing. p27: the definiton of O Flag is inadequate: i can't figure it out from this text. space before and after the fields picture. p32: 2nd para: "clashing output branch"? elsewhere we use different text for what i think this is intended to mean. (if the label is alread...) 3rd para: what are "64k call handling applications"? 4th para: "it is an error to use" is not standard specification language. suggest "the R flag must not be set if..." 5th para 1st sentence: suggest "the R flag must not be set if either the M flag or the B flag is set." p33 4th para: 2nd sentence: "There will..." should this be "may"? also suggest replacing "any switch" with "certain switches". p34 last line: "Number of Branches field"? p35 para before 4.5: "...is not implemented in..." -> "...is not defined in..." p46 2nd para last sentence: "...in an Add Branch..." -> "...in a valid Add Branch..." p48 last line: missing period at end. p49 sec5.2 first para: "...of the reservation." -> "...associated with that reservation object." p51 1st para: first sentence mentions all the functions except control of the "connection relace" function. p56 under "flow control flags field": the text here (esp. the 2nd para) is confusing and the structure of the flags field is unclear. section 6.2: i can't imagine what min and max labels might mean for the structured tdm labels. p58: D flag: the word "disjoint" means that two sets have no elements in common. isn't it more important here that the label ranges are not contiguous? what about overlapping label ranges for mpls unicast and multicast? how are these handled? the label ranges of two label spaces on one port are not disjoint in this case. after "Range Length" field the Min and Max Labels fields and Remaining Labels field should be defined, if only to say that they are defined below. last sentence of 2nd para after "Range Length": "..would be able to satisfy." -> "is able..." what happens to extant connection state when label ranges are changed? this seems to be rather important. p84: a reference to the iee qgsmp specification must eb given. if that spec is not ready for referencing then the code point should be removed and given over to iana. p87: port types stm1 and sts3 would seem to be important here. (already mentioned above) "Data Fields Length" field seems triply redundant. the function of checking the length of the fields can be achieved using the gsmp message length. p90 last para: "Count" -> "The total number" p103: 1st para: space after "3.1" next para: what is "the Service model Data field"? last line: "chapter" -> "section" p106: under CLR: the 10exp(-n) notation could be confusing to many readers. (exp(x) is often used for e^x in physics.) suggest instead "CLR takes the value of ten raised to the power of - n, i.e. log(CLR)=-n" last two paragraphs: remove "binary" p121: i think its a serious limitation that diff-serv isn't supported. diff-serv is seeing a lot of deployment in conjunction with mpls and now with atm. it wouldn't be too hard to fill this gap. you really just need to specify a phb group for a conenction. i don't understand the traffic and qos parameters for circuit em. encaps draft: p2: first para: "gsmp packets" -> "gsmp messages" last para 2nd line" "reference source not found" p4: "Frame check seq" should be defined. p4 1st para after "Pad": suggest "After adjacency has been established" p5: in the picture the Type value 6068 looks wrong. under "type" it says the gsmp ether type is 000c, should be 880c? From owner-gsmp@psyton.com Fri Aug 18 19:01:40 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10110 for ; Fri, 18 Aug 2000 19:01:40 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id SAA00967 for gsmp-list; Fri, 18 Aug 2000 18:52:30 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id SAA00964 for ; Fri, 18 Aug 2000 18:52:30 -0400 Received: (qmail 1902 invoked from network); 18 Aug 2000 21:48:12 -0000 Received: from unknown (HELO tworster) (192.168.64.102) by d83b22c8.dsl.flashcom.net with SMTP; 18 Aug 2000 21:48:12 -0000 From: "tom worster" To: Subject: RE: One last last call comment Date: Fri, 18 Aug 2000 18:53:22 -0400 Message-ID: <001901c00967$1d07b620$6640a8c0@thefsb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <399DB021.57692FBA@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit regarding separating datalink specific parts: i think this will make matters worse. i imagine implementing from the gsmp specs on a switch like ennovate's envoy 1600: all of the datalinks are relevant. dealing with several intricately cross-referenced specs would be a nightmare. also, separating out these would be enormously complex. the resulting pile of specs would be way more complicated that today's single doc. i doubt that it would be easier for an implementer to follow even if they were using only one datalink type since instead of ignoring certain parts of the current spec they would have to cross reference the docs which is not easier. i agree that gsmpv3 is long but that reflects the complexity of switches as did the length of the vsi spec. but the suggested edit is a huge and complex job that would not, in my view, bring any benefit. removing the service model would mot be quite so hard but would also bring no benefit since it is part the default qos config. the spec has to go somewhere: locating it in a separate doc increases the total word count of the gsmp spec compared to a separate chapter. and those suggesting such huge editing jobs might like to consider volunteering to supply the wg with revised text so that we could evaluate if it really is an improvement. c u fsb From owner-gsmp@psyton.com Fri Aug 18 19:24:03 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10340 for ; Fri, 18 Aug 2000 19:24:03 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id TAA01083 for gsmp-list; Fri, 18 Aug 2000 19:10:03 -0400 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id TAA01080 for ; Fri, 18 Aug 2000 19:10:02 -0400 Received: from pavilion (IDENT:root@asylum [192.48.232.17]) by apocalypse.org (8.9.3/8.9.3) with SMTP id TAA22451; Fri, 18 Aug 2000 19:09:57 -0400 Message-ID: <004501c00969$4d673780$6d21fea9@pavilion> From: "avri" To: Cc: "tom worster" References: <001801c00964$fb9bb880$6640a8c0@thefsb.org> Subject: Re: last call comments Date: Fri, 18 Aug 2000 19:08:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, Thank you for the detailed comments. We will work through them in the next few days. One question/request: any chance you can contribute the entry for DiffServ? It was dropped because no one knowledgeable contributed text. If you understand what belongs there that would be a great help. Thanks again, a. ----- Original Message ----- From: "tom worster" To: Sent: Friday, August 18, 2000 6:38 PM Subject: last call comments [snip] > p121: > > i think its a serious limitation that diff-serv isn't > supported. diff-serv is seeing a lot of deployment in > conjunction with mpls and now with atm. it wouldn't be too > hard to fill this gap. you really just need to specify a phb > group for a conenction. [snip] From owner-gsmp@psyton.com Mon Aug 21 10:15:18 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01212 for ; Mon, 21 Aug 2000 10:15:17 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id JAA09849 for gsmp-list; Mon, 21 Aug 2000 09:53:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id JAA09846 for ; Mon, 21 Aug 2000 09:53:06 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e7LDr3w12715 for ; Mon, 21 Aug 2000 15:53:03 +0200 (MEST) Received: from esealnt406.al.sw.ericsson.se ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2195.1600); Mon, 21 Aug 2000 15:53:03 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by esealnt406.al.sw.ericsson.se (NAVIEG 2.1 bld 61) with SMTP id M2000082115530228878 ; Mon, 21 Aug 2000 15:53:02 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Mon, 21 Aug 2000 15:53:02 +0200 Message-ID: <21A2BDF7A29CD3118B000008C75D087302703E58@esealnt127> From: =?ISO-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?= To: gsmp@psyton.com Cc: =?ISO-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?=, "'Joachim Buerkle'", "'balaji@cplane.com'" Subject: additional last call comment in gsmp mib Date: Mon, 21 Aug 2000 15:51:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 21 Aug 2000 13:53:03.0160 (UTC) FILETIME=[1FF5F380:01C00B77] Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Hi, Even though the last call ended friday, I don't think that just having a partiton ID on the entiry is enough. The controller entity needs to be configured to either don't handle partitions (PTYPE=0), request a specific partition identifier (PTYPE=1 and Partition ID != 0) or to allow the switch to chose partition identifier (PTYPE=1 and Partition ID = 0). Correct ? The switch entity needs to be configured to either don't allow partitions (PTYPE=0), only to allow a specific partition identifier (PTYPE=1 and Partition ID != 0) and to assign partition identifier in case it's not assigned by the controller. Correct ? To configure this per entity we need to add a PTYPE to both the controller adn the switch sides. Its not possible to define this with only the gsmpVscePartitionId and gsmpVsePartitionId objects. If you agree that this is needed PTYPE objects gets added to the mib as a (last) last call comment. regards /// Hasse From owner-gsmp@psyton.com Mon Aug 21 11:28:49 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02818 for ; Mon, 21 Aug 2000 11:28:48 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id LAA10127 for gsmp-list; Mon, 21 Aug 2000 11:09:13 -0400 Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id LAA10124 for ; Mon, 21 Aug 2000 11:09:11 -0400 Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id KAA15603 for ; Mon, 21 Aug 2000 10:07:50 -0500 (CDT) Received: from tellabs.com (bbpchr53.bb.tellabs.com [138.111.163.53]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA13985 for ; Mon, 21 Aug 2000 10:08:39 -0500 (CDT) Message-ID: <39A145F7.A0B8BA6F@tellabs.com> Date: Mon, 21 Aug 2000 10:08:39 -0500 From: Jonathan Sadler Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: last call comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Tom - The Generalized MPLS draft being worked on in the MPLS wg includes definition of a variable label size, as well as labels that are 32-bits in length (ie. SDH, SONET, and Optical labels -- see Sec 3.2.1) While the TLV formats for ATM and FR could be dropped, the TLV format for MPLS will be required if Generalized MPLS is to be supported. It seems that some of these label formats defined in the GSMPv3 spec intersect with the label formats being defined as a part of the Generalized MPLS work. It seems the best would be to take the SONET/SDH definitions and merge them with the sub-DS1 formats proposed in GSMP v3. Jonathan Sadler fsb@thefsb.org wrote: --- 8< snip >8 --- > pg15: tlv labels for atm, fr and mpls. i don't think it > makes sense to support two different encodings for these > labels. this poses a complexity burden on the spec and on > implementations and doesn't seem to have any associated > benefit. if there is a need for two different encodings > then it is not apparent. > > as far as i can see, none of the label types supported have > variable length value (i.e. the v in tlv) fields so is seems > unnecessary to distinguish between short and tlv labels. and > since the length field is redundant, a uniform label > encoding using type discriminators would appear to suffice. > > so i think we should go for: 1) only tlv labels, or 2) a > uniform encoding without a length field, or 3) drop the tlv > versions of atm, fr and mpls. --- 8< snip >8 --- > pg18 and throughout the spec: the ds3/e3/... labels are > inadequately defined. it is completely unclear to me what a > channel id is and i cannot understand how the time slots > field is encoded. it seems that reference must be made to > the sandards that specify the multiplex structure of these > signals and the semantics of the fields specified in the > gsmp be related unambiguously to those standards. > > also, since we are doing channelised ds1, ds3 etc it seems > only reasonable to also do channelised sts3 and stm1. the > deployment of channelised sts3 and stm1 in access networks > is very is widespread and increasing rapidly. From owner-gsmp@psyton.com Mon Aug 21 13:18:25 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04899 for ; Mon, 21 Aug 2000 13:18:24 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id NAA10576 for gsmp-list; Mon, 21 Aug 2000 13:02:34 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id NAA10570 for ; Mon, 21 Aug 2000 13:02:33 -0400 Received: (qmail 11079 invoked from network); 21 Aug 2000 15:58:22 -0000 Received: from d83b22c8.dsl.flashcom.net (HELO tworster) (216.59.34.200) by d83b22c8.dsl.flashcom.net with SMTP; 21 Aug 2000 15:58:22 -0000 From: "tom worster" To: Subject: RE: last call comments Date: Mon, 21 Aug 2000 13:03:31 -0400 Message-ID: <000001c00b91$bcc58a80$7203010a@ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <39A145F7.A0B8BA6F@tellabs.com> Importance: Normal Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of Jonathan Sadler > > The Generalized MPLS draft being worked on in the MPLS wg includes > definition of a variable label size, as well as labels that > are 32-bits > in length (ie. SDH, SONET, and Optical labels -- see Sec 3.2.1) While > the TLV formats for ATM and FR could be dropped, the TLV > format for MPLS > will be required if Generalized MPLS is to be supported. if variable length labels are required then tlvs make sense. but with that decided we need to make up our minds if atm, fr and basic mpls labels should be encoded in tlvs or in the short format. i don't much care which but it doesn't make any sense to specify both encodings. > It seems that some of these label formats defined in the GSMPv3 spec > intersect with the label formats being defined as a part of the > Generalized MPLS work. It seems the best would be to take > the SONET/SDH > definitions and merge them with the sub-DS1 formats proposed > in GSMP v3. in principle that would be the best approach. but i think the timing is bad. gsmp closed last call on friday and generalised mpls signalling is new and not exactly stable. a workable compromise might be to remove the tdm labels from gsmp v3 into a separate draft, put out gsmpv3 as is and then handle the tdm-label draft according to what goes down in generalised mpls. since the label type will be ianaised there shouldn't be much difficulty. any thoughts on that approach? c u fsb From owner-gsmp@psyton.com Tue Aug 22 18:17:09 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16849 for ; Tue, 22 Aug 2000 18:17:09 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id SAA15300 for gsmp-list; Tue, 22 Aug 2000 18:01:23 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id SAA15297 for ; Tue, 22 Aug 2000 18:01:23 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Tue, 22 Aug 2000 18:01:00 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RDYRYSS1; Tue, 22 Aug 2000 15:00:54 -0700 Received: from nortelnetworks.com (AVRI-1 [47.63.78.141]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RGLXZ5NL; Tue, 22 Aug 2000 18:00:04 -0400 Message-ID: <39A2F7C5.A7F9D8B9@nortelnetworks.com> Date: Tue, 22 Aug 2000 14:59:33 -0700 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: additional last call comment in gsmp mib References: <21A2BDF7A29CD3118B000008C75D087302703E58@esealnt127> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Hi, This seems totally reasonable. You are right, that info does need to be conveyed via mib or some other a-priori technique. a. Hans Sjöstrand (ETX) wrote: > > Hi, > > Even though the last call ended friday, I don't think that just having a partiton ID on the entiry is enough. > > The controller entity needs to be configured to either don't handle partitions (PTYPE=0), request a specific partition identifier (PTYPE=1 and Partition ID != 0) or to allow the switch to chose partition identifier (PTYPE=1 and Partition ID = 0). Correct ? > > The switch entity needs to be configured to either don't allow partitions (PTYPE=0), only to allow a specific partition identifier (PTYPE=1 and Partition ID != 0) and to assign partition identifier in case it's not assigned by the controller. Correct ? > > To configure this per entity we need to add a PTYPE to both the controller adn the switch sides. Its not possible to define this with only the gsmpVscePartitionId and gsmpVsePartitionId objects. > > If you agree that this is needed PTYPE objects gets added to the mib as a (last) last call comment. > > regards > /// Hasse -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Aug 22 18:17:14 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16860 for ; Tue, 22 Aug 2000 18:17:13 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id SAA15293 for gsmp-list; Tue, 22 Aug 2000 18:00:59 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id SAA15290 for ; Tue, 22 Aug 2000 18:00:52 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Tue, 22 Aug 2000 18:00:21 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RDYRYSQY; Tue, 22 Aug 2000 15:00:19 -0700 Received: from nortelnetworks.com (AVRI-1 [47.63.78.141]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RGLXZ5NN; Tue, 22 Aug 2000 18:00:18 -0400 Message-ID: <39A2F7D3.F9F66366@nortelnetworks.com> Date: Tue, 22 Aug 2000 14:59:47 -0700 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: last call comments References: <000001c00b91$bcc58a80$7203010a@ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, I actually think it does make sense to do both. In the first instance, retaining the short form makes sense for backward compatibility, and for those using just ATM, FR or MPLS labels who don't need the variable length capability. On the other hand, for someone whose switch handles several interface types, including some that have fixed length and some that have variable length, it makes sense to be able to use just one kind of label in their implementation. What doesn't necessarily make sense is to require any particular switch to support both methods. This needs to be handled by adding a phrase indicating the switches must adopt at least one of the two label types. Regards a. tom worster wrote: > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Jonathan Sadler > > > > The Generalized MPLS draft being worked on in the MPLS wg includes > > definition of a variable label size, as well as labels that > > are 32-bits > > in length (ie. SDH, SONET, and Optical labels -- see Sec 3.2.1) While > > the TLV formats for ATM and FR could be dropped, the TLV > > format for MPLS > > will be required if Generalized MPLS is to be supported. > > if variable length labels are required then tlvs make sense. > but with that decided we need to make up our minds if atm, > fr and basic mpls labels should be encoded in tlvs or in > the short format. i don't much care which but it doesn't > make any sense to specify both encodings. > > > It seems that some of these label formats defined in the GSMPv3 spec > > intersect with the label formats being defined as a part of the > > Generalized MPLS work. It seems the best would be to take > > the SONET/SDH > > definitions and merge them with the sub-DS1 formats proposed > > in GSMP v3. > > in principle that would be the best approach. but i think the > timing is bad. gsmp closed last call on friday and generalised > mpls signalling is new and not exactly stable. > > a workable compromise might be to remove the tdm labels from > gsmp v3 into a separate draft, put out gsmpv3 as is and then > handle the tdm-label draft according to what goes down in > generalised mpls. since the label type will be ianaised there > shouldn't be much difficulty. > > any thoughts on that approach? > > c u > fsb -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Aug 22 18:33:36 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17065 for ; Tue, 22 Aug 2000 18:33:36 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id SAA15501 for gsmp-list; Tue, 22 Aug 2000 18:23:16 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id SAA15498 for ; Tue, 22 Aug 2000 18:23:13 -0400 Received: (qmail 22047 invoked from network); 22 Aug 2000 21:03:03 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 22 Aug 2000 21:03:03 -0000 Received: (qmail 16450 invoked from network); 22 Aug 2000 22:23:00 -0000 Received: from unknown (HELO bombay.cplane.com) (unknown) by unknown with SMTP; 22 Aug 2000 22:23:00 -0000 Date: Tue, 22 Aug 2000 15:23:00 -0700 (PDT) From: Balaji Srinivasan To: gsmp@psyton.com Subject: Re: last call comments In-Reply-To: <39A2F7D3.F9F66366@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com >What doesn't necessarily make sense is to require any particular >switch to support both methods. This needs to be handled by adding >a phrase indicating the switches must adopt at least one of the two >label types. > If we do this then the controller must be able to discover this from the switch (via the switch configuration message or some such.) balaji From owner-gsmp@psyton.com Wed Aug 23 04:40:40 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06368 for ; Wed, 23 Aug 2000 04:40:40 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id EAA16964 for gsmp-list; Wed, 23 Aug 2000 04:27:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id EAA16961 for ; Wed, 23 Aug 2000 04:27:50 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e7N8Rmp00699 for ; Wed, 23 Aug 2000 10:27:48 +0200 (MEST) Received: from esealnt406.al.sw.ericsson.se ([153.88.251.29]) by esealnt406.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2195.1600); Wed, 23 Aug 2000 10:27:48 +0200 Received: from esealnt172.ericsson.se ([130.100.184.165]) by esealnt406.al.sw.ericsson.se (NAVIEG 2.1 bld 61) with SMTP id M2000082310274804259 for ; Wed, 23 Aug 2000 10:27:48 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Wed, 23 Aug 2000 10:27:48 +0200 Message-ID: <21A2BDF7A29CD3118B000008C75D087302703E5F@esealnt127> From: =?ISO-8859-1?Q?Hans_Sj=F6strand_=28ETX=29?= To: "'gsmp@psyton.com'" Subject: RE: last call comments Date: Wed, 23 Aug 2000 10:26:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 23 Aug 2000 08:27:48.0721 (UTC) FILETIME=[05465E10:01C00CDC] Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com > >What doesn't necessarily make sense is to require any particular > >switch to support both methods. This needs to be handled by adding > >a phrase indicating the switches must adopt at least one of the two > >label types. > > > > If we do this then the controller must be able to discover > this from the > switch (via the switch configuration message or some such.) > balaji > This was a bad track that just will cause incomptibility. What happens if two boxes have chosen different encoding. Doesn't really matter if they discover early or late, it doesn't work anyway. The old slogan "Be liberal in what you accept, and conservative in what you send." must apply. Decoding TLV's is trivial programming, please retain both. /// Hasse From owner-gsmp@psyton.com Wed Aug 23 09:55:20 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11669 for ; Wed, 23 Aug 2000 09:55:18 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id JAA17685 for gsmp-list; Wed, 23 Aug 2000 09:32:30 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id JAA17682 for ; Wed, 23 Aug 2000 09:32:28 -0400 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Wed, 23 Aug 2000 08:27:59 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RDYRZVJ0; Wed, 23 Aug 2000 06:26:44 -0700 Received: from nortelnetworks.com (AVRI-1 [47.63.78.141]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RGLXZ5W7; Wed, 23 Aug 2000 09:23:14 -0400 Message-ID: <39A3D02B.C63DC58A@nortelnetworks.com> Date: Wed, 23 Aug 2000 06:22:51 -0700 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: last call comments References: <21A2BDF7A29CD3118B000008C75D087302703E5F@esealnt127> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 8bit Hi, Of course you are right. Thank you for reminding me of the liberal in acceptance motto. While we could have used GSMP's normal method of sending an error message about a capability not supported, I think that in this case you are right and both should be required. Does anyone else have a comment on this issue? Thanks a. Hans Sjöstrand (ETX) wrote: > > > >What doesn't necessarily make sense is to require any particular > > >switch to support both methods. This needs to be handled by adding > > >a phrase indicating the switches must adopt at least one of the two > > >label types. > > > > > > > If we do this then the controller must be able to discover > > this from the > > switch (via the switch configuration message or some such.) > > balaji > > > > This was a bad track that just will cause incomptibility. What happens if two boxes have chosen different encoding. Doesn't really matter if they discover early or late, it doesn't work anyway. > > The old slogan "Be liberal in what you accept, and conservative in what you send." must apply. Decoding TLV's is trivial programming, please retain both. > > /// Hasse -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Wed Aug 23 12:00:12 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16335 for ; Wed, 23 Aug 2000 12:00:11 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id LAA18152 for gsmp-list; Wed, 23 Aug 2000 11:47:29 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id LAA18149 for ; Wed, 23 Aug 2000 11:47:27 -0400 Received: (qmail 24105 invoked from network); 23 Aug 2000 14:27:26 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 23 Aug 2000 14:27:26 -0000 Received: (qmail 7966 invoked from network); 23 Aug 2000 15:47:25 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 23 Aug 2000 15:47:25 -0000 Date: Wed, 23 Aug 2000 08:47:25 -0700 (PDT) From: Balaji Srinivasan To: gsmp@psyton.com Subject: Re: last call comments In-Reply-To: <39A3D02B.C63DC58A@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com >Of course you are right. Thank you for reminding me of >the liberal in acceptance motto. > >While we could have used GSMP's normal method of sending >an error message about a capability not supported, I >think that in this case you are right and both should be >required. > >Does anyone else have a comment on this issue? > Just this. How important is backward compatibility, especially since the PDU format has already chaged from v1 (the service capabilities etc). Does making all labels TLVs help? I would think so. It would be easier if there is not a lot of run time decisions. If we keep the old format labels in will they help in backward compatibility? I dont think so since the rest of the connection management PDU has already changed. Thanks balaji -- Balaji Srinivasan balaji@cplane.com Control Plane Technologies From owner-gsmp@psyton.com Thu Aug 24 12:39:32 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20254 for ; Thu, 24 Aug 2000 12:39:32 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id MAA21935 for gsmp-list; Thu, 24 Aug 2000 12:20:57 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id MAA21932 for ; Thu, 24 Aug 2000 12:20:50 -0400 Received: (qmail 14073 invoked from network); 24 Aug 2000 15:16:41 -0000 Received: from unknown (HELO tworster) (192.168.64.102) by d83b22c8.dsl.flashcom.net with SMTP; 24 Aug 2000 15:16:41 -0000 From: "tom worster" To: Subject: RE: last call comments Date: Thu, 24 Aug 2000 12:21:50 -0400 Message-ID: <000101c00de7$68efdb10$6640a8c0@thefsb.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of Balaji Srinivasan > > >What doesn't necessarily make sense is to require any particular > >switch to support both methods. This needs to be handled by adding > >a phrase indicating the switches must adopt at least one of the two > >label types. > > > > If we do this then the controller must be able to discover > this from the > switch (via the switch configuration message or some such.) that's right. but there is no need for this much complexity. i see these options: 1) use short form, fixed length for all labels. this is no good since there is a need for variable length labels. 2) use tlv form for all labels. this will work. it is the cleanest solution. 3) use short for atm/fr/mpls and tlv for the rest. this will work. 4) require switch support for both forms. this will also work. 5) allow switch to support either or both. this is broken -- unless we add something like the discovery you mentioned to fix it. so i think we should choose between 2), 3), and 4). i don't much like 4) because it seems nonsensical to require two message formats for the same thing -- which was my original last call comment. but i'm willing to go along with any of these three. c u fsb From owner-gsmp@psyton.com Thu Aug 24 13:35:49 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21099 for ; Thu, 24 Aug 2000 13:35:49 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id NAA22217 for gsmp-list; Thu, 24 Aug 2000 13:22:56 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id NAA22213 for ; Thu, 24 Aug 2000 13:22:54 -0400 Received: (qmail 29399 invoked from network); 24 Aug 2000 16:02:43 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 24 Aug 2000 16:02:43 -0000 Received: (qmail 29937 invoked from network); 24 Aug 2000 17:22:45 -0000 Received: from unknown (HELO cplane.com) (unknown) by unknown with SMTP; 24 Aug 2000 17:22:45 -0000 Message-ID: <39A559E5.264D5B76@cplane.com> Date: Thu, 24 Aug 2000 10:22:45 -0700 From: Jaroslaw Sydir Organization: CPlane Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: last call comments References: <000101c00de7$68efdb10$6640a8c0@thefsb.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit My preference is for choice 2. Jerry tom worster wrote: > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Balaji Srinivasan > > > > >What doesn't necessarily make sense is to require any particular > > >switch to support both methods. This needs to be handled by adding > > >a phrase indicating the switches must adopt at least one of the two > > >label types. > > > > > > > If we do this then the controller must be able to discover > > this from the > > switch (via the switch configuration message or some such.) > > that's right. but there is no need for this much complexity. > > i see these options: > > 1) use short form, fixed length for all labels. this is no good since > there is a need for variable length labels. > > 2) use tlv form for all labels. this will work. it is the cleanest > solution. > > 3) use short for atm/fr/mpls and tlv for the rest. this will work. > > 4) require switch support for both forms. this will also work. > > 5) allow switch to support either or both. this is broken -- unless > we add something like the discovery you mentioned to fix it. > > so i think we should choose between 2), 3), and 4). i don't much > like 4) because it seems nonsensical to require two message formats > for the same thing -- which was my original last call comment. but > i'm willing to go along with any of these three. > > c u > fsb From owner-gsmp@psyton.com Thu Aug 24 13:49:09 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21327 for ; Thu, 24 Aug 2000 13:49:09 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id NAA22313 for gsmp-list; Thu, 24 Aug 2000 13:36:02 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.9.0/8.9.0) with SMTP id NAA22310 for ; Thu, 24 Aug 2000 13:36:02 -0400 Received: (qmail 29473 invoked from network); 24 Aug 2000 16:15:58 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 24 Aug 2000 16:15:58 -0000 Received: (qmail 3497 invoked from network); 24 Aug 2000 17:35:59 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 24 Aug 2000 17:35:59 -0000 Date: Thu, 24 Aug 2000 10:35:59 -0700 (PDT) From: Balaji Srinivasan To: gsmp@psyton.com Subject: RE: last call comments In-Reply-To: <000101c00de7$68efdb10$6640a8c0@thefsb.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com > >2) use tlv form for all labels. this will work. it is the cleanest >solution. > Hi Everyone I think this is the best solution... balaji From owner-gsmp@psyton.com Fri Aug 25 01:56:07 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06428 for ; Fri, 25 Aug 2000 01:56:07 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id BAA24199 for gsmp-list; Fri, 25 Aug 2000 01:40:40 -0400 Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id BAA24196 for ; Fri, 25 Aug 2000 01:40:32 -0400 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0FZU00A012EPNX@firewall.mcit.com> for gsmp@psyton.com; Fri, 25 Aug 2000 05:40:01 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FZU00FLT2EPPC@firewall.mcit.com> for gsmp@psyton.com; Fri, 25 Aug 2000 05:40:01 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0FZU0010127KP4@pmismtp04.wcomnet.com> for gsmp@psyton.com; Fri, 25 Aug 2000 05:35:44 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FZU0010127JP1@pmismtp04.wcomnet.com> for gsmp@psyton.com; Fri, 25 Aug 2000 05:35:44 +0000 (GMT) Received: from pc25811 ([166.44.154.26]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0FZU006CS2753D@pmismtp04.wcomnet.com> for gsmp@psyton.com; Fri, 25 Aug 2000 05:35:31 +0000 (GMT) Date: Fri, 25 Aug 2000 00:37:23 -0500 From: Clint Bishard Subject: RE: last call comments In-reply-to: <000101c00de7$68efdb10$6640a8c0@thefsb.org> To: gsmp@psyton.com Message-id: <001e01c00e56$8c4ce5c0$6c9b2ca6@pc25811.wcom.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit It appears that option 2 is the cleanest solution. Particularly given the statements that backwards compatibility has already been lost due to the other changes. Clint -----Original Message----- From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of tom worster Sent: Thursday, August 24, 2000 11:22 AM To: gsmp@psyton.com Subject: RE: last call comments From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of Balaji Srinivasan > > >What doesn't necessarily make sense is to require any particular > >switch to support both methods. This needs to be handled by adding > >a phrase indicating the switches must adopt at least one of the two > >label types. > > > > If we do this then the controller must be able to discover > this from the > switch (via the switch configuration message or some such.) that's right. but there is no need for this much complexity. i see these options: 1) use short form, fixed length for all labels. this is no good since there is a need for variable length labels. 2) use tlv form for all labels. this will work. it is the cleanest solution. 3) use short for atm/fr/mpls and tlv for the rest. this will work. 4) require switch support for both forms. this will also work. 5) allow switch to support either or both. this is broken -- unless we add something like the discovery you mentioned to fix it. so i think we should choose between 2), 3), and 4). i don't much like 4) because it seems nonsensical to require two message formats for the same thing -- which was my original last call comment. but i'm willing to go along with any of these three. c u fsb From owner-gsmp@psyton.com Fri Aug 25 04:24:49 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14239 for ; Fri, 25 Aug 2000 04:24:49 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id EAA24632 for gsmp-list; Fri, 25 Aug 2000 04:13:23 -0400 Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id EAA24629 for ; Fri, 25 Aug 2000 04:13:21 -0400 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Fri, 25 Aug 2000 09:12:39 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QZCY482R; Fri, 25 Aug 2000 09:12:38 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.228]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Q83PA7TT; Fri, 25 Aug 2000 10:12:36 +0200 Message-ID: <39A62ABE.8D15CA17@europem01.nt.com> Date: Fri, 25 Aug 2000 10:13:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Kenneth Sundell" X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: last call comments References: <001e01c00e56$8c4ce5c0$6c9b2ca6@pc25811.wcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit folks, is there anyone that objects to option 2 as described below? ken Clint Bishard wrote: > It appears that option 2 is the cleanest solution. Particularly given the > statements that backwards compatibility has already been lost due to the > other changes. > > Clint > > -----Original Message----- > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > tom worster > Sent: Thursday, August 24, 2000 11:22 AM > To: gsmp@psyton.com > Subject: RE: last call comments > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Balaji Srinivasan > > > > >What doesn't necessarily make sense is to require any particular > > >switch to support both methods. This needs to be handled by adding > > >a phrase indicating the switches must adopt at least one of the two > > >label types. > > > > > > > If we do this then the controller must be able to discover > > this from the > > switch (via the switch configuration message or some such.) > > that's right. but there is no need for this much complexity. > > i see these options: > > 1) use short form, fixed length for all labels. this is no good since > there is a need for variable length labels. > > 2) use tlv form for all labels. this will work. it is the cleanest > solution. > > 3) use short for atm/fr/mpls and tlv for the rest. this will work. > > 4) require switch support for both forms. this will also work. > > 5) allow switch to support either or both. this is broken -- unless > we add something like the discovery you mentioned to fix it. > > so i think we should choose between 2), 3), and 4). i don't much > like 4) because it seems nonsensical to require two message formats > for the same thing -- which was my original last call comment. but > i'm willing to go along with any of these three. > > c u > fsb -- Kenneth Sundell Routing Architecture Lab, Nortel Networks Sweden phone: +46 8 5088-3538, mobile +46 70 665-7838 From owner-gsmp@psyton.com Mon Aug 28 22:00:56 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24391 for ; Mon, 28 Aug 2000 22:00:56 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id VAA05272 for gsmp-list; Mon, 28 Aug 2000 21:42:40 -0400 Received: from mail.cs.umn.edu (root@mail.cs.umn.edu [128.101.32.200]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id VAA05269 for ; Mon, 28 Aug 2000 21:42:39 -0400 Received: from myria.cs.umn.edu (tsang@myria.cs.umn.edu [128.101.35.174]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id UAA24000 for ; Mon, 28 Aug 2000 20:42:38 -0500 (CDT) From: Rose Tsang Received: (from tsang@localhost) by myria.cs.umn.edu (8.9.1/8.9.0) id UAA02143 for gsmp@psyton.com; Mon, 28 Aug 2000 20:42:37 -0500 (CDT) Message-Id: <200008290142.UAA02143@myria.cs.umn.edu> Subject: I/O QoS Model Selector To: gsmp@psyton.com Date: Mon, 28 Aug 2000 20:42:37 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit The I/O QoS Model Selector fields are not clearly described in the spectification. For example, on page 24, "If a valid Reservation ID is specified and the Service Model is used (i.e., IQS/OQS=0b10)". From examining the figure showing the message format, the IQS is a 2 bit field and the OQS is a 2 bit field, but "IQS/OQS" cannot refer to these 2-bit fields, eventhough they have the same name??? So do they really refer to the 32-bit Input Service Selector and 32 bit Output Service Selector fields? What is the format of these two 32 bit fields??? Chapter 10 describes how service IDs are used to identify different service definitions, but where are the service IDs speicified in the GSMP message? The only reference to where they belong in the GSMP message is in the 2nd sentence of Section 10.1: "The requested Service is identified by including a Service ID in the Add Branch Message". Where????? Thanks for your help in advance, Rose Tsang From owner-gsmp@psyton.com Tue Aug 29 14:32:37 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.14.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28133 for ; Tue, 29 Aug 2000 14:32:36 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.9.0/8.9.0) id OAA07905 for gsmp-list; Tue, 29 Aug 2000 14:21:40 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.9.0/8.9.0) with ESMTP id OAA07902 for ; Tue, 29 Aug 2000 14:21:39 -0400 Received: from zsc4c002.corpwest.baynetworks.com by ertpg14e1.nortelnetworks.com; Tue, 29 Aug 2000 10:05:22 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RX6JDKYS; Tue, 29 Aug 2000 07:02:00 -0700 Received: from nortelnetworks.com (AVRI-1 [132.245.139.252]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RGLX5A9A; Tue, 29 Aug 2000 10:01:58 -0400 Message-ID: <39ABC216.DA468E7C@nortelnetworks.com> Date: Tue, 29 Aug 2000 10:00:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: I/O QoS Model Selector References: <200008290142.UAA02143@myria.cs.umn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com Content-Transfer-Encoding: 7bit Hi, Thanks for your note. The issue you raise is related to the one of the comments we received during the last call. The reference to IQS, OQS and selectors is not clear. It will be rewritten. Briefly IQS/OQS definition refers to both 2 bit fields. If IQS = 0b10 then the Input Service Selector is defined by the ch 10 service model. Likewise, if the OQS = 0b10 then the Output Service Selector is defined by the chapter 10 service model. Also, you are correct about the description being difficult to follow (something we MUST fix) The service selector referred to on page 23-24 corresponds to the service ID plus the capability set ID. This is described in chapter 8 on page 87 as a 16 bit field (unlike the 32 bit field shown on page 24. The service IDs are defined in ch 10, and the capability set ids are defined by the system administrator outside of GSMP. This is definitely not clear at the moment. It is obvious that we need to review these sections and do a few things including bringing the field descriptions into alignment and adding a section to the beginning of the doc where commonly used fields are listed to explain the service selector field. Thanks for bringing this up. a. Rose Tsang wrote: > > The I/O QoS Model Selector fields are not clearly described > in the spectification. > > For example, on page 24, "If a valid Reservation ID is > specified and the Service Model is used (i.e., IQS/OQS=0b10)". > >From examining the figure showing the message format, > the IQS is a 2 bit field and the OQS is a 2 bit field, > but "IQS/OQS" cannot refer to these 2-bit fields, eventhough > they have the same name??? So do they really refer to the > 32-bit Input Service Selector and 32 bit Output Service > Selector fields? What is the format of these two 32 bit > fields??? Chapter 10 describes how service IDs are used > to identify different service definitions, but where > are the service IDs speicified in the GSMP message? > The only reference to where they belong in the GSMP message > is in the 2nd sentence of Section 10.1: "The requested Service > is identified by including a Service ID in the Add Branch > Message". Where????? > > Thanks for your help in advance, > Rose Tsang -- Avri Doria +1 401 663 5024