Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

Nick Hilliard <nick@foobar.org> Thu, 16 March 2017 10:54 UTC

Return-Path: <nick@foobar.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6812708C for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 03:54:32 -0700 (PDT)
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_PASS=-0.001] autolearn=ham autolearn_force=no
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 il2sx7bBByQV for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 03:54:30 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2606112704B for <idr@ietf.org>; Thu, 16 Mar 2017 03:54:29 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2GAsRNP021863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Mar 2017 10:54:27 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <58CA6EE2.9030701@foobar.org>
Date: Thu, 16 Mar 2017 10:54:26 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.11 (Macintosh/20170302)
MIME-Version: 1.0
To: Robert Raszuk <robert@raszuk.net>
CC: Job Snijders <job@instituut.net>, idr wg <idr@ietf.org>
References: <CA+b+ERmLDNzF=TofW=w1OwUzeLGUc-3muMckHTH6Rs=c8rc5bQ@mail.gmail.com> <20170314223333.bw3caxfn34y6zlb7@Vurt.local> <CA+b+ERmMOyqb8HFtNXyDr8e+MNxA7EWmJFukUNgSjAU+69f5CA@mail.gmail.com> <20170314225855.GN12864@pfrc.org> <CA+b+ERkt6MJUPR-4WX0LYZ9CG1FoNX-g4=hnqFB9iQy8WfKOww@mail.gmail.com> <20170315000326.GO12864@pfrc.org> <CA+b+ERmWUL-pVwjW8Vq+Vz8UzYDpcVBZxxhtM6WFqhmG+r35WA@mail.gmail.com> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <CA+b+ERn-uya3kB-FgXvfFjdK-hPmj-W-mv_T+TnbEAfkzR8Hfg@mail.gmail.com> <20170315212656.GD2367@Space.Net> <CA+b+ER=MnejDq5JNyNUHvf7mV7vkFehbeE65a_5cqFUsTEAzZA@mail.gmail.com> <CACWOCC-gAPbV0fdraHkkjhSo=Tc_YUFWMTOjx311a2XDJZMDmQ@mail.gmail.com> <CA+b+ERmxQkH75tbotT16hsZvqrvMVsX0G_zyY1ofA=kTZZzZ0w@mail.gmail.com>
In-Reply-To: <CA+b+ERmxQkH75tbotT16hsZvqrvMVsX0G_zyY1ofA=kTZZzZ0w@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PIvo33eyjCmH3bL13LU0zUKTnRA>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Mar 2017 10:54:32 -0000

Robert Raszuk wrote:
> Based on the above just making sure that those two route servers pick
> paths with different next hop as best may already address the problem to
> improve robustness with just putting only a negligible additional load
> on the customer edge keeping current hardware and software as is.

just to be clear, 1. this does not fix the problem we're trying to
address here and even if it did, 2. ixp operators are not going to
impose their own routing tweaks on their participant base by choosing
different NHs.  IXP participants demand consistency and if ixp operators
don't provide this, or start interfering in the routing decisions of
their stakeholders, then the ixp participants will go elsewhere.

Nick