11th NMRG meeting Schloss Osnabrueck, Germany September 15-16, 2002 List of participants: 1. Randy Bush (ATT, USA) IETF Area Director 2. Olivier Festor (Loria, France) 3. Mario Jeckle (Daimler-Chrysler, Germany) W3C Web Service Architecture WG 4. Jean-Philippe Martin-Flatin (CERN, Switzerland) 5. Dave Perkins (Riverstone, USA) 6. Aiko Pras (University of Twente, Netherlands) 7. Juergen Schoenwaelder (University of Osnabrueck, Germany) 8. Phil Shafer (Juniper Networks, USA) 9. Frank Strauss (Technical University of Braunschweig, Germany) 10. Margaret Wasserman (Windriver, USA) 11. Bert Wijnen (Lucent, Netherlands) IETF Area Director 1) Opening ---------- A number of guests were invited for this meeting. To know each other, the meeting started with the roll-call. Minutes: Frank and Juergen agreed to take notes, Aiko agreed to later turn these notes into meeting minutes. (Remark: after the meeting also Margaret gave her notes. Although the meeting minutes are based on Frank, Juergen and Margaret's notes, certain details have been omitted. Since all notes have been distributed over the NMRG mailing-list, readers interested in every detail should take a look at these notes.) Purpose of the meeting: At the last IRTF meeting in Pisa we discussed future directions in NM. At that meeting we agreed to organize a next meeting to discuss the merits of using web-services / XML for NM. In the meantime, the IAB has organized a workshop to discuss future directions for NM. At that workshop it was concluded that we should further investigate the use of XML for management. In addition, a BOF was organized at the Yokohama IETF to discuss the use of XML in device management. The purpose of this meeting is to discuss the advantages of using web-services / XML for management. Agenda: It was agreed to concentrate the first day on web-services, and the second on XML. 2) WEB-SERVICES --------------- Several topics related to web-services based management were discussed. Although we took the freedom to jump from topic to topic, the main conclusions of the discussion are summarized below. 2A) Presentations ---------------- To make the other attendees clear why someone believes that web- services will (not) become important for Internet management, every attendee was requested to give a short presentations. - Juergen: Does not believe in Web-Services in the interface between devices and management applications, because of complexity and performance issues and not really addressing the requirements such as transactions across devices. - Randy: Believes the problem is ill defined and Web-Services is more a technology looking for a problem. Randy thinks that distributed database technology has probably more in common with the real requirements. He also has concerns that UDDI has serious security issues. - Margaret: Margaret talks about layers in management systems and there might be some use of Web-Services at the higher layers. But they seem to be overkill at the management application - device interface. Web- Services might be useful for higher layers (such as service management layers). - Phil: Web-Services is too complex for the device interface. He wants to have a connection oriented, persistence technology. SOAP is considered too complex and has too many options. But in the end, he wants any RPC technology. - Mario: Mario says it was already hard to keep SOAP specifications not growing even faster. Web-Services are intended to bring business applications together and he believes Web-Services are easier to integrate than CORBA, DCE, ... - Bert: Bert is worried about interoperability, especially since XML is so easy to extend. He wants people to experiment first before actually trying to standardize something. He also does not think that Web-Services address the requirements. - Dave: Dave talks about the different viewpoints of mgmt app developers and device implementors. He believes that there should be different schemas for data exchange between management applications and between management applications and devices. In case of communication to the devices, he does not believe in XML and he believes that the schema must be forced (as with MIBs) and not provided individually by the devices (as with WSDL). - Frank: Looking at configurations in an XML document format is a big win. An XML advantage is that there are many tools readily available, you just have to use them. It is easy to plug things together while, with SNMP, many things have to be written from scratch. Also need to move to an RPC style interaction mechanism. - Olivier: Web-Services can play a role between management platforms and within management platforms. Representing configuration as XML documents is really helpful. Representation of meta data etc. is all available with XML. Believes that representation of additional semantic (e.g. relationships via RDF) is a big step forward. Olivier believes security is still missing. - Jean-Philippe (J.P.): SNMP is good for monitoring resource constraints devices. Today we need to do more. Open management exists only for monitoring resource constraints devices. For configuration J.P. proposes to use XML. Within management systems and between management systems, you are in a distributed system and you can use CORBA, Web-Services, ... (1) Web-Service standardization is faster then CORBA standardization (2) Better separation of protocol and data ... (3) Web-Services is trendy and should be used in/between management systems - Aiko: SNMP will not be further developed substantially. Distinction between networks and applications starts to disappear. SNMP is not going to solve the bigger problems (e.g., configuration management, higher-level service management, integration of network-, service-, and desktop-management). Web-Services is being implemented and will be available in every system and application. Network management or monitoring is not different than any other distributed applications. Web-Services will be universally available and easy to use. 2B) Scenarios ------------- A number of scenarios were identified in which web-services could play a role. To guide that discussion, the following picture was drawn: (--) ^ (DB)--- / \ NMS System (--) +---+ (High-level transactions) / \ / \ +---+ +---+ | | | | EMS System +---+ +---+ (Vendor-specific translation) | / \ | / \ +--+ +--+ +--+ | | | | | | Elements +--+ +--+ +--+ The picture allows to identify multiple layers of management: 1. Management of individual Elements: - Monitoring - Data collection (via polling or push model) - Exception Reporting - Fault management - Configuration - Initial Configuration - Modification - Northbound reporting (to higher layer managers) 2. Management of multiple Elements 3. Communication between (EMS/NMS) Managers 4. Integration with internal infrastructure: 5. Integration with external infrastructure: There was agreement that web-services will particularly be useful at the higher layers of the picture. There was disagreement whether web- services will also be useful for element management. We agreed that, although web-services might be reasonable for 4/5, these scenarios are outside the scope of this meeting. 2C) Key technologies for web-services ------------------------------------- With the help of Mario the following conclusions were drawn: SOAP - MUST UDDI - MAY sometimes be useful WSDL - SHOULD (closely related to XML Schema) WS Architecture - we do not know that this time XML RPC - NOT (is an alternative, and will be discussed tomorrow) XML Schema - SHOULD (closely related to WSDL) LDAP - NO (implementation detail) HTTP - Not necessarily (SOAP is transport independent, we need SOME transport protocol) DBMS - NO It is noted that there is a political issue with UDDI. MS and IBM have handed over UDDI to Oasis, so W3C is not doing its own work on discovery. The W3C architecture group will still need to reference a discovery mechanism. 2D) Granularity of WSDL primitives (operations) ----------------------------------------------- The following basic approaches were identified: 1. Coarse granularity, defining very simple WSDL methods. Examples of such methods are: Get and Set (WBEM of the DMTF takes this approach). The management data should be defined in XML schema. 2. Medium granularity, in which we have more extensive, but still a generic set of methods. Examples of such methods are: GetTable, Add, Delete, Action (a la CMIP), GetConfig, SetConfig (AKA dump & restore). Also in this case management data should be defined in XML schema. 3. Fine granularity, in which we define object-specific methods. Examples of such methods are: GetRoutingTable, GetIfInOctets. In this case there is no need for additional XML schema. One issue that influences the choice between these approaches, is the possibility to support vendor extensions and interoperability. With (1) and (2), vendor extensions can be accomplished in the XML schema. With (3) vendor extensions require extensibility features in the WSDL definitions. The question was raised how much interoperability we want to encourage. There is a trade-off between flexibility and interoperability. With XML schemas, extensibility is possible since you can add new stuff in new namespaces and you can mix several namespaces within an XML document. There was some feeling that we should allow extensibility of the data model (1 and 2), but not extensibility of the commands/operations (3). But even in case of approach 1 and 2, it may be complicated to extend the XML schemas underlying the WSDLs. For example, how to deal with major changes? What about versioning? Although versioning is part of the architecture, it will not happen to be in WSDL before 1.3. 2E) Transactions ---------------- For configuration management it is important to have support for transactions. The question was therefore raised whether WSDL includes support for transactions. Mario answered that that is not the case; transaction handling (called orchestration in W3C-speak) is defined as part of some proprietary protocols. Originally IBM defined WSFL, and MS XLANG. IBM and MS recently joined both proposals: BPEL. Within OASIS, there is a proposal for transaction support. Also W3C is thinking about establishing a working group on transactions. 2F) Instance data ----------------- In case of course granularity, the operations are defined in the WSDL file and the (management) information is defined in XML schema. Olivier brings up the issue of selecting specific information within an XML document, for example to isolate information related to a specific object instance (such as row 3 of the ifTable). One way of doing this would be to use XPATH (XQuery may also be possible). With XPATH, indexed information can be accessed using predicates. If, for example, we have: 1 ... 3 ... 4 ... The XPATH expression: system/interfaces/ifTable[row=3] returns the attribute values of that row (if we want its definition, we can use @row). XPATH also allows to specify multiple elements in the predicate part. 2G) Performance --------------- Since XML is verbose, web-services may require a non-trivial amount of bandwidth. If compression is used, bandwidth consumption can be reduced at the price of CPU cycles. Mario informs us of a study that shows that SOAP (with compression) performs well, provided the document is not too small (compression factors of 1:8 till 1:20 seem possible). Compared to SNMP, Dave is willing to accept a small factor of bandwidth increase (e.g. 2) but not a magnitude (e.g. 10) or more. Frank regards increased bandwidth and delay for infrequent operations to be tolerable, but not for small frequent requests/responses. Randy points out that, especially in case of out-of-band networks for management, bandwidth may remain to be a bottleneck. Compared to SNMP (over UDP), web-services have the advantage that more data can be packed into a single message. As a result, less interactions may be required, reducing the total time to retrieve bulk data. Although this may be an advantage in many cases, configuration management, which is one of the main topics to be solved, is usually not time-critical. Compared to SNMP, all attendees expect that web-services will put a stronger load on the system (unfortunately there are no studies that compare both approaches). In case of manager platforms, it may still be cheaper, however, to increase the processing power of that platform, compared to the costs of increasing bandwidth. In case of network elements, it may be expensive or even impossible to upgrade processors. The meeting felt that CPU consumption will remain to be an important issue. >From a performance point of view, probably the most problematic issue is the serialization/deserialization of XML documents. The code for DOM, which is often used for this purpose, may be 10 times bigger than that needed to store the XML document. Therefore, never keep a DOM tree if you want to be scalable, use SAX or a streaming API (adaptive DOM). The attendees ask whether there are comparison studies between BER and XML encoding. We feel that there is a lack of studies in this area. 2H) Ease of implementation -------------------------- Bert tells that one of the main issues with SNMP is the complexity of implementing MIBs in the devices. SNMP MIBs are not implemented immediately when new features are implemented in products, CLI is implemented instead. MIBs are then implemented very slowly, as vendors have no incentive to implement them promptly. How will WS relate to this? Aiko reports on some experiments to implement a Get method in WSDL. After a learning curve of one to two weeks, things are relatively simple to implement (both manager and agent). Only need a few lines of code in the server and client; everything else is libraries, etc. The question was raised whether developers can be brain washed so that the first thought when they have a new feature is to write an WSDL interface for it? Aiko thinks there are better development tools available for Web-Services, compared to SNMP tools (especially at the manager side). 2I) Security ------------ Randy mentions that we should not forget security and asks whether Web-Services helps to address these problems. Does XML digital signature address the requirements? what about XML encryption? It was noted that the signature and encryption header is used to identify identities that send messages. 3) XML ------ At the second day XML was discussed. We primarily discussed experiences of attendees in this area. 3A) Juniper ----------- Phil explained the Juniper approach. Their internal management daemon (mgd) is completely based on XML. The CLI talks XML to the management daemon, using a rendering engine. It is interesting that the CLI use many pieces of the XML code. The communication is based on an XML RPC mechanism, where the whole session maps on a single XML document. Juniper provides DTDs, but only because they were once needed, XML schema is the way to go. The management daemon may pass calls to other daemons via XML. There is an SNMP agent, which does not share any code with the XML daemon. Phil shows some examples and explains the internal workings of Junoscript. Juniper had originally a CLI which was not based on XML. Internally everything is based on meta-data, which drives the rendering and other things. Adding parsers is therefore doable, without having to touch all parts of the system. Juniper uses a self-written pull-based parser, which implements a subset of XML. Margaret thinks that it is a good idea to use a restricted set of XML in order to put parsers into memory constraint systems. Margaret wants to investigate what element of XML make parsers too memory hungry. 3B) Lucent ---------- Larry Menton (researcher at Lucent) sent some slides, and presented them via speaker phone. Larry has worked at Lucent Tech for 22 years, involved in NW management, agents and other data networking products. [See slides for details of presentation.] 4) How should the IETF proceed? ------------------------------- Discussion of what type of work makes sense in this space for the IETF to do. Bert: There are a lot of things that aren't standardizable. So, is there anything left here that makes sense for the IETF to standardize? Randy proposed to differentiate between trying to standardize the CLI (in XML, text, etc.) and trying to standardize some mechanisms by which you configure the universe. How do we download the configuration in XML? What is our transport? There are syntax primitives and transport for configuring, and then there is the syntax/semantics for the actual configuration information. Randy believes that it is important to get agreement on the first part, not on the second. There seems to be a feeling in multiple groups that we should standardize the transport & the operations, but not the structure of the data (i.e. schema). The following picture appeared: +------------+ | Content | -----> Should remain vendor-specific??? +------------+ --+ | Operations | | +------------+ | | RPC Mech | +--> Interesting parts to standardize. +------------+ | (We also understand how to do this?) | Transport | | +------------+ --+ For instance, we could use (from bottom up) HTTP, SOAP and WSDL. In that case we might have to standardize a set of WSDL operations. Aiko proposed to standardize operations like: get/set/create/delete/dump/restore. Phil proposed: create/delete/update/delete + rollback/lock/unlock (update has replace/merge modifiers). 5) What will the IRTF do with the results of this meeting? ---------------------------------------------------------- A key issue will be to create prototypes and make these available to each other. Some people (Olivier, Aiko) volunteered to proceed in this area. J.P. and Mario noted that it might be useful to write a requirements document and send it to the W3C. Such document should detail what the requirements are for the WS architecture to be used for network management. J.P. is willing to co-author, but can't write it alone. Bert would like to see someone work on defining high-level operations that we need. Aiko proposed that the NMRG holds a meeting to determine what higher-level semantics you need to manage a network (as opposed to a particular device), discuss transactions, etc. 6) Closing ---------- The meeting was closed at 16:30