RE: Verio Peering Question

Mailman List Mirror (Read Only)
1

So how is this supposed to work? For instance, I get a /27 and an AS
number, and I want to multihome. But nobody will listen to my
announcements. This is not a workable solution.

So you call up noc@foobar.net and offer them $x to listen to and
propagate your announcement, and perhaps to act as your agent in
transactions with other networks around the world.

Or, you could negotiate 1-on-1 with every network who doesn't
give you free (or agent-negotiated) access by default.

This imposes cost on you because you are consuming an AS number
and introducing an unaggregated and unaggregatable prefix
into these networks' routing systems.

Multihomers generally announce just a single route and there are less than
25k AS numbers so the majority of routes is NOT from multihomers so it
seems somewhat harsh to effectively forbid multihoming.

Not all multihoming requires the introduction of unaggregated
and unaggregatable prefixes.

Is there really no way
we can all agree on a filtering policy that keeps the routing table in
check but still leaves some room for responsible multihoming?

Given the vehemence with which some people argue that filtering
is a bad idea in the first place, the answer is clearly "no".
A better question is, can tools and information be put together
to mitigate the problems multihomers may face as network operators
try to deal with expanding tables, in the _absence_ of interprovider
cooperation?

  Sean.

2

Also sprach Sean M. Doran

So you call up noc@foobar.net and offer them $x to listen to and
propagate your announcement, and perhaps to act as your agent in
transactions with other networks around the world.

Oh, and that scales really well.</sarcasm>

Let's frame a few things first.

While IP address depletion is still an issue, its not the major issue at
the current time. CIDR is a pretty decent "fix" for that currently, and
functions, regardless of how the filtering issue is decided. So, with
that tossed to the side for the moment, let's look at the other major
issue.

Routing table size. I think we're all in agreement that this is the
critical current problem that filtering is supposed to fix.

Ultimately, the problem here is the RIR policies.

IgLou has 6 prefixes that we announce (I know, small time in the overall
scheme of things, but bear with me here). I aggregate as much as
possible given the 6 prefixes that I have been allocated.

IgLou was just allocated our 6th prefix within the past year or so. No
provisions were made for us to be able to keep the number of
advertisements even the same, let alone lower that. (I know, 6 prefixes
isn't a huge deal in the overall scheme of routing table size...I'm
talking about conceptually here)

I would think it is reasonable, and I believe there has even been
verbiage in some of the RIR policy documents at times that new
allocations be done in manners to minimize the number of announcements.

While I'm not really keen on renumbering equipment on my network, I'm
perfectly willing to do so for "the good of the Internet".

I think it would be a good idea for RIR's to have renumbering out of
un-aggregateable space as a condition on getting more IP space. Set a
time limit of a year or two, maybe dependant on the size of the block.

It would not be terribly difficult for IgLou to get down to 2
announcements from the 6 we currently have, and its conceivable that we
could get down to a single one.

Maybe this should happen over time...each time you get a new block, you
turn in 2. It doesn't matter the length of the prefix you turn in,
since the critical issue isn't the number of IP addresses in use, but
rather the number of entries in the routing table.

I could *EASILY* renumber out of one of the prefixes that I have (a
/24), in a heartbeat, but I have absolutely no incentive to do
so...indeed, I have something of a disincentive since that's a loss of
available IP space for me, with no benefit.

Keep in mind that the number of available IP addresses isn't a
significant issue as CIDR is still functional in this sort of
environment, so the current RIR policies about utilization of space
could still be used with only some minor tweaks. (Obviously, there's no
point in giving IgLou a /20 if one of the blocks that I would be turning
in would be a /20).

This addresses the heart of the current problem, the number of
un-aggregateable prefixes, without going back to the original problem
from back in the day of depletion of IP address space.

3

Those who propose filtering a la Verio / Sprint(passim) suggest that
your incentive to renumber is that certain other (not in the line
of transit) networks will not accept these prefixes (or apply more
stringent dampening on them), and hence give you inferior routing
either permanently (filtering) or temporarilly (dampening), assuming
you have a covering netblock.

Of course if you have a swamp /24, the filtering argument doesn't
apply, but the dampening one does.

