[Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Warren Kumari <warren@kumari.net> Tue, 22 May 2018 18:53 UTC

Return-Path: <warren@kumari.net>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D6412D7E6; Tue, 22 May 2018 11:53:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-bgp-gr-notification@ietf.org, Jie Dong <jie.dong@huawei.com>, aretana.ietf@gmail.com, idr-chairs@ietf.org, jie.dong@huawei.com, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152701518391.31181.3562126455441179002.idtracker@ietfa.amsl.com>
Date: Tue, 22 May 2018 11:53:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jUOUQtbjOXT_kgMQejwHBIR-_Xc>
Subject: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 22 May 2018 18:53:04 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-gr-notification-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm sure that this has already been discussed somewhere, and that I'll be able
to quickly clear my DISCUSS once pointed at it, but: "To put an upper bound on
the amount of time a router retains the stale routes, an implementation MUST
support a (configurable) timer, called the "stale timer", that imposes this
upper bound. A suggested default value for the stale timer is 180 seconds. An
implementation MAY provide the option to disable the timer (i.e., to provide an
infinite retention time) but MUST NOT do so by default."

The "infinite retention time" part of this makes me deeply uncomfortable -- I
can see a good reason for the stale timer, and the default "feels" fine to me,
but having an infinite retention time (or, really anything over 10 to 15
minutes) feels like a really dangerous idea, and that it will come back and
bite.

I'm hoping that I'm missing something obvious, but can you please explain under
what conditions an infinite retention policy makes sense? It seems like there
would be multiple opportunities for blackholing traffic with this.