Regional AS model

Fri Mar 25 00:03:32 UTC 2011

On Thu, Mar 24, 2011 at 5:51 PM, Graham Wooden <graham at g-rock.net> wrote:
> with one site being in the middle. I only have one public AS, but I have
> selected doing the confederation approach (which some may consider to be
> overkill with only three edges).

There are really several issues to consider, one of which certainly is
"overkill," but the others are:
1) in your case, you have to run allowas-in *anyway* because if your
transport or your "middle POP" goes down, so will your network and its
customers; so confederating isn't really buying you anything unless
your backbone is really vendor L3VPN
2) confederating / clustering can add to MED headaches and similar

While this is not directed at your deployment specifically, it is a
common newbie mistake to confederate something that doesn't need to
be, or to otherwise complicate your backbone because you think you
need to turn knobs to prepare for future growth.  Guess what, that
growth might happen later on, but if you don't understand emergent
properties of your knob-turning, your plan for the future is really a
plan to fail, as you'll have to re-architect your network at some
point anyway, probably right when you need that scalability you
thought you engineered in early-on.

List readers should be strongly discouraged from confederating unless
they know they need to, understand its benefits, and understand its
potential weaknesses.  In general, a network with effectively three or
six routers should never have a confederated backbone.  The number of
guys who really understand confederating / route-reflection within the
backbone is very small compared to the number of guys who *think* they
are knowledgeable about everything that falls under "router bgp," our
beloved inter-domain routing protocol which gives the operator plenty
of rope with which to hang himself (or the next guy who holds his job
after he moves on.)

On Thu, Mar 24, 2011 at 7:50 PM, Jeffrey S. Young <young at jsyoung.net> wrote:
> On the other hand if we'd had this capability years ago the notion
> of a CDN based on anycasting would be viable in a multi-provider
> environment.  Maybe time to revive that idea?

That draft doesn't identify any particular technical challenges to
originating a prefix from multiple discrete origin ASNs other than the
obvious fact that they'll show up in the various "inconsistent origin
AS" reports such as CIDR Report, etc.  It of course does identify some
advantages to doing it.

I imagine Danny McPherson and his colleagues have spent some time
looking into this, and can probably say with confidence that there are
in fact no real challenges to doing it today besides showing up in
some weekly email as a possible anomaly.  It seems to be a taboo
topic, but once a few folks start doing it, I think it'll quickly
become somewhat normal.

Note that in the current IRR routing information system, it is
possible to publish two route objects, each with the same prefix, and
each with a different origin ASN.  This is by design.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts