On 3/15/10 2:42 AM, Tony Li wrote:
Interestingly, I'm not sure that this is worth fixing. Most BGP
implementations store a copy of all of the best paths that they've received
from neighbors. They then compute the 'best path' amongst this set and
advertise it appropriately. Truly fixing this
Indeed, you're trading systemic state for implementation optimizations,
in lots of places where issues such as this are amplified. 40%
duplicates in a system today ma not be a problem, however, if prefix,
origin, and path validation techniques are employed down the road in a
secure
On 20/03/2010, at 8:40 AM, Tony Li wrote:
Indeed, you're trading systemic state for implementation optimizations,
in lots of places where issues such as this are amplified. 40%
duplicates in a system today ma not be a problem, however, if prefix,
origin, and path validation
top posting: it's my fault for not stating clearly -- Since Amund's
msg said that
- Surprisingly, as much as 40% of churn consists of duplicate
announcements, which are unnecessary for correct protocol operation.
I was merely offering one explanation for the cause of the observed
Toni, you are raising an interesting issue. However, if the sending routers
do not check whether an update is duplicate, and if the receiving
routers do not check whether an update is duplicate, don't we create
a positive feedback loop? I mean, if a router X sends a duplicate
update to N other
Hi Paul,
Well, let's look at the flip-side for a moment. Imagine if there were
/no/ growth in prefixes. Is that good? I think the answer clearly is
no. No growth in prefixes implies no growth in the internet,
implies no growth in revenue for those who make money from activities
associated
On Mar 14, 2010, at 1:33 PM, Amund Kvalbein wrote:
Folks,
In this context, I think you might be interested in a measurement
study that will be presented at INFOCOM this coming week. The focus
of the study is BGP scalability with respect to churn rates. We have
analyzed six years of
On Mar 14, 2010, at 10:17 PM, Paul Jakma wrote:
On Mon, 15 Mar 2010, Robin Whittle wrote:
I thought that you were arguing against the existence of the
routing scaling problem, because in your first message in this
thread, you wrote:
However, it does not seem justified to say the
Paul raises a critical point that IMO gets insufficient attention here...
On Mar 15, 2010, at 3:35 AM, Tony Li wrote:
Hi Paul,
Well, let's look at the flip-side for a moment. Imagine if there were
/no/ growth in prefixes. Is that good? I think the answer clearly is
no. No growth in
On Sun, 14 Mar 2010, Tony Li wrote:
Actually, no growth in prefixes does not imply that there is no growth in
the Internet. You can still add customers within existing prefix
allocations and improve your addressing efficiency.
Hehe, My implicit assumption is that there's no significant
On Mar 15, 2010, at 1:13 PM, Paul Jakma wrote:
On Sun, 14 Mar 2010, Tony Li wrote:
Actually, no growth in prefixes does not imply that there is no
growth in
the Internet. You can still add customers within existing prefix
allocations and improve your addressing efficiency.
Hehe, My
On Mon, 15 Mar 2010, Paul Jakma wrote:
Hehe, My implicit assumption is that there's no significant change
in allocation densities. :)
Oops, here I mean allocation density on a per-prefix basis. (IPv6
obviously completely changes HD on an proportion-of-address space
basis - but shouldnt as
On Mon, 15 Mar 2010, Marshall Eubanks wrote:
Do you have a write-up of this ?
See Geoff Huston's BGP in 2009 presentation:
http://www.potaroo.net/presentations/2010-03-04-bgp2009.pdf
Also see the Simula report referred to in this thread, which does not
disagree with Geoff Huston's data
Hi Constantine,
Toni, you are raising an interesting issue. However, if the sending routers
do not check whether an update is duplicate, and if the receiving
routers do not check whether an update is duplicate, don't we create
a positive feedback loop?
Yes, but I think it was obvious that
On Mon, Mar 15, 2010 at 6:04 PM, Tony Li tony...@tony.li wrote:
employer hat off
Any operator who would like to stand up and embarrass their favorite router
vendor by showing a graph of router boot convergence times is welcome to do
so. ;-)
/employer hat off
eh, I don't have a hat nor a
Folks,
In this context, I think you might be interested in a measurement study
that will be presented at INFOCOM this coming week. The focus of the
study is BGP scalability with respect to churn rates. We have analyzed
six years of Routeviews BGP update traces from four monitors in
different
On Mon, 15 Mar 2010, Robin Whittle wrote:
Also, as just mentioned by Amund Kvalbein:
BGP churn evolution: A perspective from the core
http://simula.no/research/nd/publications/Simula.nd.435/simula_pdf_file
Yes, saw the post of that. Its conclusion does not disagree with
Geoff's results,
Hi Paul,
You wrote:
You have asserted there is no routing scaling problem,
Did I?
Could you go perhaps go back to my message where I said how I
wished to vote. I think you'll find you've misunderstood me.
I have not mentioned anything about voting - there is no voting in
the RRG, and I
On Mon, 15 Mar 2010, Robin Whittle wrote:
I thought that you were arguing against the existence of the
routing scaling problem, because in your first message in this
thread, you wrote:
However, it does not seem justified to say the current routing
architecture has a scaling problem.
Hi Chris,
Thanks for your reply, in which you wrote:
1 - The unreasonable, arguably unscalable, burden placed on the
DFZ routers individually, and on the DFZ control plane in
general, by the set of end-user networks which currently
get portability, multihoming and inbound TE
Hi Paul,
I am replying to your message
Re: [rrg] 2 Possible Consensus Items
http://www.ietf.org/mail-archive/web/rrg/current/msg06277.html
in this earlier thread:
http://www.ietf.org/mail-archive/web/rrg/current/msg06163.html
since you were discussing Geoff Huston's research and the
On Fri, Mar 12, 2010 at 10:29 PM, Robin Whittle r...@firstpr.com.au wrote:
1 - The unreasonable, arguably unscalable, burden placed on the
DFZ routers individually, and on the DFZ control plane in
general, by the set of end-user networks which currently
get portability,
22 matches
Mail list logo
