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

[Brian E Carpenter]

Just commenting on a few points, and cross-posting in
response to Fred's request:

On 2010-09-25 22:35, S.P.Zeidler wrote:
> 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? 

It doesn't. The effect is exactly the same, for all practical
purposes. This emperor has no clothes.

As we have known for many years, it's only if multihoming is
achieved by running a different PA prefix for each provider that we
don't blow out the BGP4 table. Hence RFC3582, RFC4177, shim6, ILNP,
LISP and a host of other work (see draft-irtf-rrg-recommendation).

> 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.

Well, if every active AS that announces IPv4 prefix(es) today also
announced IPv6 prefix(es), guess what, we'd have about 35,000 active
ASes announcing IPv6 prefixes. That doesn't really matter; the question
is whether we would also have 330,000 IPv6 prefixes, or significantly
fewer, and how these numbers will evolve in future. And that, truly,
I cannot guess.

> 
> 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.

Not to mention the expected increase in multihoming in the future.

> 
> 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?

Data are always nice, and I suspect that these data are available
at potaroo.net, but actually, I would hesitate to extrapolate from
the early-adopter IPv6 deployment today.

> 
> 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?

That depends entirely on user sites and ISPs following good (CIDR-like)
practice. So I think encouraging that is the useful goal of this draft.

> As long as getting PI space is bound to getting or having an AS I don't
> really see the scaling problem.

Well, unless it encourages a gold rush on AS numbers.

> 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.

I really hope you're correct. But if word gets around the world of
CIOs that the thing to do is get your own AS and a PI prefix,
then you can't be sure that sanity will prevail. And frankly,
site managers that I've talked to are puzzled and worried by the
prospect of running several simultaneous PA prefixes, and having
to renumber when they add or drop an ISP. See RFC 5887.

> The danger of every corner shop in the world trying to get PI is not
> actually there IMHO.

Again, I hope you're correct, but why not document the fact that it's
highly undesirable?

   Brian

> 
> Comments to my comments?
> 
> regards,
> 	spz