April 1994 - routing-wg - mailman.ripe.net

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

29 Apr '94

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

1 0

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

27 Apr '94

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

3 2

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

26 Apr '94

Wilfried has some mail connectivity problems to the RIPE NCC, therefore he asked me to resend the mail below concerning the as-in and as-out attributes. -Marten ------- Forwarded Message Date: Tue, 26 Apr 1994 16:36:51 +0100 From: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> Sender: <woeber(a)cc.univie.ac.at> To: marten(a)ripe.net cc: woeber(a)cc.univie.ac.at Subject: Fwd: Re: Invalid data in the RIPE database Marten, this was (one of) the message(s) that made it to L.Joncheray, but didn't reach you personally and the -wg lists. Maybe you could forward them, to keep the chaos down to a reasonable level. Sorry, Wilfried. From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-APR-1994 11:31 :48.07 To: MX%"Marten.Terpstra(a)ripe.net" CC: MX%"lpj(a)merit.edu",MX%"routing-wg(a)ripe.net",MX%"db-wg(a)ripe.net",WOEBER Subj: Re: Invalid data in the RIPE database =Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> writes = * = * > Laurent Joncheray <lpj(a)merit.edu> writes: = * > Dear database managers, = * > i had a look at some entries in the RIPE database and at the = * > 'nsf-in' network attribute. For a lot of them the value in the RIPE = * > db is inconsistant with the Merit (NSF) database... = * = * More radical question: Considering that the NSFnet is going away and = * the routing registry has routing policy, should these attributes = * be deprecated or even removed totally? = =Jean-Michel writes = = * 1- obsolete this field. = * 2- Implement what Laurent proposes (automatic download from Merit). = =I feel for Daniels and Jean-Michel's first option. They should =definately be deprecated (although I have always viewed them as info =only attibutes) and preferably removed. Although some people may find I agree with this point of view. I'm going to put it on the agenda for the DB-WG at the Amsterdam RIPE-Meeting. We should have a *short* review and then agree on a proposal and a *timeschedule* to remove this information from the database. =this information useful currently, wrong information is worse than no =information. I'd say obsolete. Agreed. At the same time we should come up with a recommendation for new ways of storing pieces of information that people maybe still want to record in the DB. (Like connect, gateway, and the like). Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- ------- End of Forwarded Message

1 0

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

26 Apr '94

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

4 3

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

26 Apr '94

A new tool ("aggrwalk") to expand an aggregate into known compoments is available on rrdb.merit.edu:pub/meritrr/aggrwalk.tar.Z This tool gets all the info from the RIPE database, Merit Routing Registry DB, and NSF DB. It also adds usefull info like home AS, network name or NSF announcement list. Here is an example: % aggrwalk.pl -a -A cntry 193.74.240/20 Connected to ALC server Aggregate Database(s) homeas cntry <193.74.240/24> RIPE-DB BE <193.74.241/24> RIPE-DB BE <193.74.242/24> RIPE-DB AS1891 BE <193.74.243/24> RIPE-DB BE <193.74.244/24> RIPE-DB BE <193.74.245/24> RIPE-DB BE <193.74.247/24> RIPE-DB BE <193.74.248/24> RIPE-DB BE <193.74.249/24> RIPE-DB AS1891 BE <193.74.250/24> RIPE-DB:NSF_DB AS1891 BE <193.74.251/24> RIPE-DB AS1891 BE <193.74.252/24> RIPE-DB AS1891 BE <193.74.254/24> RIPE-DB AS1891 BE -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

1 0

Re: Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Why not deciding this by mail and doing it *now*? (since everybody seems to agree) 10 min to remove those lines from the DB file (grep -v is fine) 10 min to disable the nsf-in attribute in the conf file (or dbupdate.pl) 1h ? to rebuilt the index file. No big deal... > =I feel for Daniels and Jean-Michel's first option. They should > =definately be deprecated (although I have always viewed them as info > =only attibutes) and preferably removed. Although some people may find > > I agree with this point of view. > > I'm going to put it on the agenda for the DB-WG at the Amsterdam > RIPE-Meeting. We should have a *short* review and then agree on a > proposal and a *timeschedule* to remove this information from the > database. > > =this information useful currently, wrong information is worse than no > =information. I'd say obsolete. > > Agreed. > At the same time we should come up with a recommendation for new > ways of storing pieces of information that people maybe still want to > record in the DB. (Like connect, gateway, and the like). > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Wilfried.Woeber(a)CC.UniVie.ac.at > Computer Center - ACOnet : > Vienna University : Tel: +43 1 4065822 355 > Universitaetsstrasse 7 : Fax: +43 1 4065822 170 > A-1010 Vienna, Austria, Europe : NIC: WW144 > -------------------------------------------------------------------------- > -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

2 1

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

26 Apr '94

Hello, I would prefer to obsolete this field. Gilles

2 1

Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant? Thanks for your answer, Laurent -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

7 6

Whois database and list of networks
by Daniele Vannozzi 22 Apr '94

22 Apr '94

We would like to know your opinion about this problem and our proposal. The GARR-NIS manages a whois database (whois.nis.garr.it) where each network is described with the RIPE database format plus other "italian GARR-NIS" tags. We produce the access lists for the GARR border routers starting from GARR-NIS whois database (we use the nlc tool). In addition to that we are requested to produce the "aggregate" networks list (CIDR) from GARR-NIS database as well. In our opinion it is difficult to get the right information about network blocks from the whois database as it is currently managed because many network blocks are splitted in smaller blocks (usually corresponding to the really announced networks or because of different contact point). We would like to announce the whole original block while maintaining into the GARR-NIS database the splitted blocks. An additional gain using this scheme would be to store different rev-srv: server for each block for example). We have thought the following solution: add a new tag inet-block: into the network object which describes the original block size. In this way it is possible to store in the same object entry both the information for route aggregates (inet-block:) and other data we need (like rev-srv:, contact people, etc). This is a example: inetnum: 193.204.160.0 - 193.204.161.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: GARR aut-sys: AS137 bdrygw-l: INFN-MIL INFN-CNAF rev-srv: decsrv.caspur.it rev-srv: dns.nis.garr.it rev-srv: matrm3.mat.uniroma3.it ...... ...... inetnum: 193.204.162.0 - 193.204.167.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: LOCAL ....... ....... Please let us know your opinion. The GARR-NIS Staff Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it

2 1

Re: 20402 routing entries
by Peter Lothberg 22 Apr '94

22 Apr '94

> Peter, > > >We are at the point where action has to be taken, either to get > >CIDR the "proper way", or by forced proxy aggregation at some > >places in the Internet. > > Let me suggest to pursue a combination of both. Folks > who are willing and able to cooperate should pursue the "proper way", > and the rest may be subject of proxy aggregation (which may be "forced"). > Yakov. Fine with me, but WHO does the pushing? People that already have all thedata and are registring routes like Merit? -Peter

9 14

RE: 20402 routing entries
by Tony Hain 21 Apr '94

21 Apr '94

Peter & Yakov, >>We are at the point where action has to be taken, either to get >>CIDR the "proper way", or by forced proxy aggregation at some >>places in the Internet. > >Let me suggest to pursue a combination of both. Folks >who are willing and able to cooperate should pursue the "proper way", >and the rest may be subject of proxy aggregation (which may be "forced"). You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony

8 11

Effect of CIDR?!
by Erik-Jan Bos 21 Apr '94

21 Apr '94

BGPD, from my historical data on the size of the routing table present in Amsterdam1.dante.net I created yet another picture. IMHO, we can see some CIDR effects now, but please continue to withdraw explicits :-). The graph is available both as a GIF picture as well as a postscript file. This picture is available using gopher to gopher.nic.surfnet.nl [192.87.46.3]. Please find it at: 2. SURFnet information/ 4. SURFnet FTP Archive/ 2. net-management/ 5. ip/ 5. nets.gif <Picture> or 6. nets.ps. I will generate these pictures on a regular basis for the period to come. __ Erik-Jan. P.S. Please be aware of the fact that the x-axis of the graph is a little weird. The numbers on the x-axis are sample points since January 1, 1994 in stead of the absolute date. Sorry for this.

1 0

CIDR state
by Erik-Jan Bos 20 Apr '94

20 Apr '94

BGPD, at the CIDRD meeting in Seattle I showed some statistics on the current state of CIDR Deployment. Just for your information, here are the stats again. Sorry to bother you with stats, anyhow, since more people are doing this, but it shows IMHO that we can do better :-). At the moment (at 16:00 hrs UTC+0200 today) there are 20274 routed in the Internet. These nets are announced by 340 Autonomous Systems. The are currently 154 CIDR routes, which are announced by 43 Autonomous Systems. This means that 297 Autonomous Systems are not announcing any CIDR route yet. However, 70 Autonomous Systems consists of 1 net only, which means that a possible 227 ASs could start to CIDRize. Futhermore, I have some historical data on the total number of routes in the Amsterdam1.dante.net router, from January, 1st on. I created a simple graph using this data. This picture is available using gopher to gopher.nic.surfnet.nl [192.87.46.3]. Go to: 2. SURFnet information/ 4. SURFnet FTP Archive/ 2. net-management/ 5. ip/ 5. nets.gif <Picture> FYI. __ Erik-Jan.

4 3

Re: BGP 4 (fwd)
by Dave Morton 19 Apr '94

