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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 15 November 2021 18:25 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 429383A0486 for <idr@ietfa.amsl.com>; Mon, 15 Nov 2021 10:25:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=gmail.com
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 qbdpeVXhNl53 for <idr@ietfa.amsl.com>; Mon, 15 Nov 2021 10:25:12 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 A43093A045B for <idr@ietf.org>; Mon, 15 Nov 2021 10:25:12 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id w33-20020a17090a6ba400b001a722a06212so389629pjj.0 for <idr@ietf.org>; Mon, 15 Nov 2021 10:25:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=vElr4iUJumo+WlD4YOYhTrvw6WSGLTOzkZydvyqmJ/A=; b=FzBLfOn9xelEdgXUqWUqx/hQ3PJSC+AGdm4kcdHhaEwxcotACtCIJCILewExCBo7DT SmH8Hp/fAvEBCiXo/hZljOiabVtupCuelQmIp595XrpzpbNuhakPgfDEAnpxJ3Hz5kcg SYMh6KoHerX7qwdxtYWhvWul9w3EX7HT7BNNHKfJsRAQHXNlYui/EzeR/j9h2MLk2j3P jREPsOElqCaNPntQMz3Jy5uCGmL32+Wi8VcpEbUJkZXBgeFf3t8xySdIKk3TddQ1yfaO 7bGFlYaxtpi9V/cO/2HcNTkaeoJUdjsc78F4BEU6g2u8daoySIzHrZ9aMI5E9D5/H+t+ YO7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vElr4iUJumo+WlD4YOYhTrvw6WSGLTOzkZydvyqmJ/A=; b=Fpvi9h41Ps5nZoCgizM1ZFJ9BUm/AfYvZk34fIqdU5xubFnH+gAqZ6ooYUATMJsrLv cIZ2/gYWFFVzZ2iX4xK9eT0bvQmeS+LYql0MmkV3442oHUHSNT1tGLNY0I+9+A7Uj8ZU bB6YwrqbrDEE2rmNta7Cwow7dRQrl1cVTtFpC4jo5RnmeGMCUwnSbiCsLZ32QxOAQ4mU GOY3+6qkpqlnd6tE2mONWs8Z794V+KJAsg4gRS1DzfKhXx00QA9G6u+/cn8zEABfCqHP QWwaCXayjYS+2zbsGzIj41LGFAu3e9wDbLK2q06MdprAh+BHafNYsEZorGlbHjcOUiB1 J+bw==
X-Gm-Message-State: AOAM531DSv91+WVlo72IcTI23Tb2mHMLLw/NPPtPD/OgvX/rLgEYPnHb gQYg0DdLdcmbTgnFmTrq+mxxS8QOWdYHMg==
X-Google-Smtp-Source: ABdhPJxYZvli/AVMq4hK/EVtH0WHvA0QTuzfMaCnK6fv2QNVpB8+DbM4QR7bfaa45gwGIosc4fLP6g==
X-Received: by 2002:a17:902:b097:b0:141:ec7d:a055 with SMTP id p23-20020a170902b09700b00141ec7da055mr37402664plr.3.1637000711232; Mon, 15 Nov 2021 10:25:11 -0800 (PST)
Received: from smtpclient.apple (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id j9sm11546659pgt.54.2021.11.15.10.25.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Nov 2021 10:25:10 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-D47D9EE9-EC93-40D0-8A06-C8ACA7D874B8"
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Nov 2021 10:25:09 -0800
Message-Id: <D3405798-8BBC-465E-8F6B-0F55B213A58A@gmail.com>
References: <CAOj+MMHUZ26KTQje5ZO0wVubHMfvvb3QwZZm_x+TmTpTChdUdw@mail.gmail.com>
Cc: Randy Bush <randy@psg.com>, idr@ietf.org
In-Reply-To: <CAOj+MMHUZ26KTQje5ZO0wVubHMfvvb3QwZZm_x+TmTpTChdUdw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19B74)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LCbi_PXDPwjzmVSUPEQdBW7Shyg>
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:25:17 -0000

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