Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

Nick Hilliard <> Fri, 31 August 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A95130DE3 for <>; Fri, 31 Aug 2018 08:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VeSgGUPCfDBV for <>; Fri, 31 Aug 2018 08:28:15 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9853130DD1 for <>; Fri, 31 Aug 2018 08:28:14 -0700 (PDT)
Received: from cupcake.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w7VFS8Vl019753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2018 16:28:09 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be cupcake.local
To: Daniel Kopp <>
Cc: SIDR Operations WG <>
References: <>
From: Nick Hilliard <>
Message-ID: <>
Date: Fri, 31 Aug 2018 16:28:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
X-Mailman-Version: 2.1.27
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: Fri, 31 Aug 2018 15:28:17 -0000

Hi Daniel,

Daniel Kopp wrote on 31/08/2018 13:01:
> The draft is intended for networks that can't (technically) or won't 
> (politically) implement RPKI in their own networks,

If an organisation won't implement RPKI for policy reasons, then that is 
a decision that they are responsible for, and it is not really the job 
of the IETF to engineer around their layer 9 problems.

Regarding the "can't technically" position that some networks find 
themselves in, this argument is evaporating quickly, as more bgp stacks 
implement RO validation.  All the major vendors do this already on 
current equipment, so this is beginning to become a question of whether 
people are on current support contracts or not, which brings the issue 
back to a policy decision on their part, rather than strictly a 
technical decision.

> maybe we can find a way to make this work

This is the crux: in the context of ebgp and public exchange of NLRIs,
the draft presents a methodology which is incompatible with good quality 
network engineering and product design.  I don't believe this can be fixed.