IETF Logo Mail Archive

Re: [Sidrops] AD Review of: draft-ietf-sidrops-rov-no-rr

Randy Bush <randy@psg.com> Fri, 24 June 2022 17:09 UTC

Return-Path: <randy@psg.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 BE4E1C14F749; Fri, 24 Jun 2022 10:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwZDjQRPRW5r; Fri, 24 Jun 2022 10:09:29 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E94C14F744; Fri, 24 Jun 2022 10:09:29 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from <randy@psg.com>) id 1o4mo8-0007wY-1I; Fri, 24 Jun 2022 17:09:24 +0000
Date: Fri, 24 Jun 2022 10:09:23 -0700
Message-ID: <m25ykqvvi4.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Warren Kumari <warren@kumari.net>
Cc: draft-ietf-sidrops-rov-no-rr@ietf.org, SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <CAHw9_i+VG6Vxmeq9EzTWNk+YmjVPSnf+5bw=hjj+Av=4jRG9gw@mail.gmail.com>
References: <CAHw9_iLrCv2oNynG13oJHmPwmfRm0Z2nC-9tKc0HEgRrT8A6ew@mail.gmail.com> <m2czf0xym5.wl-randy@psg.com> <m28rpoxyar.wl-randy@psg.com> <CAHw9_i+VG6Vxmeq9EzTWNk+YmjVPSnf+5bw=hjj+Av=4jRG9gw@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/NLJ6mOFT8XArFZAmU-CtBbctQtA>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-rov-no-rr
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 24 Jun 2022 17:09:30 -0000

> How is:
> 
> A BGP Speaker performing RPKI-based policy should not issue Route Refresh
> to its neighbors when receiving new RPKI data. This document updates
> RFC8481  by describing how to avoiding doing so by either keeping a full
> Adj-RIB-In or saving paths dropped due to ROV so they may be reevaluated
> with respect to new RPKI data.
> 
> The "important" bit is to explicitly mention the RFC it updates and how...

i had removed the "updates" flag.  i can put it back.  after all, we had
so much fun with it in 8210bis :)

      A BGP Speaker performing RPKI-based policy should not issue Route
      Refresh to its neighbors because it has received new RPKI data.
      This document updates RFC8481 by describing how to avoiding doing
      so by either keeping a full Adj-RIB-In or saving paths dropped due
      to ROV so they may be reevaluated with respect to new RPKI data.

randy

v2.23.0 | Report a Bug | By Email