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

Randy Bush <randy@psg.com> Sat, 09 March 2019 01:55 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 1E679126C15 for <sidrops@ietfa.amsl.com>; Fri, 8 Mar 2019 17:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 uE9nsh62BwZu for <sidrops@ietfa.amsl.com>; Fri, 8 Mar 2019 17:55:50 -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 854DA1274D0 for <sidrops@ietf.org>; Fri, 8 Mar 2019 17:55:50 -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 1h2RDI-0005nf-N8 for sidrops@ietf.org; Sat, 09 Mar 2019 01:55:49 +0000
Date: Fri, 08 Mar 2019 17:55:48 -0800
Message-ID: <m2bm2kizff.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
References: <m2fttcd5sd.wl-randy@psg.com> <m27eeocuaq.wl-randy@psg.com>
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/fuqSB7hXWFdOmXEtdGYY5z-lzOU>
Subject: [Sidrops] Fwd: 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: Sat, 09 Mar 2019 01:55:52 -0000

did not get a lot of feedback on list.  but it may be worth a few
minutes of discussion in praha if there is room on the agenda.

maybe it will move things along if i ask to adopt; so i hereby do so.

randy


Date: Mon, 28 Jan 2019 14:05:17 -0800
Message-ID: <m27eeocuaq.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
Subject: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt

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