On 2007-09-19 08:26, Brian Dickson wrote:
Brian E Carpenter wrote:
On 2007-09-18 19:24, [EMAIL PROTECTED] wrote:
...
This becomes important when we consider non-trivial hierarchies of
allocations, such as RIR->LIR->ISP, where internally further allocations
are made for internal aggregation purposes.
Having that many layers of allocation hierarchy is an artificial
choice, and the aggregation argument only applies *within* a
single ISP's allocation. If we had flat allocation from IANA
to ISPs, your argument would go away. So assuming we keep the
artificial choice of allocation via RIRs and LIRs, that simply has
to work in a way that emulates flat allocation.
Okay, bad choice of terminology (not mine, theirs, really).
To make it clearer, let's use a reasonable example:
RIR -> Big (Tier-1/2) ISP -> small ISP -> big enterprise -> enterprise
site -> enterprise LAN
If I was running a small ISP, there is no way I would
accept being forcibly aggregated under one specific Big ISP.
I'd go to my nearest registry.
If I was running a big enterprise, I'd also go straight to a
registry for my prefix. I'd also expect to flat route internally,
at least for a few hundred major sites. Aggregation isn't an
issue at that scale.
Basically I don't think we need that many layers of hierarchy to keep
the IGP and EGP routing tables to a practical size. (That's why
we abolished the TLA/NLA split in the address architecture.)
Brian C
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
