randy@psg.com (Randy Bush) writes:
What their policy actually does is
convince wise folk not to buy from Sprint.
Well, I don't want to argue with you as a marketing person
with respect to brand names and the like, but hopefully I
can separate your technical arguments from what might
honestly be mistaken as an attempt at market positioning.
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
points.
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.
This is simply because rather than paying lip-service
to non-portable PA addresses, we have worked out a
contractual framework for delegation of these addresses,
technical support for non-portability and also for
aggregation. That is, there should be no subnets
our non-portable PA CIDR blocks seen outside Sprintlink.
This means some 4500 prefixes are hidden from global
routing tables, with nearly zero entropy, because we
do not make it easy for subnets to be migrated out of SL
and remain workable.
You have correctly noted that this effectively means that
dual-homing to a Sprintlink peer (such as MCI) will not
buy you fallback in the case of failure of your Sprintlink
connectivity. This is a side-effect people generally are
aware of, and generally can work around anyway.
The simple solutions are, in order,
-- make sure you have redundant connectivity to SL
so that you do not lose connectivity to Sprintlink
(admittedly we have not done a very good job
making this option attractive price-wise,
unlike a pair of our competitors, however we
are working on that, and hopefully this option
will be attractive _notwithstanding_ our non-portability
policy)
-- work out mutual back-up transit with another
dual-homed SL customer
Customers X and Y are using PA space.
Each announces their subnets to SL and the 2nd backbone.
Each takes, at minimum, announcements for the
other customer from _both_ backbones.
Note that this likely will require the
equivalent of de-aggregation on the SL side
in some cases (each sub AS does aggregation,
and announces only the aggregates).
This essentially amounts to what Yakov
Rekhter describes as a "route pull".
This is important for the next bullet.
Customer X's connection to SL fails.
Customer Y no longer hears SL's the
announcement of X's subnets
but they continue to hear them
from the 2nd provider
Customer Y therefore announces the subnets
to SL on X's behalf.
Note that this will require us to adjust
inbound filters on the customer
aggregation router in most cases,
and is also what Yakov Rekhter
describes as a "route push".
SL hears announcement for X from Y,
and hands X's traffic to Y.
Problem solved.
I would note that at least one SL customer,
namely CAIS, actively sells this solution as
a product. Moreover, they do a good job,
and this is clearly a win for Sprint,
Sprintlink's and CAIS's joint customers,
and the manageability of our efforts to
avoid increasing the size of global routing
tables.
-- offer yourself up as a PIARA-style volunteer
I imagine that if there was a specific fee
for a/ converting PA space into effectively PI
space, b/ adjusting inbound filters at our
edges, and c/ adjusting outbound filters at
our edges, and this were negotiated initially
as a special customer arrangement, Sprintlink's
engineering and operations folks would have
little problem with this, other than scaling
it upwards to handling lots of this type of
arrangement.
I would imagine that since there are real
amounts of effort across multiple groups
internally, not to mention concerns wrt
scalability of implementing this, the price
should be fairly steep.
However, if there is really a strong perceived value
for this, I would be very keen on seeing a
market develop.
Finally, I would note that a trend towards
large amounts of PA->PI conversion would
certainly bloat our competitor's routing
tables and those of some downstream customers,
which has real costs. I would expect (and even
hope) that this would lead either to the sort
of filtering we do now, or to some route-charging scheme, in
reasonably short order.
Sprint is in a relatively good position here,
since we already do protective filtering, and
would be receiving a revenue stream directly
associated with the increase in the amount of
routing information we'd be carrying.
Therefore, priced right, and assuming that
we don't run into impassable technical
limitations, any upgrading to new technology
that would be required would have been paid
for by the people forcing that requirement.
I would suggest that, far from indicating brain-damage
at Sprint, our addressing and aggregating policies are
rather clever.
You would have suggested that too, but you seem to be
far more keen on using terms like "brain damaged" and
"...other providers have discovered..." (a piece of
technology that was done for me) and "wise folk [should
not] buy from Sprint".
Perhaps some folk will buy from people who sell out their
engineering and operations background for quick bucks, but
I think that many others will realize that Sprint is not
out to make it hard for Sprint's customers to remain in
business (and spending more money on Sprint services
as their revenues increase), and in fact is working very
hard on preventing our customers from seeing a huge
explosion in routing table size that would be very costly
to them.
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.
Sean.