FWIW, I'd consider a current case study on such very worthwhile on CCO. The talent is certainly there, so let's see some less-than-stale content. -brian : Have you considered reflectors ? The configuration is trival and : migration easy. Is your reason for confederations partitioning based on : the need to run multiple IGP instances in your network ? If so what IGP : are you running today (having full mesh of ibgp) and how big is the : network we are talking about here ? : : I am asking as I wonder why scaling ibgp mesh with reflectors was not : chosen as the prefered option. : : > It's not a fun process. I've given the matter quite a lot of thought. : > There are no easy ways to do this. Of course, with sufficient planning, : > some scripts, a good lab environment, and a few hours of downtime, a : > network can be transitioned. I don't recommend it for faint of heart. The : > best candidates for a BGP Confederation design are isolated eBGP networks : > (i.e. networks where AS border routers run eBGP, with no iBGP mesh) and : > greenfield networks. The last network I worked with that made a successful : > transition was Mindspring, AS4355, and they fell into the former category. : > : > The big question is, how big is the network. It's a trivial transition : > with 10 routers, lets say. If you have 100 fully meshed iBGP peers, I : > wouldn't bet on it. Also, implement communities - they make certain : > aspects of confederation configuration much easier. : > : > For more information on confeds, check on the NANOG web site. There are : > several archived presentations on the subject. : > : > > Is there an easy way to migrate an existing network running IBGP full mesh : > > to a : > > Condederation based configration. Any documentation that I have come across : > > states that current BGP configs need to be redone and all peering : > > relationships must torn down and rebuilt. Any addtional info/links regarding : > > confederations would be appreciated :