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

[Leo Bicknell <[e-mail]>]

In a message written on Fri, Sep 30, 2011 at 10:51:58AM -0400, Christopher Morrow wrote:
> the troubleshooting though with something like unique origin is
> 'simpler' for them: "Oh, as27 is NYC, as37 is WDC... why is Newark
> seeing WDC as the best path?"

I'm not sure I get it.

Unique origin ASN output (simplified)

  10.1.2.3/32
        65000
        65001
*       65002 (Best)
        65003 65001

So we know it's coming from site 65002.

Using the F-Root model, with an origin of 65999 for the Anycast routes:

  10.1.2.3/32
        65000 65999
        65001 65999
*       65002 65999 (Best)
        65003 65001 65999

We still know it's coming from site 65002 by just looking.  I have a
hard time calling one "simpler" than the other, indeed I would call them
pretty darn equal.

But here's the difference, let's say I have 20 Anycasted routes for
different services, but I originate them all from 65999, I can see the
status of all 20 with:

show bgp ipv4 uni regexp _65999$

I'll get 20 lines, showing me how each virtual is routed.

With a unique origin ASN configuration, to get the same info for 20
routes I would need 20 lines like:

show bgp ipv4 uni 10.1.2.3/32
show bgp ipv4 uni 10.1.2.4/32
show bgp ipv4 uni 10.2.2.1/32

And so on, or have the discipline to keep them all in one netblock so:

show bgp ipv4 uni 10.1.2.3/24 longer-prefixes

produces useful output.

Thus I think I can make a good argument that having a consistent
origin ASN makes troubleshooting easier when you have multiple
Anycast routes, because you can select the entire set of routes by
origin ASN.

-- 
Leo Bicknell; E-mail: [e-mail], Phone: [phone]
INOC*DBA *3357*592; Internet Systems Consortium, Inc.  www.isc.org