- db-wg - mailman.ripe.net

New Draft Document available: ripe-inetnum
by RIPE NCC Draft Document Annoucement Service 10 May '94

10 May '94

Short content description ------------------------- This is to announce a draft update to the inetnum document originally known as ripe-050. 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/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-inetnum.txt for the ASCII version ripe-inetnum.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". MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/drafts/ripe-inetnum.txt

1 0

New Draft Document available: ripe-clarep
by RIPE NCC Draft Document Annoucement Service 10 May '94

10 May '94

This is to announce a draft version of the classless reperesentation document. 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/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-clarep.txt for the ASCII version ripe-clarep.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". MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/drafts/ripe-clarep.txt

1 0

New Draft Document available: ripe-81++
by RIPE NCC Draft Document Annoucement Service 10 May '94

10 May '94

This is to announce a draft version of ripe-81++. 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/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-81++.txt for the ASCII version ripe-81++.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". MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/drafts/ripe-81++.txt

1 0

Classless Registry Drafts
by Daniel Karrenberg 10 May '94

10 May '94

Dear colleagues, we have prepared three draft documents describing how support for classless addresses can be added to the RIPE database. At the same time we propose a clear split between the allocation registry and the routing registry functions of the database. The allocation registry holds information about address space assignments done by Internet registries, while the routing registry holds information about routing policies and is largely maintained by the service providers. The three documents each describe one part of this new database. ripe-81++ - routing registry ripe-inetnum - allocation registry ripe-clarep - representation of classless addresses ripe-81++ is the longest document of the three. It describes the routing registry part of the database. It is a direct descendant of ripe-81. There are major changes as required by the separation of allocation and routing information. Also there is now support for classless routes and hence CIDR aggregation. It is also now possible to describe multiple ASes originating the same route. ripe-inetnum describes the changed inetnum object which is basically stripped of all routing and obsoleted attributes. ripe-inetnum also describes the person object and thus constitutes a complete reference for the allocation registry. ripe-clarep describes the representation of classless addresses in the RIPE database and thus in both the routing and the allocation registry. As these proposals are relevant to all three working groups addressed, we would appreciate if they could be discussed at the upcoming meeting and if at all possible consensus reached at least about the general design behind them. We need to make the registries classless as soon as possible and it will take some time to do the implementation. The documents can be found in ftp.ripe.net:ripe/drafts/<name>.{ps,txt}. We will be sending MIMEd announcements for all three shortly. Comments are very welcome indeed. Daniel Marten Tony

1 0

suggestions for RIPE-81
by Laurent Joncheray 03 May '94

03 May '94

