RE: GSMP WG Status

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
  GRMP.
- 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.

Thanks,
Bert 

> -----Original Message-----
> From: Kenneth Sundell [mailto:[email protected]]
> 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
> 
> 
>