Re: Network Description Files for GLIF

[Gigi Karmous-Edwards <gigi@xxxxxxxx>]

Dear All,

I think this is a very important subject and holds the key to true
international network connectivity for NRENs. There seems to be several
excellent independent initiatives already around the world within the GLIF
community. I think the role of GLIF is one of coordination and
"standardization" for this global research community. As Kees Neggers
mentioned in an earlier email thread (which I will forward to the control
plane list), this effort straddles both the GLIF Tech group and the GLIF
Control Plane group. I will work with the chairs of the Tech group to assure
a coordinated work plan for the two groups as we prepare for the September
meeting. 

Again I feel the greatest challenge for us is to arrive at precise semantics
of all data/metadata fields to be held in the repository, so that
interpretation and perception of the information will not differ from one
network to the other, otherwise the data will be useless. Also, to architect
the repository so that it is continually expandable as networks and network
technology evolves. Lastly, some data may be more dynamic than others,
mechanisms for these updates is a critical consideration.

We look forward to hearing more on  these ideas, mechanisms, and experiences
from all on both mailing lists, as this will help in making the September
meeting very productive and speed up progress towards making this global
repository a reality.

I welcome all comments.

Kind regards,
Gigi


--------------------------------------------
Gigi Karmous-Edwards
Principal Scientist
Advanced Technology Group
MCNC Grid Computing and Network Services
RTP , NC, USA
+ 1 919-248-4121
gigi@xxxxxxxx
--------------------------------------------


