- db-wg - mailman.ripe.net

Re: Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Why not deciding this by mail and doing it *now*? (since everybody seems to agree) 10 min to remove those lines from the DB file (grep -v is fine) 10 min to disable the nsf-in attribute in the conf file (or dbupdate.pl) 1h ? to rebuilt the index file. No big deal... > =I feel for Daniels and Jean-Michel's first option. They should > =definately be deprecated (although I have always viewed them as info > =only attibutes) and preferably removed. Although some people may find > > I agree with this point of view. > > I'm going to put it on the agenda for the DB-WG at the Amsterdam > RIPE-Meeting. We should have a *short* review and then agree on a > proposal and a *timeschedule* to remove this information from the > database. > > =this information useful currently, wrong information is worse than no > =information. I'd say obsolete. > > Agreed. > At the same time we should come up with a recommendation for new > ways of storing pieces of information that people maybe still want to > record in the DB. (Like connect, gateway, and the like). > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Wilfried.Woeber(a)CC.UniVie.ac.at > Computer Center - ACOnet : > Vienna University : Tel: +43 1 4065822 355 > Universitaetsstrasse 7 : Fax: +43 1 4065822 170 > A-1010 Vienna, Austria, Europe : NIC: WW144 > -------------------------------------------------------------------------- > -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

2 1

Re: Invalid data in the RIPE database
by farrache＠ccpnxt5.in2p3.fr 26 Apr '94

26 Apr '94

Hello, I would prefer to obsolete this field. Gilles

2 1

Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant? Thanks for your answer, Laurent -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

7 6

Re: Whois database and list of networks
by jimi＠dxcoms.cern.ch 22 Apr '94

22 Apr '94

Daniele, Thank you for your proposal. We all agree that the aggregates should be stored somehow in the Ripe database and that the current structure does not allow such representations of blocks/aggregates. This is now becoming the main priority of the routing-wg and (probably) the Ripe NCC. A proposal will be sent out very soon now, and we'll then be able to discuss this in more details. I'm sure your input will be considered and appreciated. -- Jean-Michel >----- Text sent by Daniele Vannozzi follows ------- > > We would like to know your opinion about this problem and our proposal. > The GARR-NIS manages a whois database (whois.nis.garr.it) where each > network is described with the RIPE database format plus other "italian > GARR-NIS" tags. We produce the access lists for the GARR border routers > starting from GARR-NIS whois database (we use the nlc tool). > In addition to that we are requested to produce the "aggregate" networks > list (CIDR) from GARR-NIS database as well. > > In our opinion it is difficult to get the right information about > network blocks from the whois database as it is currently managed > because many network blocks are splitted in smaller blocks (usually > corresponding to the really announced networks or because of different > contact point). > > We would like to announce the whole original block while maintaining > into the GARR-NIS database the splitted blocks. > An additional gain using this scheme would be to store different > rev-srv: server for each block for example). > > We have thought the following solution: add a new tag inet-block: into > the network object which describes the original block size. In this way > it is possible to store in the same object entry both the information > for route aggregates (inet-block:) and other data we need (like > rev-srv:, contact people, etc). > > This is a example: > > inetnum: 193.204.160.0 - 193.204.161.0 > netname: ROMA3-NET > inet-block: 193.204.160.0 - 193.204.167.0 > country: IT > admin-c: Fabio Martinelli > tech-c: Aldo Altamore > connect: GARR > aut-sys: AS137 > bdrygw-l: INFN-MIL INFN-CNAF > rev-srv: decsrv.caspur.it > rev-srv: dns.nis.garr.it > rev-srv: matrm3.mat.uniroma3.it > ...... > ...... > > inetnum: 193.204.162.0 - 193.204.167.0 > netname: ROMA3-NET > inet-block: 193.204.160.0 - 193.204.167.0 > country: IT > admin-c: Fabio Martinelli > tech-c: Aldo Altamore > connect: LOCAL > ....... > ....... > > Please let us know your opinion. > > > The GARR-NIS Staff > > Daniele Vannozzi Phone: +39 50 593280 > GARR-NIS Phone NIS: +39 50 593360 > c/o CNUCE - Istituto del CNR Fax: +39 50 904052 > Via Santa Maria 36 Telex: 500371 - CNUCE > 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it > -- Jean-Michel

1 0

Whois database and list of networks
by Daniele Vannozzi 22 Apr '94

22 Apr '94

We would like to know your opinion about this problem and our proposal. The GARR-NIS manages a whois database (whois.nis.garr.it) where each network is described with the RIPE database format plus other "italian GARR-NIS" tags. We produce the access lists for the GARR border routers starting from GARR-NIS whois database (we use the nlc tool). In addition to that we are requested to produce the "aggregate" networks list (CIDR) from GARR-NIS database as well. In our opinion it is difficult to get the right information about network blocks from the whois database as it is currently managed because many network blocks are splitted in smaller blocks (usually corresponding to the really announced networks or because of different contact point). We would like to announce the whole original block while maintaining into the GARR-NIS database the splitted blocks. An additional gain using this scheme would be to store different rev-srv: server for each block for example). We have thought the following solution: add a new tag inet-block: into the network object which describes the original block size. In this way it is possible to store in the same object entry both the information for route aggregates (inet-block:) and other data we need (like rev-srv:, contact people, etc). This is a example: inetnum: 193.204.160.0 - 193.204.161.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: GARR aut-sys: AS137 bdrygw-l: INFN-MIL INFN-CNAF rev-srv: decsrv.caspur.it rev-srv: dns.nis.garr.it rev-srv: matrm3.mat.uniroma3.it ...... ...... inetnum: 193.204.162.0 - 193.204.167.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: LOCAL ....... ....... Please let us know your opinion. The GARR-NIS Staff Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it

1 0

Internet Registry Object
by Daniel Karrenberg 20 Apr '94

20 Apr '94

I have an action to propose a "registry" object for the RIPE database. Defining such an object is not so much of a problem. In fact we already have the information needed in tagged format. Look at the Irish Internet registries as an example: org: EUnet IE status: Provider person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie org: HEAnet status: Provider person: Mike Norris address: 21 Fitzwilliam Square address: Dublin 2 country: Ireland (ie) phone: +353 1 6612748 fax: +353 1 6610492 e-mail: mnorris(a)hea.ie org: IE EUnet status: Registry of Last Resort person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie However putting this in the database is not all. We need to define a querying mechanism. This is where the problem starts. Options: 1) Return all the regsitries on queries for the country code together with the toplevel domain object. 2) Return all registries on queries for "cc-reg" or some such magic. 3) Add a special flag to whois to query for registries. All these options are not very applealing because all of them have a big potential for user confusion. Also I am convinced that this information should always be presented together with some information about what a local registry is and what it is not. What did we want to achieve by putting this information in the database? - easy updates via the normal means - access to up to date information at all times between publications of the local registry list We can achieve the -more important- second goal by making this information available via the RIPE document store together with the explanatory information. This could be implemented quickly (before the RIPE meeting). The first goal cannot be achieved that way. But since the amount of info and changes is expected to be small, the NCC can process update requests manually. So my conclusion is not to include this in the database but in the document store. If I have not considered some important argument, please let me know pricately or via a discussion on these lists. If there is consensus we will implement it that way. Daniel

2 4

Re: Internet Registry Object
by Wilfried Woeber, UniVie/ACOnet 20 Apr '94

20 Apr '94

>With 113 relatively stable entities I do not think that manual update >by the NCC is a problem. > >Daniel Daniel, if you want to handle the update manually, fine with me! Can we then use the ripe-dbm mailbox and use the tagged format you have already? E.g. let's assume my phone number changes and I update my person entry. Then it would be natural to think about having the same thing updated in the IR-entry. >PS: Also an answer to Wilfired's message. Thanks :-) Wilfried.

2 1

RE: Internet Registry Object
by Wilfried Woeber, UniVie/ACOnet 19 Apr '94

19 Apr '94

