Sean M. Doran writes... [re: inbound filtering]

Sprintlink did at one point. It's a really good idea to do this in general because it mitigates the disconnectivity customers assigned prefixes out of one's address blocks will suffer if and when someone accidentally(?) announces subnet of those blocks.

Good point.

Inbound filters can be adjusted, you know. Unfortunately the people who have inbound filters have never figured out that they should make this a service that they charge for.

How easy is this to do. How many filters would a company like MCI/WorldCom have to place in each peer router?

However, since inbound announcement filtering is a game anyone can play, I recommend people consider the implications of fee-based filter updating and how it can effect their routing whether or not they are the ones doing the inbound filtering.

Should the charge be for adding the filter (deny) or for deleting it (permit)? If the provider defaults to deny, then for a customer to request a permit on their prefix means adding a filter to the router. If the provider defaults to permit, then a customer wanting a deny would obviously mean adding a filter. Once a provider starts charging for the service under one policy, that means that one set of customers pay the fee and the others do not. But if the provider decides to change the default, then it reverses the customer sets of who pays and who does not. One business model would be to choose the default based on the largest number of customers paying. But that could result in customers leaving, either due to the extra fee, or due to the slower operation of the network with so many filters in place. The other business model would be the reverse, to choose the default to minimize the number of filters, minimizing the costs to the customers and maximizing the performance (while retaining customer preferred route security policy). I would tend to prefer the latter model. I doubt such charges could really make or break the bottom line for most businesses. The tough position would be if the customer preferences went about 50/50. ... I still wish there was an easy way to filter routes on the basis of allowing N route prefixes per prefix size per AS where N might well be 1.

Connectivity = bidirectional bandwidth + bidirectional reachability.

Connectivity = value.

How might symmetry fit into that? -- Phil Howard | end7ads0@no61ads4.com blow6me1@no3place.edu stop1878@anywhere.edu phil | w1x4y4z0@spam3mer.com no2spam6@noplace9.org no8spam8@spammer9.edu at | ads2suck@no7place.net a6b0c7d4@no0where.net die0spam@noplace0.com milepost | stop9610@dumb1ads.edu eat0this@anyplace.edu crash946@noplace6.net dot | eat4this@s0p7a8m7.com stop8it5@dumb2ads.edu ads2suck@s4p9a8m0.net com | eat4this@spam8mer.com no0way44@anyplace.net eat37me5@no1place.com

In message <yt4t5j8sh9.fsf@cesium.clock.org>, "Sean M. Doran" writes:

Phil Howard <phil@charon.milepost.com> writes:

...

Route filtering is not the end of the world.

Wow. Times have changed.

...

You also need to make sure that the ISPs do not filter routes for parts of their own blocks coming in from other peers. If ISP-A did such filtering , then their own customers will find you unreachable, as well as those in ISP- C if ISP-C sends traffic for you into ISP-A.

I know of no ISPs doing such a thing

Sprintlink did at one point. It's a really good idea to do this in general because it mitigates the disconnectivity customers assigned prefixes out of one's address blocks will suffer if and when someone accidentally(?) announces subnet of those blocks.

Inbound filters can be adjusted, you know. Unfortunately the people who have inbound filters have never figured out that they should make this a service that they charge for.

However, since inbound announcement filtering is a game anyone can play, I recommend people consider the implications of fee-based filter updating and how it can effect their routing whether or not they are the ones doing the inbound filtering.

Connectivity = bidirectional bandwidth + bidirectional reachability.

Connectivity = value.

Sean.

Since you would need some type of settlement system in order for this to work, if you could get a third party to maintain the access lists information, and manage the settlements, then you might have something. I.e. a third part, Neutral Settlement Authority (NSA), uses a database such as the IRR to maintain a set of policy statements, that are readable by the rest of the Internet, They convince a few providers, say Sprint and Digex, to listen to them for prefix length filter exceptions, in return this Neutral Settlement Agency, pays these providers for this service. The Neutral Settlement Agency then, posts to Nanog, or other lists, saying it will cost you X dollars to have your execption listed with us at some cost of what the costs to providers A and B are paid plus some percentage for profit. Looking at this, pretty much any BGP speaking peer at the MAE could do it with the correct configurations, and the RA service could do it also, although there are those that won't touch an RS with a 10 AS BGP path extension, although perhaps if they were getting paid for it... The biggest problem I see with prefix charging is the many to many contract nature, which is where a MLPA type situtation is helpful, but must be setup so that different providers can negotiate different rates, as network sizes differ, and the cost to carry those prefixes internally varies. --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net