Re: Network Description Files for GLIF

["Steven S. Wallace" <ssw@xxxxxxxxxxx>]

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.