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

Randy Bush <randy@psg.com> Tue, 07 April 2020 20:56 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 46C7A3A12A8; Tue, 7 Apr 2020 13:56:26 -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 dpxbWqZhWWfz; Tue, 7 Apr 2020 13:56:24 -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 12F043A1257; Tue, 7 Apr 2020 13:56:01 -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 1jLvGJ-0001NE-SL; Tue, 07 Apr 2020 20:56:00 +0000
Date: Tue, 07 Apr 2020 13:55:59 -0700
Message-ID: <m2y2r7817k.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Benjamin Kaduk via Datatracker <noreply@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org
In-Reply-To: <158627541271.31464.16065110875282211603@ietfa.amsl.com>
References: <158627541271.31464.16065110875282211603@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/s1lbjq3bH0Due5Q_UDRd8-m0jZg>
Subject: Re: [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
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: Tue, 07 Apr 2020 20:56:27 -0000

benjamin:

thanks for the review

> 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"?)

a speaker applies policy in all circumstances.  some times a particular
vendor's syntax will apply 'allow' or 'deny' by default.  taking that
default is applying policy.  or am i being too pedanic?

but, point taken.  any suggested wording?

> 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
> me...

the "etc." was not strogh enough?

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

thanks

> 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
> predicted")?

you and alvaro both caught this one.  my ex-compiler-writer instinct is
"may not be statically predicted" but i fear that would not make things
more clear to the average protocol hacker.  post alvaro, i have

   Configurations may have complex policy where the final announced
   effective origin AS may not be easily predicted before the outbound
   policies have been run.  Therefore it SHOULD be possible to specify
   origin validation policy which will run after all non-validating
   outbound policies.

seem reasonable?  if not, send a clue

randy