Subject: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020

From: Keyur Patel <[email-masked]>
Date: Fri, 11 Dec 2020 20:38:04 +0000

Hi Folks:

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.

Regards,
Chris, Nathalie & Keyur

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Dec 2020 17:15:24 +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