Re: Why does Sprint have address filters again?

[Phil Howard <phil () charon ipal net>]

Andrew Smith writes...

> This would have one effect. ISP's would require any and all customers
> who have their own space to run BGP and use their own AS, therefore
> just sticking a variety of different labels on routes that were
> previously under the ISP's announcements.

Unless the customer has a larger network, /19 or shorter, they will face
the same problem with prefix filters in certain networks like Sprint.
Sure, this can be a problem, but the goal is to aggregate prefixes.  If
this won't encourage it, then it's a bad plan.  But the goal still remains.


> This point isn't even taking into account how absolutely real
> it is for a medium size ISP to have 3 /17s or 3 /18s or 3 /19s
> or 6 prefixes from /17 to /24.

They are taking up 15 prefixes in my route table, when they could
aggregate their space by renumbering into a single /15 or /14 and
take only one?

If the high number of prefixes out there is NOT a problem, then say so.
If that is the case, then Sprint has no justification for filtering the
routes by prefix size.


> Given that this would seriously impact the larger NSP's (how many /24's
> do you think Sprint, MCI, and UUNet) announce for non-BGP customers,
> how realistic do you view this proposal?

Us smaller ISPs are being required to constantly renumber our space
just to get more space.  So tell me what the boundary is where an ISP
can grow past where they no longer are required to renumber space?

We see "size bias" from Sprint in their filtering.  Are we also seeing
"size bias" in how ISPs are treated with respect to renumbering policies?


> /* Beginning Rant */
>
> Not to sound bitter, but the vast majority of the contributers
> to this list have gone from using engineering practices for the
> good of the net to using engineering practices to make it work,
> given the goals and limitations of corporate policy. Any other
> approach can't get the dollars behind it and compete with
> the corporate direction of "well if other providers are willing
> to limit their potential customer revenues by making this policy,
> we can just buy RSP-4's and get the customers they lose".

As it stands now, small ISPs are the ones with the potential to lose
customers because of the existing "size bias" with respect to filters
against long prefixes.


> Our ideas and suggestions need to be both good for the net, and
> not vulnerable to someone out there flying in the face of it to
> make a buck. Sprint's filtering policies are one of the few
> filtering plans that was successfully imposed upon the net that
> actually stuck (read, significantly impacted a majority of us in
> dealing with inter-provider announcements). The only way they
> did make it stick and not cost them large amounts of revenue
> was to make exceptions for their own customers thereby removing
> the "good of the net" result and making it "good for Sprint".

You're being vague here.  In on breath you are saying Sprint's policy
is good, and then saying it is not good for the net, but only good
for Sprint.

Well, I can see how it is good for Sprint.  With filters they can go
cheap on router memory and CPU speed and save a few bucks, possibly
charging less for their customers, and certainly making more profit.
This, from a business standpoint, is certainly good for Sprint in the
short term.

But a small web provider business that was smart enough to implement
their web services using shared IP addresses, instead of putting each
web site on its own IP address, can do it in a /26 instead of a /19,
but gets shafted by Sprint.  Maybe you are suggesting that they hook
up to Sprint and become and expection?  Maybe I suggest that they
blackhole all of Sprint instead.


> Cabal-like engineering mandates may be damn good for the routers,
> but the dollars behind the routers are speaking much louder with
> each passing day. It is not only naive, but irresponsible to count
> on the technical "good of the network" arguments to continue to
> dismiss without question or compromise, business concerns,
> especially when such proposed and/or implimented methods cause
> complaints of hardship from paying customers which assuredly
> reach those who's chief concern is the satisfaction of the
> stockholders.

I agree there are concerns for router efficiency.  But some other
solution is needed aside from requiring everyone to get a /19 (which
once everyone does, Sprint will raise the bar to /18 or /17 or some
such level).  There needs to be a solution where the small (whether
because their business is small or because their engineering is wise)
are treated equally to the large.

I did say that at some level the number of prefixes might no longer
need to be counted.  Would Sprint be willing to allow the one largest
prefix in the /29 to /20 range, per each AS, through, if the software
provided a feature to automatically pick it out from the announcements
for each AS, and just let all /19 and shorter through as they do now?
That would increase the number of prefixes they have to deal with by
some amount, while encouraging the smaller ISPs to keep their space
well aggregated.

It would still allow the large ISPs to flood the route space with excess
numbers of prefixes, it which seems they want to be able to do while not
allowing the smaller ones to do so.

By all means, my idea is not ideal.  But the existing situation is not,
either, unless you are willing to give each of your multi-home customers
a /19 block, whether then need that many addresses or not.

Got any better ideas?  I'd really like to see one that is better than
the choices we have now.

-- 
Phil Howard | stop3it9 () s3p7a1m8 com stop2ads () no6where com no7spam4 () no5where net
  phil      | stop7it1 () noplace7 com ads3suck () no4place org stop9630 () no7place org
      at    | stop0ads () nowhere4 com stop6137 () s2p9a0m5 com no16ads2 () anywhere edu
  ipal      | die6spam () anywhere com ads8suck () dumb3ads net no0way65 () anyplace com
     dot    | stop5it7 () s9p5a5m6 com no6spam3 () spammer0 edu die2spam () spam5mer com
  net       | end1it62 () no6where edu end4it88 () no7place edu stop6609 () no8where net