"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Thu, 11 December 2003 17:02 UTC

Received: from optimus.ietf.org ([]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09789 for <gsmp-archive@odin.ietf.org>; Thu, 11 Dec 2003 12:02:00 -0500 (EST)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUBt-0005KB-RB for gsmp-archive@odin.ietf.org; Thu, 11 Dec 2003 12:01:32 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBH1Tuc020466 for gsmp-archive@odin.ietf.org; Thu, 11 Dec 2003 12:01:29 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUBt-0005K1-L4 for gsmp-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 12:01:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09762 for <gsmp-web-archive@ietf.org>; Thu, 11 Dec 2003 12:01:21 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AUUBn-0000m9-00 for gsmp-web-archive@ietf.org; Thu, 11 Dec 2003 12:01:23 -0500
Received: from [] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUUBn-0000m6-00 for gsmp-web-archive@ietf.org; Thu, 11 Dec 2003 12:01:23 -0500
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUBd-0005Ds-L1; Thu, 11 Dec 2003 12:01:13 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUAv-000511-0q for gsmp@optimus.ietf.org; Thu, 11 Dec 2003 12:00:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09726 for <gsmp@ietf.org>; Thu, 11 Dec 2003 12:00:25 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AUUAt-0000le-00 for gsmp@ietf.org; Thu, 11 Dec 2003 12:00:27 -0500
Received: from auemail2.lucent.com ([] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AUUAs-0000lM-00 for gsmp@ietf.org; Thu, 11 Dec 2003 12:00:27 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com []) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBGxaS17358 for <gsmp@ietf.org>; Thu, 11 Dec 2003 11:00:00 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id <XRFGPBNF>; Thu, 11 Dec 2003 17:58:22 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6EBA@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Kenneth Sundell <ksundell@nortelnetworks.com>, avri <avri@psg.com>, gsmp <gsmp@ietf.org>
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, Alex Zinin <zinin@psg.com>
Date: Thu, 11 Dec 2003 17:58:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: [GSMP] RE: GSMP WG Status
Sender: gsmp-admin@ietf.org
Errors-To: gsmp-admin@ietf.org
X-BeenThere: gsmp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gsmp>, <mailto:gsmp-request@ietf.org?subject=unsubscribe>
List-Id: General Switch Management Protocol WG <gsmp.ietf.org>
List-Post: <mailto:gsmp@ietf.org>
List-Help: <mailto:gsmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gsmp>, <mailto:gsmp-request@ietf.org?subject=subscribe>

GSMP WG members,

I think this WG should be closed:

- The below message was posted to this WG list Nov 9th.
- We are now 1 month further, I have seen virtually NO reaction to it
- Alex and I have spoken with WG chairs at IETF with the implied
  message that I am ready to shut down the WG. 
- Your WG chairs defended VERY SERIOUS why the WG should continue
  and that WG pariticipation would IMPROVE imminently (such was
  promised back in the Vienna IETF also).
- But I do not see any of that happening.
- I do see that Avri delivered on the revision of the base spec
  (albeit with a note that yet more changes are needed)
- It cause two comments, but basically resulted in discussion of
- Other authors have not lived up to any promises
- I see no volunteering for the docs that have no editor/author.

I will be speaking with rest of IESG to close the WG.
I cannot support the claim that this WG is actually a Working Group.


> -----Original Message-----
> From: Kenneth Sundell [mailto:ksundell@nortelnetworks.com]
> Sent: zondag 9 november 2003 18:02
> To: gsmp
> Cc: Wijnen, Bert (Bert); Alex Zinin; avri
> Subject: GSMP WG Status
> Hi,
> As has probably been noticed, the GSMP group is not scheduled 
> to meet at 
> this IETF.  The reason for this is that there hasn't been enough 
> dialogue on the list to warrant a meeting.  It is not that 
> work hasn't 
> been continuing, it is that not enough of it has been done and not 
> enough commenting has been done.
> But, the IETF meetings are a time for updating status. So, it seemed 
> appropriate to put together a brief status report on the 
> status of the 
> group from the co-chairs' perspective.
> 1. Why GSMP
> But first, a recap of why we are doing this work.  The simple 
> answer is 
> to support GMPLS.  But this doesn't really answer the 
> question of why.  
> Why does GMPLS need the support?  As most know, GMPLS requires that a 
> routing/signaling control plane be associated with each switching 
> device.  In the original concept, this means that a single box will 
> contain both the control plane and data plane entities. GSMP 
> is meant to 
> provide the ability to decouple the control plane from the 
> data plane.  
> For new equipment, the tightly couple method of deploying GMPLS is 
> certainly a reasonable way for vendors to sell their 
> solutions.  Leaving 
> aside the issue of whether this is always the most 
> advantageous solution 
> for their customers, there is still good reason to decouple the the 
> control plane entities from the data plane entities.  If 
> GMPLS is to be 
> deployed in the near term on equipment which is already deployed in 
> customer networks, it will be necessary to find a way to deliver the 
> control instructions to the data plane in a de-coupled manner.  There 
> may be other ways to this, e.g. TL/1 messaging, CLI 
> messaging, SNMP and 
> perhaps, someday XMLconf.  GSMP offers a well defined and efficient 
> means of doing providing this control link for MPLS and, if we finish 
> our task, will provide an effective means of doing this for GMPLS as 
> well.  This info is included here because the main point, the 
> fact that 
> completing GSMP can aid in the deployment speed of GMPLS is sometimes 
> overlooked when deciding on the priority for work items.
> 2. Status of work items
> We have missed our remaining milestones.  These need to be 
> reworked and 
> to able to do that, we need to understand where we are at with the 
> remaining work and with group participation.
> 2.1. Requirements Specification Completed and released since the last 
> IETF as RFC3604.
> 2.2. Base Specification:  Avri Doria
> http://www.ietf.org/internet-drafts/draft-ietf-gsmp-v3-base-sp
> ec-04.txt
> This has gone through several revisions since the last IETF.  Most of 
> the requirements from  RFC 3604, have been met, though there is still 
> some explanatory text to be written.  there is, however, a deficiency 
> that has not yet been met that is not covered in the 
> requirements.  The 
> structure for defining and controlling the optical layers is still 
> open.  While this may be useful for other technology specific 
> areas, it 
> will be critical for the TDM Technology support.  More on 
> this below.  
> Once the layer information and updated text is produced, this 
> spec will 
> be ready for WGLC.
> 2.3 Packet Capable Switch Specification:  Kenneth Sundell
> http://www.ietf.org/internet-drafts/draft-ietf-gsmp-packet-spec-02.txt
> The draft has been updated to use the redefined base spec.  
> The Base Doc 
> + the Packet Switch document together are the functional 
> equivalent of 
> the existing GSMPv3 specification: RFC 3292.    This specification is 
> essentially done, but since it is dependent on the base spec it is 
> waiting for WGLC until that spec is completed.  There have 
> been reviews 
> of this specification on the list as of yet..
> 2.4  Optical Switch Specification:  Jung Yul Choi
> http://www.ietf.org/internet-drafts/draft-ietf-gsmp-optical-sp
> ec-02.txt 
> (-03 was sent to the list but didn't make it to the i-d repositories 
> before the deadline).
> This draft is in its third revision.   Many of the extension 
> techniques 
> generalized and  imported into the base draft originated in 
> the Optical 
> spec.  The Optical spec is being brought into alignment the 
> base spec.  
> Unfortunately this spec has not yet received extensive WG review.
> 2.5 TDM Switch Specification: Jonathan Sadler
> As of yet unavailable.
> 2.6 Review and possible update to RFC 3295 - MIB for Base and Packet 
> Capable - No owner
> 2.7 Review and possible update to RFC 3293 - encapsulation (as per 
> requirements in RFC 3604) - no owner
> 2.8 MIB to cover Optical Switch Options - No Owner, but could be 
> responsibility of team working on optical spec.
> 2.9 MIB to cover TDM Switch Options - No Owner, but could be 
> responsibility of team working on TDM spec.
> 2.10. MIB/PIB/XMLconf for Dynamic partitioning: No Owner
> A lot of work was done on a PIB and a MIB for this before the WG was 
> diverted into working on dynamic requirements specification RFC 3532.
> 3.0 Liaison with ITU-T SG15
> Avri was invited to attend the latest ITU meeting as a representative 
> from the GSMP group.  The ITU is currently reviewing 
> possibilities for 
> protocols that satisfy the CCI interface in the ASON 
> architecture.  GSMP 
> is seen as a strong candidate.  One deficiency is the support 
> that GSMP 
> offers for supporting Optical layering.  A requirements doc is 
> forthcoming from Jonathan Sadler explicitly covering this requirement 
> and making recommendations for its solution.  This document 
> was promised 
> during the IETF timeframe, though of course it can be submitted until 
> after the draft freeeze.
> 4.0 ForCES and GRMP
> Since the first days of ForCES there has been an assumption that GSMP 
> may offer a vehicle for satisfying the ForCES protocol requirements.  
> Investigating that possibility was also included in the GSMP 
> charter.  
> Recently Weiming Wang has produced a forCES candidate protocol called 
> GRMP.  GRMP is a derivative of GSMPv3.  Weiming and Avri have been 
> working together on reviewing the changes that might be necessary to 
> both the base and to GRMP in order to make GRMP fit as another 
> technology specific option to GSMPV3.  This work is not yet 
> completed, 
> but has gone far enough to indicate that the integration of the two 
> protocols is possible and would not be too onerous.  Of course it is 
> unknown at this time whether GRMP will be among the options 
> selected by 
> the ForCES WG.
> 5.0 Group Participation
> As has been discussed on the list WG participation or the 
> lack of it is 
> a real problem.  While there are 5 or 6 people who are working on the 
> specs or who do participate, the WG list is overly quiet.  We 
> need more 
> people writing specs and we need many more reviewing the new 
> specs and 
> commenting publicly.
> As Bert wrote to the list, this is a real problem in terms of 
> the being 
> able to continue the WG until we finish the work, this has become a 
> liability.  while the ADs have not yet threatened to close the group, 
> Bert has threatened to threaten.
> 6.0 Implementation
> Privately the WG chairs have been informed of several implementations 
> (>5).  Unfortunately none of them is public.  This is not terribly 
> helpful to fostering cooperation.  We should be shortly 
> getting to the 
> point where different versions are tested for interoperability.  This 
> can't be done if folks are unwilling to speak publicly about 
> their work.
> Ken and Avri
> Co-chairs GSMP WG

GSMP mailing list