(holy giant text batman!) On Fri, Mar 22, 2013 at 8:50 PM, Oleg Muravskiy <o...@ripe.net> wrote: > > Christopher Morrow wrote: > > > On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy <o...@ripe.net> wrote: > > > Hi Christopher, > > Christopher Morrow wrote: > > > 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. oops, so... we need to be > clear in terminology here there are at least: o publication points - > places/machines AS Operators would make their authoritative information > available to the world. > > > In our analysis we associate number of CAs in the global RPKI with the > number of distinct IP resource holders. > > > sure, and as a proxy for that 'AS Operator', it's not a 1:1 correlation to > be sure but it should be reasonably close, no? > > > Well, I don't see why resource holders should correlate to AS operators. > Maybe... But see below. >
ah! I made you look :) > > You seem to associate publication points (that directly relate to CAs) with > AS Operators. Since it's a second place where publication points are > associated with AS Operators (another is the "RPKI rsync Download Delay > Modeling" presentation), I wonder if I miss something? > > > most likely you are not... I think I jump to 'CA == REPO == AS-Operator == > ASN allocated' because lacking any direct data otherwise it seems like a > good estimation of numbers. Essentially each ASN allocated is going to be a > repository that needs to be gathered, right? If there are 10% more > repositories due to EndSite allocations without an ASN also allocated to > them I think it's still in the ballpark to say "number of Repos == ASN > allocation number". I could be wrong. > > > Ok, then I'll continue with mine line of thinking. > From the RIR stats files that RIRs publish daily we could get the numbers of > distinct resource holders. They are: > > AFRINIC 1310 > APNIC 7957 > ARIN 35380 > LACNIC 4278 > > For the RIPE NCC you could not get this data from stats files, and the exact > number is difficult to get because of our model of provider-independent end > users. But in our registry I could count that it is at least 28912. > That brings the total to 77837. > > Now, these are only the first level resource holders under RIRs. They all > *must* have their own CAs in order to participate in RPKI. However, many of > these first-level resource holders are NIRs or LIRs, who distribute > resources further down to their clients. They could choose to manage their > clients' RPKI objects within their single CA, but could also give their > clients own certificates, creating next level of CA hierarchy. I find it > difficult to estimate how many LIRs will do this, and for how many of their > clients. But for RIPE NCC I could see that the number of organisation > objects in RIPE DB is 70746, and that should be the upper bound of the cool! so already the number of repositories could be north of 100k (given the other 5 regions)... 'could be'. In the end I think it'd be nice of the models (some of them at least) had the ability to see 'what if 5 repos? what if 500? 500,000?' which I think is what Capitan Kent got to in his last mail.... "yes, it's a parameter we can twiddle". Some of the more real-world measurement, which Admiral Bush is after, is indeed harder to do this with (I think), but knowing behaviour of the current system should help to extrapolate I would think. > number of CAs in our region. I don't have that number for other regions, and > don't know if it's applicable in the same way, especially where NIRs are > present. > > Hope that's clear and helps. > yes! thanks. -chris > -- > Oleg Muravskiy > RIPE NCC > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
