- db-wg - mailman.ripe.net

AS690 advisory update
by Steve Heimlich 16 Nov '95

16 Nov '95

Folks, As previously mentioned, ANS is moving to a new configuration system which will eliminate the need for registering AS690 advisories with RIPE-181 route objects. Our initial deployment described below has gone well, and as a result we will freeze our aut-num (currently still machine generated based on advisories) on Friday, 11/17, at midnight ET (Saturday, 11/18, 5am GMT). Tuesday morning's AS690 config run will use the frozen aut-num. After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today. Refinement of AS690 import policies will begin on a per AS basis next week, starting with large origin ASes. The human readable version of the 18,000 line AS690 aut-num is currently available at: ftp://ftp.ans.net/pub/info/routing-stats/aut-num-as-690 Steve -------- To: nanog(a)merit.edu Subject: AS690 policy configuration changes Date: Mon, 06 Nov 1995 18:43:22 -0500 From: Steve Heimlich <heimlich(a)kingbee.ans.net> All, Starting with Friday [11/10] morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

4 5

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

What happens if policy changes for those AS'es? i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*) How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies? _k > Elliot, > > Ignore the advisory. If AS2 is the origin, we will route traffic > for that particular prefix/masklen using the most common policy > already in place for routes in AS2. > > If the common policy is for us to send traffic destined for AS2 > via our peer AS1, we will continue to do so for the new prefix/masklen. > > Steve > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > routes registered in the IRR will be based solely on origin AS. > > > The origin AS will be expanded to the set of route objects registered > > > for that origin AS; the resulting list of prefixes will be used in > > > generating router configurations, as today. > > > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object > > and list themselves as the origin, and put AS#1 in the advisory. in the > > new scenario, will ANS now only allow routes coming via the ASN in the > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field > > to AS#1 so ANS knows where to look for for the routes? > > > > - elliot alby/sprintlink implementation > >

2 1

Re: too many hits?
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 06 Nov '95

06 Nov '95

>So, no it's not an error or indexing problem. It is an design issue. >Changing this behavior can be done but might cause other unwanted effects >for people (or tools) that make use of this feature that look for more >objects at the same time. Dear David, if this is a design issue why doesn't give whois -h whois.ripe.net "panigl woeber" a result ? Both are valid person objects ! Or do I need a special whois client for this multi-object behaviour ? If it is a design issue (restricted by some DBM implementation) could you then please give us a hint how to specify in a whois query, that "Stefan Anders" isn't meant as multi-object but as single-object lookup (perhaps there is or could be a switch for running such a request in slow-mode without using the incomplete index) ? Daniel's suggestion "Please use handles" is nice but should we now go into querying for "SAn-RIPE" (for n=1..10000) and collect all "Stefan Anders" out of the result if we don't know the handle for a given person ? Doesn't sound very healthy ... Kind regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

too many hits?
by Schmitz＠rus.uni-stuttgart.de 06 Nov '95

06 Nov '95

Dear all, lately I get messages from the RIPE database when querying it with whois that there are too many hits, e.g: jade$ whois -h whois.ripe.net "Stefan Anders" The index search returned too many hits. Please refine your search key. I had a look at the database and there are exactly three entries which contain the string "Stefan Anders": jade$ grep "Stefan Anders" ripe.db.pn *pn: Stefan Andersson *pn: Stefan Anders *pn: K A Stefan Andersson Does not seem to be a lot, does it? Is this an error of the database software or is it an indexing problem (there have been other problems reported on the indexing software in the last weeks...)? Regards Joachim _______________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)rus.uni-stuttgart.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5576 voice Allmandring 30 ++ 711 678 7626 FAX D-70550 Stuttgart FRG (Germany) _______________________________________________________________________________

3 2

Re: Modification of RIPE-181's as-in/as-out attributes
by Curtis Villamizar 01 Nov '95

01 Nov '95

In message <199510311942.AA07667(a)cat.isi.edu>, Cengiz Alaettinoglu writes: > > I like this idea. There is only one problem that I see with it. The > as numbers in as-in and as-out lines are often used (by tools like > prpath and prtraceroute) to deduce the topology of the Internet. If an > AS only specifies a policy like: > > aut-num: AS2 > as-in: from (NOT AS1) 5 accept ANY > > then prpath has no way of deducing the neighbors of AS2. Doesn't that deduction belong in the inet-rtr ifaddr and peer lines? > aut-num: AS2 > neighbor-list: AS3, AS4, AS5, AS1 # pehaps with router addresses? This is reasonable for AS that don't provide inet-rtr records for their routers (I suspect most). Curtis

1 0

Draft minutes, DB-WG at RIPE #22
by Wilfried Woeber, UniVie/ACOnet 30 Oct '95

30 Oct '95

This is the draft minutes of the RIPE-DB - WG meeting. Many thanks to Hans Petter Holen for taking notes (any typos are mine :-)! Any additions, clarifications appreciated! Wilfried. ________________________________________________________________________________ Draft Minutes: Database-WG, RIPE 22, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Hans Petter Holen, Oslonett AS, volunteered to take notes. 37 people subscribed to the circulated list of attenders. The proposed WG-agenda was accepted. 1. DB-SW review David Kessens went through the Database Development Report, covering new functionality that is either being proposed or already in test. As usaul the slides for this presentation are available at ftp://ftp.ripe.net/ripe/presentations/ripe-m22-david-DB-REPORT.ps.gz David reported that the NCC currently works towards making the RIPE-DB more reliable. On the hardware aspect the DB-machine is being fitted with a RAID system (to guard against single disk drives failures). At the same time a "shadow server" for the database is being implemented and tests have already begun. Some problems with portability and scaling of the database software have been reported recently. It was pointed out that the RIPE-NCC version of the database software is tested and supported for Perl4. There is a couple of known (minor) problems in trying to port the software to Perl5 (and to Solaris). Resolving of these problems is not the top priority, but will be tackled as soon as possible. In order to avoid the scaling problems David recommended to *not* use the -P option of netdbm and to eventually move to the Berkley db package. Tests are on-going. New functionality worth noting (for a comprehensive list please refer to the presentation slides): - Hierarchial authorisation schemes to be implemented - Referral mechanisms to be implemented, first tests with domain: objects - -t option plus -v should give more elaborate descriptive text for objects - The NOC-Object to be implemented soon, according to proposal from Havard Eidnes, as circulated shortly after RIPE-21 - "Synchronized DB" is running in test environment - There is a proposal to automate and inter-lock the assignment of RIPE-Handles. This should eventually remove the need to manually obtain unique handles (with the finger mechanism) and the potential race condition due to the delay between assignment of a handle and submitting/referencing the objects. - Inverse lookup, initially for person: objects The same functionality was requested for other object types during the discussion specifically to get better selection criteria for entries in the routing registry. While part of this functionality is available by accessing the data through wais, this was seen as not really adequate. Still this method should be improved as much as possible! - Authentication and Security This is currently under active consideration. In particular both PGP and MD5 should be available. There are both legal/logistic issues (see below) as well as software issues. In particular we have to decide on the method for registering keys and whether to use a "standard package" or to move functionality into the database software itself. During the discussion it was suggested to stick with "standard packages" because things are not yet stable. (Merit is using the "standard package" as well.) The RIPE-NCC is probably following the same path. 2. User interface(s) Encryption is probably going to be a legal problem in (at least) France. In addition to that there was a comment that part of the technology has recently been submitted for patent protection. Probably the first thing to be available shall be PGP protection for signing messages. The details to guard against snooping and re-play of updates are currently be solved. (Detailled input has been received after the WG meeting). A couple of WWW interfaces to the various databases have been made available recently. There is not yet consensus whether this is the right way to go, especially for submitting updates. The RIPE NCC thinks that the DB is not focussed toward the "end user" but towards ISPs. Other comments indicated that the WWW interface could be useful for all sorts of operational people as a well-known user interface. Both Brian Renaud <renaud@meritedu> as well as Paolo Bevilacqua <pab(a)uni.net> have recently made implementations available: - http://black.uni.net/cgi-bin/whois - http://www.ra.net/cgi-bin/ra/query-radb.pl 3. External interfaces Exchange of data with the InetNIC is still not happening. All the necessary agreements and good intentions are in place, still the InterNIC seems to regard it as a low priority issue. European ISPs want this to work really soon and regard it as *urgent*. There is not much the NCC can do right now. The different functionality of the auto-assign vs. auto-dbm mailboxes was briefly reviewed. The differences as not widely known, and the interlocks could be improved. The NCC thinks about moving towards keywords on the subject line, similar to "LONGACK". 4. Input from other WGs - MBone The expansion of the inet-rtr: object to cover multicast functionality is to be progressed now. - IPv6 There is a discussion going on how to handle and possibly abbreviate things for IPv6 (macros?). Input welcome. There was a comment that similar ideas are being (or have been) discussed in the RPS environment. 5. AOB None, thus the meeting was closed. ________________________________________________________________________________ List of new actions: David Kessens: To work with A. Blasco Bonito to improve the WAIS functionality for access to the database information on info.ripe.net. Geert-Jan de Groot: To try to follow up with the InterNIC about accepting person objects with RIPE-Handles. RIPE-NCC: To circulate a proposal how to progress the authentication (and encryption) method for the RIPE Database. RIPE-NCC: To analize the merits of implementing special keywords for the subject line of update messages, like ADD, MOD, DELETE, to possibly replace the functionality of special mailbox names (e.g. auto-assign). RIPE-NCC: To follow up on and implement the NOC-Object. WW, 27.10.95, yes I know, much too late...

1 0

Modification of RIPE-181's as-in/as-out attributes
by Steven J. Richardson 25 Oct '95

25 Oct '95

In the process of reviewing RIPE-181-represented policies, I've noticed an opportunity for what I think would be a useful modification of the as-in/as-out attributes of the aut-num object. Currently, the syntax for these attributes is given as: as-in: from <aut-num> <cost> accept <routing policy expression> as-out: to <aut-num> announce <routing policy expression> I see policies which would be usefully condensed via allowing the <aut-num> to be an AS *macro*, too. E.g.: aut-num: 99999 as-name: SOMEAS ... as-in: from AS10 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS20 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS30 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS40 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS50 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS60 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS70 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS110 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS120 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS130 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS140 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS150 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS160 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS170 150 accept ANY AND NOT {0.0.0.0/0} could be equivalent to: aut-num: 99999 ... as-in: from AS-SOMEAS-100-NO-DEFAULT 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS-SOMEAS-150-NO-DEFAULT 150 accept ANY AND NOT {0.0.0.0/0} with the macro definitions: as-macro: AS-SOMEAS-100-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 100 (any but descr: the default route) as-list: AS110 AS120 AS130 AS140 AS150 AS160 AS170 ... as-macro: AS-SOMEAS-150-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 150 (any but descr: the default route) as-list: AS10 AS20 AS30 AS40 AS50 AS60 AS70 ... (The same could be said of as-out lines.) What do you think? Steve Richardson/Merit

2 2

Re: Proposal on applying advisory attribute to "aut-num" object
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 24 Oct '95

24 Oct '95

>Date: Mon, 23 Oct 1995 15:19:25 -0400 >From: "Steven J. Richardson" <sjr(a)merit.edu> > > I think that this idea, while good, may be too restrictive unless > coupled with the ability to override this "global" advisory by > setting the "advisory" attribute of a specific prefix which originates > within the AS. Steve, I fully agree and I did mean and say this but didn't explicitely write it down in my proposal :-( Unfortunately the wording in RIPE-131 isn't that explicit either, because it was written before your comment has arrived (sometimes the RIPE-NCC is really too fast ;-) >Date: Tue, 24 Oct 1995 10:44:42 +0100 >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> > >To sum up: > >ANS is not going to use advisories in aut-num since they will do away with >advisories in at most two weeks. > >The advisory attribute will stay in aut-num objects and we all hope noone >is going to use them again, ever. Daniel and David, is it worth the effort changing the one RIPE-131 paragraph to: The advisory attribute of a route object applies to the specific route. The advisory attribute of an aut-num object is intended to apply as default to all routes originated by the autonomous system in question providing a shorthand notation if the same advisory applies to most or all such routes. If both are present the advisory attribute of a route object takes precedence over the advisory attribute of the aut-num object. As with all advisories the specific semantics are defined by the 'target' AS. My feeling is, if you decided to keep it, it should be properly documented. Sorry for my incomplete proposal ! Regards Christian

2 1

Re: Proposal on applying advisory attribute to "aut-num" object
by zsako＠banknet.net 24 Oct '95

24 Oct '95

