Network Management Complexities Dan Romascanu (Contributed in discussions by Andy Bierman, David Harrington, Juergen Schoenwealder) IESG Retreat Boston,

Slides:



Advertisements
Similar presentations
Light Enterprise Architecture
Advertisements

Connected Health Framework
Brief-out: Isolation Working Group Topic discussion leader: Ken Birman.
Photonic TeraStream and ODIN By Jeremy Weinberger The iCAIR iGRID2002 Demonstration Shows How Global Applications Can Use Intelligent Signaling to Provision.
2 Introduction A central issue in supporting interoperability is achieving type compatibility. Type compatibility allows (a) entities developed by various.
Connect communicate collaborate A Network Management Architecture proposal for the GEANT-NREN environment Pavle Vuletić, Afrodite Sevasti TNC 2010, ,
Timeliness, Effectiveness, Quality and the IETF Aaron Falk
CAPWAP BOF Control And Provisioning of Wireless Access Points James Kempf DoCoMo Labs USA Dorothy Stanley Agere Systems WAP!
Systems Engineering in a System of Systems Context
Tietojärjestelmien peruskurssi Software engineering Malin Brännback.
Enterprise development reference architecture (EDRA) -Deepti Seelamsetti.
An Operational Perspective on BGP Security Geoff Huston GROW WG IETF 63 August 2005.
The OSI Model A layman’s view of the internet. OSI Structure Application Presentation Session Transport Network Data Link Physical Each layer has a specific.
WIRELESS SECURITY DEFENSE T-BONE & TONIC: ALY BOGHANI JOAN OLIVER MIKE PATRICK AMOL POTDAR May 30, /30/2009.
Network Management Principles and Protocols
WPDRTS ’05 1 Workshop on Parallel and Distributed Real-Time Systems 2005 April 4th and 5th, 2005, Denver, Colorado Challenge Problem Session Detection.
The OSI Model A layman’s view of the internet. OSI Structure Application Presentation Session Transport Network Data Link Physical Each layer has a specific.
Modified by: Masud-Ul-Hasan and Ahmad Al-Yamani 1 Chapter 11 Network Management (Selected Topics)
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 3: Basing Software Development on Reusable Technology.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Integrated Security Model for SNMPv3 (ISMS) pronounced "is" "miss" David T. Perkins & Wes Hardaker 60 th IETF August 6, 2004.
Enterprise Architecture
1 Introducing the Specifications of the Metro Ethernet Forum.
LLDP-MED Location Identification for Emergency Services Emergency Services Workshop, NY Oct 5-6, 2006 Manfred Arndt
Ops Area Discussion Management Interface Refinement Thomas Nadeau Dan Romascanu IETF 84 - Vancouver 1.
LLDP-MED Location Identification for Emergency Services Emergency Services Workshop, NY Oct 5-6, 2006 Manfred Arndt
 Cloud computing  Workflow  Workflow lifecycle  Workflow design  Workflow tools : xcp, eucalyptus, open nebula.
AIMS Workshop Heidelberg, 9-11 March 1998 P717 & P805: SIRTE Study for Internet Roaming Throughout Europe Franco Guadagni - Telecom Italia / CSELT
Model-based Programmable Networks
1 Goals and objectives (1 slide only) Project(s): MIB Ad hoc, involves EMS-NMS (MEF 7.1) Purpose of the contribution: Provide the rationale behind starting.
Draft-shafer-netconf-syslog-00.txt Phil Shafer July 2006 IETF 66, Montreal.
Happy Network Administrators  Happy Packets  Happy Users WIRED Position Statement Aman Shaikh AT&T Labs – Research October 16,
SMI to XSD Translations IETF70 David Harrington. Agenda The Need The Approaches Comparisons.
OmniRAN Specification – Structuring the effort Document Number: Omniran Date Submitted: Source: Max Riegel
Abierman-nanog-30may03 1 XML Router Configs BOF Operator Involvement Andy Bierman
Proposal for device identification PAR. Scope Unique per-device identifiers (DevID) Method or methods for authenticating that device is bound to that.
DIME WG IETF 82 Dime WG Agenda & Status THURSDAY, November 17, 2011 Jouni Korhonen & Lionel Morand.
Abierman-netconf-mar03 1 NETCONF BOF 56th IETF San Francisco, California March 17, 2003 Discussion: Admin:
SNMP Simple Network Management Protocol SNMP Simple Network Management Protocol Haris Ribic.
Next Steps in Fuego Kimmo Raatikainen Principal Scientist Helsinki Institute for Information Technology
Process is continuously improving Have Definition of Done (DoD) DoD achievable within each iteration Team respects DoD The bottom line Delivering working,
July 16, Diameter EAP Application (draft-ietf-aaa-eap-02.txt) on behalf of...
Geneva, Switzerland, April 2012 Introduction to session 7 - “Advancing e-health standards: Roles and responsibilities of stakeholders” ​ Marco Carugi.
Sub-ip - 1 Blurring the Lines Between Circuits and Protocols: Plans to Re-Organize Sub-IP Technologies in the IETF Scott Bradner Harvard University.
Software Engineering, Lecture 4 Mohamed Elshaikh.
What makes for a quality RFC? An invited talk to the MPLS WG Adrian Farrel IETF-89 London, March 2014.
Do We Need a New Network Management Framework? David Harrington IETF66 OPS Area Meeting Montreal, Quebec, Canada.
OPSREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica Monday, July 26, 2010 Afternoon Session 2, 15:20– 17:20, Brussels Room Discussion list.
United States Department of Justice Achieving Information Interoperability and Business Agility The Justice Reference Architecture:
XML Schema for Accessing SMIv2 Data Models IETF69 Chicago BOF David Harrington.
Chapter 3  Network Implementation and Management Strategies 1 Chapter 3 Overview  Why is a network implementation strategy necessary?  Why is network.
Group member: Kai Hu Weili Yin Xingyu Wu Yinhao Nie Xiaoxue Liu Date:2015/10/
CAPWAP Arch-Draft Issues IETF 59, Seoul 4 March 2004.
MPLS-TP Packet Loss and Delay Measurement draft-frost-mpls-tp-loss-delay-00 Dan Stewart IETF 76 November.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 3: Basing Software Development on Reusable Technology.
IEC TC57 Smart Grid Task Force Ed Dobrowolski for Scott Neumann 16 June 2010.
Dissuasion, Working Group Scope and Deliverables Lou Berger Pat Thaler
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
Discussion - HITSC / HITPC Joint Meeting Transport & Security Standards Workgroup October 22, 2014.
SSHSM Issues David Harrington IETF64 ISMS WG Vancouver, BC.
Design Guidelines Thursday July 26, 2007 Bernard Aboba IETF 69 Chicago, IL.
Presentation at ISMS WG Meeting1 ISMS – March 2005 IETF David T. Perkins.
WREC Working Group IETF 49, San Diego Co-Chairs: Mark Nottingham Ian Cooper WREC Working Group.
Ch. 31 Q and A IS 333 Spring 2016 Victor Norman. SNMP, MIBs, and ASN.1 SNMP defines the protocol used to send requests and get responses. MIBs are like.
Automatic attachment of end stations and network devices Dan Romascanu Paul Unbehagen (draft-romascanu-opsawg-auto-attach-framework-00)draft-romascanu-opsawg-auto-attach-framework-00.
YANG Modelling and NETCONF Protocol Discussion
Convergence of Network Management Protocols
The need for better security considerations guidance
Enterprise Architecture EA Principles Revisions CIO Council Update
Network Architecture By Dr. Shadi Masadeh 1.
Presentation transcript:

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

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?

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.

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.

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

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...)