Dear all, lend me a couple of minutes to describe my expectations, without going into technical implementation details, as described by Daniel below... 1. How about using proven and widely known tools and info-channels? For me this means putting objects into the database, and maybe having them guarded (for ease of update). I don't really believe in manual update procedures... Finding info should be possible both through the Interactive Info Service at the NCC, and probably through the WWW interface. 2. Lets investigate a setup, - where we get the over-all info from the document store (the envelope), - more details by looking into a WWW compound document and getting - the details dynamically out of the database (clicking on an item). Please feel free to give me a blow on the head... Cheers, Wilfried. ________________________________________________________________________________ Daniel said: I have an action to propose a "registry" object for the RIPE database. Defining such an object is not so much of a problem. In fact we already have the information needed in tagged format. Look at the Irish Internet registries as an example: org: EUnet IE status: Provider person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie org: HEAnet status: Provider person: Mike Norris address: 21 Fitzwilliam Square address: Dublin 2 country: Ireland (ie) phone: +353 1 6612748 fax: +353 1 6610492 e-mail: mnorris(a)hea.ie org: IE EUnet status: Registry of Last Resort person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie However putting this in the database is not all. We need to define a querying mechanism. This is where the problem starts. Options: 1) Return all the regsitries on queries for the country code together with the toplevel domain object. 2) Return all registries on queries for "cc-reg" or some such magic. 3) Add a special flag to whois to query for registries. All these options are not very applealing because all of them have a big potential for user confusion. Also I am convinced that this information should always be presented together with some information about what a local registry is and what it is not. What did we want to achieve by putting this information in the database? - easy updates via the normal means - access to up to date information at all times between publications of the local registry list We can achieve the -more important- second goal by making this information available via the RIPE document store together with the explanatory information. This could be implemented quickly (before the RIPE meeting). The first goal cannot be achieved that way. But since the amount of info and changes is expected to be small, the NCC can process update requests manually. So my conclusion is not to include this in the database but in the document store. If I have not considered some important argument, please let me know pricately or via a discussion on these lists. If there is consensus we will implement it that way. Daniel -------------------------------------------------------------------------------- Return-Path: <dfk(a)ripe.net> Received: from email.univie.ac.at by access.cc.univie.ac.at (MX V3.1) with SMTP; Fri, 15 Apr 1994 14:14:45 +0100 Received: from ncc.ripe.net by email.univie.ac.at with SMTP (PP) id <29896-0(a)email.univie.ac.at>; Fri, 15 Apr 1994 14:14:59 +0200 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA27717 (5.65a/NCC-2.2); Fri, 15 Apr 1994 14:14:47 +0200 Received: from localhost.ripe.net by reif.ripe.net with SMTP id AA12109 (5.65a/NCC-2.1); Fri, 15 Apr 1994 14:14:47 +0200 Message-ID: <9404151214.AA12109(a)reif.ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Sender: Daniel.Karrenberg(a)ripe.net

1 0

Merit Routing Registry
by epg＠merit.edu 18 Apr '94

18 Apr '94

Merit is happy to announce the Merit Routing Registry. Whereas Merit designed and manages the PRDB (Policy Routing Data Base) for the NSFNET service, RIPE pioneered a policy routing registry for the European community. The RIPE Routing Registry is based on the document, RIPE-81. With RIPE's collaboration, Merit installed RIPE-81 software and then extended the policy descriptions in order to realize more complex policies. The Merit Routing Registry will be a companion registry to the RIPE Routing Registry and is intended to serve the community that is not served by RIPE. This is a new service and we consider ourselves still in the beta phase. Registrations may be basic policy descriptions defined in RIPE-81 or complex routing policy descriptions defined in the Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu. The Extended Policy Syntax document may be found on rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for using the MeritRR can be found on rrdb.merit.edu:pub/meritrr. Merit and RIPE anticipate that the combined registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to allow the two registries to appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. For more information, please respond to rradmin(a)rrdb.merit.edu. Elise Gerich, Merit Network, Inc. Daniel Karrenberg, RIPE NCC

1 0

Re: Corrupted data
by Tony Bates 15 Apr '94

15 Apr '94

