Re: Regionally aggregatable address space for multihoming

[Sean Doran <smd@ebone.net>]

"Tony Hain" <alh-ietf@tndh.net> writes:

Tony, thanks for the first rev of a draft!  I have some
comments and questions that I hope may help improve it.

> sites that connect to metropolitan scale exchanges. 

Do such exchanges exist?  I'm curious, since I haven't run into any,
even in Stockholm, where fibre is very close to free.

> Sites will have the choice to connect to either type of
> aggregation entity.

Can sites connect to both?  If no, is that a feature or a drawback?

> Any provider announcing a short prefix SHOULD be able to
> deliver packets to anywhere in the region, either
> directly or through other arrangements.  In the case
> where a service provider does not interconnect with
> others in its region it MUST advertise the longer
> prefixes associated with its customers.

What if the provider is connected and fully peered with
all the other networks using addresses from the same
aggregate, but is partitioned from some or all of them for
a period of time?

(An interesting thinking exercise is trying to figure out
how networks multihomed at other geographical exchanges,
and having multiple transit arrangements across those
exchanges, can determine which long-haul provider should
be used to reach a network that is ordinarily abstracted
behind an aggregate covering all the networks in a given
geographical area/surrounding a given IX.  You have
discovered one of the hard questions already, viz.:

> Another issue is the business model being flipped from
> the current destination's ISP choice determines sources
> routing; to one of source's ISP choice determines at
> least its first hop.

In other words, "how does the source make a correct
choice of next-hop?".

Let us know what you come up with, or if someone else has
properly solved this á la GSE or Ohta-multi-prefix.)

> This address allocation mechanism SHOULD NOT be used on a dial access
> network pop, as scaling routes to sites attached this way are best addressed
> through provider based allocations consistent with Aggregatable [RFC 2374].

Why not?  

How do multihoming entities who offer both fixed-line and dial access
accomodate this?

How far does this reach?  Does this include a dialup pool
in a site singly-connected to a provider?

> for layer-3 exchanges to work there has to be a way to do source routing
> within a region to select ixc : rest of the system dst based routing
>         simple directory lookup on flat 48 bit site id
>         if so lec would dest route within region / src route to ixc
>         ixc would dest route to next region
>         dest lec would dest route within region

IXC and LEC are Americanisms, and moreover are an artefact
of a regulatory regime which is NOT global.  It's probably
a good idea to avoid terms like these in a document which
is designed to work for the whole Internet.  :-)

- --

If a large U.S. network has a number of peers and
paying transit customers in W. Europe (for example),
and each of these networks have customers that are using
both provider-assigned and IX-assigned addresses,
how should large U.S. network decide which of the
customers to send traffic to, if they are announcing only
an aggregate of:

> W. Europe               080000  :  000000  ->   1080:0000:0000

or

> LHR -    51.47 n    0.350 w             13B7:3B48:4D42

?

Does your apparent (post hoc) answer:

> Routing protocol should only announce a short prefix if the router can get
> to the entire concatenation, if not it will need to announce specifics.

mean that the U.S. network's x-Atlantic customers must
announce the individual customer prefixes learned at the
LHR exchange, and not announce the aggregate for LHR or
for W. Europe?

If this U.S. network has several competitors for transit
sold to networks across the Atlantic, as is the case today,
what becomes of the idea of announcing 1080:0000:0000 to anywhere?

(Think of what they would do to be able to announce 1080:0000:0000 to 
        -- competitors with no European customers
        -- customers who are multihomed to competitors
           with European customers
        -- customers who are multihomed to European networks
        -- customers who ARE European networks, but who
           operate in only one part of W. Europe
        etc.
Then think of what happens when the connectivity to one or more of
their trans-Atlantic customers fails.  This happens sometimes...)

BTW, if you are doing updates to your draft, this is not
very draft-y-language:  :-)
> Since 20 bits is nominally what tier-1's do today
> on a global scale I don't think this is out of line for scale or
> performance, and it bounds the problem to the set of providers where the
> multi-homing occurs.

        Sean.