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

[Christopher Morrow <[e-mail]>]

On Fri, Sep 30, 2011 at 10:20 AM, Leo Bicknell <[e-mail]> wrote:
> In a message written on Fri, Sep 30, 2011 at 12:40:24AM -0400, Christopher Morrow wrote:
>> keep in mind that 'enterprises' may be deploying anycast services
>> inside their wan's, NOT publicly visible... What advice would you give
>> them in such a situation?
>
> Just to level set here, I'm assuming you mean a large enterprise
> using something like a MPLS L3VPN service, and thus running BGP
> with their service provider inside the VPN to communicate routing

that's one option, enterprises come in lots of flavors... I've seen
them with mpls-vpn cores and with leased line cores and with
ipsec-over-internet cores. (I'm sure you have as well)

> information.  I clarify, because if it's a simpler IGP only Enterprise
> I don't think much of anything we've been discussing makes any
> difference, drop it in the IGP and be done.

sure.

>
> I think, basically, most of what we've discussed does not apply.
> If it really is a private network there will be no third parties
> doing route monitoring.  The chance of a rogue ASN injecting the
> route is near zero.  The provider of the service is also the end

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?"

> user of the service, and has control of virutally every routing
> device in the middle, so there are a multitude of ways they could
> monitor and troubleshoot.  There will be no external services doing
> things like inconsistent asn reports.

true, we hope.

> Personally I would still originate all of my Anycast from a private
> ASN (a la what F does with 3557) for the sole reason that then the
> announcement is consistent, thus "show bgp ipv4 unicast inconsistent-as"
> actually produces useful output.  While it is far less likely to
> be used in an enterprise context, it is far more likely to be useful
> when it is used given the end to end control.  If the enterprise
> migrates routes from one site to another (e.g. virtuals in a data
> center move) the command will show if they are coming from two
> different sites quickly and easily.

you are highlighting one troubleshooting technique, yes. I highlighted
another. potato/potatoe. Again, for 'smart folks' who know their
service inside/out they'll figure this out on their own. For a new
deployment, however, some guidelines seem like a good plan.

> Honestly though, if I were providing recomendations to an enterprise
> I would likely encourage them not to run Anycast.  They control the
> end clients.  They can configure the clients for even better
> redundancy than Anycast provides given a little thought.  Plus, as
> you said, enterprises tend not to be staffed with super-bgp-ninjas,
> and so giving them something outside the CCNA traning class is not
> a good idea.

:) but that network world article... I agree with you mostly, I've
seen some good uses of anycast internal to enterprises. Again, 'smart
people' and all of that.

>
> Anycast is best used when you don't control, or have limited control
> over the end clients.  For instance root operators get to provide
> 1 IP address in root.hints or in the root zone, which limits the
> ability to do redundancy with multiple IP adddresses...

dns servers exist for desktop/vpn clients in corporations too. maybe
it's a little 'all I have is a hammer', but it does work well.

-chris