JRA1-JRA3 2
From GEANT2-JRA1 Wiki
Contents |
[edit]
Information
Date and Time: Wednesday 29th of November 2006, 1400 hrs BT, 1500 hrs CET, 1600hrs ECT
The conf call is about refining and clarifying the inter-action between JRA1 and JRA3.
Gatekeeper: HEAnet gatekeeper - 003530110050738.
[edit]
Actions
- Dave to modify the 2nd picture he sent.
- Roberto to start follow-up with Internet2 and ESne on the global naming. (Joe should own the task)
- Matthias, Mark and Andreas to clarify the different "global names" as it has been stated that people were talking about different things, but the distinction wasn't obvious.
- Avoid future confusion when communicating outside the activities, do not speak about JRa4 schema, but rather about L2 status perfSONAR schema (or perfSONAR topology schema).
- Nicolas to send to Dave pointers on the attribute discussion.
[edit]
Notes
Attendence: Andreas, Matthias, Mark, Stephan, Martin, Nicolas, Dave, Roberto, Otto, Loukik
- Dave showed the global picture for JRA3
- Action: modification of the picture to reflect the fact that the visualisation don't have necessary to go through the MA, but can access straight away the web-service (MA or MP). But it should be stressed that the historical function is essential for JRA3, so that if a MP is used, the data should be pushed into a MA somewhere to keep the history (otherwise it will get difficult to troubleshoot).
- JRA3 and JRA4 concepts can work in parallel, no problem.
- Advantage of the situation, a NREN not taking part to the BoD don't have to deploy anything else than a MP/MP to provide the data.
- Disadvantage, the NRENs providing two type of services (CBF and BoD) will extract about the same data and send them to two different systems. (a longer term solution may be to have the inter-domain manager also taking care of the CBF data for the NRENs having the CBF and BoD services).
- In addition, the multi-domain manager stores the information as well as the MA and MP+MA serivce, there is some replication of the data. A longer term action would be either to add a perfSONAR web-service interface to the inter-domain manager.
- Matthias mentioned that the XML example in the document sent by Dave is OK, but global name is missing.
- Dave: two parallel naming schemes (JRA3 and JRA4). Do we merge those?
- Action: RS to launch the merging of the naming scheme at the next I2 tech meeting and ask to Joe to push the discussion forward.
- Martin: the naming scheme won't have any impact on the schema.
- Matthias and Mark: performing some checks on the names.
- Action: Matthias, Mark and Andreas to clarify the different "global names" as it has been stated that people were talking about different things, but the distinction wasn't obvious.
- Action: to avoid future confusion when communicating outside the activities, do not speak about JRa4 schema, but rather about L2 status perfSONAR schema (or perfSONAR topology schema).
- Mark and Matthias mentioned that JRA4 visualisation tool can be used to display JRA3 BoD status information.
[edit]
Agenda
- What is the big picture? (which pieces coming from where, which ones are missing) - Dave to present a drawing hilighting the different pieces - similar to the one from the JRA4 document).
- What is missing in the schema? (Base on Dave Investigation -> JRA1 to extend it).
- How is "globalName" defined in the schema?
- JRA3 has both domain-specific and interdomain names for each of its elements. Can or should either of these be reflected in the XML message to the MP/MA? If not, do we need to take any extra action to map each link to its JRA3 name?
- On both of these, does "nmlt2:name" describe a domain-specific link ID? Could "globalName" be the JRA3 interdomain link address? (We use IPv6 addresses to differentiate each element.)
- I think that since we can share the data export as far as the MP/MA, we should be able to share visualisation tools as well. Is this agreed? Can I reference work on visualisation tools already done in the document?
- Does the JRA4 visualisation tool fit the purpose? What is missing?
[edit]
Last call Actions and afterthoughts
- OK, MY to send pointers to the JRA4 page and to the LHC visualisation tool. JRA3 to identify if this fits with the picture.
[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).
