IETF Logo Mail Archive

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

Nick Hilliard <nick@foobar.org> Tue, 14 March 2017 09:52 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 0053C12952D; Tue, 14 Mar 2017 02:52:54 -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 b3DLp63-cLxm; Tue, 14 Mar 2017 02:52:52 -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 081BE1294DB; Tue, 14 Mar 2017 02:52:51 -0700 (PDT)
X-Envelope-To: draft-iops-grow-bgp-session-culling@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2E9qeP7064426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 09:52:40 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <58C7BD67.6080308@foobar.org>
Date: Tue, 14 Mar 2017 09:52:39 +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>
In-Reply-To: <20170314072225.55fdd871@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/d_N8rqoO5JJWWaL5VX94TxAOv5o>
Cc: grow@ietf.org, draft-iops-grow-bgp-session-culling@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 09:52:54 -0000

Tore Anderson wrote:
> By the way, as an IXP operator, you also have the possibility to simply
> shut down your members' interfaces prior to performing maintenance,
> instead of doing culling. Doing so would be completely analogous to the
> directly connected BGP speakers scenario discussed in section 1 where the
> draft says «detecting and acting upon a link down event (for example
> when someone yanks the physical connector) in a timely fashion is
> straightforward».

- if the ixp port is connected to an intermediate switch on the member
side, the ixp member router won't see the carrier state transition and
will blackhole traffic on the member side

- all other ixp members who peer with that router also won't see the
carrier state and will leave bgp up, causing traffic to be blackholed on
the remote side.

Nick

v2.23.0 | Report a Bug | By Email