(Sorry if you have already received this information from another list. You can forward this mail to /dev/null.) Merit Network Inc. has been running a Routing Registery for about 3 weeks now. Our software is based on the RIPE database distribution (beta version), plus some changes we did to meet our requirements. The main ones are: - support of aggregates in the inetnum object. - extension to the RIPE-81 policy syntax to support US autonomous system policies (in particular AS 690 - NSFNET) - development of a 'Policy Server' (called alcd) which is used by astrace (a prtraceroute like tool) to query the database (instead of whois). The server does the difficult task of parsing the policy, making prtraceroute and any other tools easier to design. We also developped a few tools to work with the registery. We'd like to propose our new syntax as an official extension for the RIPE-81 document, and ask this working group to discuss/comment/modify it and (I hope) accept it. A detailed description of the syntax is available on rrdb.merit.edu:pub/meritrr/policy_syntax.txt (FTP anonymous) and the main extensions are: - AS path (limited) - Explicit listing of exported/imported networks - Per interface policy description - More detailed default policy This syntax is fully backward compatible with RIPE-81 and the software has been running in production for 3 weeks without any major problems (bugs, bugs... :-). I'd be glad to give a presentation of our registery and tools during the next RIPE meeting but in order to give you time to read and evaluate our work I have sent this announcement. Following are an example of our tools. Enjoy. Laurent PS: Everything (tools, DB software, documentmentation) is available on rrdb.merit.edu:pub/meritrr. PS/2: This is part of my action item from the last RIPE meeting to propose these extensions. Another prtraceroute (called astrace) output: (lpj@merit: 71) astrace ftp.ripe.net Connected to ALC server traceroute to ns.ripe.net (192.87.45.1) with AS and policy additions 1 AS 237 eth1.michnet1.mich.net 35.1.1.127 [INT 0 0] 2 AS 233 fd-0.enss131.t3.ans.net 192.203.195.1 [INP 1 !RO -1] 3 AS 690 t3-1.Cleveland-cnss41.t3.ans.n 140.222.41.2 [!RO -1 !RO -1] 4 AS 690 mf-0.Cleveland-cnss40.t3.ans.n 140.222.40.222 [INT 0 0] 5 AS 690 t3-1.New-York-cnss32.t3.ans.ne 140.222.32.2 [INT 0 0] 6 AS 690 t3-1.Washington-DC-cnss56.t3.a 140.222.56.2 [INT 0 0] 7 AS 690 mf-0.Washington-DC-cnss58.t3.a 140.222.56.194 [INT 0 0] 8 AS 690 t3-0.enss145.t3.ans.net 140.222.145.1 [INT 0 0] 9 AS ??? 192.203.229.245 192.203.229.245 [!RO -1 ?AS 0] 10 AS ??? icm-dc-1-H1/0.icp.net 192.157.65.121 [INT 0 0] 11 AS ??? 192.157.65.226 192.157.65.226 [INT 0 0] 12 AS1128 194.41.0.17 194.41.0.17 [?AS 0 !RO -1] 13 AS1104 hef-router.nikhef.nl 192.87.4.21 [!RO -1 !RO -1] 14 AS3333 ns.ripe.net 192.87.45.1 [!RO -1 !RO -1] AS Path followed: 237 233 690 ??? 1128 1104 3333 AS 237 = MichNet AS 233 = UMnet AS 690 = NSFNET/ANSNET AS1128 = SURFNET-AS AS1104 = SURFNET-AS AS3333 = RIPE-ASNBLOCK4 Example of an aggregate: (lpj@merit: 82) whois -h rrdb.merit.edu 192.87/16 inetnum: 192.87/16 netname: SURFNET-C-AGGR descr: SURFnet descr: P.O. Box 19035 descr: NL-3501 DA Utrecht descr: NETHERLANDS country: NL aut-sys: AS1103 nsf-in: 1=1800 2=1133 3=1674 4=1240 changed: skw(a)merit.edu 940401 source: PRDB The syntax... ------------------------------------------------------------------------------ Copyright (c) 1993 The Regents of the University of Michigan and Merit Network, Inc. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies of the software and derivative works or modified versions thereof, and that both the copyright notice and this permission and disclaimer notice appear in supporting documentation. THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE REGENTS OF THE UNIVERSITY OF MICHIGAN AND MERIT NETWORK, INC. DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET LICENSEE'S REQUIREMENTS OR THAT OPERATION WILL BE UNINTERRUPTED OR ERROR FREE. The Regents of the University of Michigan and Merit Network, Inc. shall not be liable for any special, indirect, incidental or consequential damages with respect to any claim by Licensee or any third party arising from use of the software. -------------------DRAFT DRAFT-------------------------- Representation of Complex Routing Policies of an Autonomous System Version 0.0.3 03-10-94 I. Background The community of IP network providers and operators are unanimous in their desire to define their own routing policies independent of any core infrastructure of the Internet. Due to numerous different routing policies which impact the ability to achieve global connectivity, several groups have worked together to develop a description language which clearly expresses the various policies. RIPE-60 and RIPE-81 tackled the problem of representing the description of routing policies of European Autonomous Systems.[1,2] Yu, Chen, and Rekhter defined a Policy Description Language which describes very complex routing policies. [3] In addition, Laurent Joncheray documented the syntax to describe the policies implemented by Merit's Route Server. [4] The RIPE Network Coordination Center has implemented the recommendations of RIPE-81, and has become a repository for publishing the routing polices of European ASs. The RIPE NCC and Merit Network Inc. have collaborated to define a minimum set of attributes which are needed to represent routing policy, and both organizations will maintain routing policy information based on this minimum set of attributes. In addition to the minimum set, Merit will implement and will define some extensions to the syntax based on previous work [1,2,3,4] which will permit the description of more complex routing policies. As RIPE and Merit continue to collaborate to define a syntax which clearly expressses the routing policies which are implemented by network service providers and operators, our goal is that the registration of routing policies, no matter how simple or complex, will aid the network operators in diagnosing and resolving routing problems. This document focuses on the extensions and defines the attributes which provide the capability to describe more complex routing interactions. The more complex routing policies which can be described include: a. announcements and acceptances of routing information at network granularity b. grouping of networks into communities of interest c. syntax to describe peer gateway interactions/preferences d. expansion of the default syntax e. introduction of transit and exclusion syntax f. syntax to assign metrics to outbound and inbound announcements II. Explanation and Examples of the Policy Description This section describes the routing policy statements. For each statement, the function of the statement is followed by a simple format explanation. Examples of how to use the syntax to express policy are illustrated and the formal syntax is defined in Appendix C. The yacc description in Appendix C is authoritative. Policy is described by six attributes: - 'as-in' and 'as-out' to specify the policy of one AS toward its neighbors. - 'as-transit' and 'as-exclude' to specify the policy in terms of preferred path. - 'as-default', to specify the default policy. -as-aggr, to describe routing aggregation policy 1. Definition of some global key words ANY means any routing information associated with a particular AS. ASANY means any routing information associated with any AS. OTHER means any routing information excluding specified routing information. "net of AS" refers to a net which claims the AS as its home AS. "net via AS" refers to a net which transits an AS. 2. Policy Description Syntax 2.1. as-in attribute The as-in attribute describes the policy of importing routing information from neighboring ASs. The simple format is as-in: [from] neighborAS:preference... [accept] route 'neighborAS:preference' is a pairing of a neighbor AS number and an associated metric. The as-in attribute may contain a list of neighborASs and preferences. When there is a list of neighborAS:preferences, a comma must separate them. For compatibility with RIPE-81, the colon is optional when there is a single neighborAS/preference per as-in attribute. 'neighborAS' is of the form of ASdddd where dddd is the AS number. 'preference' is the preference at which the route will be accepted. It is an integer between 1 and dddd. The lower the value, the higher the degree of preference. 'route' is a list of destinations (or routes) imported from the neighborAS. 'route' can be: - keywords "ANY", "OTHER', 'NONE' - an AS number - a community name - a set of explicit network numbers Routes can be grouped together by the following operators to form expressions: - 'OR' or '||' or ',' for example, "route1 OR route2" means we accept networks belonging to route1 OR route2; the union of the routes - 'NOTIN' or '/' for example, "route1 NOTIN route2" means we accept networks belonging to route1 but not to route2 - 'NOT' or '!' for example, "NOT route1" means we accept networks not belonging to route1 - 'AND' or '&&' for example, "route1 AND route2" means we accept networks belonging to route1 AND route2; the intersection of the routes A note of caution, the word 'AND' may be very confusing with the current common usage of this word. The recommendation is to avoid using 'AND' unless you have carefully checked what the results will be. The use of 'AND' may result in many inconsistencies in the policy. The expressions can be grouped with parentheses. For compatibility with the syntax of RIPE-81, if no operator is present between two routes, the statement will be interpreted with an 'OR' operator. For instance, "AS690 AS1133" will be interpreted as "AS690 OR AS1133." Words in [ ] are optional. Their purpose is to increase the readability of the statement. In the appendix, a more complex syntax is defined to describe different routing policies at different border routers. A DB selector value is also defined. The DB Selector is used to select and AS or network from any database based on its attributes. Examples: 2.1.1. AS183 accepts ANY routes known to AS690 with preference 1 aut-num: AS183 as-in: from AS690:1 accept ANY An alternative way to express this is similar to the RIPE-81 format: aut-num: AS183 as-in: AS690 1 ANY 2.1.2. AS183 accepts all the routes of AS237 from AS690 with preference 1 aut-num: AS183 as-in: from AS690:1 accept AS237 This may also be expressed: aut-num: AS183 as-in: AS690 1 AS237 In this example, AS183 only accepts routes associated with AS237. AS183 does not accept nets from AS690 or any other AS. 2.1.3. AS183 accepts routes of AS237 from AS690 with preference 1 and from AS 701 with preference 2 aut-num: AS183 as-in: from AS690:1, AS701:2 accept AS237 The following format is also acceptable. aut-num: AS183 as-in: AS690 1 AS237 as-in: AS701 2 AS237 2.1.4. AS183 accepts routes of AS237 from AS690 with a preference 1 and from AS701 accepts routes from AS237 and AS233 with a preference 2. AS690 also announces nets from AS233, but AS183 does not accept those routes from AS690. aut-num: AS183 as-in: from AS690:1 accept AS237 as-in: from AS701:2 accept AS237, AS233 2.1.5. AS183 accepts 35/8 and 192.12.18/24 from AS 690 with preference 3 aut-num: AS183 as-in: from AS690:3 accept {35/8, 192.12.18/24} This introduces the capability of describing access lists based on network granularity. Examples 2.1.1-2.1.4 describe access lists that are based on AS granularity. 2.1.6. AS 183 accepts all nets which belong to the CIX community. aut-num: AS183 as-in: from AS690:1 accept CIX_COMMUNITY The community name CIX_COMMUNITY adds the ability to group networks from various ASs into communities so that routing policies can be described for those communities independent of the AS. 2.2. as-out The as-out attribute describes the policy of exporting routing information to neighboring ASs. The simple format is: as-out: [to] neighborAS:metric... [announce] route 'neighborAS:metric' is a pairing of a neighbor AS number and an associated metric. The as-out attribute may contain a list of neighborASs and metrics. The colon is optional when there is a single neighborAS:metric per as-in statement. When there is a list of neighborAS:metrics, a comma must separate them. 'neighborAS' is of the form of ASdddd where dddd is the AS number. 'metric' is the degree of preference at which the AS wants other ASs to accept the routes. It is an integer between 1 and dddd. The lower the value, the higher the degree of preference. Designating a preference in the as-out statement is optional. 'route' is a list of destinations (or routes) exported to the neighbor AS. It has the same format as defined for the as-in attribute. Words in [ ] are optional. Their purpose is to increase the readability of the statement. Examples: 2.2.1. AS 690 advertises routes of AS237 and AS233 to AS 200 aut-num: AS690 as-out: to AS200 announce AS237, AS233 The syntax defined by RIPE-81 is also acceptable. aut-num: AS690 as-out: AS200 AS237 AS233 2.2.2. AS200 advertises routes of AS200 and AS201 as primary and secondary respectively to AS690 aut-num: AS200 as-out: to AS690:1 announce AS200 as-out: to AS690:2 announce AS201 With the addition of the preference option to the as-out statement, advisory information can be offered to neighboring ASs. This capability is an extension to the as-out syntax. 2.2.3. AS200 advertises all routes to AS 1000 aut-num: AS200 as-out: to AS1000 announce ANY An alternative way to express this is: aut-num: AS200 as-out: AS1000 ANY 2.2.4. AS690 advertises only nets 35/8, 192.1.1/24 to ASs 1000 and AS1001. AS1000 and AS1001 have intersecting sets of routes and AS690 wants to establish symmetric traffic flows to the intersection from nets 35/8 and 192.1.1/24. Therefore, AS690 would like AS1000 to accept these two nets with a higher preference than AS1001. aut-num: AS690 as-out: AS1000:1 announce {35/8,192.1.1/24} as-out: AS1001:2 announce {35/8,192.1.1/24} This routing statement is possible due to the addition of metrics to the as-out statement and the ability to express announcments with a finer granularity than AS. 2.2.5. AS690 advertises all the CIX routes to AS200 with preference 5 and other routes with preference 1. aut-num: AS690 as-out: to AS200:5 announce CIX_COMMUNITY as-out: to AS200:1 announce OTHER OTHER means ANY routes except CIX route. Whenever there is a statement which uses OTHER, an additional statement is expected. or this same policy may be expressed using the 'NOTIN' operator: aut-num: AS690 as-out: to AS200:1 announce ANY/CIX_COMMUNITY 2.3. Default There are four commonly employed types of default policies: a. Static default b. Point to a net from a neighborAS as default c. Accept 0.0.0.0 from a neighborAS d. advertise 0.0.0.0 to a neighborAS Case d is clearly expressible in the as-out policy statement. The 'as-default' attribute permits non-ambiguous expression of cases a,b, and c. The simple format of a default statement is: as-default: neighborAS:preference... default_policy 'neighborAS:preference' is a pairing of a neighbor AS number and an associated metric. The as-default attribute may contain a list of neighborASs and preferences. When there is a list of neighborAS:preferences, a comma must separate them. 'neighborAS' is of the form of ASdddd where dddd is the AS number and is the neighbor AS to which default is pointed. It is possible to have several neighbor ASs to which an AS defaults. 'preference' is the degree of preference which is placed on the default announcement. It is an integer between 1 and dddd. The lower the value, the higher the degree of preference. 'default policy' defines the means of implementing default. The options are either static, acceptance of 0/0, or the default based upon a specified ip address. Examples: 2.3.1. AS 1000 points a static default to its neighbor AS 690. aut-num: AS1000 as-default: AS690:1 static or alternatively, aut-num: AS1000 as-default: AS690 static 2.3.2. AS 1002 points default at 140.222/16 which it accepts from AS690. aut-num: AS1002 as-default: AS690:1 {140.222/16} 2.3.3. AS 1001 accepts 0/0 as default from AS690 aut-num: AS1001 as-default: AS690:1 {0/0} 2.3.4. AS 1005 points primary default at 140.222/16 from AS690 and points a static default to AS266 as a secondary default. aut-num: AS1005 as-default: AS690:1 {140.222/16} as-default: AS266:2 static 2.4. as-exclude 'as-exclude' describes the transit policy of an AS. This is a special case which rejects traffic paths which include the excluded AS. It allow an AS to define a policy which applies not only the neighbor ASs but ASs in the path. Therefore it is a complimentary statement of the as-in statement which does not deal AS path information. Simple format: as-exclude: [exclude] AS [to] [destination] 'AS' is the AS number in the path which the source AS prefers not to traverse. 'destination' has the same meaning and format as the 'route' list in 'as-in'; however, if no destination is designated, the source AS never wants to transit the excluded AS no matter what the destination. The words in [ ] are optional. Examples: 2.4.1. AS 600 never wants to transit AS400 to reach destinations in AS237 aut-num: AS600 as-exclude: exclude AS400 to AS237 2.4.2. AS150 never wants to traverse AS690 to reach CIX routes. aut-num: AS150 as-exclude: exclude AS690 to CIX_COMMUNITY The as-exclude statement is only advisory. 2.5. as-transit as-transit describes the transit preferences of an AS. It allows an AS to describe its path preference in order to reach certain destinations. The AS specified here does not need to be a neighbor AS. Knowledge of these preferences is especially useful when source based routing (such as SDRP) is employed for policy routing. If the as-transit statement is employed, only the specified routing paths will be permitted. Any other routing paths that may exist to destinations from the source AS will be ignored. Simple format: as-transit: [transit] AS:preference [to] destination 'AS' is the AS that your AS prefers to transit. 'preference' is the degree of preference to transit this AS. The lower value has the higher degree of preference. 'destination' has the same meaning and format as the 'route' list in 'as-in'. word in [ ] is optional. Examples: 2.5.1. To reach destinations of AS237, AS 500 prefers to transit AS300 rather than AS400 aut-num: AS500 as-transit: transit AS300:1, AS400:2 to AS237 This statement means that AS500 prefers to only use paths via AS300 and AS400 to destinations from AS237. 2.5.2. To reach destinations of AS237, AS600 prefers to transit AS300 and not other ASes. That is if a path via AS300 is unavailable, AS600 would rather not use any other path to reach destinations from AS237. aut-num: AS600 as-transit: transit AS300:1 to AS237 If not explicitly expressed as in 2.5.3, this statement will be interpreted as a not transit to any. 2.5.3. To reach destinations of AS237, AS700 prefers to transit AS300 and will transit any other AS as backup. aut-num: AS700 as-transit: transit AS300:1, ASANY:3 to AS237 Any integer may be selected to represent preference. In the case of 'ASANY:3', the integer need only be larger than one. 2.5.4. AS250 would like to use AS300 as primary and AS400 as secondary to reach net 35/8. For other networks, it use AS400 as primary and AS300 as secondary. aut-num: AS250 as-transit: transit AS300:1, AS400:2 to {35/8} as-transit: transit AS400:1, AS300:1 to OTHER 2.6 as-aggr This policy statement will allow the description of the AS policy concerning aggregation in relationship to CIDR. The detailed syntax will be defined when more experience with CIDR is gained. I. Appendix A Extended Functions A.1. Express Routing Policy at Border Router Level Within an AS It is not unusual that two ASs have multiple interconnections and therefore, each AS will have more than one border router peering with more than one corresponding border router from the other AS. The routing exchange policy of each peer need not be identical. That requires the ability to describe the import and export routing policy between the two ASs at the border router level. The as-in and as-out statements defined in this appendix provide such function. Example 1: AS 200 connects to AS690 at two locations. At the east coast, AS200 has router 192.12.18.1/32 peering with a border router of AS690. At the west coast, AS200 has router 192.13.254.1/32 peering with another border router of AS690. To any destination of AS237, AS 200 prefers to use its west coast connection to AS 690 as primary and its east coast connection as secondary. That means AS 200 will prefer routes of AS 237 imported via AS690 at the west coast rather than from the east coast connection. aut-num: AS200 as-in: <192.13.254.1> from AS690:1 accept AS237 as-in: <192.12.18.1> from AS690:2 accept AS237 This concept is consistent with developments which are being proposed for RIPE-81. Example 2: The connections between AS200 and AS690 are the same as described above. AS200 also has connections to AS120 at the west coast and AS130 at the east coast. AS 200 would like AS 690 to use the west coast connection as primary and east coast connection as secondary for reaching destinations in AS120. In other words, AS 200 will advertise networks of AS120 to AS690 at west coast with a lower metric than the outbound metric at the east coast. aut-num: AS200 as-out: <192.13.254.1> to AS690:1 announce AS120 as-out: <192.12.18.1> to AS690:2 announce AS120 This is another concept which is under development for inclusion in RIPE-81. Example 3: AS300 and AS500 each have two routers connected to a DMZ network. / AS 300 \ / \ 192.12.80.1 192.12.80.2 | | ----------------------------------------------- | | 192.12.80.100 192.12.80.101 \ / \ AS 500 / 192.12.80.1 and 192.12.80.2 both peer with both 192.12.80.100 and 192.12.80.101. AS 300 can be used to reach AS120 and AS130. The policy of AS300 is to load share between its two border routers 192.12.80.1 and 192.12.80.2 for the traffic coming from AS500 to destinations of AS120 and AS130. aut-num: AS300 as-out: <192.12.80.1> to AS500<192.12.80.100>:1 announce AS120 as-out: <192.12.80.1> to AS500<192.12.80.101>:2 announce AS120 as-out: <192.12.80.2> to AS500<192.12.80.100>:2 announce AS130 as-out: <192.12.80.2> to AS500<192.12.80.101>:1 announce AS130 A.2. DataBase Selector This function will take advantage of information registed in other Routing Registries. The format is: database_name '{' selector_expression '}' - 'database_name' is a name of an 'official' (or known - to be defined) database. - The selector_expression is an expression of the form: attribute_name operator attribute_value - attribute_name is the name of any attribute (e.g 'country', 'source', 'connect') supported in the database, - operator is '==' (equal) or != (different) attribute_value is the value to be compared. This syntax permits the selection of networks in a database based on their attributes. For instance to select only the French networks: RIPE_DB { cc == FR } In order to maintain compatibility with the RIPE-81 format we added an alias named LOCAL which is merely RIPE_DB { co == LOCAL } Examples: A.2.1. AS 690 accept from AS 701 all networks in the NSFNET database with 701 as the primary announcing AS: aut-num: 690 as-in: from AS701:100 accept NSF_DB { aslist == 1:701 } A.2.2. Accept all german networks and all networks from AS 513 aut-num: 690 as-in: from AS701:100 accept AS513 OR RIPE_DB { cc == DE } II. Appendix B References: [1] RIPE-60 [2] RIPE-81 [3] Yu, Chen, Rekhter document [4] Joncheray document III. Appendix C Syntax in BNF and Yacc C.1 BNF syntax policy = *(policy_attribute) policy_attribute = as_in_attribute / as_out_attribute / as_transit_attribute / as_exclude_attribute / as_default_attribute as_in_attribute = KW_AS_IN ":" *(interface) *(kw_from) aslist_pref_noany *(kw_accept) accept_list as_out_attribute = KW_AS_OUT ":" *(interface) *(kw_to) aslist_nopref_any *(kw_announce) announce_list as_transit_attribute = KW_AS_TRANSIC ":" *(kw_transit) aslist_nopref_any *(kw_to) transit_list as_exclude_attribute = KW_AS_EXCLUDE ":" *(kw_exclude) aslist_nopref_any *(kw_to) exclude_list as_default_attribute = KW_AS_DEFAULT ":" aslist_nopref_noany default_type interface = "<" interface_addr ">" default_type = KW_STATIC \ *(kw_net) ip_netmask_addr /* Preference optional, ASANY not allowed */ aslist_nopref_noany: as_number interface / as_number interface INTEGER /* RIPE-81 */ / *(as_number_pref) /* Preference mandatory, ASANY not allowed */ aslist_pref_noany: as_number interface INTEGER /* RIPE-81 */ / *(as_number_pref) /* Preference mandatory, ASANY allowed */ aslist_pref_any: as_number_any interface INTEGER /* RIPE-81 */ / *(as_number_any_pref) /* Preference optional, ASANY allowed */ aslist_nopref_any: as_number_any interface / as_number_any interface INTEGER /* RIPE-81 */ / *(as_number_any_pref) as_number_pref = as_number interface ':' INTEGER as_number_any_pref = as_number_any interface ':' INTEGER as_number = AS_NUMBER accept_list = accept_item bin_operator accept_list / accept_item bin_operator accept_list / un_operator accept_list / "(" accept_list ")" accept_item = AS_NUMBER / community / ip_net_set / db_reference / KW_DEFAULT / KW_ANY / KW_NONE / KW_OTHER community = STRING ip_net_set = "{" ip_netmask_addr *("," ip_netmask_addr) "}" db_reference = STRING /* We do not know yet */ bin_operator = /* Nothing. It is a pain in the b... (RIPE-81). Means "OR" ?? */ / KW_OR / "," /* Means OR */ / KW_AND un_operator = KW_NOT announce_list = accept_list /* Same as as_in? */ interface_addr = dotted_ip_addr ip_net_addr = dotted_ip_addr / INTEGER /* = -( */ dotted_ip_addr = DOTTED_IP_ADDR; ip_netmask_addr = ip_net_addr / (ip_net_addr "/" ip_net_addr) kw_from = KW_FROM kw_to = KW_TO kw_accept = KW_ACCEPT kw_announce = KW_ANNOUNCE kw_transit = KW_TRANSIT kw_exclude = KW_EXCLUDE kw_net = KW_NET KW_AS_IN = "as-in" / "AS-IN" KW_AS_OUT = "as-out" / "AS-OUT" KW_AS_TRANSIC = "as-transit" / "AS-TRANSIT" KW_AS_EXCLUDE = "as-exclude" / "AS-EXCLUDE" KW_AS_DEFAULT = "^default" / "as-default" / "AS-DEFAULT" :-) KW_STATIC = "static" / "STATIC" KW_NET = "net" / "NET" KW_DEFAULT = "default" / "DEFAULT" KW_ANY = "any"/ "ANY" KW_NONE = "none" / "NONE" KW_OTHER = "other" / "OTHER" KW_ACCEPT = "accept" / "ACCEPT" KW_ANNOUNCE = "announce" / "ANNOUNCE" KW_TO = "to" / "TO" KW_FROM = "from" / "FROM" KW_TRANSIT = "transit" / "TRANSIT" KW_EXCLUDE = "exclude" / "EXCLUDE" KW_OR = "or" / "OR" / "||" KW_AND = "and" / "AND" / "&&" KW_NOT = "not" / "NOT" / "!" KW_EXC = "notin" / "NOTIN" / '^' INTEGER = 1*DIGIT AS_NUMBER = ("AS" / "as") (INTEGER / "ANY") STRING = ???? DOTTED_IP_ADDR = DIGIT *(DIGIT / ".") C.2 Yacc & lex syntax (authoritative) %token KW_AS_IN KW_AS_OUT KW_AS_TRANSIC KW_AS_EXCLUDE %token AS_NUMBER DOTTED_IP_ADDR NULLNET KW_ASANY KW_DEFAULT %token KW_STATIC KW_NET KW_AS_DEFAULT KW_ANY KW_NONE KW_OTHER %token STRING INTEGER %token KW_OR KW_AND KW_NOT KW_NOTIN %token KW_ACCEPT KW_ANNOUNCE KW_TO KW_FROM KW_TRANSIT KW_EXCLUDE %left NETMASK %% policy: /* Nothing */ | policy_attribute_list ; policy_attribute_list: policy_attribute | policy_attribute_list policy_attribute ; policy_attribute: as_in_attribute | as_out_attribute | as_transit_attribute | as_exclude_attribute | as_default_attribute ; as_in_attribute: KW_AS_IN ':' interface kw_from aslist_pref_noany kw_accept accept_list; as_out_attribute: KW_AS_OUT ':' interface kw_to aslist_nopref_any kw_announce announce_list; as_transit_attribute: KW_AS_TRANSIC ':' kw_transit aslist_nopref_any kw_to transit_list; as_exclude_attribute: KW_AS_EXCLUDE ':' kw_exclude aslist_nopref_any kw_to exclude_list; as_default_attribute: KW_AS_DEFAULT ':' aslist_nopref_noany default_type; /* Types of AS lists: with/without ASANY and with/without preference */ /* Preference optional, ASANY not allowed */ aslist_nopref_noany: as_number interface | as_number interface INTEGER /* RIPE-81 */ | as_number_nopref_list ; /* Preference mandatory, ASANY not allowed */ aslist_pref_noany: as_number interface INTEGER /* RIPE-81 */ | as_number_list ; /* Preference mandatory, ASANY allowed */ aslist_pref_any: as_number_any interface INTEGER /* RIPE-81 */ | as_number_any_list ; /* Preference optional, ASANY allowed */ aslist_nopref_any: as_number_any interface | as_number_any interface INTEGER /* RIPE-81 */ | as_number_nopref_any_list ; as_number_list: as_number_pref | as_number_list ',' as_number_pref ; as_number_any_list: as_number_any_pref | as_number_any_list ',' as_number_any_pref ; as_number_nopref_list: as_number_nopref | as_number_nopref_list ',' as_number_nopref ; as_number_nopref_any_list: as_number_nopref_any | as_number_nopref_any_list ',' as_number_nopref_any ; as_number_pref: as_number interface ':' INTEGER; as_number_nopref: as_number interface | as_number interface ':' INTEGER ; as_number_any_pref: as_number_any interface ':' INTEGER; as_number_nopref_any: as_number_any interface | as_number_any interface ':' INTEGER ; default_type: /* Nothing. To be compatible with RIPE-81 */ | KW_STATIC | KW_NET ip_netmask_addr | ip_net_set ; accept_list: accept_item | accept_item bin_operator accept_list | un_operator accept_list | '(' accept_list ')' ; accept_item: as_number | community | ip_net_set | db_reference | KW_DEFAULT | KW_ANY | KW_NONE | KW_OTHER ; transit_list: accept_list; exclude_list: accept_list; community: STRING; /* Anything alse? */ ip_net_set: '{' ip_net_list '}'; db_reference: STRING '{' '}'; /* We do not know yet */ bin_operator: /* Nothing. It is a pain in the b... (RIPE-81). Means 'OR' ?? */ | KW_OR | ',' /* Means OR */ | KW_AND | '/' | KW_NOTIN ; un_operator: KW_NOT ; announce_list: accept_list; /* Same as as_in? */ interface_addr: dotted_ip_addr; ip_net_addr: dotted_ip_addr | INTEGER /* :-( */ ; dotted_ip_addr: DOTTED_IP_ADDR; ip_netmask_addr: ip_net_addr | NULLNET /* 0/0 */ | ip_net_addr '/' ip_net_addr ; ip_net_list: ip_netmask_addr | ip_netmask_addr ',' ip_net_list ; as_number_any: as_number | KW_ASANY ; as_number: AS_NUMBER; interface: /* Nothing. This is optional */ | '<' interface_addr '>' ; kw_from: /* Nothing. This is optional */ | KW_FROM ; kw_to: /* Nothing. This is optional */ | KW_TO ; kw_accept: /* Nothing. This is optional */ | KW_ACCEPT ; kw_announce: /* Nothing. This is optional */ | KW_ANNOUNCE ; kw_transit: /* Nothing. This is optional */ | KW_TRANSIT ; kw_exclude: /* Nothing. This is optional */ | KW_EXCLUDE ; %% /* Lex syntax */ punctuation [<>:,;{}\.\(\)/] integer [0-9]+ string [A-Za-z_][A-Za-z_0-9-]* dotted_ip [0-9][0-9\.]* asnumber as[0-9]+ ASnumber AS[0-9]+ %% as-in return(KW_AS_IN); AS-IN return(KW_AS_IN); as-out return(KW_AS_OUT); AS-OUT return(KW_AS_OUT); as-transit return(KW_AS_TRANSIC); AS-TRANSIT return(KW_AS_TRANSIC); as-exclude return(KW_AS_EXCLUDE); AS-EXCLUDE return(KW_AS_EXCLUDE); ^default return(KW_AS_DEFAULT); as-default return(KW_AS_DEFAULT); AS-DEFAULT return(KW_AS_DEFAULT); static return(KW_STATIC); STATIC return(KW_STATIC); net return(KW_NET); NET return(KW_NET); default return(KW_DEFAULT); DEFAULT return(KW_DEFAULT); any return(KW_ANY); ANY return(KW_ANY); none return(KW_NONE); NONE return(KW_NONE); other return(KW_OTHER); OTHER return(KW_OTHER); accept return(KW_ACCEPT); ACCEPT return(KW_ACCEPT); announce return(KW_ANNOUNCE); ANNOUNCE return(KW_ANNOUNCE); to return(KW_TO); TO return(KW_TO); from return(KW_FROM); FROM return(KW_FROM); transit return(KW_TRANSIT); TRANSIT return(KW_TRANSIT); exclude return(KW_EXCLUDE); EXCLUDE return(KW_EXCLUDE); or return(KW_OR); OR return(KW_OR); \|\| return(KW_OR); and return(KW_AND); AND return(KW_AND); && return(KW_AND); not return(KW_NOT); NOT return(KW_NOT); ! return(KW_NOT); NOTIN return(KW_NOTIN); notin return(KW_NOTIN); 0\/0 return(NULLNET); {integer} return(INTEGER); {asnumber} return(AS_NUMBER); {ASnumber} return(AS_NUMBER); ASANY return(KW_ASANY); {string} return(STRING); {dotted_ip} return(DOTTED_IP_ADDR); {punctuation} return(yytext[0]); \n ++current_lex_line; ^#.* ; . ; -- 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

