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