Regional AS model

Michael Hallgren m.hallgren at
Fri Mar 25 06:04:32 CDT 2011

Le vendredi 25 mars 2011 à 02:09 -0700, Zaid Ali a écrit :
> On Mar 24, 2011, at 3:17 PM, Michael Hallgren wrote:
> > Le jeudi 24 mars 2011 à 14:26 -0700, Bill Woodcock a écrit :
> >> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote:
> >>> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote:
> >>>> On Mar 24, 2011, at 12:42 PM, Zaid Ali <zaid at> wrote:
> >>>> 
> >>>>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS  and making use of confederation. 
> >>>> 
> >>>> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable.
> >>> 
> >>> We disagree.
> >>> Single AS worldwide is fine with or without a backbone.
> >>> Which is "preferable" is up to you, your situation, and your personal tastes. 
> >> 
> >> 
> >> We're with Patrick on this one.  We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them.  I think the management headache alone would be sufficient to make it unattractive to us.
> >> 
> >>                                -Bill
> >> 
> >> 
> > 
> > Right. I think that a single AS is most often quite fine. I think our
> > problem space is rather about how you organise the routing in your AS.
> > Flat, route-reflection, confederations? How much policing between 
> > regions do you feel that you need? In some scenarios, I think 
> > confederations may be a pretty sound replacement of the multiple-AS
> > approach. Policing iBGP sessions in a route-reflector topology? Limits?
> > Thoughts?
> I always look at confederations as a longer term plan because you have some idea how your backbone is going to shape out. Knowing where you are going makes confederation planning easier. Start with RR's and then see if confeds make sense.

Yes, I agree. Confed's is a choice, in particular if you need elaborate
policies between regions of your network. Police sessions between
sub-ASes, keep iBGP simple...

Say, you start with RR... If or once your network is large, and having
customers connected to it, migrating to conferedrations may be a
challenge. Right? Thoughts? Experiences?


> Zaid 

More information about the NANOG mailing list