> From owner-db-wg(a)ripe.net Fri Oct 20 21:22:16 1995 Christian, > The famous "advisory" attribute which seems to be still needed by ANS to > get their routing done is especially cumbersome because it has to be > applied to and maintained for every single "route" object. If the > "advisory" attribute could be added to the "aut-num" object, entering an > "advisory" there could cover all routes originated by this AS. Of > course the ANS people will have to slightly modify their software. As far as I see David Kessens has already made the necessary changes in the DB software. :) zsako/banknet $ whois -h whois.ripe.net "-t aut-num" aut-num: [mandatory] [single] as-name: [optional] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] as-out: [optional] [multiple] advisory: [optional] [single] <<<<<<---------- interas-in: [optional] [multiple] interas-out: [optional] [multiple] as-exclude: [optional] [multiple] default: [optional] [multiple] guardian: [optional] [single] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] > > Comments welcome ! I would like to make some comments on the above. First of all, with respect to the `[single]' qualifier. If we indeed allow only one such advisory attribute for the AS (aut-num), then the AS can express its advisory recommendations to only one other AS for ALL of it routes. I know that this is somewhat theoretical, since only ANS use the advisory... Nevertheless ripe-130 says it could be used by any other organisation, although *everybody* is discouraged from using it at all. An other approach to this problem would not need any change in the DB schema. We have the `remarks' attribute which can be used for any additional information related to the AS. I think it could also contain something like: "advisory: AS690 1:1800 2:1133 3:1239" which means, the aut-num would have the following remarks attribute: remarks: advisory: AS690 1:1800 2:1133 3:1239 In this case any AS could add as many remarks as needed for the advisories... This is true for the `route' object as well. I know it is not a good practice to use the attributes for other purpose than they are designed for, but in this case I feel the advisory is not more than a remark (actually an important one if you want to have NSFnet connectivity...). Two other arguments are in favour of this second solution: first is that RIPE descourages people from using the advisory, second is that ANS should be ready with the new software soon, and then nobody would (or at least should) use the advisory any more. As you said, ANS have to make some (probably minor) changes in their software in order to get the advisory from the aut-num for all the routes originating in the AS corresponding to the aut-num. I do not think these changes are significantly less in the case there is an `advisory' attribute in the aut-num object, than in the case they have to parse the `remarks' attributes of the aut-num. Further comments welcome! Best regards, Janos Janos Zsako zsako(a)banknet.net BankNet Tel: +36 1 160 16 42 Fax: +36 1 160 14 06

6 5

Re: Proposal on applying advisory attribute to "aut-num" object
by Steven J. Richardson 23 Oct '95

23 Oct '95

Christian: I think that this idea, while good, may be too restrictive unless coupled with the ability to override this "global" advisory by setting the "advisory" attribute of a specific prefix which originates within the AS. Steve Richardson/Merit >From owner-db-wg(a)ripe.net Fri Oct 20 16:13:34 1995 >Date: Fri, 20 Oct 1995 21:08:19 MET >From: "Christian Panigl, ACOnet/UniVie +43 1 4065822-383" > <panigl(a)cc.univie.ac.at> >To: db-wg(a)ripe.net >Cc: domain-admin(a)cc.univie.ac.at >Message-Id: <009982B8.A55165BA.3(a)cc.univie.ac.at> >Subject: Proposal on applying advisory attribute to "aut-num" object >Status: R > > Dear colleagues, > > at RIPE22 I made the following proposal which I would like to be built > into the RIPE-DB and other routing registry databases: > > The famous "advisory" attribute which seems to be still needed by ANS to > get their routing done is especially cumbersome because it has to be > applied to and maintained for every single "route" object. If the > "advisory" attribute could be added to the "aut-num" object, entering an > "advisory" there could cover all routes originated by this AS. Of > course the ANS people will have to slightly modify their software. > > Example: > >aut-num: AS760 >descr: University of Vienna, Austria >descr: AT >as-in: from AS679 100 accept AS679 >as-in: from AS1115 100 accept AS1115 >as-in: from AS1776 100 accept AS1776 AS1117 >as-in: from AS1853 100 accept ANY >as-in: from AS2494 100 accept AS2494 >as-out: to AS1853 announce AS-UDNVIE >as-out: to AS679 announce ANY >as-out: to AS1115 announce ANY >as-out: to AS1776 announce ANY >as-out: to AS2494 announce ANY >default: AS1853 100 >advisory: AS690 1:1800 2:1133 3:1239 <<<<<<<<<<<<<<< >guardian: domain-admin(a)univie.ac.at >admin-c: HS118 >tech-c: EJ63 >tech-c: FK17-RIPE >mnt-by: AS760-MNT >changed: panigl(a)univie.ac.at 951020 >source: RIPE > > Comments welcome ! > > Regards > Christian > > --- Christian Panigl : Vienna University Computer Center - ACOnet --- > --- VUCC - ACOnet : -------------------------------------------- --- > --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- > --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

1 0