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

Randy Bush <randy@psg.com> Tue, 29 January 2019 14:59 UTC

Return-Path: <randy@psg.com>
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 D475212D84D for <sidrops@ietfa.amsl.com>; Tue, 29 Jan 2019 06:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 scOokKuPuhRJ for <sidrops@ietfa.amsl.com>; Tue, 29 Jan 2019 06:59:44 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 66BBD126F72 for <sidrops@ietf.org>; Tue, 29 Jan 2019 06:59:44 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1goUrW-00077C-Dl; Tue, 29 Jan 2019 14:59:42 +0000
Date: Tue, 29 Jan 2019 06:59:41 -0800
Message-ID: <m2d0ofbjc2.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <C1B8634B-38A3-4452-B8EC-C9DD84A16175@nlnetlabs.nl>
References: <m2fttcd5sd.wl-randy@psg.com> <m27eeocuaq.wl-randy@psg.com> <C1B8634B-38A3-4452-B8EC-C9DD84A16175@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/twrpVphLKfsPxgiAWYh_U9X9VFg>
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 14:59:46 -0000

hi tim,

(  omg!  someone is alive in this wg!  :)

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

within the trust boundary, one tends to want to manage complex services
on fewer devices.  route reflection is a poster child; the clients
have a restricted number of peers and a minimized consistent view.  so
it is what we used in the text.

   Within a routing trust boundary, e.g. an operator's Point of Presence
   (PoP), it may not be desirable or necessary for all routers to
   perform Origin Validation using the Resource Public Key
   Infrastructure (RPKI) per [RFC6811].  A good example is route
   reflectors (see [RFC4456]).

a pop may have a few dozen routers.  no need to run rpki-rtr and full
validation on them all.

> 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.

one can do it with policy, no need for a whole rpki-rtr client and
validation.

randy