Aside: It's interesting that all the anti-filtering arguments are
coming from those who are customers of Filterer's peers. We have heard
that Filterer doesn't filter its own customers, but we haven't heard
Filterer's BGP customers complaining (at least in this forum) that they
are missing routes and hence have suboptimal connectivity to Filterer's
peers' customers. As last 3 letters of NANOG indicate, we here should
perhaps be interested in designing filtering policies which
attract happy paying customers - so far few people have suggested
an upstream with aggressive peer filtering is a worse upstream.
(Ducks from torrent of mail)

4

Also sprach Alex Bligh

Those who propose filtering a la Verio / Sprint(passim) suggest that
your incentive to renumber is that certain other (not in the line of
transit) networks will not accept these prefixes (or apply more
stringent dampening on them), and hence give you inferior routing
either permanently (filtering) or temporarilly (dampening), assuming
you have a covering netblock.

But that's not an incentive to renumber at all, because I can't go to
ARIN and say, "I want to renumber out of these disparate blocks and get
one big one that is more globally routable." So renumbering out of the
block that I'm thinking of (204.252.74/24, FWIW) still doesn't do me any
good.

Of course if you have a swamp /24, the filtering argument doesn't
apply, but the dampening one does.

The /24 I mentioned above isn't swampy, but I do have a swamp /24 that
we make use of...and it would be one of the more difficult ones for us
to renumber out of, but we'd be willing to do for "the good of the
Internet" if we weren't going to be stabbed in the back for doing it,
which is about the situation as it exists now.

Aside: It's interesting that all the anti-filtering arguments are
coming from those who are customers of Filterer's peers. We have heard
that Filterer doesn't filter its own customers, but we haven't heard
Filterer's BGP customers complaining (at least in this forum) that they
are missing routes and hence have suboptimal connectivity to Filterer's
peers' customers. As last 3 letters of NANOG indicate, we here should
perhaps be interested in designing filtering policies which attract
happy paying customers - so far few people have suggested an upstream
with aggressive peer filtering is a worse upstream. (Ducks from
torrent of mail)

Perhaps that's because all of us that think the filtering is a bad thing
wouldn't touch a Filterer's network with a 39 1/2 foot pole. I think
its rather a self-selecting sample.

Personally, I look forward to the day that a Verio sales rep. calls me
trying to sell me transit so I can read him the riot act about their
filtering policies.

Ultimately, the policies in place for IP allocation *encourage* routing
table growth. We can blame Verio, or whoever is filtering, and I
believe they do deserve all the flames they get...probably more...as
they choose to filter and essentially say, "Screw you, little providers
and small corporations, you're not a big boy so you don't deserve robust
network connectivity." I do have to reserve some blame for the RIR's as
well though. Their policies encourage routing table growth, so they
have to share in the blame for that.

5

Date: Tue, 02 Oct 2001 23:48:55 +0100
From: Alex Bligh <alex@alex.org.uk>

[ snip ]

Aside: It's interesting that all the anti-filtering arguments
are coming from those who are customers of Filterer's peers. We

[ snip ]

Perhaps those who disagree with this type of filtering avoid the
upstreams in question?

If customer of Filterer understands what's happening, and doesn't
mind losing redundant paths to smaller networks, _that's_ what I
want to hear. AFAIK, that hasn't been posted, either.

Eddy

6

Jeff,

Those who propose filtering a la Verio / Sprint(passim) suggest that
your incentive to renumber is that certain other (not in the line of
transit) networks will not accept these prefixes (or apply more
stringent dampening on them), and hence give you inferior routing
either permanently (filtering) or temporarilly (dampening), assuming
you have a covering netblock.

But that's not an incentive to renumber at all, because I can't go to
ARIN and say, "I want to renumber out of these disparate blocks and get
one big one that is more globally routable." So renumbering out of the
block that I'm thinking of (204.252.74/24, FWIW) still doesn't do me any
good.

Well, I'm more familiar with RIPE than ARIN, but if you are saying
'If I were to apply for a /x anew, ARIN would give it to me, but
as I already have a /a, a /b, a /c, ARIN won't let me return them,
and renumber into a /x' I'd suggest that policy needs looking at,
for exactly the reasons you suggest.

I /do/ know of instances where companies have (say) an old /16,
severely underutilized, and want to get more space for some reason,
offer to return their old space, but insist on getting at least a
/19 (or similar) on the grounds of routability, even though if
they made the application afresh they'd get at most (say) a /22.
Hard one to call that.