RE: (multi6) requirements draft comments

["Tony Hain" <alh-ietf@tndh.net>]

J. Noel Chiappa wrote:

> I must confess I've only been listening to this exchange with
> half of one
> ear, so perhaps I've missed something, but I'm wondering what
> your proposed
> better mousetrap is (since you don't like this one).

The primary problem is assuming there exists a one-size-fits-all
solution to the multi-facetted routing problem. We are currently
restricted to a one-size-fits-all routing protocol, so I believe we need
to allow another variable to change if we expect to meet the needs of
different sites.

> Sure, supporting multi-homing in the routing works for a few
> sites, but if
> (say) 30% of all homes are multi-homed (to produce a nice big
> user base), and
> want open connections to stay up when the "primary" link
> fails (the most
> technically aggressive case), then trying to do it in the
> routing just isn't
> going to fly, at least without a fairly radical routing-name
> allocation
> system

Actually the problem of maintaining connections is the easier one
technically, but the solution doesn't sit well with some incumbent
operators. The problem is handling the large sites that expect to be
able to engineer traffic flows, where the definition of that kind of
site needs to be crisp enough for the registries to distinguish it from
a home or a service provider.

As far as radical routing-name allocation system's go, several people on
this list consider my proposal draft-hain-ipv6-pi-addr-01.txt &
draft-hain-ipv6-pi-addr-use-01.txt in that catagory, but I just consider
it to be an overlay that complements the current scheme.

> Still, a address aggregation hierarchy which did work with
> large numbers of
> multihomed sites would probably do things like group me and
> my neighours who
> have CATV into one fairly low-level entity - and assign
> *both* the CATV and
> DSL links a single fairly-low-level routing-name - which
> probably wouldn't
> sit well with the relevant companies.

This is fundamentally what I am suggesting, and it is being received
about as well as you have expected. To a first order, the bit pattern
really doesn't matter, it is the architectural concept that service
providers need to share customer access that is the stumbling block.
Since this is diametrically opposed to their business model the number
of possible technical solutions approaches 0 very quickly.

> So, perhaps there is no routing solution, even with an
> aggressive, and fully
> automatic, routing-name allocation.

At least no single one.

> So if you can't cram it into the routing that way, you're
> pretty much back to
> the "you have two routing-names (i.e. addresses)" approach,
> with all that
> implies.

I agree, but it really is a function of site goals as to which of the N
routing-names it wants to use for any particular application. It is
certainly reasonable for things which need to survive provider failures
to be in an independent address space, but if that is not a site
requirement, using N instances of PA space scales better in the routing
complex because it moves the scaling issue to the edge.

Tony