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

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