Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)

Jeffrey Haas <> Thu, 28 February 2019 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D10EC130EE9 for <>; Thu, 28 Feb 2019 10:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6j3WvASGVdQ for <>; Thu, 28 Feb 2019 10:04:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B5DC112F1AB for <>; Thu, 28 Feb 2019 10:04:29 -0800 (PST)
Received: by (Postfix, from userid 1001) id DDCCB1E2D8; Thu, 28 Feb 2019 13:03:37 -0500 (EST)
Date: Thu, 28 Feb 2019 13:03:37 -0500
From: Jeffrey Haas <>
To: Nick Hilliard <>
Cc: Randy Bush <>, Christopher Morrow <>,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Feb 2019 18:04:31 -0000

On Wed, Feb 27, 2019 at 04:28:27PM +0000, Nick Hilliard wrote:
> Maybe the authors could describe use cases?  I can't see any
> situation where this flag might be useful, but hey, other people
> have different requirements on their networks.

I'm not an author.  I had some opinions on the original extended community
that weren't exactly popular among the purists in SIDR.  A terse form of
those opinions follows:

Like all BGP features, OV will be incrementally deployed.
RPKI can tell you the useful bit of tri-state that is in the current RFC:
valid, invalid, unknown.
Carrying that state from a spot in your network that supports OV to parts
that don't may be useful, depending on your policy.
For some fault states (validator down, e.g.) carrying that state into the
network may similarly be useful.
Similarly, carrying state that OV has arrived at one state but you're taking
different action may be interesting.  This one overlaps things like more
specific routes carried between consenting providers that are not in the
global RPKI as valid.  Other mechanisms can address the issue as well.

End of the day, the tri-state is helpful, but provides the bare minimum of
operational coverage for carrying this stuff into your network.

At some point, OV can be pervasivel deployed such that these are less of an

-- Jeff