perfsonar development work

["Jeff W. Boote" <>]

Hi Andreas,

I fully agree with Stephan here. Also - I added some additional  
comments in the document regarding the 'neighborhood' information  
registered by a service, and the new messages you have created.

The 'neighborhood' information needs to be abstracted into more of a  
general rule for all services. It should not rely on the fact that the  
HADES MA is 'usually' near a router. I suggest having the web admin  
derive a NURN based on where it is in topology space (perhaps even  
communicate with the topology service to figure it out), and absent  
that it could run several traceroutes to known divergent locations on  
the network and register all the first N hops it sees (including 0). N  
could default to something like 3-5, but could be administratively  
configurable to a number large enough to get off the NREN for example.

The other thing I mention is that you have no eventTypes in any of  
your messages. eventTypes is the mechanism you should be using to  
indicate the type of data you are looking for, and therefore it is  
usually required information. (It is not in the current set of LS  
messages - but that is actually giving us some problems in the dLS  
implementation and will likely change in the future.)

(Sorry - but I will not be able to attend the call. I will be in the  
air at that time...)

jeff


On May 6, 2008, at 2:32 AM, Stephan Kraft wrote:

> Hi Andreas,
>
> i added some comments on the document (attached). Main point for  
> HADES and BWCTL will be, that it is not foreseen to put the  
> "business logic" for finding related MPs into the HADES MA or the  
> BWCTL MP. The point is to find a way to correlate the traceroute  
> information with the topology service (cNIS), together with the  
> lookup service.
>
> A proper way may be a "Traceroute MA" containing the information  
> about traceroute of N=n(n-1) measurement paths (50 boxes  
> representing 2450 measurements, _not_ containing additional  
> measurements like IPv6, ToS etc.). This Traceroute MA can be  
> requested by cNIS, LS etc.. Starting and ending point will be the  
> measurement box (HADES, BWCTL other ...), the work will be to match  
> the paths between the boxes and the paths between the corresponding  
> routers. This should not be done by HADES MA (not only because it  
> then just works for the HADES MA).
>
> Best
>
> Stephan
>
>
>
> Andreas Hanemann schrieb:
> > Hi Nicolas, Nina, Martin, and Verena,
> >
> > Based on the discussions that we had in Zagreb I have refined the  
> > document on "Finding related MPs". New is a proposal how an  
> > interface in perfsonarUI may look like and how its business logic  
> > should work (the most difficult part is the one related to the  
> > HADES MA and BWCTL MP). The business logic requires that several  
> > additional messages are exchanged. For this I have modified  
> > examples from other schema uses (similar as in the Tranformation  
> > Service document). As a starting point I would like you to read the  
> > document and participate at the conf call that I have proposed for  
> > next week. See the following link for the conf call and the document.
> >
> > http://wiki.perfsonar.net/jra1-wiki/index.php/Finding_Related_MPs_Conf_Call_13_may_2008

Attachment: Finding_Closest_MP_v5_SK_JB.doc
Description: Binary data