- db-wg - mailman.ripe.net

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