Subject: [GSMP] draft gsmp minutes

From: Kenneth Sundell <[email-masked]>
Date: Tue, 03 Dec 2002 11:38:14 +0100

Hi,

attached are the minutes from the last gsmp wg meeting in atlanta.
Please review and comment so we can make any adjustments before 
submitting them further.

Regards,
Ken

General Switch Management Protocol (gsmp)

Thursday, November 21 at 1300-1500
==================================

CHAIRS: Avri Doria <[email-masked]>
        Kenneth Sundell <[email-masked]>

Scribes: Jonathan Sadler and Scott Bradner.

Agenda bashing: nothing changed

WG Status:
----------
Kenneth went through the WG Status. The two requirement drafts have
been processed through last call. The RFC3292 has been split into
a number of drafts since it turned out to be too complex containing
all label and interface types. The division was agreed on at the 
Yokohama meeting. Two new drafts have been posted to suggest additional
Network Management of GSMP. Request has been made by WG to IESG for block 
on dynamic switch partition extensions to be removed. IESG requested report 
on implementations.
Many implementations and some deployments were reported. Scott (AD) will 
recommend to IESG to remove block in charter.

Requirement Docs
----------------
Avri reported on dyn-part-reqs-03 on behalf of Todd Anderson. Draft was sent 
in late, missing updated draft submission deadline. Copy has been made 
available on Avri's web site 
(http://www.cdt.luth.se/babylon/ietf55/draft-ietf-gsmp-dyn-part-reqs-03.txt) 
All changes requested of past version have been completed. Ready for WG Last 
Call - call to be made within one week of end of IETF 55 when draft appears
at IETF site.

Jonathan reported on gsmp-reqs-04. There has been two updates since Yokohama,
integrated optical burst switching requirements, revised sec 7.
Ready for new WG last call.

MPLS/GMPLS control/management items
-----------------------------------
Avri presented two issues with (G)MPLS control/management (also presented 
to CCAMP WG)

Issue 1: There are too many control paths to control a label switch
Some of the control paths are MIBS, CLI, GSMP, TL-1, Vendor Proprietary,
Service Provider Proprietary etc. No mechanism to coordinate the actions 
made on the same resource by two (or more) different controllers. Need 
"feedback" mechanism. 
Avri proposed that controller needs to keep state and report changes. 
Support receiving notification from the switch of any changes made.
Tested sense of the room; half of room said this a good idea, no one opposed.

Issue 2: Are MIBs the best way to control a label switch?
MIBs for MPLS showing rampant complexity. MIBs starting to challenge 
the bounds of scalability. GMPLS change may be too dynamic for effective 
management by SNMP.
Reconsider use of GSMPv3. Requested CCAMP review optical requirements drafts.

Concerns from the WG:
Scott B:How do we handle what can and cannot be changed by the other 
mechanisms?
Avri: Change can't be prevented, but GSMP better have a way to provide 
notification of change made.
Jon S: Dynamic Partitioning draft provides mechanism for controlling which 
resources GSMP is allowed to change.

GSMPv3 Specifications
---------------------
Recommendation at Yokohama was the division of the GSMPv3 spec into 
parts that dealt with general protocol, and specific applications.
Avri hopes to get unified look and feel.
Split of GSMPv3 doc into parts
- Base
- Packet Switch
- L2 Switch
- Optical
- TDM
Merge some of the parts? (Packet + L2) Seems to be support.
Question: do we need 2 or 4 other docs?
No comment
Ken: Makes sense to combine L2 and packet switch capable
Question: Should we combine optical and TDM?
Jon: Much in common. Both have to deal with layering - this should be done 
in a common way. Layering discussion should be in base spec.
?******** was this Jon or someone else?****************************
Jon : Optical and TDM have technology specific parts that can be in separate 
documents. Prefer to see as separate.
Question: What about use of GSMP for FORCES now is time to decide if this 
is a good idea. FORCES has sent out a request for candidate protocols.
This may also be outside of current GSMP charter.
No comments - will ask on mailing list, if no worker bees then let slide

Issue 1
Do tech values belong in base spec? ATM still there or put in 
technology-specific specs
Suggestion: Move tech-specific to separate specs, generalize tech-specific 
left in base specs.
Examples are TLV label types, ATM specific flags, port types, 
ATM Specific merge flag, failure response codes. 

Issue 2
There are also a lot of ATM specifics in the middle of the failure response
range. Should they be reorganized with technology independent base 
and technology specific issues? Do Failure messages need to be localized?
Scott B: Localization is not an issue for GSMP since protocol is just 
passing numbers - controller software should handle localization.
Avri: What about non-english error strings?
Scott: No need to i18n error strings because people do not see them.
Ken verified this (just numbers).
Scott: check to see if ATM is deployed if not then clean them up.

GSMP optical spec (Jun-kyun Choi)
The work was presented.
Question: Are there any requirements that have been identified for the 
optical spec that are not in the optical requirements spec? 
(Autonomous Protection and Restoration, Label formats)
Jon S: No, these issues are already captured in the optical requirements draft.
Question: Should there be coordination between GSMP and CCAMP
Jon S: Some of the things that GSMP will need will be different than what 
CCAMP needs due to node vs. network scope of operation.
Scott B: But where they are the same, they should be the same. 
(Jon S: Agreed)
Suggestion to start discuss on the ccamp mailing list.

Individual Drafts
-----------------

GSMP management (YoungWook Cha)

GSMP management updated.
Issue RFC 3295 is for provisioning of GSMP protocol, but not FCAPS
Can GSMP be used to support Network Management?
Where is network management function for supporting NM services for NE? 
Controller or Switch?
Useful? Should it be a GSMP working group doc?
Jon S: Concern that this is adding FCAPS to GSMP interface - lots of stuff 
that doesn't really matter to the controller.
Avri: However there is a need for management of the controller-side GSMP 
interface. Consequently, a MIB is needed.
Dave A: MPLS/GMPLS mibs are "incestuous" with NE and controller items in 
common places.  Coordination across the GSMP interface is necessary to work.  
Agent will probably have to be in both places
Malcom B: Interface should probably be lightweight, and not incorporate FCAPS.
Dave A: Need to have path up/down indication added to GSMPv3.
Avri: Is this captured in optical-reqs?
Jon S: If not, then it will be added.

Will discuss on list.

GSMP service mib (YoungWook Cha)
Options - new mib for service and events or add to existing mib.
MIB for GSMP Service needed for Configuration and Partition management.
Two approaches:
New GSMP Service MIB + GSMP MIB (RFC 3295)
Existing GSMP MIB + New GSMP Service MIB w/ Configuration & Partition 
Management + GSMP MIB (RFC 3295)

Report on G.805 (Jon Sadler)

Presentation about G.805. Include model of DS-1 service
ITU-T uses different layer concept.
Usage of the model for Optical and TDM specs to be discussed.

End of meeting