General Switch Management Protocol (gsmp) Thursday, November 21 at 1300-1500 ================================== CHAIRS: Avri Doria Kenneth Sundell 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