[ppml] NANOG IPv4 Exhaustion BoF
Scott Leibrand
sleibrand at internap.com
Fri Mar 7 16:56:50 EST 2008
- Previous message: [ppml] NANOG IPv4 Exhaustion BoF
- Next message: [ppml] NANOG IPv4 Exhaustion BoF
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
My own proposal is not to slow down the rate of new entrants who need routing slots to multihome. The number of those is growing, but IMO is still manageable. Rather, I want to help prevent the unnecessary addition of multiple non-aggregatable routes per ASN, i.e. by requiring that transferees get 6-12+ months worth of IP space at a time, rather than allowing them to pick up multiple smaller blocks one by one. -Scott Randy Bush wrote: >> 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. > > randy
- Previous message: [ppml] NANOG IPv4 Exhaustion BoF
- Next message: [ppml] NANOG IPv4 Exhaustion BoF
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list