Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01

Randy Bush <randy@psg.com> Wed, 18 March 2020 01:16 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 B1B9B3A0D55; Tue, 17 Mar 2020 18:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xvJ2SPO8tZ9Q; Tue, 17 Mar 2020 18:16:07 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C613A0D58; Tue, 17 Mar 2020 18:16:06 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1jENJT-00070l-Bh; Wed, 18 Mar 2020 01:16:03 +0000
Date: Tue, 17 Mar 2020 18:16:02 -0700
Message-ID: <m2zhce799p.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Linda Dunbar via Datatracker <noreply@ietf.org>
Cc: ops-dir@ietf.org, sidrops@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org
In-Reply-To: <158448201565.32201.9748655174984394118@ietfa.amsl.com>
References: <158448201565.32201.9748655174984394118@ietfa.amsl.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/MtXVzIRLQJPrB56MPXVZDL-Exxs>
Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01
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, 18 Mar 2020 01:16:11 -0000

linda,

thanks for the review

> Section 3 Egress Processing only has one sentence stating that ...

the lack of more words was not an accident; a feature not a bug. :)

> "When applied to egress policy, validation state MUST be determined
> using the effective origin AS of the route as it will (or would) be
> announced to the peer."   What other choices there are ?  Are there any
> routers that support RFC 6480 RPKI not performing this step? how?

unfortunately yes.  see nick's and chris's emails.

first, too many implementations do not even apply rov policy on locally
originated routes, routes from ibgp, etc.

second, for rov processing, many, maybe most, implementations use the
'global' AS of the router (as if there was one giving multi-AS knobs).

chris's email kinda explains that last one pretty clearly.

the purpose of this draft is to explain that the problem exists and to
make the minimal statement of what implementations should do.  i believe
the text (i need to read robert's email three more times) is well
understood by rov implementors, and even serious bgp/rov ops.

randy