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