- routing-wg - mailman.ripe.net

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