[ppml] NANOG IPv4 Exhaustion BoF

Randy Bush randy at psg.com
Fri Mar 7 16:52:31 EST 2008

> I agree that TE deaggregates will be first to be filtered

and intentional de-aggs that are not even TE

> but I think it's important that any policy we put in place doesn't
> create a whole bunch more small unique routes covering end-sites.

oh?  what if those are legitimate users and new entrants who need unique
routing because they are multi-homed or whatever?  somehow i do not
think that intentionally preventing them by policy is going to stand up
for very long.

ipv6 and nat-pt (or whatever the tvtf calls it to save face) or massive
ipv4/ipv4 nat, whichever way it goes (or it goes both ways!) is gonna
cause many *legitimate* small prefixes to be injected in slowly
increasing numbers.  get over it.

this is simply what happens when ostriches pretend there is no need for
architectural change in routing given a world where the scale is
ever-increasing.  the result is you need to handle more routes.  <doh>

this is far from new.  welcome to the new line card every year club.
what is needed is not policy preventing entrants into the market, but
rather router vendors to supply routers that can carry the load.

and you can push it out a few years by beating on the vendors to give us
knobs to stomp non-product deagg.  i have cases filed with j & c for
years, and a mailbox of excuses to match.

or you can go down the path of lisp.  watch out, on the third step there
is a sign "magic will happen here".  but at least dino is working on the
problem a opposed to blowing glossy paper at us.

or you can go down the path of multi-natting from PA space with a policy
of giving all the PI space to the largest providers.  and if you think
you can do the latter without having to explain it all to lawyers and
politicians (which may not be a bad thing.  it can't be all that much
harder than explaining it to amateur policy-making friends, and it sure
will be more effective), please share what you are smoking.


More information about the ARIN-PPML mailing list