Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

["Jakob Heitz (jheitz)" <[e-mail]>]

If ROV results in an objectionable validity, then the route is never installed.
If a "Sender" is to outsource the ROV procedure to an "Evaluator", then the
Sender MUST NOT install the route until the Evaluator returns an acceptable
validity.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[e-mail]> On Behalf Of Job Snijders
Sent: Tuesday, July 23, 2019 2:00 PM
To: John Scudder <jgs=[e-mail]>
Cc: [e-mail]
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

I have questions about this draft as well:

Why not tunnel VRPs inside BGP in a new AFI to populate the origin
validation cache on the edges? I think the BGP protocol has sufficient
hooks to model the RTR protocol fairly closely.

Or perhaps I don't understand the appeal of this mechanism. Why not
use RTR? Or if there is no room on the edge router for the memory a
VRP cache? If there is no room, can it even do Internet BGP?

Kind regards,

Job

On Tue, Jul 23, 2019 at 8:48 PM John Scudder
<jgs=[e-mail]> wrote:
>
> Things I would have said at the mic had time allowed:
>
> 1. For what it’s worth, RFC 4271 section 9.1 says you aren’t allowed to have this feature:
>
>    The function that calculates the degree of preference for a given
>    route SHALL NOT use any of the following as its inputs: the existence
>    of other routes, the non-existence of other routes, or the path
>    attributes of other routes.  Route selection then consists of the
>    individual application of the degree of preference function to each
>    feasible route, followed by the choice of the one with the highest
>    degree of preference.
>
> As I understand section 5 of the draft (as informed by Randy’s description), it is exactly mandating that we use the path attributes of other routes for the computation of the degree of preference.
>
> 2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue:
>
> - RR client C advertises route A to RR
> - RR checks A, decides it is invalid
> - RR advertises A, marked invalid, back to C. Call this A’.
> - C obeys section 5 and withdraws A from everyone (including RR)
> - Following the normal operation of BGP, RR withdraws A' from everyone (including C)
> - Now A’ is not in C’s Adj-RIB-In, but A is. I believe what Keyur said on the mic was that C is supposed to have persistently marked A as invalid in the earlier step, patching the obvious stability problem.
> - Now suppose the content of the RPKI changes such that A is now valid.
> … how does A ever find this out and un-suppress A? As far as I can tell, the answer is, “it doesn’t”. RR never sees a re-announcement of A, so it can’t re-validate and announce it to be valid. So it’s just wedged.
>
> 3. Finally, someone commented at the mic that the work to turn validation on at C is less than the work to debug, implement, and deploy this proposal. I agree.
>
> Given the above, I’m not in favor of adoption (though I’m always willing to be convinced).
>
> Thanks,
>
> —John
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidrops