On Sat, 9 Jun 2001, Randy Bush wrote:

...

There are lots of reasons to have some diverse /22 announcements in your network for example.

but if you are not paying me, what reasons are there for me to spend my resources (route bloat) so you can engineer your traffic?

The fact that your other customers are paying you to reach everyone on the internet? I agree the routing table is bloated (though I disagree that 100k should be a serious strain on a router, the blame lies with the vendors there), but there is no reason you need to lose connectivity to anyone in the process of filtering. It would be interesting if you could discard more specific routes with the same attributes as an existing shorter prefix. The problem is if you lose the shorter announcement you don't have any way to get the more specifics back. Perhaps it would be possible to keep a low-memory record of the more specifics which have been removed and the shorter which replaced it. At this point you're probably just shifting the resources used away from memory and into CPU, giving you slower convergance times. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

On Sat, 9 Jun 2001, Randy Bush wrote:

...

...

...

There are lots of reasons to have some diverse /22 announcements in your network for example. but if you are not paying me, what reasons are there for me to spend my resources (route bloat) so you can engineer your traffic? The fact that your other customers are paying you to reach everyone on the internet?

red herring alert! the point is not reachability. the aggregate is still available. see bellovin's phoenix presentation.

Assuming there is an aggregate. Unless you know for certain that there is one, you run the risk of making some addresses unreachable. As an extension of something I mentioned in a previous message, perhaps someone will be so kind as to play devils advocate and tell me why this wouldn't work. Automatically aggregate more specifics with attributes matching a shorter prefix at your network borders, and only pass the aggregates to the rest of your network via IBGP. The EBGP speaking router which receives the more specifics would keep a low memory record of them, and in the event that the aggregate route was withdrawn the more specifics would be advertised to the IBGP peers. In the event that an aggregate route is announced, any already announced more specifics would be withdrawn. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

The link on the NANOG web site points to the wrong presentation. Perhaps you would be so kind as to forward me a copy? jas At 02:37 PM 6/9/01 -0700, Randy Bush wrote:

...

...

red herring alert! the point is not reachability. the aggregate is still available. see bellovin's phoenix presentation. Assuming there is an aggregate.

see bellovin's phoenix presentation

randy

Your customers are paying for Internet connectivity. If they're unable to reach the sites they desire as a result of your intention actions (filtering announcements), why should they continue to pay you? While I fully support and expect route aggregation whenever possible, it is unreasonable to believe that everything fits in nice pretty packages. If you're unwilling to accept diverse /22 announcements without payment, why should we not expect the same for the /24's you're announcing? jas At 11:56 AM 6/9/01 -0700, Randy Bush wrote:

...

There are lots of reasons to have some diverse /22 announcements in your network for example.

but if you are not paying me, what reasons are there for me to spend my resources (route bloat) so you can engineer your traffic?

randy

At 6/10/01 04:56 AM, Randy Bush wrote:

...

There are lots of reasons to have some diverse /22 announcements in your network for example.

but if you are not paying me, what reasons are there for me to spend my resources (route bloat) so you can engineer your traffic?

none. Now tell me how to promulgate my TE-triggering routing advertisements precisely to the edge of my payment boundary (i.e. my upstreams, and their upstreams, and so on recursively along the upstream relationships) and no further, using today's BGP?

At 6/10/01 02:05 PM, Randy Bush wrote:

...

...

but if you are not paying me, what reasons are there for me to spend my resources (route bloat) so you can engineer your traffic? none.

well, we agree so far :-)

...

Now tell me how to promulgate my TE-triggering routing advertisements precisely to the edge of my payment boundary (i.e. my upstreams, and their upstreams, and so on recursively along the upstream relationships) and no further, using today's BGP?

but why should i pay the costs because the tool was not designed to do what you want done?

Taken together, the pair of statements above is a pretty good illustration of the issues at play in the inter-provider space today. Wanting to optimize traffic loads over multiple connections is not unreasonable as an objective, but having the entire world see your resultant advertisements is not the best of outcomes.

i will happily work on tool design with you [0]. but, in the meantime, why should i have to pay a penalty for your odd business choices?

If you are on my upstream chain, then I am accompanying my routing requirements with money. Whatever penalty you may incur I pay for with my upstream payment. Where your statement holds is once you are not seeing money from me (i.e. you are not an upstream paid directly or indirectly by me), in which case what would help us all is a recognised [*] community attribute which says "advertise this prefix together with this attribute only to your upstreams" [*] 'well if you don't recognise it then I am less interested in having you as my upstream than if you do.

