IETF Logo Mail Archive

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

Nick Hilliard <nick@foobar.org> Tue, 14 March 2017 11:13 UTC

Return-Path: <nick@foobar.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 6A0B412954B for <grow@ietfa.amsl.com>; Tue, 14 Mar 2017 04:13:03 -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 6EuQnOUkCInB for <grow@ietfa.amsl.com>; Tue, 14 Mar 2017 04:13:01 -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 63A131279EB for <grow@ietf.org>; Tue, 14 Mar 2017 04:13:01 -0700 (PDT)
X-Envelope-To: grow@ietf.org
Received: from cupcake.local (87-198-221-22.static.ptr.magnet.ie [87.198.221.22]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2EBCqix074054 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 11:12:53 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 87-198-221-22.static.ptr.magnet.ie [87.198.221.22] claimed to be cupcake.local
Message-ID: <58C7D033.8060203@foobar.org>
Date: Tue, 14 Mar 2017 11:12:51 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.11 (Macintosh/20170302)
MIME-Version: 1.0
To: Tore Anderson <tore@fud.no>
References: <20170313121134.6676bd02@echo.ms.redpill-linpro.com> <71D584DF-94F5-40B3-BCE0-4736354ECCCB@harg.net> <20170314072225.55fdd871@echo.ms.redpill-linpro.com> <58C7BD67.6080308@foobar.org> <20170314111326.3714e0ed@echo.ms.redpill-linpro.com>
In-Reply-To: <20170314111326.3714e0ed@echo.ms.redpill-linpro.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/qCI4whfg58Axq59MhiiqgviffYw>
Cc: grow@ietf.org
Subject: Re: [GROW] Comment on draft-iops-grow-bgp-session-culling
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 14 Mar 2017 11:13:03 -0000

Tore Anderson wrote:
> My point here was that if the IXP is doing maintenance, it could shut
> all ports to all members simultaneously, and thus get the exact same
> effect as the «when someone yanks the physical connector» scenario
> described in the draft.

this doesn't work because 1. some ixp participants connect their routers
via intermediate switches and if all ports are yanked simultaneously,
they will blackhole traffic on their side and 2. any ixp with more than
one switch in their peering fabric needs to be able to performance
maintenance on part of their ixp without affecting the rest.

Regarding point 1, you could claim that this was the ixp participant's
problem, not the IXP's, and you might even be technically right, but the
erupting blamestorm would always fall back on the IXP for initiating the
problem.

Nick

v2.23.0 | Report a Bug | By Email