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 be clear,
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
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
pointing out
On 30 Mar 2012, at 11:44, Christopher Morrow wrote:
On Fri, Mar 30, 2012 at 4:53 AM, Andy Newton a...@arin.net 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
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. Before declaring
Speaking as regular ol' member.
Too bad you couldn't make the meeting, Danny.
This is in bgpsec path validation and the signalling would go no further than
the bgpsec path validation would go.
A method of signalling that was mentioned was the validity periods on the
router keys so all RPKI
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 in its
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.
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.
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
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas jh...@pfrc.org 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.
On 3/29/12 10:24 , Christopher Morrow wrote:
On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas jh...@pfrc.org 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
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
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
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-gen rpki
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
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
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 done on cron
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
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
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
Jeff,
On 28/03/12 6:19 PM, Jeffrey Haas jh...@pfrc.org 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
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 resource
23 matches
Mail list logo
