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

Leo Bicknell <bicknell@isc.org> Fri, 30 September 2011 14:17 UTC

Return-Path: <bicknell@isc.org>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B176721F8562 for <grow@ietfa.amsl.com>; Fri, 30 Sep 2011 07:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r3Onoyt5LU3 for <grow@ietfa.amsl.com>; Fri, 30 Sep 2011 07:17:48 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3921F8540 for <grow@ietf.org>; Fri, 30 Sep 2011 07:17:47 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 711755F98BF; Fri, 30 Sep 2011 14:20:20 +0000 (UTC) (envelope-from bicknell@isc.org)
Received: by bikeshed.isc.org (Postfix, from userid 10294) id 8BC49216C3D; Fri, 30 Sep 2011 14:20:18 +0000 (UTC)
Date: Fri, 30 Sep 2011 14:20:18 +0000
From: Leo Bicknell <bicknell@isc.org>
To: Christopher Morrow <christopher.morrow@gmail.com>
Message-ID: <20110930142018.GA4530@bikeshed.isc.org>
References: <20110928235156.GA65454@bikeshed.isc.org> <352BFFD6-B2C3-4ACD-96C1-46F28B5E5719@tcb.net> <20110929130632.GA76531@bikeshed.isc.org> <E6D92094-5836-4BB8-8E3A-5F620AA67696@tcb.net> <20110929133512.GA77671@bikeshed.isc.org> <10DB5C60-A228-4877-9EF0-F14F20DB06F5@tcb.net> <20110929190706.GA84607@bikeshed.isc.org> <20110929150403.37945441@t61p> <20110929202042.GA87117@bikeshed.isc.org> <CAL9jLaZO7uS=ga8DUcG+_okPc6v+LUTpWV5x0W_uk4gy2m+wjg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAL9jLaZO7uS=ga8DUcG+_okPc6v+LUTpWV5x0W_uk4gy2m+wjg@mail.gmail.com>
Organization: Internet Systems Consortium, Inc
Cc: "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2011 14:17:48 -0000

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
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.

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
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.

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.

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.

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...

-- 
Leo Bicknell; E-mail: bicknell@isc.org, Phone: +1 650 423 1358
INOC*DBA *3357*592; Internet Systems Consortium, Inc.  www.isc.org