Talk:512k day

Recurring
Per Renesys and other technical outfits, this issue may be recurring, and the Verizon route event was a blip. Maybe move this to 512K routing problem ??? Cwolfsheep (talk) 23:25, 13 August 2014 (UTC)


 * I imagine that the 512Kday publicity should be enough to get all sysadmins to reconfigure their routers; remember, they just need to tweak them, not buy new. So it is perfectly possible that the issue will not reoccur. I say lets wait and see before any premature move in anticipation. Thue (talk) 23:48, 13 August 2014 (UTC)

If they reconfigure their TCAM to, say, 768k IPv4 routes, it will hold things off for a couple more years, and then things will start to get hairy. Not only is the IPv4 route table growing, but the size of the IPv6 routing table is steadily growing (20k-ish routes now, and rising rapidly, see http://bgp.potaroo.net/v6/as2.0/, and if memory serves me right, each IPv6 route takes two TCAM slots...) so they will start to be squeezed from both ends. Hopefully, they have a three-year core router refresh cycle... -- The Anome (talk) 15:56, 16 August 2014 (UTC)


 * The problem this time around was not that people couldn't do anything about the problem, it was that they were unaware of it. The problem is easy enough to solve - just buy routers with more TCAM. So now that network administrators are aware of the problem, there is little reason to believe why won't handle the problem in a timely fashion, transparently to end users. And remember, this is computer hardware subject to Moore's Law, so I would expect TCAM memory to fall in price much faster than the growth of the routing table. Thue (talk) 10:52, 17 August 2014 (UTC)


 * Network administrators are often not in a position to demand timely expenditure from higher management. 1M of installed TCAM is still quite enough for a couple of years if you set the allocation right, so it's not a big crisis yet: the problem is that once you run out of your remaining TCAM, there's pretty much nowhere to go from there, and that limit is approaching really fast relative to typical hardware refresh periods of three to five years or so. It's just possible that it might be possible to get away with 1M for the foreseeable future, if the IPv4 route table stops growing as IPv4 allocation finally runs out, instead of keeping on growing through address fragmentation, and the IPv6 routing table remains small and tight, instead of ballooning like the v4 table, and no-one finds any exciting new applications (geolocal routing?) that suddenly require vast numbers of IPv6 routes to be generated. But who knows? I wouldn't want to risk taking a chance on it. -- The Anome (talk) 11:58, 17 August 2014 (UTC)


 * The routing table growth is relatively smooth, so the point of failure will be reasonably predictable in advance. The coming problem will look like this: https://www.youtube.com/watch?v=OdctnPIR5kA . I can't of course guarantee that won't happen, but really seems unlikely. Anyway, complete speculation of future disasters due to e.g. geolocal routing seem unproductive in the Wikipedia context. Thue (talk) 14:21, 17 August 2014 (UTC)


 * Yes. Let's get back to building the encyclopedia... -- The Anome (talk) 20:01, 17 August 2014 (UTC)


 * There's ongoing discussion about ARIN policies that could easily cause a fairly sudden explosion of globally-routed prefixes. No-one involved can say with any certainty what will happen over the next 18 months as IPv4 resources are finally exhausted, but it's likely that several large netblocks will rapidly be de-aggregated.  A single /8 being de-aggregated into /16s (e.g. preparatory to resale) could cause an increase of 64k routes.  If policy remains constant, then yes, Thue is correct, but political & policy changes could change the landscape more rapidly than any network operator could predict.  "512k day" may become a more generic term than we'd like... athompso99 (talk) Athompso99 03:38, 20 December 2014 (UTC)