|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: non-provider aggregation, was: IPv6 news
Hi, On Wed, 19 Oct 2005, Iljitsch van Beijnum wrote: Iljitsch, fix your attributions, that's my text. (Jeroen might not appreciate you attributing my incoherent mumblings to him).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). 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 [email protected] [email protected] Key ID: 64A2FF6A Fortune: fortune: not found
|