On Thu, Mar 24, 2011 at 5:51 PM, Graham Wooden <graham@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@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@inconcepts.biz> Sr Network Operator / Innovative Network Concepts