Subject: [Idr] draft-ymbk-sidrops-rov-no-rr

From: Randy Bush <[email-masked]>
Date: Mon, 15 Nov 2021 06:28:23 -0800

some idr folk might be interested in

Name:		draft-ymbk-sidrops-rov-no-rr
Revision:	02
Title:		RPKI-Based Policy Without Route Refresh
Document date:	2021-11-15
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-rov-no-rr-02

Abstract:
   A BGP Speaker performing RPKI-based policy should not issue Route
   Refresh to its neighbors when receiving new RPKI data.  A method for
   avoiding doing so is described.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 15:45:05 +0100

HI Randy,

   When RPKI data cause one or more paths to be dropped, withdrawn, or
   merely not chosn as best path due to RPKI-based policy (ROV, ASPA,
   etc.), those paths MUST be saved and marked so that later VRPs can
   reevaluate them against then current policy.

And how about the case when we have an inbound policy and today RPKI says
this is a VALID path. Well tomorrow it may say it is INVALID for zoo of
reasons. So the above paragraph no longer covers those cases as those VALID
today would not be per the above definition (specified in section 4) in its
original format kept in the Adj-Rib-In.

Thx,
R.

On Mon, Nov 15, 2021 at 3:28 PM Randy Bush <[email-masked]> wrote:

> URL:
> https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-rov-no-rr-02
>
> Abstract:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 15 Nov 2021 10:25:09 -0800

Robert,

Something has to happen to the route in question, new policy configured locally or change to the route? It doesn’t become INVALID out of a blue?

Cheers,
Jeff

> On Nov 15, 2021, at 06:45, Robert Raszuk <[email-masked]> wrote:
> 
> 
> HI Randy,
> 
> And how about the case when we have an inbound policy and today RPKI says this is a VALID path. Well tomorrow it may say it is INVALID for zoo of reasons. So the above paragraph no longer covers those cases as those VALID today would not be per the above definition (specified in section 4) in its original format kept in the Adj-Rib-In. 
> 
> Thx,
> R.
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 19:32:33 +0100

It sure can. RIR can adjust ownership of the prefix, RIR can have bugs, ASN
ownership can change etc ... It may or may not need to trigger an
actual BGP update and those two worlds are decoupled.

IMHO we should just mandate to keep shadow of the Adj-RIB-In pre policy or
offload the validation to local controller(s) fed by RPKI and BMP data.

Thx,
R.

On Mon, Nov 15, 2021 at 7:25 PM Jeff Tantsura <[email-masked]>
wrote:

> Robert,
>
> Something has to happen to the route in question, new policy configured
> locally or change to the route? It doesn’t become INVALID out of a blue?
>
> Cheers,
> Jeff
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 15 Nov 2021 19:39:18 +0100

Hi,

> original format kept in the Adj-Rib-In.

Those prefixes that are accepted "today" (for whatever RPKI status) are
not the problematic ones - those are already there, to be re-evaluated if
needed. 

Problematic is the stuff that the router forgot about, and now needs to
re-evaluate - without "soft in always", a route refresh is needed, which
is costly if the RTR database changes often.

So, yes, I support this draft.  Need to move over and subscribe there :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Job Snijders <[email-masked]>
Date: Mon, 15 Nov 2021 19:42:20 +0100

Hi Robert,

On Mon, Nov 15, 2021 at 07:32:33PM +0100, Robert Raszuk wrote:
> IMHO we should just mandate to keep shadow of the Adj-RIB-In pre
> policy or offload the validation to local controller(s) fed by RPKI
> and BMP data.

I think you and the authors are aligned in terms of desired outcome.

When you say "shadow of the Adj-RIB-In pre policy", it makes me wonder
if there is some kind of disconnect in our mutual understanding of the
definition what "Adj-RIB-In" means. As far as I understand the term,
Adj-RIB-In is "pre-policy". https://datatracker.ietf.org/doc/html/rfc4271#section-3.2

I'm not sure I a point to explicitly describe 'offload to controller',
because from a protocol description perspective in this context there is
no difference whether a 'traditional BGP router' or 'thing + controller'
is used.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 19:43:04 +0100

Ok I buy this line of thinking/explanation ...

But what still bothers me is the root cause stating that BGP speaker can
not have few extra MB of RAM to keep peer's full advertisement yet we want
to run RPKI Origin Validation on it.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 19:45:09 +0100

Hi,

By "shadow" I meant to (really) make sure it is pre-policy. I am not sure
if this is *always* pre policy :).

Kind regards,
Robert

On Mon, Nov 15, 2021 at 7:42 PM Job Snijders <[email-masked]> wrote:

> Adj-RIB-In is "pre-policy".
> https://datatracker.ietf.org/doc/html/rfc4271#section-3.2
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 15 Nov 2021 19:47:35 +0100

Hi,

> to run RPKI Origin Validation on it.

That seems to be an implementation oversight... so maybe the ID should
have stronger language towards that?  "Do not permit RPKI OV unless 
soft-in is also turned on" (and/or auto-enable)?

Vendor defaults are also different here today...

Gert Doering
        -- NetMaster

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Nov 2021 10:55:02 -0800

> soft-in is also turned on" (and/or auto-enable)?

this little hack is merely intended to warn and to allow constrained
routers which can not keep full adj-rib-in to do rov with less damage.

beware of boiling ocean.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Nov 2021 11:00:43 -0800

> routers which can not keep full adj-rib-in to do rov with less damage.

sorry.  to be clear; in this day of lotso ram and many core cpus, it
would seem hard to justify not keeping the full adj-rib-in.

but not everyone has shiny new hardware.  and there is real code out
there which sucks caterpillar snot.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 20:03:19 +0100

> with less damage.

