Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

[S.P.Zeidler]

Hi,

I'm not currently with a provider, so personally I'm only a very small
scale v6 op at present. :) Things that struck me but may be seen
differently by people with current operational experience:

Points 4+5:
"People should just get PA from one of their providers when they want to
multihome, and talk them into allowing other providers to announce it"

been there, done that, finally got over it. Anyone not seeing that as a
dead horse?

Also, how does a PA /48 that gets announced more specific have a smaller
impact on the routing tables than a PI /48? even the provider it's PA to
must announce it more specific or have to accept being the loser in
routing decisions because more specific has to win (and in all traffic
accounted contracts, that idea will not sit well).
Aggregating this at a higher tier would require checking that there
didn't exist any announcement through a non-customer and de-aggregating
as soon as one was seen; I'm not sure the collective computational load
for that would be so much lower than just announcing the prefix.

Next:
The analysis in point 6 looks bogus to me.

point one (rephrased a lot):
"If v6 ASes grow by 54% now, it will continue to grow by at least 50%.
It is not existing v4 ASes adding v6 and being naturally limited by all
current v4 ASes having added the one v6 prefix necessary to survive,
after which point the growth rate will drop drastically to the yearly
growth rate in ASes we see in v4 now".
Obviously, we are in a flood fill period that is rather not
representative for the long run.

point two (also rephrased):
"If you only have one upstream in v6 at present you are likely an end user
who never will have more than one upstream and could as well use PA"

That's an assertion that thoroughly underestimates both getting
the upstreams one has for v4 to provide v6, and introduction periods
where one irons out the kinks and learns the ropes with one friendly
and knowledgeable upstream before tackling v6 with the rest of the
upstream zoo.

Could someone with a grab on current data do a comparison of what the ASes
that are recognized as stubs in v6 do in v4, please, just to replace
guessing (either way) with information?

Overall document:
Given that even huge ASes will only originate a small number of
prefixes in v6 compared to dozens to hundreds in v4 now, what problem
exactly is this trying to fix?
As long as getting PI space is bound to getting or having an AS I don't
really see the scaling problem.
Running an AS requires the necessary routers, time by skilled engineers
(even most IT workers only have a very vague idea how networking works
and are definitely not able to set up BGP; you can contract the service
but that costs money), and the usually more expensive upstream contracts
that allow BGP sessions.
Businesses tend to be able to do the math and decide that a server or
two in housing and two independently numbered upstreams are way cheaper;
if they serve their needs as well, they will pick that option.
The danger of every corner shop in the world trying to get PI is not
actually there IMHO.

Comments to my comments?

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)