APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists global-v6 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Matthew Petach wrote:

On 4/24/06, Pekka Savola <pekkas@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...


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.


That is not the concern. The concern is the a BGP4 system with potentially
millions of routes will be unable to converge. That's a scaling issue that
is independent of specific router technologies. Thus, we have to add a
constraint on top of stewardship of the address pool: stewardship of the
size of the route table such that it is mathematically and physically
able to converge. To my mind, that doesn't rule out PI space for some number
of thousands of large sites, but it definitely rules it out for some number
of millions of sites, unless some radically new mechanisms are put in place.


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


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.

     Brian



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



------------------------------------------------------------------------

_______________________________________________
global-v6 mailing list
global-v6@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/global-v6