non-provider aggregation, was: IPv6 news
Paul Jakma
paul at clubi.ie
Thu Oct 20 01:00:05 UTC 2005
Hi,
On Wed, 19 Oct 2005, Iljitsch van Beijnum wrote:
> On 17-okt-2005, at 14:18, Jeroen Massar wrote:
>
>>>> Another alternative is to force-align allocation and topology in some
>>>> way /other/ than by "Providers" (geographical allocation in whatever
>>>> hierarchy, IX allocation, whatever), such that networks were easily
>>>> aggregatable. Lots of objections though (the "providers and geography
>>>> don't align" one though is ultimately slightly bogus, because with
>>>> non-provider-aligned allocation policies in place it would be in
>>>> providers interests to align their peering to match the allocation
>>>> policy).
Iljitsch, fix your attributions, that's my text. (Jeroen might not
appreciate you attributing my incoherent mumblings to him).
> The current assumption is that all aggregation happens on ISP.
> Replacing that with the assumption that all aggregation will happen
> on geography isn't all that useful.
That's a bold assertion. You'll have to show why because the fact is
that that is how other networks achieve portability (after which
multi-homing is easy). Fact is I can change my fixed phone provider
and my mobile phone provider, but I can't change my ISP without some
pain (and I'm a /tiny/ site ;) ).
> The important thing here is that you can aggregate on pretty much
> anything: hair color, router vendor, market capitalization, you
> name it.
Hmm, no ;).
> In the end, you always aggregate on the way the addresses
> are given out, which may or may not be meaningful.
No, you have to aggregate on topology.
> Aggregating on provider is the most powerful because the aggregate
> leads you fairly directly to the place where you need to go as long
> as the destination is single homed.
Sure. But it means you're tied to the provider (for that address at
least).
> interconnect within the city itself. So someone sitting in New York
> probably won't see much difference: he or she still has to carry
> all the routes for multihomers in Boston. Some of these will point
> to her own customers in Boston, some to peers in New York, others
> to peers in DC, and so on.
But at least, to the rest of the world, all the multihomers in Boston
and New York have reduced down to just 2 routes. That's a significant
step forward.
(And eventually those ISPs back-hauling lots of very specific Boston
customer prefixes to New York will figure out they should just peer
in Boston and confine the very specific Boston routes there).
> limitations. An important one is that early exit routing is
> replaced by late exit routing.
Can you expand on this?
> Also, when someone multihomes by connecting to ISPs in Miami and
> Tokyo you don't get to aggregate.
Or, that entity just gets two prefixes, one for its Miami site
allocated from the Miami area prefix and one for its Tokyo site
allocated from the Tokyo area prefix.
Really large networks with their own internal-transit across
multiple areas for whom this would not work can just get a global
prefix. But those kinds of networks are rare, a fraction of
multi-homers.
So it's still a step forward.
> really sparse the savings go up again) so you're no worse off than
> today.
You're better off, because small/medium sites can be aggregated with
all the other small/medium sites in their $AREA. The really large
trans-$AREA networks are rare.
Let's be honest, the reasons that make $AREA-allocated addresses and
aggregation difficult are /not/ technical. ;)
> (Paul Jakma wrote something to the effect that I am involved with
> shim6 so that says something about other options. It doesn't, as
> far as I'm concerned. But shim6 is a worthy pursuit in its own
> right.)
I said "possibly is telling" ;). But apologies for any presumption
;).
regards,
--
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
Fortune:
fortune: not found
More information about the NANOG
mailing list