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

Christopher Morrow <> Tue, 04 September 2018 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26D93130F33 for <>; Tue, 4 Sep 2018 08:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6cIgwURd15RH for <>; Tue, 4 Sep 2018 08:57:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10864129C6B for <>; Tue, 4 Sep 2018 08:57:42 -0700 (PDT)
Received: by with SMTP id g18-v6so3286531uam.6 for <>; Tue, 04 Sep 2018 08:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KzHYRQ0DQPWQ4wTHDZasxE3eoRdwrsEZRPl9m6LYpSU=; b=VZeROJ1UsJkljqa7XkOO8JTEOz1+vkcqbabeLIjp2RFF9V6bA///OyJC4y2kpDw2Lk m78dQk0iN9dBWsq/8laoXccQDg8ONTJS+ur73f/iIY6ErKZEJpQFGy63YSFaSMtVtmBe kTyGq9//CFdUNzcy8VKRM0fXPaPuGWJwtiNwZV1E5GVNLpwmrJg3WH81TMelFbBspoa4 XPS+xglTQ/7tjW78wczT8hZkXi1roFfX1lIci6JJUqD6BoDXwvN6L5o9SPvwFXJCjJzf Av003RogwP+QQgp85Yz20JcVTg7l6HYuxT30WkkCkNZgmP6bIJvETOBjAggh3dG4N4Wc LMZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KzHYRQ0DQPWQ4wTHDZasxE3eoRdwrsEZRPl9m6LYpSU=; b=YC1x3c7UYoedXeIj1yhdU2GztReXMOY9ycnJkdD0/yU01ZJUc7PAkL6wu/fZX9euAj +C1MHAtujRq35vZmxGA035MUkGYeF7wEANBY1r8xqUTKkq0A8OK9ojUHzmzqSOygXo58 /A5TrVndqrm/0Bsl9ucx9vE7S/SCgSnI9cVqekGFkrfIinAP/K7oRZTThrP2aakgUy+B 4X+NHl+FhMhl/zjzAPRP0XQqU4aCaQ+NaOWY07N5PUaRSZwadubHyONrz2ZKcvo6ZgyA ss86gd08wmdvv1RFiHvrfbSEwl9Bm54x5dqnuJXJRqtDt2ms71nyUoYhkYBae6wX8xs0 rvOQ==
X-Gm-Message-State: APzg51A74ya89vn0tD25joFTpkar/9lSQvnqTlEklWtIkqlv1Mfa6nb+ Plnwk9ci8NP1ox2g8PnXG4chgE82L2gxWYa80BY=
X-Google-Smtp-Source: ANB0Vdbne0Qx+60unu+CDBq+BgwX4zHi/lsqQ9yQFTeQdh8we+RHT/jwd+rPyVaOPb9+myoi7QPT8FtDoer9Mveq+f8=
X-Received: by 2002:ab0:6510:: with SMTP id w16-v6mr11036520uam.139.1536076660814; Tue, 04 Sep 2018 08:57:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Christopher Morrow <>
Date: Tue, 04 Sep 2018 11:57:29 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000b73b0f05750db7c7"
Archived-At: <>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018
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: Tue, 04 Sep 2018 15:57:44 -0000

I think restating an earlier conversation about this draft (which I think
was the rpki-light draft name) is useful:
  "The draft aims to provide the ability for a third-party (IXP) to
validate routes for me, because I can't do that myself"

The reasons why 'I' may not be able to do the validation are perhaps
shifting in time though, which I think should be acknowledged in this
conversation that's progressed since the original draft was proposed.

On Fri, Aug 24, 2018 at 10:33 AM Daniel Kopp <> wrote:

> The initial idea for the draft came from network operators at IXPs.

It's worth noting that -ops groups in the IETF are supposed to gather
requirements from actual operators and coalesce these into change proposals
for ietf protocol groups as part of their charters. particularly SIDROPS
should be taking requirements for SIDR protocol deployments from the bgp
operating community(ies). So, it's great to get feedback from IXP operators
and network operators for requirements/improvements/deployment-guidance.

> The idea of the draft is to help with the adoption of RPKI in the domain
> of IXPs.
> The idea draft is not a replacement for RPKI validation or a global
> distribution of RPKI validation results.
> The draft is there to help at IXPs till we all drop invalids by default :)

I think ~2yrs back there were more 'problems' with the idea of deployment
of route origin validation and taking action(s) upon that decision process.
It's possible that in today's review of the problem space the problems have
changed or resolved, right? It sounds like, from the discussion, that some
operators (of IXP and ISP networks) are saying that:
  1) "route origin validation is not as hard to see deploying today"
  2) "just introducing an IXP lan/RS that simply implements the validation
and takes action(s) is the right course of action"
  3) "Using the IXP's RS feed in the case of: 'please drop routes based on
validation state' can get data/experience to the IXP participants such that
they can then deploy route origin validation in their networks as well"

Maybe  we can re-frame the discussion along those lines?