Customer AS


Responses in to parts of your long mressage. Overall, I commend you
for doing something. Its different from what we are doing, but
different approaches to solve a problem can exist. I think some
refinement on the policy might help. So in the spirit of cooperation,
please don't take this as flamage.

Since March of 1995, Sprint has had contractual language
with respect to our PA address delegations that make them
explicitly non-portable, and not to be used in any other
provider's network.

In order to enforce that contract, we have installed
inbound prefix filters to ignore all subnets of our PA
CIDR blocks that are announced by our peers at exchange

We have made no exceptions or holes in those inbound
filters, except in the few cases where a network with
addresses from Sprint CIDR space was willing to renumber
and cease using the old non-portable numbers within a
fixed number of days after homing itself to another provider.

Making an exception for grace period renumbering is a good thing. You
might want to consider making an exception for dual homing to another
provider. That's you business (honestly).

We are aware of you policies and if someone needs to dual home we take
them into account and try to maintain the best connectivity everywhere
including to SprintLink.

You might even consider being somewhat more charitable
towards a competitor which has, unilaterally, undertaken a
sometimes heavily criticized path leading to an economy
wherein topology-based addressing is considered the best
approach, not only from a technical perspective, but from
a business perspective too. This approach, even though
it has not been perfect, has, I suspect, made it possible
for you to go into business with only a few million
dollars of capital expenses rather than a few million
dollars per router. Heck, you've even said as much
yourself, in a previous incarnation.

Your policies would be unacceptable to many larger corporations or
customers that insist on multihoming. Your policy maybe a reflection
of you customer base and your customer base a reflection of your
policies. Your policies have been effective in reducing the number of
prefixes floating about. I don't agree that with the apparent claim
made by you and sometimes others at SprintLink that they are the only
thing being done.

This is not intended to be a flame, so be calm. I just want to look
at some numbers to support the statement that something else is being
done besides lip service (lest I surely get roasted:).

If you look in the IRR there are 823 prefixes marked ANSIGPONLY.
These are more specifics announced to ANS but not propogated further,
where the customer also announces an aggregate. MCI and BBN do
something similar, only they use BGP communities set by the customer
(less config headache, less relaible IMO, but that's a tradeoff).
I think Alternet does too.

You'll find 45 ANSPROXYAGGR and 63 ANSREFINENEXTHOP (19 have both).
The ANSPROXYAGGR are what we call inbound aggregates (not truly proxy
aggregation since this is often different customers that touch ANS at
the same ANS core node). This doesn't look like much, but these are
mostly /17 to /20. Most of the /20s are made of /25s and /26s. The
/17s are made of /24 or larger. So there is quite a bit of savings

You'll also note that you don't see most of these /17 and /20. That
is because we do outbound aggregation too. On the way out all the
/17s to /19s in become, all the /20s and
/21s in become and all of the /19-/21 in become We also leak select components.
You'll note a few more specifics of are out there (there
should be exactly 2), but you don't accept them. These are dual homed
to another provider.

All in all though, I'd say we're still not model citizens (ANS), since
there are blocks (including the rest of 204.148/14 that we own) where
we have badly allocated (some a long time ago) and are still trying to
sort out. We do intend to aggregate everthing we announce as best as
possible, we just aren't there yet.

The only thing I'd like to point out is that Sprint is not alone in
doing something. I can only give ANS examples, but I know MCI, Spint,
Alternet, and every respectable provider is taking steps toward better
aggregation and is aggregating.

The approaches have been different. Ours has been costly in terms of
software development. It requires prefixes to be registered in the
IRR (not a big deal IMO, but I know that you don't agree). The only
"feature" not yet impelemented is the autom,ation of configuration for
aggregation across provider boundaries. All other features that we
"gave lip service to" at prior NANOGs are completed in use. We feel
the precision with which we can set up routing and aggregation makes
it worth the up front investment.

For us, now that we have the code all done, its a matter of applying
it (figuring out what is safe to aggregate and submitting the right
route objects). All new ANS allocations are being done right and the
old stuff is being reviewed so we can aggregate it without breaking

Your approach gave fast results and has been controversial due to the
rigidity of some of the accompanying policies. I still commend you
for providing much of the early reduction in route table size. If I
can make a suggestion without being viewed as hostile (I really do
intend this to be just a constructive suggestion), you might want to
look at the policies and see if you can provide some types of
exceptions. Area which have lead to controversy sometimes are due to
a legitimate need for a little flexibility.

(If I were to give myself some suggestions it would be to get moving
faster on configuring the aggregation, though building a new backbone
does seem like a resonable excuse for being distracted.:slight_smile:



Curtis Villamizar <> writes:

I don't agree that with the apparent claim made by you
and sometimes others at SprintLink that they are the
only thing being done.

If I come across from time to time as saying that mine
has been the only viable approach, or the only approach
actually being taken, then you should blame that on
lapses into rhetoric.

I'm glad we both agree that we are both doing things
to try to curtail boundless growth of global routing
tables, even if our approaches are often very different.

Also, as I said at NANOG, I like many of the directions
you've headed in, and when they can be followed by us,
I expect that us Sprint people will reconsider some of
our stronger positions wrt the practicality of databases.

You also stole my follow-up paragraph with your last
paragraph, too. :slight_smile: However, just to reiterate, the
utility of other approaches is heavily reliant upon the
availability of a sizeable set of tools which can be used
by people in the trenches. Unfortunately, since those
tools tend to be developed only either by or with lots of
input from people in the trenches, and those people are
busy building new backbones (you are not the only one :slight_smile: ),
sometimes the goal seems alot farther away than I'd like
in order to justify manual work to simulate non-existant

you might want to look at the policies and see if you can
provide some types of exceptions

Naturally. Again, I probably come across as a bit
more extreme than I really am. The goal is not to
unnecessarily make life difficult for customers of ours
or even of yours, but rather to provide some backpressure
against particularly bad practices that would make
the scaling problems we are seeing now even worse.

Finally, you'll note that elsewhere I've been pushing for
a more tractable feedback system that involves unleashing
market forces upon most of the processes which have been
argued about in CIDRD, here and elsewhere.

I think that this is probably a good direction to head in,
and I would welcome your participation in PIARA land.