Beer? Sushi? Beer? I'm in.
As Miguel noted, we at Earthlink/Mindspring/OneMain continue our ongoing
AS integrations(we have over 30). A few additional gotcha's and
benefits that come to mind you might want to consider include better IP
space utilization, elimination of backdoor routes, radb updates, use of
NSSA/TSA, peering benefits, and the use of 'local-as' options.
The more efficient use of IP space and peering benefits were some of the
technical drivers behind my desire to take on this project. I hadn't
really looked too closely at the local-as options, but I will certainly do
some more research...
IP space utilization can be benefited by consolidating IP space into
larger and more useful aggregates. Which also results in better
announcements, and a happier NANOG community :).
I've been doing this in the AS that would be kept after the migration for
some time. ARIN has been receptive to my requests to keep future
allocations contiguous where possible to make my announcements as
efficient as they can be. Most of the IP space in the other networks is
provider-assigned in bite-sized pieces. I plan to replace that with CIDR
space as the opportunity permits itself.
Backdoor routes based on the integrated AS's, if currently used, become
obsolete. A minor detail.
We're using backdoor routes only as short-term fixes in specific
circumstances at the moment. For the most part, each of the separate
networks is still completely self-standing.
RADB updates should be made so that your IP space is correctly
registered to the kept AS#. Particularly important if any of your
transits/peers base their filters on such a database.
IP space and related policies for the AS we're keeping are registered in
the RADB now and I update them as needed.
Not-so-stubby and totally stubby areas, if they fit your design, are a
good way to prevent over-load of your smaller routers with an increased
LSDB size, and especially if you have a lot of redistribution going on
in your network.
Yes, redistribution and controlling LSA floods are a substantial concern.
If you are interested in peering, presenting your network as a single AS
where you can advertise routes consistently in multiple locations is
another great benefit and helps meet some of the more stringent peering
requirements. Without going too much into the value of peering, if done
correctly your overall transit costs can be significantly reduced as
well as better latency for your users. (This is a good way to impress
the boss.)
My experiences in the past with presenting a loose cobble of ASes to a
peer were less than favorable 
By specifying the local as, you can integrate IGPs and build your
confederation completely transparent to the outside world. Junipers and
Cisco's, among others, both support this option. Note, the last I
checked you can't specify different local AS#s for peers within a Cisco
peer group.
I'm not using peer-groups at this time, so that shouldn't cause an issue.
This is only a start.. It's not overly difficult, and depending on the
size of your network (and staff), probably worth it.
The combined network services around 85,000 residential and commercial
users (dialup/ISDN, DSL, T1, DS3, colo...) and managed services clients.
Staff levels are sufficient to manage a network of this size.
Justin, I'd be happy to share our experiences with you sometime at
NANOG.
Much appreciated. If it's at all possible for me to make it to NANOG 24,
I will certainly take you up on it.
jms