[Sidrops] draft-ymbk-sidrops-ov-signal-02.txt
Randy Bush <randy@psg.com> Mon, 28 January 2019 22:05 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 66FBB13115A for <sidrops@ietfa.amsl.com>; Mon, 28 Jan 2019 14:05:21 -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 l9EFDCH6t5f8 for <sidrops@ietfa.amsl.com>; Mon, 28 Jan 2019 14:05:20 -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 2CC49130EDD for <sidrops@ietf.org>; Mon, 28 Jan 2019 14:05:20 -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 1goF1q-0002yz-2X for sidrops@ietf.org; Mon, 28 Jan 2019 22:05:18 +0000
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>
References: <m2fttcd5sd.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/Z2gWG-OkBw8BPBAGYBSE0cMC0xM>
Subject: [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: Mon, 28 Jan 2019 22:05:21 -0000
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] draft-ymbk-sidrops-ov-signal-02.txt Randy Bush
- Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt Tim Bruijnzeels
- Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt Randy Bush
- [Sidrops] Fwd: draft-ymbk-sidrops-ov-signal-02.txt Randy Bush