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

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Mon, 02 December 2019 00:54 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 A1EBF12011B; Sun, 1 Dec 2019 16:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 L6_pJZ-HQ1X4; Sun, 1 Dec 2019 16:54:10 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20726.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::726]) (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 7A80A120052; Sun, 1 Dec 2019 16:54:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nI4PzcmxcR0Cp6yOmCx9gQbV7si5zU385otXMVhm0omH61qdz0EqnGMJNpqB/bmfITpp8raQ3wF2MkUQ8m2lSiRy6Q+ziqJ0fq6qBdysZdFivn/5N0N+dIGtv17v1xKajhFvoONqzWoqGJv4UypuT6wrjT4T/WDqecEW72+qz/bM6vSTO/3jC8stNfUEyiYYPXL5WSSP1JCwN5Bcs93ajJ0vaGzow7cJ+2pV5vFbqd761ySBfG92lFa8hNwsjLWjHcWrr22hd3hTNMuKssS2RxdenBEaBvoNaqs+DarFtegN55w9BygymKw2LTbQN6oFCIqWem/4X/juF63v8Q6mKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvuVGjcKP5VLg7uYOhRlY6JGlPoc7AODP3dGAr+1fKA=; b=BQCtvTrb4BhbPW/ECJ6NljcgHDGm68b0ZcykGYz5FbCau5wwlK3fZWYpYpfqNaRgvNbEp4JmTEhGAbIQxpZf3bdDsEBr2sMIqwS+YHuT/p0yZjMTxIloEeWxIE2P8lLAiEZ1znPTRMCgmeRSAkJok0RnZJncDTNmt0vhRLRjWsurQPuV+L0bG1EsT6wqelXgFbExX7PvyptsJr0JB4Caci8XxL0kPVAFB34LlMv8NxrexDcnhDQ5bFyoQM14gs9wpLokBQ093DnU46cH++szRQDl8nUv1ofHH0INn0V4xP7SBhgGNNAO6oNwcNgKRFcAm73yMk1FsjfaLrWyHnJWzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvuVGjcKP5VLg7uYOhRlY6JGlPoc7AODP3dGAr+1fKA=; b=EyTfNqjOETtebGf97XbNcSZK/61rUyPc6aU2tZLktE9BjcZdgXhA5qkrUuFq7nfnBNOgEKxnJWlJmPGXYvb682I9GNBHj4QAtCikOMrfzUqyLytO+J12AF9nenZemilihfkCe6V4VOqc6gdPfEDSjRBxBLUeVupzvtvpjp9UVUg=
Received: from DM6PR09MB3386.namprd09.prod.outlook.com (20.179.51.19) by DM6PR09MB2732.namprd09.prod.outlook.com (20.176.98.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Mon, 2 Dec 2019 00:54:08 +0000
Received: from DM6PR09MB3386.namprd09.prod.outlook.com ([fe80::3dc8:c3a3:e7eb:e1ed]) by DM6PR09MB3386.namprd09.prod.outlook.com ([fe80::3dc8:c3a3:e7eb:e1ed%4]) with mapi id 15.20.2474.023; Mon, 2 Dec 2019 00:54:08 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Chris Morrow <morrowc@ops-netman.net>, Randy Bush <randy@psg.com>
CC: "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>, "keyur@arrcus.com" <keyur@arrcus.com>
Thread-Topic: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)
Thread-Index: AQHVpWgKNx6EigmA/UCnwNYVbIcclKeluvoAgAAJRgCAAA5hAIAAMjJv
Date: Mon, 2 Dec 2019 00:54:08 +0000
Message-ID: <DM6PR09MB3386E0906EE0BDC12889173784430@DM6PR09MB3386.namprd09.prod.outlook.com>
References: <87tv6jbyjd.wl-morrowc@ops-netman.net> <25CB2E64-D0B5-4D5F-A59F-4864D1C340E7@psg.com>, <87r21nbum9.wl-morrowc@ops-netman.net>
In-Reply-To: <87r21nbum9.wl-morrowc@ops-netman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov;
x-originating-ip: [132.163.220.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ad857b56-ad10-4eea-ff45-08d776c22379
x-ms-traffictypediagnostic: DM6PR09MB2732:
x-microsoft-antispam-prvs: <DM6PR09MB273207A53959F80629EB00DF84430@DM6PR09MB2732.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(366004)(376002)(39860400002)(199004)(189003)(81166006)(81156014)(3846002)(66476007)(33656002)(71200400001)(4326008)(229853002)(55016002)(8936002)(478600001)(9686003)(76116006)(25786009)(6436002)(99286004)(91956017)(71190400001)(446003)(6246003)(186003)(110136005)(11346002)(7736002)(8676002)(76176011)(66446008)(305945005)(26005)(316002)(66556008)(54906003)(66066001)(52536014)(6116002)(256004)(64756008)(6506007)(74316002)(53546011)(7696005)(2906002)(102836004)(86362001)(14454004)(66946007)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB2732; H:DM6PR09MB3386.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MS9c9FKT50wkRSEP0du4zOt9dgRnaz0OOYo198H6BK7o0OZRgGYyR4iGco95ObOwX5E/l8L8IoYX46YwzHZ41ASu/usXGvZmHxe38KgWWdvyrusw5zk5y1zf9ouNRoV6FEqgq7fh6/rdEd3gbET/BMauj2qhtS4NllbmQ4yqsay7OYIL5A/MSsOQsSU8Yq1Cf02vVmWhMDC3I+1vuCw0vC2LM6Yt8521v/hROdEsjknmdDeWCGPZNyOZIeDBU3iREp6kREtxPAZ8ZudPuR+R6JIziVjk/9c79OGvpJKgkB9NuK0IJoS/x1rQ8nNljiNGXSmmDjjqNkpvxAlZ47qDvLqAcpBFOg0LrSScDrdiX+fbK1Xi8ecdQqRorcFKO80rGOanY5OQUOAWqWvSvgInVUo0G+HLn/8GACyrDYXPXLL0uvBael9z+KjWJIwuFqeE
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: ad857b56-ad10-4eea-ff45-08d776c22379
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 00:54:08.4966 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zE1EISM24bysdRS5osXoVPA+KIu7/hNG7OvwGipla0GjUlPHg5F1PxfhVy8ZmoD6LjBOf6WKilVW1KPz+tSDPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB2732
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/m16_wRHxKpp6gV9uD5sQrIaAI6k>
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: Mon, 02 Dec 2019 00:54:13 -0000

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

My problem was with these two sentences:

#1 
"Configurations may have complex policy where the final announced
   origin AS may not be easily predicted before all policies have been
   run."

Is it not the same as simply saying: 
Configurations may have complex policy where the final announced
   origin AS is determined only after all policies have been run.

Why not state that and keep it simple?

#2 
"Therefore it SHOULD be possible to specify an origin validation
   policy which MUST BE run after such non-deterministic policies."

What does it mean to say "specify origin validation policy"?
RFC 6811 has already specified the origin validation procedure (policy?).
The use of the term "non-deterministic policies" is ill advised.
The operator knows their complex policies and can determine
the origin AS that would result after the policies are applied.
So the sentence can be simply stated as:
Therefore, origin validation MUST BE performed after the policies are run.

I hope this clarifies what I was trying to say.

Sriram




________________________________________
From: Chris Morrow <morrowc@ops-netman.net>
Sent: Sunday, December 1, 2019 4:31 PM
To: Randy Bush
Cc: Chris Morrow; Sriram, Kotikalapudi (Fed); sidrops@ietf.org; sidrops-chairs@ietf.org; draft-ietf-sidrops-ov-egress@ietf.org; Jeffrey Haas
Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)

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