If you have neatly solved the problem of undetectable route flutter, whereby something distant from your similarly-numbered machines causes datagrams destined for those machines to flip among several of them at intervals (particularly relatively short intervals) then I think that would be worthy of a talk almost anywhere.

Yep, figured that part out. Alec's approach basically avoids the stated problem by using a DNS solution, but we've figured out the route flutter problem, though it does assume you have a network of your own (even if tunneled between two points).

Moreover, if you can generalize the "slick" solution into moving traffic by choice from one of your similarly- numbered machines to another (thinking of reboots & backups, server-driven load balancing and the like) independent of service (although you could require it to be a NAT-friendly service, I guess) then that might make a trip to Phoenix worthwhile.

It won't allow TCP sessions to survive a machine going down, but since each box runs gated, advertising its own /32 into your IGP, presumably the box's have to be pretty sick to keep advertising its route yet be unable to serve web pages. The solution guarantees that a TCP session won't be RST by a remote box getting a packet from some other TCP session to a duplicate-numbered box, but you will, of course, have extra latency to transmit the packets that come in at the "wrong place" to the "right place". I had initially postulated a TCP-session-dying approach with a central database that got updated with enough info to reconstruct a TCP session ({url, offset, port #s, seq #s, ...}) but that's quite complicated, obviously, and not necessary to just solve the route flutter problem.

Sean.

Since I'm doing the pre-NANOG tutorial thing, I was planning on going to Phoenix anyway, though... Rather than describe the approach in detail now I figure it'd be more fun to have people heckle me live @ NANOG :) Avi