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
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 126.96.36.199/13 become 188.8.131.52/13, all the /20s and
/21s in 184.108.40.206/16 become 220.127.116.11/16 and all of the /19-/21 in
18.104.22.168/14 become 22.214.171.124/14. We also leak select components.
You'll note a few more specifics of 126.96.36.199/14 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.