Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020
Nick Hilliard <nick@foobar.org> Wed, 30 December 2020 17:15 UTC
Return-Path: <nick@foobar.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2FE3A0A26 for <sidrops@ietfa.amsl.com>; Wed, 30 Dec 2020 09:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 Pd_l2qNkGrst for <sidrops@ietfa.amsl.com>; Wed, 30 Dec 2020 09:15:34 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 AD4B13A0A1E for <sidrops@ietf.org>; Wed, 30 Dec 2020 09:15:33 -0800 (PST)
X-Envelope-To: sidrops@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.16.1/8.16.1) with ESMTPSA id 0BUHFPxW015593 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Dec 2020 17:15:26 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
To: Keyur Patel <keyur@arrcus.com>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
References: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <640b6603-f0bb-41d9-1b2e-99f5e2eb9dbc@foobar.org>
Date: Wed, 30 Dec 2020 17:15:24 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.43
MIME-Version: 1.0
In-Reply-To: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/dwQi9lgYKRVctdlMAHhtgYkzhSM>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2020 17:15:40 -0000
Keyur Patel wrote on 11/12/2020 20:38: > A working group last call has been re-opened for > draft-sidrops-bgpsec-validation-signaling-05, “BGPsec Validation State > Signaling”. Please reply to the list with your comments. The WGLC will end > on December 28, 2020. > > The latest draft can be found > at:https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05. I'd like to see further work on validation-signaling-via-bgp-community drafts suspended, on the grounds that they are fundamentally harmful due to how they cause large-scale routing churn. This includes this draft, which I believe should not progress to be published as an rfc. Routing validation in the dfz has taken off a bit in the last year or two, and we're only now beginning to see how it behaves at scale. It's rather obvious in retrospect, but if there's a change in the validation state of a prefix, and if you're signaling this using bgp communities, then this causes the NLRI to be updated with the new community. In turn this will cause a bgp UPDATE to be sent. By contrast, if this is handled using native routing validation (i.e. rov / bgpsec), then the update is only flooded if the best path changes. Obviously a single update isn't a big deal, but what happens when there are systemic problems in the routing validation rpki? Every affected prefix is updated and if this is already the best path, then the new update may be flooded across the relevant routing domain. This has been happening a bit recently and it would be fair to assume that from time to time, routing validation component failures are going to happen. When this happens, the last thing you want is extraneous updates trashing the control planes on your network. Excess instability is something that needs to be designed out of protocols, not acknowledged as something which can be ignored. This is separate to all the other issues that have been raised by Job a couple of months ago, which I'm not really sure were adequately addressed by the draft authors. Nick
- [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-… Keyur Patel
- Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validat… Nick Hilliard
- Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validat… Keyur Patel