1 0

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

26 Apr '94

> Why not deciding this by mail and doing it *now*? (since everybody > seems to agree) Good for me. Gilles

1 0

Wilfried Woeber: Fwd: Re: Invalid data in the RIPE database
by Marten Terpstra 26 Apr '94

26 Apr '94

Wilfried has some mail connectivity problems to the RIPE NCC, therefore he asked me to resend the mail below concerning the as-in and as-out attributes. -Marten ------- Forwarded Message Date: Tue, 26 Apr 1994 16:36:51 +0100 From: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> Sender: <woeber(a)cc.univie.ac.at> To: marten(a)ripe.net cc: woeber(a)cc.univie.ac.at Subject: Fwd: Re: Invalid data in the RIPE database Marten, this was (one of) the message(s) that made it to L.Joncheray, but didn't reach you personally and the -wg lists. Maybe you could forward them, to keep the chaos down to a reasonable level. Sorry, Wilfried. From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-APR-1994 11:31 :48.07 To: MX%"Marten.Terpstra(a)ripe.net" CC: MX%"lpj(a)merit.edu",MX%"routing-wg(a)ripe.net",MX%"db-wg(a)ripe.net",WOEBER Subj: Re: Invalid data in the RIPE database =Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> writes = * = * > Laurent Joncheray <lpj(a)merit.edu> writes: = * > 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... = * = * More radical question: Considering that the NSFnet is going away and = * the routing registry has routing policy, should these attributes = * be deprecated or even removed totally? = =Jean-Michel writes = = * 1- obsolete this field. = * 2- Implement what Laurent proposes (automatic download from Merit). = =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 -------------------------------------------------------------------------- ------- End of Forwarded Message

1 0

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