- db-wg - mailman.ripe.net

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