In a message written on Thu, Sep 29, 2011 at 11:22:45AM -0400, Danny McPherson wrote: > With normal unicast there's a single tree for the prefix in the routing > system, while anycasting inherently introduces a polytree for the prefix. > However, anycasting with a common origin AS creates a 'pseudo AS' at the > root of the graph (i.e., the illusion of a single tree). By doing what > you describe, you force anyone doing routing system analysis to know 'a > priori' which prefixes employ a pseudo AS at the root of the tree - only > so that they can step deeper into the tree, to the actual polytree roots, > and then evaluate the adjacent nodes of those roots. This is particularly > problematic when new nodes are introduced to the system.
I'm sure you have studied this in great detail, and so I will simply assume you're correct that the method described is easier when writing a program to find hijacked routes. However, that is a small part of operating an Anycast system. Far more frequently than I help folks find hijacked routes (which are fortunately rare) I help troubleshoot ordinary performance problems. It's far easier for me to say "send me show ip bgp regex _3557$" and get all the info I need than send a list of routes (3 in our case) or local ASN's (about 55 in our case). The same goes for when I'm looking at various looking glasses to see what is going on. I also think, and this is totally subjective, that it is easier to explain to folks on the phone, particularly folks with no Anycast experience. They can just pretend in their mind that 3557 is one big global network that peers in a lot of places and their mental image is complete. So even if I spot you that it makes it easier for a third party to programmatically detect hijacks I don't think that's enough alone to rise to calling this method the "best current practice", which is the path this draft is on. It has impacts on day to day operations (including things like the inconsistent asn reports) that also need to be weighed. But, I think we've both overmade our points. I also realize I was late to this game, you can't watch everything in every group all the time. I think the question is if anyone else on the list cares one way or another, because if no other opinions have been changed we might as well stop. -- Leo Bicknell; E-mail: bickn...@isc.org, Phone: +1 650 423 1358 INOC*DBA *3357*592; Internet Systems Consortium, Inc. www.isc.org _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow