120131 NI workshop meeting minutes

Table of content

Participants

Minutes of the meeting

General discussion around network inventory

What is the primary purpose of a network inventory system

SL - to show the relationship between the physical- and logical topology (e.g. equipment and services) in relation to customers.
Primary used by NOC for troubleshooting but also planning and information gathering for maintenance or further design of the network

JF - register things and keep track of maintenance, where to start troubleshooting if things break.
Important to have a representation of the physical layer, so that we know what should work

VV - planning issues, to know what is available and how many customers we have

TK - be able to know which customers to inform when there are outages and know which customers are affected by planned maintenance

What specific functionality must be present

SL - Finding out who is affected when something break, e.g. going from physical knowledge about a specific part of the infrastructure to find out which customers are affected.
Finding out which part of the infrastructure a customer use, e.g. going from a circuit(service) ID a customer report to find where the physical infrastructure is that needs to be investigated.
Information needs to be automatically kept updated and current.
It must be easy to find information, both basic (e.g. searching through all relevant infrastructure for a service ID) and powerful (search for a group of "things" based on a specific set of requirements) searches are important.
It has to be easy to add and modify information that is not possible to obtain automatically.

JF - when doing something automatically, it is important to have a manual check before the information is saved into the network inventory. The same goes for equipment that is "removed" from the inventory. If a temporary solution is implemented it might not always be preferable to get that information into the network inventory.

VV - to show the reality or show what the reality should look like. Being able to log and comment changes is important.

JM - show everything but be able to know how the reality should look like.

JM - automatically import configuration from routers or services from the optical management systems.

JM - also be able to import some information from customer management system as that information is most likely not primarily in the network inventory.

KB - a function that can tell you what is missing if you want to establish a connection between A and C. E.g. hardware in equipment B to be able to deliver the capacity asked by the customer.

JF - agreed that the idea from KB is useful but should not necessarily be part of a Network inventory system. But information should be reusable, e.g. other system should be able to import information from the NI and calculate capacity planning. The system should also notice when there are changes, e.g. when equipment is replaced.

SL - clarified that the idea from KB idea was capacity planning and asked the participants how capacity planning was done in their organizations right now.

FS - capacity planning in UNINETT is a very manual process right now

JM - Funet use several separate sources to get the information needed for capacity planning, e.g. db for fibers, textfile for cdm channels, db for filter, tnms for the optical network

JF - FSKnet is in a similar situation as the already mentioned NRENs. Leadtimes becomes very long when everything has to be done manually. Leadtimes for getting fibers in the ground and ordering new equipment. To help keep track how equipment it could also be useful to including a stock information in the network inventory, i.e. equipment available but not installed.

MB - Capacity planning in NORDUnet is also mostly manual work correlating the different information sources we have.

KB - if you have a system that can show you the reality it might not be such a big step to automate capacity planning

JF - Another functionality that is important is to be able to manually add equipment and edit the information about that equipment or already inserted equipment

TK - extendability is important, if new equipment is used it needs to be possible to extend the network inventory to include new equipment and services

JF - people want to store different information and it needs to be possible to store different information on the same basic thing.

FS - have knowledge about fiber locations (maps), e.g. to be able to verify if a fiber will be affected by e.g. roadwork (digging).

SL - knowing where the fiber is located in the ground with high precision (preferably within a couple of decimeters to a meter) will become even more important as many NRENs have started buying and digging down their own fiber. TF-NOC discussed this at an earlier meeting (link to presentation)and there are some tools out there for this purpose, but some NRENs have also started developing their own tools to store this kind of information.

What do each NREN have in place today, if anything

SL - NORDUnet is using a combination of Editgrid, Telemator, NOCLook

• Editgrid is used as a network inventory for NORDUnet, but all the information is currently migrated from Editgrid to NOCLook instead.
  Updating Editgrid has mainly been a manual process it is an online spreadsheet tool (i.e. online excel)
  + automatic version control, online simultaneous use, most people are familiar with spreadsheets so not much time is needed before people can start using it.
  - manual updates, complicated to visualize relations between e.g. physical- and logical topology and how those relate to the customer
  Conclusion - Good for simple information but not powerful enough to show the relationships needed for a network inventory.
• Telemator is only used to store the information about the SUNET network
  + possible to build your own relations and store many different topologies, i.e. create your own models of the network and the equipment used
  - not intuitive user interface, very high learning curve to start using the software.
  Conclusion - Could be good if you keep it simple, i.e. only store fiber and basic equipment information. Modeling the equipment in detail (e.g. including transponders, muxes and interfaces) and including a hierarchical service model (several layers of logical services) quickly makes it very complicated to find information and even more complicated to update old information or input new information.
