On Sat, May 26, 2001 at 09:54:04PM +1200, Chris Wedgwood wrote:

On Sat, May 26, 2001 at 06:14:38PM +1000, Geoff Huston wrote:

If you have a cisco router, and an expect script, or similar, that collects the output of "show ip bgp", then an output analyzer is available at www.telstra.net/ops/bgp/bgp-parse.c.txt (You'll need gnuplot and whois). The program generates an html report - as per www.telstra.net/ops/bgp

Ironically 1221 is the worst offender out there for lack of aggregation and has been for some time if you look at the Bates reports :)

Not this thread, again. There is a requirement for some networks to propagate edge policy through long-prefix advertisements. There are few reliable alternatives mechanisms known. If you know a better way, please share. http://www.merit.edu/~ahuja/ptomaine-bof/ahuja-ietf-ptomaine/index.htm http://www.merit.edu/~ahuja/geoff-ietf-ptomaine.ppt http://www.ietf.org/html.charters/multi6-charter.html http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-contro... Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Sun, May 27, 2001 at 01:43:03AM +1200, Chris Wedgwood wrote:

Not this thread, again.

Again?

It's been drummed through many times on about every *og apart from this one :)

I just checked, it's not really that bad anymore, but I have to wonder about some of the stuff I see there. for some of these, its a little hard to always figure out who is in error as not all of these records are in the APNIC-DB or RADDB. Any suggestions on where else I might look?

The IRR is not universally thought to be useful, and there are lots of people who don't update it for reasons other than laziness. The delegation info at the RIRs is also only as good as people keep it, for delegations made below RIR level.

There is a requirement for some networks to propagate edge policy through long-prefix advertisements. There are few reliable alternatives mechanisms known. If you know a better way, please share.

Donning my best asbestos suit and bow-tie...

I assume we are talking about aggregation by origin AS, not transit or peer-intermediary? Aggregation of adjacent prefixes who's attributes are otherwise completely identical.

Nope -- I'm talking about deliberately splitting aggregates so that the component advertisements can be made with different attributes, hence buying cheap and nasty inter-multi-AS traffing engineering.

External to the AS I can't see why you would want or need to know about these longer prefixes (edge policy or otherwise). The draft (which you wrote) states:

There is a requirement for some multi-homed sites to influence the path selected by autonomous systems beyond those that are immediately adjacent.

If all attributes are equal external to the AS (to most or all external ASs), then how does this help?

They're not -- the attributes are different.

A quick cursory view on route-views shows that there may indeed be benefits from aggregating from 1221 (and also that they are bleeding RFC1918 stuff to the route-server). I won't pretend I've check it thoroughly recently, I assume those who claim to aren't lying to me :)

Heh :) I hadn't seen the rfc1918 leaks, which do not sound good.

I'm not saying Telstra doesn't have a need for this huge lack of aggregation, but it does strike be as somewhat unusual that they are top of the list --- especially when _much_ larger networks are further down.

Telstra is interesting in that it is isolated from the US by a relatively low number of physical routes, it uses a number of transit ASes, and it shifts a lot of traffic by virtue of the dominant position it enjoys in Australia. Suppose there was a substantial source of traffic elsewhere in the network interesting to Telstra customers that Telstra didn't peer with directly; you might see the de-aggregation as an attempt to draw traffic from that remote AS evenly back to 1221 over different transit ASes -- traffic to an aggregate would most probably follow a single route, leaving some paths highly congested and others empty. We played these same games at clear while we were multi-homed between 6453 and 3561. They are ugly, but if you have limited, expensive and diverse connectivity to the US, and your traffic requirements change faster than your IPLC contracts expire, you need *something*.

Getting back to the NZ situation, NZ is terribly fragmented in some places. It seems a common trend that people move providers and expect they can take the address space with them indefinitely. Renumbering isn't necessarily difficult or painful for most people, if it is, you are doing something wrong.

We had a conversation about this back when Telecom announced that they wanted all non-customers to renumber out of "their" UoW /16s. The loose consensus we had then was to break the /16s down into /19s, and to allocate each /19 to the provider who happened to advertise the most holes at some arbitrary point in time. That had the potential to reduce the bloat significantly; the number of /19s plus /24s was way less than the number of /16s plus /24s, and the difference would be greater now, I am guessing, if what people are telling me about market share is correct. Of course, nothing much happened as a result of this, except that Telecom stopped sending letters to clear customers telling to renumber, and I stopped waving my arms in the air and shouting :)

If anybody is interested, I'm happy to figure out and post a list of advertisements and aggregatable savings and advertisement densities[1] against known New Zealand AS. I had code to do this (partially, it didn't really consider all paths and attributes, but manual inspection of the worst offended seems to indicate everything is the same) and Geoff's code looks interesting, so its a good excuse to play with that.

Of course, to do this properly, you really need to get feeds from as many ASs as possible... so I wonder if you can assist Joe?

Sure.

(I just need you to run a pre-supplied binary as root, it will do the rest).

Hur hur :) Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

I'll just take up one comment to clarify what is going on At 5/26/01 11:43 PM, Chris Wedgwood wrote:

A quick cursory view on route-views shows that there may indeed be benefits from aggregating from 1221 (and also that they are bleeding RFC1918 stuff to the route-server). I won't pretend I've check it thoroughly recently, I assume those who claim to aren't lying to me :)

One of the views AS1221 sends to route-views is an _internal_ view of AS1221, treating AS6447 as a member of a confederation with AS1221 rather than as an external relationship - this implies that the information being sent from this view includes a whole set of internal routes (about 12,000) which are not advertised to external BGP peers. The role of route-views is one of a single repository of a set of views of the network from different persectives - there is no desire to 'sanitize' route-views to take various forms of filtered information, nor are there any traffic engineering filters applied to the feed as there is no data traffic flowing as a consequence of this route exchange. The utility of route-views as a research tool relies on the ability to take a collection of unfiltered internal views of the Internet from a number of perspectives. I'm not sure that the implied criticism that the routes being fed are internal routes is a valid one. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog