On 27 Mar, 2013, at 6:24 PM, Randy Bush wrote:
>> Yes, I assume
>> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
>> Which I think is a good estimate.
>
> actually, i think the number of pub points will be closer to the number
> of entries in the rir's datamesses
Stephen Kent wrote:
Oleg,
...
I'm not opposed to the 1AS = 1CA idea. It's just that in my mind RPKI associates with IP space holders, not AS operators,
because this is how we do RPKI on RIR level. And on this level we already have more distinct IP space holders than the number of
active AS.
> Yes, I assume
> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
> Which I think is a good estimate.
actually, i think the number of pub points will be closer to the number
of entries in the rir's datamesses, as they will be issuing the certs
based on their datam
>> Yes, I assume
>> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
>> Which I think is a good estimate.
>
>of publication points. != repositories
Arturo,
Please also see slide #15. We vary the # repositories over a wide range,
and the justification is somewhat alon
OK, I will use publication points from now own to avoid confusions.
-as
On 3/27/13 1:32 PM, Randy Bush wrote:
>> Yes, I assume
>> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
>> Which I think is a good estimate.
>
> of publication points. != r
> Yes, I assume
> http://tools.ietf.org/agenda/86/slides/slides-86-sidr-1.pdf slide 3.
> Which I think is a good estimate.
of publication points. != repositories
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinf
On 3/27/13 1:20 PM, Randy Bush wrote:
>> I think we are around the bushes.
>
> excuse me!!
>
>> We want to know an estimate of the number of CAs in the future.
>
> have you looked at sriram's and sk's work.
>
> randy
>
Yes, I assume
http://tools.ietf.org/agenda/86/slides/slides-86-s
> I think we are around the bushes.
excuse me!!
> We want to know an estimate of the number of CAs in the future.
have you looked at sriram's and sk's work.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Mar 27, 2013, at 10:24 AM, "Murphy, Sandra" wrote:
> On Wednesday, March 27, 2013 9:53 AM, John Curran said:
>
>> I believe it is fine as an indicator of potential CA entities within +/- 50%,
>> but even that is simply the best estimate at this time.
>
> No smiley?
Implied by context... :-
On Wednesday, March 27, 2013 9:53 AM, John Curran said:
>I believe it is fine as an indicator of potential CA entities within +/- 50%,
>but even that is simply the best estimate at this time.
No smiley?
--Sandy, speaking as regular ol' member
___
sidr
On Mar 27, 2013, at 9:42 AM, Oleg Muravskiy wrote:
> Yes, we also have cases when multiple members belong to a single legal entity.
> But I think we are not interested in different organisations as such, but
> rather the number of CAs.
> So the actual question is whether the number of RPKI CAs w
I think we are around the bushes.
We want to know an estimate of the number of CAs in the future.
The current number does not work because of all the reasons that we
already know.
Then, I found #CA = #AS a good estimate (yes, there are multiple
factors like an RI
John Curran wrote:
> On Mar 26, 2013, at 9:24 PM, Randy Bush wrote:
>
>> sorry. it is not you, it is the arin database (personally, all the rir
>> databases suck, they just suck differently:-). what the arin database
>> considers to be an organization does not correspond to what you consider
>>
On Mar 26, 2013, at 9:24 PM, Randy Bush wrote:
> sorry. it is not you, it is the arin database (personally, all the rir
> databases suck, they just suck differently:-). what the arin database
> considers to be an organization does not correspond to what you consider
> one,
Randy is correct - w
hi oleg,
>>> I count the number of distinct reg-ids in the RIR statistics files
>>> (ftp..net/pub/stats//delegated--extended-latest, where
>>> is in {afrinic,apnic,arin,lacnic}).
>> at least for arin, this algorithm produces a result off by a quite
>> large factor.
> I do
> $ cut -f8 -d'|' deleg
On 3/26/13 4:01 PM, Stephen Kent wrote:
> Carols,
>
> I am very happy to hear that LACNIC has been putting AS#s (allocated by
> LACNIC) in the
> certs you are issuing!
>
> If you compare the cert you have issued (w/o AS#'s) against RV or RIS
> data, what do you
> see:
> - are these prefixed
I haven't performed that analysis (how many source ASes per ORG-ID), it
could be an interesting one I'll try to find the time to do that
before Berlin.
Glad you like our resource certs :D
Warm regards,
~Carlos
On 3/26/13 4:01 PM, Stephen Kent wrote:
> Carols,
>
> I am very happy to hear tha
Carols,
I am very happy to hear that LACNIC has been putting AS#s (allocated by
LACNIC) in the
certs you are issuing!
If you compare the cert you have issued (w/o AS#'s) against RV or RIS
data, what do you
see:
- are these prefixed advertised?
- do they have one ASN associated with t
Hi Steve,
On 3/26/13 3:12 PM, Stephen Kent wrote:
> Carlos,
>> Adding to what Oleg mentions in LACNIC we also equal a user of the RPKI
>> system with a legitimate resource holder. It doesn't matter for us
>> whether the user (resource holder) has an AS or not.
> If the address space holder has an
Carlos,
Adding to what Oleg mentions in LACNIC we also equal a user of the RPKI
system with a legitimate resource holder. It doesn't matter for us
whether the user (resource holder) has an AS or not.
If the address space holder has an AS# allocated by LACNIC, then that
AS# belongs in the
cert y
Oleg,
...
I'm not opposed to the 1AS = 1CA idea. It's just that in my mind RPKI
associates with IP space holders, not AS operators, because this is
how we do RPKI on RIR level. And on this level we already have more
distinct IP space holders than the number of active AS. I don't know
much a
Adding to what Oleg mentions in LACNIC we also equal a user of the RPKI
system with a legitimate resource holder. It doesn't matter for us
whether the user (resource holder) has an AS or not.
In practice, we have quite a few resource holders with no AS, although
no one of them has yet created ROAs
Stephen Kent wrote:
> Oleg,
>
> Glad to see we are converging, a bit.
>>> ...
>>> But, irrespective of this detail, isn't it reasonable to use the number of
>>> (live) ASes as the basis for
>>> the number of pub points (CAs)? To first order, any entity that needs to be
>>> explicitly represented
Oleg,
Glad to see we are converging, a bit.
...
But, irrespective of this detail, isn't it reasonable to use the
number of (live) ASes as the basis for
the number of pub points (CAs)? To first order, any entity that needs
to be explicitly represented in the
RPKI is associated with an AS#, whet
Hi Randy,
Randy Bush wrote:
>> I count the number of distinct reg-ids in the RIR statistics files
>> (ftp..net/pub/stats//delegated--extended-latest, where
>> is in {afrinic,apnic,arin,lacnic}).
> at least for arin, this algorithm produces a result off by a quite large
> factor.
>
> randy
I do
Stephen Kent wrote:
> Oleg,
>
>> ...
>>> I agree that an LIR could behave the way you indicated, but in so doing
>>> it needs to track which
>>> other LIRs provide service to the customer in question, in order to
>>> generate ROAs for each of them. If
>>> it fails to do so, any connections to
Oleg,
...
I agree that an LIR could behave the way you indicated, but in so doing it needs to track which
other LIRs provide service to the customer in question, in order to generate
ROAs for each of them. If
it fails to do so, any connections to other LIRs may be ignored, as the NLRI in
q
Oleg,
Thanks for clarifying the term.
I defer to others' understanding of the database in question as to
whether this is a good estimator.
Steve
--
On 3/26/13 6:01 AM, Oleg Muravskiy wrote:
Stephen Kent wrote:
...
Ok, then I'll continue with mine line of thinking.
From the RIR stats f
> In our region such users normally receive a provider-independent (PI)
> address space from RIPE NCC directly, so they will have their own CA
> and will have to maintain it.
if PI becomes certifyable, while there will be a CA cert for each, and
EE/ROA etc, at least in the near term, it is likely
Hi Steve,
Stephen Kent wrote:
> Oleg,
>> No. You broke the line in the wrong place. I meant "many (NIRs or LIRs)".
> In your text the "many" is distributed over both terms, NIRs and LIRs. You
> should have just omitted NIRs,
> since there are not "many" of them .
>> Not necessarily. The LIR could
> I count the number of distinct reg-ids in the RIR statistics files
> (ftp..net/pub/stats//delegated--extended-latest, where
> is in {afrinic,apnic,arin,lacnic}).
at least for arin, this algorithm produces a result off by a quite large
factor.
randy
Stephen Kent wrote:
> ...
>> 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
>> APNIC7957
>> ARIN35380
>> LACNIC 4278
> What is the definition o
Oleg,
No. You broke the line in the wrong place. I meant "many (NIRs or LIRs)".
In your text the "many" is distributed over both terms, NIRs and LIRs.
You should have just omitted NIRs,
since there are not "many" of them .
Not necessarily. The LIR could create a ROA for client's assignment,
us
Hi Stephen,
Stephen Kent wrote:
> ...
>> 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
>> APNIC7957
>> ARIN35380
>> LACNIC 4278
> What is the
...
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
APNIC7957
ARIN35380
LACNIC 4278
What is the definition of a "distinct resource holder?" Does this
co
...
If the number of CAs is used to estimate the size of a global RPKI
repository (number of objects), then the distinction between hosted
and delegated model doesn't matter. It matters if you want to estimate
the number of different repositories to query. But I don't know what
to do with th
> During the first SIDR session I commented that I agree with the need
> to explore new paradigms for distributing RPKI repository data, but
> that i was very disappointed with the analysis being used to motivate
> the exploration.
the ripe crew have looked at server load issues. we've got client
On Mar 23, 2013, at 10:38 AM, Arturo Servin wrote:
> This would help to move a problematic CA out of the monolithic repo.
> However, this would make a cache to create multiple rsync sessions to
> retrieve objects and lowering its performance (according to Rob's
> measurements with RIPE N
On Mar 23, 2013, at 12:06 AM, Randy Bush wrote:
>> If the number of CAs is used to estimate the size of a global RPKI
>> repository (number of objects), then the distinction between hosted
>> and delegated model doesn't matter. It matters if you want to estimate
>> the number of different repo
On 3/22/13 11:40 PM, Christopher Morrow wrote:
> On Fri, Mar 22, 2013 at 9:33 PM, Oleg Muravskiy wrote:
hoping not to cut important parts
>>
>> Although in a hosted model it's possible to run just one CA and one
>> publication point for all hosted clients, in practice no one from RIRs is
>> d
> Although in a hosted model it's possible to run just one CA and one
> publication point for all hosted clients
yucchhy
> in practice no one from RIRs is doing that.
thank you
> If the number of CAs is used to estimate the size of a global RPKI
> repository (number of objects), then the distin
On Fri, Mar 22, 2013 at 9:33 PM, Oleg Muravskiy wrote:
>
> Randy Bush wrote:
>
> I have, a model that says:
> "If you want to publish a ROA, you need to have a CA and you need to
> run a publication point"
> land this a roa and a CA).
>
> Wherever did you get that? what is the ratio of hosted L
(holy giant text batman!)
On Fri, Mar 22, 2013 at 8:50 PM, Oleg Muravskiy wrote:
>
> Christopher Morrow wrote:
>
>
> On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy wrote:
>
>
> Hi Christopher,
>
> Christopher Morrow wrote:
>
>
> Comment 1 (also related with 44): I agree that ISPs may operate ca
Randy Bush wrote:
>> I have, a model that says:
>> "If you want to publish a ROA, you need to have a CA and you need to
>> run a publication point"
>> land this a roa and a CA).
> Wherever did you get that? what is the ratio of hosted LIRs to delegated
> today?
Although in a hosted model it's
Christopher Morrow wrote:
>
> On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy 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
On 2013-03-21 23:50, Randy Bush wrote:
i could conject that ten years from now we will have one repository
run
by itu-i.
Assuming you meant ITU-T, that option isn't looking nearly as bad as it
did a few years ago, at least I'll know what it takes to get operational
requirements considered t
On Mar 22, 2013, at 9:08 AM, "Osterweil, Eric" wrote:
> On Mar 22, 2013, at 9:57 AM, Randy Bush wrote:
>
>>> past experience points to the hosted model eventually looking like
>>> distinct repositories per customer, which looks like 'number of
>>> repositories == number of ASN allocated'.
>>
>
On Mar 22, 2013, at 9:57 AM, Randy Bush wrote:
>> past experience points to the hosted model eventually looking like
>> distinct repositories per customer, which looks like 'number of
>> repositories == number of ASN allocated'.
>
> actual experience is five large hosted repositories.
Randy, s
> past experience points to the hosted model eventually looking like
> distinct repositories per customer, which looks like 'number of
> repositories == number of ASN allocated'.
actual experience is five large hosted repositories.
randy
___
sidr mailin
On 03/22/2013 01:50 AM, Randy Bush wrote:
>> how do you propose we measure how large the number of CA/Repositories is
>> going to be in 1yr? 5 yrs? 10 yrs?
>
> we can not measure the future until it gets here. the best we can do is
> estimate it based on the present and past.
which was what I
> how do you propose we measure how large the number of CA/Repositories is
> going to be in 1yr? 5 yrs? 10 yrs?
we can not measure the future until it gets here. the best we can do is
estimate it based on the present and past.
i could conject that ten years from now we will have one repository r
On 03/22/2013 12:27 AM, Randy Bush wrote:
>>> So far the 1,300+ folks who have signed up for managed CA services
>>> have also let the RIRs manage their pub points, which dramatically
>>> reduces the number of repositories. That could change over time,
>>> e.g., if these
>
> this is measurement
>> So far the 1,300+ folks who have signed up for managed CA services
>> have also let the RIRs manage their pub points, which dramatically
>> reduces the number of repositories. That could change over time,
>> e.g., if these
this is measurement
> TODAY it reduces the number, yes. 100% agree.
> T
true, but the repository conversation stops at: "all gatherers in the
system have the data"
inside each ASN it's really up to the ASN operator to get from
gatherer -> cache -> router in a 'timely fashion'.
If you're signing a route with something, and your upstreams are
signing their secure
On Thu, Mar 21, 2013 at 5:42 PM, Danny McPherson wrote:
>
>> so, to me, this is just 'more objects with a tight(er) timeframe on
>> delivery' right?
>>
>> meaning: today you have (for sake of the conversation) relatively
>> static content in the repository, where data changes 1/2/3
>> objects/day,
so, to me, this is just 'more objects with a tight(er) timeframe on
delivery' right?
meaning: today you have (for sake of the conversation) relatively
static content in the repository, where data changes 1/2/3
objects/day, and it's important to get the data distributed, but
(again, for the conv
On 03/21/2013 05:14 PM, Stephen Kent wrote:
> Chris,
>> ...
>>
>> TODAY it reduces the number, yes. 100% agree.
>> TOMORROW the number of repositories, even those which are 'hosted' will
>> be split up by name and/or ip-address...
>
> I think the operative term is "might" vs. "will."
sure, I'm j
Chris,
...
TODAY it reduces the number, yes. 100% agree.
TOMORROW the number of repositories, even those which are 'hosted' will
be split up by name and/or ip-address...
I think the operative term is "might" vs. "will."
I have a feeling these will be like DNS servers and likely ripe (ha!)
poin
On Thu, Mar 21, 2013 at 4:42 PM, Danny McPherson wrote:
> On 2013-03-21 14:29, Chris Morrow wrote:
>
>> TODAY it reduces the number, yes. 100% agree.
>> TOMORROW the number of repositories, even those which are 'hosted' will
>> be split up by name and/or ip-address...
>>
>> I have a feeling these
On 03/21/2013 04:15 PM, Stephen Kent wrote:
> Chris,
>
>> On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush wrote:
> 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
On 2013-03-21 14:29, Chris Morrow wrote:
TODAY it reduces the number, yes. 100% agree.
TOMORROW the number of repositories, even those which are 'hosted'
will
be split up by name and/or ip-address...
I have a feeling these will be like DNS servers and likely ripe (ha!)
points for attack by ba
On 03/21/2013 04:11 PM, Stephen Kent wrote:
> Chris,
>
>> ...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 re
Chris,
On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush wrote:
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?
Chris,
...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%
On Thu, Mar 21, 2013 at 1:55 PM, Randy Bush wrote:
>> I have, a model that says:
>> "If you want to publish a ROA, you need to have a CA and you need to
>>run a publication point"
>>land this a roa and a CA).
>
> Wherever did you get that?
I figured in the worst case you'd end up with 1:1... I d
> I have, a model that says:
> "If you want to publish a ROA, you need to have a CA and you need to
>run a publication point"
>land this a roa and a CA).
Wherever did you get that? what is the ratio of hosted LIRs to delegated
today?
--
phone email, so sucky
___
On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush wrote:
>>> 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?
>> 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?
do we have anything other than conjecture on which to b
On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy 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 globa
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
On Mar 20, 2013, at 9:44 AM, Stephen Kent
> You cite DDoS mitigation as an example, whereas it seems to be more the
> example.
Bah.. How many examples do you need?
> Also, it's not clear
> that asserting a new origin AS for a target of such an attack is the only way
> to deal with the pr
Danny,
On 2013-03-18 10:47, Stephen Kent wrote:
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 tha
On 2013-03-18 10:47, Stephen Kent wrote:
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, typ
On Wed, Mar 20, 2013 at 1:29 AM, Randy Bush wrote:
>> your slide confuses me... with the arrows from ARIN -> cache1-asia
>> (etc) seeming to imply a push from rpki-ARIN (which I assume is the
>> pub point for arin?) to the cache1-asia system?
>
> push is your imagination. control flow is not inte
> your slide confuses me... with the arrows from ARIN -> cache1-asia
> (etc) seeming to imply a push from rpki-ARIN (which I assume is the
> pub point for arin?) to the cache1-asia system?
push is your imagination. control flow is not intended, otherwise
interpub would be unnecessarily 'interesin
On Tue, Mar 19, 2013 at 5:51 AM, Randy Bush wrote:
>> 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.
>> o 'gatherer' machines - machines an AS O
On Mon, Mar 18, 2013 at 12:22 PM, Bryan Weber wrote:
> Anyway, as someone who has considered this in the past I just wanted to
> document some of my thoughts regarding the idea.
awesome, thanks! I didn't imagine one monolithic repository, but one
per pub-point.. I don't think conflicts exist if y
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 th
I'll just address one of your comments here and I'll save the rest until I have
time to talk to Tim and Oleg as we update this document based on all the
feedback.
I had proposed to the mailing list a DVCS like approach to replace rsync, but
after more consideration I joined with Tim and Oleg to
I'm not a fan of word in general.. but this comment numbering rules ;)
On Mon, Mar 18, 2013 at 10:33 AM, Arturo Servin wrote:
> 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 thi
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
Stephen Kent wrote:
> During the first SIDR session I commented that I agree with the need to
> explore new
> paradigms for distributing RPKI repository data, but that i was very
> disappointed with
> the analysis being used to motivate the exploration.
>
> Attached are my comments on the I-D in
82 matches
Mail list logo
