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

Benjamin Kaduk <kaduk@mit.edu> Wed, 08 April 2020 04:42 UTC

Return-Path: <kaduk@mit.edu>
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 045B33A0B9F; Tue, 7 Apr 2020 21:42:34 -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 gQ6yiBOIlaf4; Tue, 7 Apr 2020 21:42:32 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 992FC3A0B9E; Tue, 7 Apr 2020 21:42:31 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0384gQ64015615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 00:42:29 -0400
Date: Tue, 7 Apr 2020 21:42:26 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Randy Bush <randy@psg.com>
Cc: Benjamin Kaduk via Datatracker <noreply@ietf.org>, sidrops@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-sidrops-ov-egress@ietf.org
Message-ID: <20200408044226.GO88064@kduck.mit.edu>
References: <158627541271.31464.16065110875282211603@ietfa.amsl.com> <m2y2r7817k.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2y2r7817k.wl-randy@psg.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tWJDFA9e_FpX6RMfTrnlHg_Luzg>
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: Wed, 08 Apr 2020 04:42:34 -0000

On Tue, Apr 07, 2020 at 01:55:59PM -0700, Randy Bush wrote:
> 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?

I think in my head it was like "any Route Origin Validation policy
semantics applied MUST be applied against the origin AS number that will
actually be put in the AS_PATH", but tweak (or reject) as desired; I have
no horse in this race.

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

I ... think I read past it.  Sorry!

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

Looks good.  Thanks!

-Ben