19 Apr '94

>This has nothing to do with BGP at all, rather we fixed a bug in 9.21 that we >left alone in 9.1, and it triggered some weirdness in ANSs's setup (they are >playing games with netmasks and their nameserver host ended up being on an >'all zeros broadcast address' and when we cleaned up some of the directed >broadcast code in 9.21, it blew things up for them. > >This shouldn't affect anyone else. Well is sort of does (not the NS stuff) since AS517 don't use ANS's NS but Arnold would like to do BGP4/CIDR to ANS same as he's doing with AS1273 and this prevents him. Judging by Tony's stats there a good gain to be achieved here. Seems it'll just take a little longer that's all. Dave

2 1

BGP 4 (fwd)
by Arnold Nipper 19 Apr '94

19 Apr '94

Does anyone know more about this problem. Regards, Arnold Serpil Bayraktar wrote: > Message-Id: <199404190507.AA76544(a)knock.aa.ans.net> > To: nipper(a)xlink.net > Cc: vimal(a)ans.net, db3l(a)ans.net, sbb(a)noc.ans.net > Subject: BGP 4 > Date: Tue, 19 Apr 1994 05:07:13 UTC > From: Serpil Bayraktar <sbb(a)noc.ans.net> > > > I know this is getting very confusing, but.. we really need to > switch back to old version soon. Basically all our customers > connected to New York are having name service problems and it > would be wonderful if we could take care of this today. > Our NOC is going to get in touch with you around 8 AM your > time (or 07:00 GMT). If you can change your configuration > to let your router negotiate or do v3, we will reload our New > York router. If you want me to be on the phone with you during > these changes please let our NOC know, but basically as soon > as you modify your config file all it takes is to reload our > Cisco. > > Serpil > -- Arnold Nipper / email: nipper(a)xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany

4 3

Merit Routing Registry
by epg＠merit.edu 18 Apr '94

18 Apr '94

Merit is happy to announce the Merit Routing Registry. Whereas Merit designed and manages the PRDB (Policy Routing Data Base) for the NSFNET service, RIPE pioneered a policy routing registry for the European community. The RIPE Routing Registry is based on the document, RIPE-81. With RIPE's collaboration, Merit installed RIPE-81 software and then extended the policy descriptions in order to realize more complex policies. The Merit Routing Registry will be a companion registry to the RIPE Routing Registry and is intended to serve the community that is not served by RIPE. This is a new service and we consider ourselves still in the beta phase. Registrations may be basic policy descriptions defined in RIPE-81 or complex routing policy descriptions defined in the Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu. The Extended Policy Syntax document may be found on rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for using the MeritRR can be found on rrdb.merit.edu:pub/meritrr. Merit and RIPE anticipate that the combined registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to allow the two registries to appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. For more information, please respond to rradmin(a)rrdb.merit.edu. Elise Gerich, Merit Network, Inc. Daniel Karrenberg, RIPE NCC

1 0

Re: 20402 routing entries
by Steven J. Richardson 18 Apr '94

18 Apr '94

>Date: Fri, 15 Apr 1994 14:56:24 -0700 >From: Paul Traina <pst(a)cisco.com> >Status: RO > >> To: Paul Traina <pst(a)cisco.com> >> Cc: Peter Lothberg <roll(a)stupi.se>, David R Conrad <davidc(a)terminus.iij.ad.jp>, >> Vadim Antonov <avg(a)sprint.net>, ALH(a)eagle.es.net, bgpd(a)merit.edu, >> eowg(a)fnc.gov, routing-wg(a)ripe.net, yakov(a)watson.ibm.com >> Subject: Re: 20402 routing entries >> Date: Fri, 15 Apr 94 13:15:20 -0700 >> From: "Milo S. Medin" (NASA ARC NSI Office) <medin(a)nsipo.nasa.gov> >> >> >> That's all fine and good, however it has little to do with the issue >> of reducing the number of routes. Your worst case of 500 staying >> 500 is more likely due to problems in getting BGP4 deployed than any >> AUP issue. > >> You hurt your credibility when you try and blame all the world's problems >> on AUP's. >My point is the same one that Andrew was making -- right now, he's got >customers randomly scatters as AUP and non-AUP. For every non-AUP net, >he's got, we end up poking serious holes into CIDR efficiency. All it takes >is, say, 30 randomly scattered holes to make a complete mess of the 500 to 2 argument. Excuse me, but it seems as though 500 -> 31 (30 more-specific routes + 1 CIDR block) is still a significant savings. >Best regards, > >Paul Steve Richardson/Merit

1 0

Re: 20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

