AS migration

Tue Jan 22 19:41:40 UTC 2002

One of the projects I'm considering for the future is migrating our
existing networks into a more unified network architecture and collapsing
them into one large AS.  Right now the networks I'm responsible for are
networks we've picked up through acquisitions and assumed the responsibility
for network management/operations.  Each of the networks were running
their own separate architectures (BGP, OSPF, etc)  at the time we acquired
them.  Of those, all but a handful are still running as separate ASes
with their own transit connections to ${UPSTREAMS} and private circuits
back to our network.  

There are two key questions to answer to determine if the project is
feasible and I can sell my management on it:

1) Does it make technical sense to collapse these networks into one AS?
2) Does it make financial sense to do this?

The answer to 1) is yes and that the best way to migrate seems to be to
migrate from the existing multi-AS architecture to one AS using
confederations.  This opens up a whole slew of other questions and
points to consider.  Some of these have been covered recently on NANOG, or
in other discussion groups.

* What is the most effective way to manage/control IGP expansion,
	especially if each regional network is already running their own
	OSPF implementation and meshed IBGP where needed?
* Once done, I could probably disconnect some of the upstreams that I
	don't really need.  Will the standard local-pref communities
	provided by the existing upstreams be sufficient to keep the
	network sane without requiring a great deal of manual
	intervention?  Put another way, if I have an OC3c to upstream A
	in one location and a fractional DS3 to upstream A in another
	location, what is the best practice to keep that fractional DS3
	from getting destroyed if the OC3c goes down?
* The process of converting to confederations is not trivial.
* Customer and upstream-facing BGP configurations for the networks that
	would be changing their local AS would need to be considered.
* Any other significant gotchas I haven't considered?

Once I answer all of the technical questions, I can begin answering the
financial/administrative piece in question 2).

If anyone has been through a project something like this, I'd definitely
be interested to hear your thoughts and experiences.  If I can make it to
NANOG 24, I'll cover your beer and sushi for the night ;-)

jms