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

[Benjamin Kaduk <[e-mail]>]

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