Fw: [GSMP] RE: GSMP WG Status

["Wang,Weiming" <[e-mail]>]

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)" <[e-mail]>
> To: "Kenneth Sundell" <[e-mail]>; "avri" <[e-mail]>; "gsmp" <[e-mail]>
> Cc: "Wijnen, Bert (Bert)" <[e-mail]>; "Alex Zinin" <[e-mail]>
> Sent: Friday, December 12, 2003 12:58 AM
> Subject: [GSMP] 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:[e-mail]]
> > > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/gsmp
>