Sprint's filtering

Michael Dillon wrote:

The policies that once were technical policies instituted
by Sean Doran are no longer technical policies but a crass manipulation of
the marketplace to Sprint's advantage as the archives of this list prove
quite amply.

Hello, my name is Sean Doran.

The reality you seem to forget is that Sprint's holding the line
on filtering has been holding the number of prefixes being seen
globally to a conveniently small number.

Just as the several networks who refuse to listen to announcements
of address space not delegated by the IP registries -- or recorded
in routing registries as associated with the origin AS --
Sprint's filtering has done some public good as a side-effect of
intelligent self-defensive design.

A denial of that is merely petty politicking, rather than anything
actually rooted in technical issues.

Finally, unlike a number of people reading this message, Sprint
was largely unaffected by the unfortunate leak of several thousand
prefixes by another large provider in the not-too-distant past.

On that note, should someone go mad and decide to deaggregate a /8
to the /32 level just for fun, how many of you honestly wouldn't
notice because you have *some* sort of prefix-length filtering in place?

I'm curious to know in your particular case, Michael, whether
you have a concern about the actual act of self-defensive filtering,
or whether you are merely arguing that the potential number of
prefixes Sprint may see is too low.

Oh, wait, you wave the spectre of "clear violation of antitrust"
around, so therefore any claim that you are making a _technical_
argument is clearly false.

So, I am sure you are unimpressed that I actually hope Sprint
undertakes to do *more* filtering, namely to ensure that prefixes
can only be originated by ASes to whom the registries have delegated
the address space, using a scheme proposed by Tony Li, Yakov Rekhter
and Randy Bush, as presented at NANOG and RIPE and in other venues.

That they protect themselves and their customers from unintentional
routing-table explosions and redistributions into and out of IGPs
does some public good is a useful side-effect, but the primary goal
is and ought to be self-protection.

But I want to know
why ARIN cannot simply issue an appropriately sized portable block of
addresses to anyone who is legitimately multihomed?

Appropriately sized: one /32, please.
Legitimately multihomed: I have accounts at two ISPs in Toronto,
                         one ISP in Copenhagen, and two ISPs in Stockholm.
I also travel to IETFs and other places with terminal rooms, and would
dearly like my laptop never to have to renumber when it changes its
location in the topology.

My laptop's *users* moreover would really hate to have to adapt
to changing IP addresses every time a new provider gets selected.

Please campaign for *MY* rights, too, you guys! I feel left out
by you big boy regional ISPs who are trying to strangle my
enterprise out of existence with your antitrust policies favouring
the large and medium-sized over the very small!

  Sean.

Sorry. While we've indeed built a system which provides mobility for
Internet engineers, that only refers to *job* mobility...

:wink:
/John

Both AT&T and GTE now offer flat rate Internet access via CDPD. Modems
are available in a type-3 P-card form factor for about $7-800. Service
is $54,95 a month, AT&T will offer off-net roaming at a flat rate for
an additional $10/month.

Anything else I can help you with? :slight_smile:

Cheers,
-- jra

Michael Dillon wrote:

The policies that once were technical policies instituted
by Sean Doran are no longer technical policies but a crass manipulation of
the marketplace to Sprint's advantage as the archives of this list prove
quite amply.

Hello, my name is Sean Doran.

Howdy Sean. Long time no see. :stuck_out_tongue:

The reality you seem to forget is that Sprint's holding the line
on filtering has been holding the number of prefixes being seen
globally to a conveniently small number.

While this *may* have been true in circa 1995, there is little to no
evidence that 112 is still performing the same service. If you want a
"technical" argument, Sean, stick to the *facts*, not your assumptions. To
be blunt, it is impossible to tell what would really have happened had
those filters not been in place for the last few years. Or are you going
to claim some Carnak like powers to predict what a system as large and
complex as the Internet would do without your sage guidance over a period
of years?

