perfsonar development work

[Jason Zurawski <>]

Szymon Trocha wrote:
> Jason,
>
> Jason Zurawski pisze:
>
> > > None of the above MAs come from PIONIER so they can't provide data 
> > > about 150.254.185.146 and 212.191.224.74 :( Unless I don't know and 
> > > you collect our data ;)
> > > How could they be the results (which are completely wrong) of such 
> > > query?
> >
> >
> > This is an excerpt from our December email thread, this is still 
> > relevant since there has been no alteration to the summarization 
> > algorithms.
> >
> > While I still do not agree that this answer is 'wrong' as described in 
> > the design documents, it will be necessary to enhance the 
> > summarization algorithms from the current state to get a more exact 
> > result.  The section below describes a common case where the hLS will 
> > advertise ranges that are broad for a given data set.  This is usually 
> > made much worse when two address ranges are present and the subsequent 
> > IP address tree is very sparse.
>
> So that means that the summarization algorithm is wrong and needs 
> serious improvements.


I agree, will Maciej be available to work with the student on improving 
the procedure?  The algorithm will be applicable to both the MDM and PS 
services.


> Can you explain to me how the answers from LS as shown by Nina can help 
> the GUI to get data from PIONIER network as they don't provide *ANY* MA 
> which contain correct data? My understanding is the results are 
> currently useless for GUI. What would be the way to get correct MAs 
> according to this algorithm?


First, are there MAs and LSs that have this data and are they gLS 
enabled?  From Nina's mail:


> 150.254.185.146  (PIONIER)
> 192.5.40.187
> 212.191.224.74
> 194.141.0.10  (BREN) 


Looking in the gLS, this is the summarization I see for PIONIER:

        <nmtl3:network 
xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
070828/">
          <nmtl3:subnet>
            <nmtl3:address type="ipv4">150.254.162.229</nmtl3:address>
            <nmtl3:netmask>32</nmtl3:netmask>
          </nmtl3:subnet>
        </nmtl3:network>
        <nmtl3:network 
xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
070828/">
          <nmtl3:subnet>
            <nmtl3:address type="ipv4">62.40.124.182</nmtl3:address>
            <nmtl3:netmask>32</nmtl3:netmask>
          </nmtl3:subnet>
        </nmtl3:network>
        <nmtl3:network 
xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20
070828/">
          <nmtl3:subnet>
            <nmtl3:address type="ipv4">212.191.224.0</nmtl3:address>
            <nmtl3:netmask>24</nmtl3:netmask>
          </nmtl3:subnet>
        </nmtl3:network>

Since this is a Java hLS, I would ask Maciej to please look at his 
summarization code to ensure the proper ranges are being reported, 
150.254.162.229/32 is rather specific :)  As for the other ranges, if 
you know which hLS is summarizing for them I can do the same analysis to 
get us closer to debugging the problem.

The bottom line is that if there is not data in the gLS cloud this will 
not work.  The results for the Interet2/IU services would still show up, 
but the 'correct' hLS would as well and proper answer can be discovered.

Thanks;

-jason