perfsonar development work

[Loukik Kudarimoti <>]

Joe Metzger wrote:
> Loukik,
> I don't think we need this.  We have already discussed putting URN's
> into the protocol. These URN's contain a domain field. So, I think we 
> should
> just implement the approach that has already been discussed, instead of
> inventing a new one.

> Or, does this new proposal support some capability that URN's don't 
> support?
Hi Joe,

I might have missed this point. URN is a great idea and I am fine with 
using that approach. However, I am not clear where such a URN will fit 
within the store file and the protocol and how it will help us achieve 
the objectives discussed in Zagreb and detailed for implementation below.

Can you please explain with some examples?

> I also think it is important that the domain field used in the MA is 
> exactly
> the same as the domain field used in the dynamic circuit provisioning 
> systems.
Completely agree. I have focussed on the need for this functionality. I 
am okay with any sensible syntax to be honest.

Loukik.

> So we should be providing explicit instructions on the field contents, 
> in addition
> to the field name.
>
>
> --Joe
>
>
>
> On May 19, 2008, at 11:36 AM, Loukik Kudarimoti wrote:
>
> > Dear all,
> >
> > As discussed and agreed in Zagreb, we have a use case for the 
> > re-introduction of a field representing 'organisation name'. In its 
> > first/previous birth, it was known by authName field although its 
> > intended purpose was different from what we have for it now. This 
> > field will go into the the metadata description of each IP interface 
> > in both the store file as well as the communication protocol.
> >
> > The following is the specification for a new field to be re-introduced.
> >
> > 1. A new XML element/tag which represents the name of an organisation 
> > or project to be described will be used. The name of this element 
> > hasn't been decided upon yet. For the purpose of this specification, 
> > this new element is named as $new-element.
> >
> > 2. The metadata configuration file (a.k.a store file) stored by RRD 
> > MA (and similar services such as SQL MA,etc) can contain the 
> > $new-element at two levels:
> >
> > 2.a . This element could be within the metadata configuration file 
> > inside the parameters block of the file (right at the beginning). The 
> > presence of $new-element at such a high level means that the 
> > specified field value applies to all the interfaces defined in the 
> > metadata file.
> >
> > 2.b. This element could be repeated within each interface element. 
> > The presence of this element at this level allows the deployer to 
> > specify which interfaces in the metadata configuration file belong to 
> > which projects/organisations/grouping, etc. This typically helps 
> > deployment scenarios where one MA serves more than one organisation 
> > or to denote interfaces for each project within an organisation.
> >
> > 2.c. This element could be repeated at both 'beginning of file' level 
> > as described in 2.a or 'interface' level as described in 2.b. The 
> > presence of this element at the interface level overrides the value 
> > set by the higher interface level. This allows deployers to easily 
> > set one value for all interfaces and override it for a few interfaces 
> > which are different.
> >
> > 3. The communication protocol used between MA and visualisation 
> > tools: The MA is not expected to make any special modifications to 
> > suit this scenario. The MA must pass back
> > * the $new-element at the store file level if present OR
> > * the $new-element at the interface level if present OR
> > * the $new-element at the interface as well as the $new-element at 
> > the store level if present
> >
> > The visualisation tools are expected to understand the logic built 
> > into the file and display accordingly.
> >
> >
> > Ideas for $new-element: This element could be
> > Option 1: <nmwg:parameter name='domain' value='GEANT2/>
> > Option 2: <nmwg:domain>GEANT2</nmwg:domain>
> > Option 3: ??
> >
> > Next steps: Since we want to have this extension released in 3.1, we 
> > would like to hear from you by 26th of May. If no comments are 
> > received, we will choose one of the options and extend the services 
> > to be released in 3.1
> >
> > If you have any questions, please let me know.
> >
> > thanks,
> > Loukik.
> >
> >
> >
> > --
> >
> > ---------------------------------------------------------------
> > L o u k i k   K u d a r i m o t i
> >
> >      * *              Network Engineer
> >    *     *            City House, 126 - 130, Hills Road
> >   *                   Cambridge CB2 1PQ, United Kingdom
> >   *                   WWW: http://www.dante.net
> > D  A  N  T  E          Tel:+44 1223 371300 Fax:+44 1223 371371


--

---------------------------------------------------------------
L o u k i k   K u d a r i m o t i

     * *              Network Engineer
   *     *            City House, 126 - 130, Hills Road
  *                   Cambridge CB2 1PQ, United Kingdom
  *                   WWW: http://www.dante.net
D  A  N  T  E          Tel:+44 1223 371300 Fax:+44 1223 371371