[ppml] [GLOBAL-V6] Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive

[Matthew Petach]

(apologies for the earlier html-mail; I had failed to notice
gmail had toggled my default away from plain text)

On 4/28/06, Brian E Carpenter <brc at zurich.ibm.com> wrote:
> Matthew Petach wrote:
> > On 4/24/06, Pekka Savola <pekkas at netcore.fi> wrote:
> >
> >>Hi,
> >>
> >>On Fri, 21 Apr 2006, Ruchti, Marcus wrote:
> >>
> >>>I don't think flapping routes will increase due to the assignments
> >>>of PI space, as in the most cases ISP's are requesting those for
> >>>customers and offers managed multihoming solutions. So announcing
> >>>these routes into BGP is the responsibility of an ISP.
> >>
> >>First off: there has been some discussion whether 200K routes is a
> >>problem or not.  If the numbers stayed at that level (how can we
> >>ensure that?), that wouldn't be a huge problem.  Bigger one is
> >>dynamicity.  Huston's study indicated that there are folks whose BGP
> >>announcements flap (due to TE) intentionally 1000's of times a day.
> >>Multiply that by the number of sites (and add sBGP or friends to the
> >>stew) and you may start thinking that your DFZ router might have
> >>better things to do than process that cruft.
> >
> > BGP flap dampening is already well understood for limiting the impact
> > of flapping routes on your CPU, if that's a concern; it has no bearing
> > on address allocation policy decisionmaking.  And configuring dampening
> > is up to each _recipient_ network, and is not something that should be
> > codified
> > into an address allocation policy, which is targetted at the _originating_
> > network.
> >
> > Let's stick to the topic at hand, which is how to craft a useful address
> > allocation policy which allows for provider indepent address allocations,
>
> Matt, note that you are begging the question there. You're *assuming* that
> the answer to the underlying problem is PI addressing. But let's use
> that assumption for now...

I'm speaking as a businessperson, and pointing out that PI
addressing is a requirement for large businesses connecting
to the Internet today.  If we don't provide a way for those
entities to connect in a way that does not tie them to their
upstream providers in IPv6, they won't use IPv6--they'll use
IPv4, where they can connect in a provider independent
fashion.

You say I'm "assuming" the answer is PI addressing; I'm pointing
out that the *reality* of the situation is that PI addressing exists in
IPv4, and has become a business requirement.  If we don't address
that requirement within the IPv6 policy, businesses won't migrate to
IPv6.  This isn't an assumption--this is the reality of the internet as
it exists today.

> Correct, in my personal view. So the policies put in place need to auto-limit
> PI space at the level of thousands rather than millions of sites. Prudent
> stewardship seems to call for that.

Except that processor capabilities are increasing year over year; so while
the limit today may be in the hundreds of thousands, in a few years it will
be capable of supporting millions of sites; are you proposing that we keep
updating the address allocation policy each year, to account for the increases
in processor capabilities?  Otherwise we really will be limiting the growth of
the internet based on the slowest/most limited hardware in place, rather
than letting it grow at the natural pace the market will support.

I guess at this point, we've cast our votes in our respective directions; I've
cast my vote in favour of 2005-1, as I think it's important to aim for the
future and stimulate growth; you're free to vote against it, and look to the
past, limiting the growth of the internet based on fears that routing
hardware won't continue to scale to meet demands.  It's up to the AC
now to take our votes and decide what to do with them.

>       Brian

Matt