Subject: RE: [GSMP] RE: GSMP WG Status

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 12 Dec 2003 01:09:04 +0100

And can you tell me when was the last time that you contributed anyting to
GSMP WG? I see no email postings from you to the WG list since mid-2002

You may be a new member who will now be posting great review comments
in the next few days. In that case I appologize for the above.

Thanks,
Bert 

> -----Original Message-----
> From: Wataru Imajuku [mailto:[email-masked]]
> Sent: vrijdag 12 december 2003 1:02
> To: gsmp
> Subject: [GSMP] RE: GSMP WG Status
> 
> 
> 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
> 
> >>GSMP WG members,
> >>
> >>I think this WG should be closed:
> >
> >As you and state below, I strongly disagree.
> >
> >>
> >>- 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).
> >
> >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.
> >
> >>- 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)
> >
> >The guarantee was that the next rev would go out with the 
> layer changes 
> >included.  not that the document would be finished in November.
> >
> >>- It cause two comments, but basically resulted in discussion of
> >>   GRMP.
> >>- 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 will be speaking with rest of IESG to close the WG.
> >>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.
> >
> >
> >
> >_______________________________________________
> >GSMP mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/gsmp
> 
> 
> 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 
> 
> 
> _______________________________________________
> GSMP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gsmp
> 

_______________________________________________
GSMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 12 Dec 2003 11:58:43 +0800

I also strongly disagree to close the group, especially at the moment. It's like the 
phone line is cut while we are actually talking about something via the phone. 
I think what we are talking about GRMP on this  list is highly related to GSMPv3 base spec., isn't it?
 
 Regards,
Weiming
 
> ----- Original Message ----- 
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Kenneth Sundell" <[email-masked]>; "avri" <[email-masked]>; "gsmp" <[email-masked]>
> Cc: "Wijnen, Bert (Bert)" <[email-masked]>; "Alex Zinin" <[email-masked]>
> Sent: Friday, December 12, 2003 12:58 AM
> > - We are now 1 month further, I have seen virtually NO reaction to it
> > > 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
> > > 
> > > 
> > > 
> > 
’0ùšŠX§‚X¬´dŒ>'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?‚É©