[ppml] [address-policy-wg] Those pesky ULAs again

[Stephen Sprunk]

Thus spake "Roger Jørgensen" <roger at jorgensen.no>
> On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote:
>> On 27-mei-2007, at 22:51, Stephen Sprunk wrote:
>>> The vast majority of folks will be fine with ULA-L
>>
>> Most people aren't very good with statistics, knowing for sure
>> you have unique space is better than having just a 99.9999%
>> probability that it's unique.
>
> not really, I work a place where we just can´t have any more
> collision of address space, we have a few options and ULA-
> central is the best.
>
> 1.) get ula-central and know for sure we won´t get into this
> issue ever again.

Unless the central administrator(s) screw up.  The odds of that are 
non-zero, you know; in fact, as long as there's humans involved it's safe to 
say the odds are higher than a ULA-L collision.

> 2.) administrate our own local version of ULA-central for
> the organization we co-operate with

Which is basically ULA-L, except that when someone new wants to join your 
private club, you'll need to spend a few seconds making sure they don't 
collide, and if they do (which is statistically unlikely, unless your club 
is on the scale of the public Internet) they'll need to renumber before they 
can join.

> 3.) get RIR-space with all the add on administration and
> documentation...

The documentation is minimal unless you need a block larger than the minimum 
size, and the administration would be the same either way.

> For me, only option 1.) is a real option, the other two are just
> work-around since we don´t need global routing of the address
> space in question.

No, you've decided #1 is what you want, so you're downplaying its problems 
and potential harm to the community and criticizing all other options.

>>> (or PA) space
>>
>> PA or PI is irrelevant to this discussion, people who need ULA
>> may not even connect to the internet, and if they do, they need
>> this space in ADDITION to routable address space, regardless
>> of the type.
>
> this go for the type of organization I work for. We have our own
> /32 already and it suite our need for public address space just
> fine given the 3 options above.

So why not carve out a /48, block it at your firewall to the public network, 
and get "local" addresses for free instead of paying for ULA-C?

> ULA-central will satisfy a need for non-routable address space
> that some bigger organization have. ULA-local are just a no go
> even with a 99,99999% chance of no collision at all. Or to put it
> in another context, renumbering or any change, experimentation
> or downtime of the infrastructure are just not an option when
> we´re talking about medicial/health related equipment.

If you're in the medical field and your equipment can't withstand a few 
seconds of outage here and there (six nines = 31sec/yr downtime) without 
killing someone, you're going to have a lot of dead people on your hands. 
You and/or your vendors have failed.

Networks have outages, period.  In a typical network, most of them will be 
hardware-, circuit-, or design-related.  I participated in a project for 
$BIG_TELCO and it took them several years of effort just to get from three 
nines to five nines consistently, and they never hit six nines.  Nearly all 
of the remaining issues, when we were done, were due to humans making typos. 
If you think you're going to get to six (or more) nines of reliability, 
you're delusional in thinking that you're better at this than people 
literally throwing billions of dollars and thousands of engineers at the 
problem.

Besides, renumbering should not cause any outages (at least more than what 
you normally see) unless your staff is incompetent.  It's a lot of work, but 
it shouldn't cause an outage, much less death.

>>> so the debate comes down to why we want to put orgs on
>>> ULA-C space instead of just giving them PI space.
>>
>> No-brainer: ULA-C space doesn't use up routing table slots.
>
> see above, PI or PA have nothing todo in the discussion of
> ULA-C or not.

Yes, it does.  If an org needs unique address space that will never appear 
in the DFZ, how does ULA-C meet their needs any better than PI?  What is the 
purpose in creating yet another thing that needs to be registered when we 
already have two alternatives that fit every need I've seen proposed so far?

> Site-local, the one that got deprecated would have suited OUR
> (where I work) just fine but it isn´t there so we need a
> replacement and ULA-C is what we would need.

If SLAs would have worked for you, then you have no fundamental need for 
unique addresses and ULA-Ls are overkill, much less ULA-C.

>>> If they're truly going to use it privately, they won't consume
>>> routing slots in the DFZ, and if they aren't they'll be using PIv6
>>> anyways and won't have a need for ULA-C.
>>
>> You are being ridiculous. There is no connection between
>> ULA-C and PI. Everyone can get ULA, not everyone can get PI.

Anyone who is large enough to care about the extreme unlikelihood of 
collisions with ULA-L will be able to get PI, at least in ARIN's region. 
The bar is incredibly low; just about the only folks who don't qualify are 
people running home networks.  And, for that matter, people can get a single 
PI block larger than /48, whereas someone who needs more than a /48 in ULA-C 
space would need multiple distinct blocks, presumably multiplying the fees 
to more than what PI costs.

If your argument is that ULA-C will be cheaper, that is perhaps an argument 
that PI fees are too high -- not that anyone has stated if or how much 
cheaper ULA-C would be if it did pass.  I have a hard time seeing anyone who 
has a legitimate need for ULA-C _or_ PI space whining about $100/yr.  If 
they can't afford that, they can't afford anyone knowledgeable enough to 
care about the problems with ULA-L (or PA) space.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov