OPSAWG, IETF 76, November 10th 2009 OPSAWG agenda 1 welcome & agenda bashing chair 2 WG document status chair 3 power monitoring Quittek draft-quittek-power-monitoring-requirements-00.txt 4 network configuration problem statement Tsou draft-tsou-network-configuration-problem-statement-00.txt 5 Virtual Network Management Information Model Okita draft-okita-ops-vnetmodel-01.txt 6 additional private address Azinger draft-azinger-additional-private-ipv4-space-issues-01.txt 7 reusable IPv4 address block Davies draft-davies-reusable-ipv4-address-block 2 WG document status, chair 4 RFCs published since the last IETF - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (RFC 5676) (43160 bytes) - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (RFC 5675) - Alarms in SYSLOG (RFC 5674) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (RFC 5706) Ron Bonica: Agenda item 6 and 7 might be contradictory 3 power monitoring, Quittek, draft-quittek-power-monitoring-requirements-00.txt Abstract This memo discusses requirements for monitoring the energy consumption and the power state of devices. It shows that these requirements are not covered by existing standards and proposes directions for new work items on this subject at the IETF. This is a requirement draft, instead of imposing a solution directly Many people, some standard bodies are currently working on this Monitoring is essential, even before energy savings Targets devices: routers, switches, middleboxes, hosts, Remote and aggregated monitoring (PoE switch, smart meter) There is a PoE MIB already. Battery based device Two things to monitor: Power state + notifications Power consumption during a period of time PULL and PUSH model PULL is necessary PUSH for notification is necessary PUSH model for continuous reporting: to be discussed A long list of existing standards, which might not be complete, showed Suggested actions: Define a power MIB as an extension of the ENTITY MIB PUSH model for continuous monitoring: maybe Harrington: why not trap? Juergen: too many traps First step: collect the requirements Questions: 1. Shall we include smart meters at home in our scope? 2. Shouldn't we start caring about other components of energy management? configuration, scheduling, control, ... Wes Hardaker: I wrote 3 enterprise MIBs for this! this is very much necessary issue 1: do the monitoring first. This could be faster. issue 2: different equipments have different capabilities. So a common management is difficult Juergen: is this feasible? Wes: possible, but the issues is with little devices that don't have the capabilities Monitoring is fine (just don't report), but configuration might be difficult Chair: Next step? Juergen: more feedback + post a MIB before the next IETF Hmm in favor of working on this: yes Nobody opposed 4 network configuration problem statement, Tsou, draft-tsou-network-configuration-problem-statement-00.txt Abstract In LTE (Long Term Evolution) bearer network, there will be a large number of network elements and service tunnels which will bring a lot of configuration work. The cost will be very high if all these work is performed manually. In order to reduce the workload of configuration to minimum, the following questions should be considered: o How to establish the DCN (Data Communication Network) connections automatically to avoid making configuration locally? o How to establish the DCN connections automatically between different vendors' network elements or how to pass through different service providers' network? o How to get network element and link information of the real network based on the information from network planning? o How to generate configuration scripts to setup network and service links automatically in order to reduce configuration design workload. LTE is a typical scenario which involves large number of network elements and service tunnels. Other scenarios like IPTV may also have network configuration problems discussed in this document. This document discusses problems related to lightening network configuration workload and better transmission tunnel setup between network elements and NMS (Network Management System). Tina come here to find for a solution, as she doesn't have one in mind. Typical LTE network scenarios: 16000 base stations and 20000 network elements and up to 200K service tunnels 3 problems - a lot of work to design the configuration scripts - some base station addresses and links can not be acquired - without a DCN connection, the initial config scripts can only be input locally or use MODEM/CF cards Automatic generation of network configuration - reduce the workload - network planning tools can generate configuration scripts, but there are also many changes Network configuration problem - how to establish the DCN connections automatically? - etc... Questions in the room Maybe 5 persons read the draft Dan Romascanu: what do you think would be the IETF action item? Any concrete plans? Tina: something such as the discovery protocol I only have the problem, not the solution Hideki Okita: relationship with the 3GPP specifications? Tina: I'm from a vendor, I don't know about those 3GPP specifications Chris Liljenstolpe (Chair): problem given to you by your customers? Tina: yes Juergen Quittek: targeted as LTE, not general solution Why not in 3GPP where they focus on LTE? Juergen: whatever we do, should be synchronized with 3GPP, or it will not be used Dave Harrington: basically the same question, why the IETF? The IETF rules: the WG that create the technology should have the data model to manage it. Chris Liljenstolpe (not WG chair) : a lot of issues you raised are solved for IP Maybe there are things that can reused... Dave Harrington: recommend that the draft is updated, and discuss why the IETF should do it Tina: I just bring the problem Mehmet Ersue: 3GPP has no focus on IP network management, as IP is underlying We are in charge of the IP network. Please detail your draft with some proposals... which could be standardized at the IETF Hum: no volume either way (in favor or opposed) Let's bring it to the mailing list 5 Virtual Network Management Information Model, Okita, draft-okita-ops-vnetmodel-01.txt Abstract Virtual switches on server virtualization platforms cause a problem in managing data center networks containing several hundred switches. Accordingly, a management information model for the network structure of data center networks containing virtual switches is proposed. The proposed model consists of a physical layer (which represents connections between physical switches) and a virtual layer (which represents connections between virtual switches). These layers also represent the association of the virtual switch with the corresponding physical switch. The model shortens the virtual LAN (VLAN) configuration time taken by operators of data center networks by a maximum of 35%. This result shows that the proposed model is effective in reducing the management time of data center networks containing virtual switches. Second time presentation. IETF has more experience of standardization of network related models than IEEE or DMTF Why information Model? Data models like MIB or XML can be easily developed from a information Model Two standard MIBs: Relationship to the ENTITY-MIB LLDP-MIB IEEE802.1.AB Issues 1. missing the relationship between physical and virtual entities 2. virtual connection management Solutions: VirtualNode object and VirtualInterface object enable the virtual connection management Summary: Will update the draft based on the comments after the Hiroshima meeting Propose the standardization of a new virtual network management Questions Interest? OPSAWG? Extension to the ENTITY MIB? Juergen Quittek: agree with the UML model. Different similar problems: MPLS, etc... We need a labeling of entity (interface, nodes). That might be enough Dan Romascana (contributor): Juergen is right. This is a management station problem Tunnel, MPLS, etc... Most of the information is already there. Information document: how a NMS can get all this information No concrete work to be standardized 6 or 7 persons read the draft Hum: light hum in favor, no hum against Let's take it to the list. 6 additional private address, Azinger, draft-azinger-additional-private-ipv4-space-issues-01.txt Additional Private IPv4 Space Issues Abstract When a private network or internetwork grows very large it is sometimes not possible to address it using private IPv4 address space. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. 7 reusable IPv4 address block, Davies, draft-davies-reusable-ipv4-address-block Proposals 6 and 7 are opposed. Please contribute on the mailing list.