On Apr 1, 2012, at 1:57 PM, Robert Raszuk wrote:
> Hi Eric,
>
> > BGP is a great soft-state protocol (where some may define
> > ``great'' differently), but I don't currently tweet or update my fb
> > status over it.
>
> While I agree with 99% of what you said today on the list (especially
> po
Hi Eric,
> BGP is a great soft-state protocol (where some may define
> ``great'' differently), but I don't currently tweet or update my fb
> status over it.
While I agree with 99% of what you said today on the list (especially
pointing out need for solid requirements to document what sidr is tr
On Mar 29, 2012, at 1:16 AM, Jeffrey Haas wrote:
> Jakob,
>
> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>> Could we not put a freshness indication into the BGP update?
>> Then everyone that receives the new update would know to invalidate the less
>> fresh paths.
>
> Just to
On Mar 29, 2012, at 4:16 AM, Jeffrey Haas wrote:
> Just to be clear, this is not a route freshness mechanism I am
> recommending. What I am recommending is a signal that a repository has
> newer data that may be needed for validation.
>
> Given such a mechanism, we may be able to reduce the wor
On Fri, 30 Mar 2012, Arturo Servin wrote:
> >> Also, the presentation given at SIDR and IEPG indicated the study
> >> was done with only one RPKI validator. We have all three running in
> >> our lab and have noticed differences in speed over a local network
> >> with the same repository. Befor
On 30 Mar 2012, at 11:44, Christopher Morrow wrote:
> On Fri, Mar 30, 2012 at 4:53 AM, Andy Newton wrote:
>>
>> Also, the presentation given at SIDR and IEPG indicated the study was done
>> with only one RPKI validator. We have all three running in our lab and have
>> noticed differences in s
On Fri, Mar 30, 2012 at 4:53 AM, Andy Newton wrote:
>
> Also, the presentation given at SIDR and IEPG indicated the study was done
> with only one RPKI validator. We have all three running in our lab and have
> noticed differences in speed over a local network with the same repository.
> Before
On Mar 29, 2012, at 4:06 PM, Randy Bush wrote:
> o we could get much better rsync performance with a trivial change at
>the rirs.
I've learned that little related to the RPKI is trivial.
Is the actual issue observed with rsync documented anywhere, along with a more
descriptive solution? I
On 3/29/2012 3:58 AM, Jakob Heitz wrote:
Any place that does not receive a new BGP update can not be helped.
Even with a beacon.
Just to be clear, the explicit expire time approach to freshness does
work to age-out updates along a update path that is no longer
bgp-reachable from the origin.
> o but we do not know the long term scaling characteristics of the
> current rsync scheme.
While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable
deployment?
> o we could get much better rsync per
On Mar 29, 2012, at 5:01 AM, Randy Bush wrote:
>>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides
>>> such a mechanism
>> Not what I'm talking about.
>>
>> What notifies a cache that it needs to fetch new objects from a RPKI
>> repository? As best I understood, it's largely
just a note at the high level
o anyone who thinks rsync is not gonna do well for the scaling we are
likely to see in the next year+ is smoking some strong optimism.
we're only at 5k objects today, three months into the game.
o but we do not know the long term scaling characteristics o
On Thu, Mar 29, 2012 at 02:01:24PM +0200, Randy Bush wrote:
> ahh. yes. if we do a next-gen rpki flooding mechanism, that would be a
> good addition.
Agreed. It certainly belongs in there.
> to a bgp hacker everything looks like a nail, eh? how about a sip
> notification? :)
Just a minor co
>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides
>> such a mechanism
> Not what I'm talking about.
>
> What notifies a cache that it needs to fetch new objects from a RPKI
> repository? As best I understood, it's largely done on cron jobs now.
ahh. yes. if we do a next-ge
Randy,
On Thu, Mar 29, 2012 at 01:41:23PM +0200, Randy Bush wrote:
> > Just to be clear, this is not a route freshness mechanism I am
> > recommending. What I am recommending is a signal that a repository
> > has newer data that may be needed for validation.
>
> Serial Notify, sec 5.2 of draft-i
> Just to be clear, this is not a route freshness mechanism I am
> recommending. What I am recommending is a signal that a repository
> has newer data that may be needed for validation.
Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides such
a mechanism
randy
___
On 3/29/12 10:24 , Christopher Morrow wrote:
> On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote:
>> Jakob,
>>
>> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>>> Could we not put a freshness indication into the BGP update?
>>> Then everyone that receives the new update would kno
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote:
> Jakob,
>
> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>> Could we not put a freshness indication into the BGP update?
>> Then everyone that receives the new update would know to invalidate the less
>> fresh paths.
>
> Just t
Jakob,
On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
> Could we not put a freshness indication into the BGP update?
> Then everyone that receives the new update would know to invalidate the less
> fresh paths.
Just to be clear, this is not a route freshness mechanism I am
recommen
Any place that does not receive a new BGP update can not be helped. Even with a
beacon.
Therefore, a freshness indicator in the BGP update itself is enough to
invalidate less fresh updates.
Only freshen the BGP update when you actually have a dispute with your old
provider.
--
Jakob Heitz.
O
Could we not put a freshness indication into the BGP update?
Then everyone that receives the new update would know to invalidate the less
fresh paths.
Here is the key point:
The new update will reach everywhere that it needs to go.
Won't it?
No expiry time needed.
--
Jakob Heitz.
__
On Wed, Mar 28, 2012 at 09:02:24PM -0400, Danny McPherson wrote:
> On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:
> > Per my mic comment at IETF 83:
> > During the San Diego interim session we had discussed potentially signaling
> > in BGP the idea that a given AS may have fresher data available
sday, March 28, 2012 9:02 PM
To: sidr wg list
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP
On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:
> Per my mic comment at IETF 83:
> During the San Diego interim session we had discussed potentially signal
On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:
> Per my mic comment at IETF 83:
> During the San Diego interim session we had discussed potentially signaling
> in BGP the idea that a given AS may have fresher data available in its
> repository.
Shouldn't this problem be solved in the resourc
On Wed, Mar 28, 2012 at 01:30:03AM -0700, Terry Manderson wrote:
> I think this is interesting. I think I would further like an
> assessment/disussion of this "serial number" being consistent between the
> BGP information, the RPKI repository, and this through the validated cache
> and presented to
Jeff,
On 28/03/12 6:19 PM, "Jeffrey Haas" wrote:
> Per my mic comment at IETF 83:
> During the San Diego interim session we had discussed potentially signaling
> in BGP the idea that a given AS may have fresher data available in its
> repository.
>
> My original thought had been something along
Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its
repository.
My original thought had been something along the lines of a new AFI/SAFI
that contains this data. Matt L.,
27 matches
Mail list logo