> From: John Graham <johng@xxxxxxxxxxx>
> Reply-To: John Graham <johng@xxxxxxxxxxx>
> Date: Fri, 10 Jun 2005 10:34:38 +0100
> To: "Steven S. Wallace" <ssw@xxxxxxxxxxx>
> Cc: <tech@xxxxxxx>, <John.Dyer@xxxxxxxxx>
> Subject: Re: [GLIF tech] Network Description Files for GLIF
> 
> Hi Steve - This is a clever idea; and I was thinking how readily
> extensible it would be to allow for a richer data set and specifically
> whether different networks and countries might need to express different
> metadata(?) and how this could accommodated...
> 
> I have been attending the TERENA Networking Conference all this week,
> and as is always the case at these events, the trick is to find the gems
> that hide in the mass of parallel sessions. I was fortunate enough to
> happen on a talk by Victorian Giralt (University of Malago, Spain) who
> was describing how they have implemented a customizable staff directory
> using LDAP classes and attributes and OpenLDAP Access Control Lists.
> This allows a staff member to maintain a single set of directory date
> and to construct rules that determine who can view which columns. So I
> might want to publicise my cellphone address within my organisation, but
> hide it for external queriers. I'm no expert in X.500 stuff, but I
> wonder whether your concept might not be suited to the flexibilty
> offered by OpenLDAP?
> 
> John Dyer, the Chief Technical Officer, was chairing the session and
> agrees there is some mileage in this. I've copied John on this message
> in case he isn't part of the GLIF Tech list.
> 
> Victoriano's slides can be found here:
> 
> http://www.terena.nl/conferences/tnc2005/programme/presentations/show.php?pres
> _id=89
> 
> I'll be attending iGrid 2005 and possibly also the Internet2 Autumn
> member meeting in September. In the meantime, hopefully this message
> will continue the discussions.
> 
> Cheers
> 
> John
> 
> Steven S. Wallace wrote:
>> Here's something I'm working to address similar needs for the Quilt.   I
>> think this could scale internationally.
>> 
>> Here's the idea:
>> 
>> all.network-map.net. TXT "us-uk-nl-ca"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> FQDN   TXT record showing what country codes contain network map data
>> 
>> 
>> 
>> all.us.network-map.net. TXT "IN-OH-FL"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> FQDN TXT record showing what states (in the US) have network map data
>> 
>> 
>> 
>> all.oh.us.network-map.net. TXT "TFN"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> FQDN TXT record showing the name of network(s) in Ohio
>> 
>> 
>> 00001.TFN.oh.us.network-map.net TXT  "Link=Columbus, OH-Cincinnati, OH"
>> 00001.TFN.oh.us.network-map.net TXT  "Status=Existing"
>> 
>> 00002.TFN.oh.us.network-map.net TXT   "Link=Columbus, OH-Chicago, IL"
>> 00002.TFN.oh.us.network-map.net TXT   "Status=Existing"
>> 
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> These are records that specify the network segment endpoints and the
>> segment's status.  An application would fetch sequential records  until
>> it hit the last one.  In this example OARnet (they run the TFN)  would
>> be delegated authority for TFN.oh.us.network-map.net.
>> 
>> 
>> 
>> Each RON would simply maintain their own delegation (zone file).  My
>> lab would make an application available that walked the DNS data and
>> constructed a map.  Since there may be multiple TXT records for a  given
>> FQDN, we could a small set of attributes for each link.
>> 
>> 
>> What do you all think?
>> 
>> 
>> Steven
>> 
>> On Jun 2, 2005, at 12:37 PM, Jeroen van der Ham wrote:
>> 
>>> Hello everyone,
>>> 
>>> In the last two months we started working on a way to make a  description
>>> of our network and resources at Netherlight and Lighthouse,
>>> Amsterdam. We
>>> had several goals in mind for making such a description:
>>> - For ourselves, to have a machine readable overview of our network,
>>> possibly including its current (automatically extracted)  configuration.
>>> - For possible users, so that they can see what we resources we have,
>>> possibly what is available at the moment. The description also  contains
>>> the list of possible entry points to our network. Ultimately, these
>>> entry
>>> points should point to the network description of the relevant  provider.
>>> - Problem detection, if you have a complete overview of the
>>> configuration
>>> of your network, written in a machine-readable format, configuration
>>> problems can be detected more easily. If every network owner were to
>>> publish this in a predefined format, then this can also be used to
>>> detect
>>> inter-domain problems, by pointing at the configuration file of the
>>> connecting network in the relevant places.
>>> - Publication in GLIF, to make lambda path setup between participants
>>> easier or even completely automatic.
>>> 
>>> Yesterday Cees de Laat pointed us at the discussion currently going in
>>> the GLIF community regarding the visualization of the networks.
>>> We think that if everyone in GLIF (automatically) publishes a
>>> description
>>> of their network in a predefined machine readable way, this  information
>>> can be gathered by applications more easily. This will make it  easier to
>>> solve problems like the ones Kees Neggers raised in a recent mail
>>> (creating a repository, generating graphics, handling policies).
>>> 
>>> For example the excellent graphics tool Greg Cole can be used as  is, but
>>> the database is not filled with information entered through a web  form,
>>> but instead automatically by crawlers reading the network  descriptions.
>>> Such crawlers can also be used to periodically collect the network
>>> information and put this in a single repository to provide an  overview.
>>> On the other hand with a machine-readable format, it is also  possible to
>>> parse the relevant information on demand.
>>> 
>>> We are currently making a draft version of a schema for describing
>>> networks, including information about the capabilities, references  to
>>> the
>>> polices and services. We will post this to the mailinglist soon.
>>> 
>>> Bert Andree, Freek Dijkstra, Paola Grosso, Bas van Oudenaarde and  Jeroen
>>> van der Ham.
>>> 
>>> 
>> 
> 
> -- 
> Dr. John S. Graham
> UKLight Technical Manager
> 
> University of London Computer Centre
> 20 Guilford Street
> London
> WC1N 1DZ
> 
> tel:  +44 (0)20 7692 1329
> cell: +44 (0)7866 712 817
> 
> "Never trust a man in a blue trenchcoat, never drive a car when you're
> dead."
> 
> Tom Waits
>