1. Network Management Complexities Dan Romascanu (Contributed in discussions by Andy Bierman, David Harrington, Juergen Schoenwealder) IESG Retreat Boston, May 5-6, 2006

2. A prelude to this discussion The current management framework has a number of limitations: –device-centric (and very much focused on routers) –vertical (operator-management app to device) oriented –very much based on one 'push' model protocol while: –'horizontal' control protocols proliferate at all layers from sub-IP OAM to transport and application end-to-end signaling –vertical provisioning functions are developped trying to perform "auto- configuration" by reversing the SNMP client-server direction (or pull vs. push) The majority of these protocols are developped in the IETF, but in isolated islands or layers. A few in other SDOs that are taking over or re-using the IETF work. All re-invent again and again the same concepts, metrics, discovery procedures, etc. and face similar security threats that they solve in an inconsistent manner. Can we reduce the mess by trying to define a new management framework that is not stuck on a single vertical model and tries to bring together the different paradigms into a more versatile architecture, with identified components, a common discovery and security model? Is this achievable? Would it help?

3. More views about what’s wrong and what’s to be fixed Opinions expressed during the discussions – not necessarily reflecting mine or in synch with the recommendations –More comments and reactions in the speaker notes Using the right tool for a given task is a good thing. So multiple protocols for different management tasks is not at all a problem, except when you have to care about authentication and authorization issues. –no real value in harmonizing management protocols –value in the harmonization of how we deal with security To really improve the state of the art in network management, someone needs to throw in money to fund the development of good open source tools (and not protocol implementations) The lack of proper engineering practices is the root cause for the lack of success in network management standards. The lack of robust reusable building blocks which start simple and then evolve over time results in very few reusable parts. InetAddress is not enough Break the separation between people who believe they do application protocols (and they control protocols) and those who believe they do management protocols. The lack of communication between these crowds is also in the scope of problems that the IESG can actually address and perhaps even fix.

4. A few principles Do not stop existing development –Netconf, ipfix, isms must continue and be completed Talk with other SDOs –More, but not too much –Developing OAM protocols ITU-T ethOAM, IEEE 802.1AB (LLDP), IEEE 802.1ag (CFM), TIA LLDP-MED –Developing data and information models DMTF CIM, TMF NGOSS –Managing services OASIS –‘harmonizing’ ITU-T NGNMFG Do not place backwards compatibility on the top of the priority scale –‘ To make omelets, you need to break some eggs. To make standards, you might need to break some existing implementations.’ Be careful about the pace of change –If people decide they don't need a paradigm change to meet their needs, then apparently we misunderstood the level of demand for a paradigm change. Business people often prefer investment protection over wholesale infrastructure upgrades.

5. Possible endgame Better think in terms of a new management framework, rather than making one protocol the final game from the start –We may end by concluding that a one protocol solution is achievable, maybe this is desirable, but a more generic approach would be helpful. –Consider requirements from other OAM protocols - Diameter, RADIUS, CAPWAP, GSMP, GMPLS, 802.1AB, 802.1ag, etc. –recommend different protocols for different purposes (CLI for troubleshooting, Netconf for config, SNMP for automated polling, IPFIX for flow reporting, etc.) and then discuss how they can be used together more effectively (carrying syslog and snmp traps in netconf notifications, carrying MIB data in both Netconf and SNMP messages for different purposes), and so on. Build a common vision for securing management protocols –With the security area In parallel with efforts to continue and complete isms, develop evolution of syslog –Needs to start from an education process Management people to better understand security Security people to better understand management Define a standardized data model instance naming –core to identification of information from different vendors and different protocols, – key factor in the access control security problem. Outcome –‘Design Guidelines for Management Protocols’ Including implementation of security vision and model –Manageability Considerations for all developped protocols Experiment in the routing area Change the focus of the recommendations within the IETF –From ‘manage by SNMP’ to ‘manageability requirements’ –From ‘write a MIB’ to ‘define a management data model’ Fill in missing pieces –Together or within other areas or other SDOs –Standardized notifications –Data modeling

6. What then? Certainly this is a community task, not limited to the IESG or IAB only. Good? Bad? Don’t care? Ideas about defining and limiting the scope and framework of such a discussion (workshop, ops area, inter-area, iab, etc...)