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