Re: BGP Confederations

[Brian Wallingford]

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
: