[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 07 April 2020 16:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A83A0DA1; Tue, 7 Apr 2020 09:03:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158627541271.31464.16065110875282211603@ietfa.amsl.com>
Date: Tue, 07 Apr 2020 09:03:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BEJxpBv1sl8Hn27WFkpmcbUkwVA>
Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 07 Apr 2020 16:03:33 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-ov-egress-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:



[IIRC the mention of "updates 6811" is queued already.]

Section 1

   As the origin AS of a BGP UPDATE is decided by configuration and
   outbound policy of the BGP speaker, a validating BGP speaker MUST
   apply Route Origin Validation policy semantics against the origin
   Autonomous System number which will actually be put in the AS_PATH

(To the extent that the speaker applies outbound policy at all?  Or is
that required by being a "validating BGP speaker"?)

Section 3

   will (or would) be announced to the peer.  The effective origin AS
   may differ from that of the route in the RIB due to commonly
   available knobs such as: removal of private ASs, AS path
   manipulation, confederation handling, etc.

Do we feel a need to add a "but not limited to"?  Feels like overkill to

nit: earlier we wrote "private AS(s)"

Section 4

   Configurations may have complex policy where the final announced
   origin AS may not be easily predicted before all policies have been
   run.  Therefore it SHOULD be possible to specify an origin validation
   policy which MUST BE run after such non-deterministic policies.

nit: are complex policies necessarily non-deterministic (vs. "not easily