Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)

Chris Morrow <morrowc@ops-netman.net> Sun, 01 December 2019 21:31 UTC

Return-Path: <morrowc@ops-netman.net>
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 D01C3120110; Sun, 1 Dec 2019 13:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 XEbi2DRADJyC; Sun, 1 Dec 2019 13:31:44 -0800 (PST)
Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC62312008F; Sun, 1 Dec 2019 13:31:43 -0800 (PST)
Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 184903C2525; Sun, 1 Dec 2019 21:31:43 +0000 (UTC)
Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id F1B843BB; Sun, 1 Dec 2019 21:31:42 +0000 (UTC)
Date: Sun, 01 Dec 2019 21:31:42 +0000
Message-ID: <87r21nbum9.wl-morrowc@ops-netman.net>
From: Chris Morrow <morrowc@ops-netman.net>
To: Randy Bush <randy@psg.com>
Cc: Chris Morrow <morrowc@ops-netman.net>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "sidrops@ietf.org" <sidrops@ietf.org>, "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "draft-ietf-sidrops-ov-egress@ietf.org" <draft-ietf-sidrops-ov-egress@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <25CB2E64-D0B5-4D5F-A59F-4864D1C340E7@psg.com>
References: <87tv6jbyjd.wl-morrowc@ops-netman.net> <25CB2E64-D0B5-4D5F-A59F-4864D1C340E7@psg.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
Organization: Operations Network Management, Ltd.
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BYNLqbsUv4ktLCIeNaG16yJ1On4>
Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)
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: Sun, 01 Dec 2019 21:31:45 -0000

On Sun, 01 Dec 2019 20:40:14 +0000,
Randy Bush <randy@psg.com> wrote:
> 
> Many documents already say to be sure to issue ROA(s) for the AS(s)
> which announce the prefix. This document does not change that in the
> slightest. If we start reiterating practice and restating the obvious
> we will have a document three or more times as large but with zero
> real added value.  Let us not do that to this simple document.
> 

that seems fair. (provided that this was what Sriram meant I guess)

> randy, on a phone
> 
> > On Dec 1, 2019, at 12:07, Chris Morrow <morrowc@ops-netman.net> wrote:
> > 
> > On Wed, 27 Nov 2019 21:17:08 +0000,
> >>> Is there such a thing as non-deterministic policy?
> >>> What does it mean to say that the outcome of applying
> >>> one or a set of policies is that it results in
> >>> a random AS being the origin AS?
> >> 
> >> non-derministic != random
> >> 
> >> in this case it is meant to refer to policy results which depend on
> >> exogenous data
> > 
> > The case probably is that at some point (with certain attributes set
> > by an upstream bgp speaker) OriginAS could be any of a set of values.
> > 
> > So, ideally the operator would just create ROA with the set covered,
> > right? (really 1 ROA per origin)
> > 
> > I think Sriram is getting to that, or is saying it in a way that
> > wasn't clear to me :)
> > 
> > -chris