( casual readers should note that 'you' and 'i' are abstract terms, and that geoff usually claims to be more of a capitalist than i :-)

indeed :-)

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of David Schwartz Sent: Sunday, June 10, 2001 4:24 AM To: Geoff Huston Cc: nanog@nanog.org Subject: RE: /24s run amuck again

If you are on my upstream chain, then I am accompanying my routing requirements with money. Whatever penalty you may incur I pay for with my upstream payment. Where your statement holds is once you are not seeing money from me (i.e. you are not an upstream paid directly or indirectly by me), in which case what would help us all is a recognised [*] community attribute which says "advertise this prefix together with this attribute only to your upstreams"

Actually, in all cases the requirements are accompanied by money. Even in settlement-free peering, if the two sides didn't feel they were getting paid to do whatever they are doing, they should sever the peering relationship and charge. You are getting that route from somewhere and if you aren't paid by someone to do so with value greater than its cost to you, you should stop accepting the route. The money flows along the same paths the routes do. Every time a route goes from router 1 to router 2, there is some agreement that allows it to do so. If the route exchange costs you more than you're getting out of it, renegotiate that connection. One thing that might help is if companies that work out peering that isn't free start to charge based, at least partly, upon aggregation. If extra routes really cost you, charge for them where they enter your network. Heck, charge per route if you want. This should work well for small to mid-sized companies that generally have trouble getting settlement free peering. I doubt you could pressure UUNet, Sprint, or C&W in this way. DS ---- I would say that the far simpler method is to filter. If the filters cause harm to a settlement-free peer, then that settlement-free peer should renegotiate the peering with the filtering-peer to encourage them to accept the route table bloat. If the settlement-free peer that is advertising the more specific routes isn't interested in doing that, then the customer isn't paying their upstream enough to be worth screwing with a system that is satisfactory to their business case. After years on the net, I think this is my general rule for the way things work. If something bothers you, you do something to mitigate it. If you tell people what you've done, and they think its a good idea, they do it to. If enough people do something about it, then usually whoever was doing the thing that was bothersome has an incentive to stop it. If the bothersome thing doesn't stop, you've already mitigated it, and you can scream till you are blue in the face, and only make a small dent in the flow of things. Case in point: RBL - Those that spam bothers a lot use it, and it helps. Those who get put on it (because the combined power of the RBL is significant to the affected parties) change their behavior or don't. Either way, RBL recipients receive less bothersome behavior. ORBS (when it was running) was used by lots of people. It bothered a lot of other people. They started filtering ORBS. ORBS only affected people who subscribed to it, and I am sure Abovenet could say [ORBS] didn't negatively impact their business case. Neither side achieved a whole lot of critical mass to sweep over the net. (Not saying RBL has either). ORBS subscribers saw less bothersome behavior. Verio and other networks that filter have decided that route table bloat is an issue for their operations. Networks that peer with [Filtering Networks] have decided that this doesn't really pose an issue to their operations. Some customers of those Networks seem to have an issue with it, but not enough to become [Filtering Networks] customers nor enough to convince their upstreams to convince [Filtering Networks] to relax their filters. The destinations that are cut off don't represent a serious business case to the [Filtering Network] so the matter doesn't really have any steam. In this case the [Filtering Network] has made a change to mitigate a problem they find bothersome. Those affected by this have not achieved critical mass to convince them or their upstreams to take action, even though they are trying to improve their traffic flows. Randy has offered as an engineer of Verio to help ease the amount of effort required to do this. Why would anyone's Customer think telling a [Filtering Network] IT should renegotiate its working peering arrangements to suit another network's Customer's needs is beyond me and anyway, its energetically unfavored. Disclaimers: I have not tried to pick on Verio here, and it is my intent to only paint specific parties in a positive light. Negative light may be cast on categories, it is not intended to be offensive. This whole message (less examples) could be summarized: Rather than taking the position: XXX is doing something I don't like and they should change it. The Internet seems to favor this: XXX and a bunch of other guys are doing things I don't like and I am going to spend my time, money, and energy engineering a way to a) defeat/obsolete what they are doing, b) make them look silly for doing it, c) bypass them, or d) put them out of business. If I am off base, it's probably not the first time, nor the last. :) Deepak Jain AiNET

...

690 502 Merit Network

Well at least we don't have to go too far to find the guilty party. :P

As the old timers in the list will recall, this ASN was used by ANS back to the NSFnet days and has ended up as part of UUNet/WorldCom's ASsets. -Bert