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

Chris Morrow <morrowc@ops-netman.net> Tue, 03 December 2019 04:28 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 6266412008F; Mon, 2 Dec 2019 20:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.69
X-Spam-Level:
X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 eq04h_4xbkOF; Mon, 2 Dec 2019 20:28:41 -0800 (PST)
Received: from relay.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59D712008C; Mon, 2 Dec 2019 20:28:40 -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 DB3443C27B9; Tue, 3 Dec 2019 04:28:39 +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 A902A56A; Tue, 3 Dec 2019 04:28:39 +0000 (UTC)
Date: Tue, 03 Dec 2019 04:28:39 +0000
Message-ID: <877e3ekp6w.wl-morrowc@ops-netman.net>
From: Chris Morrow <morrowc@ops-netman.net>
To: Randy Bush <randy@psg.com>
Cc: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "keyur@arrcus.com" <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-ov-egress@ietf.org" <draft-ietf-sidrops-ov-egress@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <m2v9qyz6a0.wl-randy@psg.com>
References: <87tv6jbyjd.wl-morrowc@ops-netman.net> <25CB2E64-D0B5-4D5F-A59F-4864D1C340E7@psg.com> <m2blsr1qzl.wl-randy@psg.com> <9AEB8712-8C36-4831-B119-87334D74CA59@nist.gov> <m2v9qyz6a0.wl-randy@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="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/V8DLG302GBCE7ZALPXpKxJxvtKk>
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: Tue, 03 Dec 2019 04:28:42 -0000

On Mon, 02 Dec 2019 22:55:51 +0000,
Randy Bush <randy@psg.com> wrote:
> 
> > I am somewhat puzzled, could you elaborate more what you mean by
> > "exogenous data".  Also I still don't see the "non-deteminable"
> > aspect?
> 
> prefix injected from static on A sent ibgp to B, and B has AS marking
> policy based on a community which may or not have been marked by A.

The general case here is likely that in a complex network (more than a
few routers), it's possible to have wonky things going on. Randy's one
example certainly is true, from a real network though I know of a case
where SOMETIMES prefixes get their origin-as set via initial creation
of the route (static route), and SOMETIMES the operator decided:

  "Oh, I should match on community-foo + attribute-bar and reset
   origin-as to BLOOP"

This leads to some hilarity when attempting to sort out RPKI/ROA data :(

  "Oh, that's clearly AS-BAR because we set that on the creation of
  the route!"

followed shortly by:

  "wait what? why is it AS-BLOOP??? WTF?"

In any case: "make the ROA you intend, all of them" is sound advice.
Verifying prior to shipping across your peering edge sure seems like
"being polite to the world" as well.