JRA1-JRA3

From GEANT2-JRA1 Wiki

Contents

[edit]

Information

Date and Time: Tuesday 7 November 2006, 1400 hrs BST, 1500 hrs CEST, 1600hrs GR

The conf call is about defining a joint course of action between JRA1 and JRA3.

Gatekeeper: pgk.vc.dfn.de (for non-GDS members) 

   * GDS number: 004910091212314***4522

ISDN 

   * Dial: 0049 711 633 0190 or 0049 30 254 10800
   * Listen to the lady
   * Type conf-id 004910091212314***4522#

Backup - ?

[edit]

Actions

OK, MY to send pointers to the JRA4 page and to the LHC visualisation tool. JRA3 to identify if this fits with the picture.

  • Next conf call, 23 14:00 UTC, 15:00 CEST, 16:00 ET.
[edit]

Comments and questions (afterthoughts)

  • OK: What about the naming for an end-to-end service? It needs to be done centrally somehow, how will the names be allocated?
  • NS: To discover where the information related to a e2e circuits are stored, the Lookup service (LS) can be used. The request would be give me all the MAs where info are available for that e2e circuit, and the LS would return the list of MAs which have information about the e2e circuit.
  • JRA3 would need to define the authorisation model: who can do what? (it is useful for Maurizio to check if it can be incorporated or to make some suggestions).
  • JRA1 will be providing classes in java and functions in perl to allow services and visualisation tools to communicate with the AA infrastructure. (Mid 2007).
  • Security audit: one port open to everybody in the world to book a circuit may be of a problem due to the fact that those service can actually perform write actions on equipment. An intermediate box may be required in case the first one is being hacked.
  • NS to put in liaison AL (MCF) and MY and MH.
  • It is foreseen that retrieving data from all the MAs and compute on the fly is quite heavy and it would be better to start with a "centralised" tool (which isn't in contradiction with the distributed system as the data are still kept on different MA).
[edit]

Notes

We started by setting the scope:

  • JRA3 wants:
    • Identify in which domains there is a fault (troubleshooting).
    • Provide an e2e view of the circuit status to the users (As well as some derived statistics and circuit uptime over time)
    • Make use of monitoring information kept in the JRA3 system for traffic engineering.
  • The model used (for the two first objectives) seems so far pretty much similar to the one of JRA4.
  • JRA3 foresee that each network will retrieve the information from their own equipment, transform them to fit with the data model (i.e. edge-to-edge status information and inter-domain status information). That data would be used by a perfSONAR web-service (either the L2 status MA or the SQL MA). The data can then be accessed by the JRA4 visualisation tool from multiple domains archives.
  • JRA3 is currently not interested by a centralised tool storing the historical information, but would rather wish to retrieve the information from the different storage system and compute them on the fly. This implies that a discovery mechanism is needed to identify in which domain measurement archive are each bits of information constituting an e2e circuit is stored.
  • JRA3 Abstracted topological information and cNIS is in constant discussion with SA3 about it. cNIS keeps all the technology information and JRA3 keeps the abstract information as translated from cNIS. JRA3 abstract model will be coming from the cNIS. For a JRA1-JRA4 standpoint, we don't really care because it is transparent to us.
  • Metric composition: Concatenating metrics at L2 is very very challenging. There has never been any similar type of work done so far. Most important so far for JRA3 is the status. Bulk of effort on having the monitoring up/down working. JRA3 is however ready to provide help and feedback on the result of the work.
  • JRA4 has a similar problem to be solved in the year3 list. Want to have a degraded status. No solution. Min exchanges ideas and where want to go.
[edit]

Agenda

  • How to feed JRA3 data into perfSONAR?
  • How to extend the existing schema to JRA3 specifics (starting from the JRA4 schema)?
  • Use any demo installation of perfSONAR to tests JRA3 tools.
  • Discussion with NDL.
  • Abstract representation of the topology which is also used for monitoring data.
  • Does JRA3 has any visualisation needs where JRA1 could help?
  • Metric Composition
Retrieved from "http://wiki.perfsonar.net/jra1-wiki/index.php/JRA1-JRA3"
Personal tools