Brian Dickson wrote:
Brian E Carpenter wrote:
On 2007-09-19 08:26, Brian Dickson wrote:
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.
You may be mistaking the "where one gets some address space from",
with "this is the only address space you get" issue.
Multi-homed ISPs can reasonably be implemented with existing tools in
IPv6, although not necessarily as fully automated as one might like.
Having multiple prefixes and having hosts with multiple addresses is
expected to be the norm.
A small ISP should be happy being given PA space from multiple
upstream ISPs. The "multiple" means no lock-in and no need for hot-cut
renumbering.
A medium-sized ISP would likely have a small PI block for servers, and
multiple upstream PA blocks, where every client gets one IPv6 from
each upstream PA simultaneously.
I'd go to my nearest registry.
You would - but not *everyone* will. That's my point.
And, in many parts of the world, *you don't have that option*.
If you have two choices of Big ISP and neither will speak BGP to you,
you take what you can get.
If I was running a big enterprise, I'd also go straight to a
registry for my prefix.
Again, not everyone will. (And scalability of the DFZ necessarily
relies on that).
And also again, not all locations provide that kind of choice.
I'd also expect to flat route internally,
at least for a few hundred major sites. Aggregation isn't an
issue at that scale.
I think you miss the point of aggregation and allocation.
Aggregation isn't only done for the routing table size issues.
Routing performance similarly benefits or suffers by
order-of-magnitude scaling. Want to carry 20,000 /128's in your OSPF
cloud in area 0? Good luck on convergence times.
Organizational boundaries, cost centers, capacity planning, are all
centralized functions, that typically require corresponding control
over networking.
Whether the subdivision of enterprise space is done in a nice,
structured, hierarchical tree-like fashion, or in a mob-rule,
anarchy-like random fashion, the underlying need for multiple levels
of allocation is a reasonable expectation, for a big percentage of big
enterprises.
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.)
If every router on the Internet were being configured by "Brian C",
I'd agree with this viewpoint.
However, there are many, many organizations running networks, all
interconnecting. Not all are run by rocket scientists. Many are
outsourced to the local ISP.
Some of those relationships will fall within hierarchies of more than
two deep, in a PA assignment and re-assignment sense.
Having enough flexibility (or "stretch") in the PA->minimum allocation
sizes, is important to have those organizations be the tail that wags
the dog.
Er, this should read, "... *not* be the tail that wags the dog.".
Sorry.
Brian
The ability to "capture" as much growth as possible, within reserved
or allocated blocks (PI or PA), without requiring new DFZ slots on a
recurring basis, is the key goal.
Think of this "capture" as the equivalent of water-tight doors on a
large ship. It doesn't matter if *your* section has no water, and is
sealed nice and tight. If other sections start to overflow, the ship
will start to sink.
And, you *are* on the same ship as everyone else.
We can ignore the (potential) issue, or address it as early as we can.
I chose the latter.
Brian D
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
