From owner-gsmp@psyton.com Mon Oct 2 14:34:23 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12195 for ; Mon, 2 Oct 2000 14:34:23 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e92IJNs01844 for gsmp-list; Mon, 2 Oct 2000 14:19:23 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e92IJLe01841 for ; Mon, 2 Oct 2000 14:19:21 -0400 Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Mon, 2 Oct 2000 13:15:02 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 41H2G1JQ; Mon, 2 Oct 2000 14:12:27 -0400 Received: from nortelnetworks.com (AVRI-1 [47.81.6.87]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ687; Mon, 2 Oct 2000 14:12:26 -0400 Message-ID: <39D8CFFC.9B661906@nortelnetworks.com> Disposition-Notification-To: avri doria Date: Mon, 02 Oct 2000 14:12:12 -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: Proposal for rework of charter 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 following is the current wording of the proposed re-charter of the group. Before sending it on to the ADs, I am looking for WG consensus on sending it on. Please comment within the next 2 weeks (i.e., by 16 October) thanks a. -- Avri Doria +1 401 663 5024 --------------- GSMP WG Re-Charter The base General Switch Management Protocol(GSMPv3) protocol is about to be submitted to the IESG with the request that it be made a proposed standard. Currently 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 current working group is responsible for completing the standardization of the GSMP protocol under the current charter. Future work includes: adding support for optical switching defining mechanisms for switch partitioning defining mechanisms for control of IP packet switches. - Support for Optical Switching The architecture of some optical switches makes the ability to remotely control the connection state of a switch important. GSMP has been designed especially for such remote control operations. GSMP is currently lacking in the specific semantics necessary for optical switches. The WG will add these capabilities to the GSMP specification. This work will be done in cooperation with the IP over Optics working group. - Switch Partitioning The current version of GSMP is designed to work with a single static switch partition. There is interest in having GSMP support multiple partitions in which resource allocation is dynamic and variable between the switch partitions. This will be achieved by adding capabilities to GSMP and by using available management tools, e.g. MIBS and PIBS. - 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. Milestones: - Document requirements for switch partitioning (Spring 2001) - Document requirements for control of optical switches (Spring 2001) - Document requirements for control of IP packet switches (Spring 2001) - Produce GSMP extensions, MIBs, and PIBs to support the requirements (Fall 2001) - Update base GSMPv3 as implementation experience mandates From owner-gsmp@psyton.com Mon Oct 2 14:56:33 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12433 for ; Mon, 2 Oct 2000 14:56:33 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e92In8T02028 for gsmp-list; Mon, 2 Oct 2000 14:49:08 -0400 Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e92In7e02025 for ; Mon, 2 Oct 2000 14:49:07 -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 NAA04521 for ; Mon, 2 Oct 2000 13:47:32 -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 NAA21499 for ; Mon, 2 Oct 2000 13:48:55 -0500 (CDT) Message-ID: <39D8D896.48F17EAD@tellabs.com> Date: Mon, 02 Oct 2000 13:48:54 -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: Proposal for rework of charter 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 Avri - In Pittsburgh, it was discussed that the re-charter not be restricted to Optical switching but include TDM and Spatial switching as well. By broadening the scope, the GSMP WG will be able to better parallel the "Generic MPLS" work in the MPLS WG. (The GMPLS draft is not restricted to just adding Lambda switching, but is also discussing SONET/SDH switched path signaling methods. This came about as a practical extension since today's service providers have to operate in Spatial, DWDM, and TDM environments.) Thoughts? Jonathan Sadler avri@nortelnetworks.com wrote: > > The following is the current wording of the proposed re-charter of the > group. Before sending it on to the ADs, I am looking for WG consensus > on sending it on. Please comment within the next 2 weeks > (i.e., by 16 October) > > thanks > a. > -- > > Avri Doria > +1 401 663 5024 > > --------------- > GSMP WG Re-Charter > > The base General Switch Management Protocol(GSMPv3) protocol is about > to be submitted to the IESG with the request that it be made a > proposed standard. > > Currently 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 current working group is responsible for completing the > standardization of the GSMP protocol under the current charter. > Future work includes: > > adding support for optical switching > defining mechanisms for switch partitioning > defining mechanisms for control of IP packet switches. > > - Support for Optical Switching > > The architecture of some optical switches makes the ability to remotely > control the connection state of a switch important. GSMP has been > designed especially for such remote control operations. GSMP is > currently lacking in the specific semantics necessary for optical > switches. The WG will add these capabilities to the GSMP specification. > This work will be done in cooperation with the IP over Optics working > group. > > - Switch Partitioning > > The current version of GSMP is designed to work with a single static > switch partition. There is interest in having GSMP support multiple > partitions in which resource allocation is dynamic and variable between > the switch partitions. This will be achieved by adding capabilities to > GSMP and by using available management tools, e.g. MIBS and PIBS. > > - 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. > > Milestones: > > - Document requirements for switch partitioning (Spring 2001) > > - Document requirements for control of optical switches (Spring 2001) > > - Document requirements for control of IP packet switches (Spring > 2001) > > - Produce GSMP extensions, MIBs, and PIBs to support the requirements > (Fall 2001) > > - Update base GSMPv3 as implementation experience mandates From owner-gsmp@psyton.com Mon Oct 2 15:25:45 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12891 for ; Mon, 2 Oct 2000 15:25:45 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e92JHwo02190 for gsmp-list; Mon, 2 Oct 2000 15:17:58 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e92JHve02187 for ; Mon, 2 Oct 2000 15:17:57 -0400 Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Mon, 2 Oct 2000 15:12:04 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T3C0RHTJ; Mon, 2 Oct 2000 15:11:56 -0400 Received: from nortelnetworks.com (AVRI-1 [47.81.6.87]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ7DH; Mon, 2 Oct 2000 15:11:58 -0400 Message-ID: <39D8DDEF.502E9BBF@nortelnetworks.com> Date: Mon, 02 Oct 2000 15:11:43 -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: Proposal for rework of charter References: <39D8D896.48F17EAD@tellabs.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, You are correct. I lost that edit. I propose the following wording be added after the Optical section : - Support for generic MPLS switching techniques The group will collect requirements and define solutions to support TDM, spatial and other switch types. This work will parallel the efforts currently underway in the MPLS group, specifically Generic MPLS. and the addition of the following work item - Document requirements for control of generic MPLS switches (Spring 2001) Thanks. a. Jonathan Sadler wrote: > > Avri - > > In Pittsburgh, it was discussed that the re-charter not be restricted to > Optical switching but include TDM and Spatial switching as well. By > broadening the scope, the GSMP WG will be able to better parallel the > "Generic MPLS" work in the MPLS WG. > > (The GMPLS draft is not restricted to just adding Lambda switching, but > is also discussing SONET/SDH switched path signaling methods. This came > about as a practical extension since today's service providers have to > operate in Spatial, DWDM, and TDM environments.) > > Thoughts? > > Jonathan Sadler > > avri@nortelnetworks.com wrote: > > > > The following is the current wording of the proposed re-charter of the > > group. Before sending it on to the ADs, I am looking for WG consensus > > on sending it on. Please comment within the next 2 weeks > > (i.e., by 16 October) > > > > thanks > > a. > > -- > > > > Avri Doria > > +1 401 663 5024 > > > > --------------- > > GSMP WG Re-Charter > > > > The base General Switch Management Protocol(GSMPv3) protocol is about > > to be submitted to the IESG with the request that it be made a > > proposed standard. > > > > Currently 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 current working group is responsible for completing the > > standardization of the GSMP protocol under the current charter. > > Future work includes: > > > > adding support for optical switching > > defining mechanisms for switch partitioning > > defining mechanisms for control of IP packet switches. > > > > - Support for Optical Switching > > > > The architecture of some optical switches makes the ability to remotely > > control the connection state of a switch important. GSMP has been > > designed especially for such remote control operations. GSMP is > > currently lacking in the specific semantics necessary for optical > > switches. The WG will add these capabilities to the GSMP specification. > > This work will be done in cooperation with the IP over Optics working > > group. > > > > - Switch Partitioning > > > > The current version of GSMP is designed to work with a single static > > switch partition. There is interest in having GSMP support multiple > > partitions in which resource allocation is dynamic and variable between > > the switch partitions. This will be achieved by adding capabilities to > > GSMP and by using available management tools, e.g. MIBS and PIBS. > > > > - 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. > > > > Milestones: > > > > - Document requirements for switch partitioning (Spring 2001) > > > > - Document requirements for control of optical switches (Spring 2001) > > > > - Document requirements for control of IP packet switches (Spring > > 2001) > > > > - Produce GSMP extensions, MIBs, and PIBs to support the requirements > > (Fall 2001) > > > > - Update base GSMPv3 as implementation experience mandates -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Mon Oct 2 23:19:00 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19712 for ; Mon, 2 Oct 2000 23:18:59 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e932vdk26982 for gsmp-list; Mon, 2 Oct 2000 22:57:39 -0400 Received: from mail3.ntu.edu.sg ([155.69.1.91]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e932vZ626978 for ; Mon, 2 Oct 2000 22:57:36 -0400 Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 10:57:24 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD0E4@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'gsmp@revnetworks.com'" Subject: RE: Some general questions on GSMP Date: Tue, 3 Oct 2000 10:57:14 +0800 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 Hi, Folks, I have some further questions: 1. Since GSMP is a protocol only to manage connections in a switch, then how does controller know that a connection in the switch should exist between these two ports, but not those two ports? Do we still need some other protocols, which can provide some related information on the required connections in the switch, to work together with GSMP? If so, do we need some rules on this cooperation? 2. To my knowledge, in the most situations, we may use those common management protocols such as OSPF, BGP, RSVP and so on to manage a network. Are there any practical applications which require GSMP? Could you tell me any examples? Many thanks for your information! Gangxiang > -----Original Message----- > From: Shen Gangxiang > Sent: Friday, September 29, 2000 4:55 PM > To: 'gsmp@revnetworks.com' > Subject: Some general questions on GSMP > > Hi, folks, > > I am new in this discussion group. I have some questions on GSMP: > 1.Based on my understanding, it seems that GSMP is a protocol only to > manage connections in a switch, not those peer-to-peer > connections(crossing multiple links). To establish a peer-to-peer one, it > needs to cooperate with other protocols including routing protocols (e.g. > OSPF) and signalling protocol (e.g. CR-LDP) > 2. If the controller and the controlled switch are deployed in the same > box, do we still need such a kind of protocol? > > Thanks in advance for any comment! > > Gangxiang From owner-gsmp@psyton.com Mon Oct 2 23:39:51 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20201 for ; Mon, 2 Oct 2000 23:39:51 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e933TZ427171 for gsmp-list; Mon, 2 Oct 2000 23:29:35 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e933TY627168 for ; Mon, 2 Oct 2000 23:29:34 -0400 Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by smtprch1.nortel.com; Mon, 2 Oct 2000 22:29:21 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T3C0RJB2; Mon, 2 Oct 2000 23:29:15 -0400 Received: from nortelnetworks.com (AVRI-1 [47.81.6.86]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ740; Mon, 2 Oct 2000 23:29:14 -0400 Message-ID: <39D9527B.2120E8D3@nortelnetworks.com> Date: Mon, 02 Oct 2000 23:28:59 -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: Some general questions on GSMP References: <9985F17605D2D21192D80008C75DE4BE01FDD0E4@exchange4.ntu.edu.sg> 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, Shen Gangxiang wrote: > > Hi, Folks, > > I have some further questions: > 1. Since GSMP is a protocol only to manage connections in a switch, then how > does controller know that a connection in the switch should exist between > these two ports, but not those two ports? Do we still need some other > protocols, which can provide some related information on the required > connections in the switch, to work together with GSMP? If so, do we need > some rules on this cooperation? Controllers are definately assumed to use some set of protocols to coordinate their assignement and use of lables in establishing connections. within a MPLs context, this might involve using CRLDP. In other situations, it might be established via COPS or some other mechanism. > 2. To my knowledge, in the most situations, we may use those common > management protocols such as OSPF, BGP, RSVP and so on to manage a network. > Are there any practical applications which require GSMP? Could you tell me > any examples? GSMP is useful when there is a desire to physically separate the control plane (where the OSPF or CRLDP is run) and the data forwarding plane. In this case the controller uses GSMP to convey connection state to the remote switch. > > Many thanks for your information! > You are most welcome a. -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Oct 3 01:05:58 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21032 for ; Tue, 3 Oct 2000 01:05:58 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e934viv27474 for gsmp-list; Tue, 3 Oct 2000 00:57:44 -0400 Received: from gateway.ntu.edu.sg (gateway.ntu.edu.sg [155.69.1.127]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e934vg627471 for ; Tue, 3 Oct 2000 00:57:43 -0400 Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <4C3BR6HJ>; Tue, 3 Oct 2000 12:57:16 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD0E7@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'avri@nortelnetworks.com'" Cc: "'gsmp@psyton.com'" Subject: RE: Some general questions on GSMP Date: Tue, 3 Oct 2000 12:57:18 +0800 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 Many thanks for your explanations!....Gangxiang -----Original Message----- From: Avri Doria [mailto:avri@nortelnetworks.com] Sent: Tuesday, October 03, 2000 11:29 AM To: gsmp@psyton.com Subject: Re: Some general questions on GSMP Hi, Shen Gangxiang wrote: > > Hi, Folks, > > I have some further questions: > 1. Since GSMP is a protocol only to manage connections in a switch, then how > does controller know that a connection in the switch should exist between > these two ports, but not those two ports? Do we still need some other > protocols, which can provide some related information on the required > connections in the switch, to work together with GSMP? If so, do we need > some rules on this cooperation? Controllers are definately assumed to use some set of protocols to coordinate their assignement and use of lables in establishing connections. within a MPLs context, this might involve using CRLDP. In other situations, it might be established via COPS or some other mechanism. > 2. To my knowledge, in the most situations, we may use those common > management protocols such as OSPF, BGP, RSVP and so on to manage a network. > Are there any practical applications which require GSMP? Could you tell me > any examples? GSMP is useful when there is a desire to physically separate the control plane (where the OSPF or CRLDP is run) and the data forwarding plane. In this case the controller uses GSMP to convey connection state to the remote switch. > > Many thanks for your information! > You are most welcome a. -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Wed Oct 4 17:46:39 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02644 for ; Wed, 4 Oct 2000 17:46:39 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e94LXba04768 for gsmp-list; Wed, 4 Oct 2000 17:33:37 -0400 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e94LXZ604765 for ; Wed, 4 Oct 2000 17:33:35 -0400 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id VAA04129 for ; Wed, 4 Oct 2000 21:34:19 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 04 Oct 2000 21:33:04 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <41X4Y713>; Wed, 4 Oct 2000 14:33:03 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8065A4AFB@orsmsx40.jf.intel.com> From: "Putzolu, David" To: "'gsmp@psyton.com'" Subject: RE: Proposal for rework of charter Date: Wed, 4 Oct 2000 14:32:47 -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 Was there some text lost when the recharter was posted? Under the section titled, "IP Packet Switches" it talks about coordinating with the MPLS group rather than talking about control of IP packet switches. Thanks, David Putzolu > -----Original Message----- > From: Avri Doria [mailto:avri@nortelnetworks.com] > Sent: Monday, October 02, 2000 11:12 AM > To: gsmp@psyton.com > Subject: Proposal for rework of charter > > > The following is the current wording of the proposed > re-charter of the > group. Before sending it on to the ADs, I am looking for WG consensus > on sending it on. Please comment within the next 2 weeks > (i.e., by 16 October) > > > thanks > a. > -- > > Avri Doria > +1 401 663 5024 > > > --------------- > GSMP WG Re-Charter > > The base General Switch Management Protocol(GSMPv3) protocol is about > to be submitted to the IESG with the request that it be made a > proposed standard. > > Currently 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 current working group is responsible for completing the > standardization of the GSMP protocol under the current charter. > Future work includes: > > adding support for optical switching > defining mechanisms for switch partitioning > defining mechanisms for control of IP packet switches. > > - Support for Optical Switching > > The architecture of some optical switches makes the ability > to remotely > control the connection state of a switch important. GSMP has been > designed especially for such remote control operations. GSMP is > currently lacking in the specific semantics necessary for optical > switches. The WG will add these capabilities to the GSMP > specification. > This work will be done in cooperation with the IP over Optics working > group. > > - Switch Partitioning > > The current version of GSMP is designed to work with a single static > switch partition. There is interest in having GSMP support multiple > partitions in which resource allocation is dynamic and > variable between > the switch partitions. This will be achieved by adding > capabilities to > GSMP and by using available management tools, e.g. MIBS and PIBS. > > - 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. > > > Milestones: > > - Document requirements for switch partitioning (Spring 2001) > > - Document requirements for control of optical switches (Spring 2001) > > - Document requirements for control of IP packet switches (Spring > 2001) > > - Produce GSMP extensions, MIBs, and PIBs to support the requirements > (Fall 2001) > > - Update base GSMPv3 as implementation experience mandates > From owner-gsmp@psyton.com Fri Oct 6 12:39:32 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07930 for ; Fri, 6 Oct 2000 12:39:31 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e96GLFr12918 for gsmp-list; Fri, 6 Oct 2000 12:21:15 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e96GLE612915 for ; Fri, 6 Oct 2000 12:21:14 -0400 Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by smtprch1.nortel.com; Fri, 6 Oct 2000 11:17:06 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4M1FD438; Fri, 6 Oct 2000 12:16:54 -0400 Received: from nortelnetworks.com (AVRI-1 [47.81.7.73]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RKDBH; Fri, 6 Oct 2000 12:16:52 -0400 Message-ID: <39DDFAEB.7B814EBA@nortelnetworks.com> Date: Fri, 06 Oct 2000 12:16:43 -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: Proposal for rework of charter References: <638EC1B28663D211AC3E00A0C96B78A8065A4AFB@orsmsx40.jf.intel.com> Content-Type: multipart/mixed; boundary="------------5658F4853E9DE89BE2AAD91E" Sender: owner-gsmp@psyton.com Precedence: bulk Reply-To: gsmp@psyton.com This is a multi-part message in MIME format. --------------5658F4853E9DE89BE2AAD91E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Putzolu, David" wrote: > > Was there some text lost when the recharter was posted? > Under the section titled, "IP Packet Switches" it talks > about coordinating with the MPLS group rather than talking > about control of IP packet switches. > > Thanks, > David Putzolu Thank you David, it was a cut and paste error. The updated version with edits and comments to date included: --------------5658F4853E9DE89BE2AAD91E Content-Type: text/plain; charset=us-ascii; name="re-charter6.txt" Content-Disposition: inline; filename="re-charter6.txt" Content-Transfer-Encoding: 7bit GSMP WG Re-Charter The base General Switch Management Protocol(GSMPv3) protocol is about to be submitted to the IESG with the request that it be made a proposed standard. Currently 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 current working group is responsible for completing the standardization of the GSMP protocol under the current charter. Future work includes: adding support for optical and TDM switching defining mechanisms for switch partitioning defining mechanisms for control of IP packet switches. - Support for Optical Switching The architecture of some optical switches makes the ability to remotely control the connection state of a switch important. GSMP has been designed especially for such remote control operations. GSMP is currently lacking in the specific semantics necessary for optical switches. The WG will add these capabilites to the GSMP specification. This work will be done in cooperation with the IP over Optics working group. - Support for other switching techiniques The WG will collect requirements and define solutions to support TDM, spatial and other switch types. This work will parallel the efforts currently underway in the MPLS group, i.e. Generic MPLS. - Switch Partitioning The current version of GSMP is designed to work with a single static switch partition. There is need to adapt GSMP to work with multiple partions in which resource allocation is dynamic and variable between the switch partitions. This will be achieved by adding capabilites to GSMP and by using available management tools, e.g. MIBS and PIBS. - IP Packet Switches Work is being done to create IP forwarding devices that are controlled by remote control plane controllers responsible for route determination. The GSMP working group will specify requirements and solutions relating to the control IP packet forwarding devices. This control will include configuration control, port management, QoS, and traffic engineering control and reporting of statistics. This will be achieved by a combination of added capabilities to GSMP and by using available management tools, e.g. MIBs and PIBS. - Continuing support of MPLS controllers 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. Milestones: - Document requirements for switch partitioning (Spring 2001) - Document requirements for control of optical switches (Spring 2001) - Document requirements for control of Generici MPLS switches (Spring 2001) - Document requirements for control of IP packet switches (Spring 2001) - Produce GSMP extensions, MIBs, and PIBs to support the requirements (Fall 2001) - Update base GSMPv3 as implementation experience mandates --------------5658F4853E9DE89BE2AAD91E-- From owner-gsmp@psyton.com Sat Oct 7 00:40:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20117 for ; Sat, 7 Oct 2000 00:40:25 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e974Sfw15027 for gsmp-list; Sat, 7 Oct 2000 00:28:41 -0400 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e974Se615024 for ; Sat, 7 Oct 2000 00:28:40 -0400 Received: from fwd05.sul.t-online.com by mailout02.sul.t-online.com with smtp id 13hlaa-0003HN-00; Sat, 07 Oct 2000 06:28:00 +0200 Received: from t-online.de (06103921725-0001@[62.226.207.108]) by fwd05.sul.t-online.com with esmtp id 13hlaQ-2KIpFYC; Sat, 7 Oct 2000 06:27:50 +0200 Message-ID: <39DEB3DD.712E8A81@t-online.de> Date: Sat, 07 Oct 2000 06:25:50 +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: Proposal for rework of charter References: <39D8CFFC.9B661906@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 Avri, that's fine for me. Thanks Joachim - - - - - - - - - - - - - - - - - - - Avri Doria schrieb: > The following is the current wording of the proposed re-charter of the > group. Before sending it on to the ADs, I am looking for WG consensus > on sending it on. Please comment within the next 2 weeks > (i.e., by 16 October) > > thanks > a. > -- > > Avri Doria > +1 401 663 5024 > > --------------- > GSMP WG Re-Charter > > The base General Switch Management Protocol(GSMPv3) protocol is about > to be submitted to the IESG with the request that it be made a > proposed standard. > > Currently 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 current working group is responsible for completing the > standardization of the GSMP protocol under the current charter. > Future work includes: > > adding support for optical switching > defining mechanisms for switch partitioning > defining mechanisms for control of IP packet switches. > > - Support for Optical Switching > > The architecture of some optical switches makes the ability to remotely > control the connection state of a switch important. GSMP has been > designed especially for such remote control operations. GSMP is > currently lacking in the specific semantics necessary for optical > switches. The WG will add these capabilities to the GSMP specification. > This work will be done in cooperation with the IP over Optics working > group. > > - Switch Partitioning > > The current version of GSMP is designed to work with a single static > switch partition. There is interest in having GSMP support multiple > partitions in which resource allocation is dynamic and variable between > the switch partitions. This will be achieved by adding capabilities to > GSMP and by using available management tools, e.g. MIBS and PIBS. > > - 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. > > Milestones: > > - Document requirements for switch partitioning (Spring 2001) > > - Document requirements for control of optical switches (Spring 2001) > > - Document requirements for control of IP packet switches (Spring > 2001) > > - Produce GSMP extensions, MIBs, and PIBs to support the requirements > (Fall 2001) > > - Update base GSMPv3 as implementation experience mandates From owner-gsmp@psyton.com Mon Oct 16 18:11:31 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17008 for ; Mon, 16 Oct 2000 18:11:28 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9GM0uS32500 for gsmp-list; Mon, 16 Oct 2000 18:00:56 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.11.1/8.9.0) with SMTP id e9GM0sT32497 for ; Mon, 16 Oct 2000 18:00:55 -0400 Received: (qmail 24287 invoked from network); 16 Oct 2000 20:36:25 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 16 Oct 2000 20:36:25 -0000 Received: (qmail 31169 invoked from network); 16 Oct 2000 21:59:00 -0000 Received: from unknown (HELO cplane.com) (unknown) by unknown with SMTP; 16 Oct 2000 21:59:00 -0000 Message-ID: <39EB796E.49B25CB0@cplane.com> Date: Mon, 16 Oct 2000 14:55:58 -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: Re: Proposal for rework of charter References: <638EC1B28663D211AC3E00A0C96B78A8065A4AFB@orsmsx40.jf.intel.com> <39DDFAEB.7B814EBA@nortelnetworks.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 Avri, Sorry for the delayed response. I've been away attending to family matters. All of the items sound reasonable, althought together it all sounds a bit ambitious. Jerry Avri Doria wrote: > "Putzolu, David" wrote: > > > > Was there some text lost when the recharter was posted? > > Under the section titled, "IP Packet Switches" it talks > > about coordinating with the MPLS group rather than talking > > about control of IP packet switches. > > > > Thanks, > > David Putzolu > > Thank you David, it was a cut and paste error. > The updated version with edits and comments to date included: > > ------------------------------------------------------------------------ > GSMP WG Re-Charter > > The base General Switch Management Protocol(GSMPv3) protocol is about > to be submitted to the IESG with the request that it be made a > proposed standard. > > Currently 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 current working group is responsible for completing the > standardization of the GSMP protocol under the current charter. > Future work includes: > > adding support for optical and TDM switching > defining mechanisms for switch partitioning > defining mechanisms for control of IP packet switches. > > - Support for Optical Switching > > The architecture of some optical switches makes the ability to remotely > control the connection state of a switch important. GSMP has been > designed especially for such remote control operations. GSMP is > currently lacking in the specific semantics necessary for optical > switches. The WG will add these capabilites to the GSMP specification. > This work will be done in cooperation with the IP over Optics working > group. > > - Support for other switching techiniques > > The WG will collect requirements and define solutions to support > TDM, spatial and other switch types. This work will parallel the efforts > currently underway in the MPLS group, i.e. Generic MPLS. > > - Switch Partitioning > > The current version of GSMP is designed to work with a single static > switch partition. There is need to adapt GSMP to work with multiple > partions in which resource allocation is dynamic and variable between > the switch partitions. This will be achieved by adding capabilites to > GSMP and by using available management tools, e.g. MIBS and PIBS. > > - IP Packet Switches > > Work is being done to create IP forwarding devices that are controlled > by remote control plane controllers responsible for route determination. > The GSMP working group will specify requirements and solutions relating > to the control IP packet forwarding devices. This control will > include configuration control, port management, QoS, and traffic > engineering control and reporting of statistics. This will be > achieved by a combination of added capabilities to GSMP and by using > available management tools, e.g. MIBs and PIBS. > > - Continuing support of MPLS controllers > > 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. > > Milestones: > > - Document requirements for switch partitioning (Spring 2001) > > - Document requirements for control of optical switches (Spring 2001) > > - Document requirements for control of Generici MPLS switches (Spring > 2001) > > - Document requirements for control of IP packet switches (Spring > 2001) > > - Produce GSMP extensions, MIBs, and PIBs to support the requirements > (Fall 2001) > > - Update base GSMPv3 as implementation experience mandates From owner-gsmp@psyton.com Wed Oct 18 10:57:51 2000 Received: from nighthawk.psyton.com (IDENT:root@[24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21206 for ; Wed, 18 Oct 2000 10:57:49 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9IEdeU06085 for gsmp-list; Wed, 18 Oct 2000 10:39:40 -0400 Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e9IEdaT06082 for ; Wed, 18 Oct 2000 10:39:39 -0400 Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Wed, 18 Oct 2000 15:04:06 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VC8R41F8; Wed, 18 Oct 2000 15:04:05 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.238]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4NZ3MRY1; Wed, 18 Oct 2000 16:04:04 +0200 Message-ID: <39EDADF6.7FE189A5@europem01.nt.com> Date: Wed, 18 Oct 2000 16:04:38 +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-list Subject: removing tdm labels? 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, there have been suggestions on this list to remove the tdm labels from gsmpv3 into a separate draft. the idea is to coordinate the separate tdm-draft with the work going on with generalized mpls. the gsmpv3 is very close a second last call but the tdm part is still broken. if there is consensus in the gsmp wg (this list) to move the tdm part out of the gsmpv3 document, the co-authors will update the gsmpv3 document and send it out on a last call together with the other three wg documents very soon. so do we have a consensus to remove the tdm part for now? ken (co-chair) From owner-gsmp@psyton.com Wed Oct 18 10:57:54 2000 Received: from nighthawk.psyton.com (IDENT:root@[24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21217 for ; Wed, 18 Oct 2000 10:57:52 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9IEqwc06158 for gsmp-list; Wed, 18 Oct 2000 10:52:58 -0400 Received: from apocalypse.org (IDENT:root@apocalypse.org [192.48.232.17]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e9IEqvT06155 for ; Wed, 18 Oct 2000 10:52:58 -0400 Received: from localhost (avri@localhost) by apocalypse.org (8.9.3/8.9.3) with ESMTP id KAA02102 for ; Wed, 18 Oct 2000 10:50:52 -0400 Date: Wed, 18 Oct 2000 10:50:52 -0400 (EDT) From: ad To: gsmp-list Subject: Re: removing tdm labels? In-Reply-To: <39EDADF6.7FE189A5@europem01.nt.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 Hi, The other co-chair here: I would like to clarify that we would not be adding the TDM content back into the spec sometime in the future. Rather, we are proposing an additonal document that will become a WG work item. And of course, this document will require a knowledgeable editor. I don't expect that either Kenneth or I is likely to edit this document. So, speak up now if you are against the proposal to remove the TDM content into its own document. And speak up if you want the editorship of the TDM doc that results. Thanks a. On Wed, 18 Oct 2000, Kenneth Sundell wrote: > > folks, > there have been suggestions on this list to remove the tdm labels from > gsmpv3 into a separate draft. the idea is to coordinate the separate > tdm-draft with the work going on with generalized mpls. the gsmpv3 is > very close a second last call but the tdm part is still broken. > > if there is consensus in the gsmp wg (this list) to move the tdm part > out of the gsmpv3 document, the co-authors will update the gsmpv3 > document and send it out on a last call together with the other three wg > documents very soon. > > so do we have a consensus to remove the tdm part for now? > > ken (co-chair) > From owner-gsmp@psyton.com Wed Oct 18 12:14:26 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23973 for ; Wed, 18 Oct 2000 12:14:23 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9IG1Jb06465 for gsmp-list; Wed, 18 Oct 2000 12:01:19 -0400 Received: from cplane.com (IDENT:qmailr@jersey.cplane.com [63.193.105.226]) by nighthawk.psyton.com (8.11.1/8.9.0) with SMTP id e9IG1IT06462 for ; Wed, 18 Oct 2000 12:01:18 -0400 Received: (qmail 30500 invoked from network); 18 Oct 2000 14:36:31 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 18 Oct 2000 14:36:31 -0000 Received: (qmail 13478 invoked from network); 18 Oct 2000 15:59:11 -0000 Received: from unknown (HELO texas.cplane.com) (unknown) by unknown with SMTP; 18 Oct 2000 15:59:11 -0000 Date: Wed, 18 Oct 2000 08:59:11 -0700 (PDT) From: Balaji Srinivasan To: gsmp-list Subject: Re: removing tdm labels? In-Reply-To: <39EDADF6.7FE189A5@europem01.nt.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 > >so do we have a consensus to remove the tdm part for now? > This sounds good balaji -- Balaji Srinivasan balaji@cplane.com Control Plane Technologies From owner-gsmp@psyton.com Wed Oct 18 19:09:22 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16203 for ; Wed, 18 Oct 2000 19:09:21 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9IN1nB08049 for gsmp-list; Wed, 18 Oct 2000 19:01:49 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.11.1/8.9.0) with SMTP id e9IN1mT08046 for ; Wed, 18 Oct 2000 19:01:48 -0400 Received: (qmail 19835 invoked from network); 18 Oct 2000 21:54:17 -0000 Received: from unknown (HELO dell100) (192.168.64.105) by d83b22c8.dsl.flashcom.net with SMTP; 18 Oct 2000 21:54:17 -0000 From: "tom worster" To: Subject: RE: Proposal for rework of charter Date: Wed, 18 Oct 2000 18:53:55 -0400 Message-ID: <002101c03957$11368ea0$e303010a@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.2911.0) Importance: Normal In-Reply-To: <39EB796E.49B25CB0@cplane.com> 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 From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of Jaroslaw Sydir > > All of the items sound reasonable, althought together it all > sounds a bit > ambitious. it's good to be a bit ambitious. it's being too ambitious that's not so good ;-) c u fsb From owner-gsmp@psyton.com Wed Oct 18 19:09:50 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16257 for ; Wed, 18 Oct 2000 19:09:49 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9IN6mj08085 for gsmp-list; Wed, 18 Oct 2000 19:06:48 -0400 Received: from thefsb.org (d83b22c8.dsl.flashcom.net [216.59.34.200]) by nighthawk.psyton.com (8.11.1/8.9.0) with SMTP id e9IN6lT08082 for ; Wed, 18 Oct 2000 19:06:47 -0400 Received: (qmail 19848 invoked from network); 18 Oct 2000 21:59:16 -0000 Received: from unknown (HELO dell100) (192.168.64.105) by d83b22c8.dsl.flashcom.net with SMTP; 18 Oct 2000 21:59:16 -0000 From: "tom worster" To: Subject: RE: removing tdm labels? Date: Wed, 18 Oct 2000 19:04:26 -0400 Message-ID: <002301c03957$c3e55ae0$e303010a@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.2911.0) Importance: Normal In-Reply-To: <39EDADF6.7FE189A5@europem01.nt.com> 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 From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > > there have been suggestions on this list to remove the tdm labels from > gsmpv3 into a separate draft. the idea is to coordinate the separate > tdm-draft with the work going on with generalized mpls. the gsmpv3 is > very close a second last call but the tdm part is still broken. > > if there is consensus in the gsmp wg (this list) to move the tdm part > out of the gsmpv3 document, the co-authors will update the gsmpv3 > document and send it out on a last call together with the > other three wg > documents very soon. > > so do we have a consensus to remove the tdm part for now? if we can't get workable text then removing it would be appropriate. c u fsb From owner-gsmp@psyton.com Wed Oct 18 23:25:47 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16322 for ; Wed, 18 Oct 2000 23:25:46 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9J3HuL08987 for gsmp-list; Wed, 18 Oct 2000 23:17:56 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e9J3HtT08984 for ; Wed, 18 Oct 2000 23:17:55 -0400 Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Wed, 18 Oct 2000 23:15:28 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VF2CD2J6; Wed, 18 Oct 2000 23:15:26 -0400 Received: from nortelnetworks.com (AVRI-1 [47.81.5.23]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZ1TPX; Wed, 18 Oct 2000 23:15:23 -0400 Message-ID: <39EE6741.1FD2D30@nortelnetworks.com> Date: Wed, 18 Oct 2000 23:15:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Avri Doria" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gsmp@psyton.com Subject: Re: Proposal for rework of charter References: <002101c03957$11368ea0$e303010a@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 agree that it is an ambitious work load, but it is the load that members of the group thought was warranted (even to the point of reminding me about work I had let drop off the list). And I assume it is a work list that the members of the group are willing to work on. When it gets submitted to the ADs, it will be reviewed by them and we may need to substantiate both the importance of the work and our ability to get it done. They may well decide that some of the work items are better left off the list for now or that some of the items may be better placed in another WG. As I understand the procedure, once the proposal is submitted they will review it, and if it is problematic they will come back to us before either rejecting the proposal or passing it on to the IESG/IAB. As the period for review has ended without any objections, I will be passing the proposed charter on to the ADs. Regards and thanks for the review and the comments. a. tom worster wrote: > > From: owner-gsmp@psyton.com [mailto:owner-gsmp@psyton.com]On Behalf Of > Jaroslaw Sydir > > > > All of the items sound reasonable, althought together it all > > sounds a bit > > ambitious. > > it's good to be a bit ambitious. it's being too ambitious > that's not so good ;-) > > c u > fsb -- Avri Doria +1 401 663 5024 From owner-gsmp@psyton.com Tue Oct 24 08:09:18 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01916 for ; Tue, 24 Oct 2000 08:09:16 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9OBuSt04789 for gsmp-list; Tue, 24 Oct 2000 07:56:28 -0400 Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e9OBuPH04786 for ; Tue, 24 Oct 2000 07:56:26 -0400 Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qnsgs000.nortel.com; Tue, 24 Oct 2000 12:48:15 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VPZV98JV; Tue, 24 Oct 2000 12:48:13 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.238]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VGPW2BPS; Tue, 24 Oct 2000 13:48:13 +0200 Message-ID: <39F57726.E7DCA469@europem01.nt.com> Date: Tue, 24 Oct 2000 13:48:54 +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: removing tdm labels? References: <39EDADF6.7FE189A5@europem01.nt.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 have not received any objections for removing the tdm labels from the gsmpv3 specification into a separate draft, so apparently we have reached consensus here. the next action will be to remove the tdm parts from the base spec and start working on the tdm draft. so if there are any tdm volunteers (i have seen one) contact me and/or avri. regards, ken "Sundell, Kenneth" wrote: > folks, > there have been suggestions on this list to remove the tdm labels from > gsmpv3 into a separate draft. the idea is to coordinate the separate > tdm-draft with the work going on with generalized mpls. the gsmpv3 is > very close a second last call but the tdm part is still broken. > > if there is consensus in the gsmp wg (this list) to move the tdm part > out of the gsmpv3 document, the co-authors will update the gsmpv3 > document and send it out on a last call together with the other three wg > documents very soon. > > so do we have a consensus to remove the tdm part for now? > > ken (co-chair) From owner-gsmp@psyton.com Thu Oct 26 15:48:17 2000 Received: from nighthawk.psyton.com (IDENT:root@psyton.ne.mediaone.net [24.218.13.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13408 for ; Thu, 26 Oct 2000 15:48:16 -0400 (EDT) Received: (from majordomo@localhost) by nighthawk.psyton.com (8.11.1/8.9.0) id e9QJbqt14075 for gsmp-list; Thu, 26 Oct 2000 15:37:52 -0400 Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by nighthawk.psyton.com (8.11.1/8.9.0) with ESMTP id e9QJboJ14072 for ; Thu, 26 Oct 2000 15:37:51 -0400 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 26 Oct 2000 20:34:15 +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 VV4X867S; Thu, 26 Oct 2000 20:34:14 +0100 Received: from europem01.nt.com (KSUNDELL [141.251.192.173]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VGPW2C58; Thu, 26 Oct 2000 21:34:13 +0200 Message-ID: <39F88764.B30C93B0@europem01.nt.com> Date: Thu, 26 Oct 2000 21:35:00 +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-list CC: "Avri Doria" Subject: Agenda items for San Diego 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, it's time to create an agenda for the next meeting. so please forward any agenda items you have to me and avri. regards, ken