From ala at merit.edu Tue Mar 1 21:17:59 1994 From: ala at merit.edu (Andrew Adams) Date: Tue, 1 Mar 1994 15:17:59 -0500 Subject: REC in conf file Message-ID: <199403012017.PAA03178@merit.edu> Hi guys. I have a question about the REC modifier specified for attributes in the conf file. The comment in the conf file implies that when that for attributes of type REC, the object they reference will be looked up before the new object is added. For example, if I'm trying to add net 35 I mail in the following object. inetnum: 140.222.0.0 netname: NSFNET-T3-BB descr: Merit Computer Network, Ann Arbor country: US admin-c: Andy Adams tech-c: Rick Riolo connect: NSF changed: ala at merit.edu 940301 source: MERITRR The conf file has the tech-c and admin-c attributes tagged as REC so should "Andy Adams" and "Rick Riolo" be looked up before this object is added?... and if the names are not found will the add fail? The behavior I'm seeing now is that I can add nets (and ASs) with contacts that do not yet exist in the db. Thanks for any info. Andy -------- Logged at Wed Mar 2 08:52:00 MET 1994 --------- From Marten.Terpstra at ripe.net Wed Mar 2 08:51:51 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 02 Mar 1994 08:51:51 +0100 Subject: REC in conf file In-Reply-To: Your message of Tue, 01 Mar 1994 15:17:59 EST. <199403012017.PAA03178@merit.edu> Message-ID: <9403020751.AA02582@ncc.ripe.net> Andrew Adams writes * * The conf file has the tech-c and admin-c attributes tagged as REC so should * "Andy Adams" and "Rick Riolo" be looked up before this object is added?... * and if the names are not found will the add fail? Maybe it should but it doesn't. It could be added it, but since the previous packages with which we did the database did not enforce this either, we left it out. * The behavior I'm seeing now is that I can add nets (and ASs) with contacts * that do not yet exist in the db. Correct, as a result of the choice above. If you wish I can have a look to see if it can be enforced easily (I think it's not that bad to add) -Marten -------- Logged at Thu Mar 10 22:37:20 MET 1994 --------- From epg at merit.edu Thu Mar 10 22:37:07 1994 From: epg at merit.edu (Elise Gerich) Date: Thu, 10 Mar 1994 16:37:07 -0500 Subject: extensions for routing registry Message-ID: <199403102137.QAA16455@merit.edu> Hi all, Well, we have wordsmithed and armwrestled and are finally ready to share the routing policy document with you all for your comments and review. Please send your comments to rr-imp at ripe.net. Happy reading. --Elise, Jessica, and Laurent -------------------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; ^#.* ; . ; -------- Logged at Fri Mar 11 12:34:30 MET 1994 --------- From Tony.Bates at ripe.net Fri Mar 11 12:34:24 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 11 Mar 1994 12:34:24 +0100 Subject: extensions for routing registry In-Reply-To: Your message of Thu, 10 Mar 1994 16:37:07 EST. <199403102137.QAA16455@merit.edu> Message-ID: <9403111134.AA27192@fs1.ripe.net> Elise, Firtly a few quick comments. Unfortunately, you've caught Marten and myself at a fairly bad time as we leave for a ski trip to France (Courchevel for Laurents benefit ;-)) for 8 days as of tomorrow morning so we won't be able to get as much discussion going as I guess we'd like to. However, firstly let me say this looks very good and in general it seems much in line with discussions we've had recently. Please take my comments as constructive. My general view is the one we've always been slightly at odds about which is "complexity v clarity". However, I think if we agree on some of the wording to warn where the more complex bits are we could in fact expand RIPE-81 with these (or some at least) additions. --Tony. Elise Gerich writes: * Hi all, * Well, we have wordsmithed and armwrestled and are finally ready * to share the routing policy document with you all for your * comments and review. Please send your comments to rr-imp at ripe.net. * Happy reading. * --Elise, Jessica, and Laurent * * * -------------------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. * Whilst this is implicitly correct. We need to actually ratify this at least in the sense that SPs need to be able to have a document describing this minimum set of attributes be that RIPE-81++ plus your extensions or RIPE-81++ as is. * 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 * As I see it then the new bits are d, e but slight adjustments to a, c and f. * * 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. Does this mean the yacc syntax is the only correct syntax definition. * * 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. * This to me is a little confusing. ANY means any to me. In your context ANY appears to be the same as specifying an AS. ASANY is what we have as ANY. * OTHER means any routing information excluding specified routing information * . * How is OTHER evaluated ? What I mean is, is it evaluated with respect to your rule or just a convenient way of saying ANY (well ASANY in your syntax) and NOT blah ? * "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 mu * st * 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, is dddd the same as the AS dddd ? (no I guess ?) * 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 I'm sort of confused here as well. I guess this comes from my one net one AS idea which you dont have. You need to say up front that this is different from RIPE-81 if you have expressions that support this concept. Plus I think "/" can certainly cause confusion (with SPs idea of the look of a CIDR route). * - 'NOT' or '!' * for example, "NOT route1" means we accept networks * not belonging to route1 Actualy - reads then as ANY and NOT. Doesn't this mean we do not accept networks beloning to route1 or is this splitting a hair not there ? * - '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. * Right. * 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." * Right this is something I added to our stuff a while back (still in draft, I sent it to Laurent yesterday actually) to attempt to make it clearer) * 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 an * 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 * Okay, but for the syntax I guess somehow you have to show that neighborAS:preference and neighbourAS preference as the compatible, probobly in the Yacc right ? * * 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. * Of course this can be done with a community as well right ? Also, when do you stop this list and turn it into a community list anyway just for clarity, 10, 1000, ? * 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:metri * c * per as-in statement. When there is a list of neighborAS:metrics, a comma m * ust * 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. * I would like to see this metric part noted as advisory information as well and clearly that as this is all it is and not enforceable at all. * '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 o * ther * 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 * * Some general things. I'm not sure the verbosity of optional "to, announce, accept" really adds much. As an operator I want the tools to do things for me and if I need verbosity get them to put in there. These are all directly implicted so if needed get the server to do it. * 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 * This gets back to the old chesnut of implementation specifc details in the policy. I would like to see the default_policy part ptional. I also see other ways of deriving default like if an interface is up for example (dynamicly derived) and so on. * 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 neighbor * ASs * 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 p * ath. * 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 traver * se. * '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 [ ] a * re * 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. * Well I kind of like this a it an advisory that we all agreed on. How does this syntax look like I want a list of exclude ASs ? aut-num: AS15 as-exclude: AS690 as-exclude: AS1133 * 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. * This again implies knowledge of the topology but I do like it as an advisory so it gives operators who really are doing this a better way of expressing there policies (which also implies it is non-advisory I guess). Plus do you allow real path rather than a single transit AS. * 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 rath * er * 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 bo * rder * router level. The as-in and as-out statements defined in this appendix pro * vide * 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 co * ast, * AS200 has router 192.13.254.1/32 peering with another border router of AS69 * 0. * To any destination of AS237, AS 200 prefers to use its west coast connectio * n * 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. A * S200 * 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 ea * st * 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 * I see why you might like this but hasn't it just gone into an area of complexity you don't want in the registry. I do see it but I do not think it will be used except by a few very large transit sites and then could easily map this information in another way. The only tool where this might help is in prtracerotue I guess. * * 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 } * * Again this is fine except for the level of complexity it adds to the representation. * II. Appendix B References: * * [1] RIPE-60 * [2] RIPE-81 * [3] Yu, Chen, Rekhter document * [4] Joncheray document * Wont comment on this. * 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_an * nounce announce_list; * * as_transit_attribute: KW_AS_TRANSIC ':' kw_transit aslist_nopref_an * y kw_to transit_list; * * as_exclude_attribute: KW_AS_EXCLUDE ':' kw_exclude aslist_nopref_an * y 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 kn * ow yet */ * * bin_operator: /* Nothing. It is a pain in the b... (R * IPE-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; * * ^#.* ; * * . ; * -------- Logged at Thu Feb 17 22:53:18 MET 1994 --------- From Tony.Bates at ripe.net Fri Mar 11 14:47:43 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 11 Mar 1994 14:47:43 +0100 Subject: No subject Message-ID: <9403111347.AA28932@fs1.ripe.net> ------- Blind-Carbon-Copy To: pride-list at ripe.net From: Tony Bates X-Phone: +31 20 592 5064 X-Fax: +31 20 592 5090 Date: Fri, 11 Mar 1994 14:47:43 +0100 Sender: tony at mature.ripe.net Marten and I have been working on the PRIDE guide for the last two weeks and are about to depart for a weeks vacation and would like to take this chance to get some early comments and feedback to the current draft. Find below a status of the document explaining the type of comments we would like if possible and also the state of the document itself. This is also included with the distributed documentation. Please also read the README that comes with the distributed documentation. All comments gratefully received. Regards, --Tony and Marten. STATUS - ------ This guide is very much a draft and as you will see some chapters are not even filled in as of yet (most notably Chapter 3). However, we are looking for some early feedback. Specifically regarding the big picture rather than things like spelling errors, grammer, etc. The main focus of comments we need are on the general structure, Chapter 4,5,6 and 7, in terms of the contents, layout and what is missing or not particularly clear. We do of course welcome all comments but try to keep the above in mind. The plan is to release the first version of the guide (which will be used to supplement the PRIDE course) within the next 3-4 weeks so your comments at this stage are much appreciated. The guide is available from ftp.ripe.net:pride/docs/guide-draft-1.0.ps.tar.Z or ftp.ripe.net:pride/docs/guide-draft-1.0.txt.tar.Z We strongly advise everyone to take the postscript version as the text one will not contain the graphics used in the guide. Please send all comments to pride at ripe.net ------- End of Blind-Carbon-Copy -------- Logged at Mon Mar 21 22:20:05 MET 1994 --------- From epg at merit.edu Mon Mar 21 22:19:58 1994 From: epg at merit.edu (Elise Gerich) Date: Mon, 21 Mar 1994 16:19:58 -0500 Subject: "the" plan Message-ID: <199403212119.QAA23310@merit.edu> Daniel, Here is what we'd like to do. 1) Announce our registry on Wednesday (this is using the minimum set we agreed on and the extensions from our draft document) 2) we have a translation program which will translate our data to a syntax compatible with RIPE 3) we will store your data in our registry with source RIPE and will give you the compatible file to store in your DB with source Merit 4) Laurent is working on a whois daemon that will search both DBs - thereby negating the need to swap files 5) if you are agreeable, we would like to have both of us run the new whois daemon when it is ready (Laurent says that prtraceroute will work just fine with the new whoisd). So, does this sound like a go to you all? If so, we will send a message to regional-techs, bgpd, iepg, and any ripe groups that you would like. Really looking forward to getting this show on the road. Thanks. --Elise -------- Logged at Tue Mar 22 11:59:12 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Mar 22 11:58:51 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Mar 1994 11:58:51 +0100 Subject: "the" plan In-Reply-To: Your message of Mon, 21 Mar 1994 16:19:58 EST. <199403212119.QAA23310@merit.edu> Message-ID: <9403221058.AA09103@reif.ripe.net> > Elise Gerich writes: > Daniel, > Here is what we'd like to do. > > 1) Announce our registry on Wednesday (this is using the minimum > set we agreed on and the extensions from our draft document) > 2) we have a translation program which will translate our > data to a syntax compatible with RIPE > 3) we will store your data in our registry with source RIPE > and will give you the compatible file to store in your DB with > source Merit Perfect. We should find a mechanism for incremental updates too, like just forwarding the update messages with a special kludge to prevent multiple diagnostic replies. > 4) Laurent is working on a whois daemon that will search both > DBs - thereby negating the need to swap files Doing a whois daemon that queries multiple places has some design issues associated with it. At least the following will have to be looked at: - how to deal with replication of data (wanted for redundancy) - how to combine and use multiple answers - how to report only partial availability of servers back to the user - Rwhois work by Kosters and Williamson - other distributed whois work We have looked into some of this and it is not straightforward. It ain't difficult either but we want to consider waht we are doing carefully. > 5) if you are agreeable, we would like to have both of us run the > new whois daemon when it is ready (Laurent says that prtraceroute > will work just fine with the new whoisd). see above. > So, does this sound like a go to you all? If so, we will send > a message to regional-techs, bgpd, iepg, and any ripe groups > that you would like. Fine. No jont announcement then. I don't mind. > Really looking forward to getting this show on the road. Thanks. Me too. -------- Logged at Tue Mar 22 13:53:03 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Mar 22 13:53:02 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Mar 1994 13:53:02 +0100 Subject: extensions for routing registry In-Reply-To: Your message of Thu, 10 Mar 1994 16:37:07 EST. <199403102137.QAA16455@merit.edu> Message-ID: <9403221253.AA09413@reif.ripe.net> To add to Tony's comments with which I agree. - I personally do not like the [to] [from] etc. syntactic sugar. Users who want a more comfortable input language, should use a local post/preprocessor which we should provide. If the routing registry itself (view it as a database) provides different representations we will get lots of confusion as to the semantics. Also all tools using the RR will have to accept multiple representations which is only adding possibilities for bugs and general entropy - The RIPE-81 as-out does *not* have a preference for a reason. I (think I) know what you want to do, BUT ... Try to define the semantics in a clear, concise and understandable way! I cannot. This will also obscure the principle of what as-in and as-out really means. This will lead to confusion even if its optionality and advisory nature is clearly marked. The only gain obtainable from it is some conistency checking implementable only if the full topology is known. Rather use as-exclude and as-transit for this as these are clearly non-local attributes. - Usage of communities must be clearly flagged with the potential problems w.r.t. implementability. The only way I see it implementable is network based lists, now that the BGP4 folks have withdrawn the path attribute from the spec. It also needs to be mentioned that using them can potentially hurt CIDR aggregation efficiency badly. - I like the as-exclude attribute (without syntactic sugar) It needs more language about that this can be implemented in two ways: - using path info by the AS registering the as-exclude - filtering implemented by the AS mentioned. The second is advisory in nature but should be encouraged. It needs language that filtering by the AS mentioned is quite OK based on the as-exclude etc. pp. This also means we need a way to provide server functionality of the type "tell me all ASes mentioning ASx (me) in as-exclude!" At them moment we can get this from the full database file but this does not scale. - as-transit can be quite usefule but needs a better definition of semantics It has similar problems as as-out preferences: You need the whole graph. But these are more acceptable here as as-transit is clearly not local. It also needs a section on how this can be implemented. And its advisory nature. - border router level this should not go in the as-out attributes but rather be a separate set of attributes line "link-out" "link-in" with a requirement to have the as-in and as-out as well. this way you get an optional level of complexity. Otherwise it looks fine. - database selector same problems as community In conclusion I personally would be very unhappy if you folks announced a registry using this stuff tomorrow. This needs some solid design sessions where semantics are clearly defined and we can discuss what is needed and what is fluff. Finally this needs some test as to wether people actually understand it (the same way). I strongly fear that adding too many features at this point in time can provide enough problems to make this whole RR idea fail. I do not want that to happen. Another *very worthwhile* idea is to make much more clear what is basic functionality and what is enhanced functionality. Please do not understand these remarks as antagonistic or de-valuing your work. Due to resource-sacrceness over here you are very much leading the way for extensions. I apreceiate that very much. My overwhelming concern is to not de-value the RR concept by making it overly complex. Daniel PS: I am missing the aggregate stuff. -------- Logged at Tue Mar 22 16:51:21 MET 1994 --------- From dsj at merit.edu Tue Mar 22 16:51:06 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 22 Mar 1994 10:51:06 -0500 Subject: "the" plan Message-ID: <199403221551.KAA15440@merit.edu> Daniel, > > 3) we will store your data in our registry with source RIPE > > and will give you the compatible file to store in your DB with > > source Merit > > Perfect. > > We should find a mechanism for incremental updates too, like just forwarding > the update messages with a special kludge to prevent multiple > diagnostic replies. I'd be willing to look into using "patch" for this. Patch covers integrity checking ("what if you got update 17 but not 16", etc). I presume this is a bit lower priority than getting the basic systems up, though, since compressed ftp will work in the mean time. --Dale -------- Logged at Tue Mar 22 16:54:55 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Mar 22 16:54:22 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 22 Mar 1994 16:54:22 +0100 Subject: "the" plan In-Reply-To: Your message of Tue, 22 Mar 1994 10:51:06 EST. <199403221551.KAA15440@merit.edu> Message-ID: <9403221554.AA11138@fs1.ripe.net> "Dale S. Johnson" writes * Daniel, * * I'd be willing to look into using "patch" for this. Patch covers integrity * checking ("what if you got update 17 but not 16", etc). We tried running a context diff on the RIPE database once (to be used with patch) and it took over 6 hours to complete (the diff). Not very useful I think. There's got to be better ways. * I presume this is a bit lower priority than getting the basic systems up, * though, since compressed ftp will work in the mean time. I agree. -Marten -------- Logged at Tue Mar 22 17:02:52 MET 1994 --------- From epg at merit.edu Tue Mar 22 17:02:42 1994 From: epg at merit.edu (epg at merit.edu) Date: Tue, 22 Mar 94 11:02:42 EST Subject: "the" plan Message-ID: <9403221602.AA02660@pepper.merit.edu> Daniel, > > Elise Gerich writes: > > Daniel, > > Here is what we'd like to do. > > > > 1) Announce our registry on Wednesday (this is using the minimum > > set we agreed on and the extensions from our draft document) > > 2) we have a translation program which will translate our > > data to a syntax compatible with RIPE > > 3) we will store your data in our registry with source RIPE > > and will give you the compatible file to store in your DB with > > source Merit > > Perfect. > > We should find a mechanism for incremental updates too, like just forwarding > the update messages with a special kludge to prevent multiple > diagnostic replies. Good idea - we have discussed this but have no solution right now. > > > 4) Laurent is working on a whois daemon that will search both > > DBs - thereby negating the need to swap files > > Doing a whois daemon that queries multiple places has some design issues > associated with it. At least the following will have to be looked at: > > - how to deal with replication of data (wanted for redundancy) > > - how to combine and use multiple answers > > - how to report only partial availability of servers back to the user > > - Rwhois work by Kosters and Williamson > > - other distributed whois work > > We have looked into some of this and it is not straightforward. > It ain't difficult either but we want to consider waht we are > doing carefully. My statement was not completely accurate. We are interested in exploring the whois daemon that queries multiple places, but what Laurent is working on as an intermediary step is a whois daemon that understands both the original RIPE-81 syntax and the Merit syntax. This whoisd can look at several DB files on the same host, but does not support query to multiple places yet. Laurent will send a more detailed message about the whoisd. So immediately, we have a translation program which will translate the Merit syntax to compatible RIPE syntax. We will send you the ripe-a-like file so that you may store it on your machine and the whoisd will return the ripe-a-like info for info registered with Merit and prtraceroute will work. The whoisd that Laurent is working on would be able to read the RIPE-81 syntax AND the Merit syntax thereby negating the need for the translation program. Files that are exchanged between us would have the "native" syntax and the whoisd would be able to respond with information from either and prtraceroute would work with the new whoisd. Then down the road we would try to actually have a whoisd that would obviate the need for exchanging files. > > > 5) if you are agreeable, we would like to have both of us run the > > new whois daemon when it is ready (Laurent says that prtraceroute > > will work just fine with the new whoisd). > > see above. > > > So, does this sound like a go to you all? If so, we will send > > a message to regional-techs, bgpd, iepg, and any ripe groups > > that you would like. > > Fine. No jont announcement then. I don't mind. > Guess I thought that it would still be a joint announcement since we'd like the message to go from both of us - RIPE and Merit. > > Really looking forward to getting this show on the road. Thanks. > > Me too. > How come everything seems to happen right before IETF??? --Elise -------- Logged at Tue Mar 22 17:14:48 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Mar 22 17:14:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 22 Mar 1994 17:14:24 +0100 Subject: "the" plan In-Reply-To: Your message of Tue, 22 Mar 1994 11:02:42 EST. <9403221602.AA02660@pepper.merit.edu> Message-ID: <9403221614.AA10017@reif.ripe.net> > epg at merit.edu writes: > Daniel, > > > > > Perfect. > > > > We should find a mechanism for incremental updates too, like just forward > ing > > the update messages with a special kludge to prevent multiple > > diagnostic replies. > > Good idea - we have discussed this but have no solution right now. Our thinking is: alternative a) At the point in the update procedure where an update is found to be without errors, send the update as an email message to a special mailbox which just includes it without checking and producing diagnostic mails. alternative b) do the same with a TCP connection rather than mail. needs spooling built in in case the other side is down. > My statement was not completely accurate. We are interested in exploring > the whois daemon that queries multiple places, but what Laurent is > working on as an intermediary step is a whois daemon that understands > both the original RIPE-81 syntax and the Merit syntax. Fine. But see my message about the extensions. > > Fine. No jont announcement then. I don't mind. > > Guess I thought that it would still be a joint announcement since > we'd like the message to go from both of us - RIPE and Merit. Misunderstanding. See my later tesponse to your later mesage. > > How come everything seems to happen right before IETF??? Fundamental Internet Law. -------- Logged at Wed Mar 23 05:35:14 MET 1994 --------- From epg at merit.edu Wed Mar 23 05:35:05 1994 From: epg at merit.edu (Elise Gerich) Date: Tue, 22 Mar 1994 23:35:05 -0500 Subject: extensions to the registry Message-ID: <199403230435.XAA11914@merit.edu> Daniel, > From dfk at ripe.net Tue Mar 22 07:53:16 1994 > > To add to Tony's comments with which I agree. > > - I personally do not like the [to] [from] etc. syntactic sugar. > Users who want a more comfortable input language, should use a local > post/preprocessor which we should provide. > If the routing registry itself (view it as a database) provides different > representations we will get lots of confusion as to the semantics. > Also all tools using the RR will have to accept multiple representations > which is only adding possibilities for bugs and general entropy The main reason that [to] and [from] are not stripped prior to entry in the DB was that it made it easier to have "user friendly" responses to whois queries that stated policy. The translator will strip the keywords from the ripe-alike file. You make a good point and we will discuss it further. > > - The RIPE-81 as-out does *not* have a preference for a reason. > I (think I) know what you want to do, BUT ... We went around and around about this one, and decided to test it. Admittedly you can not force compliance to an as-out preference. > Try to define the semantics in a clear, concise and understandable way! > I cannot. > This will also obscure the principle of what as-in and as-out really means. Not convinced that this obscures the principle of as-in and as-out. > This will lead to confusion even if its optionality and advisory nature > is clearly marked. Since we still accept the less complex descriptions why should this lead to confusion - especially if we document it well. > The only gain obtainable from it is some conistency checking implementable > only if the full topology is known. > Rather use as-exclude and as-transit for this as these are clearly non-local > attributes. > > - Usage of communities must be clearly flagged with the potential problems > w.r.t. implementability. The only way I see it implementable is network > based lists, now that the BGP4 folks have withdrawn the path attribute from > the spec. It also needs to be mentioned that using them can potentially > hurt CIDR aggregation efficiency badly. We will work on clarifying the documentation. > > - I like the as-exclude attribute (without syntactic sugar) > It needs more language about that this can be implemented in two ways: > > - using path info by the AS registering the as-exclude > > - filtering implemented by the AS mentioned. > > The second is advisory in nature but should be encouraged. It needs > language that filtering by the AS mentioned is quite OK based on the > as-exclude etc. pp. > More documentation work - guess that's why we have drafts. > This also means we need a way to provide server functionality of the type > "tell me all ASes mentioning ASx (me) in as-exclude!" At them moment we > can get this from the full database file but this does not scale. > Is this what is called job security - there is always something else that has to be done? ;-) > - as-transit can be quite usefule but needs a better definition of semantics > It has similar problems as as-out preferences: You need the whole graph. > But these are more acceptable here as as-transit is clearly not local. > It also needs a section on how this can be implemented. > And its advisory nature. > Again better documentation. > - border router level > this should not go in the as-out attributes but rather be a separate > set of attributes line "link-out" "link-in" with a requirement > to have the as-in and as-out as well. this way you get an optional level > of complexity. > Otherwise it looks fine. > > - database selector > same problems as community > > In conclusion I personally would be very unhappy if you folks announced a > registry using this stuff tomorrow. This needs some solid design sessions > where semantics are clearly defined and we can discuss what is needed and > what is fluff. Finally this needs some test as to wether people actually > understand it (the same way). > Daniel, we really have discussed this in great detail and have approached Andrew and Bill to test things. It is understandable that before you all would like to adopt this that you would like to have further discussions with us. Bill has looked at it a bit, but Andrew let us know that this was low on his priority list. So we would like to go ahead with the announcement of the Merit Routing Registry. We will try to make it clear that the straight RIPE-81 syntax is perfectly acceptable, but that if folks have routing requirements that may not be accomdated by the more standard syntax, there is a way to describe more complex routing policies. > I strongly fear that adding too many features at this point in time can > provide enough problems to make this whole RR idea fail. > I do not want that to happen. > We do not want this whole RR idea to fail either. We are willing to float the extensions as a test to see if folks say that the extensions are too complicated. If that is the case, we are still able to accept the RIPE-81 syntax. So it seems like the result would be that technical folks would reject the "complex" and accept the "simple." We (RIPE and Merit) would still have the minimum set of information registered and there would be two active registries. > Another *very worthwhile* idea is to make much more clear what is basic > functionality and what is enhanced functionality. > Point well taken. > Please do not understand these remarks as antagonistic or de-valuing your > work. Due to resource-sacrceness over here you are very much leading > the way for extensions. I apreceiate that very much. My overwhelming > concern is to not de-value the RR concept by making it overly > complex. > We are in complete agreement in your concern to not de-value the RR concept. > Daniel > > PS: I am missing the aggregate stuff. > We would like to discuss the possibility of actually just adding an attribute to intnum - say creator - which would indicate who originated the net/length registration. The idea behind having only one "classless" net object (instead of a network object and an aggregate object) is to move away from the idea of classful nets. After all who is to say what the intnum registration should be in a classless world - is 35/8 a network or an aggregate? Just a thought. --Elise --Elise -------- Logged at Wed Mar 23 16:29:32 MET 1994 --------- From epg at merit.edu Wed Mar 23 16:29:24 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 23 Mar 94 10:29:24 EST Subject: draft of proposed announcement Message-ID: <9403231529.AA02800@pepper.merit.edu> Daniel, Here is a draft of the announcement of the Merit Routing Registry. We would like to make this announcement real soon now and hope that we can come to an agreement about the text. Initially, for the first couple of weeks, while Laurent completes work on a prtraceroute that can recognize the extended syntax we will have a bit of a kludge. "as-in" and "as-out" records entered into the MeritRR will be syntax- checked and stored in the MeritRR completely as they are entered; however these records will not be used directly by prtraceroute. Instead, new, temporary "as-in" and "as-out" information will be seen by prtraceroute. This information has all of the detail of the "as-in" and "as-out" information removed, and replaced by the word "ANY". As a result of this, prtraceroute will correctly identify the AS of each network it traverses. It will not, however, present meaningful information on the right side of the output describing the nature of the transitions between ASs (e.g. primary, ERROR, etc.) Whois queries to Merit's database will return both the full-syntax and the shortened "ANY" records. As soon as the modified pretraceroute is ready (~2 weeks) the "ANY" syntax will be removed, and the new prtraceroute will work with the full information available. We think we have addressed the issues of compatibility between our registries and are ready to roll. We are just waiting to hear from you all so we can do this together. --Elise -----------------------proposed announcement---------------------- The RIPE Registry has been collecting routing information for Autonomous Systems which are based in Europe. This information has proven very useful in discovering and resolving reachability and routing problems for the segment of the Internet which is defined by the registry. Merit and RIPE have been working together to establish a peer routing registry for North America (and potentially other regions of the world). Together we have defined a minimum set of policy attributes which are described in the aut-num object, which are as-in and as-out. This minimum set, in its most basic form, has been described in the document RIPE-81. Whereas this set of policy descriptions is adequate for most standard routing requirements, some Autonomous Systems have more complex requirements. Merit has defined an extended definition for as-in and as-out as well as defining some new attributes (e.g. as_default) that will permit the description of more complex routing scenarios. Merit is ready to accept network and policy registrations in the Merit Routing Registry. Those registrations may be of the basic type pioneered by RIPE or network providers may experiment with the new extended syntax defined by Merit. Documentation for registering in the Merit Routing Registry can be found on merit.edu:/pub/meritrr. Since this is a new service, we consider ourselves still in the pilot phase; however, we expect that any initial glitches should be able to be resolved in a timely fashion. We do need some more experience with registrations to test the interactions with the RIPE Registry and the interpretation of the extended syntax. Merit and RIPE anticipate that the two registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to assure that the two registries appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. Elise Gerich and Daniel Karrenberg -------- Logged at Wed Mar 23 16:51:02 MET 1994 --------- From Tony.Bates at ripe.net Wed Mar 23 16:50:18 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 23 Mar 1994 16:50:18 +0100 Subject: draft of proposed announcement In-Reply-To: Your message of Wed, 23 Mar 1994 10:29:24 EST. <9403231529.AA02800@pepper.merit.edu> Message-ID: <9403231550.AA08533@fs1.ripe.net> Elise, infortunately Daniel is off sick today with the flu so I'm not sure how we can progress this very quickly. However, I wanted to pick up on a couple of issues. epg at merit.edu writes: * Daniel, * Here is a draft of the announcement of the Merit Routing Registry. * We would like to make this announcement real soon now and hope * that we can come to an agreement about the text. * * Initially, for the first couple of weeks, while Laurent completes * work on a prtraceroute that can recognize the extended syntax * we will have a bit of a kludge. * One thing - it is not just prtraceroute, there are other tools so I'm interested in the shape these mods are taking (not a big deal as things can always be retro-fitted I guess). Plus we are very concerned to see the how the new whoisd will work. In some ways this holds us back as we also want to re-write the tools but want to keep allignment/make progress. * "as-in" and "as-out" records entered into the MeritRR will be syntax- * checked and stored in the MeritRR completely as they are entered; however * these records will not be used directly by prtraceroute. Instead, new, * temporary "as-in" and "as-out" information will be seen by prtraceroute. * This information has all of the detail of the "as-in" and "as-out" * information removed, and replaced by the word "ANY". As a result of this, * prtraceroute will correctly identify the AS of each network it traverses. * It will not, however, present meaningful information on the right * side of the output describing the nature of the transitions between ASs * (e.g. primary, ERROR, etc.) * Woh - this is potentially dangerous as everyone will think are hunky dory or worse there policy is wrong (contridiction but also possible I'd say). Prtraceroute (as it stands) would give I (the easy one ;-)) correctly and E? for all the ANYs which I guess is not too bad but might need to be explinaed. * Whois queries to Merit's database will return both the full-syntax and * the shortened "ANY" records. As soon as the modified pretraceroute * is ready (~2 weeks) the "ANY" syntax will be removed, and the new * prtraceroute will work with the full information available. * Still interested to see the shape of prtraceroute/whoisd so we can see how this will work with our "basic" stuff. * We think we have addressed the issues of compatibility between * our registries and are ready to roll. We are just waiting to * hear from you all so we can do this together. * * --Elise * * -----------------------proposed announcement---------------------- * Daniel camp I guess but a couple of minor points... * The RIPE Registry has been collecting routing information for * Autonomous Systems which are based in Europe. This information * has proven very useful in discovering and resolving reachability * and routing problems for the segment of the Internet which is * defined by the registry. * I think PRIDE needs to be mentioned in this. DFK ? Also the RIPE Routing Registry is the correct name I would say.. * Merit and RIPE have been working together to establish a peer * routing registry for North America (and potentially other regions * of the world). Together we have defined a minimum set of * policy attributes which are described in the aut-num object, * which are as-in and as-out. * What happened to default ? * This minimum set, in its most basic form, has been described in the * document RIPE-81. Whereas this set of policy descriptions is should be a reference pointer to ripe-81 I guess. * adequate for most standard routing requirements, some Autonomous * Systems have more complex requirements. Merit has defined an * extended definition for as-in and as-out as well as defining * some new attributes (e.g. as_default) that will permit the * description of more complex routing scenarios. * * Merit is ready to accept network and policy registrations in * the Merit Routing Registry. Those registrations may be of the * basic type pioneered by RIPE or network providers may experiment * with the new extended syntax defined by Merit. Documentation for * registering in the Merit Routing Registry can be found on * merit.edu:/pub/meritrr. * * Since this is a new service, we consider ourselves still in the * pilot phase; however, we expect that any initial glitches should * be able to be resolved in a timely fashion. We do need some more * experience with registrations to test the interactions with the * RIPE Registry and the interpretation of the extended syntax. * * Merit and RIPE anticipate that the two registries will provide * a more comprehensive picture of the routing interactions in the * Internet. We are working together to assure that the two registries * appear like one virtual registry to the various tools that are * developed. We welcome your comments on all aspects of this project. * * Elise Gerich and Daniel Karrenberg * * I will also try to get hold of Daniel as I see time is pressing on this. -Tony -------- Logged at Thu Mar 24 17:12:44 MET 1994 --------- From rlr at merit.edu Thu Mar 24 17:06:40 1994 From: rlr at merit.edu (Rick Riolo) Date: Thu, 24 Mar 94 11:06:40 EST Subject: ripe whois -s dbname question Message-ID: <9403241606.AA07385@mole.merit.edu> Hi, we have four db's set up right now, MERITRR, RIPE, PRDB and TESTRR. All search line includes all but TESTRR. CANUPD includes all but RIPE. I can add things to TESTRR, but how can I get ripe's whois perl script to search in that db? I tried, eg, /u2/rrdb/dbase-beta/bin/whois -s TESTRR 35.0.0.0 but I just get what is in the MERITRR db instead of whats in TESTRR (or I get nothing if its not in MERITRR or others but only in TESTRR). Is there a way to do whois queries to see what is in a specific db, and in particular in a db that is not in the All-search chain? thanks! - r -------- Logged at Thu Mar 24 20:25:24 MET 1994 --------- From epg at merit.edu Thu Mar 24 20:25:12 1994 From: epg at merit.edu (epg at merit.edu) Date: Thu, 24 Mar 94 14:25:12 EST Subject: draft of proposed announcement In-Reply-To: <9403231550.AA08533@fs1.ripe.net>; from "Tony Bates" at Mar 23, 94 4:50 pm Message-ID: <9403241925.AA03088@pepper.merit.edu> Tony, Marten, and Daniel, Try prtraceroute -h rrdb.merit.edu 192.87.45.1 You'll get some combined output from both Merit and RIPE. We have AS 690 data and AS 237 data - a samll start. :-) --Elise -------- Logged at Thu Mar 24 20:50:17 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Mar 24 20:49:54 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 24 Mar 1994 20:49:54 +0100 Subject: ripe whois -s dbname question In-Reply-To: Your message of Thu, 24 Mar 1994 11:06:40 EST. <9403241606.AA07385@mole.merit.edu> Message-ID: <9403241949.AA01999@fs1.ripe.net> "Rick Riolo" writes * * Hi, * we have four db's set up right now, MERITRR, RIPE, PRDB and TESTRR. * All search line includes all but TESTRR. * CANUPD includes all but RIPE. * * I can add things to TESTRR, but how can I get ripe's whois perl script * to search in that db? I tried, eg, * /u2/rrdb/dbase-beta/bin/whois -s TESTRR 35.0.0.0 * but I just get what is in the MERITRR db instead of whats in TESTRR * (or I get nothing if its not in MERITRR or others but only in TESTRR). * * Is there a way to do whois queries to see what is in a specific * db, and in particular in a db that is not in the All-search chain? Actually this should work. I tried the same from here (I assume you have your server running on mole.merit.edu aka rrdb.merit.edu) and my feeling is that this is a configuration error. Could you send me your config so I can have a look? It should never return information from another source than specified with the -s flag ... -Marten -------- Logged at Thu Mar 24 20:56:41 MET 1994 --------- From rlr at merit.edu Thu Mar 24 20:56:51 1994 From: rlr at merit.edu (Rick Riolo) Date: Thu, 24 Mar 1994 14:56:51 -0500 Subject: ripe whois -s dbname question In-Reply-To: Your message of "Thu, 24 Mar 1994 14:52:52 EST." <199403241952.OAA24997@merit.edu> Message-ID: <9403241956.AA08439@mole.merit.edu> laurant, could you please hack it again, eg, so that if -s comes in it respects that (rather than just assuming -a)? thanks! - r -------- > From: Laurent Joncheray > To: Marten.Terpstra at ripe.net (Marten Terpstra) > CC: rlr (Rick Riolo) > Don't worry, i hacked the whois daemon on mole.merit.edu... > That is why you get this answer... > -- lpj > > > > > > "Rick Riolo" writes > > * > > * Hi, > > * we have four db's set up right now, MERITRR, RIPE, PRDB and TESTRR. > > * All search line includes all but TESTRR. > > * CANUPD includes all but RIPE. > > * > > * I can add things to TESTRR, but how can I get ripe's whois perl script > > * to search in that db? I tried, eg, > > * /u2/rrdb/dbase-beta/bin/whois -s TESTRR 35.0.0.0 > > * but I just get what is in the MERITRR db instead of whats in TESTRR > > * (or I get nothing if its not in MERITRR or others but only in TESTRR). > > * > > * Is there a way to do whois queries to see what is in a specific > > * db, and in particular in a db that is not in the All-search chain? > > > > Actually this should work. I tried the same from here (I assume you > > have your server running on mole.merit.edu aka rrdb.merit.edu) and my > > feeling is that this is a configuration error. Could you send me your > > config so I can have a look? It should never return information from > > another source than specified with the -s flag ... > > > > -Marten > > > > > -- > Laurent Joncheray, E-Mail: lpj at 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 -------- Logged at Thu Mar 24 21:11:14 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Mar 24 21:10:52 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 24 Mar 1994 21:10:52 +0100 Subject: ripe whois -s dbname question In-Reply-To: Your message of Thu, 24 Mar 1994 14:56:51 EST. <9403241956.AA08439@mole.merit.edu> Message-ID: <9403242010.AA02038@fs1.ripe.net> Rick Riolo writes * laurant, * could you please hack it again, eg, so that if -s comes in * it respects that (rather than just assuming -a)? * thanks! * - r Perhaps if you tell each other what you do you might avoid these miscommunications ;-) Actually, your query did lead me to another bug in whoisd, which has effect on the -a behaviour (which simply does not work properly due to some other fix I made). Below is the whoisd.pl with the fix (if you are still using it). Simply drop in the src dir, and make install one dir up, and restart. Cheers, -Marten #!PERL # whoisd - whois Internet daemon # # $RCSfile: whoisd.pl,v $ # $Revision: 0.36 $ # $Author: marten $ # $Date: 1994/03/24 20:03:45 $ # @INC = ("LIBDIR", @INC); require "rconf.pl"; require "dbopen.pl"; require "dbclose.pl"; require "enread.pl"; require "enwrite.pl"; require "enkeys.pl"; require "enukey.pl"; require "getopt.pl"; require "misc.pl"; require "dbmatch.pl"; require "syslog.pl"; require "template.pl"; # If we get a SIGALRM, exit. Used in the read loop, to make sure people # do not keep the connection open, and open and open .... sub alarmhandler { print NS "Timeout... Closing connection\n"; close(NS); exit; } # # makekeys - converts a whitespace seperated string of keys into # an array. Trailing zeros in netnumbers are removed. # sub makekeys { local($string) = @_; local(@keys) = (); local($i); $string =~ s/^\s+//; $string =~ tr/A-Z/a-z/; $string =~ s/(\.0)*\.0\s+/ /; $string =~ s/(\.0)*\.0\s*$//; @keys = split(/\s+/, $string); # remove keys shorter than 2 chars, since the indexing does not use # them either ;-) foreach $i (0..$#keys) { if (length($keys[$i]) < 2) { splice(@keys, $i, 1); } } return @keys; } # # lookupandprint - will find all matches for all keys, and will output # the objects found, if they indeed match all the keys. # will also generate an array with keys that should be # looked up recursively because they are referenced in # the printed objects # # Exit codes (set in $result): # -1 - toomany hits (if result != 1 yet) # 0 - no match (if $result was not defined yet) # 1 - OK, something was output (always) sub lookupandprint { local(*db, *keys) = @_; local(%en) = (); local(@matches) = (); local($save) = ""; print STDERR "($$) in lookupandprint\n" if $debug; @matches = &dbmatch(*i, @keys); if (($#matches < 0) && !defined($result)) { $result = 0; return; } for $j (0..$#matches) { if ($matches[$i] == -1) { $result = -1 if $result != 1; return; } %en = &enread(i, $matches[$j]); local($m) = -1; if ($#keys > 0) { foreach (@keys) { $save = $_; foreach (&enkeys(*en)) { if ($save eq $_) { $m++; } } } } else { $m = $#keys; } if ($m == $#keys) { local($uniqkey) = &enukey(*en); if ($displayed{$uniqkey}) { $result = 1; print STDERR "($$) left lookupandprint already seen\n" if $debug; return; } &enwrite(*en, 1); print "\n"; $displayed{$uniqkey} = 1; $result = 1; $type = &entype(*en); if ($RECUR{$type} && !$opt_r) { local(@tmp) = split(/[\s\t]+/, $RECUR{$type}); foreach (@tmp) { local(@r) = split(/\n/, $en{$_}); for ($k=0;$k<=$#r;$k++) { if (!$refd{$r[$k]}) { $refs[$recindex++] = $r[$k]; $refd{$r[$k]} = 1; } } } } } } print STDERR "($$) left lookupandprint\n" if $debug; return; } # fastlookup - small routine to do fast lookups, always non-recursive # it basically just reads from a file, and outputs as fast as it can # without interpreting the data. sub fastlookup { local(*db, *keys) = @_; local($j) = ""; @matches = &dbmatch(*db, @keys); foreach $j (@matches) { $result = 1; seek(db, $j, 0); while () { print; last if /^\s*$/; } print "\n" if eof; } } # # whois - main lookup loop. will output all objects found for all sources # requested. will also process the recursive lookups generated # by lookupandprint() # sub whois { local(*sources, $searchstring) = @_; local(@keys) = &makekeys($searchstring); print STDERR "($$) in whois\n" if $debug; foreach (@sources) { %displayed = (); local(*i) = 'currentdb'; &dbopen(i, $DBFILE{$_}); if ($opt_F) { &fastlookup(*i, *keys); } else { &lookupandprint(*i, *keys); } for ($j=0;$j<$recindex;$j++) { local(@refkeys) = &makekeys($refs[$j]); &lookupandprint(*i, *refkeys); } undef(@refs); $recindex=0; &dbclose(*i); } print STDERR "($$) left whois\n" if $debug; } # # parse - parses the command line string for special options and sets # appropriate variables # sub parse { local($string) = @_; print STDERR "($$) got in parse\n" if $debug; # Reset all command line arguments, except -k @source = (); $opt_a = 0; $opt_r = 0; $opt_F = 0; $opt_s = 0; $string =~ s/^\s+//; if ($string =~ /^help/) { open (HELP, $HELP); while () { print; } close(HELP); exit; } while ($string =~ /^-/) { if ($string =~ s/^-([arkF])\s*//) { eval "\$opt_$1 = 1;"; next; } if ($string =~ s/^-(s)\s+(\S+)\s+//) { local($src) = $2; $src =~ tr/a-z/A-Z/; @source = (@source, $src); $opt_s = 1; next; } if ($string =~ s/^-V(..[0-9]+[0-9\.]*)\s*//) { $opt_V = $1; next; } if ($string =~ s/^\-t\s+(\S+)//) { local($type) = $1; $type = $ALIAS{$1} if $ALIAS{$1}; $type = $ATTR{$1} if $ATTR{$1}; if (!$OBJATSQ{$type}) { print "No template available for object \"$type\"\n"; $result = 1; $opt_t = 1; return $type; } &Template($type); $opt_t = 1; $result = 0; return $type; } last; } if ($opt_a) { @source = split(/\s+/, $ALLLOOK); } elsif (!$source[0]) { @source = split(/\s+/, $DEFLOOK); } print STDERR "($$) left parse\n" if $debug; return $string; } # # Main program # # Read config file from RIPEDBCNF, or set to default. $conffile=$ENV{"RIPEDBCNF"}; $conffile= "DEFCONFIG" unless $conffile; &rconf($conffile); # If there are command line options, other than -d (for debug) # do not run as daemon, but process the command line and exit. if (($ARGV[0] ne "-d") && ($#ARGV>=0)) { local($cmdline) = ""; for $i (0..$#ARGV) { $cmdline .= $ARGV[$i]." "; } $string = &parse($cmdline); &whois(*source, $string); exit; } else { if ($ARGV[0] eq "-d") { print STDERR "($$) running in debug mode\n"; $debug = 1; } else { # detach from tty exit 0 if (fork() > 0); if (open(FILE, "/dev/tty")) { if (!ioctl(FILE,(0x20000000|(ord('t')<<8)|113),0)) { print STDERR "ioctl: $!\n" if ($debug); } close(FILE); } close(0) if -t; } } $port = 43 unless $port; print STDERR "($$) running on port $port\n" if ($debug); $AF_INET = 2; $SOCK_STREAM = 1; $SOL_SOCKET = 0xffff; $SO_REUSEADDR = 0x0004; $sockaddr = 'S n a4 x8'; ($name, $aliases, $proto) = getprotobyname('tcp'); if ($port !~ /^\d+$/) { ($name, $aliases, $port) = getservbyport($port, 'tcp'); } $this = pack($sockaddr, $AF_INET, $port, "\0\0\0\0"); select(NS); $| = 1; select(STDOUT); socket(S, $AF_INET, $SOCK_STREAM, $proto) || die "socket: $!"; setsockopt(S, $SOL_SOCKET, $SO_REUSEADDR, 1) || die "setsockopt: $!"; while (!bind(S, $this)) { if ($bindcount >= 20) { print STDERR "whoisd: bind() failed 20 times, giving up\n"; &syslog("ERRLOG", "whoisd cannot bind() for 20 times, giving up"); exit 1; } else { print STDERR "-- bind: $!, trying again\n" if ($debug); $bindcount++; sleep 5; } } if ($bindcount) { &syslog("ERRLOG", "whoisd needed $bindcount binds before succeeding"); } listen(S,5) || die "listen: $!"; select(S); $| = 1; select(STDOUT); # Set up the alarm handler $SIG{'ALRM'} = 'alarmhandler'; # We have come this far, let's write the PID to $PIDFILE, useful for # killing and stuff. if (open(PID, ">$PIDFILE")) { print PID "$$\n"; close(PID); } else { &syslog("ERRLOG", "cannot write to $PIDFILE: $!"); } # Main waiting loop, wait for connection, and fork of child to process # the incoming request for (;;) { ($addr = accept(NS,S)) || die $!; if (($child = fork()) == 0) { ($af,$port,$inetaddr) = unpack($sockaddr,$addr); @inetaddr = unpack('C4', $inetaddr); $rhost = "$inetaddr[0].$inetaddr[1].$inetaddr[2].$inetaddr[3]"; print STDERR "($$) fork connection [$rhost]\n" if $debug; local($name,$alias,$at,$len, at addr)=gethostbyaddr($inetaddr,$af); if ($name eq "") { $name = $rhost; } # Set alarm to timeout after people did not send anything # in 60 seconds alarm 60; while() { $result = 0; # Got something, reset alarm; alarm 0; chop; # we want at least some alphanumeric stuff ... if (/\w+/) { select(NS); $string = &parse($_); print STDERR "($$) lookup $string\n" if $debug; if (!$opt_t) { &whois(*source, $string); print $NOMATCH,"\n" if $result == 0; print $TOOMANY,"\n" if $result == -1; select(STDOUT); if ($opt_k) { print NS "\n"; alarm 60; } else { close(NS); } } else { close(NS); } } # got something completely non-alphanumeric else { select(NS); $string = $_; print STDERR "($$) lookup $string\n" if $debug; print "Cannot lookup non-alphanumeric keys\n"; print "Connection closed\n"; $result = 0; select(STDOUT); close(NS); } # Log this query $flags = ""; for $fl ("d", "a", "s", "k", "r", "F", "t") { if (eval "\$opt_$fl;") { if ($flags) { $flags .= ":"; } $flags .= "$fl"; } } if ($opt_V) { if ($flags) { $flags .= ":"; } $flags .= "V$opt_V"; } &syslog("QRYLOG","($$) [$flags] $result $name $string"); } close(NS); print STDERR "($$) exit connection [$rhost]\n" if $debug; exit; } while (waitpid(-1, 1) > 0) {} } -------- Logged at Thu Mar 24 21:11:44 MET 1994 --------- From Tony.Bates at ripe.net Thu Mar 24 21:11:13 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 24 Mar 1994 21:11:13 +0100 Subject: draft of proposed announcement In-Reply-To: Your message of Thu, 24 Mar 1994 14:25:12 EST. <9403241925.AA03088@pepper.merit.edu> Message-ID: <9403242011.AA14241@reif.ripe.net> epg at merit.edu writes: * Tony, Marten, and Daniel, * * Try prtraceroute -h rrdb.merit.edu 192.87.45.1 * * You'll get some combined output from both Merit and RIPE. We * have AS 690 data and AS 237 data - a samll start. :-) * --Elise Looks pretty good. --Tony. traceroute with AS and policy additions [Mar 24 20:10:12 UTC] from AS1104 reif.ripe.net (192.87.45.3) to AS 237 fox.merit.edu (35.42.1.69) 1 AS1104 hef-router.nikhef.nl 192.87.45.80 [I] 4 6 2 ms 2 AS1103 Amsterdam1.router.surfnet.nl 192.16.183.112 [D1] 3 3 7 ms 3 AS1128 Amsterdam1.dante.net 192.87.4.35 [E?] 5 3 4 ms 4 AS1128 icm-dante.icp.net 194.41.0.18 [I] 572 570 578 ms 5 AS ??? icm-dc-1-E4/1.icp.net 192.157.65.225 [?] 571 574 567 ms 6 AS ??? icm-fix-e-H2/0.icp.net 192.157.65.122 [?] 580 570 569 ms 7 AS ??? mf-0.enss145.t3.ans.net 192.203.229.246 [?] 581 574 576 ms 8 AS 690 t3-1.Washington-DC-cnss58.t3.ans.net 140.222.58.2 [?] 573 571 581 ms 9 AS 690 mf-0.Washington-DC-cnss56.t3.ans.net 140.222.56.222 [I] 576 573 572 ms 10 AS 690 t3-0.New-York-cnss32.t3.ans.net 140.222.32.1 [I] 582 585 580 ms 11 AS 690 t3-1.Cleveland-cnss40.t3.ans.net 140.222.40.2 [I] 596 594 592 ms 12 AS 690 mf-0.Cleveland-cnss41.t3.ans.net 140.222.40.193 [I] 595 636 588 ms 13 AS 690 t3-0.enss131.t3.ans.net 140.222.131.1 [I] 598 593 606 ms 14 AS 233 192.203.195.4 192.203.195.4 [E?] 600 598 616 ms 15 AS 237 fox.merit.edu 35.42.1.69 [E?] 603 598 600 ms AS Path followed: 1104 1103 1128 ??? 690 233 237 AS1104 = NIKHEF-H AS1103 = SURFnet IP AS1128 = EuropaNET PoP Amsterdam AS 690 = NSFNET Configurations AS 233 = UM Campus Network AS 237 = MichNet -------- Logged at Fri Mar 25 13:24:06 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Mar 25 13:16:30 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 25 Mar 1994 13:16:30 +0100 Subject: draft of proposed announcement In-Reply-To: Your message of Wed, 23 Mar 1994 10:29:24 EST. <9403231529.AA02800@pepper.merit.edu> Message-ID: <9403251216.AA05263@fs1.ripe.net> Elise, I am currently too ill to think straight and this has more sensitivities than I want to ponder in this condition. I suggest: If you are under pressure to announce before or during IETF then go ahead and do so yourself saying something like "initially based on RRIPE RR, usable by PRIDE tools". We can make joint announcements once the dust settles and I can think straight again. If you want to wait until after IETF for a joint one that is fine too. I don;t care which way. Sorry but there are large pitfalls here which could affect our funding situation. Daniel PS: Doctors advice: Stay put. Try to drink faster than you sweat it out. Very encouraging! -------- Logged at Fri Mar 25 17:22:31 MET 1994 --------- From epg at merit.edu Fri Mar 25 15:50:16 1994 From: epg at merit.edu (epg at merit.edu) Date: Fri, 25 Mar 94 9:50:16 EST Subject: draft of proposed announcement In-Reply-To: <9403251216.AA05263@fs1.ripe.net>; from "Daniel Karrenberg" at Mar 25, 94 1:16 pm Message-ID: <9403251450.AA03347@pepper.merit.edu> Daniel, > > > Elise, > > I am currently too ill to think straight and this has more sensitivities > than I want to ponder in this condition. I suggest: > Sorry to hear how ill you are - do hope that the whole family has not gotten sick! > If you are under pressure to announce before or during IETF then go ahead > and do so yourself saying something like "initially based on RRIPE RR, usable > by PRIDE tools". We can make joint announcements once the dust settles and > I can think straight again. > We would prefer to make a joint announcment with you all for many reasons - mostly because we see this as an ongoing collaboration. In fact, Laurent hopes that Marten and he can work together to modify prtraceroute to work with the new whoisd (just one example). So we will hold off until you are thinking straight. We would like to talk about this at IEPG and IETF in an informal way, and inidcate that we are still in the initial stages and will make a formal announcment soon. > If you want to wait until after IETF for a joint one that is fine too. > I don;t care which way. > > Sorry but there are large pitfalls here which could affect our funding > situation. > Seems there is a lot to be done - probably lots we haven't even thought of - hope whatever the hurdle is it is surmountable. Get better soon! --Elise -------- Logged at Tue Mar 29 00:23:55 MET DST 1994 --------- From dsj at merit.edu Tue Mar 29 00:23:46 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 28 Mar 1994 17:23:46 -0500 Subject: Classless RIPE-81 Message-ID: <199403282223.RAA11610@merit.edu> Tony, > After a quick look through this certainly looks to be something we can > come to consensus on reasonably quikcly. If I underastand this > correctly it gives us a similar amount of database information for > CLNP as we have today for IP and maps very nicely to boot. Form an > implementation (RIPE database) point of view these new objects and > attributes should not be a problem as soon as the DB indexing system > is truly classless which it isn't today. FYI: Rick and Laurent have our copy of the RIPE DB code working with IP aggregate notation (e.g. takes both 192.0.0/24 and 192.0/16 as independent registrations). Is that sufficient? --Dale -------- Logged at Tue Mar 29 00:26:12 MET DST 1994 --------- From lpj at merit.edu Tue Mar 29 00:26:04 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 28 Mar 94 17:26:04 EST Subject: Classless RIPE-81 In-Reply-To: <199403282223.RAA11610@merit.edu>; from "Dale S. Johnson" at Mar 28, 94 5:23 pm Message-ID: <199403282226.RAA11694@merit.edu> > FYI: Rick and Laurent have our copy of the RIPE DB code working with > IP aggregate notation (e.g. takes both 192.0.0/24 and 192.0/16 as > independent registrations). Is that sufficient? No. It is a temporary trick/hack/kludge. -- Laurent -------- Logged at Thu Mar 31 04:54:14 MET DST 1994 --------- From dsj at merit.edu Thu Mar 31 04:54:07 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 30 Mar 1994 21:54:07 -0500 Subject: Distributed RIPE?? Message-ID: <199403310254.VAA22195@merit.edu> Hi-- Bill Manning has done some playing with MERITRR. As near as I can tell, most of the problems he has encountered have been his own (misspelling "auto-dbm", not seeing files that were there). We haven't been totally ready for him (e.g. it took several hours to be able to answer him about the status of AS-macros, and it took me several hours to find out (from Rick) what I was doing wrong in running "cleandb"). He has also been staying up nights installing and playing with Mark Kosters' "rwhois". Bill has made comments to both Jessica and me about "this may make the Merit Routing Registry obsolete": e.g., if he can enter data on his own machine that will then work with prtraceroute (Kosters set up a demo of doing this). Here are my initial reactions to this: 1) The RIPE software has always been intended to evolve to a truly distributed configuration. (Right?) What Bill is suggesting is compatible with our joint intended direction. As I understand it, though, RIPE has no cycles to pursue this goal at the moment. Is this correct? 2) Even if the DB becomes totally distributed like this, there still needs to be software as part of that distribution to do local data entry, syntax checking, etc. We could (jointly) supply that. 3) Even under rwhois, the pr* tools need to be enhanced to support such distributed data. 4) Jessica and I talked about doing the "Aggregate Registry" this way; I think that registry is probably the least suitable project for rwhois, since rwhois needs a delegation chain (like for IP addresses) and there isn't such a thing for aggregates. rwhois seems to have a fair bit to offer. We might roll Bill's ideas into our upcoming discussions (when??) on what to do about RIPE whois servers. --Dale -------- Logged at Thu Mar 31 08:07:32 MET DST 1994 --------- From jyy at merit.edu Thu Mar 31 08:06:59 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 31 Mar 1994 01:06:59 -0500 Subject: Distributed RIPE?? Message-ID: <199403310606.BAA05092@merit.edu> 4) Jessica and I talked about doing the "Aggregate Registry" this way; I think that registry is probably the least suitable project for rwhois, since rwhois needs a delegation chain (like for IP addresses) and there isn't such a thing for aggregates. ***I actually suspect Bill would propose this and try to evaluate ***pros and cons of such mechanism. --Jessica -------- Logged at Fri Apr 1 19:04:51 MET DST 1994 ---------