perfsonar development work

["Matthias K. Hamm" <>]

Hi Nicolas,

thanks for the quite long protocol ;-)

I have a few points:

- who is "MK" ?
- an action and responsible for point 4 is missing (was there any ?)
- point 5 is missing details. In the call you had some remarks to that 
(personally, I am very interested in this point)

Best regards,

Matthias

Nicolas Simar schrieb:
> Notes from the meeting:
>
> http://monstera.man.poznan.pl/jra1-wiki/index.php/191006-L2_Status_Monitoring 
>
>
> Attendance: Mark, Matthias, Yee, Nicolas, Joe, Michael, Otto, Jason, 
> Giovani.
>
>
> 1. Location needs to be abstracted more. - JM
>
> JM: concerns that the location in the example was only digit and is 
> hard to understand. How to cross-reference the location in this schema 
> and in the other application (e.g. in the RRD MA and in the cNIS). The 
> need to be identical.
> If specified lat and long, need to reference what exact definition is 
> used. Like to specify street addresses.
>
> ME: touch that point on the level to which the interface goes on a 
> transponder. Don't know when it didn't go more general.
>
> MK: this was a first step, can add additional info if Martin is OK 
> with it. Question: who provides that information and who utilises it.
>
> JM: other tools will be using those data. We need to build base 
> functionalities so that more advance visualisation tools can be build 
> on top of it.
>
> ME: Agrees with it, in particular if tools are being used for 
> troubleshooting.
>
> JM: I am not acvocating that everybody needs to fill out all the 
> information. But it is important that the schema contains all the 
> information needs to
>
> MY: In that case, we will be confronted to discrepency between the 
> data offered by different networks. We need first to set-up a minimum 
> schema understandable by all.
>
> MS: Challenge of the schema definition is to represent in a common way 
> the various information available from different network devices.
>
> MH: E2E monitoring has a data model behind it and is not intended to 
> be a all purpose schema. That's why there is abstraction. If we want 
> more details, then we have to rework the whole data model, but also 
> the links. That would be a completely different system.
>
> MY: didn't get the comment (too fast)
>
> MS: It is possibly not a matter to redo what you have done, but extend 
> the schema for which further functionalities need to be added to.
>
> JM: how do we move forward from this?
>
> MS: fairly easy to add an abstract location to it, with everyone 
> feedback.
>
> OK: for an e2e path which gives the status in a particular domain, it 
> can consist of multiple segments which are concatenated (with switches).
>
> JM: what's we got is a very good start. Eventualy, we will have to go 
> a lot deeper. There may be a disconnect between what the people think. 
> Some within the perfSONAR group think that the NOCs will also be using 
> perfSONAR base tools to gather information from other side of the 
> path. Concern that we have a perfSONAR location schema and for 
> particular use, don't expect people to populate the information to the 
> slot and interface level, but we need a standardise schema.
>
> NS: summarise JM points.
>
> ME: how it fits within the particular naming from the equipment used 
> by networks (rack ID, ). Check with what comes out (if it is 
> sufficiently generic). We can do that easily.
>
> MH: is the problem we are tackling the schema be extended with 
> extending the schema or being covered with the cNIS. Clarify it there 
> rather than with the E2E schema.
>
> ME: Matthias has a very good point.
>
> MS: JRA1 people already talking with cNIS to have the schema in 
> harmony. They are fairlty close. Keeping them in sync is a priority.
>
> JM: need to have capability out sooner rather than later bcs it will 
> be used before the cNIS comes out.
>
> MH: NRENs have two or more interfaces located at the same point, to 
> separate them, they need different IDs.
>
> MY: do we want to differentiate them on the monitoring system.
>
> Lost track of few points here...
>
> ME: Mark has highlighted : "hierarchy".
>
> MS: people to have a look at the schema and not only the E2E part and 
> see it if address the points or not.
>
> JM: it won't have a huge impact.
>
> MY: Guys from different NRENs and in different PoPs user different 
> type of information (Some PoPs have room/rack, whilst some other don't 
> have).
>
> ME: if you do it hierarchical, it can be a single schema.
>
> MS: a single schema with different representation is possible.
>
> ME: the uniqueness of a topology point is key to identify uniquely a 
> point. lost track ... falls apart. If single schema with hierarchy, 
> you get the same info everywhere and you ignore what's below.
>
> JM: isn't a problem when we extend the hierarchy it is a constraint we 
> have.
>
> OK: why doesn't perfSONAR show to Matthias and Mark show them the 
> extension.
>
> Actions:
> - MS and JM: to put it down and get this moving forward.
>
>
> 2. Link types should be from an agreed on list of reasonable names
>
> JM: confusion is that in the document, one name is used and in the 
> example, there is another one.
>
> MH: in the extention of the NM-WG is using NREN-link, which means that 
> the NRENs need to change it too.
>
> ME: it's an oversight on our part. Should ask the NRENs to make the 
> correct terminology that should be "domain link".
>
> Actions: MH and MY will contact the NRENs to explain on how to change it.
>
> JM: do we want to change things asynchroneously or everything in a go.
>
> MS: link types not defined in the schema, this is a field. Its good to 
> define it and it won't invalidate the schema.
>
> 3. The time type looks odd, but Martin can decide if it is right. - JM
>
> JM: the time, is it the same type we are using in perfSONAR.
>
> MS: the ISO timestamps is the same than in the pS schema.
>
> Solved.
>
>
> 4. The circuit naming scheme needs work. Currently it is documented as 
> Organization Acronym - Organization Acronym, project ID, Serial #. 
> This doesn't scale outside of Europe. - JM
>
> ME: it is part of an unique scalable global unique scheme.
>
> MS: which means falling back to existing a unique glocal scheme URN
>
> ME: suggestion to register a MACE name. There were quire a lot of 
> comments.
>
> JM: first thought possible a workable scheme, but not totally 
> confortable with it but don't know why. It's a huge step forward.
>
> MS: not sure to have seen the proposal.
>
> JM: need coordination on the ciruit scheme, working with I2, Brew, 
> OSCAR, LHC. There are several context where they appear. There is 
> confusion. Understant that there can't be a single scheme bcs of 
> external constrains.
>
> ME: can also be used for topology points.
>
> OK: what are the other approaches for naming schemes.
>
> JM: not found document for brew and oscar. But it is a long 
> concatenation of devices along the path. In another context, the name 
> discussed are names with no geographical reference.
>
> MY: came with new schema following JM points few weeks ago.
>
> ME: why not use DNS? Hear argument that we are overloading DNS with 
> loads of functions that it is not designed to. Then how do we address 
> the uniqueness.
>
> MS: we need to submit to something more global. All the stakeholders 
> need to meet somewhere, and agree on something. This involves three 
> GN2 entities, three in the US and the GLIF.
>
> MH: no problem to follow the first solution and seek for a more global 
> one.
>
> MY: need to meet with other groups and brainstorm with them tocome up 
> wiht a more general schema. When do we need to have the schema ready.
>
> ME: there is no desperate hurry about that, bcs few discussion in high 
> places are needed.
>
> JM: we are realistically talking about few circuits a months.
>
> OK: you mentioned in Toronto that you may have quite a lot of circuits 
> and end-users may be confused wiht the names.
>
> JM: it is not an issues for the next 6-9 months. It will take some 
> time to get agreement and that will take time. Several months.
>
> ME: need to raise that in the GN2 TC in Europe. We can't go much 
> further than that. Unique naming so far is will do for few months.
>
> JM: useful to get documentation about other naming scheme from other 
> groups to see where people are coming from.
>
>
> 6. Access to JRA4 documentation.
>
> OK: done, everything has been publisehd on the perfSONAR web-site.
> We aim to make it the one to be updated.
>
>
> 5. perfSONAR services.
>
> Aimed at documenting the protocol on the wire.


--

Matthias Hamm

------------------------------------------------
Leibniz-Rechenzentrum / Leibniz Computing Centre
Raum I.2.107
Boltzmannstrasse 1, 85748 Garching, Germany
Telefon: +49 89 35831-8832
Fax:     +49 89 35831-9700
E-Mail:  

-------------------------------------------------