- routing-wg - mailman.ripe.net

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