Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

[Christopher Morrow <[e-mail]>]

jumping in in the middle...

On Thu, Sep 29, 2011 at 3:07 PM, Leo Bicknell <[e-mail]> wrote:
> 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.
>

it sounds like for the case of (for example) Leo troubleshooting
specific ISC problems one method he has works well. (and if you see
F-root originated from anything BUT 3557 you KNOW there's a problem..
again, as an example he could have 25 asns for this, but I'm assuming
1)

For a more generic problem that Danny/authors are attempting to make
simpler, each 'anycast service' would have it's own group of asn's
which would correlate to a set of both transits/peers AND geographic
locations... So, (again as a purely hypothetical example) A-root from
AS123333 behind AS4134 seen in London is likely far, far less happy
than A-root from AS123333 behind AS9150 in London. Also, A-root from
AS15169 anywhere is just bad news... (again, making up an example of
both 'location aware' troubleshooting for performance and one for
'mis-originated')

I don't think that the subject doc was intended to force compliance in
one way or the other, just to document one possibly reasonable method
to do anycast service hosting (and show how it is considered
reasonable).

Smart operators of services likely already have lots of these guts for
themselves done, if it works don't fix it.

-chris