> Not really. If you split the block into an AUP compatible group and a > non-AUP compatible group, then you send in 2 routes in some cases instead > of one. Thus you still save a large amount of route table space. > > Thanks, > Milo Milo, Who's AUP? US FED? If we allow one AUP per country we need 200+, and then we need tosplit in smaller blocks to find the smallest block of networks that meets that.. How about everyone implement their own AUP on their side, using the information in the routing registry (wich may go down to host policies). Static route packets to people you don't want to talk to into a black-whole-gw. -Peter

3 4

Re: 20402 routing entries
by Vince Fuller 15 Apr '94

15 Apr '94

I don't know how you can implement AUP in the network in a reasonable way using the approach you propose. You move a centralized management problem into a much more distributed and harder to effect approach. Centralized? Where is the problem centralized? Unfortunately, it the Internet simply does not have a "center" any more, not in a global sense. I still don't understand the problem. You split your block into a non-AUP and AUP block, and advertise the ranges appropriately. This is consistent with the existing model of how routes are advertised and approved, and requires no changes in the system. We use the same techniques we are doing today. If we reduce specific advertisements from 500 to 2, instead of 500 to 1, we still win. Unfortunately, given the way the US agency AUP's are written, this is almost impossible. For starters, the AUP's talk about content of traffic, which has very little relationship to network numbers. Tell me, Milo, should I consider HP (including HP Labs) and Xerox (including PARC) as research or commercial? And even implementing (the rather lame) approximation by destination network number is very difficult in a CIDR world - it requires ESP on the part of a network providers to determine if a customer is and will always be AUP- compliant when assigning their network numbers. And, of course, this all has to be done at network number assignment time and is effectively cast in stone if the site doesn't want to renumber later if they change AUP's. We at BARRNet have tried very hard to do number allocations along AUP lines, and it has not been either easy or perfect. Saying: If we reduce specific advertisements from 500 to 2, instead of 500 to 1, we still win. is a nice idea, but it doesn't take into consideration those blocks which have been allocated in a mix-and-match way to both AUP-conscious and AUP-ignorant sites. And, of course, whose AUP are we talking about? NSF's? NSI's? What about places outside of the U.S. that may have their own AUP's? Does every provider in the world have to allocate a separate sub-block for every AUP in the world? Until we have something like SDRP or until the politicians are taught what is is not implementatble, NSFNET-like AUP's are going to be problematic. --Vince

1 0

Re: 20402 routing entries
by Tony Hain 15 Apr '94

15 Apr '94

>I don't see any problem with doing proxy aggregation with >notification only when the aggregatee is unwilling or >unable to cooperate. > >What will be much more destabilizing than doing proxy >aggregation will be the collapse of non-64Mbyte routers >as the routing table continues to grow. > >Proxy aggregation may lead to some suboptimal routing, and >to a practical inability to do some forms of policy-based >routing, but those are minor problems compared to ignoring >people who won't or can't aggregate on their own. > >Lastly, I think that anyone who insists that everyone else >ignore a serious technical crisis only in order to satisfy their >political policy requirements is more than a little selfish. > > Sean. My point was not that proxy aggrigation is wrong, just that it can't be done without consent. There will be aggrigates which have limited advertisment range, and forcing them into a larger aggrigate will open them to exposure they are explicitly required to avoid. Making the simple-minded statement that suboptimal routing is MINOR shows a lack of understading of the true nature of the underlying circuits. If all circuits were equal capacity and capable of carrying the entire load on their own it would be a minor problem, but none of them are, or are they ever likely to be. I don't think anyone is ignoring the seriousness of the current problems. As some of you will recall, a long time ago I was not optimistic about rate of CIDR deployment and thought we should delay the block allocation of Class C's. At that time I was accused of ignoring the serious problem of depletion of Class B's. We are all trying to make this enterprise work and each of us has to do the best we can with the tools available. However that does not extend to allowing anyone to force its operation model on anyone else. Tony

1 0

Re: 20402 routing entries
by Tony Bates 15 Apr '94

15 Apr '94

