From: Iljitsch van Beijnum (no email)
Date: Sun Mar 05 2006 - 17:12:56 EST
On 5-mrt-2006, at 17:37, Christopher L. Morrow wrote:
>> The solution is routing based on geography: give every city of ~ 250k
>> people a /32, and give people who multihome in or near that city a /
>> 48 out of that /32.
> can the v6 table/space work with 6B /48's?
It can if you distribute those 6G prefixes over 6k - 64k routers, so
each only has to carry 100k - 1M of those prefixes.
Our approximate design goal was 1 multihomers per 10 people in the
year 2050. That would be around one billion mulithomers. Today we
don't see much more than 1 in 25000 in parts of the world where
multihoming is popular, and in most places it isn't.
> Additionally, how many /32's are
> there? Does scaling that to each municipality make sense? the
> arbitrary (I
> suspect) 250k person limit will quickly devolve into 'any
> municipality'
> with much less restriction on it.
The idea was having 64k /32s holding 64k /48s each. That means you'll
end up with a /32 for each area with around 250k people. Having
aggregation below that level doesn't look worthwhile and the number
of municipal /32s would become uncomfortably large.
Of course people living in small towns aren't left in the cold, it's
just that they have to share a /32 with other small towns, the
surrounding rural area or fall under a big city close by.
>> 48s that are filtered here are still known. Since every AS still has
>> all the /48s somewhere within the AS, this works without strange
>> requirements such as free transit or interconnection in every city.
> I think I'm missing how this would work... if I don't have a route
> to you
> you don't exist.
That's the beauty of aggregation. As an example, your AS could have
US routes split into two sets: east of the Mississippi and west of
the Mississippi. If you then want to send a packet from Boston to a
multihomer in San Diego, the routers in Boston don't carry the /48
for that San Diego multihomer. But there is an aggregate for San
Diego, so the packet is sent on its way with help from the aggregate.
When the packet hits the first router west of the Mississippi, it is
forwarded as per the actual /48.
> inside a single ASN aggregation may be workable. On the entire network
> it's going to be much more complex :(
As long as each AS carries its customer routers everywhere and
announces them to other ASes everywhere, there is no need to
coordinate, because the outward behavior of each AS is as before. The
only difference is that internally, things happen slightly differently.
>> Obviously strange ways of multihoming (towards ISPs on different
>> continents, for instance) or strange ways of interconnecting (such as
> ah, like pipex or vnsl or ... name your extra-us provider of
> choice. From
> the 'non-NAnog' perspective, what about US carriers in ASPAC that
> multihome to several pacific island nations at once?
Not sure what you mean, but suppose there is an island in the pacific
where several US carriers land, but they don't interconnect there.
Also suppose that carrier 1 links this island to LA and carrier 2 to
Palo Alto. A packet from a customer of carrier 1 to a customer of
carrier 2 will flow to LA because the /32 for the island points to LA
(not to the island itself because there is no interconnection there).
Carrier 2 doesn't have the full set of more specifics for the island
in LA (they have those in Palo Alto) but they DO have all their
customer routes in LA, so carrier 1 hears the /48 for carrier 2's
customer in LA and hands the packet off to carrier 2, which
transports it to Palo Alto and on to the island. Return packets will
flow from carrier 2 to carrier 1 in Palo Alto.
>> two European networks interconnecting in Chicago) aren't very
>> compatible with geographic aggregation, but who cares about 10%
>> exceptions as long as you can aggregate the other 90%. Enterprises
> is it 10%? did you measure this?
No. The only thing that we can possibly measure is what's in place
today, and that's not representative for a situation where we have
more than a million multihomers. However, it is to be expected that
when we reach the point where there are that many multihomers, there
will be some reason to the way multihomers connect to their ISPs. I
would expect that the vast majority connects to local or regional
ISPs. Even if they don't, it's not going to be that 5% of Paris
multihomers connects to Montana, another 5% to Cape Town, 5% to Aruba
and so on. If they do at the point that geographical aggregation
takes off, they'll find that their traffic takes detours, i.e. a
packet from Montana to Paris will first flow to Paris as per the
aggregate, then go to the multihomer's ISP, then to Montana where the
multihomer connects and finally back to Paris. So they'll have an
incentive to multihome to ISPs closer to home but doing that wouldn't
be too painful because they don't have to renumber if they used a
Paris prefix from the start.
|
|
|