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

[John Scudder <[e-mail]>]

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