- routing-wg - mailman.ripe.net

The Top 10
by Tony Bates 06 May '94

06 May '94

This is an auto-generated mail on Fri May 6 18:35:01 MET DST 1994 This is a list of the "Top 10" players who if CIDRizing at the AS level could make a significant gain in the size of Internet routing tables. This may be an over-estimation but it is hoped that this can act as an incentive for the "Top 10" and others to look at their CIDR capability. A full summary of all the ASes seen in the Internet can be seen by looking in: ftp.ripe.net:cidr/stats/AS* Other interesting stats can also be found there. As stated above this is auto-generated so it is not checked before it leaves my workstation. These stats will include more information on deltas in coming weeks. Here's follows the last weeks "Top 10" list with the corresponding date. --- 06May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS786 683 285 398 58.3% The JANET IP Service AS174 1232 845 387 31.4% NYSERNET-AS AS1275 555 266 289 52.1% DFN-IP AS372 1008 740 268 26.6% NSN-AMES-AS AS1717 770 521 249 32.3% RENATER AS701 735 490 245 33.3% ALTERNET-AS AS1225 569 345 224 39.4% CICNET3-AS AS1270 424 207 217 51.2% EUnet/DE AS19 646 502 144 22.3% CSS-DOMAIN AS81 256 113 143 55.9% CONCERT --- 05May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS786 676 283 393 58.1% The JANET IP Service AS174 1236 843 393 31.8% NYSERNET-AS AS1275 555 266 289 52.1% DFN-IP AS372 1020 754 266 26.1% NSN-AMES-AS AS701 739 491 248 33.6% ALTERNET-AS AS1717 762 522 240 31.5% RENATER AS1225 568 342 226 39.8% CICNET3-AS AS1270 424 207 217 51.2% EUnet/DE AS81 262 113 149 56.9% CONCERT AS19 642 502 140 21.8% CSS-DOMAIN --- 04May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS786 676 284 392 58.0% The JANET IP Service AS174 1180 828 352 29.8% NYSERNET-AS AS1275 544 257 287 52.8% DFN-IP AS372 1023 756 267 26.1% NSN-AMES-AS AS701 737 491 246 33.4% ALTERNET-AS AS1717 767 521 246 32.1% RENATER AS1225 566 346 220 38.9% CICNET3-AS AS1270 423 207 216 51.1% EUnet/DE AS81 262 115 147 56.1% CONCERT AS517 282 136 146 51.8% XLINK-UKA --- 03May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1182 548 634 53.6% ALTERNET-AS AS174 1215 827 388 31.9% NYSERNET-AS AS786 628 278 350 55.7% The JANET IP Service AS1275 537 254 283 52.7% DFN-IP AS372 1017 749 268 26.4% NSN-AMES-AS AS1717 765 519 246 32.2% RENATER AS1225 564 343 221 39.2% CICNET3-AS AS1270 424 207 217 51.2% EUnet/DE AS81 256 113 143 55.9% CONCERT AS19 641 501 140 21.8% CSS-DOMAIN --- 02May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1182 547 635 53.7% ALTERNET-AS AS786 628 278 350 55.7% The JANET IP Service AS174 1140 804 336 29.5% NYSERNET-AS AS1275 535 253 282 52.7% DFN-IP AS1717 752 512 240 31.9% RENATER AS372 876 645 231 26.4% NSN-AMES-AS AS1225 563 345 218 38.7% CICNET3-AS AS1270 419 205 214 51.1% EUnet/DE AS81 256 113 143 55.9% CONCERT AS19 633 495 138 21.8% CSS-DOMAIN --- 01May94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1178 548 630 53.5% ALTERNET-AS AS786 628 278 350 55.7% The JANET IP Service AS174 1155 806 349 30.2% NYSERNET-AS AS1275 535 253 282 52.7% DFN-IP AS372 1014 749 265 26.1% NSN-AMES-AS AS1717 761 517 244 32.1% RENATER AS1225 566 342 224 39.6% CICNET3-AS AS1270 419 205 214 51.1% EUnet/DE AS560 574 429 145 25.3% NEARNET-EXT-AS AS81 256 113 143 55.9% CONCERT --- 30Apr94 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1180 548 632 53.6% ALTERNET-AS AS174 1242 848 394 31.7% NYSERNET-AS AS786 628 278 350 55.7% The JANET IP Service AS1275 535 253 282 52.7% DFN-IP AS372 1019 747 272 26.7% NSN-AMES-AS AS1717 756 515 241 31.9% RENATER AS1225 558 337 221 39.6% CICNET3-AS AS1270 419 205 214 51.1% EUnet/DE AS560 579 432 147 25.4% NEARNET-EXT-AS AS81 254 116 138 54.3% CONCERT

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

Aggregation of HEAnet routes.
by Fergal Suipeil 29 Apr '94

29 Apr '94

Hello all, HEAnet is now advertising the entire 193.1/16 block to Ebone and EMPB. All but 3 of the explicit routes have been withdrawn and those three will be removed next month. By my calculations this reduces the number of networks advertised by HEAnet from 87 to 13 (10 next month). This is better than predicted because we've decided to confront the 'black hole' issue sooner rather than later. It seems to be working well - If anyone thinks otherwise, let me know. Thanks to all who helped, Fergal.

1 0

RedIRIS (AS766) withdrawal of routes
by Miguel A. Sanz 27 Apr '94

27 Apr '94

RedIRIS (AS766) is announcing the following aggregate: 193.144.0.0/15 All the specific routes contained within this block are withdrawn since 19th April. This reduced the routing entries announced from AS766 from 174 to 29. We hope our small contribution helps to postpone the colapse of the Internet ;-) Regards, Miguel +---------------------------------------------------------------+ | Miguel A. Sanz Tel: + 34 1 5855152 | | RedIRIS/CSIC Fax: + 34 1 5855146 | | Serrano 142 Email: miguel.sanz(a)rediris.es | | 28006 Madrid | +---------------------------------------------------------------+

3 2

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 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

4 3

A new tool to expand aggregate
by Laurent Joncheray 26 Apr '94

26 Apr '94

A new tool ("aggrwalk") to expand an aggregate into known compoments is available on rrdb.merit.edu:pub/meritrr/aggrwalk.tar.Z This tool gets all the info from the RIPE database, Merit Routing Registry DB, and NSF DB. It also adds usefull info like home AS, network name or NSF announcement list. Here is an example: % aggrwalk.pl -a -A cntry 193.74.240/20 Connected to ALC server Aggregate Database(s) homeas cntry <193.74.240/24> RIPE-DB BE <193.74.241/24> RIPE-DB BE <193.74.242/24> RIPE-DB AS1891 BE <193.74.243/24> RIPE-DB BE <193.74.244/24> RIPE-DB BE <193.74.245/24> RIPE-DB BE <193.74.247/24> RIPE-DB BE <193.74.248/24> RIPE-DB BE <193.74.249/24> RIPE-DB AS1891 BE <193.74.250/24> RIPE-DB:NSF_DB AS1891 BE <193.74.251/24> RIPE-DB AS1891 BE <193.74.252/24> RIPE-DB AS1891 BE <193.74.254/24> RIPE-DB AS1891 BE -- 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 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