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

"Montgomery, Douglas (Fed)" <> Wed, 24 July 2019 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EE1C1205F8 for <>; Wed, 24 Jul 2019 13:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UeSfXaHTpERj for <>; Wed, 24 Jul 2019 13:28:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFBE9120494 for <>; Wed, 24 Jul 2019 13:28:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=L4plfFpDvsoyRB1F8qCwGXm6oS/2tfmlJW/LomIcjp3LeSOJHU49RSESvYPIKWTGBPpNOtrevw8l97OELs6+sXNrbEdbvqzqM2KXzW0v0x/iELv6vHWfwrnHK9/4okkm07weCrO0FPdC5j5d3YJ0Shv20jJ2/dnP2jFRpmAUBRmG8ssM1HW9PztURtgiKBh2I6o6uQWx3NAbxwSWLq9GsNMEhP9zPoPztD5aH+6U8MIPtIALOWRr+/fDwUoqTx4bPzw89Zlr7gg/9BDRl5E3QRfRH2Hb8zuxXN0MkPUoPkV+unC1WpJcSU64X+uKEM548/dlK28gSiQLh1uM0Gk6aQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkXJYnl211AnzIJSpOZYOw7nfrXGs9Fz+o1ieWOlIZI=; b=TQyMyy177pb5P0UysQdQwqOsYBsIqJlQBLDjvQKdCVYJMeOyYt5qJFvsZIXONTsjI1BBJDpkaN9OZfQwkRHglEAOomhCCLVJ6O/zLByIweMZROf5/ggi9nSy6vNBKawp8zquHFs6Fal3YNhxDtkDhrW7RzvTj+UBcbuE94MjgWTVQHFT1JseRAoldtb2H+l95N3I5aHGeWqg94uWT+EfZExekdtrQTwL8XjSKX08UCewEzw/2Q6Rw134E9oSp0qcPCwD7gUPMnaCRHhntsMcKxLSBUynhn/0XE5e9rGZKULn3gUG0ArmXgXMpHtvc1+Qu3xgwBWZrIryON+aca583w==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkXJYnl211AnzIJSpOZYOw7nfrXGs9Fz+o1ieWOlIZI=; b=KWaopHSvDpxBd+TbnZ5y73LLbeEIOEAcFoSbWn3CAQ4Ei1jLSMHEeS2QVrzCZ+6yEIPme7X8ymzrFDxK/XkGAsZJ/DiRw5c03XQLJHV4xhd4471irl8fVDEbrbpcCC84R+DCcIsXymzv/T1g4nz6emIgMeOIZpivb6rDh8aO2tA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 20:28:38 +0000
Received: from ([fe80::a073:b2d8:358d:ab15]) by ([fe80::a073:b2d8:358d:ab15%7]) with mapi id 15.20.2008.014; Wed, 24 Jul 2019 20:28:38 +0000
From: "Montgomery, Douglas (Fed)" <>
To: "Jakob Heitz (jheitz)" <>, Job Snijders <>, John Scudder <>
CC: "" <>
Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-signal-02
Thread-Index: AQHVQZfqdZEC8Ka1Vk6EHyhMX0ZkL6bYr+eAgACELECAAMJtgA==
Date: Wed, 24 Jul 2019 20:28:38 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.10.c.190715
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2052de0a-fcff-4e84-dc8a-08d7107582d4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BN7PR09MB2883;
x-ms-traffictypediagnostic: BN7PR09MB2883:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(396003)(376002)(136003)(13464003)(189003)(199004)(86362001)(14444005)(6436002)(5660300002)(53936002)(256004)(186003)(6486002)(110136005)(8676002)(66946007)(76116006)(91956017)(66574012)(6512007)(305945005)(81166006)(66446008)(36756003)(71190400001)(71200400001)(64756008)(66476007)(66556008)(81156014)(7736002)(316002)(58126008)(6306002)(966005)(6506007)(446003)(26005)(6116002)(25786009)(4326008)(2906002)(11346002)(561944003)(99286004)(3846002)(8936002)(68736007)(53546011)(14454004)(486006)(229853002)(76176011)(102836004)(33656002)(45080400002)(478600001)(6246003)(2616005)(476003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR09MB2883;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GnGmQ9DNR9+6HlLuoGN7/W1j9F9vwXweUnFm9XHQZChSEfV4V3+rfGI+OyDTV/wPl/HeMOhtjq3G2jkOt8Lv/jbdOL/8SoMDJjhii4ddBWdMRYuyvqxQoGc840OHnV3OuAUIiuQU4nD8Qa1V9Eyp9UlMwI4j9nK5JtiRtgD+28BdIAlY18f6ZdzE8dw7jwC7Z5gXxCdt61p4k1bY5q56oONxW1BEMVquy3TenSL3rdiy5WxYc49yUhDfhv4azQIK+vwP4JCGos2h+jRdXzIEyH5Rb68IUaOI6eXcF01heWYUlY5anxUzMwVy7mVAUZobT8j+eccnhyEY7Novpc1WZyhhAplg4LwjaPwzZt+0i+IdzR3PT52K7XrfXGNqD0M2OKZc7pl6PSJVUQcz6creq+Pxi9eiYkX8bsZKEAt8LUQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2052de0a-fcff-4e84-dc8a-08d7107582d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 20:28:38.6391 (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-Transport-CrossTenantHeadersStamped: BN7PR09MB2883
Archived-At: <>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 20:28:44 -0000

Set the validation state of a just received update to "undefined".  

Leave it to the operator's local policy to decide if they wish to "ignore undefined" (i.e., wait for validation before including in decision process), or not.

Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

On 7/24/19, 1:01 AM, "Sidrops on behalf of Jakob Heitz (jheitz)" < on behalf of> wrote:

    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
    -----Original Message-----
    From: Sidrops <> On Behalf Of Job Snijders
    Sent: Tuesday, July 23, 2019 2:00 PM
    To: John Scudder <>
    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,
    On Tue, Jul 23, 2019 at 8:48 PM John Scudder
    <> 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 mailing list;;sdata=6nCA3ZgvvF0SkldQUR1TVCiE1bYLhQwCLhxsT3A9Tzo%3D&amp;reserved=0
    Sidrops mailing list;;sdata=6nCA3ZgvvF0SkldQUR1TVCiE1bYLhQwCLhxsT3A9Tzo%3D&amp;reserved=0