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> Wed, 11 February 2015 23:58 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 7DDE71A1BEE for <idr@ietfa.amsl.com>; Wed, 11 Feb 2015 15:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 eckchoZ-ZGzS for <idr@ietfa.amsl.com>; Wed, 11 Feb 2015 15:58:50 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4021A1BDF for <idr@ietf.org>; Wed, 11 Feb 2015 15:58:50 -0800 (PST)
Received: from [195.245.230.51] by server-12.bemta-3.messagelabs.com id B1/B8-02881-9BCEBD45; Wed, 11 Feb 2015 23:58:49 +0000
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-6.tower-33.messagelabs.com!1423699129!10097721!1
X-Originating-IP: [80.168.41.244]
X-StarScan-Received:
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22010 invoked from network); 11 Feb 2015 23:58:49 -0000
Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-6.tower-33.messagelabs.com with SMTP; 11 Feb 2015 23:58:49 -0000
Received: from [80.168.41.252] (port=51270 helo=SRVGREXCAS05.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YLhBA-0000p1-9E for idr@ietf.org (return-path <david.freedman@uk.clara.net>); Wed, 11 Feb 2015 23:58:48 +0000
Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS05.claranet.local ([fe80::3915:cdff:95ac:dcdb%11]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 23:55:32 +0000
From: David Freedman <david.freedman@uk.clara.net>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)
Thread-Index: AQHQRlY44pbQk601aE+c4rh++XFY+A==
Date: Wed, 11 Feb 2015 23:55:31 +0000
Message-ID: <D101AA78.AA0D8%david.freedman@uk.clara.net>
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: <98C909D516D7EB4AB3F47F50C0C5E264@claranet.local>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Original-Recipient: idr@ietf.org
X-Original-Sender: david.freedman@uk.clara.net
X-Clara-Helo: SRVGREXCAS05.claranet.local
X-BorderScout: ca=0.00 cm=0.00 time=3590 size=1913
X-BorderScout-CM-Score: 0
X-BorderScout-CA-Score: 0
X-Cloudmark: 0.00
X-ClamAV: clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/Q-WUA_jWndpUyrNTtmEhh-z88bQ>
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: Wed, 11 Feb 2015 23:58:53 -0000

>it would be more sensible to define a new bgp attribute to allow RS
>clients
>to announce BFD candidacy to the RSN

+1

Actually, I was speaking recently to another author who planned to
resurrect it in another as yet unpublished draft
involving a new BGP attribute to signal next-hop liveliness detection
(hopefully this post will prompt them into action to mention it).

In this discussion, we determined that these duties could probably be
devolved directly to BFD itself, which could (if configured suitably) be
left to discover potential peers and set up sessions based on seeing them
as next hops in the incoming BGP RIBs learned from the IXP route server.
This seemed like a much better approach than leaving it to BGP and the RS
(which relieves some of the potential burden on it IMHO)

Dave.