Paul,
On 2007-07-02 18:53, Paul Vixie wrote:
Brian E Carpenter <[EMAIL PROTECTED]>:
OK, I didn't intend to be emotional there. Let me try to explain. Until
we get something fundamentally different from the routing researchers,
the only model we have is BGP4, ...
i've heard of alternatives but you're right that nothing else has caught on.
... and the only way we have to control the
growth in BGP4 table size and dynamics is aggregation. That's basic and
hasn't changed in 25 years. That's why CIDR saved us.
no. i don't have objective measurements, but i know that a lot of table size
control is achieved by limiting the horizon of announcements.
Absolutely. And from what I've heard, "a lot" may in fact be as much
as 90% for some ISPs.
ULA-C with my
proposed diffs is just a way to take this a lot further, to legitimize it, to
scale it up to planetary size.
And actually that is where we seem to be at odds. I fear that ULA-G will leak.
That's all.
there's been a fundamental misunderstanding in the acadamy as to what actually
happens in the field. ietf thought that the only connectivity that mattered
was universal connectivity, and fought firewalls and nat for a long while, but
ultimately firewalls and nat and RFC 1918 were all great things for the
internet even though they "violated" the universal connectivity assumptions.
for the record, table size only matters in the DFZ, and only because there are
too many third parties for the budget of any one of them to govern the size of
the table. away from the DFZ, table size is a self limiting problem, and no
questions of aggregation are even pertinent.
So I really only see two kinds of IP prefix - those that aggregate and those
that don't.
that's an extremely informative statement, thank you for sharing it.
We need to encourage the former and discourage the latter (as far as seeing
them in BGP is concerned).
if you mean by "BGP", the DFZ, then i'd agree with this statement in isolation
from the one that came before it.
Yes, I mean the DFZ - as above, I fully understand that there are already
vast numbers of private routes.
In today's jargon, that means encouraging PA, and limiting PI to a few
thousand users that really need it. ULA-C with structure as you propose is a
form of PI. I believe it will be perceived as an easy way to get PI space,
and the pressure to stick ULA-C prefixes of this kind in the DFZ will become
very hard to resist. I don't see that risk being anywhere near as high for
current ULAs or for centrally registered random ULAs.
harken back to the above where i referenced "many third parties". in the DFZ,
what matters is what the tier-1 providers do. they can afford 2-megaroute
forwarding machinery, they compete aggressively for end-sites against both
other tier-1's and all of the regional or value-add or low-cost tier-2's, and
they really like the PA concept because the renumbering penality gives them a
form of lock-in that even microsoft and apple can only dream about.
As an aside, that's why the normal model in IPv6 is for a user site to
run several PA prefixes simultaneously, and that's why we designed shim6.
if the
tier-1's decide to exchange ULA-C routes with each other, then the rest of the
internet has to do likewise. and if some really large cash cow of a customer
puts out an RFP to tier-1 saying "we'll buy bandwidth from whoever will route
our ULA-C into the internet core" then it'll be very interesting. is this
your proposed "pressure to stick" comes from? because i can think of a dozen
reasons why it can't happen, all based on business strategy and self-interests
of every single party involved in that money chain.
I hope you're right. My argument against structured ULA prefixes is only
to make it less likely to happen.
the competing visions as i understand them are "random-prefix ULA-C makes it
impossible to postprocess one's log files on computers outside the
connectivity realm where they were gathered, makes recourse against spammers
and ddos-for-hire crews even harder, and moves the hijacking problem from the
realm where RPKI can help some day to the realm of ``i got it from agnes''(*)"
I'm not sure I understand that, given that random ULA-C assignments would
be escrowed in some way, but it will clearly be *easier* to trace
ownership of structured ULA-Cs.
and "assigned-prefix ULA-C makes it likely that the PI/PA separation regime
will collapse, and take the internet down in flames."
I suspect that's an exagerration since this is a statistical game anyway,
but my concern is along that axis.
(*) http://www.lyricsdir.com/tom-lehrer-i-got-it-from-agnes-lyrics.html
I assume we all want the routing system to continue to scale at an
economically sustainable rate. Can you show that structured ULA-C will be
added to the DFZ at a sufficiently low rate that we won't get into
trouble?
i predict that structured ULA-C will enter the DFZ at the rate of zero, since
there will be an RFC which excuses anyone who wants to filter it out, and
since there will be many more champions whose livelihoods are threatened by
it than whose livlihoods could be enriched by it. (it's all about the money.)
This is the key point. If you're right, there is nothing to be concerned
about.
What's your estimate of the total number of ULA-C prefixes needed?
approximately one per family, worldwide, counting only the population who has
electric power. much much higher than the 2-megaroute level, or the number
of domain names registered in .COM and .DE (the two largest TLDs).
I don't get that. Customers need routeable prefixes. Why do you need
a ULA-C prefix for a customer?
Brian
If those numbers fit within reasonable guesses about sustainable
DFZ growth, no problem.
they don't fit, but they don't have to fit, because they're not going in.
--------------------------------------------------------------------
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
--------------------------------------------------------------------
