- routing-wg - mailman.ripe.net

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