Paul,

On 2007-06-29 17:33, Paul Vixie wrote:
Brian E Carpenter <[EMAIL PROTECTED]>:

[vixie]
... and why are we wasting our keystrokes discussing this if there's a
preclusive topic being discussed somewhere entirely else?
I don't think it's preclusive. If that discussion does lead to an
architectural id/locator split, it will not override what we're discussing
here, IMHO. We'll still have IP addresses and they will still need to be
unambiguous. Also, that is a discussion that is finally happening after ten
years of needing to happen, so it's hardly surprising that it hasn't
converged rapidly.

ok.

I have a strong feeling there is no consensus forming...
[vixie]
i disagree, i've been immersed in this for a month now, and my draft edits
as proposed last night represent my understanding of a potential
consensus, which unlike you i can feel forming.
I personally am not part of it then. I don't want to see any structured
allocation scheme; a robotic guarantee of uniqueness is all I want to see.

i've been on the outside of ietf consensus more often than inside, so you've
got my sympathy if that matters.  also note, the fact that you don't agree
does not mean consensus isn't forming.

Absolutely. I know what "rough" means in "rough consensus".

as to your specific concern, i'm
interested in knowing more about why you want the robotic guaranty of
uniqueness to be the only feature.  others here have made compelling cases
for a larger feature set for ULA-C, and yet you are unmoved.  your words...

I don't want to facilitate making these things look like a binary hierarchy,
because that will cause people to believe for the next 50 years that they
aggregate and are routeable. I also don't want to accidentally create a
business in selling large integers, which would be the effect of structured
registration as opposed to robotic random numbers.

...involve a lot of unsupported predictions, and sound somewhat emotional.

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, 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. So I really
only see two kinds of IP prefix - those that aggregate and those that
don't. We need to encourage the former and discourage the latter (as
far as seeing them in BGP is concerned). 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.

i
don't think that we should deny others the features they're asking for on the
basis of what you don't want, especially since the things you say you don't
want aren't obviously inevitable, or obviously bad, to anybody else we've
heard from.

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? What's your estimate of the total number of ULA-C prefixes
needed?

If those numbers fit within reasonable guesses about sustainable
DFZ growth, no problem.

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to