• NOCLook is the newly in-house developed network inventory. It has so far proved both modular and powerful enough to store the information needed for NORDUnet. However it is still under development and all the information and functionality needed for the NOC is currently not implemented or used yet.

JF - FSKnet use a windows configuration file database. The database store information about every router, serial numbers and IP-addresses on interfaces.

VV - In UNINETT there are three primary systems used to store network inventory data; zino, kind (manual data stored about customers, circuit, equipment) and NAV (administering LAN). Missing system for optical network and fibers. UNINETT have investigated if Telemator would be useful, no conclusion has been made on that topic yet.

JM - Many databases are used to store the information about the network and services offered by Funet, router configuration as master information repository. Funet rely on DNS and put meaning in names of equipment and circuits. Downside of this is that it creates a complicated naming policy and require some extra work to maintain, e.g. scripts used usually start with a DNS zone transfer.

JF - it might be a possibility to input e.g. customer information in RIPE and then extract that information. However this gives the disadvantage that we put the information somewhere outside our control, might also be hard to backup (extract) information.

What has been tried/looked at before, and what are the conclusions

SL - Commercial systems (that include the wanted functionality) have been to expensive and in most cases needs further development to cover all our needs anyway. As commercial systems usually have a closed code base external help is needed to modify the code, which adds even further cost. Hard to do a network inventory due to the lack of open interfaces to communicate with equipment and network management systems used in the network. One of the main reasons commercial systems have not worked out of the box and why it is hard to find a suitable commercial system.

VV - UNINETT have started to investigate different tools and also had internal discussion about what kind of information to store in the inventory, one observation is that it is hard to agree on a strict datamodel

TK - Funet is seeing a need for a network inventory, but have not started looking at any tools

What plans, if any, exists for putting such a system in place

NORDUnet are developing our own Network inventory and will continue to develop and use it.

Why did NORDUnet decide to start implementing a system from scratch

SL - No open source systems to build on were found and commercial systems were to expensive, might as well build our own. We are building it open source to hopefully help other in our situation to build something that will fulfill their needs.
Multivendor infrastructure puts very high demands (requirements) on the system. People have very different opinions and knowledge about how a system should work and what kind of information should be stored, retrieved and used. Trying to get to a consensus simply discussing the ontology for a certain network (infrastructure) can take weeks (if consensus is reached at all). We decided to build a system that was not based on what needed to be stored in the system or the relations between that information. Instead we decided to build a system that does not initially have to have a strict datamodel where the information that will be stored in the database is predefined, with the current database (node database instead of relational database) and our current loose datamodel this can be extended as the system grows.

VV - is there a risk that people put different things into the system (if it is to flexible)?

JL - there are constraints on the user, the administrator makes a form and the users is "restricted" to that form when updating information. The form can however be updated and modified as needed by the administrator over time.

Demo of the NORDUnet system from the user perspective

Presentation of the system

What needs to be done to bootstrap an "empty" system

Installation guide.
JL - Some modification needs to be done to the producers or new producers need to be written if the current one does not support the equipment the organisteach organization use.

What type of equipment is handled (automatically/manually)

JL - Currently information about hosts (servers), Juniper routers and Alcatel nodes are gathered automatically. Information about sites, fibers and passive equipment needs to be added manually.

What functions are present today, and what are the future plans

Usecases and roadmap
NI software development tracking

How is it used in day-to-day operations now and in the future

SL - Some usecases for the NOC are implemented, e.g. finding information about sites and how equipment in the network is connected (with which fibers). However the main functions to find information about the major part of the NORDUnet services and customers will be implemented later this year (first half)

TK - how does the google map visualization work?

JL - it is using java-scripts. The scripts fetch the google map information and render it locally. Using Google java library.

VV - useful to see how the network looked in the past

JL, SL - This feature has been asked by others in NORDUnet too, it will most likely be implemented later on.

AOB

SL - Participants of the workshop agreed that it would be interesting to follow up on this work. The workshops participants will look at the NORDUnet network inventory and "play around with it". Stefan will then follow up on the development and the workshop participants when Johan is back from vacation, i.e early March. Potentially we can have some more hands-on work at that time or help any of the participants that are interested in testing to setup the system themselves.