[ppml] Provider Independence???

Michael.Dillon at radianz.com Michael.Dillon at radianz.com
Tue Dec 7 11:17:33 EST 2004


> Is it possible to peer privately?

Why not?

> Is it possible to multihome to geographically diverse
> locations?

This costs money roughly proportional to
circuit miles. One would hope that when ARIN
determines the *ROUGH* boundaries for geographic
agreggation, they leave in reasonable possibilities
for separacy of connectivity. For instance the
the Sacramento region might extend as far west as
Walnut Creek on the edge of Berkeley. This isn't 
rocket science because people already do buy separacy,
especially in a city like Sacramento. By the way,
I'm borrowing the term separacy here from the 
SAN people to denote true diversity right down
to layer one with "separate" entrances into the
building. The desire for this kind of service is
generally what drives the demand for multihoming.
In any case, if people really feel a need to be
connected outside of a local geographic agreggate, they
can either buy connectivity in a neighboring region
and slightly inflate the regional routing table. 
Or they can do traditional multihoming with the
non-geographic v6 ranges currently on offer. Or
they can do some whiz-bang stuff with the output
of MULTI6. 

The point is that by giving people some choices we 
avoid the whole "swamp" thing. My definition of the
IPv4 swamp is that it is what results when the address
allocation rules do not offer the range of choices that
networks need. In the early IPv4 days, this lack of 
flexibility resulted in the swamp. In the v6 scenario
the details may be different. The v6 swamp may be ULAs
that swell up the global routing table because endsites
can't multihome in a local or regional way.

> Is it possible for an office to move to another location?

Not without doing a lot of work on the network infrastructure.
Renumbering is minor compared with the work of physically
moving everything.

> > because it will be part of the Western USA aggregate.
> 
> Where is this aggregation occurring?

Good question. I don't know yet and I think it
has to depend on the density of the population, i.e. the
number of households per LATA. Perhaps it occurs everywhere.
For instance, Sacramento and San Francisco are in the 
Northern California region. XPs located in both cities
have circuits going to Denver. They both announce the
Northern California agreggate to Denver as a matter
of course. Now, maybe 1 XP in Denver *WANTS* to see the
detail of Northern California. That's fine. On the other
hand if both San Francisco and Sacramento have circuits
to an XP in New York, I think it likely that they will
be satisfied with the default announcement of Northern
California.

Geographically organized addressing isn't about forcing
people into a single worldview of the v6 network. It's 
about creating the choices that allow people to build
a network where the logical topology more closely matches
the physical. And they can evolve into something that fits
best. The original geographical aggregation hierarchy that
ARIN creates will be a "best effort" and operators will
evolve within that framework. 

> If a single provider is connecting all those dealerships,
> then they don't have provider independence.  If by going
> to another provider we lose aggregation, what's the
> benefit?

I don't know. I didn't put this network out for bid. 
Maybe there is no benefit. That's the way things work
today, ARIN creates a framework but individuals inside
companies build networks in a lot of different ways. The
economy sorts things out eventually and shows us who is
doing the right thing. I want ARIN to create a geographic
addressing framework and apply for the correct size of
v6 address block to do this right, i.e. better than 50%
chance of only having to ask for one geographic allocation.
But it's up to the people in North America to build the
networks as they see fit, including the choice to not 
use geographic addressing and the choice to use geographic
addressing in dumb ways.

--Michael Dillon




More information about the ARIN-PPML mailing list