MDM Pilot Success criteria

From GEANT2-JRA1 Wiki

• Have six RENs setting-up and offering a reliable MDM service (list of data to be provided in annexe B).
  • Success criteria: RENs having installed all the services (see list of metric and services in annexe) required for the pilot and having kept them running until the end of the pilot with an up-time of 90% during working hours.
  • Providing the following information: L3 link utilisation and link capacity, L2 status information (for those taking part to the LHC e2e circuit trial), show commands (looking glass like), three instances of the Hades (one-way delay)/BWCTL (TCP throughput) tool and a lookup service (functionality discovery)
• Have users to use the MDM service (perfSONAR web-service and visualisation) and solve two cases per domain thanks to dry runs.
  • Success criteria: Having each of the 6 REN’s NOC taken part to two exercises involving the use of the MDM service.
  • The dry runs will cover the simulation of problems between RENs and recommendation on how to use the tools to solve the problems. Their description will be provided in a later document.
• Have users and REN to validate the MDM service, the choice of (1) metrics, of (2) functionalities, of (3) perfSONAR web-services and of (4) visualisations and provided feedback and request for enhancements.
  • Success criteria: having collected feedback from at least the six NOCs where the MDM has been deployed (feedback from other NOCs is also expected) and PERTs.
• Test the service support structure (three levels) and the different scenarios.
  • Success criteria: Having dry runs to test the different scenarios of problems that may arise and having them pass. Those which failed will have to be investigated and replayed (may require procedure updates).
  • Success criteria: having had all the requests/incidents answered (support tests requests, but also the user and deployer requests) and no user request/incident lost by the end of the pilot.
  • Success criteria: Create support documentation and training material for the different levels of support so that it can be generalised during the prototype phase.
• SLA aspects: Gather service uptime information, the time to answer a request/incident (by L1, L2 and L3 support), and the time to close an incident. Those information will be used to be evaluate against an SLA that will be defined during the Pilot.
  • Success criteria: having kept the history of the information listed above.