Maybe instead of messing up with Adj-RIB-In selective state to be kept we
could just suppress Route Refresh Requests when triggered by RPKI
updates to a much less conservative interval ?

Would that not solve the issue ?

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Nov 2021 11:05:46 -0800

> Would that not solve the issue ?

no, changing the granularity of stupidity does not amke it smart.  my
dozen peers at the IX will still be pissed off and i will still get
large spikes when they answer my rr reqs.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Nov 2021 14:07:37 -0500

> would seem hard to justify not keeping the full adj-rib-in.

I'm not deeply following operational practices for the use of rpki-rtr right
now.  Is there current operational wisdom about how often you permit your
caches to churn?

If so, perhaps a quick comment in the draft that you can minimize impact of
these older routers by minimizing the cache churn?

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Mon, 15 Nov 2021 20:23:45 +0100

On Mon, Nov 15, 2021 at 02:07:37PM -0500, Jeffrey Haas wrote:
> > > this little hack is merely intended to warn and to allow
> > > constrained routers which can not keep full adj-rib-in to do rov
> > > with less damage.
> > 
> I'm not deeply following operational practices for the use of rpki-rtr
> right now.  Is there current operational wisdom about how often you
> permit your caches to churn?
> 
> If so, perhaps a quick comment in the draft that you can minimize
> impact of these older routers by minimizing the cache churn?

An interesting suggestion.

Some RPKI RP cache implementations already default to 'once an hour'. An
internet-draft WIP [5] suggests something along the lines of "between
once an hour and every 10 minutes", however the currently published RFC
(8182) says something that suggests along the lines of (rephrased) "poll
as frequent as every minute". There are quite some RP implementations
deployed in the wild which adhere to that published RFC, and
unfortunately have not yet been updated to implementation versions which
folow the suggested RPKI fetching slow down.

This phenomenon probably needs to be tackled via both backporting some
kind of fix to 'older hardware' (either the suggested hack, or enabling
"soft-reconfig inbound always"' by DEFAULT on older versions), and via
the RPKI RP cache implementations (but that now seems covered in all
current versions).

Kind regards,

Job

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing
[8182]: https://datatracker.ietf.org/doc/html/rfc8182

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Nov 2021 11:23:59 -0800

> permit your caches to churn?

cf. granularity of stupidity

> impact of these older routers by minimizing the cache churn?

the pressure on rpki data has been toward being more responsive, not
less

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Nov 2021 14:58:50 -0500

Job,

> > permit your caches to churn?

[...]

> the RPKI RP cache implementations (but that now seems covered in all

Not discarding routes from your Adj-Ribs-In is probably the best option,
certainly.

Randy's other commentary seems to be emphasizing the main part of the pain
is effectively self-inflicted: If you quickly and consistently distribute
route validation updates in a consuming network, implementations that are
using route refresh to deal with those updates by doing what they're told -
issuing refreshes.  (A loose comparison to network-wide impact in SPF load
when churning your IGP can be made.)

Certainly an IXP Route Server is a good example of the problem.  However,
this seems a more general operational consideration for a network.  In the
absence of the ability to retain your Adj-Ribs-In, there are a limited
number of tools in the toolbox:

- Reduce the churn in rpki-rtr.
- Immediately issue the refreshes, but receivers may choose to pace the work
  to avoid overloading the router.
- Defer issuing the refreshes.
- Flag the need for a refresh and permit the operator or external tooling to
  do the job.  In the presence of additional network telemetry, this may be
  a better option in some circumstances.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Mon, 15 Nov 2021 21:16:27 +0100

On Mon, Nov 15, 2021 at 02:58:50PM -0500, Jeffrey Haas wrote:
> Randy's other commentary seems to be emphasizing the main part of the
> pain is effectively self-inflicted: If you quickly and consistently
> distribute route validation updates in a consuming network,
> implementations that are using route refresh to deal with those
> updates by doing what they're told - issuing refreshes.

I concur it partially self-inflicted, but keep in mind that any EBGP
peers receiving those ROUTE REFRESH messages as a result of this
phenomenon didn't ask for refreshes. Operators are learning about this
infliction 'the hard way'.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2021 21:21:23 +0100

> i will still get large spikes when they answer my rr reqs.
>

Nothing should stop your implementation to send rr reqs in delta time
sequence to the peers.

Note that route refresh if negotiated go out anyway. And often they usually
go out to all peers in the same time. They get triggered not only by policy
change but also by periodic state sync with enhanced route refreshes.

Question: Is there written in any RFC that RPKI OV can only be activated
when your peer supports route refresh or you have local soft-reconfig-in
enabled on a given peer ? If not upon each RPKI update we would be doing
session reset ?

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Nov 2021 15:29:25 -0500

> infliction 'the hard way'.

That's understood.  This isn't any different than any other over-aggressive
provisioning tool's impact.  In this case, it just happens to be coming in
from a protocol.

As this thread points out, the industry seems to be moving to more and more
aggressive distribution of the RPKI state.  While we often talk about
"boiling the ocean" in terms of trying to solve too large of a problem,
we're highlighting that we may be trending the other way.  Given an
aggressive enough ROA distribution infrastructure, a single update may cause
the Internet at large to burn CPU to deal with the route re-evaluation
impact.  

A pebble tossed into the ocean and causing it to boil is likely not the
intended impact.

-- Jeff (the IGP people are likely laughing at us now...)

---

From: Job Snijders <[email-masked]>
Date: Mon, 15 Nov 2021 21:35:08 +0100

On Mon, Nov 15, 2021 at 03:29:25PM -0500, Jeffrey Haas wrote:
> A pebble tossed into the ocean and causing it to boil is likely not
> the intended impact.
> 

Thank you for sharing your insights and wisdom :-)

Kind regards,

Job