Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

["George, Wes" <[e-mail]>]

On 3/18/15, 11:10 PM, "David Mandelberg" <[e-mail]> wrote:

>Are you suggesting comparison of all the data from each single cache as
>an atomic entity, or comparison of individual IPvX and Router Key PDUs?
>
>If the former, then I think that would work fine as long as a majority
>(or maybe even a plurality) of the caches has the exact same data. But
>what does the router do if this is not the case? If the caches all
>download from the RPKI at different times, then I would expect it to be
>common for no two caches to have the same data.
>
>If the latter, then the semantics depend heavily on exactly how the
>comparison is done. Lets say a CA simultaneously issues one ROA for {AS
>65536, 10.0.0.0/8} and another for {AS 65537, 10.0.0.0/8}. Some of the
>caches see the publication point before both ROAs are issued; some see
>the pub point after both ROAs are issued and published. Can you
>guarantee that the voting mechanism will always result in either both
>ROA payloads, or neither, being used? (If a router ends up using one but
>not the other, then a previously unknown route becomes invalid.)

WG] well, that is mainly why I brought up the concern. Voting comparisons
like this can be hard to do with this amount of data, so if it was our
intent to allow multiple full views, we need better guidance on how we
think it's most likely to actually work. I'm not sure we'd see enough
consistency between caches to benefit from atomic comparisons, so it may
be a matter of taking age and other things into account. Building or
adapting a voting algorithm seems like a lot of effort for what may well
be a corner case, but if we're going to allow retention of multiple
caches' data, we have to address the issue of how to handle disagreement
between caches. Unless perhaps this part of section 10 is just
poorly-worded and the intent was only ever to allow retention of other
cache's data to keep a quasi-complete view during a failover/resync, i.e.
As one entry is pulled from the new cache, its corresponding entries
[SHOULD/MUST] be purged from the other one(s), etc.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.