asp(a)uunet.uu.net (Andrew Partan) writes: * Folks: There are routers out there that have *already* died due to too * many routes. * * CIDRize your nets. * * Thanks, * --asp(a)uunet.uu.net (Andrew Partan) Andrew, I'm sorry but it is all well and good to say this, but if I look the amount of clasful routes AS701 is injecting into the Internet it comes out at ~1200 routes (~6% of the total routing table) and then the aggregates from AS701 I get the following. [mature-tony-77] grep AS701 Specific.15Apr94 N 198.84.4.0/22 AS701 198.84.4.0 198.84.7.0 4 0 I see a big saving of 3 routes so far. I do not mean this as a personal gripe at AS701 but the big gains will undoubtedly come from the big ASes. So perhpas we need to chase these down first. Just to be fair here is the status of the "big 10" ASes and their classful (i.e in the tables now) and classles status (in the tables now) as of last night. ASnum Classful Aggs Routes Description potentially saved* AS701 1204 1 3 ALTERNET-AS AS174 1134 0 0 NYSERNET-AS AS372 977 0 0 NSN-AMES-AS AS1717 747 0 0 RENATER AS19 632 0 0 CSS-DOMAIN AS786 590 0 0 The JANET IP Service AS2551 571 3 374 NETCOM-AS AS560 569 0 0 NEARNET-EXT-AS AS1225 538 0 0 CICNET3-AS AS200 525 3 1316 BARRNET-AS * this is done by looking at the aggregates and taking out the more specifics. However, this is the potential routes saved as some of these aggs (i.e. the AS200) would probably not have been fully advertised in the classful world. I hope my point is clear. This top 10 represents about a 1/3 of all the routes we keep worrying about. End story. --Tony.

2 1

Re: 20402 routing entries
by Vince Fuller 15 Apr '94

15 Apr '94

You can't do proxy aggrigation without consent!!! You WILL create policy violations as well as destablizing global routing. Forget any concept of 'forced proxy aggregation'!!!! Tony, yell all you like. How will you stop someone? As we mentioned at IETF, folks will have to do proxy aggregation unless there is substantial aggregation happening just so that they can survive. Well, I suppose Tony H. could offer to buy us all 64Mb routers if he's so concerned about us creating policy problems for him... As for destabilizing global routing - we're going to have plenty of opportunity to experience that if we *don't* deploy aggregation; routers which crash and reboot every 5 minutes because they are out of memory do simply delightful things to routing stability. Question to the MERIT folks: have you had any luck (and have you tried) using the ASxxx(a)MERIT.EDU mailing lists to try and get in touch with those non-BGP4 sites which might not be on the BGPD or Regional Techs mailing list? I'm likely asking the obvious, but... --Vince

3 2

20402 routing entries
by yakov＠watson.ibm.com 15 Apr '94

15 Apr '94

Ref: Your note of Thu, 14 Apr 1994 18:10:14 -0400 Vadim, >Also, it won't be a bad idea to *stop* processing NACRs for >blocks of consequtive networks and tell people to do aggregation >instead. I'd like to strongly support this suggestion. This would help to encourage sites to either (a) CIDRized themselves, or (b) arrange for some proxy aggregation. What would be the problems with putting this suggestion in place ? Yakov.

1 0

Re: 20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

> How does ICM handle consecutive networks that it receives from > its customers? > > --Elise > > > I would like Merit to start processing CIDR NACRs on > > priority basis and with less formalities. Also, > > it won't be a bad idea to *stop* processing NACRs for > > blocks of consequtive networks and tell people to do > > aggregation instead. > > > > --vadim If ICM for example aggregated things down to 'provider', it would cut a lot of people from being able to access AS690, as it requires each induvidual 'network owner' to register by themself. -Peter

1 0

RE: 20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

> Peter & Yakov, > > >>We are at the point where action has to be taken, either to get > >>CIDR the "proper way", or by forced proxy aggregation at some > >>places in the Internet. > > > >Let me suggest to pursue a combination of both. Folks > >who are willing and able to cooperate should pursue the "proper way", > >and the rest may be subject of proxy aggregation (which may be "forced"). > > You can't do proxy aggrigation without consent!!! You WILL create policy > violations as well as destablizing global routing. Tony, It might be the case that it is 'to expensive' to make the global internet to carry the costs of 'private policies'. I don't se any problems of implementing policy inside the AS that has the policy, even if things are announced as 'provider aggregates', just do packet filtering opn YOUR side. > Forget any concept of 'forced proxy aggregation'!!!! What are the options? -Peter

1 0

Re: 20402 routing entries
by Erik-Jan Bos 15 Apr '94

15 Apr '94

Peter, > If ICM for example aggregated things down to 'provider', it would cut > a lot of people from being able to access AS690, as it requires each > induvidual 'network owner' to register by themself. I don't understand this, not do I believe this to be the case. SURFnet announces for example 192.87.0.0/16 and this is (of course) provider aggregation. *We* registered the aggregate at Merit. Individual network "owner" were only informed of this by SURFnet. __ Erik-Jan.

2 1

Re: Corrupted data
by Tony Bates 15 Apr '94

15 Apr '94

