Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 24 July 2019 05:01 UTC

Return-Path: <jheitz@cisco.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 837CD12011D for <sidrops@ietfa.amsl.com>; Tue, 23 Jul 2019 22:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DNxy1T1p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rMe3S23W
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 nB6yQQIx2hBK for <sidrops@ietfa.amsl.com>; Tue, 23 Jul 2019 22:01:16 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1771112003F for <sidrops@ietf.org>; Tue, 23 Jul 2019 22:01:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4686; q=dns/txt; s=iport; t=1563944476; x=1565154076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=DNxy1T1pfH1jc/AqLa/v8pqxAHy7vjkIMOAebyMnezgKaHmzzLA/39cx 6ERjaitMKP9XZvAUuBJblI6wH37Lu4TVxKPtPzEJ2hpnj8htAhkKq4G0X nGjPIdL3ZkZQG9E0QWs0SDFX4T6YEa8J8RHu8x44TGFgci/F1xiZLVfOJ A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A7RLzGBWvUtHwukrL+B5pRLq2jU3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank4HMlDSE1N9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AACl5Tdd/5NdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4FEUANtVSAECyqDXUCDRwOOAIJbfpZSglIDVAkBAQE?= =?us-ascii?q?MAQEYCwoCAQGDekYCF4I3IzgTAQMBAQQBAQIBBm2FHgyFSgEBAQEDAQEKBhE?= =?us-ascii?q?RDAEBLAsBCwQCAQYCEQQBAQECAiYCAgIlCxUICAIEAQ0FCBqDAYFqAx0BAgy?= =?us-ascii?q?QQZBgAoE4iGBxgTKCeQEBBYUGGIITAwaBDCiLXxeBQD+BEUaCFzU+gmEBAQK?= =?us-ascii?q?BYYMJMoImjnibcQkCghmLd4gymAqNN5dRAgQCBAUCDgEBBYFnIYFYcBU7gmy?= =?us-ascii?q?CQgwXg06FFIU/cgGBKIo1K4IlAQE?=
X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208";a="297396647"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 05:01:14 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x6O51EWR003355 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 05:01:14 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 00:01:14 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 01:01:13 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 00:01:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M25YNEvaWCATZVcgSmt4l2BVHRDp14Ro4HMJQ2704elnFI//fmOrx2S1JyJOYUpSQsw4/LWjY7E0P888DJK7HFXmjEfg1L1KJYjDZzMJESYwpanAjvM0YpZwpIPefbsmchihbIDLo+aLdAqyagMgBYG4EQ4lPl45y1jAy+pWuxlnogeaXhEtVSStictoU5g1a03urWwE8GHzdECm2Q0LY3MGL2e3zIyueC6c/6VIFJumTSFb/MG7POIEirEULgTMae0wxtx+u24yS67LBh2aedkAgBUmsHaEH43R0ysZ/6js4XHhp7BYD3L0nRH3amtaXeCk1ByQjNI6NpjdwCMoSA==
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=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=Wms7aR52pikWxFkiK7RJPFsJEW/eoeRDuqGZ7p7hnLBl+KMIgLCZ4CN08O+UetWROUhwcljLoojVK6TzgdNN7vhi8FOnO4RdnTfPtQo4ydLtFfp2cKH1/tl4YvA3+NtaHt9tXODPzqXvogDYwNUPzUZT43aFXdDPgfHQvWe9t92bS1Lj7PLUw5EynKvPTybdeKW7MDnR8w1MtWFlPWWcQj03m8S+W6PJHH0GEwWgQhzR+QbcVRqtBultucL9gIs7cMMAwTKgK4vhB0T1Pz7qZgJZXD+H+Ti8KJdJEoEQY5Z9k21wPumVBLZv4JYooyZ3yBil+laF89Os9M0jbJY4Vg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFEpMHJxN7ENn+sZvHBRcOhk0G8wQf1yXBwu61jn8j4=; b=rMe3S23WAh7oOl9uVkgiPRh829OQHopDIiZgy1mk1Y30eOswhTV6tnAakU+zzc7twiPF3yrYoQWU+qWLERVR+1b9Crkg/9nUAkbGP7Rybo6qPCvKC3Q0sxvOoSmj75FRiEFHpBWUeUNSI+FVKnJd5+K0g0kMJg2kG3p0uoNI1oY=
Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3781.namprd11.prod.outlook.com (20.178.238.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Wed, 24 Jul 2019 05:01:12 +0000
Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2094.017; Wed, 24 Jul 2019 05:01:12 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Job Snijders <job@instituut.net>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-signal-02
Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkL6bYr+eAgACELEA=
Date: Wed, 24 Jul 2019 05:01:11 +0000
Message-ID: <BYAPR11MB375178BDAA447C3C6A052460C0C60@BYAPR11MB3751.namprd11.prod.outlook.com>
References: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net> <CACWOCC-qhjA1L6Xoi2J4cvW=Ksor3wENXc8wgmwQqHCYKZ6wVw@mail.gmail.com>
In-Reply-To: <CACWOCC-qhjA1L6Xoi2J4cvW=Ksor3wENXc8wgmwQqHCYKZ6wVw@mail.gmail.com>
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=jheitz@cisco.com;
x-originating-ip: [2001:420:c0c8:1001::216]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7e856ff-4045-4b04-2e08-08d70ff3f2d1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3781;
x-ms-traffictypediagnostic: BYAPR11MB3781:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR11MB37811E9E334A58054F91008BC0C60@BYAPR11MB3781.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(366004)(346002)(396003)(13464003)(199004)(189003)(561944003)(6436002)(478600001)(74316002)(476003)(66574012)(9686003)(55016002)(6306002)(52536014)(53936002)(76116006)(14454004)(86362001)(66556008)(5660300002)(6246003)(25786009)(66446008)(64756008)(229853002)(66946007)(66476007)(8676002)(8936002)(81166006)(81156014)(33656002)(110136005)(316002)(7736002)(186003)(76176011)(4326008)(71190400001)(305945005)(71200400001)(46003)(6506007)(53546011)(256004)(102836004)(2906002)(68736007)(966005)(6116002)(7696005)(486006)(99286004)(11346002)(446003)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3781; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 7Pz/CPPqOnaWCfqjdAr7FgulstQ1+qS2dNGFmT7W29O2BIgoWcUe308t8l47jIs2uQ1bbalzAqBKQdyE9FeDc3Fqvi1Y1WW4CI0psbigijEoKL4QXWRSR/Z1BFCAYCrBrs5JOGjYGOZm09OwbEqTZlDtqp/H2hJZUQBY1xF9AUJuJy4zIKNt3hzrmvOOWiGpPmByuBPSbEWC9dxmEdZ5mVdLHDtfmusgzVuhGe4kAhCLZBS9vCawREkAidIwAqaJRQA1TPj6Rioep3ef4ndLMous3RvaCP7rX850K2DYDsKGtY7QTewEHBNlBGOb/fmOEPe6qJYJRL361Rf0Kwk/6Qrsphe7I3ecBxtzUHSwp+qKaotgyxc0HJ/K0zoCHeaRDTHJE1suw7lJO2i3cxDlogA6n6ELZe/j93GKUkRRbRw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f7e856ff-4045-4b04-2e08-08d70ff3f2d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 05:01:11.9860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/_CMe6-zyxp_7M98HjkWHPwESjsM>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02
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: Wed, 24 Jul 2019 05:01:19 -0000

If ROV results in an objectionable validity, then the route is never installed.
If a "Sender" is to outsource the ROV procedure to an "Evaluator", then the
Sender MUST NOT install the route until the Evaluator returns an acceptable
validity.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Job Snijders
Sent: Tuesday, July 23, 2019 2:00 PM
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

I have questions about this draft as well:

Why not tunnel VRPs inside BGP in a new AFI to populate the origin
validation cache on the edges? I think the BGP protocol has sufficient
hooks to model the RTR protocol fairly closely.

Or perhaps I don't understand the appeal of this mechanism. Why not
use RTR? Or if there is no room on the edge router for the memory a
VRP cache? If there is no room, can it even do Internet BGP?

Kind regards,

Job

On Tue, Jul 23, 2019 at 8:48 PM John Scudder
<jgs=40juniper.net@dmarc.ietf.org> wrote:
>
> Things I would have said at the mic had time allowed:
>
> 1. For what it’s worth, RFC 4271 section 9.1 says you aren’t allowed to have this feature:
>
>    The function that calculates the degree of preference for a given
>    route SHALL NOT use any of the following as its inputs: the existence
>    of other routes, the non-existence of other routes, or the path
>    attributes of other routes.  Route selection then consists of the
>    individual application of the degree of preference function to each
>    feasible route, followed by the choice of the one with the highest
>    degree of preference.
>
> As I understand section 5 of the draft (as informed by Randy’s description), it is exactly mandating that we use the path attributes of other routes for the computation of the degree of preference.
>
> 2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue:
>
> - RR client C advertises route A to RR
> - RR checks A, decides it is invalid
> - RR advertises A, marked invalid, back to C. Call this A’.
> - C obeys section 5 and withdraws A from everyone (including RR)
> - Following the normal operation of BGP, RR withdraws A' from everyone (including C)
> - Now A’ is not in C’s Adj-RIB-In, but A is. I believe what Keyur said on the mic was that C is supposed to have persistently marked A as invalid in the earlier step, patching the obvious stability problem.
> - Now suppose the content of the RPKI changes such that A is now valid.
> … how does A ever find this out and un-suppress A? As far as I can tell, the answer is, “it doesn’t”. RR never sees a re-announcement of A, so it can’t re-validate and announce it to be valid. So it’s just wedged.
>
> 3. Finally, someone commented at the mic that the work to turn validation on at C is less than the work to debug, implement, and deploy this proposal. I agree.
>
> Given the above, I’m not in favor of adoption (though I’m always willing to be convinced).
>
> Thanks,
>
> —John
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops