Subject: [GSMP] RE: GSMP WG Status

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 11 Dec 2003 17:58:20 +0100

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-masked]]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: avri <[email-masked]>
Date: Thu, 11 Dec 2003 23:22:10 +0100

On torsdag, dec 11, 2003, at 17:58 Europe/Zurich, Wijnen, Bert (Bert) 

> I think this WG should be closed:

As you and state below, I strongly disagree.

>   promised back in the Vienna IETF also).

And there was improvement after Vienna, just not as much as you wanted.
There has been traffic on the list, and just becasue it was about GRMP 
is no reason to discount the conversation.

>   (albeit with a note that yet more changes are needed)

The guarantee was that the next rev would go out with the layer changes 
included.  not that the document would be finished in November.

> - Other authors have not lived up to any promises

The other document which is promised in promised for December,.  It is 
early to say that promise has not been lived up to.

> - I see no volunteering for the docs that have no editor/author.

There have been volunteers and the co-chairs are in the process of 
working out specifics.

> I cannot support the claim that this WG is actually a Working Group.

I think you are acting prematurely and I do not support your your claim 
that it is not a working group.  there are small groups and there are 
big groups.  there are quiet groups and there are noisy groups.  the 
work is progressing.

I am at least one voice in the working group who thinks that closing 
the group is wrong.  I hope there are other.

And I hope that they speak up.

Best Regards,

a.

---

From: Wataru Imajuku <[email-masked]>
Date: Fri, 12 Dec 2003 09:02:19 +0900

Hi, All

  I also strongly disagree with closing this WG.

  I think current  GSMP specifications lacks management feature of
switching hardwares, especially, if you think adaptation of GSMP to
  legacy-switches such as SDH-XC.

  Still, we have lot of work to do.

W. Imajuku@NTT

>There has been traffic on the list, and just becasue it was about GRMP is 
>no reason to discount the conversation.
>
>that it is not a working group.  there are small groups and there are big 
>groups.  there are quiet groups and there are noisy groups.  the work is 
>progressing.
>
>I am at least one voice in the working group who thinks that closing the 
>group is wrong.  I hope there are other.
>

I have changed E-mail address from April 1/2003!!!!
---------------------------------------------
Wataru Imajuku
NTT Network Innovation Labs.
807A, 1-1 Hikari-no-oka, Yokosuka, Kanagawa, Japan
Zip: 239-0847
E-mail: [email-masked]
TEL: +81-46-859-4315
FAX: +81-46-859-3396

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 12 Dec 2003 12:03:28 +0100

Bert,

We promised to take a look at the MIBs and actually started already but 
will now immediately stop the effort to get that problem solved.

Marcus

> - I see no volunteering for the docs that have no editor/author.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus