Arturo,
Hi,
Some comments about Steve comments:
Comment 1 (also related with 44): I agree that ISPs may operate caches
in behalf end-users ASNs, but also I think that more than 1 cache may be
operated by a single ISP. Imagine a global ASN operator with routers in
several places. Are they going to have just one master cache? Or are
they have one or two (backup), and just in one location? Considering
this, even the 40k clients may be low as worse case IMHO.
See Chris's comment re the issue of "gather's" vs. caches, for a more
precise description of this issue.
Comment 10: Not sure if I understand the point, but because we do not
trust fully on BIND we also operate DNS with NSD. In fact, I agree with
the authors that we have a problem depending on just one implementation
of rsync.
My point was that there are circumstances in which there is a de facto
single implementation and
that folks have survived. But, I agree with the principle stated here,
so, never mind ,...
Comment 28: For LACNIC ~ 2,500 members and ~ 2,200 PI. But as opposite
to RIPE NCC, PI holders are members as well (not sure if this is
relevant to the numbers)
Thanks. I suspected that the dichotomty cited in the RIPE context might
not be representative of all RIRs, as your reply conformed.
Comment 31: I do not have numbers of prefixes per ROA, but it is a
number that we could get soon.
I think it will be useful to have such #'s from several sources.
Comment 44: Does any body has a pointer of that proposal?
http://www.iepg.org/2012-07-ietf84/120729-randy.pdf
Comment 46: This is hard to answer. I have heard some operators asking
for minutes to have fresh new ROAs. Some others do not mind and request
objects every few hours. What is the middle or agreed value? (also
related with 55)
There are at least two issue here: how quickly a new/changed ROA is
published
after it is created/modified, and how quickly one should expect all
RPs to have acquired this info. The RPKI propagation model for ROAs was
based on the observation that, typically, the binding between an address
space holder
and the AS originating routes to that space changed very infrequently, and
not very fast. Conversations with RIR staff supported this notion, based on
IRR DB experience. So, suggesting that this data needs to be propagated in
minutes, vs. 1/2 a day, is quite a change.
Comment 57: I think the reason is that CDNs today work on http and we
know them more or less well. Although possible it would be more
expensive and complex to have rsync-CDNs. Also this is related to
comment 54, the "single point" is "magically" distributed by the CDN
responding with the "closest" point as it is done today for http content.
My comment was independent of the use of CDNs; an RIR could maintain a
master DB
for RPKI data and push copies to multiple caches for access by RPs,
using rsync.
But, I agree that it is attractive to explore using CDNs, IF we can make use
of appropriate security mechanisms to ensure that RPs know that the
current version data
and deltas are authentic.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