Following on from the mail yesterday about errors in aut-num objects in the database. Please find a new set of database errors on ftp.ripe.net:ripe/dbase/errors/* -rw-r--r-- 1 tony dbase 0 Apr 15 11:59 as-macro.errors -rw-r--r-- 1 tony dbase 5319 Apr 15 11:55 aut-num.errors -rw-r--r-- 1 tony dbase 0 Apr 15 11:58 bdry-gw.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 community.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:01 dom-prefix.errors -rw-r--r-- 1 tony dbase 103796 Apr 15 12:06 domain.errors -rw-r--r-- 1 tony dbase 58285 Apr 15 12:46 inetnum.errors -rw-r--r-- 1 tony dbase 320852 Apr 15 12:38 person.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 rout-pr.errors As you can see person has the most errors. Please can all (especialy local-irs take a look at these files and correct where possible. Here's a summary of the amount of errors over what is in the database. Object Number in DB Number in Error aut-num 322 11 domain 3222 354 inetnum 16107 176 person 16366 1072 Please look at these files. Remember many of the errors are where mandatoy fields are not in the object rather than syntax errors. The next round will be to start chasing people individually. Thanks, --Tony.

1 0

Re: 20402 routing entries
by Vadim Antonov 15 Apr '94

15 Apr '94

>We can aggregate all of >202.32/16, but we either have to lie to the NSF and claim all >customers in that block are AUP compliant or all the customers in that >block can't get to the NSFnet. Please note that networks shouldn't be "AUP compliant" to be routed thru NSFNET, they only shouldn't send non-AUP traffic across NSFNET. Since they don't do that now there are good chances they won't do that in the future. NSFNET AUP does not explicitly state what kind of enforcement users should use (if any) and i do not see any sense in assuming that network number filtering is mandatory to be AUP-compliant. >Therefore, we have to break 202.32/16 >into pieces and some service provider up the wire may proxy aggregate >for us. Don't do that! It will hurt many service providers most of which don't have anything to do with NSFNET AUP. Since your commercial traffic won't go to NSFNET anyway you don't run any risk of violating AUP. [As a side note -- here comes another technically unenforceable policy. AUP and Die.]. >Or have I missed something obvious? Yes. Enforcing NSFNET's policy with some (small) probability can prevent abuse of US taxpayers' money; not aggregating will CERTAINLY hurt the whole Internet (not excluding NSFNET) -- most of which wasn't built on US taxpayers' money. --vadim

3 3

Re: 20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

> When I checked today I noticed that there are about 1,200 more > specific routes that are covered by aggregates (unless my perl code is > broken). I suspect most of these could be withdrawn but it may be > that providers are still waiting to see if any bad things happen. Yeeiks, if they don't withdraw, BIG-bad things will hapen, if they take out the specific routes, small-bad things might hapen. Let's try to gently ask the people who are sending both aggregates and specific routes, to pull their specific routes NOW. -Peter

1 0

Re: 20402 routing entries
by Vadim Antonov 15 Apr '94

15 Apr '94

I would like Merit to start processing CIDR NACRs on priority basis and with less formalities. Also, it won't be a bad idea to *stop* processing NACRs for blocks of consequtive networks and tell people to do aggregation instead. --vadim

2 1

20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

Folks, We are at the point where action has to be taken, either to get CIDR the 'proper way' or by forced proxy aggregation at some places in the Internet. Are we all really doing our best to cut down the number of routing entries? -Peter

2 1

20402 routing entries
by yakov＠watson.ibm.com 14 Apr '94

14 Apr '94

Ref: Your note of Thu, 14 Apr 94 23:49:40 MET DST Peter, >We are at the point where action has to be taken, either to get >CIDR the "proper way", or by forced proxy aggregation at some >places in the Internet. Let me suggest to pursue a combination of both. Folks who are willing and able to cooperate should pursue the "proper way", and the rest may be subject of proxy aggregation (which may be "forced"). Yakov.

1 0

Re: Corrupted data
by Tony Bates 14 Apr '94

14 Apr '94

Laurent Joncheray <lpj(a)merit.edu> writes: * Could you clean up these data? Some of the policies are not RIPE-81 * compliant. Thanks. * Laurent, while this is interesting it is not very helpful as the users have no idea what objects these errors refer to. Here is some more useful output (at the end) from our DB checker. One caveat - I also note a bug in my parsing of default which I'l fix in a minute. Also, "*am" is certainly valid. You need to update your configuration probably. By the way we also post out errors every now and again anyway, we need to do this more regulalrly. The problem is these got in before we had fully implemented stronger syntax checking barring the bug of course. Tony * alc: reading file "/f/rrdb/dbase-beta/data/ripe.db" (RIPE-DB)... * * ERROR (201339): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ao: AS1853" * ERROR (201348): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ai: AS1800 ANY" * ERROR (201349): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ai: AS1880 ANY" * ERROR (201368): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1755 100 AS1755 AS690" * ERROR (201369): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1883 200 AS1755 AS690" * ERROR (201382): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1880 100 AS1755 AS690" * ERROR (201395): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1880 100 AS1755 AS690" * ERROR (201396): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1883 200 AS1755 AS690" * ERROR (201414): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1755 100 AS1755 AS690" * ERROR (203306): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ao: AS1755 AND AND NOT (AS1729)" * ERROR (205269): object *am undefined * alc: Printing stat for db RIPE-DB * alc: ipblock: 16075 objects, 38766 count * alc: autsys: 321 objects, 321 count * aut-num: AS1271 descr: DE-NIC unused admin-c: Ruediger Volk changed: rv(a)Informatik.Uni-Dortmund.DE 930310 source: RIPE *ERROR*: mandatory field "tech-c" missing aut-num: AS1752 descr: BT main internal data network guardian: N.Titley(a)axion.bt.co.uk admin-c: Nigel Titley (NT13) tech-c: Nigel Titley (NT13 changed: N.Titley(a)axion.bt.co.uk 930520 source: RIPE *ERROR*: syntax error in "tech-c" *ERROR*: syntax error in "admin-c" aut-num: AS1759 descr: The DataNet IP Service descr: Fi as-in: AS544 50 ANY as-in: AS701 100 ANY as-in: AS1729 100 ANY as-in: AS1732 100 NOT AS544 as-in: AS1755 100 ANY as-out: AS544 ANY as-out: AS701 NOT AS1729 AS1741 AS1755 as-out: AS1729 NOT AS701 AS1741 AS1755 as-out: AS1732 ANY as-out: AS1755 NOT AS701 AS1729 AS1741 guardian: netman(a)noc.datanet.tele.fi admin-c: Seppo Noppari tech-c: netman(a)noc.datanet.tele.fi tech-c: Tapio Aaltio changed: jok(a)noc.datanet.tele.fi 930603 source: RIPE *ERROR*: syntax error in "tech-c" aut-num: AS1853 descr: ACOnet Backbone descr: AT as-out: AS1853 guardian: net-admin(a)cc.univie.ac.at admin-c: Walter Kunft tech-c: Ewald Jenisch changed: Ewald.Jenisch(a)cc.univie.ac.at 930403 source: RIPE *ERROR*: syntax error in "as-out: AS1853" - no routing policy expression given aut-num: AS1878 descr: Peter & Paul's test network as-in: AS1800 ANY as-in: AS1880 ANY as-out: AS1800 ANY as-out: AS1880 ANY guardian: roll(a)stupi.se admin-c: Peter Lothberg tech-c: Peter Lothberg changed: roll(a)stupi.se 930819 source: RIPE *ERROR*: syntax error in "as-in: AS1800 ANY" - cost ANY must be a positive integer *ERROR*: syntax error in "as-in: AS1880 ANY" - cost ANY must be a positive integer aut-num: AS1880 descr: Stupi, house man's policy as-in: AS1755 100 AS1755 AS1653 AS1257 AS1883 as-in: AS1883 200 AS1755 AS1653 AS1257 AS1883 as-in: AS1881 100 AS1881 as-in: AS1882 100 AS1882 as-out: AS1755 AS1880 AS1881 AS1882 AS1883 as-out: AS1883 ANY as-out: AS1881 ANY as-out: AS1882 ANY default: AS1755 100 AS1755 AS690 default: AS1883 200 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg tech-c: Peter Lothberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1881 descr: Stupi, toaster network as-in: AS1880 100 ANY as-in: AS1882 100 ANY as-out: AS1800 ANY as-out: AS1802 ANY default: AS1880 100 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg tech-c: Peter Lothberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1882 descr: Stupi, house woman's policy as-in: AS1883 200 AS1755 AS1653 AS1257 AS1883 AS1880 AS1881 as-in: AS1880 100 AS1755 AS1653 AS1257 AS1883 AS1880 AS1881 as-out: AS1883 ANY as-out: AS1880 ANY default: AS1880 100 AS1755 AS690 default: AS1883 200 AS1755 AS690 guardian: Ulla Sandberg admin-c: Ulla Sandberg tech-c: Ulla Sandberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1883 descr: Stupi, backboone test network as-in: AS1755 100 ANY as-in: AS1755 50 AS1880 AS1881 AS1882 as-in: AS1653 100 ANY as-in: AS1880 100 AS1880 AS1881 AS1882 as-in: AS1882 300 AS1880 AS1881 AS882 as-out: AS1755 AS1880 AS1881 AS1882 AS1883 AS1653 as-out: AS1653 ANY as-out: AS1880 ANY as-out: AS1882 ANY default: AS1755 100 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg admin-c: Bjorn Carlsson tech-c: Peter Lothberg tech-c: Bjorn Carlsson changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS2047 descr: KFKI-RMKI Autonomous system as-in: AS1955 100 AS1955 as-in: AS2547 100 AS2547 as-in: AS2012 100 AS2012 as-in: AS513 100 DEFAULT as-out: AS1955 AS2047 as-out: AS2547 AS2047 as-out: AS2012 AS2047 as-out: AS513 AS2047 default: AS513 100 guardian: giese(a)rmki.kfki.hu admin-c: Piroska Giese tech-c: Piroska Giese changed: giese(a)rmki.kfki.hu 930618 source: RIPE *ERROR*: syntax error in "as-in: AS513 100 DEFAULT" - DEFAULT is not a routing policy KEYWORD aut-num: AS544 descr: The DataNet IP Service descr: Fi as-in: AS1732 100 NOT AS1759 as-in: AS1741 50 NOT AS1759 AS790 as-in: AS1759 100 ANY as-out: AS1732 ANY as-out: AS1741 NOT AS701 AS1729 AS1755 as-out: AS1759 NOT AS1755 guardian: netman(a)noc.datanet.tele.fi admin-c: Seppo Noppari tech-c: DataNet NOC tech-c: Tapio Aaltio changed: jok(a)noc.datanet.tele.fi 030194 source: RIPE *ERROR*: date part of "changed" is not a valid YYMMDD value

1 0

CIDR state
by yakov＠watson.ibm.com 13 Apr '94

13 Apr '94

Ref: Your note of Wed, 13 Apr 1994 16:31:04 +0200 Erik-Jan, >... a possible 227 ASs could start to CIDRize. I doubt that the administrators of all these ASs are on the BGPD mailing list. Therefore, we need to assume that administrators of the Network Service Providers (e.g. regional networks) that connect to these sites to the Internet have to work with these ASs directly. I also think that requiring in the near term all these 227 ASs to perform site-level aggregation by themselves is not very practical (for one thing this would require all these ASs to move to BGP-4). That seems to leave us with only one feasible alternatives -- proxy aggregation, where a CIDR-capable provider generates aggregates on behalf of its clients that are not CIDR-capable. As a way of trying to identify "easy" target first, let me suggest that each provider who is on the BGPD mailing should identify pure stub sites served by the provider. Once identified, the provider can perform proxy aggregation for such a site with no negative impact. Yakov.

1 0

Re: Supernet 192.216
by Steven J. Richardson 13 Apr '94

13 Apr '94

This is great news from Vince and Erik-Jan; let's keep the CIDR use rolling. :-) Steve Richardson/Merit

1 0

Re: Supernet 192.216
by Erik-Jan Bos 12 Apr '94

12 Apr '94

Vince, > Effective today, we have ceased sending most of the explicit routes for the > supernet 192.216/16 to the CIX and have requested that they be removed from > the NSFNET PRDB. The single exception to this change is 192.216.61, which is > multi-homed. > > Assuming no problems are found with 192.216/16, we will next remove all > singly-homed explicit routes in the blocks 198.31/16 and 198.92/14. > > According to the MERIT PRDB, these changes will removed approximately 530 > class-C network routes. According to a recent routing table dump, this will > translate into approximately 210 active routing table entries. Furthermore, > it should cause BARRNet to cease aggrevating the global routing table problem > as the vast majority of our new subscribers are assigned network numbers from > one of our CIDR blocks. > > Anybody else ready to take the plunge? Sure. Today, SURFnet ceased sending any of the explicits in the two large SURFnet CIDR blocks: - 145.0.0.0/9 - 192.87.0.0/16 Some explicits in these blocks remain since the sites using these nets are connected to another provider (but long matches take precedence so no routing problem occurs), but these are not announced by SURFnet (maybe we should try to get those numbers back one day...). This step means that around 60 networks are gone from the routing tables (okay, SURFnet has some smaller numbers than BARRnet :-), but everything helps, IMHO). SURFnet is issuing network numbers from the SURFnet CIDR blocks for customers that are new in the Internet game. SURFnet also "asks gently" from sites that already obtained address space some time ago to renumber to the SURFnet CIDR blocks. Up till now I have been effective in all case except one, since I play this game. This is really worth trying. Who's next? __ Erik-Jan.

1 0

Uninett (AS224) withdraws routes
by Havard Eidnes 08 Apr '94

08 Apr '94

Hi, we have now started announcing the aggregates 129.240.0.0/15 158.36.0.0/14 193.156.0.0/15 and we have withdrawn the more specific routes covered by these aggregates. By doing this we have reduced the number of routing announcements we send to the Internet with approximately 50%, though in real numbers the contribution is small. We know that a number (hopefully small, I'm aware of two...) of european R&D networks will get inoptimal paths for destinations covered by these prefixes, but I still pray that I'll not have to back out this configuration on monday morning... Today's number of routes on the Internet appears to be 20201 (or thereabout). - Havard

1 0