On Nov 10, 2012, at 12:54 PM, Tony Li wrote:
I agree, but as you correctly point out, SIDR is an engineering solution. If
you dislike that particular solution, you're of course free to propose
others. However, the correct forum for engineering solutions is the IETF.
I was hoping for
On Nov 9, 2012, at 10:29 PM, Noel Chiappa wrote:
We still have the same old kludgy BGP global routing system we always had,
and _nothing_ has been proposed to improve/replace it.
No, but I suspect if we bolt on BGPSEC extensions and things like periodic
updates and per router signing
On Nov 10, 2012, at 12:24 PM, Tony Li wrote:
We still have the same old kludgy BGP global routing system we always had,
and _nothing_ has been proposed to improve/replace it.
Blatantly not true. There's this thing called NIMROD that has been proposed
to replace it. Perhaps you've heard
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
On Feb 17, 2010, at 6:16 PM, Joel M. Halpern wrote:
Should we at least acknowledge in section 5 that our habit of addressing
any and all problems with BGP extensions puts pressure on the control
plane? (It may be that this component is manageable, but I wonder.)
Each of these features
On Feb 5, 2010, at 11:30 AM, Christopher Morrow wrote:
[2] Let's not forget that it's not *just* routes in BGP, but just as
importantly *paths* that has negative scaling implications, as well, on the
control plane, (note slide 13):
http://www.ietf.org/proceedings/74/slides/grow-6.pdf
i
On Feb 12, 2010, at 8:27 AM, Noel Chiappa wrote:
Can you expand on that a bit?
I think the slides here illustrate some of this pretty well, and even
illustrate how implementation optimizations that result in systemic
state and churn are a very bad idea - but most operators don't complain
On Feb 12, 2010, at 12:54 PM, heinerhum...@aol.com wrote:
A corner stone of TARA is the computation of consistent topologies for the
various zooms (just by knowing the standardized scale
ratio).http://www.ietf.org/proceedings/74/slides/grow-6.pdf refers to Route
Reflectors (and what
On Nov 17, 2009, at 8:46 AM, Tony Li wrote:
Do not depend on DNS to get packet delivered.
Sorry, we already broke that. When DNS is down, the net is down. ;-)
Com'n Tony, that's a little disingenuous (unless you
were strictly kidding and not just smirking there :-)
The point is that
On Nov 17, 2009, at 9:57 PM, Shane Amante wrote:
Com'n Tony, that's a little disingenuous (unless you
were strictly kidding and not just smirking there :-)
I don't think he was, particularly in light of the vast majority of end-users
perception that regardless of whether DNS fails or IP
On Jan 31, 2009, at 10:17 PM, Enke Chen wrote:
So here is an alternative (operationally):
accept MEDs from each other and perform longest-exit.
The MEDs could be set by the sender based on the location (community)
so that at most 2 or 3 peering locations would advertise the same
MED.
On Jan 6, 2009, at 4:23 PM, Tony Li wrote:
I know that the internal tables are always a pain, but since we have
to deal
with the global issues, the internal, private growth (self-
inflicted ;-) has
to necessarily be out of scope for RRG.
That's quite odd to me, considering by today's
12 matches
Mail list logo
