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