I'm also looking at it from the perspective of making peering with various providers or in various exchanges a more compelling business driver, as opposed to putting all of the $$ into transit.
Yes, definitely. That's one of the main drivers to merge AS'es as well. Consolidating AS'es means aggregating the traffic in a single AS. That's a "GoodThing"TM as far as maintaining and establishing peering sessions. On the transit side, consolidating AS'es allows you to rationalize your transit connections and take out redundant links in a market to the same provider and maybe even afford a distinct backup provider for each market.
Most of the service/server consolidation has already been done.
I assume, then, that connectivity between your AS'es are via private lines and not through common transit providers. That's usually one of the other things that is necessary to start on this project. make sure your AS'es are well connected to your chosen surviving AS.... and of course, convert one AS at a time ;) heehhe
One approach we took before merging AS'es is to make sure you have a common local pref and community infrastructure among the AS'es you want to merge. attempting to go confeds with mismatching local pref and community based policies might be a headache.
I designed both for all of the other ASes so they're all similar in design.
awesome! =) you should then be able to set the proper communities and route-maps between your confederations to make sure that you spill routes across your own AS'es in a controlled manner. Through prepending and local pref tweaks, you should have the ability to make sure you don't overwhelm that DS-3 vs OC-3 to upstream A when you start merging networks. The more automated you make the ability to prepend or change local prefs or filter announcements to peers on a per route basis, the easier the migration will be. You can "automate" this process by having the necessary communities, community-lists and route-maps already in place. Once done, all you need to change the way a network is announced is by attaching a community to it. this is "automation" is necessary to ease control.
My big concern is controlling IGP growth as a whole. Each of the ASes is running their own independent OSPF implementation. Dealing with all of those disjoint backbone areas and rolling them into one AS while minimizing/eliminating service disruptions for my customers has been a source of constant brow-beating.
Start to look deep into your OSPF implementation and try to minimize the routes in your area 0 via summarization. you can also look into what's in area 0 now in your AS'es. do all the devices in area 0 now have to remain in area 0? can you some of these devices live in a new stubby or even NSSA area? The less routes in area 0, the smaller the number of routers in area 0, the more conceptually and practically easy it is to follow/monitor/verify when you merge backbone areas. Not to mention that its probably good practice. Hope this helps =) Miguel =) Miguel de Leon Dimayuga God does not ask us to be successful, Networks & Technologies only to be faithful. Cbeyond Communications -Mother Teresa of Calcutta