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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 09:03:32 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Abstract

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

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Apr 2020 13:55:59 -0700

benjamin:

thanks for the review

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

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

the "etc." was not strogh enough?

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

thanks

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

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Apr 2020 14:04:18 -0700

i pushed -03 in case folk want to review post corrections suggested so
far and in case anyone has the time to catch any new badness i managed
to introduce.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 Apr 2020 21:42:26 -0700

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

> the "etc." was not strogh enough?

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

> seem reasonable?  if not, send a clue

Looks good.  Thanks!

-Ben