Customer AS

Sat Aug 17 21:29:52 UTC 1996

-----BEGIN PGP SIGNED MESSAGE-----

randy at 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.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey

iQCVAwUBMhY5tkSWYarrFs6xAQFS6gP/QXwPBUi6yp7xxitG9Pca3OFBiyDos7IY
4A2vBKQHW85dveEp9a1Qd0YSITWfaSImr5qhryENCDwTPMVIkWDIKM12wz+7Bxhs
aX8kYTNMr44o1p5P2alRWMxHydoZtWfMJLMPLxAFD5U30j+yUPyJArCz5uvolZTK
r+Vhnd65h2M=
=6hUy
-----END PGP SIGNATURE-----