Re: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)

David Freedman <david.freedman@uk.clara.net> Thu, 12 February 2015 06:25 UTC

Return-Path: <david.freedman@uk.clara.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38691A9042 for <idr@ietfa.amsl.com>; Wed, 11 Feb 2015 22:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVmm5c_7_RVF for <idr@ietfa.amsl.com>; Wed, 11 Feb 2015 22:25:44 -0800 (PST)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) by ietfa.amsl.com (Postfix) with ESMTP id ACB221A904F for <idr@ietf.org>; Wed, 11 Feb 2015 22:25:43 -0800 (PST)
Received: from [193.109.254.3] by server-11.bemta-14.messagelabs.com id 0F/31-02760-6674CD45; Thu, 12 Feb 2015 06:25:42 +0000
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-4.tower-184.messagelabs.com!1423722342!7571029!1
X-Originating-IP: [80.168.41.245]
X-StarScan-Received:
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22607 invoked from network); 12 Feb 2015 06:25:42 -0000
Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-4.tower-184.messagelabs.com with SMTP; 12 Feb 2015 06:25:42 -0000
Received: from [80.168.41.252] (port=49438 helo=SRVGREXCAS06.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YLnDa-0006C6-AB (return-path <david.freedman@uk.clara.net>); Thu, 12 Feb 2015 06:25:42 +0000
Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS06.claranet.local ([fe80::60c3:7160:9e52:1c63%11]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 06:23:18 +0000
From: David Freedman <david.freedman@uk.clara.net>
To: Randy Bush <randy@psg.com>
Thread-Topic: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)
Thread-Index: AQHQRlY44pbQk601aE+c4rh++XFY+JzsXFGAgABAhAA=
Date: Thu, 12 Feb 2015 06:23:17 +0000
Message-ID: <D102047C.AA1A1%david.freedman@uk.clara.net>
References: <D101AA78.AA0D8%david.freedman@uk.clara.net> <m2a90jst34.wl%randy@psg.com>
In-Reply-To: <m2a90jst34.wl%randy@psg.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [172.26.6.254]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9ED294069D9AC841B5C8E154D50146FC@claranet.local>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Original-Recipient: randy@psg.com
X-Original-Sender: david.freedman@uk.clara.net
X-Original-Recipient: idr@ietf.org
X-Clara-Helo: SRVGREXCAS06.claranet.local
X-BorderScout: cm=0.00 ca=0.00 time=3334 size=2057
X-BorderScout-CM-Score: 0
X-BorderScout-CA-Score: 0
X-ClamAV: clean
X-Cloudmark: 0.00
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/rv58SL8_OqJtXXCizN4SwSW-SCs>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 06:25:45 -0000

>we considered a more 'liberal' approach similar to one recommended
>privately by job, where the peer discovers who to set up bfd with by
>what next hops they get.  this has problems in that it assumes NH is
>set, prefixes exist (A may announce nothing to B), etc.

Making this a function of BFD (and not BGP) makes sense here IMHO,
if there is no NH set, or no prefixes exist on day one then
I'm not going to need a BFD session in the first place.


>> which provides some assurance that you
>>know your potential bfd peer set.

Is't this the point of the RS, to facilitate in the face of the unknown?
with the above approach, assuming I filter against the RS, if I wanted to,
would I not still reach the same outcome?

Dave.