[139013] in North American Network Operators' Group
Re: Regional AS model
daemon@ATHENA.MIT.EDU (Zaid Ali)
Fri Mar 25 05:09:25 2011
From: Zaid Ali <zaid@zaidali.com>
In-Reply-To: <1301005023.2933.14.camel@home>
Date: Fri, 25 Mar 2011 02:09:14 -0700
To: Michael Hallgren <m.hallgren@free.fr>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 24, 2011, at 3:17 PM, Michael Hallgren wrote:
> Le jeudi 24 mars 2011 =E0 14:26 -0700, Bill Woodcock a =E9crit :
>> 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@zaidali.com> wrote:
>>>>=20
>>>>> 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.=20
>>>>=20
>>>> 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.
>>>=20
>>> 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.=20
>>=20
>>=20
>> 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.
>>=20
>> -Bill
>>=20
>>=20
>=20
> 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=20
> regions do you feel that you need? In some scenarios, I think=20
> 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.
Zaid=20=