IETF Logo Mail Archive

Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 29 January 2019 10:13 UTC

Return-Path: <tim@nlnetlabs.nl>
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 54425130F4A for <sidrops@ietfa.amsl.com>; Tue, 29 Jan 2019 02:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 L4wcNt8p-9S1 for <sidrops@ietfa.amsl.com>; Tue, 29 Jan 2019 02:13:04 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82861130F47 for <sidrops@ietf.org>; Tue, 29 Jan 2019 02:13:04 -0800 (PST)
Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id F331F1F7C1; Tue, 29 Jan 2019 11:13:00 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1548756781; bh=GMzx/cTvsbt6qGGtgRdbBGVmzMASjScvy9WK1zIsNfw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=luWyC3xKBLdsZGC0Q7a3RqXCnvdIjxUDoRB7Ci3KKyRwSIC0tn3aknipDjcNnUYBP cxuo/5I8gUopI7X5YEzs/RsLYUy2rni7jYs6Z9dXxc1c/ZIH8WB80PJfT7ls3cVeIh 0lwwERqrlx6XS3l7wuNI2CYN8POvRR7X9u9QXX7g=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m27eeocuaq.wl-randy@psg.com>
Date: Tue, 29 Jan 2019 11:13:00 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1B8634B-38A3-4452-B8EC-C9DD84A16175@nlnetlabs.nl>
References: <m2fttcd5sd.wl-randy@psg.com> <m27eeocuaq.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RstJufv_f_XL4v4bnUmnRVsaTIg>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt
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: Tue, 29 Jan 2019 10:13:06 -0000

Hi Randy, all,

I have a question: why is signalling OV (within a trust boundary) preferable over doing OV?

If signalling is desired, then the community seems plausible enough to me, albeit that it's not clear to me how this is easier on the router than doing OV in the first place.  A lot of routers support this now, and there are more and more lightweight RP options. But I may well miss the operational reason for this, so don't take this as opposition.

Tim


> On 28 Jan 2019, at 23:05, Randy Bush <randy@psg.com> wrote:
> 
> i would like to put draft-ymbk-sidrops-ov-signal-02.txt on the agenda
> for praha.  discussion so far:
> 
>  there was one red herring; outsourcing security.  as this was
>  discussed in the draft, i can only assume actual reading helped.
> 
>  the substantial issues raised in the meeting (i found nothing in the
>  mailing list archives) seems to be the signaling/transport.  let's
>  focus on this.
> 
> these seem to be three general alternatives for signaling.
> 
>  in-band, as described in the draft, uses an extended community.
>  alternatively it could use a new attribute or other hack.  such
>  alternative in-band mechanisms could be discussed/investigated.
> 
>  a new afi/safi, which did not get rousing support from router
>  implementors who would have to create and support a whole new afi/safi
>  for the task.  of course, creative folk could undoubtedly find more
>  things to do with the new afi/safi if they get bored with bgp-ls:)
> 
>  augment the rpki-rtr protocol to allow the router to signal back to
>  the cache one or more invalid routes.  but then what happens with
>  those data?  if the cache will signal those to router clients, then
>  those router clients will have done the evaluation on their own.
> 
> these are the thoughts which led us to in-band signaling.  but this is
> certainly worth discussing, here, praha, or both.
> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email