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

[Matthew Petach]

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,
while at the same time showing good stewardship of the overall address
pool.  The policy cannot allow itself to be shaped by the least-capable
routers, or we'll be chaining ourselves to the past,unable to make adequate
forward progress so long as there's any network out there that's still
running
old hardware that's unwilling to upgrade.

I agree we need to be reasonable--but please, let's not "dumb down" the
v6 internet just because some people aren't willing to step up to the plate
and
upgrade their routers when needed.  Provider independence is here already,
period.  It's too late to try to put the horse back in the barn--what we
*can*
try to do is craft a well-thought-out policy 'bridle' for it, and then let
it start
running (to abuse a metaphor horribly).

Trying to stop provider independent addressing in IPv6 is simply another way
of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' --
because
that's what the practical outcome is.  Any addressing scheme that tries to
deny the need for provider independent addressing is less capable for
businesses than what they have today in the IPv4 world, and will therefore
not be used.


So.  Given that PI allocations are going to happen in IPv6 just as they have
in
IPv4, let's put all the rest of the grumbling about it aside, acknowledge
the
reality of the situation, and simply agree that as a starting point, issuing
a /48 out of a reserved /44 to each multi-homed,
non-transit-service-providing
network which applies and demonstrates it has met the requirements for
being multi-homed and obtaining its own AS, is reasonable--if adjustments to
the policy are needed, they can be applied in the future as needed, just as
we've done in the IPv4 world.

I *do* agree that stipulating that only the largest possible aggregate
assigned
to a given AS *should be* announced by the AS is a reasonable addition to
the policy to help encourage aggregation, and prevent stupid routing
mistakes
like this:
*  198.144.160.0/20 195.66.224.82                          0 4513 174 6983
8051 i
*  198.144.172.0    195.66.224.82                          0 4513 701 8051 i
(real-world example pulled from route-views; the /24 is announced by the
same originating AS, but is not connected to or directly reachable from the
network that announces the /20 aggregate, as was pointed out by the end-site
when their /24 more specific was filtered out at one point.)
That is, if you have discontiguous networks, they should each obtain their
own AS, and should pay the registration fees for that AS and the associated
IP aggregate which it will announce.

I don't see why the discussion is dragging out for so long.  This isn't
rocket
science.   Let's just nail the policy down, and move on with more productive
work.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060425/32262ad5/attachment.htm>