Following on from the mail yesterday about errors in aut-num objects in the database. Please find a new set of database errors on ftp.ripe.net:ripe/dbase/errors/* -rw-r--r-- 1 tony dbase 0 Apr 15 11:59 as-macro.errors -rw-r--r-- 1 tony dbase 5319 Apr 15 11:55 aut-num.errors -rw-r--r-- 1 tony dbase 0 Apr 15 11:58 bdry-gw.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 community.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:01 dom-prefix.errors -rw-r--r-- 1 tony dbase 103796 Apr 15 12:06 domain.errors -rw-r--r-- 1 tony dbase 58285 Apr 15 12:46 inetnum.errors -rw-r--r-- 1 tony dbase 320852 Apr 15 12:38 person.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 rout-pr.errors As you can see person has the most errors. Please can all (especialy local-irs take a look at these files and correct where possible. Here's a summary of the amount of errors over what is in the database. Object Number in DB Number in Error aut-num 322 11 domain 3222 354 inetnum 16107 176 person 16366 1072 Please look at these files. Remember many of the errors are where mandatoy fields are not in the object rather than syntax errors. The next round will be to start chasing people individually. Thanks, --Tony.

1 0

Corrupted data
by Laurent Joncheray 14 Apr '94

14 Apr '94

Could you clean up these data? Some of the policies are not RIPE-81 compliant. Thanks. alc: reading file "/f/rrdb/dbase-beta/data/ripe.db" (RIPE-DB)... ERROR (201339): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ao: AS1853" ERROR (201348): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ai: AS1800 ANY" ERROR (201349): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ai: AS1880 ANY" ERROR (201368): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1755 100 AS1755 AS690" ERROR (201369): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1883 200 AS1755 AS690" ERROR (201382): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1880 100 AS1755 AS690" ERROR (201395): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1880 100 AS1755 AS690" ERROR (201396): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1883 200 AS1755 AS690" ERROR (201414): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1755 100 AS1755 AS690" ERROR (203306): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ao: AS1755 AND AND NOT (AS1729)" ERROR (205269): object *am undefined alc: Printing stat for db RIPE-DB alc: ipblock: 16075 objects, 38766 count alc: autsys: 321 objects, 321 count -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

2 1

A ROUGH alternate proposal to CLNS DB for RIPE
by Susan Hares 06 Apr '94

06 Apr '94

Wilfried: I'm thrilled to see your response. The reason I proposed this change was to align it with the IP CIDR object. My hope was we could then leverage the IP CIDR work to quickly implement the CLNS. So, I am looking at implementation at RIPE NCC and MERIT. I would like to expand prtraceroute and whois servers to use the CLNS. The host.txt option is certainly open to question. I suggest we talk about the benefits of the proposal without this section. To discuss the "host.txt" section, I suggest we query the noop(a)merit.edu tuba(a)merit.edu lists to determine the distribution of the DNS NSAP object. If it is far enough along, then we should can this. Otherwise, it may be a very useful "bootstrapping" function to support. If you agree, I will send notes to this and the rare-clns-wg4 mail list. In the implementation these objects could be kept in a different sequence of files that could be easily cut when the DNS NSAP object is widely deployed. Again, many thanks for such a thought response! Sue Hares

1 0

Re: A ROUGH alternate proposal to CLNS DB for RIPE
by Wilfried Woeber, UniVie/ACOnet 30 Mar '94

30 Mar '94

Hi Sue, Tony, > * I'd like some pointers on where to go from here. > * I send this document because my questions and alternate > * formats provoked no additional comments. > * >I guess from a RIPE DB point of view the next step needs for these new >objects to be agreed and for a RIPE document to come out of this. >What say the RIPE DB chairman. Wilfried ? (BTW, Sue and Victor could you please distribute this discussion to the appropriate lists @merit and @rare.nl, I deliberately shortened the Cc: list in order to save bandwidth) I've got to different opinions at the same time :-( The first one would say - we had a lengthy discussion in the RIPE-DB meetings, and we decided to implement the stuff according to the circulated proposal after minor improvement. The RIPE-NCC found no problem in implementing it. Unfortunately it turned out that there is room for considerable improvement (thanks to Sue's contribution!), thus my second opinion would say - as there is not yet wide-spread use of this object we should aim at the best solution that is economically feasable (implementation effort and quality of data). So let's go that way! Ok, now the technical part: I don't understand much of the game of NSAPs, RDIs, and the like :-( Thus I'd really like the folks who initially proposed the object and those who want to use it to review the situation and come up with a good-quality proposal. I'd like to have it circulated well before the next RIPE-Meeting because I'd like to eventually have final consensus in May. Henk, Victor, and the others who want to use it, please speak up! > * CLNS routing-domain object for the > * RIPE database > * Version 1.3B > * Feb 1994 >... > * 3) NETs host systems > * > * The DNS for CLNS system is under development. > * As a host.txt file was once used to bootstrap > * the internet, so a iso_hosts file must > * be generated to help boot strap the CLNP Internet. Right now I cannot clearly see the validity of this statement. I'd propose to provide an explanation why for example the use of IP-DNS or some other directory service is not possible to register hosts that are CLNP-capable. Also we would need a specification where, when, and how to convert the CLNS-hosts data in the RIPE-DB into an iso-hosts file. I think it is essential to describe the timeframe and the functional and resource limits (if any) of using the RIPE-DB for registering hosts and how to migrate the accumulated info afterwards to some form of CLNS-DNS or to whatever. Again, you know, when it comes to CLNS I may be terribly wrong :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

A ROUGH alternate proposal to CLNS DB for RIPE
by Susan Hares 28 Mar '94

28 Mar '94

Victor and all: This *very* rough draft is the start of an alternate proposal to be discussed at the ripe data base working group. Any comments would be welcomed on this. I started with Hank's proposal I'd like some pointers on where to go from here. I send this document because my questions and alternate formats provoked no additional comments. I suggest this alternate proposal to align things more closely to IP CIDR ideas. I thought that was the point of CIDR. I am in hopes this will help tools creation, but again since I have started anything like that I welcome comments. Are there on-line tools for CLNS traceroutes like prtraceroute? I welcome pointers. Again, thank-you for letting me comment. My comment should be taken as personal, and not representative of Merit. So flame at me. Sue Hares ---- CLNS routing-domain object for the RIPE database Version 1.3B Feb 1994 Susan Hares/Hank Steeman skh@merit.edu/Henk_Steenman@sara.nl CLNS routing-domain object Page 2 Introduction. ____________ In the RARE lower layer technology work group for CLNS it was recognised that in order to coordinate routing between CLNS routing domains a central registry for such domains was necessary. At a meeting of the work group at the 27 IETF in Amsterdam it was decided to write a registry specification. At this meeting the RIPE NCC offered to extend their database for IP domains/networks with CLNS related objects if a sound proposal came forward. Below is a revision of the 1.3 database description to include the following: RIPE-81++ features: - Registration of ISO addresses - Registration of Routing Policy - Registration of Aggregation policy The registration of ISO address needs to include the: 1) Network Layer Reachability (NLRI) information These are simply the Prefix passed in the routing protocols. Just as IP network numbers are passed in the IP routing protocols. 2) Routing Domain Identifier (RDI) Routing Domain Identifiers are the "AS number" equivalent for ISO routing protocols such as IDRP. The Routing Domain Identifiers are take out of the same address space as the rest of the ISO addresses. This address spaces minimizes some allocation issues, but increases the need to register RDIs. The IDRP for IP specification allows an AS number to be mapped into RDI. RDI so mapped can be directly mapped into an AS. The registration should indicate if this registration space i is used. 3) NETs host systems The DNS for CLNS system is under development. As a host.txt file was once used to bootstrap the internet, so a iso_hosts file must be generated to help boot strap the CLNP Internet. The routing policy in this database is listed on an Routing domain basis. 1) Routing Domains attached to a Routing Domain 2) Address of Router that provides exit points for Routing Domain 3) Policy of what routes the Routing Domain will take from other domains. (This equivalent to the IP AS-IN policy used by CLNP). 4) Policy of what the Routing Domain will send to other routing Domains (This equivalent to the IP AS-OUT policy used by CLNP). 5) Communities this RD belongs 6) Distribution Policy The Aggregation policy in this database object is listed as: 1) Aggregator location Location is listed as both RDI (AS) and the NET 2) Prefix that represents the aggregation 3) prefixes that will be are routed by the aggregated prefix 4) Type of Aggregation Whether the aggregation is proxy or or by the RD holding the routing. Below a description of a three database objects for CLNS routing domains are defined. These objects directly mirror the IP objects defined in the paper RIPE 81 [1] to improve the cross use of tools. The following uses of the information are envisioned: 1) The attributes describing routing policy are intended to be set-up such that routing tables for static inter-domain routing can be derived from them or existing routing can be checked against the described policy. 2) Bootstrapping host to host communication by providing an iso_hosts table 3) With the advent the dynamic inter-domain routin, these objects may be used to configure the initial IDRP sesions. It is desired that tools are made to serve these tasks. It is understood that the object as described below is subject to change when CLNS routing developes. In an appendix, some generally used combinations of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI) are shown. The RIPE database expects NSAPs or prefixes to be formatted with dots, seperating the first two and then every next four digits. CLNS routing-domain object Page 3 Object Summary _______________ Registration of ISO Prefixes: i-prefix: iso-prefix/length prefix-name: character descr: country: admin-c: tech-c: colors: RDI: community: rev-srv: changed: source: Registration of ISO capability Hosts: i-net: NET type: <bis> <is> <host> host-name: character descr: country: admin-c: tech-c: guardian: saps: RDI: applications: rev-srv: changed: source: Registration of RDIs and policy: RDI: [ASxxxx or RDIxxx] RDI-name: descr: RDI-in: RDI-out: default: (points to what RDI) bis: NETs tech-c: admin-c: guardian: source: changed: Registration of Aggregates: i-aggr: iso-prefix descr: i-aggr-prefix: (repeated several times) i-aggr-type: <proxy> <originator> country: admin-c: tech-c: connect: i-aggr-RDI: rev-srv: changed: source: ====== iso_prefix: Defines an IDRP prefix. It consists of a NSAP prefix followed by a "/" and a length Example: 47.0005.80ff.ff00/48 RDI: Defines an unique routing domain, characterised by a NSAP prefix , within a certain prefix hierarchy. Example: RDI: RD39.528f.1100 AS1200 - Use the AS to RDI mapping used by IDRP for IP RDI-name: String representing the routing domain. Format: Text string. Example: RDI-name: SURFnet-CLNS descr: Description of the organisation and place of its location Format is equal to the descr attribute as defined for IP autonomous systems in [1]. CLNS routing-domain object Page 4 RDI-in: Description of accepted routing domain prefixes, from other domain BIS. Analogue to "as-in" in [1]. Format:< dom-prefix > < cost> <routing policy expression > For every BIS you peer with, there should be such an entry <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <cost> is a relative cost to discriminate between different routes to the same domain. The lowest cost gives the most preferred route. <routing policy expression > can be expressed in the following way's 1: list of "dom-prefixes" Example: RDI-in: RD39.528f.1103 100 39.124F/24 47.0005/24 Example2: RDI-IN: AS1139 100 39 47 2: KEYWORD Only one keyword for the moment ANY - accept everything you get announced. 3: A logical expression of 1 and/or 2. The following operators should be defined AND OR NOT Parenthesis are used to group rules. Example: dom-in: 39.528f.1103 ANY AND NOT 39.756f Accept all announcements from EMPB BIS except for the Switzerland routing domain. 3: Community Name equivalent to [1] RDI-out: Routing domain prefixes announced to other BIS'. Analogue to the "as-out' tag in [1]. Format : <RDI> <routing policy expression > <RDI> is the routing domain prefix where the BIS you peer with belongs to. <routing policy expression > As defined with the RDI-in tag. Example: RDI-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10 Advertise to Europanet the SURFnet-CLNS routing domain but not the PTT-Research routing domain. default: Indication how default routing is done default: < RDI> <cost> <RDI> again is the RDI where the the default routes are passed. <cost> indicates which default path is preferred. The lower cost gives the preffered path Example: default: 39.528f.1103 10 Default points to is routed to 39.528f.1103. This default may be passed from multiple routers. saps: Well-known transport Service Access Points (SAP)s that this node supports over CLNP. TCP, UDP, TP4, skinny stack. admin-c: Administrative contact. Format equal to admin-c in [1]. tech-c: Technical contact Format equal to tech-c in [1]. guardian: e-mail and/or postal address of domain guardian. Analogue to AS guardian in [1]. source: Source of the information. Equal to source field in [1]. remark: remarks or comments Equal to remark field in [1] changed: Who and when of last change. Equal to change field in [1]. CLNS routing-domain object Page 7 Example: _________ i-prefix: 39.528f.1103/40 prefix-name: SURFNET-C descr: SURFnet-CLNS domain country: NL admin-c: Victor Reijgs tech-c: Henk Steenman guardian: domain-guardian@surfnet. connect: RDI: RD39.528f.1100 rev-srv: changed: 2-9-94 source: RIPE i-prefix: 39.528f.1100.0009.10/64 prefix-name: PTT-1 descr: PTT CLNS domain country: NL admin-c: Victor Reijgs tech-c: Henk Steenman guardian: domain-guardian@surfnet. connect: RDI: RD39.528f.1100 rev-srv: changed: 2-9-94 source: RIPE i-net: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 i-type: bis host-name: bis.empb.surfnet.net descr: Bis that connects surfnet to EMPB cisco-4 country: NL admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl saps: TUBA, TP4, TCP RDI: RD39.528f.110 applications: ftp, telnet, smtp rev-srv: source: RIPE changed: henk(a)sara.nl 930716 RDI-prefix: RD39.528f.1100 RDI-name SURFnet-CLNS descr: SURFnet-CLNS domain. bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103 dom-in: 39.528f.1103 100 ANY AND NOT 39.528f.1100.0009.10 dom-in: 39.528f.1100.0009.10 100 39.528f.1100.0009.10 dom-in: AS1183 39.528f.1100 dom-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10 dom-out: 39.528f.1100.0009.10 39.528f.1100 dom-out: AS1183 39.528f.1100 default: 39.528f.1103 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 RDI-Prefix: RD39.528f.1103 RDI-name: EMPB descr: European Backbone (rest of entry is truncated for this example) RDI-Prefix: 39.528f.1103 RDI-name: EMPB descr: European Backbone bis: (rest of entry is truncated for this example) RDI-Prefix: RD39.528f.1100.0009.10 RDI-name: PTT-Research descr: PTT Research network (rest of entry is truncated for this example) RDI-Prefix: AS1183 RDI-name: Interconnect AS descr: Interconnect AS to US vai ANSNET i-aggr: 39.528f.1100/40 i-aggre-name: NL-SURFNET-aggr1 descr: NL SURFNET aggregate i-aggr-prefix: 39.528f.1100.03/48 i-aggr-prefix: 39.528f.1100.04/48 i-aggr-RDI: AS1183 country: NL admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 (Below text needs to be verified:) SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one, 39.528f.1100.0009.10, which is PTT-research that is connected to both EMPB and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix. SURFnet announces to EMPB, 39.528f.1100 but not 39.528f.1100.0009.10. To PTT-research only 39.528f.1100 is announced. AS1183 is to represent the AS number that this network uses. This AS number can be used if the IP and CLNP networks are the same. With in the SURFNET addresses, the aggregates 39.528f.1100.03 and 39.528f.1100.04 are aggregated to 39.528f.1100. Translated to static routing; on the SURFnet BIS connected to PTT- research, there is a static route to 39.528f.1100.0009.10. And on the SURFnet BIS connected to EMPB there is a static route to all other know prefixes. On both the PTT-reserach and EMPB BIS's connected to SURFnet there is a static route to 39.528f.1100. Alternate example with names used instead of the numerical sequences. RDI-prefix: RD39.528f.1100 RDI-name SURFnet-CLNS descr: SURFnet-CLNS domain. bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 EMPB dom-in: EMPB 100 ANY AND NOT PTT-1 dom-in: PTT-Research 100 PTT-1 dom-out: EMPB SURFNET-C AND NOT PTT-1 dom-out: PTT-1 SURFNET-C default: EMPB 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 Registration of ISO capable Hosts: i-net: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 EMPB type: bis host-name: BIS.EMPB descr: EMPB hosts country: NL admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 Appendix A ------- Definition of NSAP structure is defined in OSI 8348 Ad2 [2]. In general: NSAP's are always an integer number of octets where the AFI is always one octet and the IDI is always an integer number of octets. NSAP's are hierarchical structured and once the AFI is decided upon, structuring of the rest of the NSAP is up to authorities down the tree. Two common AFI are 47 and 39 and can be described by some general rules. AFI: 39 Describes that the following two octets are the ISO DCC country codes. Since these codes are always described by three digits, padding with an "f" is necessary to complete the 2 octets. Further structure is done by the authority for each country and there is no general rule. AFI: 47 IDI: 4 defines OSINET. Followed by a two byte organisation identifier. IDI: 5 defines US-GOSIP Version 1 defines a two byte organisation identifier. Version 2 defines a one byte data format identifier, a two byte zero field a three byte administrative authority a two byte routing domain id. CLNS routing-domain object Page 9 References __________ [1] : RIPE-81, Representation of IP routing Policies in the RIPE database, Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and Marten Terpstra, Feb. 1993 [2] : OSI 8348 Ad2 Network Services Definition, Addendum 2, covering Network Layer Addressing.

2 1

MK domain registration in the RIPE DB
by Milan Sterba 23 Mar '94

23 Mar '94

Dear colleague, I have just noticed, that MK is a coorectly registered domain in the DNS However there is no cooresponding entry in the RIPE database. Please could you update the RIPE database accordingly, it helps a lot, especially with newly connected countrie. Thanks Best regards Milan Sterba -- ====================================================================== Prague University of Economics e-mail : Milan.Sterba(a)vse.cz Computing Center tel : +42 2 24 21 79 00 nam. W. Churchilla 4 home: +42 2 823 78 59 130 67 Praha 3 fax : +42 2 24 22 42 66 Czech republic =======================================================================

1 0

DRAFT input for the RIPE database on NSAP addresses for SURFnet bv
by Victor Reijs 18 Mar '94

18 Mar '94

Hello all of you, Below you find the DRAFT entries for CLNS domain for SURFnet bv. There are still some open ends: - I introduced the guardian list: clns-domain-guardian. This because the IP and CLNS guardians coudl be different persons/organisations. What is the idea of RIPE for this? - I changed the responsibility of entry with relation to my earlier mail. It now seems to be more alligned with the existing IP world. - Marcel, are you still pushing ISO to include the top-levels of NSAP domains in the RIPe database? Together with the DUtch NSO (NNI) we could jointly put presure on ISO. - I am trying to get the Dutch NSO (NNI) involved in their entries. - syntax checking is, I assume, not yet their (including logical checking, like bis info, domain info, routing info, etc.). The CLNS coordination group will have to look at that. Marcel? If people have remarks to the below entries, please let me know. I plan to input the entries next week in the RIPE database. All the best, Victor - ---- remark: I introduced the a new guardian address for CLNS-domains. remark: it is: clns-domain-gaurdian@... dom-prefix: 39 dom-name: AFI for ISO-DCC NSAP address scheme (binary DSP syntax) admin-c: someone from ISO guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 remark: Just to start the hierarchy in the RIPE database, this record remark: has been temporarily made by someone else then ISO. remark: In future this record must be ownded by ISO. dom-prefix: 38 dom-name: AFI for ISO-DCC NSAP address scheme (decimal DSP syntax) admin-c: someone from ISO guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 remark: Just to start the hierarchy in the RIPE database, this record remark: has been temporarily made by someone else then ISO. remark: In future this record must be ownded by ISO. dom-prefix: 39.528f dom-name: DCC NSAP address scheme for the Netherlands (binary DSP syntax) desc: NNI desc: Postbus 5059 desc: 2600 GB Delft desc: The Netherlands admin-c: someone from NNI guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 remark: Just to start the hierarchy in the RIPE database, this record remark: has been temporarily made by someone else then NNI. remark: In future this record must be ownded by NNI. dom-prefix: 38.528 dom-name: DCC NSAP address scheme for the Netherlands (decimal DSP syntax ) desc: NNI desc: Postbus 5059 desc: 2600 GB Delft desc: The Netherlands admin-c: someone from NNI guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 remark: Just to start the hierarchy in the RIPE database, this record remark: has been temporarily made by someone else then NNI. remark: In future this record must be ownded by NNI. dom-prefix: 38.5281.100 dom-name: SURFnet-CLNS domain (decimal DSP syntax) descr: SURFnet bv descr: P.O. Box 19035 descr: 3501 DA Urecht descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: victor.reijs(a)surfnet.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100 dom-name: SURFnet-CLNS domain (binary DSP syntax) descr: SURFnet bv descr: P.O. Box 19035 descr: 3501 DA Urecht descr: The Netherlands admin-c: Victor.Reijs.surfnet.nl tech-c: Victor.Reijs(a)surfnet.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.1000.10 dom-name: CLNS domain for DECnet IV and DECnet/OSI descr: SURFnet bv descr: P.O. Box 19035 descr: 3501 DA Urecht descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: pve(a)kub.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.1000.20 descr: CLNS domain for SURFnet CLNS test backbone descr: SURFnet bv descr: P.O. Box 19035 descr: 3501 DA Urecht descr: The Netherlands bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103 dom-in: 39.528f.1103 100 ANY AND NOT 39.528f.1100.0009.10 dom-in: 39.528f.1100000910 100 39528f1100000910 dom-out: 39.528f.1103 39528f1100 AND NOT 39.528f.1100.0009.10 dom-out: 39.528f.1100.0009.10 39.528f.1100 default: 39.528f.1103 10 admin-c: Victor.Reijs(a)surfnet.nl tech-c: henk_steenman(a)sara.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.1000.30 dom-name: CLNS domain for SURFnet CLNS production backbone descr: SURFnet bv descr: P.O. Box 19035 descr: 3501 DA Urecht descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: henk_steenman(a)sara.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.0009.10 dom-name: CLNS domain of SARA descr: SARA descr: Kruislaan 415 descr: 1098 SJ Amsterdam descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: Henk_steenman(a)sara.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.0000.90 dom-name: CLNS domain of TU Delft descr: TU Delft descr: Michiel de Ruyterweg 10-12 descr: 2628 BA Delft descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: B.Zorn(a)ET.TUDelft.NL guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.0012.30 dim-name: CLNS domain of SURFnet bv desc: SURFnet bv desc: P.O. Box 19035 desc: 3501 DA Urecht desc: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: Victor.Reijs(a)surfnet.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 dom-prefix: 39.528f.1100.0009.10 dom-name: PTT Research - TUBA/CLNS Testnetwork descr: PTT Research descr: St. Paulusstraat 4 descr: P.O. Box 421 descr: Leidschendam descr: The Netherlands bis: 39.528f.1100.0009.1000.0000.0040.0000.0c03.df7d.00 39.528f.1100.1000.20 bis: 39.528f.1100.0009.1000.0000.0040.0000.0c04.5eaf.00 39.528f.1103 dom-in: 39.528f.1100.1000.20 39.528f.1100 dom-in: 39.528f.1103 ANY AND NOT 39.528f.1100 dom-out: 39.528f.1100.1000.20 39.528f.1100.0009.10 dom-out: 39.528f.1103 39.528f.1100.0009.10 default: 39.528f.1103 10 admin-c: Victor.Reijs(a)surfnet.nl tech-c: A.A.L.Reijnierse(a)research.ptt.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: A.A.L.Reijnierse(a)research.ptt.nl 940228 dom-prefix: 39.528f.1100.001.10 dom-name: CLNS domain of KUB descr: KUB descr: Hogeschoollaan 225 descr: 5037 GC Tilburg descr: The Netherlands admin-c: Victor.Reijs(a)surfnet.nl tech-c: martin(a)kub.nl guardian: clns-domain-guardian(a)nic.surfnet.nl source: RIPE changed: victor.reijs(a)surfnet.nl 940228 ------- End of Forwarded Message

4 6

Re: draft Dutch RIPE entries
by Victor Reijs 17 Mar '94

17 Mar '94

------- Forwarded Message Date: Thu, 17 Mar 1994 22:22:07 +0100 From: Victor Reijs <Victor.Reijs(a)SURFnet.nl> To: Susan Hares <skh(a)merit.edu> cc: epg(a)merit.edu, jyy(a)merit.edu, sn3plus-clns(a)SURFnet.nl Subject: Re: draft Dutch RIPe entries ==> From: Susan Hares > Victor: > > Thanks for the entries. However, the reason I wanted > to reconsider the top 39,47 entries is that they > are "summary" routes. No one AS (or RDI as the ISO INdeed, these are more there so let people know that someone is responsible for the above level. > folks in IDRP call it.) has this within it's bounds. > So, we must treat it more like an aggregate. > > I think that perhaps we really need to re-emphasize > the difference between RDI and iso prefixes. > > Did my concern come across in the other mail? > I'll be glad to chat with Hank. > Certainly, that is also the reason why I posted the message to Henk. He is the writer of the document, so I think he also should react. I indeed hope that you both will start chating;-) > OSI route and IP routes should be of the same > type of information, just different formats for > the addresses. Did that make sense to you? That is also my idea. I know there is somesemantic difference in wording, but lets try to make things as analgue as possible (beut difference should be stressed, that no confusing will start!). Two things are for me VERY important when using the RIPE database. It is with regard to 'consent' during database updates by differnet people from different hierarchical layers: - - when somebody inputs a NEW entry below another entry (seen in hierarchy), the highest should get a message about that update. Remark: I still see the 'first somebody' as the guardian of its inputted record! - - somebody is NOT allowed to change the routing in their record without the approval of the higher hierarchy. This to guard that no routing loops will occur. What do people think about this!!! So this message was about two things: - - the document of Henk. Please Henk and Sue try to get concensis. - - the autorisation mechanism ([preferrable automatic] checking tools) during the input session for the RIPE database. Please database-workgroup react on this. All the best, Victor > > Sue ------- End of Forwarded Message

1 0

Routing prefixes in the RIPE database?
by Havard Eidnes 11 Mar '94

11 Mar '94

Sorry to those of you who see this twice, I mis-spelt one of the addresses and want both groups to receive copies of any resulting discussion. - Havard ------------------------------ Message-Id: <9403092125.AA28955@ravn> To: routing-wg(a)ripe.net Cc: db-gw(a)ripe.net, hostmaster(a)sunet.se, hostmaster(a)uninett.no Subject: Routing prefixes in the RIPE database? Date: Wed, 09 Mar 1994 22:25:48 +0100 From: Havard Eidnes <Havard.Eidnes(a)runit.sintef.no> Hi, all. I've been thinking about what we should do wrt. routing prefixes that are not "natural" network numbers, ie. what should be done about CIDR routes. This was prompted by fear that the Merit people would get "confused" because the routing prefixes we send in NACRs for these days are not directly found in the RIPE database, but it would perhaps also make sense as seen from a general perspective to register routing prefixes (ie. CIDR routes) in the RIPE database. Point for discussion: 1) should we try to register routing prefixes as such in the RIPE database? I know some argue that should not be necessary, eg. with the counter- argument being "you can use 'show ip bgp <prefix>' and thereby inspect the 'aggregator' attribute to get a handle on where to direct trouble reports" etc. etc. However, this only works as long as the prefix is reachable, so... Also, how will this show up in the BGP routing table if it isn't really BGP routes which are aggregated, but the aggregate is "locally originated" in the AS in question? If I am correct in my guesses here, this all points in the direction of registering the prefixes administratively. If there is consensus that we should try to register routing prefixes in the database, I have the following proposals/suggestions: 2) the routing prefix should be a separate object from the "inetnum" object. The reasoning behind this is that "inetnum" is mostly used for registering assignments of natural network numbers -- the ranges registered are not always of power-of-2 size, so cannot be represented as a single routing prefix. I suggest "rout-pfx" as long-form name. 3) the format when registering a routing prefix could be <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the obvious in-between. 4) lookup of a "natural IP network number" with WHOIS in the RIPE database should give as result all the routing prefixes it is a part of, as well as the traditional "inetnum" output. Hint for implementation in the RIPE database: from a routing prefix eg. "129.240/15" create keys for all the natural IP network numbers covered by this prefix with pointers to the routing prefix object. This should be a fairly straight-forward approach (say I who haven't really hacked on the RIPE software... ;-) Side-effect: lookup of unassigned network numbers within a routing prefix after this change will no longer give the "No entries found for the selected source(s)" result when whois is used, but instead the routing prefix(es) will be returned, but no inetnum object. I haven't really thought much about what attributes the "rout-pfx" object should/could contain -- there probably shouldn't be all that many, and we can probably give a pointer for recursion via the AS where the aggregate is originated (and we all have our ASes registered, right? ;-). Comments? - Havard

5 5

NSAP address registration/authorization
by Victor Reijs 25 Feb '94

25 Feb '94

Hello all of you, Because we now have the RIPE database, I am investigating how we could registrate the addressing including defining the authorities. I hope to do thing together with the NNI (the NSO of the Netherlands). What do I have in mind (and please provide you remarks on this!): - I define 'domain' in this case as: part of the NSAP address starting at the beginning of the NSAP address and ending at some hierarchical point in the NSAP address structure. - - try to stimulate ISO, to put in the top level 'domains' in the RIPE database. They are the 'domain' authority of e.g. 38, 38, 47, etc. So dom-prefix, dom-name, descr, admin-c, source, remark, changed and guardian are under authority of ISO. No routing info is allowed. - try to stimulate ISO to put in the 'domains' that are part of the authority of ISO, e.g. 38 xxx (where XXX is DCC). So every country (like Holland) gets an entry in the RIPE database. So dom-prefix, dom-name, descr, admin-c, source, remark, changed, guardian are under authority of ISO. tech-c could be under authority of NSO. No routing info is allowed. - try to stimulate BSI to put in 'domain' 47 xxx (where xxx= ICD). So every international organization (like NORDUNET) gets an RIPE database entry. So dom-prefix, dom-name, descr, admin-c, source, remark, changed and guardian are under authority of BSI. tech-c could be under authority of intern. organization. No routing info is allowed. - - try to stimulate the NSO (in case of DCC, like NNI, AFNOR) to input their 'domains'. So every national organization (like SURFnet bv) gets an entry in the database. So dom-prefix, dom-name, descr, admin-c, source, remark, changed and guardian are under authority of NSO. Routing information will be given under authority of the national organization. tech-c could be under authority of national organization. - - the national organization (like SURFnet bv) inputs its 'domains' in the RIPE database. So every institute/etc. (like SARA) gets an entry. So dom-prefix, dom-name, descr, admin-c, source, remark, changed and guardian are under authority of nat. organization. tech-c could be under authority of institute. Routing information (if different from the nat.organization) can inputed by insitute, only with the consent of the nat. organization. So NO change may be made to this information without agreement with national organization. Remark: I interpretated 'guardian' as a person that gets information when something is changed. I think no more leveling is needed. If so let me know. Is the above scene workable? All the best, Victor

1 0

New Document available: ripe-108
by RIPE NCC Document Annoucement Service 11 Feb '94

11 Feb '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-108 Title: Support of Guarded fields within the RIPE Database Author: Tony Bates Date: 11 February 1994 Format: PS=45180 TXT=18019 bytes Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-docs" followed by the command "get filename". The relevant filenames for this document are: ripe-108.txt for the ASCII version ripe-108.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document. SEND ripe/docs/ripe-docs/ripe-108.txt

1 0

Guarded Attributes (IMPORTANT)
by Marten Terpstra 03 Feb '94

03 Feb '94

[Apologies for wide distribution, think it is important though] Folks, Please find below a slightly updated version of the guarded attribute procedure document. For those of you who manage an AS, please not that starting coming Monday, the aut-sys field in the network object will become guarded, and can only be updated thru the procedure described below. We have created accounts for all ASes we currently see routed in Europe, and if you do not have your account yet, please come and get it as soon as possible and check out the files we have created for you. Please send requests for these accounts to <ripe-dbm(a)ripe.net>. Also if you know some of your AS neighbors have not got their account yet, and are perhaps not on any of these lists, pass this message. If you have questions, send them to ripe-dbm(a)ripe.net as well, or directly to me. -Marten Support of Guarded fields within the RIPE Database * FINAL DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW ripe-1nn.txt February 3, 1994 - 2 - aut-sys: AS1104 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS<positive integer between 1 and 65535> (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the <routing policy expression> KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt February 3, 1994 - 3 - Multiple text strings representing the routing privilege. bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt February 3, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt February 3, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Any changes of other (unguarded) fields in the update will be checked for syntactic correctness and if they pass will go through to the database irrespective of any conflicts for the guarded fields. When through the normal database update procedure an object with guarded attributes is deleted, the guardians of these guarded attri- butes will be notified of this deletion. Only deletions will be notified in this way to guardians. For normal changes the "notify" attribute of the database should be used. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. To have complete guardian accounts removed from the NCC machine, and thus all references to this guarded value, please contact the RIPE NCC at <ripe-dbm(a)ripe.net>. Removing an account and the guardian file that goes with it means that this guarded value will not be added any longer to any of the objects in the database. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the ripe-1nn.txt February 3, 1994 - 6 - correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt February 3, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra(a)gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt February 3, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt February 3, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt February 3, 1994

1 0

Revised proposol CLNS domain object:
by Henk Steenman 02 Feb '94

02 Feb '94

Based on the outcome of some discussion during the presentation of the dom-prefix at the last RIPE database workgroup meeting I have added/changed the following. 1: Prefixes or NSAPs are to be formatted with dots. The first dot defines the AFI and comes after the first two digits. Every next four digits should be seperated by dots. 2: The cost associated with default routing should be interpreted such that the prefered path has the lowest cost. - Henk Steenman ----------------------------- Cut here ------------------------------------- CLNS routing-domain object for the RIPE database Version 1.3 Feb 1994 Henk Steenman Henk_Steenman(a)sara.nl +31 20 5928038 CLNS routing-domain object Page 2 Introduction. ____________ In the RARE lower layer technology work group for CLNS it was recognised that in order to coordinate routing between CLNS routing domains a central registry for such domains was necessary. At a meeting of the work group at the 27 IETF in Amsterdam it was decided to write a registry specification. At this meeting the RIPE NCC offered to extend their database for IP domains/networks with CLNS related objects if a sound proposal came forward. Below a description of a database object for CLNS routing domains is defined. The object can be used to describe some general information of a CLNS routing domain such as NSAP prefix, name, description and responsible persons. It can also be used to describe routing policies in a manner comparable to that for IP domains ( AS's ) as defined in the paper RIPE 81 [1]. The attributes describing routing policy are intended to be set-up such that routing tables for static inter-domain routing can be derived from them or excisting routing can be checked against the described policy. It is desired that tools are made to serve these tasks. It is understood that the object as described below is subject to change when CLNS routing developes. An example of this could be the future availability of IDRP for dynamic inter-domain routing. In an appendix, some generally used combinations of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI) are shown. The RIPE database expects NSAPs or prefixes to be formatted with dots, seperating the first two and then every next four digits. CLNS routing-domain object Page 3 Object Description _________________ dom-prefix: Defines an unique routing domain, characterised by a NSAP prefix , within a certain prefix hierarchy. Example: dom-prefix: 39.528f.1100 dom-name: String representing the routing domain. Format: Text string. Example: dom-name: SURFnet-CLNS descr: Description of the organisation and place of its location Format is equal to the descr attribute as defined for IP autonomous systems in [1]. bis: Format : < bis NET > < dom-prefix > NET of boundary intermediate system to between two domains Example: SURFnet BIS for EuropaNet bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103 CLNS routing-domain object Page 4 dom-in: Description of accepted routing domain prefixes, from other domain BIS. Analogue to "as-in" in [1]. Format:< dom-prefix > < cost> <routing policy expression > For every BIS you peer with, there should be such an entry <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <cost> is a relative cost to discriminate between different routes to the same domain. The lowest cost gives the most preferred route. <routing policy expression > can be expressed in the following way's 1: list of "dom-prefixes" Example: dom-in: 39.528f.1103 100 39.124F 47.0005 2: KEYWORD Only one keyword for the moment ANY - accept everything you get announced. 3: A logical expression of 1 and/or 2. The following operators should be defined AND OR NOT Parenthesis are used to group rules. Example: dom-in: 39.528f.1103 ANY AND NOT 39.756f Accept all announcements from EMPB BIS except for the Switzerland routing domain. CLNS routing-domain object Page 5 dom-out: Routing domain prefixes announced to other BIS'. Analogue to the "as-out' tag in [1]. Format : < dom-prefix > <routing policy expression > <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <routing policy expression > As defined with the dom-in tag. Example: dom-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10 Advertise to Europanet the SURFnet-CLNS routing domain but not the PTT-Research routing domain. default: Indication how default routing is done default: < dom-prefix> <cost> <dom-prefix> again is the prefix of the domain where the BIS peer is in. <cost> indicates which default path is preferred. The lower cost gives the preffered path Example: default: 39.528f.1103 10 Default everything is routed to 39.528f.1103 CLNS routing-domain object Page 6 admin-c: Administrative contact. Format equal to admin-c in [1]. tech-c: Technical contact Format equal to tech-c in [1]. guardian: e-mail and/or postal address of domain guardian. Analogue to AS guardian in [1]. source: Source of the information. Equal to source field in [1]. remark: remarks or comments Equal to remark field in [1] changed: Who and when of last change. Equal to change field in [1]. CLNS routing-domain object Page 7 Example: _________ dom-prefix: 39.528f.1100 descr: SURFnet-CLNS domain. bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103 dom-in: 39.528f.1103 100 ANY AND NOT 39.528f.1100.0009.10 dom-in: 39.528f.1100.0009.10 100 39.528f.1100.0009.10 dom-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10 dom-out: 39.528f.1100.0009.10 39.528f.1100 default: 39.528f.1103 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one, 39.528f.1100.0009.10, which is PTT-research that is connected to both EMPB and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix. SURFnet announces to EMPB, 39.528f.1100 but not 39.528f.1100.0009.10. To PTT-research only 39.528f.1100 is announced. Translated to static routing; on the SURFnet BIS connected to PTT- research, there is a static route to 39.528f.1100.0009.10. And on the SURFnet BIS connected to EMPB there is a static route to all other know prefixes. On both the PTT-reserach and EMPB BIS's connected to SURFnet there is a static route to 39.528f.1100. CLNS routing-domain object Page 8 Appendix A. ___________ Definition of NSAP structure is defined in OSI 8348 Ad2 [2]. In general: NSAP's are always an integer number of octets where the AFI is always one octet and the IDI is always an integer number of octets. NSAP's are hierarchical structured and once the AFI is decided upon, structuring of the rest of the NSAP is up to authorities down the tree. Two common AFI are 47 and 39 and can be described by some general rules. AFI: 39 Describes that the following two octets are the ISO DCC country codes. Since these codes are always described by three digits, padding with an "f" is necessary to complete the 2 octets. Further structure is done by the authority for each country and there is no general rule. AFI: 47 IDI: 4 defines OSINET. Followed by a two byte organisation identifier. IDI: 5 defines US-GOSIP Version 1 defines a two byte organisation identifier. Version 2 defines a one byte data format identifier, a two byte zero field a three byte administrative authority a two byte routing domain id. CLNS routing-domain object Page 9 References __________ [1] : RIPE-81, Representation of IP routing Policies in the RIPE database, Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and Marten Terpstra, Feb. 1993 [2] : OSI 8348 Ad2 Network Services Definition, Addendum 2, covering Network Layer Addressing. --------

1 0

Draft minutes 17th RIPE meeting: DB-WG
by Wilfried Woeber, UniVie/ACOnet 02 Feb '94

02 Feb '94

Dear all, this is the draft minutes of the Database-WG meeting(s) at the 17th RIPE meeting. Any input and comments welcome, especially from those being affected by these things in one way or the other :-). Best regards, Wilfried. -------------------- start of draft minutes -------------------- 17th RIPE Meeting: Draft minutes for the DB-Working-Group meeting 25.1.1993, Amsterdam. ----------------------------------------------------------------------------- Due to the scheduling (and the un-avoidable overlap) of some WG meetings, the items on the agenda were treated in a different order than originally proposed. However the minutes follow the original ordering. 0. Opening, Scribe, Admin The DB-WG meeting was opened and Ruediger Volk volunteered to take notes. As a direct result of the preceding meeting of the Routing-WG and following other discussions the proposed agenda was amended (DB statistics for Domain-Object, maintainance of e-mail attribute and .forward files for guarded objects, timing considerations for guarded objects and values, aspects of ownership of objects and deletions and inter-dependancies). 1. New Databse software 1.1 . current status Marten Terpstra gave a concise report on the current state of the "new" database software. Due to timing constraints (and the lack of documentation) there is still no official distribution of the "New DB Software". However it has already been successfully installed at a couple of sites. The slides for the presentation can be found in ftp.ripe.net:ripe/presentations/ripe-m17-marten-DB.ps.Z 1.2 . experiences No operational problems were mentioned. Operation of the software, including the organizational environment, is going very smooth and was generally appreciated. 1.3 . documentation (who, how, when, what) Documentation is still missing. A new effort is needed and will be made early February. It has to be taken into account, that Marten Terpstra will primarily work on the PRIDE project, reducing his involvement with the DB software. Action (Wilfried Woeber, NCC): produce the necessary documentation for the new DB software. 2. RIPE-Handles RIPE-Handles are urgently needed to make progress in the area of Database Exchange. Several possible methods of assigning these handles were discussed. the group reached consensus that the RIPE-Handles will be of the form RIPE-XYZ9999. It was decided that from the DB's point of view, there exists only ONE handle: the RIPE-Handle. Thus this handle is stored in the person object in the "nic-hdl:" attribute. For the initial population/conversion of the current entries, the value of the NIC-Handle will be taken and converted to a RIPE-Handle by appending the string "-RIPE". E.g. the NIC-Handle for Wilfried Woeber (WW144) will be converted to form the RIPE-Handle (WW144-RIPE). This conversion will be done only once for the inital population. There will then be a short period, when missing handles can be provided by means of "vanity-handles". After a to-be-announced flag-day, RIPE-Handles will be required for any operation on person objects in the Database. Any vanity handles used MUST be properly registered with the NCC! The same syntax has already been adopted by the JPNIC and the AUNIC. *** Please note that during the discussion (by accident) we all were talking about a prefix format *** The NCC was mandated to circulate an updated proposal, including operational aspects, and after a short review-process (e-mail), go ahead with the implementation. Action (NCC): update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation. 3. PRIDE - DB Interaction Editorial comment: RIPE-81++ was treated in the Routing-WG. Currently there is no real pending issue with regard to the interaction between the PRIDE project and the RIPE-DB. After discussing possible future modifications or additions to DB objects, the NCC was mandated to go ahead and implement changes/additions to support the PRIDE project (like the hidden flags/options), unless there is a direct influence on operational aspects or changes to the user interface to the RIPE-DB. 4. Future needs 4.2 . Delete Operation vs Guarded Field interaction Various aspects of implementation of guarded objects were reviewed. With regard to possible "delete:" operation on network objects that are tagged with a guarded AS-value, consensus was to automatically notify the guardian of the AS-value. Changes to such objects do NOT generate a notification message. This functionality can be achieved by using the "notify:" attribute. The "notify:" attribute for an object is evaluated before the update is made. The technical issues of RIPE-81 was treated in the Routing-WG. Generally the transaction of deleting an object must be described. The document with the proposal for implementing guarded attributes is to be updated and recirculated for comment (e-mail, 14 days comment period). Then the NCC goes ahead with the implementation as soon as possible. Action (NCC): update and re-circulate the Guarded Fields proposal and then go ahead with the implementation. 4.3 . Phase-out of RIPE-60 stuff Jean-Michel Jouanigot continues to coordinate the migration to the RIPE-81 functionality. Any technical issues treated in the Routing-WG. 4.4 . Tools A proposal to have a certain kind of "template-mode" for checking and/or updating database objects was discussed. Several possible ways of implementing this were discussed (like a special flag for the whois-client, an interactive method at the NCC, providing a full template for further processing). Any solution proposed should be usable on most platforms. Action (NCC): investigate and propose facilities for a "template-mode" to support the maintaining database objects. 4.5 . Syntax checkers (distributed, and/or @ the NCC) The need for syntax-checking facilites for objects was again stated. The NCC was asked to look into providing this functionality and come up with a proposal. Action (NCC): Investigate and propose a syntax-checking facility for the new database software. 5. New/Revised Objects 5.1 . CLNS Routing "dom-prefix:" Henk Steenman provided an introduction to the current version of the proposal to have a database object for CLNS Routing. The only technical amendment discussed was to present the CLNP addresses in the format of xx.xxxx.xxxx.xxxx (no trailing dots). The NCC may have to review the current shell of scripts supporting the database operations for limitations in line-length. The NCC was mandated to go ahead with implementing this object after another short round of review (e-mail) of Henk's updated specification. Action (Henk Steenman): update and re-circulate the "dom-prefix:" proposal. Action (NCC): implement the CLNS Routing Object. >>>>>>>>>>>> I'm going to ask Henk to provide the (updated) proposal for the presentations directory!? 5.2 . status of "connect:" and value "LOCAL" Decision about the future of the "connect:" attribute for a Network Object was postponed after full deployment of the RIPE-81 stuff. It is expected that the "connect:" will be phased out and be replaced by a different mechanism (community?). The "connect:" attribute is no longer mandatory. 5.3 . Domain Object The status of the Domain Object was reviewed, prompted by the fact of poor coverage in the database. Again the object was felt to be useful, although currently there is little operational influence of registering (or NOT registering) domains in the database. Consensus was to ask the DNS-WG to review and maybe update the definition of the Domain Object. Action (Francis Dupont): Have the DNS group review the Domain Object and come up with either a recommendation for retirement or with an updated functionality 5.4 . others The "notify:" attribute is already implemented and is already used by the database software. The "maintainer:" attribute is already implemented but currently not used by the databse software. 6. Exchange Format 6.1 . current status No progress has been made due to the lack of RIPE-Handles. Can be progressed after implementation of RIPE-Handles. 6.2 . recommendations for further action As an aside - the group propsed to NOT enforce uniqueness of network names. 7. DB statistics (Domain-Object) Having stistics about the DB coverage of domains was seen to be potentially useful. Postponed to wait for the Domain Object review by the DNS-WG. 8. Maint. of e-mail: and .forward for guarded objects After evaluating possible szenarios it was decided that an automatic modification of either the "e-mail:" attribute of a guarded object or the .forward file for the guardian's account is not desirable. Responsibility of the maintainance remains with the guardians. 9. Timing considerations for guarded objects, values, secondary DBs Some operational issues of implementing guarded fileds were reviewed. Aspects discussed in more detail were: - timing and interlock: Some mechanism must be set up by the NCC to allow for checking the merge/update status of the current version of the database. This should allow for an automatic delay of retrieving the DB for local use and/or providing read-only copies. The NCC will come up with a technical proposal how to do this. - change control: in order to preserve the update history for databse objects a structured scheme was proposed. This method preserves the "changed:" attributes supplied by any manual update process. In addition to that any automatic up-date and/or merge operation done by the database software maintains a single related "changed:" attribute describing the "agent" performing the modification. From a formal point of view, regular maintainance and/or merge operations are NOT treated as update operations, thus e.g. they do not trigger (automatic) notification messages. Action (NCC): Propose and implement a mechanism to check the current state of the database with regard to garbage-collection and merging of guarding values. Action (NCC): Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification operations. 10. Deletions, Ownership of Objects, Interdependency This was a more general discussion, focussing on issues of "ownership" of objects, inter-dependency of various components and quality of the information in the database. >From a formal point of view, there was agreement that we should stick with the concept that the responsibility for maintaining objects remains with the owner of the object. From an operational point of view it was felt necessary to perform automatic modifications to certain attributes of an objects. In the long run this could eventually lead to splitting objects along the lines of maintainance. This is for further discussion. Concern was voiced that we do not have the concept of winding down the use of methods, removing out-dated information and/or deleting objects, closing guardian's accounts, etc. It was felt that there is a need to analyze, discuss and document these issues. For the time being these aspects have to be covered in individual documents describing certain procedures, in the long run this should be an intrinsic part of the documentation. The aspect of "sanity checking" the information in the databse was shortly touched. Given the current shortage of manpower in the NCC and the important changes to be implemented in the near future this issue was postponed. Z. AOB None. -------------------- end of draft minutes --------------------

1 0

Draft Guarded Field document
by Tony Bates 24 Jan '94

24 Jan '94

Please find enclosed a DRAFT copy of a document describing the Guarded Field procedure. This gives details of both the process for updating guardian files as well as how conflicts are handled. The current status is that the software is in final beta test and all the auto-generated "AS" accounts/files have been generated (see doc for more details). Our plan is to turn the "guarded field" software on in the database on February 7th. There will be a short introduction for both the paper and implementation given in the routing working group session at next weeks RIPE meeting. All comments welcome. We plan to agree and close this document at the RIPE meeting. See you next week. --Tony. Support of Guarded fields within the RIPE Database * DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS1104 ripe-1nn.txt January 19, 1994 - 2 - comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS<positive integer between 1 and 65535> (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the <routing policy expression> KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: Multiple text strings representing the routing privilege. _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt January 19, 1994 - 3 - bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt January 19, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt January 19, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. ripe-1nn.txt January 19, 1994 - 6 - o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt January 19, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra(a)gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt January 19, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt January 19, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt January 19, 1994

3 4

Proposal for a CLNS routing domain object for the RIPE database.
by Henk Steenman 21 Jan '94

21 Jan '94

Here is the proposal for the CLNS routing domain object for the RIPE datase as will be presented next tuesday during the DB workgroup meeting. This version is almost similar as the one presented at a previous RIPE meeting. The main differences are a new attribute "dom-name", an introduction describing shortly why such an object is desired and an appendix that gives a very short comment on the breakdown of NSAP's for some commonly used AFI's. - Henk Steenman SARA, NIC --------------------- CUT HERE --------------------------------------------- CLNS routing-domain object for the RIPE database Version 1.2 Jan 1994 Henk Steenman Henk_Steenman(a)sara.nl +31 20 5928038 CLNS routing-domain object Page 2 Introduction. ____________ In the RARE lower layer technology work group for CLNS it was recognised that in order to coordinate routing between CLNS routing domains a central registry for such domains was necessary. At a meeting of the work group at the 27 IETF in Amsterdam it was decided to write a registry specification. At this meeting the RIPE NCC offered to extend their database for IP domains/networks with CLNS related objects if a sound proposal came forward. Below a description of a database object for CLNS routing domains is defined. The object can be used to describe some general information of a CLNS routing domain such as NSAP prefix, name, description and responsible persons. It can also be used to describe routing policies in a manner comparable to that for IP domains ( AS's ) as defined in the paper RIPE 81 [1]. The attributes describing routing policy are intended to be set-up such that routing tables for static inter-domain routing can be derived from them or excisting routing can be checked against the described policy. It is desired that tools are made to serve these tasks. It is understood that the object as described below is subject to change when CLNS routing developes. An example of this could be the future availability of IDRP for dynamic inter-domain routing. In an appendix, some generally used combinations of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI) are shown. CLNS routing-domain object Page 3 Object Description _________________ dom-prefix: Defines an unique routing domain, characterised by a NSAP prefix , within a certain prefix hierarchy. Example: dom-prefix: 39528f1100 dom-name: String representing the routing domain. Format: Text string. Example: dom-name: SURFnet-CLNS descr: Description of the organisation and place of its location Format is equal to the descr attribute as defined for IP autonomous systems in [1]. bis: Format : < bis NET > < dom-prefix > NET of boundary intermediate system to between two domains Example: SURFnet BIS for EuropaNet bis: 39528f1100100020000000000100000c0429b400 39528f1103 CLNS routing-domain object Page 4 dom-in: Description of accepted routing domain prefixes, from other domain BIS. Analogue to "as-in" in [1]. Format:< dom-prefix > < cost> <routing policy expression > For every BIS you peer with, there should be such an entry <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <cost> is a relative cost to discriminate between different routes to the same domain. The lowest cost gives the most preferred route. <routing policy expression > can be expressed in the following way's 1: list of "dom-prefixes" Example: dom-in: 39528f1103 100 39124F 470005 2: KEYWORD Only one keyword for the moment ANY - accept everything you get announced. 3: A logical expression of 1 and/or 2. The following operators should be defined AND OR NOT Parenthesis are used to group rules. Example: dom-in: 39528f1103 ANY AND NOT 39756f Accept all announcements from EMPB BIS except for the Switzerland routing domain. CLNS routing-domain object Page 5 dom-out: Routing domain prefixes announced to other BIS'. Analogue to the "as-out' tag in [1]. Format : < dom-prefix > <routing policy expression > <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <routing policy expression > As defined with the dom-in tag. Example: dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 Advertise to Europanet the SURFnet-CLNS routing domain but not the PTT-Research routing domain. default: Indication how default routing is done default: < dom-prefix> <cost> <dom-prefix> again is the prefix of the domain where the BIS peer is in. <cost> indicates which default path is preferred. In a static routing environment this doesn't make sense. Example: default: 39528f1103 10 Default everything is routed to 39528f1103 CLNS routing-domain object Page 6 admin-c: Administrative contact. Format equal to admin-c in [1]. tech-c: Technical contact Format equal to tech-c in [1]. guardian: e-mail and/or postal address of domain guardian. Analogue to AS guardian in [1]. source: Source of the information. Equal to source field in [1]. remark: remarks or comments Equal to remark field in [1] changed: Who and when of last change. Equal to change field in [1]. CLNS routing-domain object Page 7 Example: _________ dom-prefix: 39528f1100 descr: SURFnet-CLNS domain. bis: 39528f1100100020000000000100000c0429b400 39528f1103 dom-in: 39528f1103 100 ANY AND NOT 39528f1100000910 dom-in: 39528f1100000910 100 39528f1100000910 dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 dom-out: 39528f1100000910 39528f1100 default: 39528f1103 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one, 39528f1100000910, which is PTT-research that is connected to both EMPB and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix. SURFnet announces to EMPB, 39528f1100 but not 39528f1100000910. To PTT-research only 39528f1100 is announced. Translated to static routing; on the SURFnet BIS connected to PTT- research, there is a static route to 39528f1100000910. And on the SURFnet BIS connected to EMPB there is a static route to all other know prefixes. On both the PTT-reserach and EMPB BIS's connected to SURFnet there is a static route to 39528f1100. ^L ^L CLNS routing-domain object Page 8 Appendix A. ___________ Definition of NSAP structure is defined in OSI 8348 Ad2 [2]. In general: NSAP's are always an integer number of octets where the AFI is always one octet and the IDI is always an integer number of octets. NSAP's are hierarchical structured and once the AFI is decided upon, structuring of the rest of the NSAP is up to authorities down the tree. Two common AFI are 47 and 39 and can be described by some general rules. AFI: 39 Describes that the following two octets are the ISO DCC country codes. Since these codes are always described by three digits, padding with an "f" is necessary to complete the 2 octets. Further structure is done by the authority for each country and there is no general rule. AFI: 47 IDI: 4 defines OSINET. Followed by a two byte organisation identifier. IDI: 5 defines US-GOSIP Version 1 defines a two byte organisation identifier. Version 2 defines a one byte data format identifier, a two byte zero field a three byte administrative authority a two byte routing domain id. ^L ^L CLNS routing-domain object Page 9 References __________ [1] : RIPE-81, Representation of IP routing Policies in the RIPE database, Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and Marten Terpstra, Feb. 1993 [2] : Network Services Definition, Addendum 2, covering Network Layer Addressing.

1 0