perfsonar development work

["Nina Jeliazkova" <>]

Michael,

I mostly concur with you about LS/topology service discussion, but back to my
original question, I am still not sure how proposed URN's solve the problem.

For an IP belonging to an interdomain link and registered in more than one
perfsonar service, domain (FQDN) is the same, consequently URN is the same.
Again, we have more than service providing information about a network element
and the problem about selection/data comparison is still in place. Please
correct me if I misunderstood the theory.

Best regards,
Nina


"Michael Bischoff" 
<>
 wrote:

> URN's (https://wiki.internet2.edu/confluence/display/PSPS/URNs) should solve
> most problems
> even with local ip ranges as a domain is always included.
> 
> We discussed about things that would solve this. To me it really sounds like
a
> mismatch
> between what the LS is suppose to do and what the topology service is
suppose
> to do,
> undoubtly in the topo service this problem is trivial to solve as they have
all
> the
> information right there and in the LS infrastructure it would feel like
> hack-ar-y thing.
> Since that discussion ended in strong disagreement and arguments I'll not
> rattle it up again.
> 
> The idea with LS client api was to represent the topology elements as URN's
> (but I beleave it
> is a bit 'lax' at the moment.) I think you can either query with just the
ip's
> without the
> domain information and I would probably then return anything that I can find
> with that ip but
> in the data I return I try to also supply domain and the client(software
that
> calls the api)
> can sort it out that or simply supply a domain with the ip and the problems
> would go away
> too.
> 
> The only issues that are really there is whether I can extract enough
> information from the
> back-end / infrastructure.
> 
> Suggestions with regard to issues with visualising would bring us back in
the
> old discussion.
> 
> The problem isn't new; to globally uniquely identify a node a ip + subnet
> doesn't cut it from
> the URN proposal I take it addign domain information fixes this issue.
> 
> As far as the LS api goes I think that the policy of leaving filtering data
is
> up to the
> programmer and not the api saves from headaches in the future.
> 
> regards
> 
> Michael B.
> 
> > On Aug 14, 2008, at 3:41 AM, Nina Jeliazkova wrote:
> >
> >>
> >> However, Maciej had a different view ( don't restrict the answer to
> >> one subnet, present everything to the user, see emails below ), so we
> thought it will be
> >> best to move the discussion into the developers mailing list.
> >>
> >> In summary,  my question is as follows (having in mind only the use
> >> case when the user is asking for list of IPs coming from a traceroute and
a
> given eventtype,
> >> i.e. subnet mask 32 ) • Is there a chance, that information for a given
IP
> and given
> >> eventtype (e.g. utilization) is provided by more than one (MA) service ?
> >
> > Once the rest of my infrastructure is ready I should always have 2
> > geographically distributed MA's with very similar utilization data for any
> ESnet interface.
> > This
> > is a critical part of the architecture as far as I am concerned.  During
> network outages or
> > server maintenance, it is quite possible that one of the systems will have
> holes in the data.
> >
> > We have also contemplated having 3 MA's.  2 of which are based on
> > independent systems that are doing active polling and have the current
data
> for the last week
> > (or month), and a 3rd,
> > which will have archived historical data which is synthesized from the 2
> servers, with any
> > data holes filled in.
> >
> >
> >> • If yes, how do we visualize that and assure the information is
> >> consistent?
> >
> > People working on operational purposes will want one display with the
> > 'best' data.
> >
> >
> > People working on network research, or measurement maintenance will
> > want to see all the data, and be especially interested in when various
> sources are different.
> >
> > So, I think the default could be to pick one.  But eventually we will
> > want the ability to select and compare the data from multiple servers.
> >
> >
> >> • If not, what is the reason of looking into multiple options?
> >> Discussion on other use cases are of course welcome :)
> >>
> >>
> >> Best regards,
> >> Nina
> >>
> >
> >
>