Re: [Idr] draft-ymbk-sidrops-rov-no-rr

Robert Raszuk <robert@raszuk.net> Mon, 15 November 2021 18:32 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8C83A060D for <idr@ietfa.amsl.com>; Mon, 15 Nov 2021 10:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 Xy3n2Yk-HH_w for <idr@ietfa.amsl.com>; Mon, 15 Nov 2021 10:32:46 -0800 (PST)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACDA3A05A7 for <idr@ietf.org>; Mon, 15 Nov 2021 10:32:46 -0800 (PST)
Received: by mail-ua1-x932.google.com with SMTP id i6so36866652uae.6 for <idr@ietf.org>; Mon, 15 Nov 2021 10:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a9tcM4/JSfG0+IC9wzIs9jRQspEP4NTbQ5rtcCASTR8=; b=MBuER5mSAVWMWtWktD5jkcJX2o84X+x0U+RhYzrQSiCr6LA/9+n8uNmOl8lelsfY2E MX9I3RBQamjfL/YAUHa4UBDTn2l4eGAEW5yudqgFJWg3LW2Dqa2YynqoM/qPnhZyDEkM 0bhLTiZ0IYYUmpb/6MF5tHOoVdAmYj8reGhKj5eXpYuo1ymqB/w3dqn1XavUaFxHjj27 TlRwGsPibW+LIdHBJpyNsEFFnGYj1sZ+hY4QUZKt5T3bCohliD4CCVu1MBqup5OztfyY 73Z9sR8QyDjnF5kruyHBZMF9L1SP2QZM0pk1NfGyQihn8+eJpm9GXC/STbM6Jq6E7rWh b56w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a9tcM4/JSfG0+IC9wzIs9jRQspEP4NTbQ5rtcCASTR8=; b=6p6wwhiw4MRy8h1UoguNGBMR9Z/6Fvjxi2av0qnJnhfFM8z+2nxJBtpQcj96t1IwW9 r74RVBZmn7M1a3ZzY5rg+nMYdrg55YXAt/6KfOu3PrP7agoC/zvXQ6dGx9XTUQptxQLG 2JDchI1+IBpRznZ/oNIrKTJv9MUE3KQgvteBdoAu3uHXLBk7ULaywwl84jlWCOFSqON9 yMIvkgjm/lAUt/1aviRYzG27w+8Stdl8VMKxdWUrtH7mFChvc8gzp6WupazuX7XnAfFw qQmT5A8EPMatLbFUkrQ0y3sj2OUwj33xXWBa+2cG+FiobaemUa+NVK0lPaEnnP+X6APk IZCA==
X-Gm-Message-State: AOAM533fuiUrQxvM/9Q7KVtxNzUXYqFXSBHnSeGu+XYTVtWZjDPhVkzi RcBL/OPDEFpwexK/C9CjHdV3ZgGGlH06IznjffrIbA==
X-Google-Smtp-Source: ABdhPJyky2PgqyfU2H79u0+Qs2IF7WBO3nGEnJ2DCxv/pdpgvSKuNMBmFJbSo3Mn565qH4qLRpSnVEmrDjOIWraziuc=
X-Received: by 2002:ab0:6354:: with SMTP id f20mr1341548uap.116.1637001164614; Mon, 15 Nov 2021 10:32:44 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMHUZ26KTQje5ZO0wVubHMfvvb3QwZZm_x+TmTpTChdUdw@mail.gmail.com> <D3405798-8BBC-465E-8F6B-0F55B213A58A@gmail.com>
In-Reply-To: <D3405798-8BBC-465E-8F6B-0F55B213A58A@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 15 Nov 2021 19:32:33 +0100
Message-ID: <CAOj+MMFTfEW6EuL+srSyDgu=466GegSdaU3ioBHWKqsvhV00Jw@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Randy Bush <randy@psg.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e9ffc705d0d80852"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jPnDSKlNmdez3SdM8D-aXdAO_zg>
Subject: Re: [Idr] draft-ymbk-sidrops-rov-no-rr
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 18:32:52 -0000

It sure can. RIR can adjust ownership of the prefix, RIR can have bugs, ASN
ownership can change etc ... It may or may not need to trigger an
actual BGP update and those two worlds are decoupled.

IMHO we should just mandate to keep shadow of the Adj-RIB-In pre policy or
offload the validation to local controller(s) fed by RPKI and BMP data.

Thx,
R.

On Mon, Nov 15, 2021 at 7:25 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Robert,
>
> Something has to happen to the route in question, new policy configured
> locally or change to the route? It doesn’t become INVALID out of a blue?
>
> Cheers,
> Jeff
>
> On Nov 15, 2021, at 06:45, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
> HI Randy,
>
>    When RPKI data cause one or more paths to be dropped, withdrawn, or
>    merely not chosn as best path due to RPKI-based policy (ROV, ASPA,
>    etc.), those paths MUST be saved and marked so that later VRPs can
>    reevaluate them against then current policy.
>
>
> And how about the case when we have an inbound policy and today RPKI says
> this is a VALID path. Well tomorrow it may say it is INVALID for zoo of
> reasons. So the above paragraph no longer covers those cases as those VALID
> today would not be per the above definition (specified in section 4) in its
> original format kept in the Adj-Rib-In.
>
> Thx,
> R.
>
>
> On Mon, Nov 15, 2021 at 3:28 PM Randy Bush <randy@psg.com> wrote:
>
>> some idr folk might be interested in
>>
>> Name:           draft-ymbk-sidrops-rov-no-rr
>> Revision:       02
>> Title:          RPKI-Based Policy Without Route Refresh
>> Document date:  2021-11-15
>> Group:          Individual Submission
>> Pages:          6
>> URL:
>> https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-02.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-rov-no-rr-02
>>
>> Abstract:
>>    A BGP Speaker performing RPKI-based policy should not issue Route
>>    Refresh to its neighbors when receiving new RPKI data.  A method for
>>    avoiding doing so is described.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>