Unfortunately, about the only way to "test" it is to take the filters off.
Fortunately, most providers out there ignore Sprint's filters because an
aggregate is being announced by their upstream and they'll get the packets
eventually.

Personally, I think a far larger gain could be made by searching out all
the people who are announce sub-blocks of their own CIDR from their own
ASN. While doing this can provide some utility to your peers (e.g. more
accurate MEDs), the overwhelming majority of people announcing a
sub-section of their own CIDR are doing it ... by accident. (At least I
hope it is by accident. :slight_smile: Add to that some aggregation effort (two /18s
into one /17, etc.) and the table would probably shrink quite a bit more
than under the effect of Sprint's filters. Of course, that's just my
opinion. :slight_smile:

The good thing is, the amount of shrinkage from my suggestion can be
calculated fairly easily. Mr. Rand at Above.Net once ran a script which
showed such calculations and there are things like the CIDR report which
show large amounts of deaggregation by some large providers. (I seem to
recall one of Sprint's networks being pretty hi up on that list until
recently. :slight_smile: Perhaps we should spend some time LARTing those who do not
aggregate properly?

Just as the several networks who refuse to listen to announcements
of address space not delegated by the IP registries -- or recorded
in routing registries as associated with the origin AS --
Sprint's filtering has done some public good as a side-effect of
intelligent self-defensive design.

A denial of that is merely petty politicking, rather than anything
actually rooted in technical issues.

[SNIP]

Actually, Sprint's policy is partially motivated by "politicking" - or at
least by capitalistic goals. Since you have personally admitted this to my
face, and Sprint's management has said as much in private e-mail, I think
you calm down on the name calling.

If Sprint were *truly* out for the "good of the Internet", then they would
filter their downstreams the same way they filter their peers. But for
some unknown reason, I see all kinds of small blocks coming out of Sprint.
For instance:

*>i136.150.45.0/24 X.X.X.X 169 100 0 1239 1785 i
*>i136.150.46.0/24 X.X.X.X 169 100 0 1239 1785 i
*>i136.150.60.0/24 X.X.X.X 169 100 0 1239 1785 i
[...]
*>i168.167.25.0/24 X.X.X.X 169 100 0 1239 4005 ?
*>i168.167.26.0/24 X.X.X.X 169 100 0 1239 4005 ?
*>i168.167.27.0/24 X.X.X.X 169 100 0 1239 4005 ?
*>i168.167.28.0/24 X.X.X.X 169 100 0 1239 4005 ?
[...]
*>i208.14.160.0 X.X.X.X 169 100 0 1239 4997 i
*>i208.14.161.0 X.X.X.X 169 100 0 1239 4997 i
* i208.14.162.0 X.X.X.X 189 100 0 1239 4997 i
*>i208.14.163.0 X.X.X.X 169 100 0 1239 4997 i
[...]

(I've obviously edited it a bit, but it's easy enough for anyone here to
check this information at any of the public route servers.)

So Sprint obviously has some agenda besides "the good of the Internet" or
"the size of the table". Or they at least realize some benifit, financial
or otherwise, from not practicing what they preach.

Now please don't flame me saying Sprint can do as it pleases. I completely
agree that Sprint is allowed to filter whomever they want whenever they
want. (As long as the filters don't break any contracts, etc.) If a
customer doesn't like it, they can move. I just have a problem with Sprint
saying "we're here to save the Internet" and then doing *exactly* what they
claim others should not be doing. Hypocrisy annoys me.

Of course, publicly Sprint blames this on their peers. You see, they say
their peers should filter Sprint the same way Sprint filters their peers.
So, let's take them up on it. If you honestly believe Sprint is getting
some advantage out of filtering you, then FILTER THEM BACK. But be sure to
only filter Sprint. :stuck_out_tongue:

If everyone - or even just a couple really big providers - did this, Sprint
would suddenly lose its "advantage". All those people who bought a T1 into
Sprint so their /24 would be seen globally will be pretty upset when it was
not being seen by, say, UUNET.

Unfortunately, the large backbones don't have the ... backbone to do this.
(Sorry about the pun, I couldn't resist. :slight_smile: It's really a shame. Sprint
is no longer even close to the largest backbone out there, so people don't
have to bow and scrape at their whim. But they've already taken the heat
for instituting filters, and no one else wants to do the same. (I gotta
admit, Sean, it took balls to do that - even if you were the biggest back
then.)

Anyway, I'll prolly get flamed for this by all kinds of people saying "of
COURSE the table would be out of control without Sprint's help!" But
that's okay, I'm used to flames. Sean's own evidence didn't show me
anything I would call even close to "proof" that 112 is saving the
Internet, so anyone just "claiming to know" 'cause they have been around
longer than me, or they run this network, or they work for this vendor, or
even they are psychic probably isn't going to sway me. Unsubstantiated
claims are worthless. OTOH, if you have some *facts* to present, please
feel free to send them my way.

Sean.

TTFN,
patrick

Hi,

if you have some *facts* to present, please
feel free to send them my way.

Fact: the existence of documented filters imposed by Sprint was and is
used by the Internet registries (well, at least one I'm positive about) to
discourage the allocation of provider independent prefixes.

Did this "save the Internet"? First, you have to figure out what it means
for the Internet not to be "saved". In this context, I'd argue it would
mean portions of the Internet would become unreachable because routers
couldn't handle the routing load. The Internet would not have collapsed --
service providers would take whatever steps they felt necessary to provide
the highest level of service they were able to please the largest portion
of their customers. In practice, I suspect this would mean they would (you
guessed it) filter out long prefixes.

So the question really is, did Sprint's filters reduce the rate of growth
of the Internet routing system. Clearly, given the registries did not
allocate some prefixes they would have had otherwise, the answer is yes.
Would the Internet have partitioned if Sprint didn't impose the filters?
Dunno. I do know that the number of provider independent prefixes at least
one registry allocated dropped significantly after the filters were turned on.

Regards,
-drc

it is impossible to tell what would really have happened had those
filters not been in place for the last few years.

one can truely not tell about alternate futures, i.e. mci would probably be
filtering, as they were pretty ram short.

but those interested in data as opposed to cheap talk might look at frank's
measurement reports to ale and cidrd.

randy

Hi,

if you have some *facts* to present, please
feel free to send them my way.

Fact: the existence of documented filters imposed by Sprint was and is
used by the Internet registries (well, at least one I'm positive about) to
discourage the allocation of provider independent prefixes.

I have been told that ARIN did make an effort to have Sprint remove its
filter so that ARIN could allocate blocks longer than /19, but I have not
confirmed this with ARIN. In any event, I do not dispute that Sprint's
filters had at least some affect on the allocation policies of ARIN. So
we'll count this as a fact barring a denial from ARIN.

Did this "save the Internet"? First, you have to figure out what it means
for the Internet not to be "saved". In this context, I'd argue it would
mean portions of the Internet would become unreachable because routers
couldn't handle the routing load. The Internet would not have collapsed --
service providers would take whatever steps they felt necessary to provide
the highest level of service they were able to please the largest portion
of their customers. In practice, I suspect this would mean they would (you
guessed it) filter out long prefixes.

While I agree that unchecked growth of the table will likely lead to Bad
Things, I'm simply stating that we are incapable of *knowing* the table
would not have found some better way of regulating itself had 112 not been
implemented. Perhaps people would have tried harder to aggregate. Perhaps
people would have filtered only those providers who did not aggregate.
Perhaps cisco and the other vendors would have come out with bigger,
better, faster, cheaper routers sooner. Who knows? Certainly not me, and,
unless you have some mystical powers, neither do you.

So the question really is, did Sprint's filters reduce the rate of growth
of the Internet routing system. Clearly, given the registries did not
allocate some prefixes they would have had otherwise, the answer is yes.
Would the Internet have partitioned if Sprint didn't impose the filters?
Dunno. I do know that the number of provider independent prefixes at least
one registry allocated dropped significantly after the filters were turned

on.

Your assumption does not guarantee your conclusion in any way. Clearly, if
the registries had decided to allocate smaller blocks, we would have some
routes in the table which we currently do not have. This does not prove
the size of the table as a whole would be bigger, smaller or the same as it
is now. It's a reasonable guess, but that's all it is.

Here's what facts I do have regarding 112. When Sean and I first had this
argument, he posted several URLs showing graphs over the last few years of
the size of the table. I'm afraid that other than a small dip in when the
filters were implemented, I see little to no change in the actual growth
rate due to 112's implementation. In fact, right after that short, small
dip, the rate of growth actually increases slightly.

Now, unless you are going to claim Sean is a fortune teller and knew that
the growth rate would skyrocket right at that time, it is obvious that 112
did not have its intended effect.

Going back to your idea about the allocations from the registries. How
many of you go "I can't announce that because Sprint won't hear it?" I
almost never hear that. Everyone just assumes the aggregate CIDR allocated
from ARIN (or wherever) will be announced and whoever announces the more
specific expects the provider announcing the aggregate to pass the packet
along. Unless, of course, the provider announcing the aggregate is Sprint.
So, if anything, Sprint's filters tend to create a bit of suboptimal
routing, not slow the table growth. It may even be argued that the number
of announcements has *increased* due to 112 - because we now have the
downstream announcing their tiny block and the upstream announcing the full
allocated CIDR. Perhaps if each downstream were allocated their own block,
we could remove some of the CIDR announcements and shrink the table?

But that's academic now. Besides, I'm still not saying that Sprint has to
remove their filters - it's their network, they can filter as they please.
In fact, even I believe Sprint's filters have some effect on the table - at
least initially. I just think the overall effect is less than everyone
else seems to think. I also believe that there are other, more useful ways
of shrinking the table - such as forcing people to aggregate.

My main point was that Sprint *does* enjoy a competitive advantage with 112
- but only because we let them. Whether they did it for altruism (yeah,
right, even Sean doesn't say that), or because they had to 'cause their own
equipment couldn't handle it (as Sean claims), they probably get some
business because of those filters. But that advantage would evaporate if
everyone filtered Sprint the same way. (It would actually be a
disadvantage if everyone filtered Sprint *and only Sprint* in that way.)

So, let's assume filtering is really that awesome and absolutely necessary
for the good of the Internet. I propose we try a test case to prove this
hypothesis. Everyone filter Sprint. It's quite easy, Sean posted some
versions of 112 to NANOG back in September of 1995. (See
http://www.ianai.net/filters/Sprint-ACL112 for one of his early versions.)

I said before it was difficult to test, but I think this may provide a
valid measurement. If Sprint is not a large enough provider to make
filtering them sadistically significant, then their continued use of 112 is
useless with regards to slowing the growth of the table. (Can't have it
both ways.)

So, anyone care to filter Sprint with a 112-like ACL?

-drc

TTFN,
patrick

Balderdash. The cost of a few SIMMs in routers pales beyond the market
damage that comes from not being able to get where your customers want to
go.

Protecting provider's hardware budgets is not part of a registry's job.

I don't think the cost of having enough memory was the issue, it was the
physical ability of the router's cpu to handle updating the routing table
with that many routes...

Sean Mentzer
Qwest Communications
IP Engineering
303-226-6770

The key word is "was". Since then, Moore's Law has taken us to routers that
can handle the load better.

Aggressively dampening flaps solves that problem. Entropy is controllable;
the issue was presented as being one of table space (much as it was when the
AGS+ ran out of space until the 7000/SSP was introduced)

It was RAM and CPU IIRC - but both aren't the same issue as they were then
- speeds have factored up a bit too