Hi Randy,
Thanks for the response. I think we're getting closer. See below.
On Nov 14, 2011, at 2:45 PM, Randy Bush wrote:
>> 1) From Section 3:
>> ---snip---
>> A local valid cache containing all RPKI data may be gathered from the
>> global distributed database using the rsync protocol, [
Brian,
For BGP-4 updates, Geoff does provide the peak numbers observed
for prefix updates in 1 second intervals.
http://bgpupdates.potaroo.net/instability/bgpupd.html
For example:
Peak Prefix Update Rate per second: 1539
while
Average Prefix Updates per second: 2.76
I suspect the peak per
It will be as bursty as the sender of the bursts pleases.
A great way for the receiver of those non-urgent bursts
to insulate itself is to send them in a different tcp
session than regular BGP updates. It can then throttle
the BGPSEC bursts without affecting regular BGP.
If you consider a BGPSEC
At Mon, 14 Nov 2011 18:45:09 +0800, Shane Amante wrote:
>
> More specifically, what I've been attempting to ask here is how one
> configures, in one's _local_ RPKI cache (that syncs to the outside
> world), /where/ the RIR's publication points are on Day 1. Do I
> contact one RIR (which maintains
> It will be as bursty as the sender of the bursts pleases.
that is true today, someone can annouce at an arbitrary rate
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
> Thanks for the response. I think we're getting closer. See below.
i am too stuffed with good food to work tonight. can you catch me in
the terminal room tomorrow or whenever. i hang with the rpki interop
testing folk. we can talk and hack.
randy
On Fri, Oct 28, 2011 at 2:40 PM, Christopher Morrow
wrote:
> Seems that the authors, at least, expect this doc to be prepared for
> WGLC, could we do that concluding 11/11/11 please?
Sorry, didn't notice the date in the request.
I do have some brief comments about a few bullet points.
3.17 says
The difference is that today's updates all have the same urgency.
BGPSEC is not urgent. It doesn't matter if you don't receive a signature for a
few minutes.
An UNREACH is not signed.
--
Jakob Heitz.
On Nov 14, 2011, at 6:26 AM, "Randy Bush" wrote:
>> It will be as bursty as the sender of the
Rob/Steve, et al.,
Relative to the SIDR Origin Ops draft and local trust anchor (LTA)
configuration, I'm trying to understand how one would actualize
trust anchor locators (TALs) and LTAs in a deployment scenario and
was hoping you could help me here.
I think it's probably safe to assume ever
We have had no volunteers to take minutes or serve as jabber scribe. Those are
really needed for the meeting. Please consider volunteering.
--Sandy
From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy, Sandra
[sandra.mur...@cobham.com]
Sent:
On Nov 14, 2011, at 8:37 AM, Rob Austein wrote:
> Ultimately, the problem is the same as distributing DNSSEC TAs, or any
> other TA for that matter. Pretty much by definition, these things
> have to be configured outside the automated system, because they're
> the bootstrap data. Inclusion in d
Danny,
For purposes of this discussion, a LTA is semantically equivalent to a
collection of TAs plus a constraint list. Since LTAs are also a more
general mechanism (they can be shared by a group of like-minded folks
more easily than a constraint list -- just create a TAL pointing at
the LTA) and
I'm about to request some cleanup of the draft "replaced by" relationships. If
you see anything incorrect about the list below, please let me know.
The tools page already records some of these "replaced by" records. However,
the datatracker is authoritative and the datatracker has not caught
On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
> Danny,
>
> For purposes of this discussion, a LTA is semantically equivalent to a
> collection of TAs plus a constraint list. Since LTAs are also a more
> general mechanism (they can be shared by a group of like-minded folks
> more easily than a
I have uploaded all the slide sets (all four of them) received - for the mib
draft, the pfx-validate draft, the router cert profile and algorithms, and the
cpu load analysis.
If you think you have sent slides and do not see your slides listed, or what is
uploaded is not what you want there, ple
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Jakob Heitz
>
> The difference is that today's updates all have the same urgency.
> BGPSEC is not urgent. It doesn't matter if you don't receive a
> signature for a few minutes.
> An UNREACH is not signed.
[WEG] I don't to
I can not believe that it will be 2X.
First case: A beacon will very rarely cause a different
bestpath.
Second case: There is actually a changed route being updated.
You will receive both a regular update and a signature.
Only one of those will casue a new bestpath in the great
majority of cases.
In general, I don't like the idea of using an extcomm community to convey
a prefixes validation state, I think we should deal with this problem natively
(e.g., as BGPSEC inter-domain) if we're going to address the problem, in
particular if we're not going to address the AS Confederations problem
One clarification. I included Eric below as he was one of those who took
offense at the conclusion Steve drew from Brian's remark about colleagues.
Unfortunately, "you" is both singular and plural, so the text as written
implies that Eric colluded in the remark about "colleagues". I should
d
Eric,
i think we are making progress. thanks for the feedback.
...
I really think we should address these issues in a single document.
It seems like splitting this off into a separate/as yet unwritten
document is likely to cause some problems. In particular, since
that document does not y
> From: Jakob Heitz [mailto:jakob.he...@ericsson.com]
> Sent: Monday, November 14, 2011 8:47 PM
> To: George, Wes; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-
> sidr-bgpsec-reqs)
>
> I can not believe that it will be 2X
On Mon, Nov 14, 2011 at 7:02 PM, Danny McPherson wrote:
>
> On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
>
>> Layers 8+ are mostly out of scope for this list, so let me just say
>> that I am really hoping that IANA and the RIRs will get their
>> collective act together and issue a single TA bef
> One clarification. I included Eric below as he was one of those who
> took offense at the conclusion Steve drew from Brian's remark about
> colleagues. Unfortunately, "you" is both singular and plural, so the
> text as written implies that Eric colluded in the remark about
> "colleagues". I sh
On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
> On top of that if the resource is then re-certified (to the same or
> different end entity) how do the intermediate parties know which is
> the 'right' thing to do?
Agreed.. It's critical to highlight that LTA doesn't fix anything here
u
On Nov 15, 2011, at 10:53 AM, Stephen Kent wrote:
> Eric,
>
> i think we are making progress. thanks for the feedback.
>
>> ...
>>
>> I really think we should address these issues in a single document. It
>> seems like splitting this off into a separate/as yet unwritten document is
>> like
> From: George, Wes [mailto:wesley.geo...@twcable.com]
> Sent: Monday, November 14, 2011 7:04 PM
> To: Jakob Heitz; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
>
> > From: Jakob Heitz [mailto:jakob.
in the case you missed the note at the beginning, a nice gentleman
from Orange is going to videotape the entire slide-sets being
presented. Be aware of this when you walk to the mic/etc.
(If you have a problem with it, speak up first and he'll be nice)
thanks!
-chris
_
Sorry to jump in here, but I think that there is a drifting into conjecture...
It would be best to stay within the realm of facts.
> Great, so you don't disagree that beacons mostly cause no change.
> That should cover the bulk of BGPSEC updates.
>
> That brings us a long way down from 2X.
Ther
On Mon, Nov 14, 2011 at 10:57 PM, Danny McPherson wrote:
>
> On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
>
>> On top of that if the resource is then re-certified (to the same or
>> different end entity) how do the intermediate parties know which is
>> the 'right' thing to do?
>
> Agree
Thank you for clarification, indeed i'm keeping video trace of the meeting for
myself (in addition to the great amount of material already available, yes)
Thank you and I can stop the process of course if anybody complains,
Mickael
-Message d'origine-
De : sidr-boun...@ietf.org [mailto:
> From: Brian Dickson [mailto:brian.peter.dick...@gmail.com]
> Sent: Tuesday, November 15, 2011 12:16 AM
> Sorry to jump in here, but I think that there is a drifting into
> conjecture...
>
> It would be best to stay within the realm of facts.
[WEG] To clarify, the issue got conflated between the
Elisa,
In the meeting you noted that:
"Some route servers don't have an ASN, some use a private-asn"
Do you have some examples of these? Some quick doc searching (not by
me) noted that all docs point to using a public-ASN... Err, so
confusion reigns, could you help here?
-chris
__
> "Some route servers don't have an ASN, some use a private-asn"
i have had a small visit by a clue bat. if two RSs use AS 65666,
where is the cert for that AS? oops!
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
33 matches
Mail list logo
